備註:文章內容借鑑了郭憶老師《數據中臺》課程,想了解更多可以看這個課程哈、
目錄：
一、元數據
1、數據字典
2、數據血緣
3、數據特徵
二、指標管理
1、如何規範化定義指標
三、數據模型
1、我建模的方法
2、理想的數倉模型設計應該具備的因素
3、已經存在煙囪式開發，如何變成一個數據中臺？
四、數據質量
1、如何提高數據質量
2、如何衡量數據質量
五、數據成本
1、有哪些成本的陷阱
2、如何實現精細化成本管理
3、治理效果評估
六、數據管理工具
不對學習的內容總結，總覺得自己沒學習到。這10天在極客時間上面看了郭憶《數據中臺》課程，裏面的內容每一條都戳中工作遇見的問題，曾吐槽無數次的數據模型煙囪式開發、無數據指標管理、數據質量不能監控、無數據血緣關係分析，在這裏都找到判斷標準和解決思路了。
課程主要講了數據只加工一次，數據服務統一的API接口。也就是阿里數據中臺的onedate、oneservice的思想。onedate就是數據只加工一次，這是我工作中主要遇見的問題；數據服務的思想是第一次看見、相見恨晚又慶幸自己看見了、它幫我貫穿了數據體系。
數據加工和數據服務都非常重要，本篇文章是對onedate數據加工總結。onedata主要包括六個部分：元數據、指標管理、數據模型、數據質量、數據成本、「元數據、指標、數據模型、數據質量、數據成本」管理工具。
管理工具貫穿整個體系，每個階段都需要工具管理。剩下的五個部分是獨立的，可以逐個突破，除了首先得梳理元數據、剩下的模塊可以選擇重要的解決
一、元數據
元數據中心是數據中臺的基石，它提供了我們做數據治理必須的數據支撐。比如通過數據血緣：
- 可以根據數據血緣定位數據質量問題
- 可以根據數據血緣計算數據成本
- 可以根據數據血緣，對大數據平臺上運行的任務和分析查詢進行的統計
（每層表活躍數量、查詢數量、每層查詢任務目標表分層情況），判斷模型好壞。
而數據指標是元數據中心的一部分，所以我們在做數據治理的時候第一步需要梳理元數據。
元數據描述是到每張表的，包括三個部分數據字典、數據血緣、數據特徵。
1、數據字典：
數據字典包括表名、表註釋、表產出、表英文字段、字段含義、字段類型
以前我以爲數據字典就是字段註釋，哈哈
2、數據血緣：
表通過哪些表加工而來，要到字段級別，字段通過哪些表加工而來。
數據血緣可以做影響分析和問題溯源。
3、數據特徵：數據的屬性信息
數據特徵包括存儲空間大小，訪問熱度（每次n次）、分層、主題域、表關聯的指標。表的主題域、分層、存儲空間大小經常接觸；表的訪問熱度和表關聯指標需要理解一下。
第一次看見在描述表特徵的時候，可以把表關聯的指標列出來。關聯上指標、後期在對指標搜索的時候，可以快速定位到某張表。
4、我的思考
元數據就3部分，比較容易理解，但是怎麼管理元數據同樣是我們關心的。比如我們天天說的數據血緣，數據血緣是怎麼通過工具維護的。知道了方向要利用工具去實現還是挺難的，開發一個工具難、哈哈。
補充一下：可以去了解 Metacat 和 Atlas 這兩款產品，一個擅長於管理數據字典，一個擅長於管理數據血緣。
Metacat數據字典維護：
Metacat多數據源的可擴展架構設計，它並沒有單獨再保存一份元數據，而是採取直連數據源拉的方式。想到在以前公司也會管理元數據、也是通過添加數據源、連接數據庫、實時獲取數據字典等信息
Apache Atlas 實時數據血緣採集
血緣採集，一般可以通過三種方式：
- 通過靜態解析 SQL，獲得輸入表和輸出表；
- 通過實時抓取正在執行的 SQL，解析執行計劃，獲取輸入表和輸出表；
- 通過任務日誌解析的方式，獲取執行後的 SQL 輸入表和輸出表。
第一種方式，面臨準確性的問題，因爲任務沒有執行，這個 SQL 對不對都是一個問題。第三種方式，血緣雖然是執行後產生的，可以確保是準確的，但是時效性比較差，通常要分析大量的任務日誌數據。所以第二種方式，是比較理想的實現方式，而 Atlas 就是這種實現。
二、指標管理
指標劃一般分爲原子指標、派生指標、衍生指標。我接觸到的是指標通常是由兩個指標相除計算而來；一個指標對應一個需求、一長段的描述。
剛開始我還沒迫切想對指標分類，最讓頭痛是指標重複計算，相同指標結果不一樣。看課程才知道原來指標也需要管理的，但對於已經存在的指標梳理，是很難的工作，主要是領導沒意識，沒人去推動這項工作吧。
雖然沒接觸規範的指標，但可以學習如何管理它，還是可以一起了解下
1、如何規範化定義指標
1）按照按照業務條線、主題域、業務過程管理指標
2）按原子指標、派生指標、複合指標管理
2.1) 原子指標就是基於業務過程的度量值，比如訂單金額。也可以把原子指標定義爲不能夠按照（統計週期、統計粒度、業務限定詞）進一步拆分的指標
2.2) 派生指標 = 統計週期（近30天）+ 統計粒度(商品) + 業務限定（黑卡會員/非會員） + 原子指標（購買用戶數）。
粒度：就比如統計銷售額的時候會按照，省、市、縣、區、商品大類、商品小類等統計。
修飾詞：就是維度的屬性值，就比如商品大類的屬性值可以劃分爲
蔬菜、水果、飲料
2.3)複合指標:兩個或者多個指標，通過一定規則，計算出來的，即爲複合指標
3）指標命名規範
指標命名規範要遵循兩個基本的原則：
易懂，就是看到指標的名稱，就可以基本判斷這個指標歸屬於哪個業務過程；
統一，就是要確保派生指標和它繼承的原子指標命名是一致的
4）關聯的應用和可分析維度
指標對應的報表
指標可分析維度
5）分等級管理指標
指標那麼多，數據中臺管理不過來，可以把指標區分等級，來管理指標
一級指標：數據中臺直接產出，核心指標（提供給公司高層看的）、原子指標以及跨部門的派生指標。
二級指標：基於中臺提供的原子指標，業務部門創建的派生指標。
爲什麼要區分原子指標和派生指標呢？ 全當原子指標，不就好了，這樣能確保每個指標的業務口徑都在指標系統裏面強管理。
但是這樣的後果，是指標的管理工作量太大了，而且整個數據分析的瓶頸會壓在指標的管理上。所以就想出來一個方法，能不能把原子指標中，不涉及口徑的指標，可以拆出來，而這些就是派生指標。
2、思考
對於經常變化的業務可以先不梳理指標，對於已經穩定不變化的業務需要梳理指標、統一指標的業務計算口徑。
其實指標管理目前工作中不怎麼用，可以先了解擴充知識。
三、數據模型
不知道規範的模型應該是怎樣的，看得最多的就是基於業務過程進行維度建模。在《數據中臺》課程中，主要是評價模型好壞的思路，並沒有講dwd、dws、ads如何建模及案例等。
1、我建模的方法
總結下我dwd、dws建模的思想，我認爲不完善、沒借鑑意義。先簡單記錄下。在網上看的建模案例比較少，而且針對dws層建模思路都是每日的彙總表，在工作中，我覺得dws建成覆蓋小業務過程的大寬表更好使用
1)DWD
維度建模一般按照以下四個步驟：
選擇業務過程→聲明粒度→確認維度→確認事實。
目前我們的業務過程都是根據需求來的，所以我在dwd層建模一般是：根據需求所涉及的業務過程------》在業務系統中找到對應的表-----》建模：dwd的模型結構可以跟業務庫中表結構一樣，只是會存在數據清洗、及維度退化。
最近dwd層經常在加字段，主要是流程的開始時間和流程的審批通過時間,應該還是業務不熟悉
2)DWS
聽見最多的就是dws層是彙總層、大寬表。建一些大寬表還是比較適用的。比如我們可以一個大的業務過程、或者一個大的主題域建寬表明細表、和寬表彙總表。
2、理想的數倉模型設計應該具備的因素
一個理想的數倉模型設計應該具備的因素，那就是“數據模型可複用，完善且規範”。
1）DWD 層完善度
ODS 層有多少表被 DWS/ADS/DM 層引用。因爲** DWD 以上的層引用的越多，就說明越多的任務是基於原始數據進行深度聚合計算的，明細數據沒有積累，無法被複用，數據清洗、格式化、集成存在重複開發**
跨層引用率：ODS 層直接被 DWS/ADS/DM 層引用的表，佔所有 ODS 層表（僅統計活躍表）比例。
2)DWS/ADS/DM 層完善度
考覈彙總數據的完善度，我認爲主要看彙總數據能直接滿足多少查詢需求
彙總數據查詢比例：DWS/ADS/DM 層的查詢佔所有查詢的比例。
跟跨層引用率不同，彙總查詢比例不可能做到 100%，但值越高，說明上層的數據建設越完善，對於使用數據的人來說，查詢速度和成本會減少
3）模型複用度
數據中臺模型設計的核心是追求模型的複用和共享。
模型引用係數：一個模型被讀取，直接產出下游模型的平均數量。
比如一張** DWD 層**表被 5 張 DWS 層表引用，這張 DWD 層表的引用係數就是 5。dwd的表被ads層的表引用可以算引用係數嗎？。DWD 層表平均模型引用係數，一般低於 2 比較差，3 以上相對比較好（經驗值）
5）規範度
規範的表命名應該包括主題域、分層、表是全量快照，還是增量等
更好管理數據模型，可以看每層表活躍表數據量、被讀表數量、被寫表數量、讀表任務數量、寫表任務數量。根據各層數量、可以看出模型建設的完善度。
比如：ODS：DWD：DWS：ADS 的讀取任務分別是 1072：545：187：433，直接讀取 ODS 層任務佔這四層任務總和的 47.9%，這說明有大量任務都是基於原始數據加工，中間模型複用性很差。
3、已經存在煙囪式開發，如何變成一個數據中臺？
- 1）接管 ODS 層，控制源頭
- 2）劃分主題域，構建總線矩陣
- 3）構建一致性維度
- 4）事實表整合
- 5）模型開發
關於數據模型，課程給了檢驗模型的指標。至於如何建模，還需要學習。
四、數據質量
學了之後，發現數據質量都是相通，需要添加數據質量稽覈規則，以前的添加的稽覈規則是及時性、一致性、規範性；有些規則在數據中臺中也可以使用。
1、如何提高數據質量
要想提升數據質量，最重要的就是“早發現，早恢復”
- 早發現，是要能夠先於數據使用方發現數據的問題，儘可能在出現問題的源頭髮現問題，這樣就爲“早恢復”爭取到了大量的時間。
- 早恢復，就是要縮短故障恢復的時間，降低故障對數據產出的影響
1）添加稽覈校驗任務
在數據加工任務中，對產出表按照業務規則，設計一些校驗邏輯，確保數據的完整性、一致性和準確性
- 完整性規則。主要目的是確保數據記錄是完整的，不丟失.常見的稽覈規則:表數據量、表主鍵
- 一致性規則：解決相關數據在不同模型中一致性的問題
- 準確性規則：解決數據記錄正確性的問題。常見的稽覈規則有，一個商品只能歸屬在一個類目，數據格式是不是正確的 IP 格式，訂單的下單日期是還沒有發生的日期等等。
2）通過智能預警，確保任務按時產出
2、如何衡量數據質量
- 4 點半前數據中臺核心任務產出完成率
- 基於稽覈規則，計算表級別的質量分數
- 需要立即介入的報警次數，通常以開啓循環報警的電話報警次數爲準
-
數據產品上所有指標有沒有在 9 點產出
![]()
元數據中心、指標管理、數據模型、數據質量，越瞭解到後面越感受到數據治理很難，研發管理工具難、知道原理方法實施難。不過如果自己深入其中肯定會成長不少，這些點也是提升的方向。
五、數據成本
數據成本是在《數據中臺》課程中，才瞭解到。以前沒想過數據還需要計算成本。
郭憶老師在課程裏說過：數據像手機中的圖片，我們總是不斷地拍照，生成圖片，卻懶得清理，最終手機裏面的存儲經常不夠用。對於30天內沒使用的表可以下線。
1、有哪些成本的陷阱
1）數據上線容易下線難
我們可以統計最近30天表使用情況，做成上圖所似的數據
2） 低價值的數據應用消耗了大量的資源
數據看上去每天都在被訪問，但究竟產出了多少價值，投入和產出是否匹配？這個我們需要思考。
3）煙囪式的開發模式
煙囪式的開發不僅會帶來研發效率低的問題，同時因爲數據重複加工，還會存在資源浪費的問題
4）數據傾斜
數據傾斜會讓任務性能變差，也會浪費大量的資源
5）數據未設置生命週期
原始數據和明細數據，會保留完整的歷史數據，彙總層、應用層、集市層，考慮導數據存儲成本，數據按照生命週期管理。
大表未設置生命週期、會造成浪費存儲資源。
思考：比如我們公司彙總層的數據從上線開始，每天的數據都保存下來。這樣就很浪費資源
6）調度週期不合理
7）任務參數配置
8）數據未壓縮
2、如何實現精細化成本管理
1)全局資產盤點
根據數據血緣關係，可以得到末端數據的成本和價值。
**這張報表的成本 **=3 個任務加工消耗的計算資源成本 +6 張表消耗的存儲資源的成本
3)數據價值
3、治理效果評估
省了多少錢
- 下線了多少任務和數據
- 這些任務每日消耗了多少資源
- 據佔用了多少存儲空間
成本治理不是一勞永逸的工作，需要持之以恆，不斷髮現問題，然後治理優化
關於數據成本我目前是學習裏面的思想。我認爲自己目前能接觸並且重要的是數據模型。以及相關的技術也需要提升。
六、數據管理工具
數倉onedate最後一步就是數據工具管理，如果是購買的平臺這些工具都是有的，如果是自己研發可以參考已經有的開源工具。
總結
寫到最後腦袋是懵的，不過在複習一篇《數據中臺》建設方法任然收穫很多。
在附上數據開發職業規劃：熟練的使用數據中臺支撐技術體系內的工具，熟悉數據中臺模式下數據研發的流程，對指標定義、維度建模、數據質量稽覈監控、成本的管理、數據安全、數據服務化等內容要有深入的掌握。