搭建資料倉庫可以從多個方面切入，我接觸到的工作中處理實際工作案例大致分為2中模式。一種是在需求不明確的情況下從底層搭建開始，主要工作重心在於先收集資料，並對資料分類儲存，等到具體需求到位的時候再搭建上層的資料倉庫表（如使用者一體化）。另外一種模式就是在確定需求場景下，根據需求內容向下拆解任務反推需要的資料來源支援（如使用者線上）。兩種模式各有利弊，我的總結如下：

模式1：屬於通用型強的廣泛收集資料，但是會造成很多冗餘和不合理。後期可支援的需求種類會寬泛很多，但是整體專案工程的進度會慢，專案返工的機率很高。目前的主要的應用場景現在只有一種，或正在摸索式中。

模式2：根據需求設計資料針對性強很多，能夠快速的梳理出依據需求得出資料支援關係。按照需求搭建資料產出速度很會很快，當然最終的資料結果可能僅適用case by case的解決問題。

兩種模式其實無論好壞，不同職責的部門可能距離業務需求的遠近不同，無權選擇採用的哪種模式解決問題。但是最終成熟的資料倉庫產品是符合兩種模式的優點的，這就需要兩種模式在不斷優化迭代中逐步完成。

如何分別不同的兩種模式，我們可以從實際的場景中看看兩種模式的反應情況，以便於遇到的時候能注意到利弊。

模式1：常見的實際場景

我們都知道並認同abc資料很重要，但是怎麼分析和使用沒有具體的方案。

例如，我們要分析業務的訂單資料，我們要將訂單資料納入到資料倉庫中。至於支援哪些維度和指標，分析師們以後會怎麼用資料。我們並不清楚。這個是典型的模式1。我很難判斷資料的重要優先順序，也很難合理設定出滿足今後需求的資料表結果。因此，我們只能依賴偏技術性的資料倉庫知識去做管理和維護。將業務庫的訂單資料全部拿過來，將訂單的系統日誌全部拿過來，將埋點的訂單資料全部拿過來。有什麼拿什麼過來形成最底層的ODS層資料就好。幾百幾千的原始資料表資料被灌入到資料倉庫。

這個過程中我們是對資料不加任何多餘考慮的。既然不知道是否有不需要的資料，為了保障完整性全部拿來。也不會知道資料有什麼缺失，反正具體的需求是什麼我們也不知道。

拿來資料是比較方便的，ODS層資料的只要苦力加個班幾天時間就可以將大量的資料灌入資料倉庫。接下來的一步就會非常困難，怎麼分類整理搭建輕度彙總層，將資料加工出彙總的明細資料。這個過程對於研發工程師最大的考驗是熟悉業務（熟悉業務和資料的“對映”關係）。訂單都包含什麼資訊，訂單的建立到消費經歷什麼環節，有多少環節，對應的狀態和引數是什麼？資料之間的關聯關係是一對一，一對多，多對多？訂單對應幾個使用者資訊，訂單資訊會被更改退嗎？

當任何不熟悉業務的資料工程師想要在ODS層的基礎上去搭建上層資料的時候，都會陷入複雜的業務知識和邏輯中。我所經歷的類似工作內容中，能夠一次性搞定這塊資料倉庫搭建的至今成功案例非常少，除非公司業務簡單，老員工佔多數，不然真是浩劫（當然解決辦法也有很多，這個以後再聊更深入點）。所以，如果遇見類似的場景要做2個判斷，a、業務的複雜度。b、有沒有老員工扛大旗。如果不符合這兩個條件，專案儘早認慫或者換思路解決問題。

模式2：常見的實際場景

我們現在有一個數據需求，想看A頁面帶來的訂單轉化資料效果。表頭是日期、城市、模組（頁面整體、頁面子模組）、訂單數，訂單人數，支付訂單數、支付異常訂單數、支付金額，利潤金額。

根據需求去搭建資料倉庫就簡單很多，因為需求明確，所以首要任務是以需求為導向設計方案，在上述提到的資料表頭中我們很容易推斷出資料倉庫各層應該放什麼樣的內容。尤其是對於應用層、資料彙總層的設計，在為了僅滿足一個需求的前提下是很容易給出方案的。那麼接下來的重點主要在於搞清楚業務資料中是否有我們需要的欄位，我們從哪裡抽資料即可（輕度彙總層的資料明細層，主要是對拿過來的ODS層資料進行加工一輪，以便於符合資料倉庫標準和規範，因此這層的設計可有可無也不難處理）。

以上兩種模式在實際工作中，前者需要後期不斷實際需求的提出才能逐步摸清資料給出更好而方案。後者會在新一輪又一輪的資料需求提出過程中發現前期的方案不足慢慢自我優化迭代。