作者 | 蔡芳芳
採訪嘉賓 | 王峰（莫問）
維基百科的 “Apache Flink” 詞條下，有這麼一句描述：“Flink 並不提供自己的資料儲存系統，但為 Amazon Kinesis、Apache Kafka、Alluxio、HDFS、Apache Cassandra 和 Elasticsearch 等系統提供了資料來源和接收器”，很快，這句話的前半句或許將不再適用。
完整視訊：https://developer.aliyun.com/...
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
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 視訊展示。
https://www.bilibili.com/vide...
雖然整個流程初步走通，但真正要實現全實時鏈路且足夠穩定，社群還需要逐步提升實現方案的質量，這其中包括 Flink SQL 在 OLAP 互動式場景下的優化、動態表儲存效能和一致性的優化以及構建動態表服務化能力等諸多工作。流式數倉這個方向只是剛剛啟動，並有了初步嘗試，在莫問看來，設計沒有問題，但後續還需要解決一系列工程問題。這就像設計一個先進製程晶片或 ARM 架構，很多人都能設計出來，但在要保證良品率的前提下把晶片生產出來，其實是很難的。流式數倉會是接下來 Flink 在大資料分析場景下最重要的一個方向，社群也會在這個方向上大力投入。
Flink 不止於計算
在大資料實時化轉型大趨勢之下，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 的流式數倉剛剛啟動，技術方案還需要進一步迭代，距離成熟還需要一定時間打磨，希望能有更多企業和開發者帶著自己的需求參與進來一起建設，這才是開源社群的價值。
結語
大資料開源生態元件眾多、架構複雜度高的問題已經被詬病了很多年，如今業界似乎已經在一定程度上達成共識，即通過融合、一體化來推動資料架構往簡化的方向演進，儘管不同企業有不同的說法和實現路徑。
在莫問看來，開源生態百花齊放很正常，每個技術社群都有自己擅長的領域，但真正要解決業務場景問題的話，還是需要一套一站式的解決方案，才能為使用者提供簡單易用的體驗。因此他也認同總體趨勢會往整合和融合的方向走，但可能性並不唯一，未來有可能專門有一個系統來負責整合所有元件，也有可能每個系統都逐漸演變成一體化。哪一種可能性才是終局，或許只能等時間給我們答案了。
FFA 2021 視訊回放 & 演講 PDF 獲取
關注「Apache Flink」公眾號，回覆 FFA2021
更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間獲取最新技術文章和社群動態，請關注公眾號～
