數據中臺是 2015 年阿里提出來的雙中臺的概念其中的一個重要組成，阿里作為先驅者，提供了數據中臺架構、以及非常多的建設思路供大家參考，但是一千人眼里有一千個數據中臺，到底什么是數據中臺?數據中臺包含什么?

 

[[324712]]

 

圖片來自 Pexels

 

 

本文分享的議題主要包括如下幾大內容：

• 帶大家回顧一下大數據在國內的發展，從傳統數倉到當前數據中臺的演進過程。
• 我個人認為數據中臺的核心組成，以及一些技術選型參考。
• 數據研發是數據中臺很重要的一環，會分享一些我們在數據研發方面的實踐，主要是數據倉庫架構與研發方面。

大數據演進，從數據倉庫到數據中臺

第一階段

21 世紀的第一個 10 年，企業級數據倉庫(EDW)從萌芽到蓬勃發展，“IOT”(IBM、Oracle、Teradata)占領了大部分市場，提供數據倉庫建設從硬件、軟件到實施的整體方案。

這個時代的數據倉庫實施不僅需要購買大(中、小)型機，配套商用的關系型數據庫(Oracle、DB2、SQL Server)以及一些 ETL/OLAP 套件，實施成本相對高昂，數據倉庫建設主要集中在金融、電信、大型零售與制造等行業。

數據倉庫的應用主要通過為企業提供報表、分析等數據，輔助企業的經營決策。

像電信行業的經營分析系統、銀行的風控管理等，都是這個期間比較典型的應用。

第二階段

2010-2015 年，大數據平臺階段，移動互聯網的飛速發展帶動 Bigdata(大數據)的發展。

其中 Hadoop 生態技術開始逐步在國內大范圍使用，企業只要基于 Hadoop 分布式的計算框架，使用相對廉價的 PC 服務器就能搭建起大數據集群。

數據湖的概念也是這個階段誕生(主要是為降低傳統數倉較為復雜的中間建模過程，通過接入業務系統的原始數據，包括結構化、非結構數據，借助 Hadoop 生態強大計算引擎，將數據直接服務于應用)。

這個階段不只是金融、電信這些行業，國內主流互聯網企業也紛紛搭建起大數據平臺。

大數據應用更為豐富，不僅限于決策分析，基于 APP/門戶站點的搜索推薦、以及通過 A/B Test 來對產品進行升級迭代等是這個階段常規的應用點，用戶畫像在這個階段也得到重視，主要應用于企業的營銷、運營等場景。

 

 

 

 

第三階段

就是我們現在所處的階段，數據中臺以及云上大數據階段，通過前 10 多年不斷的技術積累，大數據在方法和組織的變革上也有了新的沉淀，主要體現在幾個方面：

①數據統一化

其核心思想是數據流轉的所有環節進行統一化，如從采集到存儲到加工等過程，在這些過程中通過建立統一的公共數據模型體系、統一的指標與標簽體系，提高數據的標準性、易用性，讓數據本身更好地連通，提升使用效率。

②工具組件化

數據在采集、計算、存儲、應用過程中涉及多業務線條，多場景，將這些場景與工具(采集工具、管道工具、計算&調度工具、數據服務工具，數據管理工具、可視化工具等)進行沉淀，研發出通用、高效的組件化工具，避免重復開發，降低研發成本。

③應用服務化

之前大數據應用的數據調用比較混雜，有些直接訪問數倉數據表，有些調用臨時接口等。

通過數據中臺應用服務化建設，提供標準的應用服務，以數據可視化產品、數據 API 工具等服務，支撐應用的靈活調用。

④組織清晰化

數據中臺團隊專注于數據內容&數據平臺開發，提供各種基于數據的能力模塊。

而其他部門人員如業務產品、運營、分析等角色，只需要借助工具/產品有效地使用數據，發揮其價值，無需關注數據加工的過程，做到各盡其職，充分發揮各自專長，同樣也能達到降本提效目的。

