如何設計實時數(shù)據(jù)平臺（設計篇）
導讀：本文將會分上下兩篇對一個重要且常見的大數(shù)據(jù)基礎設施平臺展開討論，即“實時數(shù)據(jù)平臺”。在上篇設計篇中，我們首先從兩個維度介紹實時數(shù)據(jù)平臺：從現(xiàn)代數(shù)倉架構角度看待實時數(shù)據(jù)平臺，從典型數(shù)據(jù)處理角度看待實時數(shù)據(jù)處理；接著我們會探討實時數(shù)據(jù)平臺整體設計架構、對具體問題的考量以及解決思路。在下篇技術篇中，我們會進一步給出實時數(shù)據(jù)平臺的技術選型和相關組件介紹，并探討不同模式適用哪些應用場景。希望通過對本文的討論，讀者可以得到一個有章可循、可實際落地的實時數(shù)據(jù)平臺構建方案。
一、相關概念背景
1.1 從現(xiàn)代數(shù)倉架構角度看待實時數(shù)據(jù)平臺
現(xiàn)代數(shù)倉由傳統(tǒng)數(shù)倉發(fā)展而來，對比傳統(tǒng)數(shù)倉，現(xiàn)代數(shù)倉既有與其相同之處，也有諸多發(fā)展點。首先我們看一下傳統(tǒng)數(shù)倉（圖1）和現(xiàn)代數(shù)倉（圖2）的模塊架構：
圖1 傳統(tǒng)數(shù)倉
圖2 現(xiàn)代數(shù)倉
傳統(tǒng)數(shù)倉大家都很熟悉，這里不做過多介紹，一般來說，傳統(tǒng)數(shù)倉只能支持T＋1天時效延遲的數(shù)據(jù)處理，數(shù)據(jù)處理過程以ETL為主，最終產(chǎn)出以報表為主。
現(xiàn)代數(shù)倉建立在傳統(tǒng)數(shù)倉之上，同時增加了更多樣化數(shù)據(jù)源的導入存儲，更多樣化數(shù)據(jù)處理方式和時效（支持T＋0天時效），更多樣化數(shù)據(jù)使用方式和更多樣化數(shù)據(jù)終端服務。
現(xiàn)代數(shù)倉是個很大的話題，在此我們以概念模塊的方式來展現(xiàn)其新的特性能力。首先我們先看一下圖3中Melissa Coates的整理總結：
在圖3 Melissa Coates的總結中我們可以得出，現(xiàn)代數(shù)倉之所以“現(xiàn)代”，是因為它有多平臺架構、數(shù)據(jù)虛擬化、數(shù)據(jù)的近實時分析、敏捷交付方式等等一系列特性。
在借鑒Melissa Coates關于現(xiàn)代數(shù)倉總結的基礎上，加以自己的理解，我們也在此總結提取了現(xiàn)代數(shù)倉的幾個重要能力，分別是：
數(shù)據(jù)實時化（實時同步和流式處理能力）
數(shù)據(jù)虛擬化（虛擬混算和統(tǒng)一服務能力）
數(shù)據(jù)平民化（可視化和自助配置能力）
數(shù)據(jù)協(xié)作化（多租戶和分工協(xié)作能力）
1)數(shù)據(jù)實時化（實時同步和流式處理能力）
數(shù)據(jù)實時化，是指數(shù)據(jù)從產(chǎn)生（更新至業(yè)務數(shù)據(jù)庫或日志）到最終消費（數(shù)據(jù)報表、儀表板、分析、挖掘、數(shù)據(jù)應用等），支持毫秒級／秒級／分鐘級延遲（嚴格來說，秒級／分鐘級屬于準實時，這里統(tǒng)一稱為實時）。這里涉及到如何將數(shù)據(jù)實時的從數(shù)據(jù)源中抽取出來；如何實時流轉；為了提高時效性，降低端到端延遲，還需要有能力支持在流轉過程中進行計算處理；如何實時落庫；如何實時提供后續(xù)消費使用。實時同步是指多源到多目標的端到端同步，流式處理指在流上進行邏輯轉換處理。
但是我們要知道，不是所有數(shù)據(jù)處理計算都可以在流上進行，而我們的目的，是盡可能的降低端到端數(shù)據(jù)延遲，這里就需要和其他數(shù)據(jù)流轉處理方式配合進行，后面我們會進一步討論。
2) 數(shù)據(jù)虛擬化（虛擬混算和統(tǒng)一服務能力）
數(shù)據(jù)虛擬化，是指對于用戶或用戶程序而言，面對的是統(tǒng)一的交互方式和查詢語言，而無需關注數(shù)據(jù)實際所在的物理庫和方言及交互方式（異構系統(tǒng)／異構查詢語言）的一種技術。用戶的使用體驗是面對一個單一數(shù)據(jù)庫進行操作，但其實這是一個虛擬化的數(shù)據(jù)庫，數(shù)據(jù)本身并不存放于虛擬數(shù)據(jù)庫中。
虛擬混算指的是虛擬化技術可以支持異構系統(tǒng)數(shù)據(jù)透明混算的能力，統(tǒng)一服務指對于用戶提供統(tǒng)一的服務接口和方式。
圖4 數(shù)據(jù)虛擬化
（圖1-4均選自“Designing a Modern Data Warehouse + Data Lake” - Melissa Coates, Solution Architect, BlueGranite）
3)數(shù)據(jù)平民化（可視化和自助配置能力）
普通用戶（無專業(yè)大數(shù)據(jù)技術背景的數(shù)據(jù)從業(yè)人員），可以通過可視化的用戶界面，自助的通過配置和SQL方式使用數(shù)據(jù)完成自己的工作和需求，并無需關注底層技術層面問題（通過計算資源云化，數(shù)據(jù)虛擬化等技術）。以上是我們對數(shù)據(jù)平民化的解讀。
對于Data Democratization的解讀，還可以參見以下鏈接：
https://www.forbes.com/sites/bernardmarr/2017/07/24/what-is-data-democratization-a-super-simple-explanation-and-the-key-pros-and-cons
文中提到技術層面如何支持數(shù)據(jù)平民化，并給出了幾個例子：Data virtualization software，Data federation software，Cloud storage，Self-service BI applications等。其中數(shù)據(jù)虛擬化和數(shù)據(jù)聯(lián)邦本質(zhì)上是類似技術方案，并且提到了自助BI這個概念。
4)數(shù)據(jù)協(xié)作化（多租戶和分工協(xié)作能力）
技術人員應該多了解業(yè)務，還是業(yè)務人員應該多了解技術？這一直是企業(yè)內(nèi)爭論不休的問題。而我們相信現(xiàn)代BI是一個可以深度協(xié)作的過程，技術人員和業(yè)務人員可以在同一個平臺上，發(fā)揮各自所長，分工協(xié)作完成日常BI活動。這就對平臺的多租戶能力和分工協(xié)作能力提出了較高要求，一個好的現(xiàn)代數(shù)據(jù)平臺是可以支持更好的數(shù)據(jù)協(xié)作化能力的。
我們希望可以設計出一個現(xiàn)代實時數(shù)據(jù)平臺，滿足以上提到的實時化、虛擬化、平民化、協(xié)作化等能力，成為現(xiàn)代數(shù)倉的一個非常重要且必不可少的組成部分。
1.2 從典型數(shù)據(jù)處理角度看待實時數(shù)據(jù)處理
典型的數(shù)據(jù)處理，可分為OLTP, OLAP, Streaming, Adhoc, Machine Learning等。這里給出OLTP和OLAP的定義和對比：
（圖5選自文章“Relational Databases are not Designed for Mixed Workloads”-Matt Allen）
從某種角度來說，OLTP活動主要發(fā)生在業(yè)務交易庫端，OLAP活動主要發(fā)生在數(shù)據(jù)分析庫端。那么，數(shù)據(jù)是如何從OLTP庫流轉到OLAP庫呢？如果這個數(shù)據(jù)流轉時效性要求很高，傳統(tǒng)的T＋1批量ETL方式就無法滿足了。
我們將OLTP到OLAP的流轉過程叫Data Pipeline（數(shù)據(jù)處理管道），它是指數(shù)據(jù)的生產(chǎn)端到消費端之間的所有流轉和處理環(huán)節(jié)，包括了數(shù)據(jù)抽取、數(shù)據(jù)同步、流上處理、數(shù)據(jù)存儲、數(shù)據(jù)查詢等。這里可能會發(fā)生很復雜的數(shù)據(jù)處理轉換（如重復語義多源異構數(shù)據(jù)源到統(tǒng)一Star Schema的轉換，明細表到匯總表的轉換，多實體表聯(lián)合成寬表等）。如何支持實時性很高的Pipeline處理能力，就成了一個有挑戰(zhàn)性的話題，我們將這個話題描述為“在線管道處理”(OLPP, Online Pipeline Processing)問題。
因此，本文所討論的實時數(shù)據(jù)平臺，希望可以從數(shù)據(jù)處理角度解決OLPP問題，成為OLTP到OLAP實時流轉缺失的課題的解決方案。下面，我們會探討從架構層面，如何設計這樣一個實時數(shù)據(jù)平臺。
二、架構設計方案
2.1 定位和目標
實時數(shù)據(jù)平臺（Real-time Data Platform，以下簡稱RTDP），旨在提供數(shù)據(jù)端到端實時處理能力（毫秒級／秒級／分鐘級延遲），可以對接多數(shù)據(jù)源進行實時數(shù)據(jù)抽取，可以為多數(shù)據(jù)應用場景提供實時數(shù)據(jù)消費。作為現(xiàn)代數(shù)倉的一部分，RTDP可以支持實時化、虛擬化、平民化、協(xié)作化等能力，讓實時數(shù)據(jù)應用開發(fā)門檻更低、迭代更快、質(zhì)量更好、運行更穩(wěn)、運維更簡、能力更強。
2.2 整體設計架構
概念模塊架構，是實時數(shù)據(jù)處理Pipeline的概念層的分層架構和能力梳理，本身是具備通用性和可參考性的，更像是需求模塊。圖6給出了RTDP的整體概念模塊架構，具體每個模塊含義都可自解釋，這里不再詳述。
圖6 RTDP整體概念模塊架構
下面我們會根據(jù)上圖做進一步設計討論，給出從技術層面的高階設計思路。
圖7 整體設計思想
由圖7可以看出，我們針對概念模塊架構的四個層面進行了統(tǒng)一化抽象：
統(tǒng)一數(shù)據(jù)采集平臺
統(tǒng)一流式處理平臺
統(tǒng)一計算服務平臺
統(tǒng)一數(shù)據(jù)可視化平臺
同時，也對存儲層保持了開放的原則，意味著用戶可以選擇不同的存儲層以滿足具體項目的需要，而又不破壞整體架構設計，用戶甚至可以在Pipeline中同時選擇多個異構存儲提供支持。下面分別對四個抽象層進行解讀。
1)統(tǒng)一數(shù)據(jù)采集平臺
統(tǒng)一數(shù)據(jù)采集平臺，既可以支持不同數(shù)據(jù)源的全量抽取，也可以支持增強抽取。其中對于業(yè)務數(shù)據(jù)庫的增量抽取會選擇讀取數(shù)據(jù)庫日志，以減少對業(yè)務庫的讀取壓力。平臺還可以對抽取的數(shù)據(jù)進行統(tǒng)一處理，然后以統(tǒng)一格式發(fā)布到數(shù)據(jù)總線上。這里我們選擇一種自定義的標準化統(tǒng)一消息格式UMS（Unified Message Schema）做為統(tǒng)一數(shù)據(jù)采集平臺和統(tǒng)一流式處理平臺之間的數(shù)據(jù)層面協(xié)議。
UMS自帶Namespace信息和Schema信息，這是一種自定位自解釋消息協(xié)議格式，這樣做的好處是：
整個架構無需依賴外部元數(shù)據(jù)管理平臺；
消息和物理媒介解耦（這里物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通過物理媒介支持多消息流并行，和消息流的自由漂移。
平臺也支持多租戶體系，和配置化簡單處理清洗能力。
2)統(tǒng)一流式處理平臺
統(tǒng)一流式處理平臺，會消費來自數(shù)據(jù)總線上的消息，可以支持UMS協(xié)議消息，也可以支持普通JSON格式消息。同時，平臺還支持以下能力：
支持可視化／配置化／SQL化方式降低流式邏輯開發(fā)／部署／管理門檻
支持配置化方式冪等落入多個異構目標庫以確保數(shù)據(jù)的最終一致性
支持多租戶體系，做到項目級的計算資源／表資源／用戶資源等隔離
3)統(tǒng)一計算服務平臺
統(tǒng)一計算服務平臺，是一種數(shù)據(jù)虛擬化／數(shù)據(jù)聯(lián)邦的實現(xiàn)。平臺對內(nèi)支持多異構數(shù)據(jù)源的下推計算和拉取混算，也支持對外的統(tǒng)一服務接口（JDBC／REST）和統(tǒng)一查詢語言（SQL）。由于平臺可以統(tǒng)一收口服務，因此可以基于平臺打造統(tǒng)一元數(shù)據(jù)管理／數(shù)據(jù)質(zhì)量管理／數(shù)據(jù)安全審計／數(shù)據(jù)安全策略等模塊。平臺也支持多租戶體系。
4)統(tǒng)一數(shù)據(jù)可視化平臺
統(tǒng)一數(shù)據(jù)可視化平臺，加上多租戶和完善的用戶體系／權限體系，可以支持跨部門數(shù)據(jù)從業(yè)人員的分工協(xié)作能力，讓用戶在可視化環(huán)境下，通過緊密合作的方式，更能發(fā)揮各自所長來完成數(shù)據(jù)平臺最后十公里的應用。
以上是基于整體模塊架構之上，進行了統(tǒng)一抽象設計，并開放存儲選項以提高靈活性和需求適配性。這樣的RTDP平臺設計，體現(xiàn)了現(xiàn)代數(shù)倉的實時化／虛擬化／平民化／協(xié)作化等能力，并且覆蓋了端到端的OLPP數(shù)據(jù)流轉鏈路。
2.3 具體問題和考量思路
下面我們會基于RTDP的整體架構設計，分別從不同維度討論這個設計需要面對的問題考量和解決思路。
1)功能考量
功能考量主要討論這樣一個問題：實時Pipeline能否處理所有ETL復雜邏輯？
我們知道，對于Storm／Flink這樣的流式計算引擎，是按每條處理的；對于Spark Streaming流式計算引擎，按每個mini-batch處理；而對于離線跑批任務來說，是按每天數(shù)據(jù)進行處理的。因此處理范圍是數(shù)據(jù)的一個維度（范圍維度）。
另外，流式處理面向的是增量數(shù)據(jù)，如果數(shù)據(jù)源來自關系型數(shù)據(jù)庫，那么增量數(shù)據(jù)往往指的是增量變更數(shù)據(jù)（增刪改，revision）；相對的批量處理面向的則是快照數(shù)據(jù)（snapshot）。因此展現(xiàn)形式是數(shù)據(jù)的另一個維度（變更維度）。
單條數(shù)據(jù)的變更維度，是可以投射收斂成單條快照的，因此變更維度可以收斂成范圍維度。所以流式處理和批量處理的本質(zhì)區(qū)別在于，面對的數(shù)據(jù)范圍維度的不同，流式處理單位為“有限范圍”，批量處理單位為“全表范圍”。“全表范圍”數(shù)據(jù)是可以支持各種SQL算子的，而“有限范圍”數(shù)據(jù)只能支持部分SQL算子，具體支持情況如下：
join：
? left join：支持?！跋拗品秶笨梢詌eft join外部lookup表（通過下推，類似hashjoin效果）
? right join：不支持。每次從lookup拿回所有l(wèi)ookup表數(shù)據(jù)，這個計算是不可行的也是不合理的
? inter join：支持?？梢赞D化為left join ＋filter，可以支持
? outer join：不支持。存在right join，因此不合理
union：支持?？梢詰迷诶鼐植糠秶鷶?shù)據(jù)做窗口聚合操作。
agg：不支持?？梢越柚鷘nion做局部窗口聚合，但無法支持全表聚合操作。
filter：支持。沒有shuffle，非常適合。
map：支持。沒有shuffle，非常適合。
project：支持。沒有shuffle，非常適合。
Join往往需要shuffle操作，是最費計算資源和時間的操作，而流上join（left join）將join操作轉化成hashjoin的隊列操作，將批量處理join的集中數(shù)據(jù)計算資源和時間平攤在數(shù)據(jù)流轉過程中，因此在流上做left join是最劃算的計算方式。
復雜的ETL并不是單一算子，經(jīng)常會是由多個算子組合而成，由上可以看出單純的流式處理并不能很好的支持所有ETL復雜邏輯。那么如何在實時Pipeline中支持更多復雜的ETL算子，并且保持時效性？這就需要“有限范圍”和“全表范圍”處理的相互轉換能力。
設想一下：流式處理平臺可以支持流上適合的處理，然后實時落不同的異構庫，計算服務平臺可以定時批量混算多源異構庫（時間設定可以是每隔幾分鐘或更短），并將每批計算結果發(fā)送到數(shù)據(jù)總線上繼續(xù)流轉，這樣流式處理平臺和計算服務平臺就形成了計算閉環(huán)，各自做擅長的算子處理，數(shù)據(jù)在不同頻率觸發(fā)流轉過程中進行各種算子轉換，這樣的架構模式理論上即可支持所有ETL復雜邏輯。
圖8 數(shù)據(jù)處理架構演化
圖8給出了數(shù)據(jù)處理架構的演化，和OLPP的一種架構模式。其中wormhole和moonbox分別是我們開源的流式處理平臺和計算服務平臺，后面會具體介紹。
2)質(zhì)量考量
上面的圖也引出了兩個主流實時數(shù)據(jù)處理架構：Lambda架構和Kappa架構，具體兩個架構的介紹網(wǎng)上有很多資料，這里不再贅述。Lambda架構和Kappa架構各有其優(yōu)劣勢，但都支持數(shù)據(jù)的最終一致性，從某種程度上確保了數(shù)據(jù)質(zhì)量，如何在Lambda架構和Kappa架構中取長補短，形成某種融合架構，這個話題會在新起文章中詳細探討。
當然數(shù)據(jù)質(zhì)量也是個非常大的話題，只支持重跑和回灌并不能完全解決所有數(shù)據(jù)質(zhì)量問題，只是從技術架構層面給出了補數(shù)據(jù)的工程方案。關于大數(shù)據(jù)數(shù)據(jù)質(zhì)量問題，我們也會起一個新的話題討論。
3)穩(wěn)定考量
這個話題涉及但不限于以下幾點，這里簡單給出應對的思路：
高可用HA
整個實時Pipeline鏈路都應該選取高可用組件，確保理論上整體高可用；在數(shù)據(jù)關鍵鏈路上支持數(shù)據(jù)備份和重演機制；在業(yè)務關鍵鏈路上支持雙跑融合機制
SLA保障
在確保集群和實時Pipeline高可用的前提下，支持動態(tài)擴容和數(shù)據(jù)處理流程自動漂移
彈性反脆弱
? 基于規(guī)則和算法的資源彈性伸縮
? 支持事件觸發(fā)動作引擎的失效處理
監(jiān)控預警
集群設施層面，物理管道層面，數(shù)據(jù)邏輯層面的多方面監(jiān)控預警能力
自動運維
能夠捕捉并存檔缺失數(shù)據(jù)和處理異常，并具備定期自動重試機制修復問題數(shù)據(jù)
上游元數(shù)據(jù)變更抗性
?上游業(yè)務庫要求兼容性元數(shù)據(jù)變更
? 實時Pipeline處理顯式字段
4)成本考量
這個話題涉及但不限于以下幾點，這里簡單給出應對的思路：
人力成本
通過支持數(shù)據(jù)應用平民化降低人才人力成本
資源成本
通過支持動態(tài)資源利用降低靜態(tài)資源占用造成的資源浪費
運維成本
通過支持自動運維／高可用／彈性反脆弱等機制降低運維成本
試錯成本
通過支持敏捷開發(fā)／快速迭代降低試錯成本
5)敏捷考量
敏捷大數(shù)據(jù)是一整套理論體系和方法學，在前文已有所描述，從數(shù)據(jù)使用角度來看，敏捷考量意味著：配置化，SQL化，平民化。
6)管理考量
數(shù)據(jù)管理也是一個非常大的話題，這里我們會重點關注兩個方面：元數(shù)據(jù)管理和數(shù)據(jù)安全管理。如果在現(xiàn)代數(shù)倉多數(shù)據(jù)存儲選型的環(huán)境下統(tǒng)一管理元數(shù)據(jù)和數(shù)據(jù)安全，是一個非常有挑戰(zhàn)的話題，我們會在實時Pipeline上各個環(huán)節(jié)平臺分別考慮這兩個方面問題并給出內(nèi)置支持，同時也可以支持對接外部統(tǒng)一的元數(shù)據(jù)管理平臺和統(tǒng)一數(shù)據(jù)安全策略。
本文我們探討了實時數(shù)據(jù)平臺RTDP的相關概念背景和架構設計方案。在架構設計方案中，我們尤其著重講了RTDP的定位和目標，整體設計架構，以及涉及到的具體問題和考量思路。有些話題很大，可以后續(xù)單獨形成文章進行專題討論，但整體上，我們給出了一整套RTDP的設計思路和規(guī)劃。在下篇技術篇中，我們會將RTDP架構設計具體化落地化，給出推薦的技術選型和我們的開源平臺方案，并會結合不同場景需求探討RTDP的不同模式應用。
本文作者：盧山巍
推薦閱讀：
用 Apache Pulsar SQL 查詢數(shù)據(jù)流
干貨:Flink+Kafka 0.11端到端精確一次處理語義實現(xiàn)