本文整理自宋辛童（阿里云智能高級技術專家）老師，梅源（阿里云智能資深技術專家）、李麟（阿里云智能高級技術專家）老師，在 Flink Forward Asia 2024 主會場的分享。三位老師共同為大家?guī)磉@場關于 Flink 2.0 的技術分享。主要分為以下幾個內(nèi)容：

一、Streaming

二、Stream-Batch Unification

三、Streaming Lakehouse

四、AI

宋辛童（阿里云智能高級技術專家）：Apache Flink 于 2014 年被捐贈給 Apache 基金會，其第一個正式版本 Flink 1.0 則于 2016 年 3 月發(fā)布。從 Flink 1.0 發(fā)布以來，這些年 Flink 一直以小版本的形式進行技術演進，例如 1.16、1.17 等。然而，到了去年，我們意識到隨著 Flink 技術的發(fā)展和迭代，會面臨越來越多的新挑戰(zhàn)和問題。為了有效解決這些問題，我們需要對 Flink 的現(xiàn)有技術架構進行系統(tǒng)性的大規(guī)模升級。因此，去年 4 月，我們在 Apache Flink 社區(qū)開始籌備 Flink 2.0 版本的計劃。

整個籌備過程經(jīng)歷了相當長的時間，經(jīng)過 Flink 1.18、1.19、1.20 三個小版本的迭代，終于在不久前的 10 月，在柏林的 Flink Forward 會議上，我們發(fā)布了 Flink 2.0 的預覽版本。正式的 Flink 2.0 版本預計將在明年年初與大家見面。Flink 2.0 的籌備過程耗時接近兩年，從去年的 4 月到明年年初發(fā)布，其原因除了技術架構升級的復雜性，還有就是我們將在這次大版本升級中引入一系列非兼容性的改動，希望為用戶和生態(tài)合作伙伴留出足夠的時間來適應這些改動。

這些改動包括移除一些舊的、過時的 API，例如 DataSet API、Scala DataStream API 和舊的 Connector API 等等。同時，我們對現(xiàn)有的 API，如 DataStream API、Table API、REST API 和 Flink/SQL Client，也進行了小幅度的更新。

在配置方面，舊的 flink-conf.yaml 配置文件被徹底移除，新的 config.yaml 配置文件全面對接標準的 YAML 生態(tài)。此外我們也清理了一系列陳舊的配置項。需要提醒大家的是，F(xiàn)link 1.X 和 Flink 2.0 之間無法保證 100% 的 Checkpoint (CP) 和 Savepoint (SP) 狀態(tài)兼容性。這主要是因為 Flink 對其序列化框架進行了多項升級和改造。不過大家不用擔心，F(xiàn)link 社區(qū)將準備相應的遷移工具，來幫助用戶進行非兼容性狀態(tài)的遷移。此外，Java 8 的支持將不再提供。Per-job 部署模式也將在 2.0 版本中移除，用戶可以更廣泛地采用 Application 的部署模式。

在這里，我們提到的一個重要改動是移除了陳舊的 Connector API。這意味著，如果現(xiàn)有的 Connector 使用了這些老的 API，就需要經(jīng)過適配過程才能在 Flink 2.0 中繼續(xù)使用。Flink 社區(qū)計劃在 Flink 2.0 發(fā)布時，首批支持幾個最常見的 Connector，如 Kafka、Paimon、JDBC 和 Elasticsearch。后續(xù)，我們將陸續(xù)支持其他 Connector。我們也非常歡迎社區(qū)的開發(fā)者們加入我們的行列，共同加速 Flink 2.0 Connector 生態(tài)的適配過程。

前面我們已經(jīng)介紹了 Flink 2.0 版本籌備的進程以及非兼容性的改動。接下來，我們將主要介紹 Flink 2.0 中，以及未來幾年我們的一些重點技術方向和技術演進情況。

一、Streaming-Flink 2.0存算分離云原生化

梅源（阿里云智能資深技術專家）：接下來由我來給大家分享 Flink 2.0 中關于流處理部分最重要的能力提升，也就是我們的存算分離云原生化架構升級，以及使這一架構升級成為可能的 ForSt DB。存算分離架構升級主要解決狀態(tài)變大帶來的問題，比如成本變大，性能降低，Checkpoint 不穩(wěn)定以及恢復慢等問題。

