大數據“網紅”阿里雲數據中臺簡介
數據中臺的定義
阿里巴巴數據中臺是阿里雲上實現數據智能的最佳實踐，它是由數據中臺方法論+組織+工具所組成，數據中臺方法論採用實現企業數據的全局規劃設計，通過前期的設計形成統一的數據標準、計算口徑，統一保障數據質量，面向數據分析場景構建數據模型，讓通用計算和數據能沉澱並能複用，提升計算效能。
數據中臺的建設實施必須有能與之配合的組織，不僅僅相應崗位的人員要配備齊全，而且組織架構建設也需要對應，有一個數據技術部門統籌企業的數字化轉型，數據賦能業務中形成業務模式，在推進數字化轉型中實現價值；數據中臺由一系列的工具和產品組成，阿里雲數據中臺以智能數據構建與管理Dataphin產品、商業智能QuickBI工具和企業參謀產品爲主體等一系列工具組成。
阿里雲在過去幾年中經過數十個實際項目沉澱形成實施標準化流程和方法論。阿里雲OneData數據中臺解決方案基於大數據存儲和計算平臺爲載體，以OneModel統一數據構建及管理方法論爲主幹，OneID核心商業要素資產化爲核心，實現全域鏈接、標籤萃取、立體畫像，以數據資產管理爲皮，數據應用服務爲枝葉的松耦性整體解決方案。其數據服務理念根植於心，強調業務模式，在推進數字化轉型中實現價值。
數據中臺的概念來自於阿里巴巴“大中臺，小前臺”業務戰略下的數據化實踐，它是關於“數據價值化和數據資產化”的一整套解決方案，內容包括數據中臺方法論，組織，數據產品三個方面。
數據中臺建設成果主要體現在兩方面：一個是數據的技術能力，另一個是數據的資產。今天阿里的各個業務都在共享同一套數據技術和資產。阿里內部爲這個統一化的數據體系命名爲“OneData”。
Onedata體系包括OneModel，OneID，OneService3個方面，在OneData體系之下，不斷擴大的業務版圖內的各種業務數據，都將按統一的方式接入中臺系統，之後通過統一化的數據服務反哺業務。
數據中臺頂層設計
數據中臺定位於計算後臺和業務前臺之間，其關鍵職能與核心價值是大數據以業務視角而非純技術視角出發，智能化構建數據、管理數據資產與提供數據調用、數據監控、數據分析與數據展現等多種服務。
承技術啓業務，是建設智能數據和催生數據智能的引擎；而以數據中臺內核價值爲中段的數據中臺業務模式不是純數據、不是純技術、也不是純業務，它同時關注着與大數據能力相關的上下游，以大數據爲中軸線，基於技術而又深入業務，它以數據產品+數據技術+方法論+場景實現的綜合性輸出，同時爲智能化數據、技術極致提升和數據智能化業務負責。
一方面專注於從業務視角，建設標準統一、融會貫通、資產化、服務化、閉環自優化的數據中臺智能數據體系，同時極致化追求技術上的降本提效。另一方面，致力於智能數據與業務場景深度融合的業務數據化與數據業務化中的各類智能化價值創新。
數據中臺與傳統數據倉庫差異
傳統的數據倉庫具有以下幾個特點：
1. 業務主題性：傳統的數倉要求解決服務問題，比如對一個生產型企業來說公司的主題域是產品、訂單、銷售商、材料等，要解決應用問題可能是庫存、銷售、銷售商等。其有業務是面向主題的。
2. 系統集成性：在傳統數據倉庫中，集成是最重要的，由於計算和存儲的成本原因，其數據需要從不同的數據源抽取過來並集中，其數據的冗餘度需要儘可能的降低，因此數據進入數據倉庫中需要進行轉化、格式化、重新排列和彙總等操作，其所有數據具有單一物理特性，都是結構化方式存在。
在系統架構方面，也是以集中式存儲和計算方式存在，新一代的數倉採用分佈式計算，但軟件產品採用集中部署方式存在。
3. 非易失性：數倉系統會記錄所有記錄，與業務系統相比，它不會對記錄進行變化操作（update和delete），它會保留所有記錄的變化，但受限於成本和計算能力考慮，數倉不會記錄全量明細數據，特別是日誌數據，因此大部分數倉平臺的數據容量在TB級別。
4. 時間變化性：數據倉庫中每個數據單元只是在某一時間是準確的，因此數據單元的準確性與時間相關，數據倉庫中的數據時間範圍5-10年。
5. 系統一體化: 傳統數倉以系統整體設計爲特性，軟件平臺圍繞着數據庫或計算平臺以整套服務爲主，結合度縝密，對外服務也較單一。傳統的數倉採用集中式數據庫作爲數據和計算平臺，近10年來，新興企業採用分佈式數據庫和大數據技術實現OLAP類數倉建設，但其本質還是基於一個整體來考慮的。
在系統和服務上數據中臺與傳數倉有很多明顯的區別，首先表現在服務對象方面，傳統的數倉只是滿足領導數據決策的需要，因此更多的體現在報表輸出，使用者以小部分的業務人員和決策層爲主，新需求的開發週期以月甚至到年爲計。
而數據中臺由於起家於互聯網企業，其使用對象擴大到一線服務人員和商家企業，其業務需求更繁雜，很難用一套報表系統滿足需求，因此催生出一個生態的數據服務。
其次是體系架構上，數據中臺是由多系統組成，除了計算平臺外，其方案由多個分佈式服務系統提供，滿足不同業務需求和高併發和系統自動擴容需求，除了大數據存儲和計算平臺外，還包含數倉建設、工作臺開發IDE、任務調度、數據同步服務、對外統一數據服務、資產管理系統、實時流計算平臺和開發平臺、oneID計算和查詢模塊，敏捷BI報表開發等多個組件，通過多個維度組件組成一整套方案。
再則，在服務表現形式上數據中臺體現的更多樣化，數據中臺不僅能提供報表基礎服務功能，而且爲了滿足各個業務部門不同需求，會提供領導決策系統、行業分析、業務洞察、業務重塑，自助查詢等多個功能，滿足從領導層、PD、業務人員、開發人員等各個層級的需求。
在繼承性方面，數據中臺採用傳統的數倉Kimball維度建模法，按照事實表，維表來構建數據中臺的數據模型。
數據倉庫與數據中臺的區別到底是什麼？
我們先來看看什麼是數據倉庫。
數據倉庫從技術上講主要會涉及到數據抽取，建模，清洗，存儲等技術過程，用戶方面以IT人員爲主，功能方面會專注於數據的整合，通過整合內部數據源、打破數據孤島，提供統一、唯一、標準、規範的原始數據，因此各個業務線都可以從這個數據倉庫獲取數據，並根據各自的業務需要做自助探索式分析，得出不同的結果，比如同一份會員數據，不同業務部門在加工後標籤內容和定義上可能會不盡相同。
不足主要體現在數據應用上缺乏話語權，往往是以業務需求爲導向，但不同業務團隊的需求很難一樣，所以IT響應的需求大多是個性定製化的，不具備複用性，導致企業使用的成本很高。
再來看看什麼是數據中臺。
首先引用下Kyligence聯合創始人兼CTO李楊對數據中臺的解釋：在中臺前臺的概念中，前臺指的是業務線，而中臺是指對業務線的支撐，代表數據賦能業務的意思。
從這個簡單的定義中不難看出，數據中臺不僅僅只有數據，還有支撐前線業務的運用場景，可以將數據轉變爲信息，從而指導業務決策支持，它包含了“數據爲核心、平臺爲支撐、驅動前線商務變革“三層意思，成功地在業務和技術之間建立了一個溝通的橋樑。
數據中臺旨在通過複用數據資產來驅動前線業務的高速創新和改造，說白了就是專門有一箇中臺部門，來爲各前線業務提供統一數據服務的解決方案，比如用戶畫像場景，同一份會員數據，由中臺人員根據業務情況進行統一建模，統一定義標籤後提供統一對外的輸出。
數據中臺的主體涉及到建模，清洗和應用，主要專注於數據的應用，主要提供統一的應用標準解決方案，成員不僅僅有IT人員，還要有非常理解公司業務的業務專家，在數據應用上依賴業務模型搭建，響應的一般都是比較通用的業務場景，如用戶畫像，然後基於用戶畫像提供不同服務如個性化營銷，精準推廣，行爲洞察等。
如果非要加以區分，數據倉庫是一個實體，承載着企業的數據中心，提供標準統一的數據來源；數據中臺更像是一個概念，承載着企業的業務中心，提供標準統一的業務場景輸出。
所以數據中臺不僅提供統一口徑，規範的數據，且還有中臺這個”部門”將這些數據轉變成了業務所需要的具體應用，業務用戶能直接拿來使用。而數據倉庫則僅僅是提供了一份標準，統一口徑的數據來源，至於是誰在用這份數據，怎麼用，數據倉庫就不管了(數據倉庫層面)。如果把數據倉庫比作數據的"技術語言"，那麼業務中臺則更加偏向於數據的"業務語言"。
數據中臺與數據湖區別
數據湖是數據的聚集、加工爲目的數據資源池，但是數據湖只是解決了聚集問題，在數據加工方面由於不可控制的需求變得異常繁重，由於數據的繁雜和混亂引入數據治理讓數據的加工更是舉步維艱。
傳統上數據湖中的數據會存儲原始數據，量大並且非結構化和半結構化的數據較多，需要有一個低成本分佈式存儲和計算架構來承載這些數據，屬於ODS層，缺乏數據主題和加工能力，因此近期對數據湖上的數據治理項目和應用越來越多。
數據湖彙集了原始ODS數據，解決了傳統數倉基礎數據缺乏的問題，作爲企業數倉平臺的補充，有其重要的意義，但數據湖的作用在於彙集企業的各個數據源，有一個存放和分析之地，在規劃中沒有一個整體的數據資產規劃和管理職能，這會導致其功能薄弱性，不能承擔整體的數據處理和管理之重。
實際在一些大型企業，使用數據湖其數據陷阱就會馬上出現，業務人員的需求需要DBA或IT人員經過繁雜的處理步驟才能實現達到業務人員的數據分析目的，其會耗費開發人員的時間耗以周計，原因之一是數據湖沒有一個數據構建和管理平臺去管理和計算這些數據，因此不講治理的雜亂無章的數據看似能提升數據獲取，數據分析的效率，實際上並不能承擔企業智能化的使命。
企業數據智能需要解決企業數據智能所面臨的諸多問題，企業數據智能需要解決數據的快速計算和結果產出；需要對企業數據資產有整體規劃和掌控；需要有一個好的方法論處理業務邏輯繁雜的統計；需要有一個好的構建和管理平臺面向業務使用方和開發使用方...這些都是數據湖所不能解決的問題。
數據中臺是由阿里巴巴在2015年在內部技術演進和組織優化中提出中臺戰略中提到的，數據湖本身的缺陷正是數據中臺強項，二者可以起到方案補充的作用，在現有技術框架中數據中臺可以基於Hadoop數據湖平臺作爲數據存儲和計算載體，實現數據的加工和處理。
數據中臺更多實現數據的管理，強調利用數據的能力，強調數據開發和高效的使用，數據中臺的數據資產管理可以對數據湖中的數據按照數據域方式進行管理並結合業務的邏輯實現整個數據模型的加工和開發。
數據中臺與數據域相比，數據中臺強調方法論，組織和工具的建設。非常強調數據賦能業務，衍生出很多的數據業務產品。比如在阿里面向商家的生意參謀，面向人物屬性的標籤服務、面向行業小二的行業洞察…這些都極大的擴展了數據價值，其次數據中臺按分析的原子指標和派生指標方式做計算並存儲在Maxcompute平臺上，如有及時查詢要求會同步分析結果數據給MPP或其他DB。這塊在數據頂層設計，全域資產、統一技術、產品業務上與Datalke及EDW是不同的。
最後說到底都是企業提供數據計算、存儲和應用的平臺，最終各種平臺的目的都是要更好地服務於業務。
《硅谷的“中臺論”與中國的“中臺論”》筆記
提要：
數據中臺指的是企業抽象，共享，和複用數據能力的平臺，核心是數據能力的共享和複用，並且提倡“去中心化的數據能力的複用和共享”
什麼是數據中臺？
數據中臺指的是企業抽象，共享，和複用數據能力的平臺，其目的是實現去中心化的商品洞察能力和產品迭代能力，使得企業能夠持續進行不斷演進的數字化運營，適應產品市場和人員組織的快速變化。
有了數據中臺，公司所有人不用再重複開發相關數據組件，就可以共享數據能力。產品經理不用再去各個部門找數據，而是在平臺上看有哪些數據、API 可以用……；某部門需要用戶畫像功能時，直接調用 API 就可以；反欺詐部門把“甄別用戶是不是機器人或者是惡意賬號”的能力輸出，其它部門想用的時候也可以直接調用 API。
數據中臺的核心是數據能力的共享和複用，並且這種共享和複用要在一個可管理的系統中進行，目的是通過數據驅動公司業務。在大數據領域主要體現在兩個方面，一個是 BI（商業洞見），一個是 AI（數字驅動的產品），對應美國常用的兩個指標，一是 time to reliable insight，老闆如何快速及時的獲取可靠商業洞見決策；二是 time to market。
數據中臺不只是一個理念，它還需要一系列的工具來支撐。“什麼是去中心化的數據能力的複用和共享？因爲如果共享是強制的，那麼大部分業務部門是不願意花時間在大數據上的，因爲這跟業務沒關係。那麼我們怎麼做呢？首先，要讓業務部門嚐到甜頭，其次，工具要足夠好用，第三，要保證系統無論如何不會崩壞。如果你有一系列在安全可控環境下的工具來共享業務部門的數據能力，並且能夠量化這些能力帶來的價值，業務部門纔會願意共享數據能力。”
數據中臺與技術中臺還不一樣，因爲數據是跟着業務走的，而技術的共性會比較多。讓數據中臺部門天天跟着業務去學習數據顯然是不可能的，所以數據中臺部門必須提供足夠好用的工具，賦能業務部門共享數據能力。中國有另一種模式，即：把某個能力抽取出來，由專門的組來負責。這兩種方式都可行，因此，要視公司的具體情況而定。
數據中臺的建設是從 0 到 1？還是是從 0 到 0.1？我們認爲是後者——數據中臺要很快見效，不斷迭代，分階段逐漸體現出數據中臺的價值，這樣各個部門纔有動力繼續配合建設數據中臺。
做中臺，一定要動組織架構嗎？
技術中臺的建設一定要動組織架構！ 但數據中臺的建設不一定要動組織架構！
數據中臺建設有一個關鍵的問題，數據能力由誰來提供？一種方式是由數據中臺部門來推動，將數據能力抽取到數據中臺；另一種方式是所有數據共享能力都由業務部門來提供，數據中臺部門提供工具。在後一種情況下，組織架構不需要變，開發流程會改變，以前各組件都是自己負責自己的數據，但是現在各組件的數據都必須符合公司規範。
雖然建設中臺是否動組織架構不太確定，但確定的是中臺戰略會涉及到多方利益，因此中臺建設一定是個“一把手”工程。
數據中臺的分層體系及數據流轉
一個完整的數據平臺至少應該包含三層，即大數據計算平臺、數據中臺、數據應用前臺。除此之外，還應該包括四層。未來的程序一定是雲原生的。因此數據平臺的底層一定是個私有云平臺，中間一層是大數據基礎組件層，包括 Hadoop、Kafka、Spark、認證安全、共享存儲等等，再上一層是大數據運營管理層，即如何把組件以一種最方便、最安全可靠的方式實現數據的共享和複用，最上面的一層是業務部門輸出的數據能力層，在大數據運營管理層之下，各部門能夠輸出和複用數據能力。
公共模塊的整合、提煉是數據中臺建設的重點，比較重要的公共模塊有數據採集、數據轉換、數據治理、數據和應用資產管理、數據分析、數據服務和數據展示，除此之外，還有一些必要的工具，例如數據安全、審計、多租戶、資源隔離、監控等等。
當數據進入到數據中臺之後，它的流轉路徑是怎樣的呢？首先，原始數據會先導入到數據湖，接着轉換到數據倉庫，再轉換到數據集市，數據集市中會有數據服務的發佈工具，自動發佈到平臺，並與具體的業務系統進行對接。當然，工具不僅有自動發佈工具，還有包括數據應用的調度管理、數據服務的生產、算法平臺的執行以及數據格式化等等。
原文見：AI前線 公衆號。
《數據中臺：讓數據用起來！》筆記
各行業數據中臺需求特徵
數據中臺能解決什麼問題？
整合孤島數據，沉澱數據資產，快速形成數據服務能力，爲企業經營決策、精細化運營提供支撐，這套機制就是數據中臺。中臺也是一套快速可靠的數據資產體系和數據服務能力（數據資產化和資產服務化）。這樣當出現新的市場變化，需要構建新的前臺應用時，數據中臺可以迅速供給數據服務（服務業務化）。
數據中臺能解決什麼問題？
中臺需要具備 數據匯聚整合、提純加工、服務可視化、價值變現４個核心能力，讓企業員工、客戶、夥伴能夠方便地應用數據。
a.匯聚整合：能夠接入、轉換、寫入或緩存企業內外部多種來源的數據，打破各業務系統塑造的孤島。
b.提純加工（即數據資產化）：通過統一的數據標準和質量體系，建設提純加工後的標準數據資產體系。光數據多還不行，還需要標準化，按應用需求梳理整合。
c.服務可視化：爲了儘快讓數據用起來，數據中臺必須提供便捷、快速的數據服務能力，讓相關人員能夠迅速開發數據應用，比如實時流數據分析、預測分析、機器學習...
d.價值變現（資產服務化）：提供以前單個部門或者單個業務單元無法提供的數據服務能力，以實現數據的更大價值變現。即1+1>2
數據中臺４個核心能力
數據中臺工具技術組件包括數據匯聚、數據開發、數據資產管理、數據服務管控等。
入手步驟和建議：
第一步，把企業現有哪些業務線，每個業務線有哪些數據，分別以什麼形式存儲以及數據的應用情況調研清楚；第二步，可以對照這本《數據中臺》裏提到的數據資產成熟度評估模型，對集團的數據應用成熟度做一個評估。
企業數據應用成熟度有4個階段：統計分析階段->決策支持階段->數據驅動階段->運營優化階段。
適合企業當前發展階段的纔是最好的，數據中臺也不是銀彈。 隨着數據獲取越來越容易，運用信息化系統讓企業經營、內部管理的過程越來越數字化，加上未來大概率進入穩定中速發展階段，存量博弈將會加劇，如何增效，提高生產率是內部管理的永恆話題。
不同行業的不同企業在不同階段，數瀾科技拿出了自家的數據中臺體系與方法論供大家學習，期待更多的最佳實踐案例。
讓企業更好的把數據用起來，科技讓人們更容易洞見本源。
參考書目
Ralph Kimball和Margy Ross的《數據倉庫工具集》或阿里巴巴的《大數據之路》等書
中國信通院聯合多家企業於2019年6月發佈了《數據資產管理實踐白皮書4.0》
相關書目待讀：中臺戰略、企業數字化、企業IT架構轉型之道、數字政府2.0、爲數據而生、賦能數字經濟。
《阿里的數據中臺正在背離初心》
相比數據中臺的強管控，敏捷的數據分析、智能的數據發現乃至更新的增強分析和增強數據管理等方法，探索的是一種越來越自助、敏捷、智能的道路，讓處於中心位置的數據工程團隊越來越精簡甚至不需要。這是一種平臺的思路。平臺的思路就是把技術做的門檻越來越低，越來越智能，不強行追求整齊劃一，而是容忍數據的不完美，風格和需求的多變，降低對中心化組織的需要，讓溝通鏈路更短。這纔是一種更創新，以賦能前臺爲出發點的模式。
中臺往往是一個方法論和組織驅動的概念，所以強調中臺，也會導致組織的固化。中臺組織要是變成倚老賣老、尾大不掉，那就不是好事了。
堅持賦能而非管控爲出發點，用什麼方法能夠更好的將數據轉化爲生產力，就用什麼方式，以企業級數據倉庫爲核心的數據中臺方法只是一種，我更認可能夠支持敏捷、自助、自組織的方式。雖然我們也實踐了很多數據中臺技術，但對於業務多元化的我們來說，會從更廣的視角來看。
from:冷技術熱思考公衆號
數字化企業的基礎是業務數據實時、統一、在線。
企業中臺的技術本質是：共性和個性的分離
共性體現在中臺架構層：共性業務抽象、業務邏輯解耦、業務數據隔離、分佈式技術架構等特點。
個性化體現在前端應用：快速組合服務、個性業務擴展、靈活業務適應。
業務中臺與數據中臺相輔相成、互相支撐，一起構建起戰場強大的後方炮火羣和雷達陣。
業務中臺將後臺資源進行抽象包裝整合，轉化爲前臺友好的可重用共享的核心能力，實現了後端業務資源到前臺易用能力的轉化。
數據中臺從後臺及業務中臺將數據流入，完成海量數據的存儲、計算、產品化包裝過程，構成企業的核心數據能力，爲前臺基於數據的定製化創新和業務中臺基於數據反饋的持續演進提供了強大支撐。
企業中臺就是，“將企業的核心能力隨着業務不斷髮展以數字化形式沉澱到平臺，形成以服務爲中心，由業務中臺和數據中臺構建起數據閉環運轉的運營體系，供企業更高效的進行業務探索和創新,實現以數字化資產的形態構建企業核心差異化競爭力。”
2019SACC擷英
小米自己搞了個”kafka“，還自帶source和sink。
海致BDP（智能數據平臺）一站式數據平臺——快速打造貼合業務（靈活、易用）的一站式（完整、閉環）數據平臺
《小白也能看懂的阿里數據中臺分析》
數據中臺不是大數據平臺！它不是一個平臺，也不是一個系統，如果有廠商說他們有個數據中臺賣給你，對不起，它是個騙子。
在數據開發中，核心數據模型的變化是相對緩慢的，同時，對數據進行維護的工作量也非常大；但業務創新的速度、對數據提出的需求的變化，是非常快速的。
數據中臺的出現，就是爲了彌補數據開發和應用開發之間，由於開發速度不匹配，出現的響應力跟不上的問題。
數據中臺解決的問題可以總結爲如下三點：
- 效率：爲什麼應用開發增加一個報表，就要十幾天時間？爲什麼不能實時獲得用戶推薦清單？當業務人員對數據產生一點疑問的時候，需要花費很長的時間，結果發現是數據源的數據變了，最終影響上線時間。
- 協作問題：當業務應用開發的時候，雖然和別的項目需求大致差不多，但因爲是別的項目組維護的，所以數據還是要自己再開發一遍。
- 能力問題：數據的處理和維護是一個相對獨立的技術，需要相當專業的人來完成，但是很多時候，我們有一大把的應用開發人員，而數據開發人員很少。
這三類問題都會導致應用開發團隊變慢。這就是中臺的關鍵——讓前臺開發團隊的開發速度不受後臺數據開發的影響。
數據中臺是聚合和治理跨域數據，將數據抽象封裝成服務，提供給前臺以業務價值的邏輯概念。
DData API 是數據中臺的核心，它是連接前臺和後臺的橋樑，通過 API 的方式提供數據服務，而不是直接把數據庫給前臺、讓前臺開發自行使用數據。至於產生 DataAPI 的過程，怎麼樣讓 DataAPI 產生得更快，怎麼樣讓 DATA API 更加清晰，怎麼樣讓 DATA API 的數據質量更好，這些是要圍繞數據中臺去構建的能力。
阿里數據中臺詳解
1、阿里數據中臺賦能業務全景圖
2、阿里數據中臺三大體系
經過多年實戰，沉澱出了阿里雲上數據中臺內核能力框架體系：產品+技術+方法論。
歷經阿里生態內各種實戰歷練後，雲上數據中臺從業務視角而非純技術視角出發，智能化構建數據、管理數據資產，並提供數椐調用、數據監控、數據分析與數據展現等多種服務。
承技術啓業務，是建設智能數據和催生數據智能的引擎。在OneData、OneEntity、OneService三大體系，特別是其方法論的指導下，雲上數據中臺本身的內核能力在不斷積累和沉澱。
OneData致力幹統一數據標準，讓數據成爲資產而非成本；OneEntity致力於統一實體，讓數據融通而以非孤島存在；OneService致力於統一數據服務，讓數據複用而非複製。
那麼，實時的數據中臺怎麼做？
下面是實現實時數據中臺的一種邏輯架構，方便你去理解，其實最關鍵的是實時模型那一層。
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定製化輸出應用所需的各類數據，從而高效的對外提供實時/離線數據服務。
5、實時應用
數據中臺如果能支持實時數據的快速編排，根據我們的測算，其實時場景應用的數據開發、測試、部署週期會由0.5-1個月降低爲1-2天，效益是很高的。
附：
《阿里數據中臺建設實踐案例》
《中臺架構50篇資料精選，阿里/騰訊/京東...中臺建設實踐彙集》
《OneData建設探索之路：SaaS收銀運營數倉建設》
務實信息量大，接地氣
ADX項目Review及思考
1 Datahub數據服務：如何規劃設計。
2 各個模塊獨立性不夠，有相互依賴的地方。
建議分別打造成可單獨使用的積木模塊/插件。相互直接通過rest調用及隊列進行通信和數據交換。
每個模塊功能做紮實。
3 過於複雜。如何提高部署運維自動性？