​

一、關於流批一體資料倉庫

流批一體是一種架構思想，這種思想說的是同一個業務，使用同一個sql邏輯，在既可以滿足流處理計算同時也可以滿足批處理任務的計算。

從效率層面來說，批處理只能以t+1的形式呈現業務資料，流處理只能以t+0的形式呈現業務資料，當二者獨立時企業需要執行兩套程式碼，開發、運維、人力成本高，呈現週期長。而流批一體則使用一套程式碼呈現兩套業務資料，開發、運維成本降低一半，實效性顯著提升。

那麼，什麼又是流批一體資料倉庫呢？簡單點說，它是將異構源的資料使用同一套計算引擎並結合資料倉庫理論所特有的資料儲存架構完成實時、離線分析業務的資料集合。

該資料集合具以下特點：

面向主題：資料倉庫按照一定主題域組織資料；

易於整合：消除源資料中的不一致性，保證企業全域性資訊的一致性；

相對穩定：集合中資料長期保留，只需定期載入、重新整理；

預測趨勢：資料中存放歷史資訊，可對企業發展歷程和未來趨勢做出定量分析和預測。

二、數棧在流批一體數倉上的演進

隨著客戶體量增大，客戶需求逐步增加，面對PB級別的批資料和流資料的處理需求，數棧技術團隊面臨越來越多的挑戰，在這個過程中逐步完善了數棧數倉架構體系。從2017年的基於傳統架構的批處理經過4年迭代到基於混合架構的流批一體數倉，如圖：

​

數棧流批一體架構混合數倉演進過程示意圖

1. 基於傳統架構的批處理

網際網路誕生之初雖然資料量暴增，單日事實表條數達千萬級別，但客戶需求場景更多是“t+1”形式，只需對當日、當週、當月資料進行分析，這些訴求僅離線分析就可滿足。

恰逢hadoop生態剛剛興起之時，數棧技術團隊基於資料暴增儲存緊張的困境搭載Hadoop生態鏈，將資料週期性匯入HDFS，利用Hadoop平臺Hive做資料倉庫就可實現對HDFS上的海量資料集進行離線分析。

這一階段其實與網際網路本質架構沒有過多變化，仍是將資料週期性裝載然後分析，只是使用的技術由經典的數倉工具轉型到了大資料工具。

2. 基於Lambda架構的流批獨立

隨著網路、通訊技術發展，“隔日達”的資料已不能滿足客戶的需求場景，他們更期待實時資料呈現，這樣無論是在金融、證券交易還是零售、港口的實時監控預警等場景下，決策者都可以第一時間做出有利判斷，提升效率減少損失。

為應對這種變化，數棧技術團隊結合當時主流大資料處理技術，在原有的HIVE數倉上，增加了當時最先進的流批一體計算引擎Spark來加快離線計算效能。同時在原有的離線大資料架構上，增加了一條基於Kafka儲存以及Flink計算引擎的流處理鏈路用於完成實時性要求較高的指標計算。

雖然使用Spark和Flink計算引擎滿足了客戶對於實時資料的場景呈現，但由於Spark雖然理念上是流批一體但本質上還是基於批來實現流，在實效上仍存在一定的硬傷。而同期的Flink計算引擎並不完善，數棧技術團隊於是對Flink功能進行了一定的擴充套件。

在此過程中同步孵化出了可以完成更多資料來源同步的FlinkX和可以通過Sql對更多的資料來源進行實時計算並寫入的FlinkStreamSql。（取之開源，饋之開源。數棧技術團隊已將它們分享到了Github上，有需要的同學可以點原讀原文檢視。）

這一階段數棧技術團隊通過自研的FlinkX和FlinkStreamSql，在原有的離線鏈路上新增了流計算鏈路用於實時資料分析，完成了從傳統大資料架構到Lambda架構的轉變。

Lambda架構的核心思想是將業務進行拆分，實時性要求高的業務走實時計算方案，實時性要求低的業務走離線計算方案，最後由資料服務層對全部資料進行分析彙總供下游使用。

​

Lambda架構流批獨立處理流程圖

3. 基於Kappa架構的實時處理

Lambda架構的搭載基本滿足了客戶對於實時資料的訴求，大量客戶通過數棧DTinsight實現資料賦能生產任務的需求，在每日數以萬計的資料量下，數棧DTinsight也能保持穩定的執行，為客戶在資料驅動業務上提供了強有力的後盾。

雖然Lambda架構滿足了客戶在業務上對於實時性的需求，但隨著企業發展業務量也在逐步增加，導致開發與運維成本逐步增加。此時Flink流處理技術也逐步成熟，Flink Exactly-Once和狀態計算已完全可以保證計算最終結果的準確性，因此數棧技術團隊開始關注在Lambda架構的基礎上如何做出調整。