今年是 Flink 成為 Apache 頂級項目的十周年。在這十年間，F(xiàn)link 已經(jīng)發(fā)展成為流計算的事實標準，擁有非常豐富的上下游生態(tài)，并廣泛應用于各行各業(yè)。然而，回歸本質，F(xiàn)link 流計算的核心要義仍舊集中在三個方面：分布式、高性能和有狀態(tài)計算。這三個特點是 Flink 成為流計算標準并取得成功的核心因素。

1. 分布式高性能有狀態(tài)計算

什么是有狀態(tài)計算？對于流處理來說，輸入數(shù)據(jù)是無界且持續(xù)的，并根據(jù)這些持續(xù)的輸入實時輸出數(shù)據(jù)，狀態(tài)實際上是計算的中間結果。每處理一條新的數(shù)據(jù)，都需要訪問和更新中間狀態(tài)結果。因此，狀態(tài)存儲的訪問延遲對處理性能有著至關重要的影響。也正是這個原因，F(xiàn)link 將計算和存儲放在一起，如中間的圖示所示，以加速計算和提升處理性能。

狀態(tài)計算需要周期性地進行快照，以便在發(fā)生故障時能夠重新加載恢復或在擴縮容時在不同節(jié)點重新分配狀態(tài)。同時，作為一個分布式系統(tǒng)，F(xiàn)link 需要確保狀態(tài)快照的一致性。這里的一致性，是指對于一個完整的快照，其所有分布式節(jié)點的快照都需要對應于相同的輸入位點，這就是 Flink 的 Checkpoint 流程。

2. 云原生新需求

存算一體的架構為 Flink 提供了高性能支持，但隨著時間的推移，我們也發(fā)現(xiàn)這種架構對 Flink 的發(fā)展帶來了一些限制。特別是當狀態(tài)數(shù)據(jù)量增大，以及云原生部署變得越來越普遍時，我們對 Flink 的整體架構提出了四個新的需求，總結如下：

1. 計算和存儲解綁：希望計算和存儲能夠獨立地進行擴展和縮減，以解決狀態(tài)存儲變大帶來的額外成本
2. 容器化資源的均勻使用：目前在存算一體架構下，一致性快照過程需要在短時間內(nèi)占用大量資源，導致資源使用出現(xiàn)高峰。因此，希望資源使用能夠更加均勻和平緩，提升系統(tǒng)穩(wěn)定性。
3. 利用海量低價云存儲：隨著硬件的發(fā)展，使用本地盤不再是強需求，希望能夠充分利用海量低價云存儲，進一步降低成本
4. 帶狀態(tài)的快速擴縮容：這是云原生的彈性需求，無狀態(tài)容器的擴縮容相對簡單輕量，但有狀態(tài)的容器因為涉及到狀態(tài)重新分配，需要更多時間。如何實現(xiàn)秒級的狀態(tài)重新分配，也是存算分離目標解決的需求。

Flink 2.0 中的存算分離云原生化架構升級正是為這些問題而設計的。這些問題歸根結底是存儲的問題，目前市場上沒有可直接解決這些問題的存儲解決方案。因此，我們開發(fā)并開源了 ForSt DB。ForSt 是 "For Streaming" 的縮寫，這是一個非常簡單直接且富有美好愿景的名字。

3. ForSt DB

那么 ForSt DB 可以實現(xiàn)什么功能呢？它最大的特點是原生支持 DFS（分布式文件系統(tǒng)）。簡單來說，就是從左邊的存算一體架構變到右邊的架構：從將本地盤與計算綁定在一起，到可以直接進行 DFS 的直讀直寫。

通過這種方式，可以很自然地解決之前提到的四個問題：

1. 狀態(tài)存儲不再依賴本地盤：因為可以直接讀寫 DFS，所以不再需要依賴本地盤。
2. 快速擴縮容和容錯恢復：由于可以直接從 DFS 讀取數(shù)據(jù)，因此擴縮容和故障恢復的速度可以非常快。
3. 輕量化的 Checkpoint：因為狀態(tài)和 Checkpoint 都存儲在 DFS 上，可以共享文件，所以 Checkpoint 的設計可以更加輕量。
4. 資源使用的平緩穩(wěn)定：由于 Checkpoint 流程變得輕量，資源使用也會更加平穩(wěn)和穩(wěn)定。

