《實時大數(shù)據(jù)平臺規(guī)劃設(shè)計方案》

1、現(xiàn)代數(shù)倉由傳統(tǒng)數(shù)倉發(fā)展而來， 對比傳統(tǒng)數(shù)倉，現(xiàn)代數(shù)倉既有與其相同之1）和現(xiàn)代數(shù)倉（圖處，也有諸多發(fā)展點。首先我們看一下傳統(tǒng)數(shù)倉（圖2）的模塊架構(gòu)：圖 1 傳統(tǒng)數(shù)倉傳統(tǒng)數(shù)倉大家都很熟悉，這里不做過多介紹，一般來說，傳統(tǒng)數(shù)倉只能支持 T1 天時效延遲的數(shù)據(jù)處理， 數(shù)據(jù)處理過程以 ETL 報表為主。現(xiàn)代數(shù)倉建立在傳統(tǒng)數(shù)倉之上，同時增加了更多樣化數(shù)據(jù)源的導(dǎo)入存儲，更多樣化數(shù)據(jù)處理方式和時效（支持 T0 天時效），更多樣化數(shù)據(jù)使用方式和更多樣化數(shù)據(jù)終端服務(wù)?，F(xiàn)代數(shù)倉是個很大的話題， 在此我們以概念模塊的方式來展現(xiàn)其新的特性能力。首先我們先看一下圖 3 中 Melissa Coates 的整理總結(jié)：在圖

2、3 Melissa Coates 的總結(jié)中我們可以得出，現(xiàn)代數(shù)倉之所以 “現(xiàn)代”，是因為它有多平臺架構(gòu)、數(shù)據(jù)虛擬化、數(shù)據(jù)的近實時分析、敏捷交付方式等等一系列特性。在借鑒 Melissa Coates 關(guān)于現(xiàn)代數(shù)倉總結(jié)的基礎(chǔ)上，加以自己的理解，我們也在此總結(jié)提取了現(xiàn)代數(shù)倉的幾個重要能力，分別是：數(shù)據(jù)實時化（實時同步和流式處理能力）數(shù)據(jù)虛擬化（虛擬混算和統(tǒng)一服務(wù)能力）1)數(shù)據(jù)實時化（實時同步和流式處理能力）數(shù)據(jù)實時化，是指數(shù)據(jù)從產(chǎn)生（更新至業(yè)務(wù)數(shù)據(jù)庫或日志） 據(jù)報表、儀表板、分析、挖掘、數(shù)據(jù)應(yīng)用等） ，支持毫秒級秒級分鐘級延遲（嚴格來說，秒級分鐘級屬于準實時，這里統(tǒng)一稱為實時） 。這里涉及到如何將

3、數(shù)據(jù)實時的從數(shù)據(jù)源中抽取出來； 如何實時流轉(zhuǎn)；為了提高時效性，降低端到端延遲， 還需要有能力支持在流轉(zhuǎn)過程中進行計算處理；如何實時落庫；如何實時提供后續(xù)消費使用。實時同步是指多源到多目標的端到端同步，流式處理指在流上進行邏輯轉(zhuǎn)換處理。但是我們要知道， 不是所有數(shù)據(jù)處理計算都可以在流上進行， 而我們的目 這里就需要和其他數(shù)據(jù)流轉(zhuǎn)處理方式配合進行，后面我們會進一步討論。數(shù)據(jù)虛擬化，是指對于用戶或用戶程序而言， 面對的是統(tǒng)一的交互方式和查詢語言，而無需關(guān)注數(shù)據(jù)實際所在的物理庫和方言及交互方式 （異構(gòu)系統(tǒng)異構(gòu)查詢語言） 的一種技術(shù)。用戶的使用體驗是面對一個單一數(shù)據(jù)庫進行操作，但其實這是一個虛擬化的數(shù)據(jù)

