「年年資料要治理，資料年年治不好」。
數倉治理的老大難，通常是跟著業務需求快跑，要不是資料零散在各個團隊，或者是大家的研發規範有不同，作為一項通過維度模型來約束規範的工種來講，「模型」的治理難度，大於「架構」。
目前整個行業通常的模型治理方法，是規定一種**建模規範，大家在編碼的過程中各自遵守。當業務開始變得模糊不清的時候，再專門抽調時間，來做人工治理。就像黃河一樣，流沙清理了一次又一次，但上游還是會衝下新的流沙。數倉的假設既然都是採用的維度建模，那麼其設計思想必然是自下而上**的進行建設，與架構進行模擬，也就是先做好子模組，最後做頂層設計。但如果設計者不熟悉對應的領域模型，一旦業務上發生了變動，一張核心表動輒幾百張的引用，會讓重構的工作變得困難無比。
強如阿里，會做一些更進一步的工作，比如模型的健康分，看看你的儲存成本有多少、計算成本有多少、生命週期是不是合理、**規範有沒有避免全表掃瞄，等等。但這些工作只能發現一些常規的問題，也依然需要進行人工治理，不僅效率上沒有得到提高，每天推送的郵件也會讓你產生心煩。
投入多少人，投入多少時間，終歸是解決了一時的問題，而非長遠。
因此，換個思路考慮問題，當業務高速發展時，數倉勢必要跟著跑，不然業務都跪了，數倉又有何用。但業務通常不會一直處於高速發展的階段，就像長跑一樣，總有跑跑停停的時候，因此如果我們遵循一定的做事方法，流程上多一點步驟，那麼就會極大的延緩數倉治理的問題。即不追求長久的問題解決，而以一段時間內的穩定為目標，比如一年。當業務已經發展到比較穩定的階段，再回過頭來做治理，既能夠避免因為業務變動而影響模型重構，也可以節省大家的精力和壓力，就不失為一種解決思路了。
完美的解決方案通常不存在，退而求其次是大多數人的選擇。當技術無法解決問題時，不妨用另類思路去解決。
那麼「一定的做事方法」該如何理解呢？聽下文分解。
數倉的指導思想是什麼？如果一定有定義，那麼就是：以維度建模為基礎，根據業務域和資料域設計主題模型，構建一致性的維度和事實。
以下簡略敘述理論，維度模型已經有很多的講解文章，這裡只是起到思路講解的作用。
從巨集觀上將，首先要了解資料的統計週期，是增量同步，還是全量同步，並根據預估的資料量設計ods。
其次，要大致了解業務域的劃分情況，將一類不可拆分的行為作為一類，比如支付、比如搜尋。當有了巨集觀的劃分之後，就可以根據這些業務過程，構建最明細粒度的事實表，也就是dwd。
再次，基於dwd便可以根據主題物件進行資料建模，構建公共粒度的彙總指標事實表。很多時候，由於需要加工一定的業務邏輯，可能帶來dwd依賴dws的情況，比如基於時間序列的業務過程，這裡就需要避免統計型別或者業務型別的邏輯，加工到dwd中，這部分應該放到ads層去做，儘管這樣在實現上更為複雜，但避免了公共層的頻繁變動。
最後，定義好一致性的維度，即dim。通常是靜態的資訊，如果存在動態可變的屬性，還是放到dwd比較合適。
從這裡開始，每位研發同學，都可以掌握維度建模的核心思想，通常公共層建設好之後，應該是變動極其小的，為了避免設計不好導致的後續維護問題，模型一定要有評審，即便是忙，也至少要找乙個人幫忙進行codereview。
根據這些建模方法，我們就可以愉快的進行ads層的業務開發了。
掌握了建模方法，不代表可以發揮創造力，就像谷歌編碼規範一樣，有很多的tips要貫徹強調：
每個人平時面試的時候，都會準備許許多多類似的tips，團隊如果比較規範，也會有一定的文件沉澱。這裡比較考驗乙個人的編碼功底了，是p6到p7高階的重要考量。
資料問題的檢測是一門大學問。
通常而言，檢測有三種方式：基於統計；基於自動規則；基於價值衡量。
基於統計：因為前文提到了，我們能夠根據規範進行編碼，因此我們便可以清晰的統計，ods/dwd/dws/ads層各有多少張表，每個業務域有多少張表，每張表的引用次數是多少，產品出口的ads表到最底下的ods表依賴層級有多深，基於這些統計，我們便可以對整個數倉的建設情況有乙個大體的了解。如果某個資料域表數量過多，或者某個dwd表下游太多，或者ads到ods的層級過深，大家便可以根據具體的情況進行治理。這種方法有乙個好處：簡單，做幾張bi報表便可以完成，但問題便是，即便知道了具體問題，治理起來也是一件棘手的問題。
基於自動規則：既然提到了，基於統計，我們能夠掌握大體的情況，那麼有沒有方法進行更細化的分析，提供解決的指導思路呢？這邊是基於自動規則的檢測方法。例如，我們可以檢測重複開發的表有哪些，通過表名相似性/字段相似性/資料量相似性等，估算兩兩之間的相似情況，如果相似程度90%以上，通常它們是可以合併的。再者，我們可以使用更高階的演算法，比如計算兩張表的主鍵與上下游引用，如果主鍵相似，且上下游表高度重合，那麼這樣的兩張表也是可以合併的。準確來講，自動規則，體現了我們對於數倉模型的理解程度。
基於價值衡量：治理也要有優先順序，優先治理**值的場景，或者尋找低價值的重構點，都是投入側重點的最重要因素。比如，a表只有乙個下游，占用了1tb的空間，而b表有1000個下游，占用了1gb的空間，是不是意味著b表價值遠大於a表？不見得，只要下游的收益，大於儲存這些資料的成本，就是有用的。因此只根據收益和成本，來衡量資料表的價值，容易產生極端。這裡如果有演算法的同學能夠接入，做一些類似於c-v模型的公式，找出異常點，就能夠相對準確的衡量價值。但這一點目前比較難以實現。
最後提一下工具的重要性。資料治理有乙個很棘手的問題，我們發現了有問題的表，如何進行糾正？比如字段不同了要廢棄，比如命名不規範要重新改，那麼如果下游依賴過多，又涉及許可權問題，基本上就算是無藥可救的狀態了。這時候開發乙個外掛程式，能夠同步hive解決命名問題，同步下游修改字段命名，以及將表的許可權複製到新錶中，就很有用。
文章**於木東居士
數倉建設生命週期 數倉治理一場仗
分享資料大咖實踐經驗 網羅職場大佬成長秘籍 年年資料要治理，資料年年治不好 數倉治理的老大難，通常是跟著業務需求快跑，要不是資料零散在各個團隊，或者是大家的研發規範有不同，作為一項通過維度模型來約束規範的工種來講，模型 的治理難度，大於 架構 目前整個行業通常的模型治理方法，是規定一種建模規範，大家...
資料治理 VS 公司治理 IT治理 數倉治理
如題，今天要聊得這個話題，包含了四個 治理 看完這張圖你有什麼想法，這張圖說明了什麼？它是在描述公司治理 it治理 數倉治理和資料治理的關係嗎？如果這張圖是在描述四個 治理 之間的層次結構，那你認為哪乙個結構是正確的呢？如果您是企業的高管，您會選擇哪個結構，來實施 治理 呢？01 資料治理 vs 公...
一場遊戲一場夢
勝，不妄喜，敗，不惶餒。胸有激雷而面如平湖者，可拜上將軍。中午突然收到老爸發來的這條簡訊，非常驚奇，因 血色浪漫 昨晚正好看到這一段，鄭桐在鐘躍民出征前對他說的一席話。當時覺得很觸動人心就把它記到手機裡，也想了好一會。沒想到老爸老媽昨天在家也正好看到這裡。這個巧合也太有心靈感應之嫌疑吧？其實這樣的話...