從左到右的轉變看似簡單，似乎只是將本地盤替換為 DFS。但實際上，這并非易事。如果僅僅是這樣簡單的替換，這個問題不會花費多年來解決。真正的挑戰(zhàn)在于如何高效地實現(xiàn)這一轉變，并確保系統(tǒng)的性能和可靠性在新架構下能夠得到保障。

首先要解決的問題是 DFS 直讀直寫對 Flink 帶來的性能回退影響。正如之前提到的，存儲訪問延遲對 Flink 的性能有非常關鍵的影響。要知道，本地盤訪問的存儲延遲與 DFS 直讀直寫的訪問延遲之間基本上有 10 倍的差距。如果我們直接連接 DFS，性能回退 10 倍，這基本上是不可接受的，也無法使用。這其實也是為什么多年來 Flink 存算分離的嘗試很多，但都不怎么成功的原因。我們是如何解決這個問題的呢？

其次，對于 Flink 這樣的流計算系統(tǒng)，其快照框架和內(nèi)置數(shù)據(jù)庫需要原生且無縫的深度集成。只有這樣，才能保證快照的一致性，否則從理論上是無法保證一致性的，會產(chǎn)生和寫外部數(shù)據(jù)庫一樣的重復問題。因此，我們在這部分也做了大量的工作。

第三，對存算分離來說，緩存（Cache）是非常重要的性能提升部分。如果有本地盤可以作為緩存，我們也不能忽視這一點。因此，F(xiàn)orSt DB 主要從以上三個方面全面升級了 Flink 的存算分離架構。

我們計劃在明年初發(fā)布 Flink 2.0，上圖左邊藍框內(nèi)的六大部分即為存算分離在 2.0 版本中包含的內(nèi)容。這里想特別提到的是異步化執(zhí)行部分。異步化執(zhí)行的主要目的是實現(xiàn)計算和存儲的分離執(zhí)行，從而在執(zhí)行層面實現(xiàn)存算分離。這其實是我們能夠使存算分離性能達標的一個最主要原因。

我們的 ForSt DB 預覽版本已經(jīng)在兩個月前發(fā)布了，大家如果感興趣，可以去看看，里面有一些實驗數(shù)據(jù)的分享https://github.com/ververica/ForSt/releases/tag/v0.1.2-beta 。正式版本將與 Flink 2.0 一起發(fā)布，屆時將支持端到端的 Flink 存算分離各項功能，并完成 70% SQL 異步算子的改寫。

以下是 2.0 存算分離版本的所有技術文檔，社區(qū)公開可見，大家感興趣可以查看。下期會有蘭兆千老師對這部分（存算分離的狀態(tài)存儲 ForSt DB）的分享，大家如果感興趣，可以關注公眾號的下期推送。

上圖是 ForSt DB 預覽版的實驗結果，這些結果都是與目前社區(qū)最新版本的 Apache Flink 1.20 進行對比得出的，這里強調(diào)三點：

1. 在同步模式下，存算分離的性能預期內(nèi)下降了 10 倍。如果我們僅僅將本地盤替換為 DFS，或者使用當前的外置數(shù)據(jù)庫，我們得到的結果就是性能下降 10 倍。因此為了加速這個過程，采用了異步模式。
2. 在異步執(zhí)行模式下，即使沒有任何本地盤緩存，進行 DFS 直讀直寫的情況下，存算分離的性能僅略有下降。這個略有下降在測試中表現(xiàn)為大約 15% 的性能差異（從 19.2 到 16）。
3. 在異步模式下，如果我們使用 50% 的本地盤作為緩存，存算分離的性能比 Flink 1.20 還提升了 50%。如果你對這個神奇現(xiàn)象的實現(xiàn)感興趣，可以期待下期蘭兆千老師的分享。

二、Stream-Batch Unification

1. 什么是流批一體？

李麟（阿里云智能高級技術專家）：接下來，我將與大家探討 Flink 的流批一體。什么是流批一體呢？從數(shù)據(jù)工程的角度來看，可以用一句話來描述：存儲一份數(shù)據(jù)，只需編寫一份代碼，用一套引擎來同時滿足離線和實時的數(shù)據(jù)需求。

一份數(shù)據(jù)意味著存儲的統(tǒng)一，而只寫一份代碼則隱含著對計算引擎的統(tǒng)一要求。因為即便是用 SQL 語言作為用戶 API，也難免會遇到不同 SQL 方言的差異，最直接的方式就是使用一套執(zhí)行引擎來同時支持流處理和批處理。

