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