4、庫， 數(shù)據(jù)本身并不存放于虛擬數(shù)據(jù)庫中。虛擬混算指的是虛擬化技術(shù)可以支持異構(gòu)系統(tǒng)數(shù)據(jù)透明混算的能力， 統(tǒng)一服務(wù)指對于用戶提供統(tǒng)一的服務(wù)接口和方式。（圖 1-4 均選自“Designing a Modern Data Warehouse + Data Lake” -Melissa Coates, Solution Architect, BlueGranite ）3)數(shù)據(jù)平民化（可視化和自助配置能力）普通用戶（無專業(yè)大數(shù)據(jù)技術(shù)背景的數(shù)據(jù)從業(yè)人員），可以通過可視化的 SQL 方式使用數(shù)據(jù)完成自己的工作和需求，并無需關(guān)注底層技術(shù)層面問題 （通過計算資源云化， 數(shù)據(jù)虛擬化等技術(shù)）。以上是我們對數(shù)據(jù)平民化的

5、解讀。文中提到技術(shù)層面如何支持數(shù)據(jù)平民化，并給出了幾個例子：Datavirtualization software ，Data federation software ，Cloud storage ，Self-service BI applications 等。其中數(shù)據(jù)虛擬化和數(shù)據(jù)聯(lián)邦本質(zhì)上是類似技術(shù)方案，并且提到了自助 BI 這個概念。4)數(shù)據(jù)協(xié)作化（多租戶和分工協(xié)作能力）技術(shù)人員應(yīng)該多了解業(yè)務(wù)， 還是業(yè)務(wù)人員應(yīng)該多了解技術(shù)？這一直是企業(yè)內(nèi)爭論不休的問題。而我們相信現(xiàn)代 BI 是一個可以深度協(xié)作的過程，技術(shù)人員和業(yè)務(wù)人員可以在同一個平臺上， 發(fā)揮各自所長，分工協(xié)作完成日常 BI 活動。這就對

6、平臺的多租戶能力和分工協(xié)作能力提出了較高要求，一個好的現(xiàn)代數(shù)據(jù)平臺是可以支持更好的數(shù)據(jù)協(xié)作化能力的。我們希望可以設(shè)計出一個現(xiàn)代實時數(shù)據(jù)平臺， 滿足以上提到的實時化、 虛擬化、平民化、協(xié)作化等能力，成為現(xiàn)代數(shù)倉的一個非常重要且必不可少的組成部分。1.2 從典型數(shù)據(jù)處理角度看待實時數(shù)據(jù)處理典型的數(shù)據(jù)處理，可分為 OLTP, OLAP, Streaming, Adhoc, MachineLearning 等。這里給出 OLTP 和 OLAP 的定義和對比：從某種角度來說， OLTP 活動主要發(fā)生在業(yè)務(wù)交易庫端， OLAP 活動主要發(fā)生在數(shù)據(jù)分析庫端。 OLTP 庫流轉(zhuǎn)到 OLAP 庫呢？如果這個數(shù)據(jù)

7、流轉(zhuǎn)時效性要求很高， 傳統(tǒng)的 T1 批量 ETL 方式就無法滿足了。我們將 OLTP 到 OLAP 的流轉(zhuǎn)過程叫 Data Pipeline （數(shù)據(jù)處理管道），它是指數(shù)據(jù)的生產(chǎn)端到消費端之間的所有流轉(zhuǎn)和處理環(huán)節(jié)， 包括了數(shù)據(jù)抽取、數(shù)據(jù)同步、流上處理、數(shù)據(jù)存儲、數(shù)據(jù)查詢等。這里可能會發(fā)生很復(fù)Star Schema 的轉(zhuǎn)換，明細表到匯總表的轉(zhuǎn)換，多實體表聯(lián)合成寬表等）。如何支持實時性很高的 Pipeline 處理能力，就成了一個有挑戰(zhàn)性的話題，我們將這個話題描述為 “在線管道處理 ”(OLPP, Online Pipeline Processing) 問題。因此，本文所討論的實時數(shù)據(jù)平臺， 希望可

8、以從數(shù)據(jù)處理角度解決 OLPP問題，成為 OLTP 到 OLAP 實時流轉(zhuǎn)缺失的課題的解決方案。下面，我們會探討從架構(gòu)層面，如何設(shè)計這樣一個實時數(shù)據(jù)平臺。二、架構(gòu)設(shè)計方案2.1 定位和目標實時數(shù)據(jù)平臺（ Real-time Data Platform ，以下簡稱 RTDP），旨在提供數(shù)據(jù)端到端實時處理能力（毫秒級秒級分鐘級延遲），可以對接多數(shù)據(jù)源進行實時數(shù)據(jù)抽取， 可以為多數(shù)據(jù)應(yīng)用場景提供實時數(shù)據(jù)消費。 作為現(xiàn)代數(shù)倉的一部分， RTDP 可以支持實時化、虛擬化、平民化、協(xié)作化等能力，讓實時數(shù)據(jù)應(yīng)用開發(fā)門檻更低、迭代更快、質(zhì)量更好、運行更穩(wěn)、運維更簡、能力更強。概念模塊架構(gòu)，是實時數(shù)據(jù)處理 Pi

