摘要：本文整理自阿里云高級產(chǎn)品專家黃鵬程和阿里云技術(shù)專家陳婧敏在 FFA 2023 平臺建設(shè)專場中的分享。內(nèi)容主要為以下五部分：
阿里云實時計算 Flink
產(chǎn)品化思考
產(chǎn)品化實踐
SQL 產(chǎn)品化思考及實踐
展望
三、產(chǎn)品化實踐
4、技術(shù)民主化
這涉及到了一個關(guān)鍵問題：如何確保每個人都能夠參與實時數(shù)據(jù)處理和分析的過程中。這正對應(yīng)了國內(nèi)常見的問題，即業(yè)務(wù)和使用門檻的高度挑戰(zhàn)。
Snowflake 之所以廣受歡迎，不僅歸功于其卓越的技術(shù)架構(gòu)，還在于它推動了技術(shù)的民主化過程。即便是非技術(shù)人員，只要掌握一些 SQL 知識就能輕松使用。相比之下，F(xiàn)link 在實現(xiàn)技術(shù)民主化方面還面臨著較長的道路。
作為一家云服務(wù)提供商，阿里云 Flink 提供了一個一站式的開發(fā)和運維平臺。它支持用戶的全方位需求，包括開發(fā)、測試、調(diào)試、以及底層資源的運行調(diào)度，并在運行維護方面（包括問題診斷、資源優(yōu)化、日志排查、監(jiān)控與告警等）提供全面服務(wù)。
4.1 流批一體的作業(yè)開發(fā)與運行
我們提供一個平臺式的流批一體作業(yè)開發(fā)運行環(huán)境，支持流作業(yè)和批作業(yè)。在今年的云棲大會上，我們宣布了我們有了自己的調(diào)度引擎，能夠讓用戶在平臺上一次把所有的流和批都做完。
4.2 純SQL 開發(fā)，簡單易用，專注業(yè)務(wù)
我們的開發(fā)過程中，我們鼓勵用戶采用 SQL 進行開發(fā)。盡管 Datastream API 和 Table API 提供了極高的靈活性，我們?nèi)耘f希望用戶能夠在確保業(yè)務(wù)需求得到滿足的前提下，優(yōu)先選擇使用 Flink SQL。目前在云端，大約70%的用戶選擇使用純 Flink SQL，而剩下的 30% 則部署了使用 Datastream API 或 Table API 的 JAR 作業(yè)，這顯示了 SQL 在我們平臺上的首要地位。
為了進一步支持用戶，我們在云端提供了一個可視化 Web IDE，它不僅能協(xié)助用戶更便捷地開發(fā) Flink 作業(yè)，還提供語法校驗和錯誤提示，從而增強開發(fā)體驗。此外，該 IDE 還支持用戶進行數(shù)據(jù)探查，管理用戶定義的函數(shù)（UDF），組織作業(yè)，管理元數(shù)據(jù)，以及進行 SQL 優(yōu)化分析，全方位滿足不同開發(fā)者的需求。
4.3 快速實現(xiàn)SQL 調(diào)試，支持模擬數(shù)據(jù)生成
調(diào)試部分分為以下幾個步驟：第一，可快速地反復(fù)運行；第二，確定測試數(shù)據(jù)的來源；第三，如何保證不影響線上數(shù)據(jù)。們會按照用戶要求在規(guī)則的限制下使用專門的 Connector 快速生成一些類似于業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)，可以用戶自行上載測試數(shù)據(jù)，整個過程不會影響線上的實際生產(chǎn)數(shù)據(jù)。
4.4 智能自動調(diào)優(yōu)模式，輕松應(yīng)對洪峰
項目進入開發(fā)測試階段后，便開始了在云環(huán)境上運行作業(yè)的過程。此時，我們引入了智能調(diào)優(yōu)模式，旨在幫助用戶高效應(yīng)對業(yè)務(wù)高峰。該模式能根據(jù)作業(yè)運行情況，對 Flink 的配置提出針對性的調(diào)整建議或采取相應(yīng)措施，無論配置偏高或偏低均可。它通過分析作業(yè)指標(biāo)（包括作業(yè)本身的指標(biāo)和底層環(huán)境的指標(biāo)，以及日志信息），輔助用戶對作業(yè)執(zhí)行參數(shù)進行優(yōu)化調(diào)整，以更好地適應(yīng)當(dāng)前的業(yè)務(wù)需求，例如通過調(diào)整作業(yè)的并發(fā)度。此外，當(dāng)需要對資源進行伸縮調(diào)整時，系統(tǒng)還可利用上邊提到的參數(shù)動態(tài)更新模式，實現(xiàn)資源配置的迅速變更。在右下角展示的案例中，顯示了一個 AGG 算子的處理能力遭遇瓶頸。隨著作業(yè)運行一段時間，系統(tǒng)會提示用戶考慮增加 MiniBatch 配置以提升處理能力。
目前，我們擁有一套豐富的智能自動調(diào)優(yōu)策略，這套策略涵蓋了三個方面：基于 CPU、基于內(nèi)存以及基于延遲的參數(shù)調(diào)整。未來，還計劃通過考慮 State 的情況來進一步完善這套自動調(diào)優(yōu)策略。
除了完全自動調(diào)優(yōu)外，還有一種定時調(diào)優(yōu)。
因為自動調(diào)整是為了應(yīng)對意料之外的流量，但如果每個人對自己的業(yè)務(wù)較為熟悉，或者業(yè)務(wù)運作具有一定的計劃性—比如雙十一購物節(jié)、教育培訓(xùn)行業(yè)的周末和晚間時段—那么用戶可以按照時間制定資源計劃。這樣，他們就能在特定的時間段重啟作業(yè)，或者采用動態(tài)更新的方式調(diào)整資源配置，比如橫向調(diào)整并發(fā)處理的數(shù)量、縱向調(diào)整資源規(guī)模，或者根據(jù)需求高峰期調(diào)整適用于 Flink 的相關(guān)配置。
4.5 作業(yè)智能診斷， 一鍵診斷問題
阿里云 Flink 進一步降低了用戶在問題診斷上的使用門檻，這通常是使用 Flink 時壓力最大、最耗費時間和精力的環(huán)節(jié)。Flink 的智能診斷功能覆蓋了作業(yè)開發(fā)和運行的整個過程，包括在出現(xiàn)異常時提供的建議。在整個應(yīng)用周期內(nèi)，無論是在運行階段還是上線過程中，它都能進行錯誤檢測，明確指出錯誤原因以及糾正方法。在運行狀態(tài)下，F(xiàn)link 還會提供問題提示。尤其是當(dāng)作業(yè)運行失敗時，F(xiàn)link 能夠根據(jù)當(dāng)前的作業(yè)狀況與規(guī)則庫匹配，提出針對性的建議，幫助用戶迅速回歸到業(yè)務(wù)開發(fā)上，免去底層細(xì)節(jié)問題的困擾。
全生命周期的作業(yè)狀態(tài)管理還可以降低使用門檻，這關(guān)系到如何管理狀態(tài)的問題。具體包括狀態(tài)的（定期）生成與刪除、狀態(tài)的展示、狀態(tài)的兼容性，以及狀態(tài)的恢復(fù)。
用戶往往需要確認(rèn)狀態(tài)是否按照預(yù)期進行操作并希望通過狀態(tài)來觀察業(yè)務(wù)的進展情況，特別是當(dāng)使用 Datastream API 的情況下，對于狀態(tài)的操作更加的靈活。平臺提供了檢查 Checkpoint 的正確性、數(shù)量、所需時間以及探查狀態(tài)的中間結(jié)果等方面的功能。另外，我們計劃后續(xù)推出一套狀態(tài)探查工具和結(jié)果分析功能，以幫助用戶更深入地了解和監(jiān)控狀態(tài)。
對于狀態(tài)兼容性，無論對于 Apache Flink 還是云服務(wù)的能力而言，我們都渴望在業(yè)務(wù)邏輯發(fā)生變化后，現(xiàn)有的狀態(tài)能夠保持兼容，避免需要重新追溯數(shù)據(jù)。為此，我們引入了狀態(tài)兼容性檢查功能，此功能能夠告知我們作業(yè)的兼容性情況，幫助我們判斷是否能夠直接重啟業(yè)務(wù)。此外，我們還致力于在兼容性方面進行一定程度的提升。這里所說的“提升”，并非指向狀態(tài)周期管理的具體功能上，而是指在 SQL 核心級別進行的改進，以期望用戶在修改特定 SQL 語句后，仍舊保持兼容性。關(guān)于如何修改 SQL 以保持狀態(tài)兼容的詳盡文檔，可以在阿里云 Flink 官方網(wǎng)站找到。
對于狀態(tài)的恢復(fù)，具體而言，涉及從狀態(tài)（state）、檢查點（checkpoint）進行恢復(fù)，未來還將支持兼容 Flink 開源狀態(tài)的云端恢復(fù)。此外，我們已經(jīng)支持跨作業(yè)狀態(tài)恢復(fù)，允許使用 B 作業(yè)的狀態(tài)來啟動A作業(yè)。這在進行 A/B 測試或構(gòu)建容錯機制時特別有用，因為這些場景常常要求根據(jù)一個作業(yè)的狀態(tài)來順序啟動或建立關(guān)聯(lián)啟動另一個作業(yè)。
5、實時數(shù)據(jù)可觀測性
它與我們平時談?wù)摰目捎^測性內(nèi)容沒有區(qū)別，我們現(xiàn)在只是站在了實時領(lǐng)域的角度進行分析。
首先，數(shù)據(jù)處理的狀態(tài)：這指的是作業(yè)處理過程中的各個階段需要被觀測。其次，元數(shù)據(jù)的管理，涉及到作業(yè)當(dāng)前的數(shù)據(jù)背后的業(yè)務(wù)含義。最后，數(shù)據(jù)血緣，關(guān)注的是數(shù)據(jù)之間的相互關(guān)系。
5.1 作業(yè)運行狀態(tài)
產(chǎn)品具備極其詳細(xì)且全面的監(jiān)控告警功能，同時與阿里云的云產(chǎn)品 ARMS 實現(xiàn)了對接，為用戶提供了一種更為靈活的方式，以查看所有指標(biāo)的狀態(tài)。
5.2 數(shù)據(jù)血緣
近些年實時數(shù)倉常常被提起，它涉及在實時環(huán)境中根據(jù)數(shù)據(jù)倉庫理論進行數(shù)據(jù)的分層建設(shè)。在這個過程中，作業(yè)之間的關(guān)系變得更加復(fù)雜。這不僅僅關(guān)乎單個作業(yè)的運行，而是關(guān)于一個作業(yè)的產(chǎn)出如何成為另一個作業(yè)的原始輸入的過程。對于這一流程，流式作業(yè)與批處理作業(yè)之間存在諸多差異。批處理作業(yè)的數(shù)據(jù)血緣可以在一定程度上通過調(diào)度工具獲取，而流式作業(yè)并不涉及調(diào)度，缺乏調(diào)度器提供的信息，因此需要借助平臺來完成這一部分工作。
具體的實施方法以及達(dá)到的效果將在后續(xù)由陳老師進行分享。
5.3 元數(shù)據(jù)管理
無論是云端用戶還是開源用戶，我們都希望他們能夠使用 Catalog。盡管從開源或商業(yè)角度來看，Catalog 目前支持的數(shù)據(jù)組件數(shù)量相對較少，但它已經(jīng)支持了包括 Kafka、MySQL 在內(nèi)的常見數(shù)據(jù)組件，以及阿里云的 Hologres、ADB、MaxCompute、數(shù)據(jù)湖 Paimon 等。
6、實時離線一體化
6.1 Apache Paimon構(gòu)建流批一體存儲基礎(chǔ)
首先，Apache Paimon 本身采用的是湖倉一體化的架構(gòu)，主打的是離線數(shù)據(jù)在成本可控的情況下進一步的實時化改造升級；其次，它并不直接提供存儲服務(wù)，而是依托于對象存儲技術(shù)，例如阿里云的 OSS，可以視作與 Flink 高度兼容的 Hudi 或 Iceberg 的延伸。Apache Paimon 具備流表二元屬性，能夠同時支持文件存儲（File Store）和日志存儲（Log Store）。在其架構(gòu)下，支持流式讀寫和批量讀寫操作，同時也能實現(xiàn)流式寫入后的批量處理。
6.2 Flink + Paimon構(gòu)建流式湖倉
Apache Paimon 上構(gòu)建的 Streamhouse 旨在從用戶的數(shù)據(jù)庫或日志系統(tǒng)中提取數(shù)據(jù)后進行湖上數(shù)倉分層構(gòu)建準(zhǔn)實時數(shù)據(jù)分析體系。對于數(shù)據(jù)庫數(shù)據(jù)，我們通過 Flink CDC 實時抽取數(shù)據(jù)，并將其存儲在 OSS 云服務(wù)上的 Paimon 數(shù)據(jù)湖中。接著，我們可以進一步進行數(shù)據(jù)流的分層處理，遵循標(biāo)準(zhǔn)的數(shù)據(jù)倉庫分層架構(gòu)。每一層都可以采用流處理或批處理的方式構(gòu)建，且每一層的數(shù)據(jù)都能被多種外部獨立供應(yīng)商的查詢工具，如 Presto、Hologres、StarRocks，以及阿里云的 MaxCompute 等，進行查詢。這種模式相較于以往依賴 Kafka 的純開源方案，使得數(shù)據(jù)沉淀更加便捷，且數(shù)據(jù)的查詢變得更加高效。
該架構(gòu)實現(xiàn)了流批處理的一體化，存儲全部基于 OSS，計算通過 Flink 加上 Paimon 的 API 來完成，整個鏈路的實時處理能力意味著每一層都能生成供下一層消費的日志。由于整個系統(tǒng)建立在 OSS 之上，它實現(xiàn)了近乎實時的數(shù)據(jù)處理，同時保持了較低的成本。此外，其開放的數(shù)據(jù)架構(gòu)確保了每一層都可以被不同的 OLAP 引擎查詢，增強了數(shù)據(jù)的可訪問性和靈活性。
四、SQL產(chǎn)品化思考及實踐
這部分主要介紹近一年 SQL 在產(chǎn)品上做出的重要突破及未來的規(guī)劃。
1、降本增效
我們在保持了社區(qū) API 不變的前提下，內(nèi)部引入了增強的特性，能夠更好地幫助用戶達(dá)到降本增效的效果。
1.1 引入增強的 QUERY HINTS
（1）針對雙流 Join 的 TTL Hint
在社區(qū)1.18之前，SQL 作業(yè)只能在作業(yè)粒度設(shè)置狀態(tài)算子 TTL，這意味著如果作業(yè)中有多個狀態(tài)算子，只能設(shè)置同樣的 TTL。我們以雙流 Join 為例簡要介紹一下這個過程。當(dāng)作業(yè)在從 Execplan 生成 Transformation 時 TableConfig 會被解析出來作為入?yún)⑷?chuàng)建 StreamingJoinOperator。在 Runtime 階段，當(dāng) Operator 的 Open 函數(shù)被調(diào)用時，TTL 值會分別用于創(chuàng)建左流和右流的 StateDescriptor。
FLIP-292 中提出了一種通用的在算子粒度修改 State TTL 的方法。但該方法要求用戶修改 ExecPlan 序列化之后的 JSON 文件，交互沒那么友好。產(chǎn)品上我們針對雙流 Join 這種 hint 傳播沒有歧義的場景下引入了 JOIN_STATE_TTL，這樣用戶就可以通過寫 SQL 來修改左、右流的State TTL 達(dá)到預(yù)定效果。在實現(xiàn)方面，優(yōu)化器會先在 LogicalPlan 解析和校驗 Hint。在 ExecPlan 到 Transformation 的生成過程中，把 Hint 的 Value 轉(zhuǎn)化成 FLIP-292 引入的 StateMetadata，達(dá)到跟社區(qū)保持兼容的目的。
下面展示了阿里云內(nèi)部作業(yè)的優(yōu)化效果：
該作業(yè)中左流是大流，右流是小流，左流的數(shù)據(jù)是右流的 20-50 倍，右流有長周期保存的需求。理想狀態(tài)下，右流的 State 需要保存 18 天，但出于權(quán)衡，業(yè)務(wù)方最終設(shè)置了 10 天為 TTL。在這種情況下，可以看到其 State Size 約為 5.8T，而當(dāng)用戶使用了 JOIN_STATE_TTL 之后，它的左流可以設(shè)置為 12 個小時，進而提高其右流數(shù)據(jù)的計算精度達(dá)到 18 天。在不犧牲數(shù)據(jù)正確性的前提下，其 State Size 降低到了 582 G，整個作業(yè)的資源消耗從原來的 700CU 降低到了現(xiàn)在的 300-400CU。
可以看出，對于左流跟右流需要保存不同的 TTL 的場景，Hint 的優(yōu)化效果比較明顯。
（2）針對維表 Join 的 Shuffle Hint
除了雙流 Join 場景之外，我們也為維表 Join 場景引入了優(yōu)化的 Hint。以 Cache All 為例，過去如果要使用 Cache All 方式做維表關(guān)聯(lián)，每個 Subtask 上面都會緩存維表全部數(shù)據(jù)，故而較大的維表很難完成該操作。
最近我們引入了 SHUFFLE_HASH Hint。它會指定流表在關(guān)聯(lián)之前先按照連接 Key 做一次 Hash。同一個 Key 值對應(yīng)的記錄在做完 Hash Shuffle 之后，必然會落在某個確定的 Subtask 上，與此同時，維表在 Open 和 Loading 過程中可以只過濾出當(dāng)前 Key 所對應(yīng)的維表的數(shù)據(jù)。假設(shè)作業(yè)的并發(fā)是 N，在數(shù)據(jù)分布均勻的情況下，通過一次 Hash Shuffle 之后，每個 Subtask 上只需要加載 1/N 的數(shù)據(jù)，如此一來大維表也可以較好地支持 Cache All 操作。
在數(shù)據(jù)分布不均勻時，通過一次 Hash Shuffle，Key 會落在某個或某幾個 Subtask 上，造成作業(yè)出現(xiàn)數(shù)據(jù)熱點，拖垮整個作業(yè)處理數(shù)據(jù)的速度。
針對這種情況，我們引入了 REPLICATED_SHUFFLE_HASH hint。
核心思路是隨機打散。通過種分桶機制指定 Bucket 的數(shù)量，這樣對于熱點數(shù)據(jù)，就會把它隨機 Shuffle 到 b 個桶，即 b 個 Subtask 上，相當(dāng)于把維表的數(shù)據(jù)隨機地在 b 個 Subtask 上 Loading。通過這種方式就完成了動態(tài)維表的復(fù)制，用戶不需要自己再去把維表復(fù)制 b 份打散，在 Runtime 階段會自動完成，來緩解由于 Shuffle 導(dǎo)致的數(shù)據(jù)熱點問題。
1.2 Mini-batch 雙流 Join
以當(dāng)前 Query 為例，這是一個左表關(guān)聯(lián)右表的場景。假設(shè)關(guān)聯(lián) Key a0 和 b0 都分別是 A 表跟 B 表的主鍵。接下來通過一個小動畫展示有更新流的場景 Outer Join 存在的問題。假設(shè)在 t1 時刻，B 流流入了一條 +I 數(shù)據(jù)，由于 A 流還沒有數(shù)據(jù)，則此時不會有數(shù)據(jù)發(fā)送。同時，會把 B 流來的數(shù)據(jù)更新到 B 流所對應(yīng)的 State 中；在下一時刻，A 流流入了一條數(shù)據(jù)，同樣 A 流的數(shù)據(jù)會更新到它對應(yīng)的 State 中，假設(shè) a0 跟 b0 可以關(guān)聯(lián)到，此時就會輸出一條關(guān)聯(lián)之后的數(shù)據(jù)；在下一刻，收到了一條來自 B 流的 -U 的數(shù)據(jù)，此時，B 流對應(yīng)的 State 被清空，發(fā)出一條 -U 的消息撤回之前的操作，同時在此 Outer Join 場景下，根據(jù)語義再發(fā)送一條左流 Pad Null 數(shù)據(jù)，因為此時 B 里面已經(jīng)沒有數(shù)據(jù)了；同樣，如果此時 B 流流入了一條更新的數(shù)據(jù)，就會先把之前的 Pad Null 數(shù)據(jù)撤回，再發(fā)送更新之后的數(shù)據(jù)。
以此類推，如果 B 流更新了兩次，則會發(fā)送九條數(shù)據(jù)。其中有七條是因為 B 流的狀態(tài)變更導(dǎo)致的中間結(jié)果，也就是冗余的中間消息。假設(shè)下游并不需要完整 Changelog，則沒有必要去發(fā)送中間的冗余消息，也不需要每次都更新 State。
針對這種情況，我們最近引入了 Mini-batch 的雙流 Join 優(yōu)化。其核心思想很簡單——攢批。數(shù)據(jù)流入之后先不進行處理，而是攢在 Buffer 中，等到指定的時間或 Buffer 填滿時，統(tǒng)一進行處理。在實現(xiàn)層面，攢批既降低了 State 的更新，又能避免發(fā)送中間的冗余消息。以剛才的 Example 為例來介紹 Mini-batch 的攢批實現(xiàn)。
現(xiàn)在對于 A 流跟 B 流來說，除了對應(yīng)的 State 之外，還多了對應(yīng)的 In-memory Buffer 用來緩存每個 Batch 之內(nèi)的數(shù)據(jù)。假設(shè) t1 時刻，B 流流入了一條數(shù)據(jù)，將其放進 B 流 Buffer；在 t2 時刻，A 流流入了一條數(shù)據(jù)，同樣將其放進 A 流的 Buffer，此時 A 流跟 B 流都流入了數(shù)據(jù)，但由于仍未觸發(fā) Buffer Flush，則不會更新 State 也不會輸出關(guān)聯(lián)結(jié)果；假設(shè)在 t3 時刻 Buffer 已經(jīng)充滿，則 A 流的 Buffer 就會 Flush 到 State，B 流同樣如此。同時，因為 a0 和 b0 可以互相關(guān)聯(lián)，則此時輸出第一條關(guān)聯(lián)記錄。當(dāng) B 流流入了一條 -U 數(shù)據(jù)，就會把它放進對應(yīng) Buffer 中，同時不更新 State；當(dāng) B 流流入了一條 +U 數(shù)據(jù)，把它放在 Buffer 的 List 中，同樣不更新 State；t5 時刻又流入了一條 -U 的消息，此時發(fā)現(xiàn) Buffer 中的數(shù)據(jù)變成了一開始的 -U 的消息，因為這一組數(shù)據(jù)在寫入 Buffer 時被消除了，因為不考慮 Rowkind 時記錄的內(nèi)容是相同的，相當(dāng)于 Accumulate 數(shù)據(jù)在前，Retract 數(shù)據(jù)在后，進行了抵消；t7 時刻，流入了一條 +U 的消息，因為它不可以與前面的消息折疊，則會被放在 Buffer 中；到 t8 時刻，當(dāng) Flush Buffer 時，可以看到 Buffer里只有兩條數(shù)據(jù)。最后，只會輸出對于第一條消息的 -U 和第二條消息的 +U 帶來的更新操作。
這里還可以進一步優(yōu)化，因為假定 a0 和 b0 分別是 A 流和 B 流的主鍵，當(dāng)其既是主鍵又是 Join Key 時，只需要保留 Join Key 下最新的記錄。也就是在更新 State 時，只需要把最后一條 +U 的數(shù)據(jù)更新到 State 即可。這樣，一方面減少了中間冗余消息的輸出，另一方面也減少了 State 的操作。
1.3 級聯(lián) Join 優(yōu)化 (WIP)
由于目前所有流上的 Join 都是算子兩兩之間的 Join，故而在級聯(lián) Join 場景，隨著加入 Join 的流的增多，State 會存在逐級放大的現(xiàn)象。目前我們正在探索是否有可能從 Plan 結(jié)合 Multiple Input 算子的層面消除這種中間 State 的冗余。
2、易用性提升
2.1 SQL優(yōu)化建議
雖然 SQL 已經(jīng)可以非常方便地幫助用戶快速搭建實時的 Pipeline，但與批模式下執(zhí)行 SQL 相比，流 SQL 的語義門檻仍相對較高，我們在社區(qū)或內(nèi)部值班時，經(jīng)常會遇到 Changelog 亂序，Retraction 造成非預(yù)期結(jié)果，或是 State 過期，或是使用了非確定性的函數(shù)等導(dǎo)致的種種問題。用戶往往會覺得 SQL 編寫不易，且無從排查。FLIP-280 試圖解決這類問題，如果我們在框架層面可以提供一種新的 Explain Level——PLAN_ADVICE，當(dāng)用戶執(zhí)行 Explain 語句時，將當(dāng)前 Query 可能存在的風(fēng)險和優(yōu)化隨執(zhí)行 Plan 一起打印出來，給出比較有針對性的建議，可能會緩解這種情況。
我們在內(nèi)部的產(chǎn)品上集成了社區(qū)的框架，并且引入了更多的 Analyzer 去分析問題。當(dāng)用戶點擊 SQL 的深度校驗之后，Plan 和優(yōu)化建議會一起返回。
2.2 元數(shù)據(jù)血緣
除了plan Advice 之外，我們還引入了元數(shù)據(jù)血緣功能。
如果用戶使用 Catalog Table 讀寫的話，他可以在作業(yè)界面查看表與表之間關(guān)系。在實現(xiàn)方面，用戶在提交作業(yè)時，就會觸發(fā)異步的任務(wù)，通過 Calcite 分析含有字段的血緣，并將返回的結(jié)果保存下來。另外，如果是在 Catalog 視角，還可以查詢字段之間的血緣關(guān)系。
以上就是最近一年阿里云在 SQL 產(chǎn)品方面做出的一些比較重要的突破。
五、展望
后面近期內(nèi)阿里云 Flink 主要有兩項工作：
先是優(yōu)化流式湖倉的構(gòu)建，具體而言，我們將探索如何進一步改善 Flink 與 Paimon 的集成，以便用戶能夠?qū)崿F(xiàn)真正的流批一體化體驗和應(yīng)用方式。此外，我們不僅會在流式存儲方面持續(xù)優(yōu)化 Paimon，還將研究更適合 Flink 這一流式計算領(lǐng)域領(lǐng)導(dǎo)者的高效存儲解決方案；同時，我們計劃對數(shù)據(jù)治理體系進行優(yōu)化，包括元數(shù)據(jù)管理和數(shù)據(jù)血緣等關(guān)鍵方面的改進。
其次，我們計劃積極擁抱AI技術(shù)，探討如何將 AI 或 AIGC 的高級能力融入 Flink 產(chǎn)品之中。這包括從 AI 自動生成代碼開始，到利用AI技術(shù)加速并智能化地處理當(dāng)前云用戶的工單服務(wù)內(nèi)容，從而在產(chǎn)品中更快速、更智能地實現(xiàn)智能診斷。此外，在前文提及的能力之中，我們還希望能夠進一步拓展 Flink 的實時分析功能，包括情緒分析、輿情評估等多樣化應(yīng)用場景，在與 AIGC 的結(jié)合使用過程中，實現(xiàn)功能的進一步豐富和優(yōu)化。
