本人目前在一家線上教育公司擔任大資料營銷產品負責人，由於一些機緣巧合，我同時負責了資料產品線和營銷CRM產品線，因此給了我更多的機會去思考和實踐如何把資料與營銷業務深入融合，將大資料的勢能賦予營銷平臺，從而實現業務的精細化運營和資料驅動。

接下來，針對線上教育業務場景下的大資料營銷平臺實戰，我會系統化闡述。文章可能會涉及：大資料平臺搭建、使用者畫像服務體系、CRM線索動態評分模型及分配演算法、資料產品實施推廣方案、客戶資料中臺（CDP）等多個方向。

一、企業資料問題診斷

產品是為了滿足需求，是否需要構建大資料平臺？以及構建什麼樣的大資料平臺？取決於企業的資料化程度和麵臨的資料問題。因此在構建大資料平臺之前，需要進行充分地調研，找準問題才能對症下藥。對企業資料化程度的評估方法，可以參考下圖所示的資料管理能力成熟度模型(DMM)。

透過前期的調研和分析，我們公司當時處於L2等級，面臨的主要資料問題如下：

1）資料來源分散

不利於多資料來源之間關聯分析不利於資料資產價值的進一步挖掘資料孤島嚴重無統一資料平臺、資料資源得不到彙總沉澱，資料無法高效支撐業務

2）資料指標不統一

不同業務部門分而治之準確性、權威性受到質疑不利於公司各業務部門KPI考核指標統計口徑需要標準化

3）資料分析效率低

各業務部門佔用部分精力資料分析工作對於資料的需求往往需要從原始資料開始對資料分析師的支撐不夠無成型完整的資料分析工具

4）資料管理問題

無統一資料字典缺少資料地圖無元資料管理二、大資料平臺業務架構及Road Map

上一部分已經對企業內部資料問題進行了全面診斷和問題剖析，接下來我們針對這些問題給出解決的架構方案和路線圖。

1. 資料服務體系藍圖

從業務視角給出瞭如下的資料服務體系藍圖，資料服務體系的規劃需要滿足三點：資料服務體系需要覆蓋完整的公司業務、貫穿業務的各個階段、伴隨企業發展。

在此資料服務體系中，處於核心環節的是資料整體建模和資料資產管理，也就是我們熟悉的統一化數倉建設。結合線上教育業務特點，數倉建設需要滿足三個核心資料體系建設：

使用者資料體系：使用者分析應用、使用者標籤、使用者行為資料，使用者基本資訊主資料等；營銷資料體系：營銷分析應用、營銷分層標籤、渠道特徵資料、營收轉化相關的主資料等；學習資料體系：學習分析應用、學習偏好標籤、學習行為資料、學習素材基礎資料等。2. 資料倉庫架構

資料倉庫的層次劃分採用業界通用的層級劃分方式，包括：ODS、DWD、DWS、ADS層，如下圖所示：

1）ODS層

資料同步：結構化資料增量或全量同步到資料倉庫；結構化：非結構化(日誌)結構化處理並存儲到資料倉庫；累積歷史、清洗：根據資料業務需求及稽核和審計要求儲存歷史資料、資料清洗；

2）CDM層

組合相關和相似資料：採用明細寬表，複用關聯計算，減少資料掃描。公共指標統一加工：基於OneData體系構建命名規範、口徑一致和演算法統一的統計指標；建立邏輯彙總寬表。建立一致性維度：建立一致的資料分析維表，降低資料計算口徑不統一的風險。

3）ADS層

個性化指標加工：不公用性、複雜性（指數型、比值型、排名型等）基於應用的資料組裝：大寬表集市、橫錶轉縱表、趨勢指標串。3. 資料處理流程架構

資料處理流程主要包括源資料同步清洗、資料處理加工、模型運算和資料應用。基於線上線上教育公司的業務特點，源資料主要包括：渠道資料、使用者資料、交易資料、營銷過程資料、學習資料、外部第三方資料等。

模型引擎包括離線計算引擎和實時計算引擎兩類，需要滿足演算法（或規則）部署、模型訓練和上線、以及對其他業務系統提供介面服務的能力，比如為CRM系統提供多演算法的線索實時分配、使用者畫像分層等服務。在資料的匯聚、加工生產、應用的全流程中，全生命週期的資料治理不能忽視，因為資料的準確定、完整性、一致性直接影響業務對資料系統的可信度。