然而，流批一體的理想非常美好，但在實際的實現(xiàn)過程中仍然面臨著許多問題和挑戰(zhàn)。

讓我們通過數(shù)據(jù)工程的架構演變，來看看現(xiàn)實中遇到的問題。左邊是經(jīng)典的 Lambda 架構，從數(shù)據(jù)鏈路分層來看，首先是數(shù)據(jù)的攝入層，完成數(shù)據(jù)的入倉入湖。接下來是存儲層，分別包括離線存儲和實時消息隊列。最后，面向具體的計算引擎進行業(yè)務開發(fā)。

從上到下，離線和實時是兩套不同的技術棧和開發(fā)流程，這就導致了一系列的問題，存儲冗余、技術棧復雜、離線和實時需要開發(fā)兩遍，還容易出現(xiàn)數(shù)據(jù)不一致。在 2020 年的“雙十一”期間，我們與天貓的技術團隊合作，在數(shù)倉的明細層到 ADS 層落地了新的流批一體數(shù)據(jù)開發(fā)架構。但受限于當時的存儲成本，沒能進一步推廣。

這兩年來流批一體的湖存儲開始流行。在 Lakehouse 架構下，像 Paimon 這樣的存儲能夠同時支持流讀流寫、批讀批寫，結合 Flink 計算引擎，能在很大程度上實現(xiàn)計算和業(yè)務開發(fā)的統(tǒng)一。然而，過程中仍然存在一些未能很好解決的問題。例如，當業(yè)務需要進行數(shù)據(jù)回刷時，流模式可能太慢，而使用性能更好的批模式刷新時，原有的 SQL 無法直接復用，仍需進行修改。

回到 Flink 的視角，十年來，從流批一體的引擎架構出發(fā)，到 SQL 引擎生產(chǎn)可用，實現(xiàn)了計算的統(tǒng)一。Paimon，新的流批一體湖存儲實現(xiàn)了存儲的統(tǒng)一。Flink CDC 為用戶提供了攝入層的統(tǒng)一。要做到全鏈路的流批一體，讓用戶只開發(fā)一份代碼究竟還缺什么？

流批代碼無法統(tǒng)一的核心問題在于編程模型的區(qū)別。批處理是面向靜態(tài)數(shù)據(jù)編程，通常會基于分區(qū)操作，比如 INSERT OVERWRITE PARTITION，每個分區(qū)的數(shù)據(jù)有確定的過濾條件。而流計算是面向無限流編程，不會有這種分區(qū)操作。這就導致兩種模型下寫出來的 SQL 無法做到完全統(tǒng)一。

2. 流批一體 Materialized Table

為了解決上述問題，我們引入了全新的流批一體 Materialized Table（物化表）。以下是一個簡單的物化表創(chuàng)建腳本，它由 3 部分組成

首先是CREATE MATERIALIZED TABLE來創(chuàng)建表對象，在 Paimon Catalog 下創(chuàng)建的就是一張 Paimon 表。

第二部分是用戶期望的數(shù)據(jù)新鮮度 FRESHNESS 定義，可以根據(jù)需求來靈活設置。

最后是 Query 部分來描述用戶的業(yè)務邏輯。

通過使用物化表，用戶可以從原來的命令式 SQL 轉變?yōu)橐环N聲明式的一體化 SQL。用戶只需要關注業(yè)務邏輯和數(shù)據(jù)的新鮮度，剩下的工作交由 Flink 引擎自動完成。

使用 Materialized Table 后，用戶能夠只寫一份代碼，同時還能簡化日常運維工作。例如，在大型促銷活動期間，用戶可以向業(yè)務方提供秒級實時數(shù)據(jù)。在促銷活動結束后，為了降低運行成本，用戶可以通過一鍵切換，將數(shù)據(jù)的新鮮度調(diào)整為天級。在數(shù)倉中經(jīng)常使用的數(shù)據(jù)回刷，也只要一行語句就能觸發(fā)完成。

除了幫助用戶實現(xiàn)只寫一份代碼、提高開發(fā)運維效率之外，Materialized Table 還提供了更多的成本優(yōu)化空間。Materialized Table 支持流式持續(xù)刷新、批式全量刷新以及增量刷新 3 種模式。