9、peline 的概念層的分層架構(gòu)和能力梳 更像是需求模塊。圖 6 給出了 RTDP的整體概念模塊架構(gòu)，具體每個模塊含義都可自解釋，這里不再詳述。圖 6 RTDP 整體概念模塊架構(gòu)下面我們會根據(jù)上圖做進一步設(shè)計討論，給出從技術(shù)層面的高階設(shè)計思路。由圖 7 可以看出，我們針對概念模塊架構(gòu)的四個層面進行了統(tǒng)一化抽象：統(tǒng)一數(shù)據(jù)采集平臺統(tǒng)一流式處理平臺 意味著用戶可以選擇不同的存儲層以滿足具體項 目的需 要，而又不破 壞整體 架構(gòu)設(shè)計，用 戶甚至 可以在Pipeline 中同時選擇多個異構(gòu)存儲提供支持。 下面分別對四個抽象層進行解讀。1)統(tǒng)一數(shù)據(jù)采集平臺統(tǒng)一數(shù)據(jù)采集平臺， 既可以支持不同數(shù)據(jù)源的全量抽取

10、， 也可以支持增強 以減少對業(yè)務(wù)庫的讀取壓力。 平臺還可以對抽取的數(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, SparkStreaming 的 Stream 等），因此可以通過物理媒介支持多消息流并行，和消息流的自由漂移

11、。 平臺也支持多租戶體系， 和配置化簡單處理清洗能力。2)統(tǒng)一流式處理平臺UMS 協(xié)議消息，也可以支持普通 JSON 格式消息。同時，平臺還支持以下能力：支持可視化配置化 SQL 化方式降低流式邏輯開發(fā)部署管理支持配置化方式冪等落入多個異構(gòu)目標庫以確保數(shù)據(jù)的最終一致性支持多租戶體系，做到項目級的計算資源表資源用戶資源等隔離3)統(tǒng)一計算服務(wù)平臺統(tǒng)一計算服務(wù)平臺， 是一種數(shù)據(jù)虛擬化數(shù)據(jù)聯(lián)邦的實現(xiàn)。 平臺對內(nèi)支持多異構(gòu)數(shù)據(jù)源的下推計算和拉取混算，也支持對外的統(tǒng)一服務(wù)接口（JDBCREST）和統(tǒng)一查詢語言（ SQL）。由于平臺可以統(tǒng)一收口服計數(shù)據(jù)安全策略等模塊。平臺也支持多租戶體系。4)統(tǒng)一數(shù)據(jù)可視化

12、平臺統(tǒng)一數(shù)據(jù)可視化平臺， 加上多租戶和完善的用戶體系權(quán)限體系， 可以支持跨部門數(shù)據(jù)從業(yè)人員的分工協(xié)作能力， 讓用戶在可視化環(huán)境下， 通過緊密合作的方式，更能發(fā)揮各自所長來完成數(shù)據(jù)平臺最后十公里的應(yīng)用。以上是基于整體模塊架構(gòu)之上， 進行了統(tǒng)一抽象設(shè)計， 并開放存儲選項以提高靈活性和需求適配性。這樣的 RTDP 平臺設(shè)計，體現(xiàn)了現(xiàn)代數(shù)倉的OLPP2.3 具體問題和考量思路下面我們會基于 RTDP 的整體架構(gòu)設(shè)計，分別從不同維度討論這個設(shè)計需要面對的問題考量和解決思路。1)功能考量功能考量主要討論這樣一個問題：實時 Pipeline 能否處理所有 ETL 復(fù)雜邏輯？我們知道，對于 StormFlin

