基于Apache doris怎么構建數據中臺(三)-數據資產管理

前面我們講了什么是數據中臺,及數據中臺的架構及功能規劃,這次我們開始從數據資產開始拆解每個功能模塊做的內容

1.概述

數據資產管理平臺可以定量評估數據資產的成本,價值,質量。幫助企業優化存儲成本,節約計算資源。精細化的數據生命周期管理,幫助企業更好的管理數據的生產到銷毀的整個生命周期。

在管理方面:管理者在規劃數據文化建設時,對企業數據資產的全局構成、使用形式、 使用效果都需要詳細的指標輸入,往往這些指標都沒有被統籌起來;在組織保障上, 需要多少資源、運作機制應該如何制定才能保障數據文化的落地,也需要運營指標來 輔助決策,所以管理者通常需從以下幾個方面的問題進行思考:

  1. 數據如何被用起來?
  2. 數據保值后如何增值?
  3. 組織已不再滿足變化所需?
  4. 管理體系如何建立?

在治理方面:企業擁有大量的數據資產之后,由于分工不同,一般的數據生產者、數據 消費者之間會隨著時間推移、人員變動等因素,造成數據資產的信息成為無人維護的 靜態狀態,數據的存儲成本、檢索的理解成本會越來越高。這些數據資產分布在一片 數據沼澤中,難以分辨數據資產的成本、價值,更難以進行生命周期管理,甚至給數據 消費者帶來難以跨越的信息鴻溝;數據治理通常關注以下幾個方面的問題:

  1. 數據的成本如何降低?
  2. 數據生命周期如何管理?
  3. 數據質量低,如何保證可用?
  4. 數據價值如何評估?

在運營方面:數據資產從被建立,到數據內容的生產、到被使用,各環節用戶各自所關注的、所進行的工作重點不一致;從數據管理視角、數據生產視角、數據應用視角來 看,各個視角之間的目標實現、工作重點、協作方式,不再以點對點的形式存在,而是 貫穿于整個數據鏈路中,數據運營正是為了從以上角度來發現問題、解決問題,作用是:數據運營會從“戰略、執行、目標拆解、跟蹤實現”各個階段進行統籌,對運營目標 負責。數據運營通常關注以下幾個方面的問題:

  1. 有限的資源如何科學分配?
  2. 數據的關系如何互相影響?
  3. 如何發現最迫切的問題?
  4. 數據運營缺乏工具、渠道;

在使用方面:數據只有被用起來,才能發揮其應有的價值。然而當前部分的企業使用 數據的情況并不樂觀。根據調研統計,只有約 14%的企業數據相關的從業人員認為使用 數據是方便的。數據使用是否方便,可從兩個維度來判斷,一是工具:是否能夠具備 “順暢的、快捷的、容易完成的”數據使用場景的工具集;二是時間:是否可以快速地查找、信任、理解數據。根據調研統計,有不低于 80%的時間消耗在“查找-理解-信任”數據的過程中;這兩個現狀成為阻礙數據使用的最大的瓶頸。我們歸納了數據使用的幾 大問題點,如下所示:

  1. 數據孤島亟需打破;
  2. 發現、理解、使用數據耗時費力;
  3. 知識經驗無法共享、迭代;
  4. 溝通不暢、權責不明;
  5. 個人信息無法歸檔;
  6. 數據安全如何保障;

本次只介紹數據資產管理的核心元數據管理及數據資產數據地圖,及數據生命周期管理,其他相關模塊:數據接入,數據處理,數據服務等后面介紹

2.資源管理

實現集中對各種數據資源的管理,包括數據庫,消息隊列等的管理

實現數據庫數據源管理:屬性包括:所屬業務名稱,業務技術負責人,數據源IP,端口、數據庫名稱,用戶名、密碼,數據庫類型(Mysql、oracle、SQLServer、Doris等),創建時間,創建人

實現Kafka數據源管理:屬性包括:Kafka集群名稱,Kafka Broker Server地址(示例:172.22.197.123:9020),對應zookeeper地址(示例:172.22.197.123:2181),創建時間,創建人,集群負責人

3.元數據管理

元數據管理是整個系統的核心,所有的功能及業務流程都是圍繞這個進行的,也是整個系統數據治理的核心

