數據倉庫是所有產品的數據中心，公司體系下的所有產品產生的所有數據最終都流向數據倉庫，可以說數據倉庫不產生數據，也不消費數據，只是數據的搬運工。
記得很久以前曾有一位前輩和我說過：“進來的數據是垃圾數據，出去也是垃圾數據”。
在實際環境中，往往我們一條業務線會由多個不同的系統支撐組成（例如：很多電商後端業務線都區分爲庫存系統、售後系統、採購系統、CRM系統等）。
這些系統由於本身設計的缺陷或業務流程變更等問題，所產生的數據往往都是有缺失、冗餘的，如果直接使用這些數據去進行數據分析，那最後分析出來的結論多半也不正確。
因此需要有個數據產品來對數據進行整合加工，而數據倉庫就是這樣一款產品。
要想了解怎麼搭建數據倉庫，首先需要明白數據倉庫的作用：
- 存儲數據
- 校準數據
- 整合數據
- 輸出數據
基於以上幾點，需要將數據分層次管理，每一層分工合作，對數據進行不同程度的處理，如同工廠裏的流水線一般，從而確保數據的生命性、生態性。
大數據體系整體架構
數據倉庫並不是獨立存在的一個個體，而是與整個大數據體系融爲一體的——換句話說，數據倉庫就像人的心臟，人只有心臟而沒有其他器官是無法單獨存活下來的。
大數據體系架構如圖所示：
開源系統
數據的來源系統，可以理解爲數據的收集系統。
如圖所示爲基於電商業務下的大數據體系，因此數據大體可分爲業務數據和用戶行爲數據，其來源系統更多是與電商業務相關的後端訂單、庫存等業務系統以及前端商城帶來的用戶行爲數據。
原始數據層
顧名思義，即存放從來源系統過來的原始數據，所謂原始數據——即未經過任何加工處理的數據。
這一層次乍看之下有點多餘，但實際上是有所考量的：
1）將數據倉庫與業務系統分隔開
數據倉庫的數據，實時性要求不高，而準確性、清潔性必須較高，因此清洗的腳本繁多。如果每條數據都實時傳送到數據倉庫的話，那腳本執行的頻率將非常高，所佔用的系統資源也隨之增加。
2）分擔業務系統的報表任務
衆所周知，搭建大數據體系架構所使用的硬件資源是相對較高的，而業務系統往往只是支撐業務持續開展，從性能上往往無法支撐大數據量報表的導出。因此，原始數據層可以承載此項功能，業務系統數據傳輸的實時性也保證了從原始數據層導出的數據符合業務人員對報表實時性的需要。
帆軟
這纔是真正的實時報表
數據倉庫
一般來說，數據倉庫可區分爲三層：基礎數據層、主題層、模型層
基礎數據層
原始數據層以天爲時間週期，將每天的數據傳輸到數據倉庫，數據倉庫通過ETL（抽取、轉化、加載）的方式，將數據按照設定的數據表格式存儲好，形成基礎數據層的數據。
主題層
數據清洗就像打掃衛生一樣，將不要的東西扔掉，將破舊的東西擦拭乾淨，但並不代表數據是完整的。
主題層的構建相對複雜，搭建的規則主要是看未來的需要以及產品經理對業務的理解。
舉個例子：
題主所在的公司是一家大型零售分銷公司，因此往往有一張訂單賣給零售商，零售商再下一張訂單給零售店，零售單再下一張訂單給終端用戶。此時，每一級訂單是斷層，且來源於不同的系統的，因此每一級訂單的表結構完全不同。
這樣導致的結果是：無法從全鏈條上看到每一個商品在渠道中的流轉，也無法實時跟蹤到每個商品的具體轉化效率。所以，需要把每一級的訂單按照主體分門別類（一級訂單、二級訂單、三級訂單），並且建立一種關聯關係，使這三者能串聯起來，形成一整個渠道流程。
模型層
數據來到模型層，也就意味着他們最終要成爲“炮彈”，發射到數據分析平臺了，因此模型層的最主要作用是：將主題數據組合成數據分析模型。
假設我們需要在數據分析平臺上體現出“不同商品在不同區域不同客戶的熱銷情況”，那在模型層就需要以訂單表作爲最基礎的表，關聯上區域表、客戶表、商品表，關聯出一個以區域+商品+客戶特徵維度劃分的明細數據。
每個區域每個商品每個客戶對應一行銷售數據，根據這份數據彙總出一個按區域+商品+客戶特徵的模型，輸出到數據分析平臺，展示出不同區域，不同商品的客戶特徵是怎樣的。
需要注意的是：模型層的數據都是呈現出星狀結構和高度索引化的。
因爲在大數據平臺上，數據與數據之間往往是需要存在關聯的，運營人員看到商品在不同區域上的銷量分佈，往往也想進一步看到在不同區域上的商品有什麼特徵，客戶有什麼特徵，這些都需要和區域相關聯起來的。
數據應用層
數據應用層嚴格意義上不屬於大數據架構，因爲它除了會涉及各式各樣的數據分析平臺，還會涉及到業務系統。
數據反哺
上文提到過，業務系統對於數據倉庫而言更多是作爲數據收集工具，但同時業務系統也存在着數據的需求，我把這樣的過程稱爲數據反哺。
往往支撐公司業務開展下去的業務系統不止一個，很可能是有多個，而各式各樣的業務系統之間也需要數據交互。例如：一般電商公司會有一套前端商家平臺，也會一套後端的管理平臺，這兩套平臺使用的往往不是同一套SKU，因此需要將後端SKU同步到前端來進行mapping。
那麼爲什麼不能直接讓這兩套系統直接進行數據交互呢？
因爲數據已經不再幹淨，需要數據倉庫進行清洗過後，將冗餘的數據去除後方可推送至前端商家平臺。
分析模型輸出
數據倉庫的數據，最終除了會流向業務系統以外，更多的會流向各大數據應用系統，即：數據大屏，大數據分析平臺等
此時的數據，已經過層層清洗加工、模型搭建，形成一個個炮彈，通過接口的形式推送至各大數據平臺。對於這些數據分析、數據展示平臺而言，更多的只需要考慮如何直觀展示數據即可。
總結
數據倉庫不產生數據，也不消費數據，如果把數據比作是水的話，可以將它理解成礦泉水廠商：負責將水抽取上來->排污->打包->運送。說來容易，做來難，其中辛酸與難度只有數據產品經理能理解。