13、k 這樣的流式計算引擎，是按每條處理的；對于 Spark Streaming 流式計算引擎，按每個 mini-batch 處理；而對于離線跑批任務(wù)來說， 是按每天數(shù)據(jù)進行處理的。 因此處理范圍是數(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ù)范圍維度的不同

14、，流式處理單位為 “有限范圍 ”，批量處理單位為 “全表范圍”。“全表范圍 ”數(shù)據(jù)是可以支持各種 SQL 算子的，而 “有限范圍 ”數(shù)據(jù)只能支持部分 SQL 算子，具體支持情況如下：join：left join ：支持。 “限制范圍 ”可以 left join 外部 lookup 表（通過下推，類似 hashjoin 效果） right join：不支持。每次從 lookup 拿回所有 lookup 表數(shù)據(jù)，這個計算是不可行的也是不合理的 inter join ：支持?？梢赞D(zhuǎn)化為 left join filter，可以支持 outer join ：不支持。存在 right join ，因此不合

15、理union：支持?？梢詰?yīng)用在拉回局部范圍數(shù)據(jù)做窗口聚合操作。agg：不支持?？梢越柚?union 做局部窗口聚合，但無法支持全表聚合操作。Join 往往需要 shuffle 操作，是最費計算資源和時間的操作，而流上 join（left join）將 join 操作轉(zhuǎn)化成 hashjoin 的隊列操作，將批量處理 join 的left join復(fù)雜的 ETL 并不是單一算子，經(jīng)常會是由多個算子組合而成，由上可以看出單純的流式處理并不能很好的支持所有 ETL 復(fù)雜邏輯。那么如何在實時 Pipeline 中支持更多復(fù)雜的 ETL 算子，并且保持時效性？這就需要“有限范圍 ”和“全表范圍 ”處理的相

16、互轉(zhuǎn)換能力。設(shè)想一下： 流式處理平臺可以支持流上適合的處理，然后實時落不同的異構(gòu)庫，計算服務(wù)平臺可以定時批量混算多源異構(gòu)庫 （時間設(shè)定可以是每隔幾分鐘或更短），并將每批計算結(jié)果發(fā)送到數(shù)據(jù)總線上繼續(xù)流轉(zhuǎn)，這樣流式處理平臺和計算服務(wù)平臺就形成了計算閉環(huán)，各自做擅長的算子處 這樣的架構(gòu)模式理論上即可支持所有 ETL 復(fù)雜邏輯。圖 8 數(shù)據(jù)處理架構(gòu)演化圖 8 給出了數(shù)據(jù)處 理架構(gòu)的演化，和 OLPP 的一種架構(gòu)模 式。其中wormhole 和 moonbox 分別是我們開源的流式處理平臺和計算服務(wù)平臺，后面會具體介紹。2)質(zhì)量考量上面的圖也引出了兩個主流實時數(shù)據(jù)處理架構(gòu)： Lambda 架構(gòu)和 Kap

17、pa架構(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ì)量問題， 只是從技術(shù)架構(gòu)層面給出了補數(shù)據(jù)的工程方案。 關(guān)于大數(shù)據(jù)數(shù)據(jù)質(zhì)量問題，我們也會起一個新的話題討論。3)穩(wěn)定考量這個話題涉及但不限于以下幾點，這里簡單給出應(yīng)對的思路：高可用 HA整個實時 Pipeline 鏈路都應(yīng)該選取高可用組件，確保理論上整體高可用；在數(shù)據(jù)關(guān)鍵鏈路上支持數(shù)據(jù)備份和重演機制； 在業(yè)務(wù)關(guān)鍵鏈路上支持雙跑融合機制SLA 保障在確保集群和實時 Pipeline 高可用的前提下，支持動態(tài)擴容和數(shù)據(jù)處理流程自動漂移彈性反脆弱 基于規(guī)則和算法的資源彈性伸縮 支持事件觸發(fā)動作引擎的失效處理監(jiān)控預(yù)警集群設(shè)施層面，物理管道層面，數(shù)據(jù)邏輯層面的多方面監(jiān)控預(yù)警能力自動運維能夠捕捉并存檔缺失數(shù)據(jù)和處理異常， 并具備定期自動重試機制修復(fù)問題數(shù)據(jù)上游元數(shù)據(jù)變更抗性上游業(yè)務(wù)庫要求兼容性元數(shù)據(jù)