元數據主要解決三個問題:首先,通過建立相應的組織、流程和工具,推動業務標準的落地實施,實現指標的規范定義,消除指標認知的歧義;其次,基于業務現狀和未來的演進方式,對業務模型進行抽象,制定清晰的主題、業務過程和分析方向,構建完備的技術元數據,對物理模型進行準確完善的描述,并打通技術元數據與業務元數據的關系,對物理模型進行完備的刻畫;第三,通過元數據建設,為使用數據提效,解決找數據,理解數據,問題評估難題以及取數和數據可視化難題

4.元數據管理系統架構

這里元數據分為物理元模型和血緣元模型

img

5.元數據采集

元數據采集分為人工錄入和自動抽取,通過人工錄入的方式實現物理表的準確歸屬(包括該表屬于倉庫哪一層、對應的主題、業務過程、星型模型關系等)以及指標的采集,從而完成技術元數據和業務元數據的采集,通過自動抽取的方式完成生產元數據的采集和使用元數據的采集,主要包括:物理模型的依賴關系、存儲占用、熱度等信息

血緣關系:這塊因為我們數倉是用的Apache doris,實現起來相對月Hadoop架構的簡單了很多,通過Flume采集每個Doris Fe節點的審計日志(fe.audit.log)中的sql,通過阿里開源的數據庫連接池Druid進行解析自動生成,這里同時還可以對SQL操作進行一些安全審計,比如Delete,truncate,drop及sql執行成功失敗,執行時間等進行審計預警

5.1 元數據管理功能

1.業務數據元數據同步采集

實現對業務數據庫數據表的元數據自動采集同步,包括建表語句中的中文備注信息,并將中文備注信息填寫到對應的中文字段名稱中,界面提供元數據修改功能,主要修改是添加業務技術負責人、修改表的中文名稱、備注說明等信息,表的字段名稱,類型、長度等信息不允許修改

2.數據倉表元數據采集

實現對數倉數據庫數據表的元數據自動采集同步,包括建表語句中的中文備注信息,并將中文備注信息填寫到對應的中文字段名稱中,界面提供元數據修改功能,主要修改是添加數倉表對應技術負責人、修改表的中文名稱、備注說明等信息,表的字段名稱,類型、長度等信息不允許修改

3.元數據版本管理

因為數據庫表存在結構變更,這里需要提供元數據多的歷史版本管理,可以查詢元數據歷史版本信息

4.業務元數據變更管理及預警

對業務元數據的變更(主要是Mysql數據庫),通過flink監控binlog的schema變更時間,一旦發現及時發送消息通知,后端監控變更消息隊列,取到變更信息,發出元數據變更預警,并自動修改相應的元數據,生成版本信息。

5.元模型構建

分為以物理表為核心的基礎元模型構建,以及以血緣為中心的血緣元模型。

基礎元模型構建以物理表為中心,打通其與技術元數據(主題、業務過程、Schema)的關系,實現了物理表的清晰歸屬,打通其與生產元數據的關系,要加上物理表查詢熱度、資源消耗、查詢密級等生產使用信息,打通其與指標、維度和應用的對應關系,為上層的取數應用建立了完備的元數據。

血緣元模型以血緣為中心,通過監控Doris審計日志,通過sql解析完成自動的血緣關系構建,不僅要構建從上游業務表到倉庫表的物理血緣,而且要打通倉庫表到下游對應報表的血緣,為后續的影響評估構建了完備的元數據基礎

6.虛擬庫及表的管理

對于通過API接口方式對接的數據,要通過頁面手動添加庫,添加表及表字段類型,字段名稱,字段中文名稱,字段長度等等,這樣的目的是為了統一元數據管理方式

5.2 業務元數據

