更新時間：2025-05-09 21:14:21
數倉開發
624??? 數倉治理是一個非常棘手的問題，通常需要跟著業務需求快速發展。可能存在數據分散在不同團隊或者團隊之間研發規范不一致的情況。從維度模型來約束規范的工作來看，“模型”的治理難度大于“架構”。
目前行業通常的模型治理方法是規定一種建模規范，然后各自按照規范進行編碼。當業務變得模糊不清時，再抽調時間進行人工治理。這種方法就像清理黃河的流沙一樣，雖然可以清理一次又一次，但上游仍然會沖下新的流沙。
因此，考慮換個思路來解決問題。當業務高速發展時，數倉必須跟著發展，否則數倉就沒有意義了。但是業務通常不會一直處于高速發展階段，就像長跑一樣，總會有跑跑停停的時候。所以如果我們遵循一定的做事方法，多一些流程步驟，就可以大大延緩數倉治理的問題。
換句話說，不要追求長期的問題解決，而是以一段時間內的穩定為目標，比如一年。當業務發展到比較穩定的階段時，再來進行治理，既可以避免因業務變動而影響模型重構，也能節省精力和壓力。
完美的解決方案通常是不存在的，所以當技術無法解決問題時，可以嘗試一些另類思路去解決。
數倉的指導思想是以維度建模為基礎，根據業務域和數據域設計主題模型，構建一致性的維度和事實。
具體建模方法如下：首先了解數據的統計周期，是增量同步還是全量同步，并根據預估的數據量設計ODS。其次，大致了解業務域的劃分情況，將一類不可拆分的行為作為一類，例如支付、搜索等。然后根據這些業務過程，構建最明細粒度的事實表（DWD）?；贒WD，可以根據主題對象進行數據建模，構建公共粒度的匯總指標事實表。同時定義一致性的維度（DIM），通常是靜態信息，動態可變屬性應放到DWD中。
掌握了維度建模的核心思想后，每位研發同學都可以開始進行維度建模了。
掌握建模方法并不意味著可以發揮創造力，就像谷歌編碼規范一樣，有很多的Tips要遵循：
表名和字段命名要有規范，指標命名應能推測出大概的涵義；善于利用分區、臨時表等方法降低表的依賴層級；擴展字段應以key-value形式存儲，雖然get_json_object操作慢，但簡潔；小數精度應使用Decimal而不是Double，避免問題；對每個任務進行摸底，解決可能產生數據傾斜的地方，常見于Join的空值問題。
數據問題的檢測是一個復雜的過程。
通常有三種檢測方式：基于統計、基于自動規則和基于價值衡量。
基于統計可以統計ODS/DWD/DWS/ADS層的表數量、業務域的表數量以及每張表的引用次數等，從而了解數倉建設情況。
基于自動規則可以檢測重復開發的表，估算表之間的相似程度，推測是否可以合并。還可以計算表的主鍵和上下游引用，判斷是否可以合并。這種方法需要對數倉模型有較深的理解。
基于價值衡量可以根據收益和成本對數據表的價值進行衡量，優先治理高價值的場景或者尋找低價值的重構點。這種方法需要考慮收益和成本的平衡。
最后提到了工具的重要性，例如FineDataLink可以幫助解決數據表命名、字段命名和權限問題，加速企業數據集成。選擇合適的工具需要結合實際情況，目前市場占有率較高的產品是帆軟ETL軟件——FineDataLink。
我們專注高端建站，小程序開發、軟件系統定制開發、BUG修復、物聯網開發、各類API接口對接開發等。十余年開發經驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！
