如何設計實時數據平臺（設計篇）

導讀：本文將會分上下兩篇對一個重要且常見的大數據基礎設施平臺展開討論，即「實時數據平臺」。 在上篇設計篇中，咱們首先從兩個維度介紹實時數據平臺：從現代數倉架構角度看待實時數據平臺，從典型數據處理角度看待實時數據處理；接着咱們會探討實時數據平臺總體設計架構、對具體問題的考量以及解決思路。 在下篇技術篇中，咱們會進一步給出實時數據平臺的技術選型和相關組件介紹，並探討不一樣模式適用哪些應用場景。但願經過對本文的討論，讀者能夠獲得一個有章可循、可實際落地的實時數據平臺構建方案。

1、相關概念背景

1.1 從現代數倉架構角度看待實時數據平臺

現代數倉由傳統數倉發展而來，對比傳統數倉，現代數倉既有與其相同之處，也有諸多發展點。首先咱們看一下傳統數倉（圖1）和現代數倉（圖2）的模塊架構：

圖1 傳統數倉

圖2 現代數倉

傳統數倉你們都很熟悉，這裏不作過多介紹，通常來講，傳統數倉只能支持T＋1天時效延遲的數據處理，數據處理過程以ETL爲主，最終產出以報表爲主。

現代數倉創建在傳統數倉之上，同時增長了更多樣化數據源的導入存儲，更多樣化數據處理方式和時效（支持T＋0天時效），更多樣化數據使用方式和更多樣化數據終端服務。

現代數倉是個很大的話題，在此咱們以概念模塊的方式來展示其新的特性能力。首先咱們先看一下圖3中Melissa Coates的整理總結：

在圖3 Melissa Coates的總結中咱們能夠得出，現代數倉之因此「現代」，是由於它有多平臺架構、數據虛擬化、數據的近實時分析、敏捷交付方式等等一系列特性。

在借鑑Melissa Coates關於現代數倉總結的基礎上，加以本身的理解，咱們也在此總結提取了現代數倉的幾個重要能力，分別是：

• 數據實時化（實時同步和流式處理能力）

• 數據虛擬化（虛擬混算和統一服務能力）

• 數據平民化（可視化和自助配置能力）

• 數據協做化（多租戶和分工協做能力）

1)數據實時化（實時同步和流式處理能力）

數據實時化，是指數據從產生（更新至業務數據庫或日誌）到最終消費（數據報表、儀表板、分析、挖掘、數據應用等），支持毫秒級／秒級／分鐘級延遲（嚴格來講，秒級／分鐘級屬於準實時，這裏統一稱爲實時）。這裏涉及到如何將數據實時的從數據源中抽取出來；如何實時流轉；爲了提升時效性，下降端到端延遲，還須要有能力支持在流轉過程當中進行計算處理；如何實時落庫；如何實時提供後續消費使用。實時同步是指多源到多目標的端到端同步，流式處理指在流上進行邏輯轉換處理。

可是咱們要知道，不是全部數據處理計算均可以在流上進行，而咱們的目的，是儘量的下降端到端數據延遲，這裏就須要和其餘數據流轉處理方式配合進行，後面咱們會進一步討論。

2) 數據虛擬化（虛擬混算和統一服務能力）

數據虛擬化，是指對於用戶或用戶程序而言，面對的是統一的交互方式和查詢語言，而無需關注數據實際所在的物理庫和方言及交互方式（異構系統／異構查詢語言）的一種技術。用戶的使用體驗是面對一個單一數據庫進行操做，但其實這是一個虛擬化的數據庫，數據自己並不存放於虛擬數據庫中。

虛擬混算指的是虛擬化技術能夠支持異構系統數據透明混算的能力，統一服務指對於用戶提供統一的服務接口和方式。

圖4 數據虛擬化

（圖1-4均選自「Designing a Modern Data Warehouse + Data Lake」 - Melissa Coates, Solution Architect, BlueGranite）

3)數據平民化（可視化和自助配置能力）

普通用戶（無專業大數據技術背景的數據從業人員），能夠經過可視化的用戶界面，自助的經過配置和SQL方式使用數據完成本身的工做和需求，並沒有需關注底層技術層面問題（經過計算資源雲化，數據虛擬化等技術）。以上是咱們對數據平民化的解讀。

對於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

文中提到技術層面如何支持數據平民化，並給出了幾個例子：Data virtualization software，Data federation software，Cloud storage，Self-service BI applications等。其中數據虛擬化和數據聯邦本質上是相似技術方案，而且提到了自助BI這個概念。

4)數據協做化（多租戶和分工協做能力）

技術人員應該多瞭解業務，仍是業務人員應該多瞭解技術？這一直是企業內爭論不休的問題。而咱們相信現代BI是一個能夠深度協做的過程，技術人員和業務人員能夠在同一個平臺上，發揮各自所長，分工協做完成平常BI活動。這就對平臺的多租戶能力和分工協做能力提出了較高要求，一個好的現代數據平臺是能夠支持更好的數據協做化能力的。