5.2.1 數據域主題管理

  1. 數據倉庫是面向主題(數據綜合、歸類并進行分析利用的抽象)的應用。數據倉庫模型設計除橫向的分層外,通常也需要根據業務情況進行縱向劃分數據域。數據域是聯系較為緊密的數據主題的集合,是業務對象高度概括的概念層次歸類,目的是便于數據的管理和應用。
  2. 數據域是指面向業務分析,將業務過程或者維度進行抽象的集合。為保障整個體系的生命力,數據域需要抽象提煉,并長期維護更新。在劃分數據域時,既能涵蓋當前所有的業務需求,又能讓新業務在進入時可以被包含進已有的數據域或擴展新的數據域。數據域的劃分工作可以在業務調研之后進行,需要分析各個業務模塊中有哪些業務活動。
  3. 數據域可以按照用戶企業的部門劃分,也可以按照業務過程或者業務板塊中的功能模塊進行劃分

數據域的管理本質是一個分類管理,暫定二級分類

數據域主題作用于數倉內部數據表的管理及數據指標的分類管理

5.2.2 數據維度管理

建立統一的維度管理系統,實現對維度信息的統一管控,并為公司的數據產品提供統一的維度數據服務,包含維度開發管理,維度信息管理及維度數據服務三個方面。

維度管理:基于數據維度管理規范,對維度新增、修改、發布等生命周期進行統一管理。

維度服務:基于數據倉庫ODS層模型源數據,建立服務化的維度表模型,在模型基礎上建立維度,包括系統維度和手工維度定義,支持離線和實時大數據量的維度查詢服務,維度創建完成后為各數據產品提供高可用,高性能的數據服務

1, 選擇業務過程 根據業務場景以及可用數據源 2, 聲明粒度 根據事實表及應用場景,確定匯總粒度,一般盡可能的用最細粒度 3, 確定維度 根據確定的粒度,定義對應的維度,最細粒度,也是最低層次的維度 4, 確定事實 確認將哪些事實放到事實表中,維度表只是做關聯,不做維度數據的查詢服務。

維度定義: 維度按集團產業進行指標一級業務域劃分,包括:智能工廠、供應商、采購、銷售、門店、倉儲、運輸、POS等;在各業務域下,對維度進行主題分類,主要有:時間類(DT)、組織類(OG)、產品(PD)、銷售平臺(SP)、經營方式(BM)、終端(TM)、業務渠道(BC)、營銷(MK)、會員(MB)、采購模式(PM)、地點(AD)等。

維度管理:

維度:維度平臺要支持快速定義維度,通過設置維度的基本信息,選擇維度映射的維度表,做好維度與維度表的映射,設定維度的一些特性(布爾維度,時間維度,雜項維度等),檢測維度的定義結果。達到了讓業務人員能夠只是通過頁面操作就可以制定需要的維度。

維度表:數據開發人員可以通過維度庫平臺定義維度表,定義好之后可以集成數據倉庫的同步任務一鍵將倉庫的數據同步到維度表中,將維度表與維度做映射關系。

維度層級:維度庫平臺支持定義維度層級,只要是維度庫平臺上有的維度表并且做好維度與維度的映射關系之后,就可以定義需要的維度層級,根據維度層級提供維度值的上卷下鉆查詢服務。

維度血緣:提供了維度,指標,報表的血緣關系,以及還準備做的維度數據的血緣,維度,指標,報表調用次數的血緣等等。

5.3 數據地圖

數據地圖提供數據檢索能力,致力于提供蜀海生態內豐富數據源的檢索服務。完成找數據的過程,通過該平臺,用戶可以以較小成本找到所需數據,無論是業務數據、數倉數據庫表或字段、數據指標,數據服務都可以通過該功能完成檢索,對業務及數據開發使用人員能很快的找到需要的資源,并根據搜索的結果展示了解數據

img

1.找表

通過統一的查詢頁面,通過輸入關鍵字完成數據表的檢索

在檢索的結果頁面找到符合自己的數據,進去查看表的詳情頁信息,詳情頁展示內容包括

  • 表的詳情信息
  • 表的字段信息
  • 表的數據預覽(最多10條)
  • 表的血緣關系(包括表的上下游依賴,表的關聯關系)
  • 表的使用情況統計
  • 表的建表語句
  • 表評論信息,對于表有不理解的地方可以在這塊進行提問
  • 表的分區信息
  • 表的使用說明
  • 收藏及使用足跡記錄
img

表明細

img

2.找維度

通過統一的維度檢索頁面,通過輸入關鍵字檢索字段信息,點擊字段列表數據,可以查看該字段的信息

  • 維度所在表的信息
  • 維度關聯表的信息
  • 維度說明信息
  • 該維度關聯的指標數據信息
  • 維度評論

