The Tips of Data Warehouse

資料倉庫 · 發表 2018-09-17 22:59:16

摘要：大資料時代，作為資料的掌握者，我們不僅要更好地使用資料，也要更好地管理資料。而資料倉庫正是這樣一套管理和組織資料的解決方案。本文試圖從一種經驗的角度來描述在資料倉庫建設中的會遇到的各種坑和需要注意的關鍵點，希望以此幫助踏上資料倉庫之路的小夥伴們。注意：本文不會詳細地解釋資料倉庫的各...

大資料時代，作為資料的掌握者，我們不僅要更好地使用資料，也要更好地管理資料。而資料倉庫正是這樣一套管理和組織資料的解決方案。

本文試圖從一種經驗的角度來描述在資料倉庫建設中的會遇到的各種坑和需要注意的關鍵點，希望以此幫助踏上資料倉庫之路的小夥伴們。

注意：本文不會詳細地解釋資料倉庫的各個概念，亦不會給出各種示例程式碼來闡述資料倉庫的建設細節。

正文

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

我們常說的資料倉庫不僅僅是指資料接入、資料儲存和資料計算，它也要包括資料治理、資料建模和資料探勘。比如元資料管理、維度建模和 OLAP 分析，這些都是我們在建設資料倉庫時候要考慮的內容。

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

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

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

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

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

切記不要以為可以完全脫離業務去做一套資料倉庫，我們可以在資料倉庫的某個層次不以業務需求為導向來設計，但是最終面向業務的資料一定會是和業務理解有關。

資料倉庫建設的初期，要逐步沉澱出各種文件，比如模型設計文件、欄位命名規範文件、SQL 開發規範文件。文件是資料倉庫沉澱的最直觀的一種體現，這也是技術積累的一部分。

最重要的是，如果元資料系統沒有成型，那就要把資料倉庫中間表的內容沉澱到文件中，儘量做到一表一文件。這樣不管是從節約溝通成本的角度，亦或是增加團隊積累，更或是完成 KPI 的角度考慮，都是有很大益處的。

請儘早佈局資料質量管理的內容，不要等到發生嚴重的資料事故後才注意到資料質量問題。關於資料質量監控，如果沒有足夠的時間和精力做一套完整的系統，可以先從以下幾個點入手，這樣至少能對自己有一層基本的保護：

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

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

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

不要一直埋著頭搞 ETL，可以搞半年或一年來了解大致的業務和技能，但不能長期這樣發展。現在開源平臺相對成熟，長時間搞 ETL，會弱化自己的技術深度，如果再沒有資料探勘相關的專案經驗，很容易在以後得面試中被淘汰。

因此，建議各位資料開發的小夥伴，如果你近一年的工作主要都是在用 SQL 做 ETL，那就要有一點危機意識，經常反思一下自己是否有成長，核心競爭力是否有所提現。

如果有些心虛，可以考慮在資料倉庫、資料探勘或者核心平臺開發上下一些功夫。