LinkedIn的前首席工程師傑伊·克雷普斯（Jay Kreps）曾針對Lambda架構提出過一個改進觀點：改進Lambda架構中的Speed Layer，使它既能夠進行實時資料處理，同時也有能力在業務邏輯更新的情況下重新處理以前處理過的歷史資料。

受到Kreps的啟發，數棧團隊推薦實時業務較多的客戶將Kafka的資料日誌保留日期，當流任務發生了程式碼變動或者需要對上游進行回溯計算時，只需要保持原來的Job N不動，然後再啟動一個作業Job N+1，指定歷史資料的offset進行計算並寫入到一張新的N+1表中，當Job N+1的計算進度趕上Job的進度後，可以將原來的Job N任務替換成Job N+1，下游的業務程式只需要根據Job N+1生成的表進行分析或者展示。這樣就可以將離線鏈路層去掉，減少客戶額外開發及維護程式碼的工作量，同時統一了業務的計算口徑。

Lambda架構的的缺點在於需要維護兩個複雜的分散式系統中產生相同結果的程式碼，而通過增加並行度以及重播歷史資料的方式去重新處理實時資料可以有效的代替離線資料處理系統。這樣架構既簡單也避免了維護兩套系統程式碼還需要保持結果一致的問題。

​

Kappa架構實時數倉流程圖

4. 基於Kappa+Lambda混合架構的流批一體數倉

通過Lambda架構和Kappa架構，數棧可以解決大部分企業面臨的實時場景和開發運維需求，但也有些企業對於實時業務需求較高就會發生因極端資料亂序導致實時計算資料不準確，那麼這個時候流任務就面臨著資料質量上的問題。

針對於這種情況數棧技術團隊結合Kappa架構和Lambda架構的優勢，通過Labmda架構中離線鏈路對實時鏈路產出資料週期性校訂，同時結合FlinkX核心支援流批一體的特性，在計算層基於FlinkX計算引擎來統一完成整個鏈路中計算任務，以此來保證資料的最終一致性。

三、數棧流批一體核心引擎FlinkX技術解讀

FlinkX是一款基於Flink的流批統一的資料同步以及SQL計算工具。既可以採集靜態的資料，比如MySQL，HDFS中的業務資料，也可以採集實時變化的資料，比如MySQL、 Binlog、Kafka等。在FlinkX1.12中，也會將FlinkStreamSql融合其中，使得FlinkX1.12既能通過同步任務採集靜態、動態的資料，又能通過SQL任務對採集後的資料根據業務時效性進行流批處理。

在數棧中，FlinkX的流批一體的實現是體現在資料採集層以及資料計算層。

1. 資料採集層

從資料的時態來講，可以將資料分為實時資料和離線資料。比如像Kafka、EMQ這類高吞吐量的訊息中介軟體它們通常持有的是源源不斷的資料，所以可以通過FlinkX的實時採集任務對資料進行實時的落庫，以便後續的任務進行近實時、準實時的業務計算。像Mysql、Oracle這類OLTP資料庫通常是持有的歷史的事務資料，這類資料都是以天、月為時間單位進行儲存與計算，因此可以通過FlinkX的離線同步任務將這類資料間隔性增量或者全量同步到我們的OLAP數倉或者資料湖中，然後根據各類業務指標對資料進行分層以及跑批分析。

另外，除了將資料採集到儲存層，還會根據資料治理中定義的資料規範並結合數倉規範，通過FlinkX的同步任務完成對資料的清洗、轉換以及維度補全，以此提高資料的有效性以及業務計算的準確性。

2. 資料計算層

當資料被採集到指定的儲存層後，會結合儲存型別以及業務時效性對資料進行常規的業務計算。FlinkX Sql能支援流批計算的能力來源於Flink核心在1.12版本中對元資料的統一管理以及在DataStream API上支援批執行模式，這樣增強了作業的可複用性和可維護性，使得FlinkX 作業可以在流和批兩種執行模式之間自由進行切換並只需要維護一套程式碼，無需重新寫任何程式碼。而且，相比於開源的Flink，FlinkX 1.12 不僅提供了更多的Source以及Sink來支援對各類資料來源的實時以及離線計算還實現了髒資料管理外掛，讓客戶在ETL階段針對錯誤不合規的資料能夠由感知以及容錯處理能力。

​

FlinkX在數棧中實現流批一體流程圖

3. 數棧流批一體在數倉上的實踐

