1.理解資料倉庫和資料平臺的區別

當你開始建設資料倉庫之前，需要明白資料倉庫和資料平臺是兩個不同的概念，不要把搭建一套 Hadoop + Hive 的平臺叫資料倉庫，這是資料平臺的範疇。 

我們常說的資料倉庫不僅僅是指資料接入、資料儲存和資料計算，它也要包括資料治理、資料建模和資料探勘。

比如元資料管理、維度建模 和 OLAP 分析，這些都是我們在建設資料倉庫時候要考慮的內容。 

2.提前規劃你的資料倉庫 

資料倉庫是公司資料體系的核心模組，資料倉庫可以做的不好，但是不能不做。 

因此，在資料體系設計的前期最好要有一定的規劃，即使最簡單的表和欄位命名的規範也能帶來很大的收益。 

另外，從資料開發的角度出發，在做各種臨時資料處理需求的時候也要有資料倉庫的思維，多嘗試抽象出來資料中間層，這樣對公司和對自己的成長都是有幫助的。 

3.實現輕量級的資料倉庫

 -- 如果業務的快速發展不能留給你太多的時間來實現一個完善的資料倉庫，那麼可以考慮在前期實現一個輕量級的資料倉庫，以儘可能小的成本帶來最大收益。關於這個輕量級的資料倉庫，建議優先考慮如下幾個點： 

 -- 明確資料分層 

 -- 確定可執行的表和欄位命名規範 

 -- 定期抽象出常用的中間表 

 -- 建設元資料管理系統，或者建設文件庫，提供中間表的文件說明 

4.不要脫離業務場景

做資料一定要記得貼近業務，雖說會有很多臨時和重複需求，但卻能切實地創造價值。 

切記不要以為可以完全脫離業務去做一套資料倉庫，我們可以在資料倉庫的某個層次不以業務需求為導向來設計，

但是最終面向業務的資料一定會是和業務理解有關。

5.文件文件

資料倉庫建設的初期，要逐步沉澱出各種文件，比如模型設計文件、欄位命名規範文件、SQL 開發規範文件。

文件是資料倉庫沉澱的最直觀的一種體現，這也是技術積累的一部分。

最重要的是，如果元資料系統沒有成型，那就要把資料倉庫中間表的內容沉澱到文件中，儘量做到一表一文件。

這樣不管是從節約溝通成本的角度，亦或是增加團隊積累，更或是完成 KPI 的角度考慮，都是有很大益處的。

6.儘早佈局資料質量管理

請儘早佈局資料質量管理的內容，不要等到發生嚴重的資料事故後才注意到資料質量問題。

關於資料質量監控，如果沒有足夠的時間和精力做一套完整的系統，可以先從以下幾個點入手，這樣至少能對自己有一層基本的保護：

-- 核心資料每日資料量級監控和告警

-- 重要業務指標監控和告警

-- 主要業務流程各階段資料的監控和告警

7.多使用視圖表

多使用視圖表對外提供資料服務，它可以有效地遮蔽業務方對最底層表結構變更的感知，同時加強許可權管理。

如下場景可以多考慮使用視圖表：

-- 該表經常會有加欄位的需求

-- 該表的計算口徑會出現變化，需要並行跑多份資料，某個時間點進行表切換

-- 該表可能會對不同人或部門提供服務，希望不同人或部門可讀的欄位不同

-- 視圖表主要是來晚上表結構變更、口徑修改和許可權管理的場景，不要濫用而增加維護成本。