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

一、相關概念背景

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.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的不同模式應用。

作者：盧山巍

來源：宜信技術