一、數據中臺功能架構
數據中臺建設是一個宏大的工程，涉及整體規劃、組織搭建、中臺落地與運營等方方面面的工作，本節重點從物理形態上講述企業的數據中臺應該如何搭建。一般來講，企業的數據中臺在物理形態上分為三個大層：工具平臺層、數據資產層和數據應用層。
1. 工具平臺層
工具平臺層是數據中臺的載體，包含大數據處理的基礎能力技術，如集數據采集、數據存儲、數據計算、數據安全等于一體的大數據平臺;還包含建設數據中臺的一系列工具，如離線或實時數據研發工具、數據聯通工具、標簽計算工具、算法平臺工具、數據服務工具及自助分析工具。
以上工具集基本覆蓋了數據中臺的數據加工過程。
(1) 數據開發平臺
大數據的4V特征[1]決定了數據處理是一個復雜的工程。建設數據中臺需要搭建建設數據中臺的基建工具，要滿足各種結構化、非結構化數據的采集、存儲與處理，要根據場景處理離線和實時數據的計算與存儲，要將一個個數據處理任務串聯起來以保障數據的運轉能賦能到業務端。
[1] 大數據的4V 指Volume(數據量大)、Variety(類型繁多)、Velocity(速度快，效率高)、Value(價值密度低)。
因此首先搭建一個大數據能力平臺是非常有必要的。當然，可根據企業實際情況來決定是外采還是自建平臺。
(2) 數據資產管理
數據中臺建設的成功與否，與數據資產是否管理有序有直接關系。前文提到，數據中臺是需要持續運營的。隨著時間的推移，數據不斷涌入數據中臺，如果沒有一套井然有序的數據資產平臺來進行管理，后果將不堪設想。
數據資產管理工具既能幫助企業合理評估、規范和治理信息資產，又可以發揮數據資產價值并促進數據資產持續增值。對于數據資產管理，我們不推薦事后管理，而要與數據研發的過程聯動。也就是說，當數據經過數據開發平臺加工的鏈路時，數據資產管理平臺就已經無聲無息地介入了。
數據資產管理的首要任務是管理好進入數據中臺的元數據，這里的元數據包括數據源、建設的各種模型、通過模型拆解出來的指標與標簽以及調度作業。有序管理這些數據資產的元數據是前提條件，只有做好了這一步，才能繼續對數據流向的追溯，才能對指標、標簽體系的生命周期進行管理，確定指標的使用頻率，決定是否下線。
(3) 標簽工廠
標簽工廠又稱標簽平臺，是數據中臺體系內的明星工具類產品。標簽建設是數據中臺走向數據業務化的關鍵步驟。因此，一個強大的標簽工廠是數據中臺價值體現的有力保障。
嚴格來說，標簽工廠也屬于數據開發平臺的一部分，為什么我們要把它單獨剝離出來講呢?這是因為標簽的使用場景豐富，標簽與業務結合得非常緊密;同時，標簽數據的存儲與分析型數據的存儲有一定的差異。
標簽工廠致力于屏蔽底層復雜的大數據框架，面向普通開發人員、數據分析師、運營人員提供友好的界面交互配置，完成標簽的全生命周期管理;同時，對上層業務系統提供自身API能力，與各業務系統形成數據閉環。
標簽工廠按功能一般分為兩部分：底層的標簽計算引擎與上層的標簽配置與管理門戶。標簽計算引擎一般會采用MapReduce、Spark、Flink等大數據計算框架，而計算后的標簽存儲可采用Elasticsearch或者HBase，這樣存儲的好處是便于快速檢索。
而標簽配置與管理門戶則支持通過配置標簽規則提交到標簽計算引擎，就能定時算出所需要的標簽。標簽配置和管理門戶還提供標準的標簽服務申請與調用。通過標簽工廠，數據中臺團隊可減少大量的數據開發工作。
(4) ID-Mapping
ID-Mapping又稱ID打通工具，是數據中臺建設的可選項。可選不代表不重要，在一些多渠道、多觸點的新零售企業，離開了這個工具，數據質量將大打折扣。
舉個例子。消費者在逛街的時候看到一款剃須刀，掃了店內的二維碼，正準備下單購買時被朋友的電話中斷了。回到家，打開抖音又看到這個剃須刀的廣告，便立即打開鏈接下單購買了。
這樣的場景在生活中比比皆是，其中隱藏了很多的消費者信息，如果我們不去打通ID，那么可能至少會將同一個用戶當作4個用戶來處理。實際上可以將掃描二維碼記錄留下的OpenID、抖音注冊留下的微信號、下單提供的訂單手機號碼及注冊賬號等多條信息結合起來，判別是不是同一個人。這樣給這個消費者打標簽或者推薦商品就會更加精準。
ID-Mapping功能的建設一般會利用強大的圖計算功能，通過兩兩之間的關系實現互通，自動高效地將關聯的身份映射為同一身份即唯一ID的數據工具。它能大幅度降低處理成本，提高效率，挖掘更多用戶信息，形成更完整的畫像，大大利于數字營銷的推進。
另外，ID-Mapping工具也可用于企業主數據治理。
(5) 機器學習平臺
在整個機器學習的工作流中，模型訓練的代碼開發只是其中一部分。除此之外，數據準備、數據清洗、數據標注、特征提取、超參數的選擇與優化、訓練任務的監控、模型的發布與集成、日志的回收等，都是流程中不可或缺的部分。
機器學習平臺支持訓練數據的高質量采集與高效標注，內置預訓練模型，封裝機器學習算法，通過可視化拖曳實現模型訓練，支持從數據處理、模型訓練、模型部署為在線預測服務，通過RESTful API的形式與業務應用集成，實現預測，打通機器學習全鏈路，幫助企業更好地完成傳統機器學習和深度學習的落地。
(6) 統一數據服務
統一數據服務旨在為企業搭建統一的數據服務門戶，幫助企業提升數據資產的價值，同時保證數據的可靠性、安全性和有效性。
統一數據服務支持通過界面配置的方式構建API和數據服務接口，以滿足不同數據的使用場景，同時降低數據的開發門檻，幫助企業實現數據應用價值最大化。
統一數據服務作為唯一的數據服務出口，實現了數據的統一市場化管理，在有效降低數據開放門檻的同時，保障了數據開放的安全。
2. 數據資產層
數據資產層是數據中臺的核心層，它依托于工具平臺層，那么這一層又有什么內容呢?答案是因企業的業務與行業而異，但總體來講，可以劃分為主題域模型區、標簽模型區和算法模型區。
(1) 主題域模型
主題域模型是指面向業務分析，將業務過程或維度進行抽象的集合。業務過程可以概括為一個個不可拆分的行為事件，如訂單、合同、營銷等。
為了保障整個體系的生命力，主題域即數據域需要抽象提煉，并且長期維護和更新，但是不輕易變動。在劃分數據域時，既要涵蓋當前所有業務的需求，又要保證新業務能夠無影響地被包含進已有的數據域中或者很容易擴展新的數據域。
數據域劃分需要先對業務系統進行充分調研。將業務過程劃分到哪個數據域沒有絕對的對錯，但是會影響報表開發人員定位數據的效率，所以還需要從開發人員定位效率的角度來進行綜合劃分。
(2) 標簽模型
標簽模型的設計與主題域模型方法大同小異，同樣需要結合業務過程進行設計，需要充分理解業務過程。標簽一般會涉及企業經營過程中的實體對象，如會員、商品、門店、經銷商等。這些主體一般來說都穿插在各個業務流程中，比如會員一般都穿插在關注、注冊、瀏覽、下單、評價、服務等環節。
那么在設計標簽的時候就需要充分理解這些業務流程，在流程中發現標簽的應用點，結合這些應用點來搭建企業的標簽體系。
標簽模型按計算模式一般分為客觀標簽和主觀標簽，客觀標簽是可以量化的，而主觀標簽是不可量化的。根據實現方式又可以將標簽分為事實標簽、模型標簽、算法標簽等，根據業務場景還可將標簽分為基礎信息標簽、偏好標簽、價值標簽等。
設計標簽模型時非常關鍵的要素是標簽模型一定要具有可擴展性。畢竟標簽這種數據資產是需要持續運營的，也是有生命周期的，在運營的過程中隨時可能增加新的標簽。
(3) 算法模型
算法模型更加貼近業務場景。在設計算法模型的時候要反復推演算法模型使用的場景，包括模型的冷啟動等問題。整個模型搭建過程包含定場景、數據源準備、特征工程、模型設計、模型訓練、正式上線、參數調整7個環節。
以新零售企業為例，常用的機器學習算法有決策樹、神經網絡、關聯規則、聚類、貝葉斯、支持向量機等。這些算法已經非常成熟，可以用來實現商品個性化推薦、銷量預測、流失預測、商品組貨優化等新零售場景的算法模型。
3. 數據應用層
數據應用層嚴格來說不屬于數據中臺的范疇，但數據中臺的使命就是為業務賦能，幾乎所有企業在建設數據中臺的同時都已規劃好數據應用。數據應用可按數據使用場景來劃分為以下多個使用領域。
(1) 分析與決策應用
分析與決策應用主要面向企業的領導、運營人員等角色，基于企業的業務背景和數據分析訴求，針對客戶拉新、老客運營、銷售能力評估等分析場景，通過主題域模型、標簽模型和算法模型，為企業提供可視化分析專題。
用戶在分析與決策應用中快速獲取企業現狀和問題，同時可對數據進行鉆取、聯動分析等，深度分析企業問題及其原因，從而輔助企業進行管理和決策，實現精準管理和智能決策。
在分析專題設計的過程中，首先需要根據不同的業務分析場景，采用不同的分析方法進行數據分析的前期規劃，搭建清晰的數據分析框架，如在用戶行為分析、營銷活動等場景下，會采用5W2H分析法和4P營銷理論;在復購客戶下降、客單價下降等問題診斷分析場景，需要考慮問題與哪些因素有關，則采用邏輯樹分析法。
在數據分析框架構建完成后，結合用戶的分析目的，采用不同的分析思路和呈現方式，包括趨勢分析、多維分解、漏斗分析、A/B測試、對比分析和交叉分析等。
(2) 標簽應用
標簽旨在挖掘實體對象(如客戶、商品等)的特征，將數據轉化成真正對業務有價值的產物并對外提供標簽數據服務，多應用于客戶圈選、精準營銷和個性化推薦等場景，從而實現資產變現，不斷擴大資產價值。
標簽體系的設計立足于標簽使用場景，不同使用場景對標簽需求是不同的，譬如在客戶個性化推薦場景下，需要客戶性別、近期關注商品類型、消費能力和消費習慣等標簽。
因此，在標簽體系設計前，需要先基于業務需求分析標簽的使用場景，再詳細設計標簽體系和規則。在標簽的使用過程中，可利用A/B測試等數據分析方式，持續分析標簽的使用效果，并優化標簽體系和規則。
(3) 智能應用
智能應用是數智化的一個典型外在表現。比如在營銷領域，不僅可實現千人千面的用戶個性化推薦，如猜你喜歡、加購推薦等，還可借助智能營銷工具進行高精準度的用戶觸達，推動首購轉化、二購促進、流失挽留等。
在供應鏈領域，可通過數據中臺整合用戶數據、銷售數據、采購數據等優化庫存，實現自動配補貨、自動定價。除了傳統統計分析、機器學習之外，還可以融入深度學習，實現以圖搜圖并與商城打通，實現拍立購;實現人臉識別，用于地產行業的案場風控;融入自然語言處理，實現智能客服問答機器人等。
總之，以上各層是數據中臺的核心內容。需要指出的是，在工具平臺層，企業并不需要完全自主建設，可以考慮采用拿來主義，從中臺建設廠商采購成熟的產品，而數據資產層與數據應用層是企業數據中臺組織需要密切關注的。
二、數據中臺技術架構
隨著大數據與人工智能技術的不斷迭代以及商業大數據工具產品的推出，數據中臺的架構設計大可不必從零開始，可以采購一站式的研發平臺產品，或者基于一些開源產品進行組裝。企業可根據自身情況進行權衡考慮，但無論采用哪種方案，數據中臺的架構設計以滿足當前數據處理的全場景為基準。
以開源技術為例，數據中臺的技術架構如圖4-3所示，總體來看一般包含以下幾種功能：數據采集、數據計算、數據存儲和數據服務;在研發、運維和公共服務方面包括離線開發、實時開發、數據資產、任務調度、數據安全、集群管理。
1. 數據采集層
按數據的實時性，數據采集分為離線采集和實時采集。離線采集使用DataX和Sqoop，實時采集使用Kafka Connect、Flume、Kafka。
在離線數據采集中，建議使用DataX和Sqoop相結合。DataX適合用在數據量較小且采用非關系型數據庫的場景，部署方式很簡單。Sqoop適合用在數據量較大且采用關系型數據庫的場景。
在實時數據采集中，對于數據庫的變更數據，如MySQL的binlog、Oracle的OGG，使用Kafka Connect進行數據的實時采集。對于其他數據，先將數據實時寫成文件，然后采用Flume對文件內容進行實時采集。將實時采集后的數據推送到Kafka，由Flink進行數據處理。
2. 數據計算層
數據計算采用YARN作為各種計算框架部署的執行調度平臺，計算框架有MapReduce、Spark及Spark SQL、Flink、Spark MLlib等。
MapReduce是最早開源的大數據計算框架，雖然現在性能相對較差，但它的資源占用比較小，尤其是內存方面。因此在部分數據量過大，而其他計算框架由于硬件資源的限制(主要是內存限制)而無法執行的場景，可以將MapReduce作為備選框架。
Spark及Spark SQL是在批處理方面擁有出色性能的成熟技術方案，適合大部分的離線處理場景。特別是在離線數據建模方面，建議使用Spark SQL進行數據處理，既能保證易用性，又能保證處理的性能。Flink是實時數據處理方面的首選，在處理的時效性、性能和易用性方面都有很大優勢。
而機器學習一般采用Spark家族的Spark MLlib為技術底座。Spark MLlib內置了大量的常規算法包，如隨機森林、邏輯回歸、決策樹等，可以滿足大部分數據智能應用場景。
同時，數據中臺不斷進化，也逐漸融入AI能力。如人臉識別、以圖搜圖、智能客服等能力的實現就需要AI平臺。目前較為成熟的AI平臺有TensorFlow及PyTorch。為實現物體的檢測和識別，可使用SSD、YOLO和ResNet等深度學習模型，而在人臉檢測和識別中則主要使用MTCNN、RetinaNet和ResNet，人臉檢索可使用Facebook開源的針對人臉檢索的Faiss框架。
3. 數據存儲層
數據存儲層所有的存儲引擎都基于Hadoop的HDFS分布式存儲，從而達到數據多份冗余和充分利用物理層多磁盤的I/O性能。在HDFS上分別搭建Hive、HBase作為存儲數據庫，在這兩個數據庫的基礎上再搭建Impala、Phoenix、Presto引擎。
Hive為大數據廣泛使用的離線數據存儲平臺，用于存儲數據中臺的全量數據，在建模階段可以使用Hive SQL、Spark SQL進行數據處理和建模。 HBase為主流的大數據NoSQL，適合數據的快速實時讀寫。在實時數據處理時，可將數據實時保存到HBase中，并且可以從HBase中實時讀取數據，從而滿足數據的時效性。 Impala可以對Hive、HBase等大數據數據庫進行準實時的數據分析，能滿足對分析結果速度有一定要求的場景。 Phoenix是構建在HBase上的一個SQL層，能讓我們用標準的JDBC API而不是HBase客戶端API來創建表、插入數據和對HBase數據進行查詢。 Presto是一個開源的分布式SQL查詢引擎，適用于交互式分析查詢。Presto支持Hive、HBase、MySQL等多種關系型和大數據數據庫的查詢，并且支持join表。對于對接自助分析和統一數據服務的場景，可以通過Presto來統一訪問具體存儲的數據庫，從而達到語法統一和數據源統一。
4. 數據服務層
數據服務層采用的技術與業務應用類似，主要基于開源Spring Cloud、Spring Boot等構建，使用統一的服務網關。
京公網安備 11010502049343號