從經驗角度描述：在數據倉庫建設中的會遇到的各種坑和需要注意的關鍵點

前言
大數據時 代，作為數據的掌握者，我們不僅要更好地使用數據，也要更好地管理數據。而數據倉庫正是這樣一套管理和組織數據的解決方案。
本文試圖從一種經驗的角度來描述在數據倉庫建設中的會遇到的各種坑和需要注意的關鍵點，希望以此幫助踏上數據倉庫之路的小伙伴們。
注意：本文不會詳細地解釋數據倉庫的各個概念，亦不會給出各種示例代碼來闡述數據倉庫的建設細節。
一
請理解數據倉庫和數據平臺的區別
當你開始建設數據倉庫之前，需要明白數據倉庫和數據平臺是兩個不同的概念，不要把搭建一套 hadoop + hive 的平臺叫數據倉庫，這是數據平臺的范疇。
我們常說的數據倉庫不僅僅是指數據接入、數據存儲和數據計算，它也要包括數據治理、數據建模和數據挖掘。比如元數據管理、維度建模和 olap 分析，這些都是我們在建設數據倉庫時候要考慮的內容。
二
提前規劃你的數據倉庫
數據倉庫是公司數據體系的核心模塊，數據倉庫可以做的不好，但是不能不做。
因此，在數據體系設計的前期最好要有一定的規劃，即使最簡單的表和字段命名的規范也能帶來很大的收益。
另外，從數據開發的角度出發，在做各種臨時數據處理需求的時候也要有數據倉庫的思維，多嘗試抽象出來數據中間層，這樣對公司和對自己的成長都是有幫助的。
三
實現輕量級的數據倉庫
如果業務的快速發展不能留給你太多的時間來實現一個完善的數據倉庫，那么可以考慮在前期實現一個輕量級的數據倉庫，以盡可能小的成本帶來最大收益。關于這個輕量級的數據倉庫，建議優先考慮如下幾個點：
1.明確數據分層
2.確定可執行的表和字段命名規范
3.定期抽象出常用的中間表
4.建設元數據管理系統，或者建設文檔庫，提供中間表的文檔說明
四
不要脫離業務場景
做數據一定要記得貼近業務，雖說會有很多臨時和重復需求，但卻能切實地創造價值。
切記不要以為可以完全脫離業務去做一套數據倉庫，我們可以在數據倉庫的某個層次不以業務需求為導向來設計，但是最終面向業務的數據一定會是和業務理解有關。
五
文檔！文檔！
數據倉庫建設的初期，要逐步沉淀出各種文檔，比如模型設計文檔、字段命名規范文檔、sql 開發規范文檔。文檔是數據倉庫沉淀的最直觀的一種體現，這也是技術積累的一部分。
最重要的是，如果元數據系統沒有成型，那就要把數據倉庫中間表的內容沉淀到文檔中，盡量做到一表一文檔。這樣不管是從節約溝通成本的角度，亦或是增加團隊積累，更或是完成 kpi 的角度考慮，都是有很大益處的。
六
盡早布局數據質量管理
請盡早布局數據質量管理的內容，不要等到發生嚴重的數據事故后才注意到數據質量問題。關于數據質量監控，如果沒有足夠的時間和精力做一套完整的系統，可以先從以下幾個點入手，這樣至少能對自己有一層基本的保護：
1.核心數據每日數據量級監控和告警
2.重要業務指標監控和告警
3.主要業務流程各階段數據的監控和告警
七
多使用視圖表
多使用視圖表對外提供數據服務，它可以有效地屏蔽業務方對最底層表結構變更的感知，同時加強權限管理。
如下場景可以多考慮使用視圖表：
1.該表經常會有加字段的需求
2.該表的計算口徑會出現變化，需要并行跑多份數據，某個時間點進行表切換
3.該表可能會對不同人或部門提供服務，希望不同人或部門可讀的字段不同
視圖表主要是來晚上表結構變更、口徑修改和權限管理的場景，不要濫用而增加維護成本。
八
考慮你的職業發展
不要一直埋著頭搞 etl，可以搞半年或一年來了解大致的業務和技能，但不能長期這樣發展?，F在開源平臺相對成熟，長時間搞 etl，會弱化自己的技術深度，如果再沒有數據挖掘相關的項目經驗，很容易在以后得面試中被淘汰。
因此，建議各位數據開發的小伙伴，如果你近一年的工作主要都是在用 sql 做 etl，那就要有一點危機意識，經常反思一下自己是否有成長，核心競爭力是否有所提現。
如果有些心虛，可以考慮在數據倉庫、數據挖掘或者核心平臺開發上下一些功夫。