數倉治理一場仗

|0x00 老大難的數倉治理

“年年資料要治理，資料年年治不好”。

數倉治理的老大難，通常是跟著業務需求快跑，要不是資料零散在各個團隊，或者是大家的研發規範有不同，作為一項通過維度模型來約束規範的工種來講，“模型”的治理難度，大於“架構”。

目前整個行業通常的模型治理方法，是規定一種建模規範，大家在編碼的過程中各自遵守。當業務開始變得模糊不清的時候，再專門抽調時間，來做人工治理。就像黃河一樣，流沙清理了一次又一次，但上游還是會衝下新的流沙。數倉的假設既然都是採用的維度建模，那麼其設計思想必然是自下而上的進行建設，與架構進行類比，也就是先做好子模組，最後做頂層設計。但如果設計者不熟悉對應的領域模型，一旦業務上發生了變動，一張核心表動輒幾百張的引用，會讓重構的工作變得困難無比。

強如阿里，會做一些更進一步的工作，比如模型的健康分，看看你的儲存成本有多少、計算成本有多少、生命週期是不是合理、程式碼規範有沒有避免全表掃描，等等。但這些工作只能發現一些常規的問題，也依然需要進行人工治理，不僅效率上沒有得到提高，每天推送的郵件也會讓你產生心煩。

投入多少人，投入多少時間，終歸是解決了一時的問題，而非長遠。

因此，換個思路考慮問題，當業務高速發展時，數倉勢必要跟著跑，不然業務都跪了，數倉又有何用。但業務通常不會一直處於高速發展的階段，就像長跑一樣，總有跑跑停停的時候，因此如果我們遵循一定的做事方法，流程上多一點步驟，那麼就會極大的延緩數倉治理的問題。即不追求長久的問題解決，而以一段時間內的穩定為目標，比如一年。當業務已經發展到比較穩定的階段，再回過頭來做治理，既能夠避免因為業務變動而影響模型重構，也可以節省大家的精力和壓力，就不失為一種解決思路了。

完美的解決方案通常不存在，退而求其次是大多數人的選擇。當技術無法解決問題時，不妨用另類思路去解決。

那麼“一定的做事方法”該如何理解呢？聽下文分解。

|0x01 事前：理論

數倉的指導思想是什麼？如果一定有定義，那麼就是：以維度建模為基礎，根據業務域和資料域設計主題模型，構建一致性的維度和事實。

以下簡略敘述理論，維度模型已經有很多的講解文章，這裡只是起到思路講解的作用。

從巨集觀上將，首先要了解資料的統計週期，是增量同步，還是全量同步，並根據預估的資料量設計ODS。

其次，要大致瞭解業務域的劃分情況，將一類不可拆分的行為作為一類，比如支付、比如搜尋。當有了巨集觀的劃分之後，就可以根據這些業務過程，構建最明細粒度的事實表，也就是DWD。

再次，基於DWD便可以根據主題物件進行資料建模，構建公共粒度的彙總指標事實表。很多時候，由於需要加工一定的業務邏輯，可能帶來DWD依賴DWS的情況，比如基於時間序列的業務過程，這裡就需要避免統計型別或者業務型別的邏輯，加工到DWD中，這部分應該放到ADS層去做，儘管這樣在實現上更為複雜，但避免了公共層的頻繁變動。

最後，定義好一致性的維度，即DIM。通常是靜態的資訊，如果存在動態可變的屬性，還是放到DWD比較合適。

從這裡開始，每位研發同學，都可以掌握維度建模的核心思想，通常公共層建設好之後，應該是變動極其小的，為了避免設計不好導致的後續維護問題，模型一定要有評審，即便是忙，也至少要找一個人幫忙進行CodeReview。

根據這些建模方法，我們就可以愉快的進行ADS層的業務開發了。

|0x02 事中：方法

掌握了建模方法，不代表可以發揮創造力，就像谷歌編碼規範一樣，有很多的Tips要貫徹強調：

• 不僅表名設計要有規範，欄位命名也要有規範，指標如果不能根據命名猜出大概的涵義，那麼設計上就是失敗的；

• 善於利用分割槽、臨時表等方法，降低表的依賴層級；

• 擴充套件欄位按照key-value的形式進行儲存，雖然get_json_object慢，但它很簡潔；

• 小數精度要用Decimal，而不是會出問題的Double；

• 每個任務都要進行摸底，解決會產生資料傾斜的地方，常見於Join的空值問題。

每個人平時面試的時候，都會準備許許多多類似的Tips，團隊如果比較規範，也會有一定的文件沉澱。這裡比較考驗一個人的編碼功底了，是P6到P7進階的重要考量。

|0xFF 事後：檢測

資料問題的檢測是一門大學問。

通常而言，檢測有三種方式：基於統計；基於自動規則；基於價值衡量。

基於統計：因為前文提到了，我們能夠根據規範進行編碼，因此我們便可以清晰的統計，ODS/DWD/DWS/ADS層各有多少張表，每個業務域有多少張表，每張表的引用次數是多少，產品出口的ADS表到最底下的ODS表依賴層級有多深，基於這些統計，我們便可以對整個數倉的建設情況有一個大體的瞭解。如果某個資料域表數量過多，或者某個DWD表下游太多，或者ADS到ODS的層級過深，大家便可以根據具體的情況進行治理。這種方法有一個好處：簡單，做幾張BI報表便可以完成，但問題便是，即便知道了具體問題，治理起來也是一件棘手的問題。

基於自動規則：既然提到了，基於統計，我們能夠掌握大體的情況，那麼有沒有方法進行更細化的分析，提供解決的指導思路呢？這邊是基於自動規則的檢測方法。例如，我們可以檢測重複開發的表有哪些，通過表名相似性/欄位相似性/資料量相似性等，估算兩兩之間的相似情況，如果相似程度90%以上，通常它們是可以合併的。再者，我們可以使用更高階的演算法，比如計算兩張表的主鍵與上下游引用，如果主鍵相似，且上下游表高度重合，那麼這樣的兩張表也是可以合併的。準確來講，自動規則，體現了我們對於數倉模型的理解程度。

基於價值衡量：治理也要有優先順序，優先治理高價值的場景，或者尋找低價值的重構點，都是投入側重點的最重要因素。比如，A表只有一個下游，佔用了1TB的空間，而B表有1000個下游，佔用了1GB的空間，是不是意味著B表價值遠大於A表？不見得，只要下游的收益，大於儲存這些資料的成本，就是有用的。因此只根據收益和成本，來衡量資料表的價值，容易產生極端。這裡如果有演算法的同學能夠接入，做一些類似於C-V模型的公式，找出異常點，就能夠相對準確的衡量價值。但這一點目前比較難以實現。

最後提一下工具的重要性。資料治理有一個很棘手的問題，我們發現了有問題的表，如何進行糾正？比如欄位不同了要廢棄，比如命名不規範要重新改，那麼如果下游依賴過多，又涉及許可權問題，基本上就算是無藥可救的狀態了。這時候開發一個外掛，能夠同步Hive解決命名問題，同步下游修改欄位命名，以及將表的許可權複製到新表中，就很有用。