從上圖右側的成本曲線來看，流式持續(xù)刷新 也就是 Flink 流模式，能夠提供秒級的新鮮度，但成本并不會因為改成小時級新鮮度就明顯降低，因為流模式需要常駐的計算資源。全量刷新就是批計算，在小時到天級別的一次性計算中，成本最低，但如果用全量刷新去實現(xiàn)分鐘級的新鮮度，就會因為每次刷新都是基于全量數(shù)據(jù)重算，導致成本劇增。增量刷新介于兩者之間，在分鐘到小時級新鮮度上，通過只計算增量數(shù)據(jù)來降低成本。

這樣，Materialized Table 可以為用戶在數(shù)據(jù)新鮮度、時效性和成本上提供靈活的切換選擇。用戶只需提出期望的數(shù)據(jù)新鮮度，F(xiàn)link 會自動根據(jù)成本選擇最佳性價比的刷新方式。

Materialized Table 補全了 Flink 流批一體化的最后一塊拼圖，但這僅僅是一個開始。未來，我們將繼續(xù)推進計算和存儲的聯(lián)合優(yōu)化。在計算層面，我們將適配新的存算分離存儲，以實現(xiàn)更好的算子異步化吞吐，并持續(xù)優(yōu)化計算執(zhí)行模式，包括物化數(shù)據(jù)的共享。在存儲的聯(lián)動上，我們將充分發(fā)揮新存儲的能力，感知數(shù)據(jù)分布，實現(xiàn)更好的計算下推和卸載。

面向新的湖流一體存儲，我們希望通過融合，為用戶提供從秒級、分鐘級到小時級的靈活切換體驗。

三、Streaming Lakehouse

宋辛童（阿里云智能高級技術專家）：流式湖倉架構在之前的分享中已經(jīng)介紹過，這是基于 Flink 和 Paimon 兩個項目打造的全鏈路數(shù)據(jù)實時化、全鏈路流批一體化以及全鏈路數(shù)據(jù)可查詢的數(shù)據(jù)分析架構。為了更好地在生產(chǎn)環(huán)境中落地，這套架構對 Flink 和 Paimon 兩個項目的深度集成提出了很高的要求。為此，F(xiàn)link 和 Paimon 的社區(qū)進行了緊密合作，在這方面進行了大量努力。

首先，在場景方面，我們針對一些用戶常用的場景進行了深度優(yōu)化。例如，在寬表拼接場景中，用戶通常會使用 Join 操作，而 Join 操作在數(shù)據(jù)處理中是相對昂貴的。有了 Flink 和 Paimon 的組合，在某些特殊情況下（如有唯一主鍵時），我們可以使用 Paimon 的 Partial Update 特性來取代 Join，從而大幅降低計算成本。

此外，在需要使用 Paimon 作為維表進行查詢和關聯(lián)的場景中，我們也針對不同的細分場景進行了深度定制優(yōu)化。例如，在 Flink 的 Lookup Join 中，會考慮 Paimon 中數(shù)據(jù)的分布情況來優(yōu)化存儲和計算。針對單 Key 熱點問題，我們適配了 Flink 的 Skew Join 特性。此外，F(xiàn)link 目前正在開發(fā)一個名為 Proc-time Temporal Join 的功能，這在某些場景下，尤其是維表更新不頻繁的情況下，可以取代 Lookup Join 提升計算效率。在流批一體新場景下，例如 Flink CDC 的全增量一體化數(shù)據(jù)同步過程中，或者李麟老師剛剛介紹的 Materialized Table 新場景下，我們也做了很好的支持和適配。

在引擎能力方面，最重要的是 Flink 讀寫 Paimon 表的性能問題。我們在這方面做了大量工作，包括對接 Paimon 最新的 Feature——Deletion Vectors，并對 Flink 寫入到 Paimon 表中的數(shù)據(jù)進行按字段分區(qū)和排序，從而優(yōu)化下游業(yè)務訪問 Paimon 數(shù)據(jù)的讀取性能。此外，我們還做了文件讀寫的 Native 實現(xiàn)。在可維護性方面，目前 Paimon 所有的湖表管理操作（如 Compaction、元數(shù)據(jù)清理和管理等）都可以通過 Flink SQL 中的 Procedures 方便快捷地完成。