大數據團隊內部本身組織和職責也傾于清晰化，比如按照職責分為平臺(工具)研發、數據研發、數據產品、數據分析等不同組織。

當前階段

數據應用到各個角落，除了之前可以支撐的決策分析以外，大數據與線上事務系統(OLTP)的聯動場景非常多，比如我們在電商平臺查詢個人所有歷史訂單，再比如一些刷單、反作弊的實時攔截，以及一些實時推薦等。

這些都是通過將數據的運算交給數據中臺部門處理，前臺部門直接通過 API 進行結果調用。

數據中臺的集中化建設也更好地支撐起創新業務，比如通過大數據+分析建立起商業化數據變現產品，進行數據售賣，把數據變成新的業務。

大家知道共享復用是中臺建設中很關鍵的一個詞，這也是為什么我們很多數據中臺下面會包括共享數據組，公共數據組等。

實際上共享復用并不是大數據發展的一個新詞，在早期數據倉庫(建立公共數據模型)、大數據平臺(研發一些組件化工具)的建設中，也是滿足共享復用的。

如上提到，數據中臺本身是組織，方法的升級與變革，更多是利用技術的進步更好地支持這些升級變革，如果你當前的建設還是數據平臺+數倉(數據湖等)但是已經具備這些方法和特性，我個人認為也是合理的。

數據中臺的建設也需要相應的成本與門檻，例如集群搭建、工具建設等。

云計算的發展可以快速提供數據中臺建設的能力，例如企業無需自己搭建機房，使用云計算的彈性計算存儲能力以及豐富的工具，可以支撐數據中臺的快速搭建。

關于數據中臺的合理性也一直頗有爭議，大型(集團型)公司有相互獨立的子公司，數據之間不需要太多連接與共享，分別構建自己子數據中臺也是合理的架構。

集團層面可以利用數據子中臺進行數據上報解決集團層面數據大盤、統計、分析、財務等訴求。

再比如一些小型公司是否需要在一開始就按照數據中臺的架構進行建設，也是存有一些爭議。

數據中臺是 2015 年阿里提出來的雙中臺的概念其中的一個重要組成，阿里作為先驅者，提供了數據中臺架構、以及非常多的建設思路供大家參考。

從目前的建設效果來看，很多公司在數據中臺建設中有不錯的成效(尤其是大中型公司)，數據中臺整體思路得到了驗證。

但是數據中臺本身還算一個新鮮事務，這個新鮮事務目前還沒有標準答案，只有參考答案。

數據中臺架構與技術選型

數據中臺架構核心組成

我認為的數據中臺核心架構包括四大組成部分，具體是：

• 底座是數據基礎平臺，包括數據采集平臺&計算平臺&存儲平臺，這些可以自建也可以使用云計算服務。
• 中間部分兩大塊是中臺的公共數據區，公共數據區包括數據倉庫(數據湖) ，主要負責公共數據模型研發，還包括統一指標(標簽)平臺，負責把模型組織成可以對外服務的數據，例如數據指標、數據標簽。
• 上層是數據應用服務層，主要將公共數據區的數據對外包裝并提供服務，包括數據接口平臺、多維查詢平臺，數據可視化平臺、數據分析平臺等。

另外，數據研發平臺和數據管理平臺貫穿始終，其中：

• 數據開發平臺包括數據開發的各類工具組合，例如：數據管道工具(比如數據接入、數據導出)、模型設計工具、腳本開發工具、數據調度工具等。
• 數據管理平臺包括統一元數據管理、數據質量管理、數據生命周期管理。針對數據全鏈路的數據管理，保證數據中臺可以監控數據鏈路中的數據流向、數據使用效果、數據生命周期，以衡量數據的價值與成本。

以上是數據中臺的核心部分，數據中臺的組成也可以更加豐富，比如包括：數據資產平臺、算法平臺等等。

 

 

 

 