咱們但願能夠設計出一個現代實時數據平臺，知足以上提到的實時化、虛擬化、平民化、協做化等能力，成爲現代數倉的一個很是重要且必不可少的組成部分。

1.2 從典型數據處理角度看待實時數據處理

典型的數據處理，可分爲OLTP, OLAP, Streaming, Adhoc, Machine Learning等。這裏給出OLTP和OLAP的定義和對比：

（圖5選自文章「Relational Databases are not Designed for Mixed Workloads」-Matt Allen）

從某種角度來講，OLTP活動主要發生在業務交易庫端，OLAP活動主要發生在數據分析庫端。那麼，數據是如何從OLTP庫流轉到OLAP庫呢？若是這個數據流轉時效性要求很高，傳統的T＋1批量ETL方式就沒法知足了。

咱們將OLTP到OLAP的流轉過程叫Data Pipeline（數據處理管道），它是指數據的生產端到消費端之間的全部流轉和處理環節，包括了數據抽取、數據同步、流上處理、數據存儲、數據查詢等。這裏可能會發生很複雜的數據處理轉換（如重複語義多源異構數據源到統一Star Schema的轉換，明細表到彙總表的轉換，多實體表聯合成寬表等）。如何支持實時性很高的Pipeline處理能力，就成了一個有挑戰性的話題，咱們將這個話題描述爲「在線管道處理」(OLPP, Online Pipeline Processing)問題。

所以，本文所討論的實時數據平臺，但願能夠從數據處理角度解決OLPP問題，成爲OLTP到OLAP實時流轉缺失的課題的解決方案。下面，咱們會探討從架構層面，如何設計這樣一個實時數據平臺。

2、架構設計方案

2.1 定位和目標

實時數據平臺（Real-time Data Platform，如下簡稱RTDP），旨在提供數據端到端實時處理能力（毫秒級／秒級／分鐘級延遲），能夠對接多數據源進行實時數據抽取，能夠爲多數據應用場景提供實時數據消費。做爲現代數倉的一部分，RTDP能夠支持實時化、虛擬化、平民化、協做化等能力，讓實時數據應用開發門檻更低、迭代更快、質量更好、運行更穩、運維更簡、能力更強。

2.2 總體設計架構

概念模塊架構，是實時數據處理Pipeline的概念層的分層架構和能力梳理，自己是具有通用性和可參考性的，更像是需求模塊。圖6給出了RTDP的總體概念模塊架構，具體每一個模塊含義均可自解釋，這裏再也不詳述。

圖6 RTDP總體概念模塊架構

下面咱們會根據上圖作進一步設計討論，給出從技術層面的高階設計思路。

圖7 總體設計思想

由圖7能夠看出，咱們針對概念模塊架構的四個層面進行了統一化抽象：

• 統一數據採集平臺

• 統一流式處理平臺

• 統一計算服務平臺

• 統一數據可視化平臺

同時，也對存儲層保持了開放的原則，意味着用戶能夠選擇不一樣的存儲層以知足具體項目的須要，而又不破壞總體架構設計，用戶甚至能夠在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數據流轉鏈路。

2.3 具體問題和考量思路

下面咱們會基於RTDP的總體架構設計，分別從不一樣維度討論這個設計須要面對的問題考量和解決思路。

1)功能考量

功能考量主要討論這樣一個問題：實時Pipeline可否處理全部ETL複雜邏輯？

咱們知道，對於Storm／Flink這樣的流式計算引擎，是按每條處理的；對於Spark Streaming流式計算引擎，按每一個mini-batch處理；而對於離線跑批任務來講，是按天天數據進行處理的。所以處理範圍是數據的一個維度（範圍維度）。

另外，流式處理面向的是增量數據，若是數據源來自關係型數據庫，那麼增量數據每每指的是增量變動數據（增刪改，revision）；相對的批量處理面向的則是快照數據（snapshot）。所以展示形式是數據的另外一個維度（變動維度）。

單條數據的變動維度，是能夠投射收斂成單條快照的，所以變動維度能夠收斂成範圍維度。因此流式處理和批量處理的本質區別在於，面對的數據範圍維度的不一樣，流式處理單位爲「有限範圍」，批量處理單位爲「全表範圍」。「全表範圍」數據是能夠支持各類SQL算子的，而「有限範圍」數據只能支持部分SQL算子，具體支持狀況以下：

• join：

✔ left join：支持。「限制範圍」能夠left join外部lookup表（經過下推，相似hashjoin效果）

✔ right join：不支持。每次從lookup拿回全部lookup表數據，這個計算是不可行的也是不合理的

