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

一、Streaming

二、Stream-Batch Unification

三、Streaming Lakehouse

四、AI

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

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

這些改動包括移除一些舊的、過時的 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 對其序列化框架進行了多項升級和改造。不過大家不用擔(dān)心，F(xiàn)link 社區(qū)將準備相應(yīng)的遷移工具，來幫助用戶進行非兼容性狀態(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 中，以及未來幾年我們的一些重點技術(shù)方向和技術(shù)演進情況。

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

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

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

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

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

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

2. 云原生新需求

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

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

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

3. ForSt DB

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

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

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

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

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

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

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

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

我們的 ForSt DB 預(yù)覽版本已經(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 存算分離版本的所有技術(shù)文檔，社區(qū)公開可見，大家感興趣可以查看。下期會有蘭兆千老師對這部分（存算分離的狀態(tài)存儲 ForSt DB）的分享，大家如果感興趣，可以關(guān)注公眾號的下期推送。

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

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

二、Stream-Batch Unification

1. 什么是流批一體？

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

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

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

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

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

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

回到 Flink 的視角，十年來，從流批一體的引擎架構(gòu)出發(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ū)操作。這就導(dǎo)致兩種模型下寫出來的 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ù)需求來靈活設(shè)置。

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

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

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

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

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

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

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

此外，在需要使用 Paimon 作為維表進行查詢和關(guān)聯(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è)務(wù)訪問 Paimon 數(shù)據(jù)的讀取性能。此外，我們還做了文件讀寫的 Native 實現(xiàn)。在可維護性方面，目前 Paimon 所有的湖表管理操作（如 Compaction、元數(shù)據(jù)清理和管理等）都可以通過 Flink SQL 中的 Procedures 方便快捷地完成。

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

四、AI

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

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

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

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

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

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

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

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

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

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

更多內(nèi)容

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

活動推薦

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

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