在數據中臺的建設中一定不要忽視的是與業務的銜接，因為數據來源于業務并最終應用于業務，在數據中臺的建設中需要有一系列的流程制度明確與業務的充分銜接，以保障數據源&數據產出的質量。

數據中臺技術選型參考

在搭建數據中臺方面，基于開源技術的選型，尤其是 Hadoop 生態圈有非常多的選擇，從數據整體流向來看各大層級的選型。

數據抽取層：Sqoop 和 Flume 是兩大主流工具，其中 Sqoop 作為結構化數據(關系型數據庫)離線抽取，Flume 作為非結構化日志接入。

數據存儲層：Hadoop 文件系統 HDFS 大家都比較了解，而 Kafka 作為流式數據總線應用也非常廣泛。

計算與調度層，包括：

• 離線計算：離線計算主要是 Hive，Spark，也有部分選用 Tez。
• 實時計算：前些年 Storm，Spark 比較流行，最近幾年大家紛紛往 Flink 轉型。
• 數據調度：除了像 Airflow Azkaban Oozie 等，易觀開源的 Dolphin-scheduler 也非常活躍。

數據引擎層：也就是我們常說的 OLAP 層，我們看到這一層里的選擇非常多，就不一一列舉了(業務需求帶動技術進步的典型，選擇豐富主要是可以適配不同的數據應用場景)。

從概念上講分為 ROLAP、MOLAP 以及兩者混搭。MOLAP 提前做一些預計算，以生成 Cube 的方式，達到空間換取查詢效率。

而 ROLAP 是即查即用，效率完全取決于查詢引擎的性能，我個人認為從將來看，ROLAP 的趨勢會更加明顯，因為沒有中間的數據鏈路。

但目前看來，沒有一個統一的引擎足以支撐各類數據場景(這或許是將來的機會~)。

數據可視化層：比較主流的有 Metabase、Superset、Redash，也可以選擇阿里、百度的一些開源控件。

 

 

 

 

在開源技術的選擇里，我們看到各層里都有越來越多國內開源的工具(也充分體現了我們在大數據技術領域的進步)。

除了以上列舉的這些，整個 Hadoop 生態圈的技術選擇非常多，可以結合自己的實際場景選擇自己的架構，在選型層面可以參照的一些原則，比如：

• 是否有鮮活的成功案例，優先找自己類似業務場景。
• 接口的開放性，與其他組件的兼容性。
• 社區活躍性度&發展趨勢。

當然，數據中臺的選型不只是開源技術，開源本身也不是完美的，例如維護開發成本較高，升級迭代不好把控，通過開源技術去建立數據中臺還是有一定研發門檻。

所以也有很多商業化的套件、以及基于云的數據組件可以選擇，包括數據采集、處理、分析、數據可視化全過程，國內外有很多廠商都提供了豐富的選擇。尤其在大數據可視化這塊，國內有許多非常專業的商業套件。

數據研發實踐

數據處理架構

下面是一個簡單的數據處理架構演進過程：

 

 

 

 

最早數據倉庫的計算只支持批處理，通常是按天定時處理數據，在后期逐步進化到準實時，本質上還是批處理，只是處理頻度上得有提升，到小時級，或者 15 分鐘這種。

隨著技術不斷進步，后期演化出一條新的流處理鏈路，這個鏈路和之前的批處理分別處理，然后在服務層面利用大數據的計算能力進行合并，向外提供離線+實時數據服務，這也是著名的 Lambda 架構。

最近幾年隨著 Flink 等技術的發展，有一個趨勢是流批一體化，在接入層統一采用流式接入，計算層采用統一套框架支持實時計算+離線計算，批處理僅僅作為流處理的一個特殊場景進行支持。

整體上可以做到流處理、批處理的自由切換。流計算和批處理在需求場景上有一些本質區別，前者主要用于支持線上業務場景(比如互聯網的推薦、搜索、風控等)，而批處理更多是支持離線統計分析。

