數據倉庫并不是獨立存在的一個個體，而是與整個大數據體系融為一體的——換句話說，數據倉庫就像人的心臟，人只有心臟而沒有其他器官是無法單獨存活下來的。數據的來源系統(tǒng)，可以理解為數據的收集系統(tǒng)。顧名思義，即存放從來源系統(tǒng)過來的原始數據，所謂原始數據——即未經過任何加工處理的數據。

這一層次咋看之下有點多余，但實際上是有所考量的：

1）將數據倉庫與業(yè)務系統(tǒng)分隔開

數據倉庫的數據，實時性要求不高，而準確性、清潔型必須較高，因此清洗的腳本繁多。如果每條數據都實時傳送到數據倉庫的話，那腳本執(zhí)行的頻率將非常高，所占用的系統(tǒng)資源也隨之增加。

2）分擔業(yè)務系統(tǒng)的報表任務

總所周知，搭建大數據體系架構所使用的硬件資源是相對較高的，而業(yè)務系統(tǒng)往往只是支撐業(yè)務持續(xù)開展，從性能上往往無法支撐大數據量報表的導出。因此，原始數據層可以承載此項功能，業(yè)務系統(tǒng)數據傳輸的實時性也保證了從原始數據層導出的數據符合業(yè)務人員對報表實時性的需要。

一般來說，數據倉庫可區(qū)分為三層：基礎數據層、主題層、模型層原始數據層以天為時間周期，將每天的數據傳輸到數據倉庫，數據倉庫通過ETL（抽取、轉化、加載）的方式，將數據按照設定的數據表格式存儲好，形成基礎數據層的數據。

ETL即：Extra、Transfer、Load——簡單來說，即數據清洗。先將數據抽取出來，將冗余數據，錯誤數據，有歧義的數據按照既定的規(guī)則進行刪減、填充、修改，再填充入已設定好的表結構的數據庫表中。

數據清洗就像打掃衛(wèi)生一樣，將不要的東西扔掉，將破舊的東西擦拭干凈，但并不代表數據是完整的。主題層的構建相對復雜，搭建的規(guī)則主要是看未來的需要以及產品經理對業(yè)務的理解。數據來到模型層，也就意味著他們最終要成為“炮彈”，發(fā)射到數據分析平臺了，因此模型層的最主要作用是：將主題數據組合成數據分析模型。

假設我們需要在數據分析平臺上體現出“不同商品在不同區(qū)域不同客戶的熱銷情況”，那在模型層就需要以訂單表作為最基礎的表，關聯上區(qū)域表、客戶表、商品表，關聯出一個以區(qū)域+商品+客戶特征維度劃分的明細數據。每個區(qū)域每個商品每個客戶對應一行銷售數據，根據這份數據匯總出一個按區(qū)域+商品+客戶特征的模型，輸出到數據分析平臺，展示出不同區(qū)域，不同商品的客戶特征是怎樣的。

需要注意的是：模型層的數據都是呈現出星狀結構和高度索引化的。因為在大數據平臺上，數據與數據之間往往是需要存在關聯的，運營人員看到商品在不同區(qū)域上的銷量分布，往往也想進一步看到在不同區(qū)域上的商品有什么特征，客戶有什么特征，這些都需要和區(qū)域強關聯起來的。

數據應用層嚴格意義上不屬于大數據架構，因為它除了會涉及各式各樣的數據分析平臺，還會涉及到業(yè)務系統(tǒng)。上文提到過，業(yè)務系統(tǒng)對于數據倉庫而言更多是作為數據收集工具，但同時業(yè)務系統(tǒng)也存在著數據的需求，我把這樣的過程稱為數據反哺。

往往支撐公司業(yè)務開展下去的業(yè)務系統(tǒng)不止一個，很可能是有多個，而各式各樣的業(yè)務系統(tǒng)之間也需要數據交互。例如：一般電商公司會有一套前端商家平臺，也會一套后端的管理平臺，這兩套平臺使用的往往不是同一套SKU，因此需要將后端SKU同步到前端來進行mapping。

那么為什么不能直接讓這兩套系統(tǒng)直接進行數據交互呢？因為數據已經不再干凈，需要數據倉庫進行清洗過后，將冗余的數據去除后方可推送至前端商家平臺。

數據倉庫的數據，最終除了會流向業(yè)務系統(tǒng)以外，更多的會流向各大數據應用系統(tǒng)，即：數據大屏，大數據分析平臺等此時的數據，已經過層層清洗加工、模型搭建，形成一個個炮彈，通過接口的形式推送至各大數據平臺。對于這些數據分析、數據展示平臺而言，更多的只需要考慮如何直觀展示數據即可。