中臺的種類
1.技術中臺（基礎服務中臺）
技術中臺指的是將大家都通用的技術能力聚合到一起，由同一個團隊負責，防止重複造輪子，是最容易實現的中臺化。核心價值是降成本。
各公司的基礎服務，以賬號體系爲代表，都已經是中臺化的了。淘寶、天貓、飛豬等業務之間，快車、專車、順風車等業務之間，美團外賣、酒旅、團購之間，必然要做打通。
2.數據中臺
顧名思義，表面上數據中臺是各業務的數據能夠打通。不過在實際運用中，又分爲多種。
數據中臺的本質就是“數據倉庫+數據服務中間件+實時性”。
基本的數據採集、數據倉庫建立和數據分析能力的共享，其實是數據技術中臺的範疇，是將做數據相關工作的技術團隊整合，來支持各業務。核心價值是降成本。
各業務線的數據打通、數據共享和協同運用，則屬於業務中臺的範疇，是以業務目標牽頭的（比如阿里的88VIP會員的前提就是用戶數據打通）。
有時這兩者是耦合在一起的，既有技術能力的共享，又有業務支撐。不過在國內數據分析的認知還比較淺（認爲數據都是拉報表的），後者往往效果不佳。前者在不少互聯網公司倒是確實落地了。
在有些公司，數據中臺只是很粗淺地把數據整合到一起，並沒有解決任何問題，或者讓整合產生什麼價值。阿里雲中間件架構總監謝純良曾經說過，許多公司的數據中臺就是把數據加工成“大屏”，搞一個展示用的“大屏”就以爲實現了中臺。意思就是，數據中臺如果不爲業務服務，或者說爲業務中臺服務，那就沒有價值。
3.業務中臺
既然技術模塊可以抽象出來複用，那業務模塊是不是也可以？在淘寶時用過的營銷策略，能不能直接挪到飛豬用？專車的策略能不能直接給快車用？這就是業務中臺的概念。
很顯然的，由於業務存在更高複雜度，因此難度更大。
業務中臺是各大公司追求的最終效果：前臺業務敏捷推進，後臺業務穩固支持。不過真實情況往往事與願違，難盡人意，真正做到業務中臺運轉良好的，很少見。
4.組織中臺
組織中臺是嫁接在前三種中臺基礎上，再加入“放權機制”的中臺結構。
阿里的中臺業務支撐能力可以支持新的電商相關業務快速創新；字節跳動把增長能力中臺化，頭條的增長部隊可以快速投入到抖音中去，甚至可以投入到海外各個國家各個產品；美團有試錯小團隊，會利用既有的技術能力、用戶流量等資源快速試錯，找到新的方向，包括外賣在內都是這樣來的。
這些都是組織中臺的體現。組織中臺與其說是中臺能力，倒不如說是內部創業的空間。它的核心價值應該在於“舊業務能否幫到新業務”，很考驗組織能力。有的公司內部創業，封閉隔離，跟這個公司自己投資了個新團隊，沒啥區別。
那麼，實時的數據中臺怎麼做？
下面是實現實時數據中臺的一種邏輯架構，方便你去理解，其實最關鍵的是實時模型那一層。
1、實時接入
不同類型的數據需要不同的接入方式，flume+kafka現在是標配，其他還有文件、數據庫的DSG等等技術。比如運營商就有B域的訂購、通話，O域的位置、上網等各類實時數據。
2、計算框架
這裏只列出一種，基於Kappa架構實現實時/離線一體化業務開發能力，相對於傳統Lambda架構，開發人員只需面對一個框架，開發、測試和運維的難度都相對較小，且能充分發揮Flink流式計算框架一點執行、高吞吐、毫秒級響應、批流融合的特點。
比如將流計算組件劃分實時數據切片，批處理組件提供離線數據模型（駐留內存），兩類數據在處理過程中實現批流關聯。
3、實時模型
跟數據倉庫模型一樣，實時模型肯定首先是面向業務的，比如運營商有流量運營、服務提醒、競爭應對、放好拉新、廳店引流、語音消費、運營評估、實時關懷、實時預警、實時洞察、實時推薦等一系列的實時場景，你總是要基於你的實時業務提煉出具備共性的數據模型要素。
比如放號拉新中的外來務工實時營銷，其中可能的觸發場景是針對漫入到某個交通樞紐並駐留10分鐘以上的用戶進行營銷投放，“在某個位置的駐留時長”這個公共要素可能就是一種可複用的實時模型。
實時模型縱向可以劃分爲DWD和DW兩層，DWD模型做的其實是針對各類實時數據做命名的標準化和過濾字段的操作，方便進行數據的標準化管理，DW模型這裏分成了三大類：動態模型、事件模型和時序模型，每種模型適合不同的場景，同時需要採用與之適配的存儲格式。
動態模型：對實時的數據進行彙總統計，適合做實時的統計指標分析，比如實時的業務辦理量，一般可存儲於Kafka和Hbase。
事件模型：把實時的數據抽象成一系列業務事件，比如從位置日誌軌跡中記錄用戶的位置變更事件，從而可以觸發LBS的位置營銷，以下是典型的位置事件模型設計，一般可存儲於MQ和Redis。
時序模型：主要保存用戶的在線的時空位置等信息，可以基於業務場景需要進行各種快速的計算，比如非常方便的計算駐留時長，存儲於Hbase或TSDB（時序數據庫）：
4、實時服務
有了實時模型還不夠，數據中臺還需要提供圖形化、流程化、可編排的數據開發工具，才能真正的降低實時數據開發成本。但由於離線和實時數據處理的技術手段不同，導致針對這兩種類型的數據開發和管理大多是在不同的平臺承載的。
比如以前我們的離線數據模型是通過DACP平臺管理的，但實時數據則遊離在DACP平臺之外，其往往屬於應用本身的一部分，應用需要通過編寫特定腳本去消費和處理流處理引擎中的原生數據，這種處理的門檻不僅高，而且資源浪費也挺嚴重，每個實時應用其實都是流數據的孤島。
站在應用的角度看，業務其實需要的是一個統一的數據開發管理平臺，離線和實時數據應作爲統一的對象進行管理，比如具備混合編排，混合關聯等能力，用簡單的類SQL定製化輸出應用所需的各類數據，從而高效的對外提供實時/離線數據服務。