2021 年初，在 InfoQ 編輯部策劃的全年技術趨勢展望中，我們提到大數據領域將加速擁抱「融合」（或「一體化」）演進的新方向。本質是為了降低大數據分析的技術複雜度和成本，同時滿足對性能和易用性的更高要求。如今，我們看到流行的流處理引擎 Apache Flink（下稱 Flink）沿着這個趨勢又邁出了新的一步。
1 月 8 日上午，Flink Forward Asia 2021 以線上會議的形式拉開帷幕。今年是 Flink Forward Asia（下文簡稱 FFA）落地中國的第四個年頭，也是 Flink 成為 Apache 軟件基金會頂級項目的第七年。伴隨着實時化浪潮的發展和深化，Flink 已逐步演進為流處理的領軍角色和事實標準。回顧其演進歷程，Flink 一方面持續優化其流計算核心能力，不斷提高整個行業的流計算處理標準，另一方面沿着流批一體的思路逐步推進架構改造和應用場景落地。但在這些之外，Flink 長期發展還需要一個新的突破口。
在 Flink Forward Asia 2021 的主題演講中，Apache Flink 中文社區發起人、阿里巴巴開源大數據平台負責人王峰（花名莫問）重點介紹了 Flink 在流批一體架構演進和落地方面的最新進展，並提出了 Flink 下一步的發展方向——流式數倉（Streaming Warehouse，簡稱 Streamhouse）。正如主題演講標題「Flink Next, Beyond Stream Processing」所言，Flink 要從 Stream Processing 走向 Streaming Warehouse 去覆蓋更大的場景，幫助開發者解決更多問題。而要實現流式數倉的目標，就意味着 Flink 社區要拓展適合流批一體的數據存儲，這是 Flink 今年在技術方面的一個創新，社區相關工作已經在 10 月份啟動，接下來這會作為 Flink 社區未來一年的一個重點方向來推進。
那麼，如何理解流式數倉？它想解決現有數據架構的哪些問題？為什麼 Flink 要選擇這個方向？流式數倉的實現路徑會是怎樣的？帶着這些問題，InfoQ 獨家專訪了莫問，進一步了解流式數倉背後的思考路徑。
Flink 這幾年一直在反覆強調流批一體，即：使用同一套 API、同一套開發範式來實現大數據的流計算和批計算，進而保證處理過程與結果的一致性。莫問表示，流批一體更多是一種技術理念和能力，它本身不解決用戶的任何問題，只有當它真正落到實際業務場景中，才能夠體現出開發效率和運行效率上的價值。而流式數倉可以理解為流批一體大方向下對落地解決方案的思考。
在去年的 FFA 上，我們已經看到 Flink 流批一體在天貓雙十一的落地應用，那是阿里首次在核心數據業務上真正規模化落地流批一體。如今一年過去了，Flink 流批一體在技術架構演進和落地應用兩方面都有了新進展。
技術演進層面，Flink 流批一體 API 和架構改造已經完成，在原先的流批一體 SQL 基礎上，進一步整合了 DataStream 和 DataSet 兩套 API，實現了完整的 Java 語義層面的流批一體 API，架構上做到了一套代碼可同時承接流存儲與批存儲。
在今年 10 月發布的 Flink 1.14 版本中，已經可以支持在同一個應用中混合使用有界流和無界流：Flink 現在支持對部分運行、部分結束的應用（部分算子已處理到有界輸入數據流的末端）做 Checkpoint。此外，Flink 在處理到有界數據流末端時會觸發最終 Checkpoint，以確保所有計算結果順利提交到 Sink。
而批執行模式現在支持在同一應用中混合使用 DataStream API 和 SQL/Table API（此前僅支持單獨使用 DataStream API 或 SQL/Table API）。
此外，Flink 更新了統一的 Source 和 Sink API，開始圍繞統一的 API 整合連接器生態。新增的混合 Source 可在多個存儲系統間過渡，實現諸如先從 Amazon S3 中讀取舊的數據再無縫切換到 Apache Kafka 這樣的操作。
在落地應用層面，也出現了兩個比較重要的應用場景。
第一個是基於 Flink CDC 的全增量一體化數據集成。
數據集成、不同數據源之間的數據同步對於很多團隊來說是剛需，但傳統方案往往複雜度太高且時效性不好。傳統的數據集成方案通常是離線數據集成和實時數據集成分別採用兩套技術棧，其中涉及很多數據同步工具，比如 Sqoop、DataX 等，這些工具要麼只能做全量要麼只能做增量，開發者需要自己控制全增量的切換，配合起來比較複雜。
基於 Flink 的流批一體能力和 Flink CDC，只需要寫一條 SQL，就可以做到先全量同步歷史數據，再自動斷點續傳增量數據，實現一站式數據集成。全程無需用戶判斷和干預，Flink 能自動完成批流之間的切換並保證數據的一致性。
Flink CDC Connectors 作為一個獨立的開源項目，從去年 7 月份開源以來，一直保持相當高速的發展，平均兩個月一個版本。目前 Flink CDC 版本已經更新到 2.1 版本，並完成了很多主流數據庫的適配，比如 MySQL、PostgreSQL、MongoDB、Oracle 等，更多數據庫如 TiDB、DB2 等的對接工作也在進行中。可以看到已經有越來越多企業在自己的業務場景中使用 Flink CDC，InfoQ 前不久採訪過的 XTransfer 就是其中之一。
第二個應用場景則是大數據領域最核心的數倉場景。
目前主流的實時離線一體化數倉架構通常如下圖所示。
絕大部分場景都會使用 Flink+Kafka 來做實時數據流的處理，也就是實時數倉的部分，並將最終分析結果寫入到一個在線服務層，用來展示或做進一步的分析。同時後台一定會有一個異步的離線數倉架構對實時數據作補充，每天定期運行大規模批量甚至是全量分析，或進行歷史數據的定期修正等。
但這個經典架構存在一些顯而易見的問題：首先，實時鏈路和離線鏈路使用的技術棧不同，必定會有兩套 API，那麼就需要兩套開發流程，增加了開發成本；其次，實時離線技術棧不同，無法保證數據口徑的一致性；再次，實時鏈路的中間隊列數據不利於分析。如果用戶想要分析實時鏈路中一個明細層的數據，其實非常不方便，很多用戶目前採用的辦法可能是先把這個明細層中的數據導出來，比如導到 Hive 做離線分析，但這個時效性會大幅下降，或者為了加速查詢，把數據導入到其他 OLAP 引擎中，但這又會增加系統複雜度，且數據一致性同樣很難保證。
Flink 流批一體的理念可以在上述場景下得到充分應用。在莫問看來，Flink 可以讓當前業界主流數倉架構再進階一層，實現真正端到端全鏈路的實時化分析能力，即：當數據在源頭發生變化時就能捕捉到這一變化，並支持對它做逐層分析，讓所有數據實時流動起來，並且對所有流動中的數據都可以實時查詢。再藉助 Flink 完備的流批一體能力，使用同一套 API 就可以同時支持靈活的離線分析。這樣一來，實時、離線以及交互式查詢分析、短查詢分析等，就可以統一成一整套解決方案，成為理想中的「流式數倉（Streaming Warehouse）」。
流式數倉（Streaming Warehouse）更準確地說，其實是「make data warehouse streaming」，就是讓整個數倉的數據全實時地流動起來，且是以純流的方式而不是微批（mini-batch）的方式流動。目標是實現一個具備端到端實時性的純流服務（Streaming Service），用一套 API 分析所有流動中的數據，當源頭數據發生變化，比如捕捉到在線服務的 Log 或數據庫的 Binlog 以後，就按照提前定義好的 Query 邏輯或數據處理邏輯，對數據進行分析，分析後的數據落到數倉的某一個分層，再從第一個分層向下一個分層流動，然後數倉所有分層會全部流動起來，最終流到一個在線系統里，用戶可以看到整個數倉的全實時流動效果。在這個過程中，數據是主動的，而查詢是被動的，分析由數據的變化來驅動。同時在垂直方向上，對每一個數據明細層，用戶都可以執行 Query 進行主動查詢，並且能實時獲得查詢結果。此外，它還能兼容離線分析場景，API 依然是同一套，實現真正的一體化。
目前業界還沒有這樣一個端到端全流式鏈路的成熟解決方案，雖然有純流的方案和純交互式查詢的方案，但需要用戶自己把兩套方案加起來，必然會增加系統的複雜性，如果要再把離線數倉方案也加進來，系統複雜性問題就更大了。流式數倉要做的是在實現高時效性的同時，不進一步提高系統複雜性，讓整個架構對於開發和運維人員來說都是非常簡潔的。
當然，流式數倉是終態，要達成這個目標，Flink 需要一個配套的流批一體存儲支持。其實 Flink 本身有內置的分布式 RocksDB 作為 State 存儲，但這個存儲只能解決任務內部流數據狀態的存儲問題。流式數倉需要一個計算任務之間的表存儲服務：第一個任務將數據寫進去，第二個任務就能從它實時地再讀出來，第三個任務還能對它執行用戶的 Query 分析。因此 Flink 需要再擴展出一個跟自身理念配套的存儲，從 State 存儲走出來，繼續向外走。為此，Flink 社區提出了新的 Dynamic Table Storage，即具備流表二象性的存儲方案。
Flink Dynamic Table（社區討論詳見 FLIP-188）可以理解為一套流批一體的存儲，並無縫對接 Flink SQL。原來 Flink 只能讀寫像 Kafka、HBase 這樣的外部表，現在用同一套 Flink SQL 語法就可以像原來創建源表和目標表一樣，創建一個 Dynamic Table。流式數倉的分層數據可以全部放到 Flink Dynamic Table 中，通過 Flink SQL 就能實時地串聯起整個數倉的分層，既可以對 Dynamic Table 中不同明細層的數據做實時查詢和分析，也可以對不同分層做批量 ETL 處理。
從數據結構上看，Dynamic Table 內部有兩個核心存儲組件，分別是 File Store 和 Log Store。顧名思義，Flie Store 存儲 Table 的文件存儲形式，採用經典的 LSM 架構，支持流式的更新、刪除、增加等；同時，採用開放的列存結構，支持壓縮等優化；它對應 Flink SQL 的批模式，支持全量批式讀取。而 Log Store 存儲的是 Table 的操作記錄，是一個不可變更序列，對應 Flink SQL 的流模式，可以通過 Flink SQL 訂閱 Dynamic Table 的增量變化做實時分析，目前支持插件化實現。
對 Flie Store 的寫入被封裝在內置的 Sink 中，屏蔽了寫入的複雜性。同時 Flink 的 Checkpoint 機制和 Exactly Once 機制能夠保證數據的一致性。
目前 Dynamic Table 第一個階段的實現方案已經完成，社區也在圍繞這個方向展開更多討論。根據社區的規劃，未來的終態會實現 Dynamic Table 的服務化，真正形成一套 Dynamic Table 的 Service，實現完全實時化的流批一體存儲。同時，Flink 社區也正在討論將 Dynamic Table 作為 Flink 獨立子項目運營和發布，不排除後續將其完全獨立成為流批一體通用存儲項目發展。最終，利用 Flink CDC、Flink SQL、Flink Dynamic Table 就可以構建一套完整的流式數倉，實現實時離線一體化的體驗。整個流程及效果參見以下 demo 視頻展示。
雖然整個流程初步走通，但真正要實現全實時鏈路且足夠穩定，社區還需要逐步提升實現方案的質量，這其中包括 Flink SQL 在 OLAP 交互式場景下的優化、動態表存儲性能和一致性的優化以及構建動態表服務化能力等諸多工作。流式數倉這個方向只是剛剛啟動，並有了初步嘗試，在莫問看來，設計沒有問題，但後續還需要解決一系列工程問題。這就像設計一個先進制程芯片或 ARM 架構，很多人都能設計出來，但在要保證良品率的前提下把芯片生產出來，其實是很難的。流式數倉會是接下來 Flink 在大數據分析場景下最重要的一個方向，社區也會在這個方向上大力投入。
業界原先對於 Flink 的定位更多是一個流處理器或流計算引擎，實際並非如此。莫問表示，Flink 原生也不只是計算，大家可能狹義上認為 Flink 是計算，但廣義來說，Flink 本來就有存儲。「Flink 能夠靠流計算衝出重圍，靠的就是有狀態的存儲，這是相對 Storm 來說更大的優勢。」
現在 Flink 希望更進一步，實現一個覆蓋更大範圍實時化問題的解決方案，原有的存儲就不夠用了。而外部的存儲系統或其他引擎體系跟 Flink 的目標和特性又不完全一致，無法跟 Flink 做很好的集成。比如 Flink 跟數據湖包括 Hudi、Iceberg 都做了集成，支持實時入湖、入湖實時增量分析，但這些場景仍然無法完全發揮出 Flink 全實時的優勢，因為數據湖存儲格式本質還是 Mini-Batch，Flink 在其中也會退化到 Mini-Batch 模式。這不是 Flink 最希望看到或最適合 Flink 的架構，所以它自然就需要自己再拓展出一套與 Flink 流批一體理念相配套的存儲系統。
在莫問看來，對於一套大數據計算分析引擎，如果沒有一套與其理念配套的存儲技術體系支撐，是無法提供一套極致體驗的數據分析解決方案的。這就類似於，任何優秀的算法都需要有相應的數據結構與其配套，才能以最佳效率解決問題。
為什麼說 Flink 做流式數倉更合適？這是由 Flink 的理念決定的，Flink 的核心理念是以 Streaming 優先來解決數據處理的問題，而要讓整個數倉的數據實時流動起來，Streaming 是必不可少的。在數據都流動起來之後，集合數據的流表二象性，以及 Flink 的流批一體分析能力，就可以對流動中的任何一個環節的數據進行分析，不管是短查詢的秒級分析，還是離線的 ETL 分析，Flink 都具備相應能力。莫問表示，Flink 流批一體原來受到最大的限制就是中間沒有能配套的存儲數據結構，會讓場景不好落地，只要把存儲和數據結構補上，很多流批一體的化學反應自然就會出現。
那 Flink 自建數據存儲系統，是否會對大數據生態中現有的數據存儲類項目帶來一定的衝擊呢？對此莫問解釋道，Flink 社區推出新的流批一體存儲技術，是為了更好地配合自身流批一體計算的需求，會保持存儲和數據的開放協議、開放的 API 和 SDK，後續也有計劃將此項目獨立發展。此外，Flink 也依然會積極對接業界主流存儲項目，保持對外生態的兼容和開放。
大數據生態不同組件之間的邊界正變得越來越模糊，莫問認為，當下的趨勢是從單一組件能力走向一體化解決方案。「大家其實都在順着這個趨勢走，比如你可以看到很多數據庫項目，原來是 OLTP 後來加上了 OLAP，最後都叫 HTAP，實際上就是融合了行存和列存，既支持 Serving，又支持分析，都是為了給用戶提供一套完整的數據分析體驗。」莫問進一步補充表示：「目前很多系統都開始不斷拓展邊界，從實時走向離線，或從離線走向實時，相互滲透。否則，用戶就需要自己手動去組合各種技術組件，還要面對各種複雜性，門檻越來越高。所以，一體化的融合趨勢是非常明顯的。到底誰組合誰其實沒有對錯，關鍵是能不能用一種很好的融合方式，給用戶提供最好的體驗。誰做到了，誰就能贏得最後的用戶。社區要有生命力、持續發展，僅僅把自己最擅長的領域做到極致是不夠的，還要不斷基於用戶需求和場景去創新和突破邊界，大部分用戶的需求不一定在單一能力從 95 分到 100 分的差距上。」
據莫問估計，大約還需要一年左右的時間可以形成一個相對成熟的流式數倉方案。對於已經採用 Flink 作為實時計算引擎的用戶，天然就適合去嘗試新的流式數倉方案，用戶接口完全兼容 Flink SQL。據透露，在最新的 Flink 1.15 版本就會發出第一個 Preview 版本，正在使用 Flink 的用戶都可以先試一試。莫問表示，基於 Flink 的流式數倉剛剛啟動，技術方案還需要進一步迭代，距離成熟還需要一定時間打磨，希望能有更多企業和開發者帶着自己的需求參與進來一起建設，這才是開源社區的價值。
大數據開源生態組件眾多、架構複雜度高的問題已經被詬病了很多年，如今業界似乎已經在一定程度上達成共識，即通過融合、一體化來推動數據架構往簡化的方向演進，儘管不同企業有不同的說法和實現路徑。
在莫問看來，開源生態百花齊放很正常，每個技術社區都有自己擅長的領域，但真正要解決業務場景問題的話，還是需要一套一站式的解決方案，才能為用戶提供簡單易用的體驗。因此他也認同總體趨勢會往整合和融合的方向走，但可能性並不唯一，未來有可能專門有一個系統來負責整合所有組件，也有可能每個系統都逐漸演變成一體化。哪一種可能性才是終局，或許只能等時間給我們答案了。
今日好文推薦
阿里正式開源自研 XQUIC：已服務手淘上億用戶，網絡耗時降低超 20%
所謂「現代Web開發」，都是些什麼妖魔鬼怪？
解讀中間件的2021：被雲原生重塑之後，選型更難了
解讀操作系統的2021：觸到了創新的天花板，卻站在巨變的前夜
點個在看少個 bug👇
留言列表