3.找指標

通過統一的指標檢索頁面,通過輸入關鍵字檢索指標信息,點擊指標列表數據,可以查看該指標的信息

  • 顯示指標的基本信息
  • 指標的生產鏈路
  • 指標技術邏輯
  • 指標字段信息(按維度和指標分開)
  • 指標數據預覽
  • 指標使用說明
  • 指標評論

指標明細:

img

4.找服務

通過統一的服務檢索頁面,通過輸入關鍵字檢索服務信息,點擊服務列表數據,可以查看該服務的信息

  • 數據服務接口基本信息
  • 數據接口參數及響應說明
  • 數據接口使用說明
  • 接口權限

5.找報表

5.3 數據生命周期管理

主要是為了完成數據從產生、采集、處理、存儲、加工、使用及歸檔銷毀的全生命周期的各個階段的管理

根據數據的使用情況或者根據 用戶設定的數據生命周期,及時幫用戶銷毀數據,在大數據研發中大部分用戶關注的是數據怎么進入數據倉庫,但是很少有用戶會關注數據的銷毀。隨著時間持續性發展之后數據會無限量增加,數據倉庫慢慢的成為一個很大的成本負擔。數據生命周期管理,關注于數據整個鏈路的生命周期管理,及時推薦無效數據下線。 在數據下線的過程中,很多用戶會擔心數據誤刪,完備的數據下線機制,在有效期限內可以對數據進行恢復,確保數據誤刪的情況。

主要是通過數據接入,數據ETL、數據地圖、元數據、數據指標各個系統在使用過程中的使用日志數據,對數據進行一個全面的采集及分析,生成數據在各個階段的數據指標。

生命周期管理關注以下內容:

  1. 數據歸檔管理:對符合歸檔的數據進行歸檔到冷存儲上,減少存儲及計算成本
  2. 統計在數據每個階段的數據變化趨勢
  3. 業務庫DDL變更趨勢
  4. 數據熱度排名:數據庫,數據表的使用熱度統計
  5. 數據庫數據量排名,
  6. 庫內數據表數據排名

根據數據的使用情況或者根據 用戶設定的數據生命周期,及時幫用戶銷毀數據

  1. 在大數據研發中大部分用戶關注的是數據怎么進入數據倉庫,但是很少有用戶會關注數據的銷毀。隨著時間持續性發展之后數據會無限量增加,數據倉庫慢慢的成為一個很大的成本負擔。數據生命周期管理,關注于數據整個鏈路的生命周期管理,及時推薦無效數據下線。 在數據下線的過程中,很多用戶會擔心數據誤刪,完備的數據下線機制,在有效期限內可以對數據進行恢復,確保數據誤刪的情況

5.4 數據資產全景視圖

img

數倉界的360,可以定量評估數據資產的成本,價值,質量。幫助企業優化存儲成本,節約計算資源。精細化的數據生命周期管理,幫助企業更好的管理數據的生產到銷毀的整個生命周期。

  • 資源視圖
  • 數據庫統計
  • 表統計
  • 表引用統計
  • 數據在各個生命周期階段的資源使用情況
  • 文件數量:總文件數,累計存儲量,當月優化存儲量
  • Job統計
  • 優化建議等
  • 足跡

5.5 數據問答

我們為數據地圖中的找表,找維度,找指標,找服務,找報表都提供了數據問答功能,通過評論問答功能,幫助用戶可以快速得到問題反饋:如果用戶看了信息后還是感到有問題,提供評論問答的功能,用戶通過這個功能可以進行提問,會有相應的負責人進行回復。對于重復問反復問的問題,用戶通過查看其它人的提問和回復就能找到答案。并且負責人還會定期的將問答信息沉淀到對應的元數據里,不斷地對元數據進行補充和完善

下一講會講解怎么基于Apache doris實現快速數據接入,零代碼數據接入系統

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,197評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,415評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,104評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,884評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,647評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,130評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,208評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,366評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,887評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,737評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,939評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,478評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,174評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,586評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,827評論 1 283
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,608評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,914評論 2 372

推薦閱讀更多精彩內容