日出而作，日落而息，大家針對大數據的統計分析習慣不會發生根本性變化，最簡單的 T+1 批處理方式也還是數據應用必不可少的環節。

在使用同一套架構上，由于數據源變化&維度變化的多樣性，批處理往往面臨一些復雜場景，這是采用同一套框架上的一些難點，充分支持好批處理也是將來流批一體框架的發展方向。

數倉分層與主題分類

①數倉分層

 

 

 

 

與傳統 ETL 不同的，我們采用的是 ELT 的數據架構，較為適合在互聯網，總體分為業務數據層、公共數據層、應用數據層三大層次。

業務數據層(ODS 層)：原始數據經過緩沖層(STG)的加載，會進入數倉的業務數據層，這一層采用范式建模，基本保持與數據源完全一致的結構，對于變化的數據，使用數據拉鏈加工與存儲。

這一層選用范式建模，是指保持源系統(例如關系數據庫)的范式結構，好處主要是：

• 一次性接入數據源結構，針對需求的變動不用頻繁去與數據源對接。
• 便于業務研發更好地理解數據，同時是也是公司的原始數據資產。

針對變化數據采用數據拉鏈的好處：

• 保留歷史數據的同時，盡可能少占用存儲空間，長期來看，拉鏈存儲比起每天全量保留歷史節約大概 90% 空間。
• 快速、高效地獲取歷史任意一天業務系統的快照數據。

公共數據層(包括公共明細層 DWD，公共匯總層 DWS)：公共數據層是數據倉庫的核心層，是整個數倉中使用率最高的，這一層主要采用的維度建模思路進行設計，類型包括事務事實、周期快照、累積快照。

同時為了方便下游對數據的使用，我們會設計一系列的寬表模型，將不同業務過程中的事實進行統一整合，包括縱向整合&橫向整合。

對于商品、用戶主數據類可能分散在不同的源系統中采用縱向整合;橫向整合主要包括交易、內容等行為數據不同業務過程的整合。

比如：用戶(用戶信息、注冊信息)購買(下單、支付、結算、覆約、完成)商品(商品信息，商家信息，等)。

我們會把訂單流轉業務過程整合放到一張明細表里，同時會研發一些基于用戶、或者商品視角的輕度匯總寬表。

寬表非常便于理解和易用，下游應用調用也方便。我們之前也做過一些統計，在調用分布來看，寬表的使用占到 70% 以上。

雖然寬表的使用在數倉建模中非常普遍，但是也有一些缺陷：

• 數據冗余較多，在存儲、計算、調用較為占資源，建議盡量還是按場景去使用。
• 寬表整合的信息較多，數據權限不好控制。建議可以根據需求，在有限范圍內開放整體寬表權限，或者通過視圖或者子表的方式建立不同權限的數據范圍，適應不同組織的需求。
• 寬表通常依賴比較多，會影響數據的產出的時效。

應用數據層(DWA 層)：顧名思義，就是偏向應用的數據加工，也可以叫集市層，這一層的設計可以相對靈活，貼近應用即可，總體設計思想仍然可以按維度建模思想為主。

主題分類

數倉架構的數據分類兩個視角，包括主題視角與業務視角。

①數據主題視角

最重要的一個視角，也就是咱們經常提到的數倉主題，主題是將企業的業務進行宏觀數據抽象，是數據倉庫里數據的主要組織形式。

劃分方法如下：

• 參照波特價值鏈，分析企業本身經營的業務(基本活動、支持型活動)，分別對應哪些數據。
• 參照業界通用模型，例如像 IBM、TD 等針對大型行業(如電信、金融、零售)有一些數據主題的通用劃分方法。
• 對企業的內部數據(線上數據模塊、數據字典)進行摸底，確認對應到哪些主題。

劃分結果會按照三個層級：

