本文先梳理了為何需要數據中臺，以及數據中臺構建需要用到什么技術，什么平臺。

01

在談過業務中臺和數據中臺的區別后，今天再談下數據中臺。首先我們看下網上對于數據中臺的一個定義和說法，即：

數據中臺是指通過數據技術，對海量數據進行采集、計算、存儲、加工，同時統一標準和口徑。數據中臺把數據統一之后，會形成標準數據，再進行存儲，形成大數據資產層，進而為客戶提供高效服務。這些服務跟企業的業務有較強關聯性，是這個企業獨有且能復用的。

如果單獨看這個定義，那么數據中臺很容易被理解為企業里面的BI系統建設，包括了ODS庫和數據倉庫，同時支持OLTP和OLAP能力。也可以說是構建企業的大數據平臺。

而今天自己想談下對數據中臺這個概念的一些理解：

首先我們要看到數據中臺是整個企業中臺戰略的一部分，是配合企業微服務架構轉型和業務中臺能力構建不可缺少的部分。

如果沒有整個中臺戰略，那么就不存在數據中臺，你單獨去建設大數據平臺或BI平臺就可以了。

數據中臺不是一個單純的數據技術平臺，而是一個共享數據能力提供平臺。對于數據的采集，清洗，存儲和加工最終都是為了開放數據服務能力。

如果說業務中臺更多的是業務能力的開發，那么數據中臺就是聚合后的數據服務能力的開放。

為何要開放數據服務能力？

這個絕對不是簡單的給上層做BI來分析用的，而是這種數據服務能力需要去支撐前臺業務場景和業務功能的實現。

即這種數據服務能力需要具備一定的數據實時性要求，那么我們可能看到對于業務中臺本身也會提供數據服務能力，比如訂單中心也提供訂單查詢數據服務能力，那么兩者的區別究竟在哪里？

初步分析包括：

1. 業務中臺數據服務實時性最強，數據中臺數據服務準實時
2. 業務中臺數據服務單一數據對象，而數據中臺數據服務可以提供關聯后多數據對象聚合后數據
3. 業務中臺數據服務包括了CRUD各種類型，但是數據中臺的數據服務一般為單一的查詢服務

02

這點理解清楚后，我們再回來就容易搞清楚為何數據中臺需要提供準實時的數據服務API接口——

要看到在微服務架構下構建的業務中臺各個中心，按照標準的微服務架構要求，各個中心對應的數據庫本身也完全是獨立和拆分的，訂單中心是訂單數據庫，用戶中心是用戶數據庫，相互之間完全垂直獨立以方便應用的靈活擴展。

但是這種數據庫拆分帶來最大的問題就是——當業務場景需要底層多個業務數據對象提供關聯后聚合后的查詢數據集的時候極不方便。

為了解決這個問題，實際上我們有兩種做法來進行處理：

第一種：構建一個領域服務層組件

即我們單獨構建一個領域服務層組件或微服務模塊，來提供整合后的領域服務能力，這個組件如果需要提供一個關聯多個業務對象的數據集合，那么就需要調用過個API接口返回多個獨立數據集合，然后在組件業務邏輯實現中來完成多個數據集的整合工作。

雖然對于查詢類服務沒有分布式事務問題，但是這種方式在性能上肯定存在較大損耗，優勢則在這種方式不用前臺訪問多次API接口服務，同時又保證了數據的實時性。

第二種：構建數據中臺，然后提供開放數據服務能力接口

這種方式就是構建數據中臺，在數據中臺完成業務中臺多個數據庫數據的數據采集和整合，形成一個完整的跨越的數據模型，由于有了完整的數據，因此很自然能夠提供關聯聚合數據對象服務的能力。

但是這種方式的問題也比較明顯，就是如何保證數據本身的實時性和一致性，完全的實時往往很難保證，那么如何保證數據的準實時性，如何保證數據采集過程中出現問題而導致數據不一致也需要考慮。

把整個想清楚了，也就是想清楚了數據中臺的一個關鍵作用，就是提供準實時的聚合數據服務能力API接口并進行開放給前臺使用，方便前臺業務場景和功能的實現，而不是簡單的提供一個供分析決策的數據庫。因此對于數據中臺的這個關鍵能力我們可以簡單的理解為：

分布式ODS庫+能力開放平臺+準實時數據能力提供

這個就是我們前面談到的數據中臺的一個關鍵能力提供，那么我們談到數據采集集成技術，分布式數據存儲，實時數據集成，數據流處理，包括類似Hadoop大數據平臺等，所有這些都是數據中臺在實現過程中為了滿足分布式+實時性的技術支撐。

先理解清楚為何需要數據中臺，再來搞清楚數據中臺構建需要用到什么技術，什么平臺，整個對中臺戰略，中臺構建的思考邏輯才會清楚。

本文由 @人月神話 授權發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議