在O2O專案中強調電子化和數字化，因此資料是個很關鍵的基礎工作。而圍繞資料，那麼經常提到的客戶主資料和資料倉庫、大資料是什麼關係呢？今天我們簡單來聊聊，幫助大家理順一下思路。

O2O強調的是客戶體驗，所有的流程和場景都離不開人，都是以人為本。所以，O2O專案中，對人的資料非常關注，尤其是使用者的主資料模型的設計，以及對應主資料模型的資料採集、使用者ID的統一等等，而基於主資料模型進行ID統一和主資料採集的，可以稱之為“統一客戶資料管理”，我們一般簡稱為UCM（Universal Customer Master）。

在對人進行統一後，基本上是形成大會員系統，通過會員ID進行統一和唯一識別，這樣形成了對客戶的主資料（基礎資料）的統一。但是企業一定是需要對整體業務資料的分析，這就意味著要建立

但由於當前企業的資料量越來越大，而且非結構化資料越來越多，對非結構化資料的處理需求也越來越緊迫；同時海量的結構化資料當資料量增長到10TB以上，可能就會遇到效能瓶頸，這時候就需要構建大資料平臺如Hadoop或者類似Spark等平臺進行重構。

實際上，大資料平臺不是萬能的，它的優勢在於海量資料的儲存和運算，但不善於對結構化資料的業務和事務處理。所以，類似Hadoop大資料平臺適合做大資料量的儲存、ETL和運算，但不適合做企業的業務系統和

如果企業既要做業務系統，又需要海量資料和高併發，那麼這種情況不要採取大資料平臺，而是可以採用記憶體資料庫+記憶體計算的技術，可以實現大資料量的業務系統。比如12306的系統平臺，以前經常宕機卡頓，但現在明顯感覺快多了不宕機了吧？就是因為用了記憶體資料庫和記憶體快取計算技術。而記憶體資料庫技術，類似SAP的HANA和Oracle的記憶體資料庫，都是可以考慮的。

同樣，大資料在查詢統計上也不如關係型資料庫。大資料平臺因為結構不同，所以對一條資料的查詢和對數萬條資料的查詢可能都是一個效率，而關係型資料庫當對處理後的小資料量的查詢特別快。因此，統計分析時會選擇一個方式：大資料平臺將資料清洗整理運算之後，載入到一個關係型資料庫，再通過

是不是太專業了？說到底，一個合理的大資料平臺的架構可能是：

針對關係型資料庫，建立企業統一的ETL機制和介面規範，按照統一規則或者基於企業資料匯流排對接全部業務系統，抽取清洗資料來源後到資料來源歷史庫，再分別根據UCM的需要載入或者平抽到UCM的臨時庫、根據DW的需要抽取到資料倉庫的ODS。

針對非結構化資料，通過大資料平臺進行海量資料收集、歸檔和索引。並提供專用的大資料查詢工具滿足常規資料查詢和動態的資料分析。尤其要確保既能滿足實時的資料細節獲取也能滿足批量的與關係型DW的資料同步。

UCM在大資料平臺上清洗整理合並後形成UCM基表庫，根據需要載入到關係型資料介面準備主資料分發服務，服務的物件包括業務系統、企業資料倉庫和資料集市、以及大資料平臺。分發的渠道則仍是統一的ETL平臺。

資料倉庫根據抽取過來的ODS資料進行清洗整理格式化和遷移轉換，在DW進行建模和形成資料集市，比如有關聯分析、有畫像分析、有購物籃分析等等不同主題，最後根據分析的需要將所需資料載入到關係型資料庫，通過BI工具進行統計分析和視覺化展現，或者實現移動端報表展現