• 第一級是主題域，針對相對穩定的主題進行合并，歸攏到主題域，利于數據的理解與建立全局的數據資產目錄。
• 第二級是主題。
• 第三級是子主題，主要針對有些主題下分類較多，比如供應鏈主題下會包含采購、倉儲、配送等子主題。

數據主題劃分建議完全互斥，不建議重復。

②數據業務視角

數據業務域是根據企業經營的具體業務，結合企業的組織架構進行劃分，層次和分類可以相對靈活，子分類可以允許重復，因為兩條不同的業務域可能經營相同的業務，例如電商、內容下都有會員這個業務。

 

 

 

 

上圖是一個比較典型的內容+電商的數據主題與業務分類。

以上一橫一縱兩個視角，將數據進行更好的歸類，在數據模型設計中會打上相應分類標簽，從而讓數據研發&數據使用人員統一認知。以上兩種分類方式主要應用于核心的公共數據層。

業務數據層、應用數據層并不需要遵循以上分類規則，比如業務數據層(ODS層)是按照數據源進行分類，應用數據層(DWA)是根據具體的應用進行分類。

數據研發流程

除了合理的架構之外，數據研發的流程也很重要，總體流程如下：

 

 

 

 

包括需求分析/數據調研、數據模型設計、數據開發&測試、上線發布等流程。

在之前數據中臺的核心架構提到不閉門造車，數據研發需要與業務部門充分銜接，比如在數據調研中要與業務研發同學進行線上數據&結構訪談。

在數據開發中，與分析&業務同學共同確認標準口徑;在數據研發完成后對數據使用方進行數據發布與培訓。

以上流程中，除了需求調研，其他部分我們都進行了線上化，包括數據的模型設計。

早期我們會手寫 Mapping 文檔，后期我們逐步把 Mapping 文檔進行了線上化，整體的數據模型設計通過模型設計工具完成，包括從概念模型、邏輯模型到物理模型的設計。

模型設計完成后，可以一鍵生成數據知識文檔：

 

 

 

 

數據生命周期管理

數據研發完成，還需要關注數據生命周期：

• 一方面數據量的飛速增長不僅僅需要占用大量存儲，比如像自建機房，會涉及擴充機柜、機房，往往會面臨一些瓶頸。
• 另外一方面，大量的數據會降低數據的計算效率，所以從數據的生成開始，我們就需要考慮生命周期，并且結合數據的使用情況制定數據歸檔、數據銷毀等管理策略。

 

 

 

 

針對數據已經占用了大量存儲資源，可以采取一系列措施進行成本控制，例如：

• 降存量：通過數據壓縮技術、降副本等方式，以及在數據模型更合理的設計，將存量數據存儲降低。
• 控增量：根據數據重要性，可恢復性等考量角度，確認數據的保留周期，并根據周期自動歸檔或刪除。
• 攤成本：可以通過一些算法，比如數據調用分布、需求來源等，把成本分攤到相應業務部門，讓相關業務部門關注到成本。

數據安全也是數據生命周期管理重的一個重要課題，比如針對用戶敏感信息，需要在接入時考慮如何加密。

一種做法是通過一個獨立的物理集群對敏感數據進行隔離與強管控;數據使用中，也需要將數據劃分不同的安全或敏感等級(例如有些財務數據的非常敏感，需要謹慎對外開放)，根據不同的等級設定不同的訪問審批機制。

另外，在數據歸檔、銷毀也需要制定好配套的安全管理措施，避免安全風險。

數據質量管理

數據質量管理主要包括 3 個角度：準確性、及時性、一致性。管理的環節包括：事前、事中、事后、以及事故管理。

 

 

 

 

針對數據運維的告警發送，傳統的方式主要是短信、郵件、電話;隨著移動辦公工具功能逐步的強大，可以將運維告警以數據接口的方式與這些工具進行對接，將告警發送到企業內部的即時通訊工具。

數據應用架構

