183.17.230.* 2020-04-20 13:34:45 |
大數(shù)據(jù)實(shí)時分析平臺(以下簡稱PB-S),旨在提供數(shù)據(jù)端到端實(shí)時處理能力(毫秒級/秒級/分鐘級延遲),可以對接多數(shù)據(jù)源進(jìn)行實(shí)時數(shù)據(jù)抽取,可以為多數(shù)據(jù)應(yīng)用場景提供實(shí)時數(shù)據(jù)消費(fèi)。作為現(xiàn)代數(shù)倉的一部分,PB-S可以支持實(shí)時化、虛擬化、平民化、協(xié)作化等能力,讓實(shí)時數(shù)據(jù)應(yīng)用開發(fā)門檻更低、迭代更快、質(zhì)量更好、運(yùn)行更穩(wěn)、運(yùn)維更簡、能力更強(qiáng)。
整體設(shè)計(jì)思想
我們針對用戶需求的四個層面進(jìn)行了統(tǒng)一化抽象:
統(tǒng)一數(shù)據(jù)采集平臺
統(tǒng)**式處理平臺
統(tǒng)一計(jì)算服務(wù)平臺
統(tǒng)一數(shù)據(jù)可視化平臺
同時,也對存儲層保持了開放的原則,意味著用戶可以選擇不同的存儲層以滿足具體項(xiàng)目的需要,而又不破壞整體架構(gòu)設(shè)計(jì),用戶甚至可以在Pipeline中同時選擇多個異構(gòu)存儲提供支持。下面分別對四個抽象層進(jìn)行解讀。
1)統(tǒng)一數(shù)據(jù)采集平臺
統(tǒng)一數(shù)據(jù)采集平臺,既可以支持不同數(shù)據(jù)源的全量抽取,也可以支持增強(qiáng)抽取。其中對于業(yè)務(wù)數(shù)據(jù)庫的增量抽取會選擇讀取數(shù)據(jù)庫日志,以減少對業(yè)務(wù)庫的讀取壓力。平臺還可以對抽取的數(shù)據(jù)進(jìn)行統(tǒng)一處理,然后以統(tǒng)一格式發(fā)布到數(shù)據(jù)總線上。這里我們選擇一種自定義的標(biāo)準(zhǔn)化統(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)**式處理平臺,會消費(fèi)來自數(shù)據(jù)總線上的消息,可以支持UMS協(xié)議消息,也可以支持普通JSON格式消息。同時,平臺還支持以下能力:
支持可視化/配置化/SQL化方式降低流式邏輯開發(fā)/部署/管理門檻
支持配置化方式冪等落入多個異構(gòu)目標(biāo)庫以確保數(shù)據(jù)的最終一致性
支持多租戶體系,做到項(xiàng)目級的計(jì)算資源/表資源/用戶資源等隔離
3)統(tǒng)一計(jì)算服務(wù)平臺
統(tǒng)一計(jì)算服務(wù)平臺,是一種數(shù)據(jù)虛擬化/數(shù)據(jù)聯(lián)邦的實(shí)現(xiàn)。平臺對內(nèi)支持多異構(gòu)數(shù)據(jù)源的下推計(jì)算和拉取混算,也支持對外的統(tǒng)一服務(wù)接口(JDBC/REST)和統(tǒng)一查詢語言(SQL)。由于平臺可以統(tǒng)一收口服務(wù),因此可以基于平臺打造統(tǒng)一元數(shù)據(jù)管理/數(shù)據(jù)質(zhì)量管理/數(shù)據(jù)安全審計(jì)/數(shù)據(jù)安全策略等模塊。平臺也支持多租戶體系。
4)統(tǒng)一數(shù)據(jù)可視化平臺
統(tǒng)一數(shù)據(jù)可視化平臺,加上多租戶和完善的用戶體系/權(quán)限體系,可以支持跨部門數(shù)據(jù)從業(yè)人員的分工協(xié)作能力,讓用戶在可視化環(huán)境下,通過緊密合作的方式,更能發(fā)揮各自所長來完成數(shù)據(jù)平臺**十公里的應(yīng)用。
以上是基于整體模塊架構(gòu)之上,進(jìn)行了統(tǒng)一抽象設(shè)計(jì),并開放存儲選項(xiàng)以提高靈活性和需求適配性。這樣的RTDP平臺設(shè)計(jì),體現(xiàn)了現(xiàn)代數(shù)倉的實(shí)時化/虛擬化/平民化/協(xié)作化等能力,并且覆蓋了端到端的OLPP數(shù)據(jù)流轉(zhuǎn)鏈路。
具體問題和解決思路
下面我們會基于PB-S的整體架構(gòu)設(shè)計(jì),分別從不同維度討論這個設(shè)計(jì)需要面對的問題考量和解決思路。
功能考量主要討論這樣一個問題:實(shí)時Pipeline能否處理所有ETL復(fù)雜邏輯?
我們知道,對于Storm/Flink這樣的流式計(jì)算引擎,是按每條處理的;對于Spark Streaming流式計(jì)算引擎,按每個mini-batch處理;而對于離線跑批任務(wù)來說,是按每天數(shù)據(jù)進(jìn)行處理的。因此處理范圍是數(shù)據(jù)的一個維度(范圍維度)。
另外,流式處理面向的是增量數(shù)據(jù),如果數(shù)據(jù)源來自關(guān)系型數(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算子。
復(fù)雜的ETL并不是單一算子,經(jīng)常會是由多個算子組合而成,由上可以看出單純的流式處理并不能很好的支持所有ETL復(fù)雜邏輯。那么如何在實(shí)時Pipeline中支持更多復(fù)雜的ETL算子,并且保持時效性?這就需要“有限范圍”和“全表范圍”處理的相互轉(zhuǎn)換能力。
設(shè)想一下:流式處理平臺可以支持流上適合的處理,然后實(shí)時落不同的異構(gòu)庫,計(jì)算服務(wù)平臺可以定時批量混算多源異構(gòu)庫(時間設(shè)定可以是每隔幾分鐘或更短),并將每批計(jì)算結(jié)果發(fā)送到數(shù)據(jù)總線上繼續(xù)流轉(zhuǎn),這樣流式處理平臺和計(jì)算服務(wù)平臺就形成了計(jì)算閉環(huán),各自做擅長的算子處理,數(shù)據(jù)在不同頻率觸發(fā)流轉(zhuǎn)過程中進(jìn)行各種算子轉(zhuǎn)換,這樣的架構(gòu)模式理論上即可支持所有ETL復(fù)雜邏輯。
1)質(zhì)量考量
上面的介紹也引出了兩個主流實(shí)時數(shù)據(jù)處理架構(gòu):Lambda架構(gòu)和Kappa架構(gòu),具體兩個架構(gòu)的介紹網(wǎng)上有很多資料,這里不再贅述。Lambda架構(gòu)和Kappa架構(gòu)各有其優(yōu)劣勢,但都支持?jǐn)?shù)據(jù)的最終一致性,從某種程度上確保了數(shù)據(jù)質(zhì)量,如何在Lambda架構(gòu)和Kappa架構(gòu)中取長補(bǔ)短,形成某種融合架構(gòu),這個話題會在其他文章中詳細(xì)探討。
當(dāng)然數(shù)據(jù)質(zhì)量也是個非常大的話題,只支持重跑和回灌并不能完全解決所有數(shù)據(jù)質(zhì)量問題,只是從技術(shù)架構(gòu)層面給出了補(bǔ)數(shù)據(jù)的工程方案。關(guān)于大數(shù)據(jù)數(shù)據(jù)質(zhì)量問題,我們也會起一個新的話題討論。
2)穩(wěn)定考量
這個話題涉及但不限于以下幾點(diǎn),這里簡單給出應(yīng)對的思路:
高可用HA
整個實(shí)時Pipeline鏈路都應(yīng)該選取高可用組件,確保理論上整體高可用;在數(shù)據(jù)關(guān)鍵鏈路上支持?jǐn)?shù)據(jù)備份和重演機(jī)制;在業(yè)務(wù)關(guān)鍵鏈路上支持雙跑融合機(jī)制
SLA保障
在確保集群和實(shí)時Pipeline高可用的前提下,支持動態(tài)擴(kuò)容和數(shù)據(jù)處理流程自動漂移
彈性反脆弱
基于規(guī)則和算法的資源彈性伸縮
支持事件觸發(fā)動作引擎的失效處理
監(jiān)控預(yù)警
集群設(shè)施層面,物理管道層面,數(shù)據(jù)邏輯層面的多方面監(jiān)控預(yù)警能力
自動運(yùn)維
能夠捕捉并存檔缺失數(shù)據(jù)和處理異常,并具備定期自動重試機(jī)制修復(fù)問題數(shù)據(jù)
上游元數(shù)據(jù)變更抗性
上游業(yè)務(wù)庫要求兼容性元數(shù)據(jù)變更
實(shí)時Pipeline處理顯式字段
3)成本考量
這個話題涉及但不限于以下幾點(diǎn),這里簡單給出應(yīng)對的思路:
人力成本
通過支持?jǐn)?shù)據(jù)應(yīng)用平民化降低人才人力成本
資源成本
通過支持動態(tài)資源利用降低靜態(tài)資源占用造成的資源浪費(fèi)
運(yùn)維成本
通過支持自動運(yùn)維/高可用/彈性反脆弱等機(jī)制降低運(yùn)維成本
試錯成本
通過支持敏捷開發(fā)/快速迭代降低試錯成本
4)敏捷考量
敏捷大數(shù)據(jù)是一整套理論體系和方法學(xué),在前文已有所描述,從數(shù)據(jù)使用角度來看,敏捷考量意味著:配置化,SQL化,平民化。
5)管理考量
數(shù)據(jù)管理也是一個非常大的話題,這里我們會重點(diǎn)關(guān)注兩個方面:元數(shù)據(jù)管理和數(shù)據(jù)安全管理。如果在現(xiàn)代數(shù)倉多數(shù)據(jù)存儲選型的環(huán)境下統(tǒng)一管理元數(shù)據(jù)和數(shù)據(jù)安全,是一個非常有挑戰(zhàn)的話題,我們會在實(shí)時Pipeline上各個環(huán)節(jié)平臺分別考慮這兩個方面問題并給出內(nèi)置支持,同時也可以支持對接外部統(tǒng)一的元數(shù)據(jù)管理平臺和統(tǒng)一數(shù)據(jù)安全策略。
如何設(shè)計(jì)一個大數(shù)據(jù)實(shí)時分析平臺.中琛魔方大數(shù)據(jù)平臺(www.zcmorefun.com)表示從概念背景,討論到架構(gòu)設(shè)計(jì),接著介紹了技術(shù)組件,**探討了模式場景。由于這里涉及到的每個話題點(diǎn)都很大,本文只是做了淺層的介紹和探討。 |