✔ inter join：支持。能夠轉化爲left join ＋filter，能夠支持

✔ outer join：不支持。存在right join，所以不合理

• union：支持。能夠應用在拉回局部範圍數據作窗口聚合操做。

• agg：不支持。能夠藉助union作局部窗口聚合，但沒法支持全表聚合操做。

• filter：支持。沒有shuffle，很是適合。

• map：支持。沒有shuffle，很是適合。

• project：支持。沒有shuffle，很是適合。

Join每每須要shuffle操做，是最費計算資源和時間的操做，而流上join（left join）將join操做轉化成hashjoin的隊列操做，將批量處理join的集中數據計算資源和時間平攤在數據流轉過程當中，所以在流上作left join是最划算的計算方式。

複雜的ETL並非單一算子，常常會是由多個算子組合而成，由上能夠看出單純的流式處理並不能很好的支持全部ETL複雜邏輯。那麼如何在實時Pipeline中支持更多複雜的ETL算子，而且保持時效性？這就須要「有限範圍」和「全表範圍」處理的相互轉換能力。

設想一下：流式處理平臺能夠支持流上適合的處理，而後實時落不一樣的異構庫，計算服務平臺能夠定時批量混算多源異構庫（時間設定能夠是每隔幾分鐘或更短），並將每批計算結果發送到數據總線上繼續流轉，這樣流式處理平臺和計算服務平臺就造成了計算閉環，各自作擅長的算子處理，數據在不一樣頻率觸發流轉過程當中進行各類算子轉換，這樣的架構模式理論上便可支持全部ETL複雜邏輯。

圖8 數據處理架構演化

圖8給出了數據處理架構的演化，和OLPP的一種架構模式。其中wormhole和moonbox分別是咱們開源的流式處理平臺和計算服務平臺，後面會具體介紹。

2)質量考量

上面的圖也引出了兩個主流實時數據處理架構：Lambda架構和Kappa架構，具體兩個架構的介紹網上有不少資料，這裏再也不贅述。Lambda架構和Kappa架構各有其優劣勢，但都支持數據的最終一致性，從某種程度上確保了數據質量，如何在Lambda架構和Kappa架構中取長補短，造成某種融合架構，這個話題會在新起文章中詳細探討。

固然數據質量也是個很是大的話題，只支持重跑和回灌並不能徹底解決全部數據質量問題，只是從技術架構層面給出了補數據的工程方案。關於大數據數據質量問題，咱們也會起一個新的話題討論。

3)穩定考量

這個話題涉及但不限於如下幾點，這裏簡單給出應對的思路：

• 高可用HA

整個實時Pipeline鏈路都應該選取高可用組件，確保理論上總體高可用；在數據關鍵鏈路上支持數據備份和重演機制；在業務關鍵鏈路上支持雙跑融合機制

• SLA保障

在確保集羣和實時Pipeline高可用的前提下，支持動態擴容和數據處理流程自動漂移

• 彈性反脆弱

✔ 基於規則和算法的資源彈性伸縮

✔ 支持事件觸發動做引擎的失效處理

• 監控預警

集羣設施層面，物理管道層面，數據邏輯層面的多方面監控預警能力

• 自動運維

可以捕捉並存檔缺失數據和處理異常，並具有按期自動重試機制修復問題數據

• 上游元數據變動抗性

✔上游業務庫要求兼容性元數據變動

✔ 實時Pipeline處理顯式字段

4)成本考量

這個話題涉及但不限於如下幾點，這裏簡單給出應對的思路：

• 人力成本

經過支持數據應用平民化下降人才人力成本

• 資源成本

經過支持動態資源利用下降靜態資源佔用形成的資源浪費

• 運維成本

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

• 試錯成本

經過支持敏捷開發／快速迭代下降試錯成本

5)敏捷考量

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

6)管理考量

數據管理也是一個很是大的話題，這裏咱們會重點關注兩個方面：元數據管理和數據安全管理。若是在現代數倉多數據存儲選型的環境下統一管理元數據和數據安全，是一個很是有挑戰的話題，咱們會在實時Pipeline上各個環節平臺分別考慮這兩個方面問題並給出內置支持，同時也能夠支持對接外部統一的元數據管理平臺和統一數據安全策略。

本文咱們探討了實時數據平臺RTDP的相關概念背景和架構設計方案。在架構設計方案中，咱們尤爲着重講了RTDP的定位和目標，總體設計架構，以及涉及到的具體問題和考量思路。有些話題很大，能夠後續單獨造成文章進行專題討論，但總體上，咱們給出了一整套RTDP的設計思路和規劃。在下篇技術篇中，咱們會將RTDP架構設計具體化落地化，給出推薦的技術選型和咱們的開源平臺方案，並會結合不一樣場景需求探討RTDP的不一樣模式應用。

做者：盧山巍

來源：宜信技術學院