數據研發最終還是需要賦能到業務&應用，一個合理的數據應用架構是非常關鍵的。

這張圖是一個應用架構的簡圖參考：

 

 

 

 

從數據的流向上分：

• 數據倉庫(或者數據湖)：負責原始數據的計算，主要將數據落地到 HDFS。
• 數據引擎層：數據加工完成之后，會將數據推送到不同的引擎中，這一層之前提到選擇非常多，可以根據自己的場景選擇一個混搭組合，比如我們目前選擇的有 Presto，Kylin，Druid，MySQL。
• 數據服務層：通過統一化的 SQL 調用服務，屏蔽底層不同的數據引擎，為上層統一查詢提供標準接口。
• 指標平臺：指標平臺是一個非常關鍵的產品，定位于銜接數據研發與數據應用，包括指標的標準定義、邏輯、計算方式、分類等各項內容。指標分類上我們分為標準指標(指標口徑經過審核過)、以及非標準指標。
• 多維查詢：這是我們的一個即席查詢工具，查詢的數據主要來源指標平臺，可以選定不同的指標維度組合進行結果呈現，用戶可以一次性查詢得到結果，也可以將查詢結果配置成可視化的報表進行固化。

中間是統一元數據管理：對整個架構中可以對外提供服務的元數據進行統一管理(包括數倉的元數據、查詢引擎的元數據、指標元數據等)，以及監控這些元數據的調用情況。

最右側是權限管理：權限管理關乎到數據安全，在設計上需要考慮周全，比如針對表級、指標級、維度級別都可以進行控制;同時產品層面也需要靈活配置權限審批級別與人員。

在面向用戶使用層面，我們主要開放的是多維查詢&可視化，用戶通過多維去查詢各類指標&維度數據，得到數據結果列表，再選擇可視化配置面板，完成各類圖表、表格的自主配置，并發布到個人看板或者業務大盤目錄里。

也可以將配置的數據看板進行靈活組合，定制成一個小型的數據產品。

數據 ROI 評估

在數據研發中，也要考量數據的 ROI，下面是一個簡單的 ROI 模型：

 

 

 

 

根據活躍度(調用次數等)、覆蓋度(通過血緣關系找出依賴數量)，以及貢獻度(依賴數據的重要等級)來確認數據的價值。同時會評估數據的成本指數(例如計算成本、存儲成本等)。

通過以上兩者相除，綜合得到數據的 ROI，針對 ROI 可以將數據分為不同等級，并相應進行數據治理。比如針對價值低，成本高的數據，可以考慮下線等。

數據研發趨勢&關注點：

• 提效：目前借助工具的研發可以把絕大部分數據研發工作線上化，將來借助 AI 等能力，實現數據處理中包括開發、運維的自動化，提升處理效率。
• 靈活：流批一體化，包括流處理與批處理自由切換，之前已經提到過，個人認為也是一個發展的趨勢。
• 降本：數據研發鏈路的成本控制，在數據建設的早期通常不太引起關注，隨著數據量不斷的積累，往往存儲、計算成本成為瓶頸。針對數據建設成本需提前考慮。
• 算力：我們看到 Google，IBM 和阿里都在研究量子計算，將來的數據中間層(比如數倉的公共模型)是否可以考慮虛擬化(比如只保留規則&數據結構)，具體數據內容在應用發起時，即調即用，更多時候可以不需要占用存儲資源。算力的不斷提升，有可能會顛覆一些傳統數據建設的思路。

作者：顏博

簡介：現任馬蜂窩數據倉庫團隊負責人，曾供職于京東、IBM、亞信等公司。數據行業老兵一名，歷經傳統數據倉庫、大數據平臺到數據中臺的發展。

編輯：陶家龍

 

出處：轉載自微信公眾號 DBAplus 社群(ID：dbaplus)，本文根據顏博老師在〖Deeplus 直播第 218 期〗線上分享演講內容整理而成。