數(shù)據(jù)倉庫是所有產(chǎn)品的數(shù)據(jù)中心，公司體系下的所有產(chǎn)品產(chǎn)生的所有數(shù)據(jù)最終都流向數(shù)據(jù)倉庫，可以說數(shù)據(jù)倉庫不產(chǎn)生數(shù)據(jù)，也不消費數(shù)據(jù)，只是數(shù)據(jù)的搬運工。

記得很久以前曾有一位前輩和我說過：“進來的數(shù)據(jù)是垃圾數(shù)據(jù)，出去也是垃圾數(shù)據(jù)”。

在實際環(huán)境中，往往我們一條業(yè)務線會由多個不同的系統(tǒng)支撐組成（例如：很多電商后端業(yè)務線都區(qū)分為庫存系統(tǒng)、售后系統(tǒng)、采購系統(tǒng)、CRM系統(tǒng)等）。這些系統(tǒng)由于本身設計的缺陷或業(yè)務流程變更等問題，所產(chǎn)生的數(shù)據(jù)往往都是有缺失、冗余的，如果直接使用這些數(shù)據(jù)去進行數(shù)據(jù)分析，那最后分析出來的結論多半也不正確。

因此需要有個數(shù)據(jù)產(chǎn)品來對數(shù)據(jù)進行整合加工，而數(shù)據(jù)倉庫就是這樣一款產(chǎn)品。

要想了解怎么搭建數(shù)據(jù)倉庫，首先需要明白數(shù)據(jù)倉庫的作用：

存儲數(shù)據(jù)

校準數(shù)據(jù)

整合數(shù)據(jù)

輸出數(shù)據(jù)

基于以上幾點，需要將數(shù)據(jù)分層次管理，每一層分工合作，對數(shù)據(jù)進行不同程度的處理，如同工廠里的流水線一般，從而確保數(shù)據(jù)的生命性、生態(tài)性。

大數(shù)據(jù)體系整體架構

數(shù)據(jù)倉庫并不是獨立存在的一個個體，而是與整個大數(shù)據(jù)體系融為一體的——換句話說，數(shù)據(jù)倉庫就像人的心臟，人只有心臟而沒有其他器官是無法單獨存活下來的。

大數(shù)據(jù)體系架構如圖所示：

來源系統(tǒng)

數(shù)據(jù)的來源系統(tǒng)，可以理解為數(shù)據(jù)的收集系統(tǒng)。

如圖所示為基于電商業(yè)務下的大數(shù)據(jù)體系，因此數(shù)據(jù)大體可分為業(yè)務數(shù)據(jù)和用戶行為數(shù)據(jù)，其來源系統(tǒng)更多是與電商業(yè)務相關的后端訂單、庫存等業(yè)務系統(tǒng)以及前端商城帶來的用戶行為數(shù)據(jù)。

原始數(shù)據(jù)層

顧名思義，即存放從來源系統(tǒng)過來的原始數(shù)據(jù)，所謂原始數(shù)據(jù)——即未經(jīng)過任何加工處理的數(shù)據(jù)。

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

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

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

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

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

數(shù)據(jù)倉庫

一般來說，數(shù)據(jù)倉庫可區(qū)分為三層：基礎數(shù)據(jù)層、主題層、模型層

基礎數(shù)據(jù)層

原始數(shù)據(jù)層以天為時間周期，將每天的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)倉庫，數(shù)據(jù)倉庫通過ETL（抽取、轉化、加載）的方式，將數(shù)據(jù)按照設定的數(shù)據(jù)表格式存儲好，形成基礎數(shù)據(jù)層的數(shù)據(jù)。

何謂ETL呢？

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

舉個栗子：

從訂單系統(tǒng)過來的訂單數(shù)據(jù)上，客戶名稱多種多樣，相同一個客戶，有大寫的名稱、小寫的名稱、有些訂單甚至沒有客戶的相關信息（這當然是業(yè)務系統(tǒng)本身的歷史遺留問題導致的）。此時，作為數(shù)據(jù)產(chǎn)品經(jīng)理必須要了解這些數(shù)據(jù)的“坑”，并且和對應業(yè)務系統(tǒng)的產(chǎn)品經(jīng)理共同商討如何處理這批數(shù)據(jù)，確定好清洗邏輯（例如：所有名稱統(tǒng)一轉化為小寫，如果客戶名稱、地址、電話號碼都是同一個的，歸為同一個客戶），程序猿們根據(jù)數(shù)據(jù)產(chǎn)品經(jīng)理的清洗規(guī)則寫好腳本進行清洗。