4. 從0~1構建大資料平臺的Road Map

筆者結合自身在推進大資料平臺建設過程中的經驗，給出以下路線圖供大家參考。

三、資料建模及設計規範1. 資料模型選型及舉例

維度建模常見的模型有星型模型、雪花模型和星座模型三種，資料倉庫設計一般採用星型模型。

星型模型是一種多維的資料關係，它由一個事實表（Fact Table）和一組維表（Dimension Table）組成。每個維表都有一個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。事實表的非主鍵屬性稱為事實（Fact），它們一般都是數值或其他可以進行計算的資料。

事實表：表示對分析主題所屬型別的描述。比如“昨天早上張三在環球網校花費1000元購買了一個一建零基礎暢學班課程”。那麼以購買為主題進行分析，可從這段資訊中提取三個維度：時間維度(昨天早上)，地點維度(環球網校), 商品維度(一建零基礎暢學班課程)。通常來說維度表資訊比較固定，且資料量小。

維度表：表示對分析主題的度量。比如上面那個例子中，1000元就是事實資訊。事實表包含了與各維度表相關聯的外碼，並透過JOIN方式與維度表關聯。事實表的度量通常是數值型別，且記會不斷增加，表規模迅速增長錄數。

2. 數倉表設計規範

1）表命名規範

數倉各層表命名規範如下圖所示。

2）欄位級規範

新增指標的命名參考已有欄位命名方式，避免出現同一個欄位，10個人有10個命名方法。

欄位分類包括：明細，維度，指標，時間，程式碼，標誌位，命名規範如下：

id結尾表示編號，部分維度編號對應含義需關聯數倉相應維度表獲取含義；name結尾表示名稱，多與id對應，解釋其含義，獨立的以name結尾的欄位；code結尾表示程式碼欄位，對應含義部分可在文件直接檢視，部分需關聯數倉程式碼表獲取；time結尾表示時間欄位，格式為yyyy-mm-dd hh:mi:ss，從源系統獲取，不作處理；money結尾表示金額，都為系統相應交易金額；is_開頭表示標誌欄位，此欄位只有0,1，含義：1是，0否；除以上規範字段，其他欄位根據中文含義對應生成英文欄位，多為一些屬性欄位，意義不大。四、大資料平臺技術架構及模組簡介

在大資料平臺的建設過程中，筆者和公司大資料架構師共同研究探討後給出的技術架構如下圖所示。

1）安全模組

作為資料平臺來講，保障資料安全始終是第一要素。 安全體系的建立主要包含以下幾個方面：

資料安全規範、安全等級制定使用者系統基礎元件層許可權管理服務層許可權管理使用者認證秘鑰管理流程審批資料加密脫敏審計

2）監控模組

資料安全之外，服務的穩定性算是平臺的第二級指標。好的監控體系可以幫助預測風險定位問題。例如：

提前預判磁碟容量定位記憶體、CPU資源問題發現異常任務節點宕機等問題檢視該各服務負載，評估資源

3）儲存模組

儲存模組屬於基礎元件模組，主要採用hadoop生態系統的相關元件。面向不同的應用場景選擇一種元件，例如：

hive： 離線數倉HBase：KV儲存，可用於高度聚合後的固定指標，應對有較高併發請求的場景Druid：面向OLAP場景，能夠提供亞秒級、較高請求量且需要鑽取能力的OLAP功能Impala： 在數倉資料基礎上提供更高效的查詢分析能力，適合即席查詢場景，但是並不能處理更高的請求量。

4）計算模組

Yarn做統一資源管理，Spark或者Flink都可以作為統一流、批處理框架。或者階段性允許兩者並存。

5）管理模組

資料治理： 數倉管理資料的主要平臺，包括：

元資料管理資料質量管理血緣關係管理資料安全、許可權管理

任務管理：

離線任務管理、排程：

包含管道任務、SQL任務、Shell任務等形態，數倉場景中SQL任務佔整體任務的絕大多數需要基於SQL自動生成任務之間的依賴關係，並且按照任務之間的依賴關係和優先順序排程任務

流式任務管理：

流式任務釋出、監控、重啟等操作

五、寫在最後

致此，線上教育大資料營銷平臺實踐第一篇文章已經結束，下篇文章筆者會闡述在大資料平臺建設的初期，如何將資料倉庫和神策分析系統（sa）相結合來快速滿足運營人員對資料分析的需求，開啟資料化運營戰略落地的序幕。