半結構化數(shù)據(jù)在 AI 和特征工程等場景下尤為常見，為了更好地讀寫和處理這些半結構化數(shù)據(jù)，F(xiàn)link 和 Paimon 社區(qū)正在合作探索一些新技術，例如在 SQL 中引入 Variant 數(shù)據(jù)類型的技術。以上是關于 Flink 與 Paimon 集成情況的介紹。

四、AI

最后一部分是關于 AI 的話題，這是我們在社區(qū)和與合作伙伴交流時經(jīng)常被問到的問題?，F(xiàn)在 AI 大模型非?；馃?，那么 Flink 在其中能夠發(fā)揮什么作用呢？今天我想和大家聊一聊這個話題。

在這里，我們展示了最近非?；馃岬?RAG（Retrieval-Augmented Generation）業(yè)務場景。RAG 的核心思想是利用特定的知識庫（例如企業(yè)內(nèi)部數(shù)據(jù)的知識庫或特定領域的知識庫）來輔助大模型進行內(nèi)容生成。

在這種場景下，主要分為兩條鏈路：

1. 知識庫數(shù)據(jù)的預處理：將知識庫中的數(shù)據(jù)調(diào)用大語言模型進行 Embedding 向量化，并將得到的向量存儲在向量數(shù)據(jù)庫中。
2. 用戶查詢請求的處理：當用戶發(fā)起查詢請求時，對該查詢進行 Embedding 向量化，將得到的向量與向量數(shù)據(jù)庫中的其他向量進行近似搜索匹配，找出與查詢最相關的知識庫文檔，并將這些文檔作為上下文與查詢一起提供給大語言模型進行內(nèi)容生成。

在這樣的 RAG 架構下，F(xiàn)link 能夠發(fā)揮哪些作用呢？Flink 的最大優(yōu)勢在于實時計算和實時處理。我們可以換個角度思考，RAG 架構下是否存在實時計算和處理的需求？答案顯然是有的。

在知識庫方面，知識庫并不是一成不變的靜態(tài)數(shù)據(jù)集，而是不斷發(fā)展、演進和變化的。當知識庫中的文檔更新時，能否快速反映在大語言模型生成的內(nèi)容中？這對上面這條黃色的鏈路有很高的實時處理/實時計算需求。其次，用戶發(fā)起查詢后希望盡快看到大模型生成的內(nèi)容結果，在這個過程中可能很多時間花費在大語言模型的內(nèi)容生成上，但鏈路本身的實時性也有很高的要求。

在這個架構中，有一條關鍵鏈路是對大語言模型的調(diào)用，無論是進行 Embedding 向量化還是內(nèi)容生成，都會反復調(diào)用大語言模型。為了更好地支持這條關鍵鏈路的實時化，我們在 Flink SQL 中引入了全新的語法，原生支持一些 AI 模型的使用。

現(xiàn)在，用戶可以在 Flink SQL 中像定義 Catalog 一樣定義一些 AI 模型，包括輸入輸出的數(shù)據(jù)結構以及一些模型參數(shù)等。通過這樣的定義，用戶可以在 SQL 查詢中像使用函數(shù)或表值函數(shù)一樣調(diào)用 AI 模型。通過這種方法，我們可以將對大語言模型的調(diào)用與調(diào)用前后的數(shù)據(jù)處理、結果校驗等邏輯有機地整合在一起。

目前這項工作的設計方案在 Flink 社區(qū)已經(jīng)討論通過，處于開發(fā)階段。這也是 Flink 社區(qū)在 AI 大模型領域的初步探索。我們相信未來 Flink 社區(qū)將在 AI 大模型領域進行更多的探索和實踐，包括對半結構化和非結構化數(shù)據(jù)的處理，以及對向量數(shù)據(jù)庫的查詢訪問和處理等。

以上就是我們今天為大家?guī)淼年P于 Flink 2.0 的一些技術分享。感謝大家的關注和支持！

更多內(nèi)容

[圖片上傳失敗...(image-c0030d-1734575714131)]

活動推薦

阿里云基于 Apache Flink 構建的企業(yè)級產(chǎn)品-實時計算 Flink 版現(xiàn)開啟活動：
新用戶復制點擊下方鏈接或者掃描二維碼即可0元免費試用 Flink + Paimon
實時計算 Flink 版（3000CU*小時，3 個月內(nèi)）
了解活動詳情：https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc

[圖片上傳失敗...(image-87f2cc-1734575714131)]