作者 | 張志豪

?數據倉庫是什么？

還是得先從定義開始：數據倉庫是一個面向主題的(Subject Oriented)、集成的(Integrated)、相對穩定的(Non-Volatile)、反映歷史變化(Time Variant)的數據集合，用于支持管理決策。這里的“支持決策”往往是面向分析的，需要能夠對業務系統的數據進行大批量的、多維度的數據探索和分析，從而幫助最終的業務決策。此文是我對于數據倉庫項目的一點點感悟，不涉及具體的技術實現。

但它從來都不是(純)技術項目

數據倉庫項目上用到了很多技術組件，相信很多人都可以用報菜名的方式列舉出來，聽起來像是一個用了很多時髦組件、很性感的技術項目。但如果從權重上來看，我認為技術不是最重要的部分。對于數據倉庫項目而言，更需要的是一套策略，一套組合拳，不僅僅需要技術卓越、業務理解，還需要需求方、業務方在整體架構和流程上的配合。

數據倉庫建設應該包括這些主要流程：

• 業務需求訪談、業務架構設計；?
• 技術選型、技術架構設計；?
• 客戶頂層戰略支持以及各個業務方、需求方的配合；?
• 具體業務需求分析、數據建模；?
• ETL導入數據；?
• 報表開發、數據服務、數據集市等。?

數據倉庫項目實施不是一開始就馬上接數據進來，而是需要經過前期的幾輪業務訪談確定整體的業務需求并完成總體業務架構設計，并根據業務架構和具體的客戶技術狀況確定頂層的技術選型和技術架構設計，在和數據倉庫涉及到的業務方、需求方、技術方等同步確定并獲得了各方支持之后才能準備開始真正準備接入數據，也就是上述4~6這幾個步驟。 

而4~6是不斷地在進行的過程，而不是等到所有業務分析結束之后再進行ETL的部分。目的是快速接入、快速出結果、快速見效，如果遇到問題也可快速調整，更重要的目的是獲得客戶信任。如果時間拉得太久，客戶很有可能會因為看不到效果而喪失信心。這個邏輯也類似于故事卡中的“縱向拆分”。

“客戶的游艇在哪里？”姊妹篇：“客戶的金子在哪里？”

說起數據倉庫，用到比較多的比喻是“海平面下的冰山”和“沉睡在礦山的黃金”。如果我們只是把多個不同業務系統的礦石（數據）搬過來、規整規整，是不能淘到金子的。如果耗費大量人力物力，而只是做了搬運工的工作，那整個項目就是“虧錢”的項目。因為它沒有產生業務價值（金子）。這個時候不禁自問：“客戶的金子在哪里”?

我理解業務價值主要分布在這些領域：

• 支撐運營，輔助決策：各類活動、業務增長依賴于數據來做決策，這時核心指標計算、對齊各個業務口徑、多維度分析等十分重要，準確及時的結果能夠幫助客戶制定運營決策。?
• 數據分析：對于用戶轉化、用戶行為分析等場景，數據探索、交互式分析、數據可視化等支持十分重要。?
• 業務支撐：機器學習、風控、數據服務、推薦系統等對于數據倉庫提出了更高的要求。?

也不局限于上述的幾個領域，我認為主要的判斷條件是數據倉庫的產出結果是否為業務系統提供了有價值、甚至是可以直接變現的支持作用。比如風控和推薦系統就可以從防止了多少可能的財產損失和提升了多少訂單轉化率兩個維度來衡量“金子”的價值。

如果只是說我們這個月多了xxx張報表，新接入了xxx個業務系統，進行了xxx次業務訪談聽起來好像很忙，但仔細想想其實并沒有產生太多的“金子”。也有人說可以通過衡量ROI（投資回報率（ROI）= 年利潤/投資總額）來量化“含金量”，在實際操作中“年利潤”可能還好計算，但是“投資總額”往往難以衡量，因為底層的數據、集群、運維往往是和其他業務數據共用的，且很多流程的數據流非常長，這大大增加了衡量“投資總額”的難度，以至于大多數據倉庫都很難精確衡量投資了多少。這也不意味著就可以完全不用思考ROI了，我認為即使沒有精確的數據，也可以用預估的方式來粗略的判斷大致的ROI是多少，而不是悶頭往前走。

同時前期的步驟也非常重要，沒有前期的數據搬運、建模等步驟，這些“金子”就變成了無源之水，前期的數據獲取、數據清洗、數據建模等步驟決定了能不能淘到高質量的黃金。這里更像“木桶理論”，從業務分析、數據建模、數據加載、數據清洗、數據轉換到指標計算、報表開發、數據分析、機器學習等等步驟如果有一塊短板都會導致其他過程的產出“含金量”下降，尤其是前期的步驟，如果前期步驟沒有做好，后續幾乎就是“garbage in, garbage out”了。?