大資料平臺治理——運營的角度看數倉

前言

三分靠技術，七分靠管理，其實一直就是技術崗位的現狀，事實上在一個完整的網際網路產業結構中，除了本身的軟體效能和軟體設計的優雅追求，還有著業務的持續運營以及背後的商業模式的運作。分析師的工作更多的就是指導業務的運營以及商業上成本的考量，以便為進一步的決策提供資料參考，本文就從一個數據分析師的角度去聊一下數倉的治理。

分析框架

開局一張圖

我們說一個數倉的好與壞不是單純的某個地方的好與壞，而是透過從左看右看上看下看達到一個最佳化區域性最優到整體最優的解決方案。我們需要的一個結果就是數倉的健康，當然，健康的定義又可以有很多詮釋，比如說控制野蠻生長、高時效、資產覆蓋度厚實、模型規範、高質量等考量。基於各個方面的考量，我對數倉需要關注的點做了一個梳理，從這些點出發，我們便可以去建立考核的運營指標。從大類的劃分主要分到兩塊，一塊就是資源成本模型，因為本身成本就是錢嘛，另一塊的話就是數倉的規範性，因為數倉的規範性衡量的其實就是數倉好用的一個方向，畢竟這個才是本身數倉的價值所在。

成本模型指標化

數倉的成本模型其實分為兩大塊，一塊就是我們的儲存，另一塊就是計算了，我們關注的就是儲存到底有沒有問題，或者說計算是不是有問題，怎樣去衡量這兩塊健康與否呢，一般是三部曲——技術引數量化+資源消耗成本化+成本指標化，下面我們分別進行說明。

大資料平臺的成本主要是儲存成本和計算成本來衡量。下面從這兩塊進行剖析。

儲存成本化

衡量儲存的技術引數

衡量儲存的引數項主要是空間+格式+壓縮演算法，如下表格：

專案	技術描述
檔案	資料空間、臨時空間、資源空間
格式	文字、ORC、SequenceFile
儲存介質	SSD、HDD、SMR
壓縮演算法	gzip、bzip2、LZO、LZ4、Snappy

儲存的目標

儲存少+備份少+壓縮比高+更省錢便是儲存的目標了，為了達成目標我們其實是透過不同手段去實施的，可想到的辦法可以一張表格：

專案	辦法
儲存少	模型最佳化、減少節點數、週期性清理、無用表刪除、檢視化或者物化檢視
備份少	回收站清理，中間表直接去掉回收站、EC編碼歸檔(3份變成1.5份)
壓縮比高	Orc儲存、資料重分佈、Bucket分桶儲存
省錢	冷備份、便宜儲存介質

儲存成本化

根據儲存的目標，儲存成本化，我們一般是按照計算和儲存總成本進行分攤，*成本=(儲存r1+計算*r2)**，然後進行定價，比如1TB=1塊錢,其中1塊錢按照總成本進行換算分攤，因為還會分攤總的包括機櫃，頻寬的成本，所以成本計算並不代表實實在在的採購成本，但是會有對應的關係。

儲存成本指標

指標的構建可以比較靈活去調整，目標是有效指導且可落地，可衡量成本的參考指標如下:

類別	指標項	粒度	參考獲取
儲存	容量、長生命週期數量	部門、專案、Owner	TopN、彙總、分佈
備份類	回收站生命週期、容量	部門、專案、Owner	TopN、彙總、分佈
壓縮格式	壓縮格式佔比、容量	部門、專案、Owner	TopN、彙總、分佈
低成本	表訪問頻率，儲存格式，容量	部門、專案、Owner	TopN、彙總、分佈

資源成本化

衡量資源的技術引數

衡量計算的主要引數是資源佔用+計算耗時因為資源的計算平臺是比較難容忍高峰期的佔用，且和排程頻率都有關係，所以一般還會考慮排程成本、如下表格:

專案	技術描述
CPU消耗	Task佔用CPU個數*時間
記憶體消耗	Task記憶體佔用*時間
作業時間	XX分鐘
排程頻率	分鐘級、小時級、天級、每天排程次數
排程時間段	高峰時期(00:00-9:00)、低峰時間段(9:00-22:00)
資料傾斜	嚴重傾斜、輕度傾斜
大檔案掃描	長週期數據掃描
資源分佈	低併發、高併發

計算目標

對於資源的最佳化來說，其實目標就是達到計算效能的最佳化，但是計算的場景其實是相對複雜的，針對整個平臺來說，實際的場景是保障高峰時段的資源使用就可以了，而且是關注高優先順序的作業，低峰的話就沒關係了，一般平臺側識別出一些問題場景，針對問題比較大的場景去進行最佳化，同時最佳化側的辦法其實是由平臺和Owner一起出方案進行落地:

專案	辦法
高峰資源減少	不緊急任務錯峰、排程後延、任務定點效能最佳化
高頻作業保障	高頻作業常駐記憶體、批作業流化
作業計算合理性	大掃描、傾斜等任務治理
資源保障	優先順序劃分、資源分配粒度合理、資源借調

