大數(shù)據(jù)實時分析平臺（以下簡稱PB-S），旨在提供數(shù)據(jù)端到端實時處理能力（毫秒級／秒級／分鐘級延遲），可以對接多數(shù)據(jù)源進行實時數(shù)據(jù)抽取，可以為多數(shù)據(jù)應用場景提供實時數(shù)據(jù)消費。作為現(xiàn)代數(shù)倉的一部分，PB-S可以支持實時化、虛擬化、平民化、協(xié)作化等能力，讓實時數(shù)據(jù)應用開發(fā)門檻更低、迭代更快、質(zhì)量更好、運行更穩(wěn)、運維更簡、能力更強。



　　整體設計思想



　　我們針對用戶需求的四個層面進行了統(tǒng)一化抽象：



　　統(tǒng)一數(shù)據(jù)采集平臺



　　統(tǒng)**式處理平臺



　　統(tǒng)一計算服務平臺



　　統(tǒng)一數(shù)據(jù)可視化平臺



　　同時，也對存儲層保持了開放的原則，意味著用戶可以選擇不同的存儲層以滿足具體項目的需要，而又不破壞整體架構(gòu)設計，用戶甚至可以在Pipeline中同時選擇多個異構(gòu)存儲提供支持。下面分別對四個抽象層進行解讀。



　　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é)議格式，這樣做的好處是：



　　整個架構(gòu)無需依賴外部元數(shù)據(jù)管理平臺；



　　消息和物理媒介解耦（這里物理媒介指如Kafka的Topic,Spark Streaming的Stream等），因此可以通過物理媒介支持多消息流并行，和消息流的自由漂移。



　　平臺也支持多租戶體系，和配置化簡單處理清洗能力。



　　2)統(tǒng)**式處理平臺



　　統(tǒng)**式處理平臺，會消費來自數(shù)據(jù)總線上的消息，可以支持UMS協(xié)議消息，也可以支持普通JSON格式消息。同時，平臺還支持以下能力：



　　支持可視化／配置化／SQL化方式降低流式邏輯開發(fā)／部署／管理門檻



　　支持配置化方式冪等落入多個異構(gòu)目標庫以確保數(shù)據(jù)的最終一致性



　　支持多租戶體系，做到項目級的計算資源／表資源／用戶資源等隔離



　　3)統(tǒng)一計算服務平臺



　　統(tǒng)一計算服務平臺，是一種數(shù)據(jù)虛擬化／數(shù)據(jù)聯(lián)邦的實現(xiàn)。平臺對內(nèi)支持多異構(gòu)數(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ù)可視化平臺，加上多租戶和完善的用戶體系／權(quán)限體系，可以支持跨部門數(shù)據(jù)從業(yè)人員的分工協(xié)作能力，讓用戶在可視化環(huán)境下，通過緊密合作的方式，更能發(fā)揮各自所長來完成數(shù)據(jù)平臺**十公里的應用。



　　以上是基于整體模塊架構(gòu)之上，進行了統(tǒng)一抽象設計，并開放存儲選項以提高靈活性和需求適配性。這樣的RTDP平臺設計，體現(xiàn)了現(xiàn)代數(shù)倉的實時化／虛擬化／平民化／協(xié)作化等能力，并且覆蓋了端到端的OLPP數(shù)據(jù)流轉(zhuǎn)鏈路。



　　具體問題和解決思路



　　下面我們會基于PB-S的整體架構(gòu)設計，分別從不同維度討論這個設計需要面對的問題考量和解決思路。



　　功能考量主要討論這樣一個問題：實時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算子。



　　復雜的ETL并不是單一算子，經(jīng)常會是由多個算子組合而成，由上可以看出單純的流式處理并不能很好的支持所有ETL復雜邏輯。那么如何在實時Pipeline中支持更多復雜的ETL算子，并且保持時效性？這就需要“有限范圍”和“全表范圍”處理的相互轉(zhuǎn)換能力。



　　設想一下：流式處理平臺可以支持流上適合的處理，然后實時落不同的異構(gòu)庫，計算服務平臺可以定時批量混算多源異構(gòu)庫（時間設定可以是每隔幾分鐘或更短），并將每批計算結(jié)果發(fā)送到數(shù)據(jù)總線上繼續(xù)流轉(zhuǎn)，這樣流式處理平臺和計算服務平臺就形成了計算閉環(huán)，各自做擅長的算子處理，數(shù)據(jù)在不同頻率觸發(fā)流轉(zhuǎn)過程中進行各種算子轉(zhuǎn)換，這樣的架構(gòu)模式理論上即可支持所有ETL復雜邏輯。



　　1)質(zhì)量考量



　　上面的介紹也引出了兩個主流實時數(shù)據(jù)處理架構(gòu)：Lambda架構(gòu)和Kappa架構(gòu)，具體兩個架構(gòu)的介紹網(wǎng)上有很多資料，這里不再贅述。Lambda架構(gòu)和Kappa架構(gòu)各有其優(yōu)劣勢，但都支持數(shù)據(jù)的最終一致性，從某種程度上確保了數(shù)據(jù)質(zhì)量，如何在Lambda架構(gòu)和Kappa架構(gòu)中取長補短，形成某種融合架構(gòu)，這個話題會在其他文章中詳細探討。



　　當然數(shù)據(jù)質(zhì)量也是個非常大的話題，只支持重跑和回灌并不能完全解決所有數(shù)據(jù)質(zhì)量問題，只是從技術架構(gòu)層面給出了補數(shù)據(jù)的工程方案。關于大數(shù)據(jù)數(shù)據(jù)質(zhì)量問題，我們也會起一個新的話題討論。



　　2)穩(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處理顯式字段



　　3)成本考量



　　這個話題涉及但不限于以下幾點，這里簡單給出應對的思路：



　　人力成本



　　通過支持數(shù)據(jù)應用平民化降低人才人力成本



　　資源成本



　　通過支持動態(tài)資源利用降低靜態(tài)資源占用造成的資源浪費



　　運維成本



　　通過支持自動運維／高可用／彈性反脆弱等機制降低運維成本



　　試錯成本



　　通過支持敏捷開發(fā)／快速迭代降低試錯成本



　　4)敏捷考量



　　敏捷大數(shù)據(jù)是一整套理論體系和方法學，在前文已有所描述，從數(shù)據(jù)使用角度來看，敏捷考量意味著：配置化，SQL化，平民化。



　　5)管理考量



　　數(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ù)實時分析平臺.中琛魔方大數(shù)據(jù)平臺(www.zcmorefun.com)表示從概念背景，討論到架構(gòu)設計，接著介紹了技術組件，**探討了模式場景。由于這里涉及到的每個話題點都很大，本文只是做了淺層的介紹和探討。