下面結合架構圖場景講述下數棧流批一體的做法。

​

場景：股票交易中K線有分時圖、日線圖、周線圖等之分，使用者股票交易完成後需要在K線上顯示買賣點和成交金額。

數棧未實現流批一體處理方式：

對於上面這個場景數棧未實現流批一體前的做法是分時圖的買賣點會採用Flink計算，日K、周K等的買賣點通過配置週期Spark任務進行計算，即經典的Lambda架構，這種架構的痛點是比較明顯的，維護兩套程式碼開發效率低、兩套計算引擎成本高、資料口徑不一致。

數棧實現流批一體後處理方式：

在數棧平臺先選擇建立實時採集和資料同步任務將業務庫資料採集到Kafka和Iceberg，即數倉的ODS層。實時數倉和離線數倉從ODS到DWD層資料清洗和資料打寬的處理邏輯是一樣的，表定義結構也是保持一致的，所以這一步只需要實現一套Flink SQL數棧平臺會自動翻譯成Flink Stream和Flink Batch任務即可用於實時數倉又可以用於離線數倉。實時數倉和離線數倉DWS層分別存放分時圖買賣點資訊和日K、周K等資料，兩邊處理邏輯不同所以在這一層需要根據業務開發兩套SQL, Stream Flink SQL對接實時數倉DWD層資料實時計算分時圖買賣點，Batch Flink SQL對接離線數倉DWD層資料週期排程計算日K、周K等買賣點資料。應用層服務直接從DWS層獲取買賣點資料進行展示。

通過例項我們可以看到數棧選擇了Iceberg作為流批一體的儲存層，原因如下：

1. Iceberg儲存的是原始資料，資料結構可以多樣化；

2. Iceberg支援多種計算模型，是一個通用化設計的Table Format，完美地解耦了計算引擎和底下的儲存系統；

3. Iceberg底層儲存支援靈活，一般用 S3、OSS、HDFS 這種廉價的分散式檔案系統，採用特定的檔案格式和快取就可以對應場景的資料分析需求；

4. Iceberg專案背後的社群資源非常豐富，在國內外已經有不少大公司將海量的資料跑在Iceberg上；

5. Iceberg儲存全量資料，當流計算任務有重跑歷史資料的需求時可從Iceberg讀取資料然後無縫切換到Kafka即可。

四、流批一體為企業賦能

隨著大資料領域不斷髮展，企業對於業務場景的訴求從離線的滿足到高實時性的要求，數棧產品也在這一過程中進行著不斷的迭代升級，為企業在提升資料計算結果質量，提升企業業務研發效率，降低企業維護成本上提供了有力幫助。

1. 提升資料計算結果質量

高質量、高準確度的資料有利於企業做優秀的決策，數棧基於混合架構的流批一體數倉將計算引擎進行了統一，解決了不同引擎兩套程式碼之間的SQL邏輯不能複用問題，讓資料在一致性和質量上得到了保障。

2. 提升企業業務研發效率

從業務開發到上線，業務開發人員只需要針對業務開發一套SQL任務，隨後根據業務延時標準在流批計算之間進行靈活切換即可。應用端開發人員也只需要針對業務拼接一套SQL封裝邏輯。

3. 提升企業資源利用率，降低維護成本

企業使用者的實時、離線業務只需要執行在同一套計算引擎上即可。無需為執行實時、離線業務的不同計算引擎分別購置高配的硬體資源。而針對業務變更，開發人員也只需要修改對應的SQL任務，無需考慮實時、離線任務分別修改。

五、未來規劃

雖然FlinkX SQL在一定程度提升了流批計算的能力，但批處理在實效上還有待提高，下一步數棧技術團隊將從Flink原始碼層面去對運算元以及Task進行一些優化，提高批處理層面計算效率降低企業時間成本。同時進一步統一資料來源中元資料標準，讓企業在資料治理過程中所涉及的資料字典、資料血緣、資料質量、許可權管理等模組在後續使用層面可快速被響應，減少企業管理成本。

數棧流批一體架構，通過迭代已實現實時數倉+OLAP場景結合，只需一套程式碼就可進行多個計算處理模式，不僅滿足了企業低延遲、高時效的業務驅動需求，同時也降低了企業開發、運維、人工成本。當然這只是流批一體探索的第一步，數棧技術團隊將繼續在資料儲存層面進行深挖，將資料倉庫的便捷管理、高質量資料特性與資料湖的可探索、高靈活性相融合，完成數棧在資料倉庫到湖倉一體的轉變，實現對未知資料先統一儲存再靈活探索的能力，在資料架構層面更進一步。

​