資源成本指標

指標的構建可以比較靈活去調整，目標是更多的發現問題，可衡量成本的參考指標如下:

類別	指標項	粒度	參考獲取
資源	資源使用分佈	佇列、部門、專案、Owner	TopN、彙總、分佈、高峰時段、低峰時段
作業問題類	資料傾斜、大掃描、任務報錯	部門、專案、Owner	TopN、彙總、分佈
作業頻率	作業天排程次數	作業級	TopN、彙總、分佈
作業優先順序	高優先順序作業數量、延遲情況	部門、專案、Owner	TopN、彙總、分佈
時效保障	1小時以上作業數量、2小時以上作業數量	部門、專案、Owner	TopN、彙總、分佈

數倉規範

前面提到，數倉的規範其實是衡量數倉好用不好用的一項參考，要想衡量一個數倉好和不好，我們首要的就是給好和不好界定標準、然後根據這個標準去進行匹配，這樣我們就可以對健康程度進行量化，從而產生我們的運營指標。所以對於數倉來說，也是三部曲:——定義標準+標準化度量+模型健康度指標。數倉的衡量主要是在模型規範和層次規範上進行衡量，下面逐一說明。

數倉層次化規範

資料的劃分

資料的劃分其實也就是我們所謂的頂層設計，劃分的方式本身隨著業務的規模，組織結構以及經濟體的要求不同而不一樣，但是不管出於什麼考慮，我們總是希望我們的資料在整個劃分層次上是可以找到對應關係的，不管是傳統的3層也好，5層也好，甚至7層模型也好，我個人觀點可以參考我們的linux對目錄的劃分，不管世界怎麼複雜，都需要有自己的歸屬。

需要了解的是，即使是資料的架構，是緊密跟上時代的變化的，傳統的ODS->DWD->DWS->ADM的場景在企業發展的過程中不斷的經受著新挑戰，首要的其實就是軟體系統的改變，下一步就是資料體系的改變了，所以數倉規範的過程其實是有參考現代容器化部署的思想，引入租戶隔離、單元板塊架構，加上原有的專案劃分和數倉分層便是現代的架構模式了。

層次化規範的考量

我們的考量標準，在劃分的基礎之上對資產都有掛靠，這在一片混亂的資產治理中便是邁向了第一步:

專案	技術描述
單元板塊劃分	有無定義
穿透率	下游對上游訪問是按層次還是直接跨層級訪問
層級覆蓋	指的上一層次的訪問對下游的覆蓋情況，一般是觀測中間層資產的覆蓋程度

層次劃分下的指標

類別	指標項	粒度	參考獲取
資產分佈	可掛靠的資產數量	單元、板塊、專案、Owner	TopN、彙總、分佈
資產分佈	跨板塊不可覆蓋的資產數量	專案、Owner	TopN、彙總、分佈
穿透率	dws、adm等下游應用層穿透到ods的數量、比率	單元、板塊、專案、Owner	TopN、彙總、分佈
穿透率	adm等下游應用直接訪問上一層級dwd\dws的數量、比率	單元、板塊、專案、Owner	TopN、彙總、分佈

模型規範

模型規範主要是從模型定義規範和資料質量上面來衡量，定義規範是保障使用方好用而質量保證是保證資料是對的，這個是對資料最base的要求。

模型定義的規範

表的定義一般是按照層級規範會做表名上的約束，不符合規範的就是異常情況了，規範命名的建議是單獨對不同層次去做規範，因為在ods+dwd+dws+adm表達的資訊其實不一樣，我們的目標是期望在命名上就找到歸類。剩下的便是基礎的對錶使用了

專案	技術描述
表命名規範	是否按照規範定義
生命週期	明確的生命週期和說明
描述資訊	常規的就是中文資訊，其他國際化場景是詳細英文註釋
欄位合理性	欄位的定義、取值是否是遵循儲存內容合理定義
時效要求	期望描述是高優先順序還是常規，對資源分配要求不會一樣
資料來源	期望描述上下文資料的獲取來源
資料質量	準確性、完整性、一致性的要求，需要有對應的dqc規則覆蓋

模型定義規範性指標

類別	指標項	粒度	參考獲取
表命名規範	規範資產+不規範資產定義量	單元、板塊、專案、Owner	TopN、彙總、分佈
生命週期	長週期資產、歷史無訪問的資料情況、數量+明細	專案、Owner	TopN、彙總、分佈、明細清單
時效要求	高基線上的高延遲作業	單元、板塊、專案、Owner	TopN、彙總、分佈
描述資訊	描述資訊、欄位資訊是空的情況	單元、板塊、專案、Owner、表清單	TopN、彙總、分佈
資料質量	資料質量透過率	單元、板塊、專案、Owner、表清單	TopN、彙總、分佈