主題層

數(shù)據(jù)清洗就像打掃衛(wèi)生一樣，將不要的東西扔掉，將破舊的東西擦拭干凈，但并不代表數(shù)據(jù)是完整的。

主題層的構建相對復雜，搭建的規(guī)則主要是看未來的需要以及產(chǎn)品經(jīng)理對業(yè)務的理解。

舉個栗子：

題主所在的公司是一家大型零售分銷公司，因此往往有一張訂單賣給零售商，零售商再下一張訂單給零售店，零售單再下一張訂單給終端用戶。此時，每一級訂單是斷層，且來源于不同的系統(tǒng)的，因此每一級訂單的表結構完全不同。

這樣導致的結果是：無法從全鏈條上看到每一個商品在渠道中的流轉，也無法實時跟蹤到每個商品的具體轉化效率。所以，需要把每一級的訂單按照主題分門別類（一級訂單、二級訂單、三級訂單），并且建立一種關聯(lián)關系，使這三者能串聯(lián)起來，形成一整個渠道流程。

模型層

數(shù)據(jù)來到模型層，也就意味著他們最終要成為“炮彈”，發(fā)射到數(shù)據(jù)分析平臺了，因此模型層的最主要作用是：將主題數(shù)據(jù)組合成數(shù)據(jù)分析模型。

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

需要注意的是：模型層的數(shù)據(jù)都是呈現(xiàn)出星狀結構和高度索引化的。

因為在大數(shù)據(jù)平臺上，數(shù)據(jù)與數(shù)據(jù)之間往往是需要存在關聯(lián)的，運營人員看到商品在不同區(qū)域上的銷量分布，往往也想進一步看到在不同區(qū)域上的商品有什么特征，客戶有什么特征，這些都需要和區(qū)域強關聯(lián)起來的。

數(shù)據(jù)應用層

數(shù)據(jù)應用層嚴格意義上不屬于大數(shù)據(jù)架構，因為它除了會涉及各式各樣的數(shù)據(jù)分析平臺，還會涉及到業(yè)務系統(tǒng)。

數(shù)據(jù)反哺

上文提到過，業(yè)務系統(tǒng)對于數(shù)據(jù)倉庫而言更多是作為數(shù)據(jù)收集工具，但同時業(yè)務系統(tǒng)也存在著數(shù)據(jù)的需求，我把這樣的過程稱為數(shù)據(jù)反哺。

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

那么為什么不能直接讓這兩套系統(tǒng)直接進行數(shù)據(jù)交互呢？

因為數(shù)據(jù)已經(jīng)不再干凈，需要數(shù)據(jù)倉庫進行清洗過后，將冗余的數(shù)據(jù)去除后方可推送至前端商家平臺。

分析模型輸出

數(shù)據(jù)倉庫的數(shù)據(jù)，最終除了會流向業(yè)務系統(tǒng)以外，更多的會流向各大數(shù)據(jù)應用系統(tǒng)，即：數(shù)據(jù)大屏，大數(shù)據(jù)分析平臺等

此時的數(shù)據(jù)，已經(jīng)過層層清洗加工、模型搭建，形成一個個炮彈，通過接口的形式推送至各大數(shù)據(jù)平臺。對于這些數(shù)據(jù)分析、數(shù)據(jù)展示平臺而言，更多的只需要考慮如何直觀展示數(shù)據(jù)即可。

總結

數(shù)據(jù)倉庫不產(chǎn)生數(shù)據(jù)，也不消費數(shù)據(jù)，如果把數(shù)據(jù)比作是水的話，可以將它理解成礦泉水廠商：負責將水抽取上來->排污->打包->運送。說來容易，做來難，其中辛酸與難度只有數(shù)據(jù)產(chǎn)品經(jīng)理能理解。