簡介：Flink 1.13.0 版本讓流處理應用的使用像普通應用一樣簡單和自然，并且讓用戶可以更好地理解流作業(yè)的性能。

?翻譯 | 高赟
Review | 朱翥、馬國維

GitHub 地址
https://github.com/apache/flink
歡迎大家給 Flink 點贊送 star~

Flink 1.13 發(fā)布了！Flink 1.13 包括了超過 200 名貢獻者所提交的 1000 多項修復和優(yōu)化。

這一版本中，Flink 的一個主要目標取得了重要進展，即讓流處理應用的使用和普通應用一樣簡單和自然。Flink 1.13 新引入的被動擴縮容使得流作業(yè)的擴縮容和其它應用一樣簡單，用戶僅需要修改并發(fā)度即可。

這個版本還包括一系列重要改動使用戶可以更好的理解流作業(yè)的性能。當流作業(yè)的性能不及預期的時候，這些改動可以使用戶可以更好的分析原因。這些改動包括用于識別瓶頸節(jié)點的負載和反壓可視化、分析算子熱點代碼的 CPU 火焰圖和分析 State Backend 狀態(tài)的 State 訪問性能指標。

除了這些特性外，Flink 社區(qū)還添加了大量的其它優(yōu)化，我們會在本文后續(xù)討論其中的一些。我們希望用戶可以享受新的版本和特性帶來的便利，在本文最后，我們還會介紹升級Flink版本需要注意的一些變化。

我們鼓勵用戶下載試用新版 Flink 并且通過郵件列表和 JIRA 來反饋遇到的問題。

重要特性

被動擴縮容

Flink 項目的一個初始目標，就是希望流處理應用可以像普通應用一樣簡單和自然，被動擴縮容是 Flink 針對這一目標上的最新進展。

當考慮資源管理和部分的時候，Flink 有兩種可能的模式。用戶可以將 Flink 應用部署到 k8s、yarn 等資源管理系統(tǒng)之上，并且由 Flink 主動的來管理資源并按需分配和釋放資源。這一模式對于經(jīng)常改變資源需求的作業(yè)和應用非常有用，比如批作業(yè)和實時 SQL 查詢。在這種模式下，Flink 所啟動的 Worker 數(shù)量是由應用設置的并發(fā)度決定的。在 Flink 中我們將這一模式叫做主動擴縮容。

對于長時間運行的流處理應用，一種更適合的模型是用戶只需要將作業(yè)像其它的長期運行的服務一樣啟動起來，而不需要考慮是部署在 k8s、yarn 還是其它的資源管理平臺上，并且不需要考慮需要申請的資源的數(shù)量。相反，它的規(guī)模是由所分配的 worker 數(shù)量來決定的。當 worker 數(shù)量發(fā)生變化時，Flink 自動的改動應用的并發(fā)度。在 Flink 中我們將這一模式叫做被動擴縮容。

Flink 的 Application 部署模式開啟了使 Flink 作業(yè)更接近普通應用（即啟動 Flink 作業(yè)不需要執(zhí)行兩個獨立的步驟來啟動集群和提交應用）的努力，而被動擴縮容完成了這一目標：用戶不再需要使用額外的工具（如腳本、K8s 算子）來讓 worker 的數(shù)量與應用并發(fā)度設置保持一致。

用戶現(xiàn)在可以將自動擴縮容的工具應用到 Flink 應用之上，就像普通的應用程序一樣，只要用戶了解擴縮容的代價：有狀態(tài)的流應用在擴縮容的時候需要將狀態(tài)重新分發(fā)。

如果想要嘗試被動擴縮容，用戶可以增加 scheduler-mode: reactive 這一配置項，然后啟動一個應用集群（Standalone 或者 K8s）。更多細節(jié)見被動擴縮容的文檔。

分析應用的性能

對所有應用程序來說，能夠簡單的分析和理解應用的性能是非常關鍵的功能。這一功能對 Flink 更加重要，因為 Flink 應用一般是數(shù)據(jù)密集的（即需要處理大量的數(shù)據(jù)）并且需要在（近）實時的延遲內給出結果。

當 Flink 應用處理的速度跟不上數(shù)據(jù)輸入的速度時，或者當一個應用占用的資源超過預期，下文介紹的這些工具可以幫你分析原因。

瓶頸檢測與反壓監(jiān)控

Flink 性能分析首先要解決的問題經(jīng)常是：哪個算子是瓶頸？

為了回答這一問題，Flink 引入了描述作業(yè)繁忙（即在處理數(shù)據(jù)）與反壓（由于下游算子不能及時處理結果而無法繼續(xù)輸出）程度的指標。應用中可能的瓶頸是那些繁忙并且上游被反壓的算子。

Flink 1.13 優(yōu)化了反壓檢測的邏輯（使用基于任務 Mailbox 計時，而不在再于堆棧采樣），并且重新實現(xiàn)了作業(yè)圖的 UI 展示：Flink 現(xiàn)在在 UI 上通過顏色和數(shù)值來展示繁忙和反壓的程度。

Web UI 中的 CPU 火焰圖

Flink 關于性能另一個經(jīng)常需要回答的問題：瓶頸算子中的哪部分計算邏輯消耗巨大？

針對這一問題，一個有效的可視化工具是火焰圖。它可以幫助回答以下問題：

• 哪個方法調現(xiàn)在在占用 CPU？
• 不同方法占用 CPU 的比例如何？
• 一個方法被調用的棧是什么樣子的？

火焰圖是通過重復采樣線程的堆棧來構建的。在火焰圖中，每個方法調用被表示為一個矩形，矩形的長度與這個方法出現(xiàn)在采樣中的次數(shù)成正比。火焰圖在 UI 上的一個例子如下圖所示。

火焰圖的文檔包括啟用這一功能的更多細節(jié)和指令。

State 訪問延遲指標

另一個可能的性能瓶頸是 state backend，尤其是當作業(yè)的 state 超過內存容量而必須使用 RocksDB state backend 時。

這里并不是想說 RocksDB 性能不夠好（我們非常喜歡 RocksDB！），但是它需要滿足一些條件才能達到最好的性能。例如，用戶可能很容易遇到非故意的在云上由于使用了錯誤的磁盤資源類型而不能滿足 RockDB 的 IO 性能需求的問題。

基于 CPU 火焰圖，新的 State Backend 的延遲指標可以幫助用戶更好的判斷性能不符合預期是否是由 State Backend 導致的。例如，如果用戶發(fā)現(xiàn) RocksDB 的單次訪問需要幾毫秒的時間，那么就需要查看內存和 I/O 的配置。這些指標可以通過設置 state.backend.rocksdb.latency-track-enabled 這一選項來啟用。這些指標是通過采樣的方式來監(jiān)控性能的，所以它們對 RocksDB State Backend 的性能影響是微不足道的。

通過 Savepoint 來切換 State Backend

用戶現(xiàn)在可以在從一個 Savepoint 重啟時切換一個 Flink 應用的 State Backend。這使得 Flink 應用不再被限制只能使用應用首次運行時選擇的 State Backend。

基于這一功能，用戶現(xiàn)在可以首先使用一個 HashMap State Backend（純內存的 State Backend），如果后續(xù)狀態(tài)變得過大的話，就切換到 RocksDB State Backend 中。

在實現(xiàn)層，Flink 現(xiàn)在統(tǒng)一了所有 State Backend 的 Savepoint 格式來實現(xiàn)這一功能。

K8s 部署時使用用戶指定的 Pod 模式

原生 kubernetes 部署（Flink 主動要求 K8s 來啟動 Pod）中，現(xiàn)在可以使用自定義的 Pod 模板。

使用這些模板，用戶可以使用一種更符合 K8s 的方式來設置 JM 和 TM 的 Pod，這種方式比 Flink K8s 集成內置的配置項更加靈活。

生產(chǎn)可用的 Unaligned Checkpoint

Unaligned Checkpoint 目前已達到了生產(chǎn)可用的狀態(tài)，我們鼓勵用戶在存在反壓的情況下試用這一功能。

具體來說，Flink 1.13 中引入的這些功能使 Unaligned Checkpoint 更容易使用：

• 用戶現(xiàn)在使用 Unaligned Checkpoint 時也可以擴縮容應用。如果用戶需要因為性能原因不能使用 Savepoint而必須使用 Retained checkpoint 時，這一功能會非常方便。
• 對于沒有反壓的應用，啟用 Unaligned Checkpoint 現(xiàn)在代價更小。Unaligned Checkpoint 現(xiàn)在可以通過超時來自動觸發(fā)，即一個應用默認會使用 Aligned Checkpoint（不存儲傳輸中的數(shù)據(jù)），而只在對齊超過一定時間范圍時自動切換到 Unaligned Checkpoint（存儲傳輸中的數(shù)據(jù)）。

關于如何啟用 Unaligned Checkpoint 可以參考相關文檔。

機器學習遷移到單獨的倉庫

為了加速 Flink 機器學習的進展（流批統(tǒng)一的機器學習），現(xiàn)在 Flink 機器學習開啟了新的 flink-ml 倉庫。我們采用類似于 Stateful Function 項目的管理方式，通過使用一個單獨的倉庫從而簡化代碼合并的流程并且可以進行單獨的版本發(fā)布，從而提高開發(fā)的效率。

用戶可以關注 Flink 在機器學習方面的進展，比如與 Alink（Flink 常用機器學習算法套件）的互操作以及 Flink 與 Tensorflow 的集成。

SQL / Table API 進展

與之前的版本類似，SQL 和 Table API 仍然在所有開發(fā)中占用很大的比例。

通過 Table-valued 函數(shù)來定義時間窗口

在流式 SQL 查詢中，一個最經(jīng)常使用的是定義時間窗口。Flink 1.13 中引入了一種新的定義窗口的方式：通過 Table-valued 函數(shù)。這一方式不僅有更強的表達能力（允許用戶定義新的窗口類型），并且與 SQL 標準更加一致。

Flink 1.13 在新的語法中支持 TUMBLE 和 HOP 窗口，在后續(xù)版本中也會支持 SESSION 窗口。我們通過以下兩個例子來展示這一方法的表達能力：

• 例 1：一個新引入的 CUMULATE 窗口函數(shù)，它可以支持按特定步長擴展的窗口，直到達到最大窗口大小：

SELECT window_time, window_start, window_end, SUM(price) AS total_price FROM TABLE(CUMULATE(TABLE Bid, DESCRIPTOR(bidtime), INTERVAL '2' MINUTES, INTERVAL '10' MINUTES)) GROUP BY window_start, window_end, window_time;

• 例 2：用戶在 table-valued 窗口函數(shù)中可以訪問窗口的起始和終止時間，從而使用戶可以實現(xiàn)新的功能。例如，除了常規(guī)的基于窗口的聚合和 Join 之外，用戶現(xiàn)在也可以實現(xiàn)基于窗口的 Top-K 聚合：

SELECT window_time, ...FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY window_start, window_end ORDER BY total_price DESC) as rank FROM t) WHERE rank <= 100;

提高 DataStream API 與 Table API / SQL 的互操作能力

這一版本極大的簡化了 DataStream API 與 Table API 混合的程序。

Table API 是一種非常方便的應用開發(fā)接口，因為這經(jīng)支持表達式的程序編寫并提供了大量的內置函數(shù)。但是有時候用戶也需要切換回 DataStream，例如當用戶存在表達能力、靈活性或者 State 訪問的需求時。

Flink 新引入的 StreamTableEnvironment.toDataStream()/.fromDataStream() 可以將一個 DataStream API 聲明的 Source 或者 Sink 當作 Table 的 Source 或者 Sink 來使用。主要的優(yōu)化包括：

• DataStream 與 Table API 類型系統(tǒng)的自動轉換。
• Event Time 配置的無縫集成，Watermark 行為的高度一致性。
• Row 類型（即 Table API 中數(shù)據(jù)的表示）有了極大的增強，包括 toString() / hashCode() 和 equals() 方法的優(yōu)化，按名稱訪問字段值的支持與稀疏表示的支持。

Table table = tableEnv.fromDataStream(dataStream,Schema.newBuilder().columnByMetadata("rowtime", "TIMESTAMP(3)").watermark("rowtime", "SOURCE_WATERMARK()").build());DataStream<Row> dataStream = tableEnv.toDataStream(table).keyBy(r -> r.getField("user")).window(...);

SQL Client: 初始化腳本和語句集合 （Statement Sets）

SQL Client 是一種直接運行和部署 SQL 流或批作業(yè)的簡便方式，用戶不需要編寫代碼就可以從命令行調用 SQL，或者作為 CI / CD 流程的一部分。

這個版本極大的提高了 SQL Client 的功能。現(xiàn)在基于所有通過 Java 編程（即通過編程的方式調用 TableEnvironment 來發(fā)起查詢）可以支持的語法，現(xiàn)在 SQL Client 和 SQL 腳本都可以支持。這意味著 SQL 用戶不再需要添加膠水代碼來部署他們的SQL作業(yè)。

配置簡化和代碼共享

Flink 后續(xù)將不再支持通過 Yaml 的方式來配置 SQL Client（注：目前還在支持，但是已經(jīng)被標記為廢棄）。作為替代，SQL Client 現(xiàn)在支持使用一個初始化腳本在主 SQL 腳本執(zhí)行前來配置環(huán)境。

這些初始化腳本通常可以在不同團隊/部署之間共享。它可以用來加載常用的 catalog，應用通用的配置或者定義標準的視圖。

./sql-client.sh -i init1.sql init2.sql -f sqljob.sql

更多的配置項

通過增加配置項，優(yōu)化 SET / RESET 命令，用戶可以更方便的在 SQL Client 和 SQL 腳本內部來控制執(zhí)行的流程。

通過語句集合來支持多查詢

多查詢允許用戶在一個 Flink 作業(yè)中執(zhí)行多個 SQL 查詢（或者語句）。這對于長期運行的流式 SQL 查詢非常有用。

語句集可以用來將一組查詢合并為一組同時執(zhí)行。

以下是一個可以通過 SQL Client 來執(zhí)行的 SQL 腳本的例子。它初始化和配置了執(zhí)行多查詢的環(huán)境。這一腳本包括了所有的查詢和所有的環(huán)境初始化和配置的工作，從而使它可以作為一個自包含的部署組件。

-- set up a catalog CREATE CATALOG hive_catalog WITH ('type' = 'hive'); USE CATALOG hive_catalog;-- or use temporary objects CREATE TEMPORARY TABLE clicks (user_id BIGINT,page_id BIGINT,viewtime TIMESTAMP ) WITH ('connector' = 'kafka','topic' = 'clicks','properties.bootstrap.servers' = '...','format' = 'avro' );-- set the execution mode for jobs SET execution.runtime-mode=streaming;-- set the sync/async mode for INSERT INTOs SET table.dml-sync=false;-- set the job's parallelism SET parallism.default=10;-- set the job name SET pipeline.name = my_flink_job;-- restore state from the specific savepoint path SET execution.savepoint.path=/tmp/flink-savepoints/savepoint-bb0dab;BEGIN STATEMENT SET;INSERT INTO pageview_pv_sink SELECT page_id, count(1) FROM clicks GROUP BY page_id;INSERT INTO pageview_uv_sink SELECT page_id, count(distinct user_id) FROM clicks GROUP BY page_id;END;

Hive 查詢語法兼容性

用戶現(xiàn)在在 Flink 上也可以使用 Hive SQL 語法。除了 Hive DDL 方言之外，Flink現(xiàn)在也支持常用的 Hive DML 和 DQL 方言。

為了使用 Hive SQL 方言，需要設置 table.sql-dialect 為 hive 并且加載 HiveModule。后者非常重要，因為必須要加載 Hive 的內置函數(shù)后才能正確實現(xiàn)對 Hive 語法和語義的兼容性。例子如下：

CREATE CATALOG myhive WITH ('type' = 'hive'); -- setup HiveCatalog USE CATALOG myhive; LOAD MODULE hive; -- setup HiveModule USE MODULES hive,core; SET table.sql-dialect = hive; -- enable Hive dialect SELECT key, value FROM src CLUSTER BY key; -- run some Hive queries

需要注意的是， Hive 方言中不再支持 Flink 語法的 DML 和 DQL 語句。如果要使用 Flink 語法，需要切換回 default 的方言配置。

優(yōu)化的 SQL 時間函數(shù)

在數(shù)據(jù)處理中時間處理是一個重要的任務。但是與此同時，處理不同的時區(qū)、日期和時間是一個日益復雜的任務。

在 Flink 1.13 中，我們投入了大量的精力來簡化時間函數(shù)的使用。我們調整了時間相關函數(shù)的返回類型使其更加精確，例如 PROCTIME()，CURRENT_TIMESTAMP() 和 NOW()。

其次，用戶現(xiàn)在還可以基于一個 TIMESTAMP_LTZ 類型的列來定義 Event Time 屬性，從而可以優(yōu)雅的在窗口處理中支持夏令時。

用戶可以參考 Release Note 來查看該部分的完整變更。

PyFlink 核心優(yōu)化

這個版本對 PyFlink 的改進主要是使基于 Python 的 DataStream API 與 Table API 與 Java/scala 版本的對應功能更加一致。

Python DataStream API 中的有狀態(tài)算子

在 Flink 1.13 中，Python 程序員可以享受到 Flink 狀態(tài)處理 API 的所有能力。在 Flink 1.12 版本重構過的 Python DataStream API 現(xiàn)在已經(jīng)擁有完整的狀態(tài)訪問能力，從而使用戶可以將數(shù)據(jù)的信息記錄到 state 中并且在后續(xù)訪問。

帶狀態(tài)的處理能力是許多依賴跨記錄狀態(tài)共享（例如 Window Operator）的復雜數(shù)據(jù)處理場景的基礎。

以下例子展示了一個自定義的計算窗口的實現(xiàn)：

class CountWindowAverage(FlatMapFunction):def __init__(self, window_size):self.window_size = window_sizedef open(self, runtime_context: RuntimeContext):descriptor = ValueStateDescriptor("average", Types.TUPLE([Types.LONG(), Types.LONG()]))self.sum = runtime_context.get_state(descriptor)def flat_map(self, value):current_sum = self.sum.value()if current_sum is None:current_sum = (0, 0)# update the countcurrent_sum = (current_sum[0] + 1, current_sum[1] + value[1])# if the count reaches window_size, emit the average and clear the stateif current_sum[0] >= self.window_size:self.sum.clear()yield value[0], current_sum[1] // current_sum[0]else:self.sum.update(current_sum)ds = ... # type: DataStream ds.key_by(lambda row: row[0]) \.flat_map(CountWindowAverage(5))

PyFlink DataStream API 中的用戶自定義窗口

Flink 1.13 中 PyFlink DataStream 接口增加了對用戶自定義窗口的支持，現(xiàn)在用戶可以使用標準窗口之外的窗口定義。

由于窗口是處理無限數(shù)據(jù)流的核心機制 （通過將流切分為多個有限的『桶』），這一功能極大的提高的 API 的表達能力。

PyFlink Table API 中基于行的操作

Python Table API 現(xiàn)在支持基于行的操作，例如用戶對行數(shù)據(jù)的自定義函數(shù)。這一功能使得用戶可以使用非內置的數(shù)據(jù)處理函數(shù)。

一個使用 map() 操作的 Python Table API 示例如下：

@udf(result_type=DataTypes.ROW([DataTypes.FIELD("c1", DataTypes.BIGINT()),DataTypes.FIELD("c2", DataTypes.STRING())])) def increment_column(r: Row) -> Row:return Row(r[0] + 1, r[1])table = ... # type: Table mapped_result = table.map(increment_column)

除了 map()，這一 API 還支持 flat_map()，aggregate()，flat_aggregate() 和其它基于行的操作。這使 Python Table API 的功能與 Java Table API 的功能更加接近。

PyFlink DataStream API 支持 Batch 執(zhí)行模式

對于有限流，PyFlink DataStream API 現(xiàn)在已經(jīng)支持 Flink 1.12 DataStream API 中引入的 Batch 執(zhí)行模式。

通過復用數(shù)據(jù)有限性來跳過 State backend 和 Checkpoint 的處理，Batch 執(zhí)行模式可以簡化運維，并且提高有限流處理的性能。

其它優(yōu)化

基于 Hugo 的 Flink 文檔

Flink 文檔從 JekyII 遷移到了 Hugo。如果您發(fā)現(xiàn)有問題，請務必通知我們，我們非常期待用戶對新的界面的感受。

Web UI 支持歷史異常

Flink Web UI 現(xiàn)在可以展示導致作業(yè)失敗的 n 次歷史異常，從而提升在一個異常導致多個后續(xù)異常的場景下的調試體驗。用戶可以在異常歷史中找到根異常。

優(yōu)化失敗 Checkpoint 的異常和失敗原因的匯報

Flink 現(xiàn)在提供了失敗或被取消的 Checkpoint 的統(tǒng)計，從而使用戶可以更簡單的判斷 Checkpoint 失敗的原因，而不需要去查看日志。

Flink 之前的版本只有在 Checkpoint 成功的時候才會匯報指標（例如持久化數(shù)據(jù)的大小、觸發(fā)時間等）。

提供『恰好一次』一致性的 JDBC Sink

從 1.13 開始，通過使用事務提交數(shù)據(jù)，JDBC Sink 可以對支持 XA 事務的數(shù)據(jù)庫提供『恰好一次』的一致性支持。這一特性要求目標數(shù)據(jù)庫必須有（或鏈接到）一個 XA 事務處理器。

這一 Sink 現(xiàn)在只能在 DataStream API 中使用。用戶可以通過 JdbcSink.exactlyOnceSink(…) 來創(chuàng)建這一 Sink（或者通過顯式初始化一個 JdbcXaSinkFunction）。

PyFlink Table API 在 Group 窗口上支持用戶自定義的聚合函數(shù)

PyFlink Table API 現(xiàn)在對 Group 窗口同時支持基于 Python 的用戶自定義聚合函數(shù)（User-defined Aggregate Functions, UDAFs）以及 Pandas UDAFs。這些函數(shù)對許多數(shù)據(jù)分析或機器學習訓練的程序非常重要。

在 Flink 1.13 之前，這些函數(shù)僅能在無限的 Group-by 聚合場景下使用。Flink 1.13 優(yōu)化了這一限制。

Batch 執(zhí)行模式下 Sort-merge Shuffle 優(yōu)化

Flink 1.13 優(yōu)化了針對批處理程序的 Sort-merge Blocking Shuffle 的性能和內存占用情況。這一 Shuffle 模式是在Flink 1.12 的 FLIP-148 中引入的。

這一優(yōu)化避免了大規(guī)模作業(yè)下不斷出現(xiàn) OutOfMemoryError: Direct Memory 的問題，并且通過 I/O 調度和 broadcast 優(yōu)化提高了性能（尤其是在機械硬盤上）。

HBase 連接器支持異步維表查詢和查詢緩存

HBase Lookup Table Source 現(xiàn)在可以支持異步查詢模式和查詢緩存。這極大的提高了使用這一 Source 的 Table / SQL 維表 Join 的性能，并且在一些典型情況下可以減少對 HBase 的 I/O 請求數(shù)量。

在之前的版本中，HBase Lookup Source 僅支持同步通信，從而導致作業(yè)吞吐以及資源利用率降低。

升級 Flink 1.13 需要注意的改動

• FLINK-21709 – 老的 Table & SQL API 計劃器已經(jīng)被標記為廢棄，并且將在 Flink 1.14 中被刪除。Blink 計劃器在若干版本之前已經(jīng)被設置為默認計劃器，并且將成為未來版本中的唯一計劃器。這意味著 BatchTableEnvironment 和 DataSet API 互操作后續(xù)也將不再支持。用戶需要切換到統(tǒng)一的 TableEnvironment 來編寫流或者批的作業(yè)。
• FLINK-22352 – Flink 社區(qū)決定廢棄對 Apache mesos 的支持，未來有可能會進一步刪除這部分功能。用戶最好能夠切換到其它的資源管理系統(tǒng)上。
• FLINK-21935 – state.backend.async 這一配置已經(jīng)被禁用了，因為現(xiàn)在 Flink 總是會異步的來保存快照（即之前的配置默認值），并且現(xiàn)在沒有實現(xiàn)可以支持同步的快照保存操作。
• FLINK-17012 – Task 的 RUNNING 狀態(tài)被細分為兩步：INITIALIZING 和 RUNNING。Task 的 INITIALIZING 階段包括加載 state 和在啟用 unaligned checkpoint 時恢復 In-flight 數(shù)據(jù)的過程。通過顯式區(qū)分這兩種狀態(tài)，監(jiān)控系統(tǒng)可以更好的區(qū)分任務是否已經(jīng)在實際工作。
• FLINK-21698 – NUMERIC 和 TIMESTAMP 類型之間的直接轉換存在問題，現(xiàn)在已經(jīng)被禁用，例如 CAST(numeric AS TIMESTAMP(3))。用戶應該使用 TO_TIMESTAMP(FROM_UNIXTIME(numeric)) 來代替。
• FLINK-22133 – 新的 Source 接口有一個小的不兼容的修改，即 SplitEnumerator.snapshotState() 方法現(xiàn)在多接受一個 checkpoint id 參數(shù)來表示正在進行的 snapshot 操作所屬的 checkpoint 的 id。
• FLINK-19463 – 由于老的 Statebackend 接口承載了過多的語義并且容易引起困惑，這一接口被標記為廢棄。這是一個純 API 層的改動，而并不會影響應用運行時。對于如何升級現(xiàn)有作業(yè)，請參考作業(yè)遷移指引 。

其它資源

二進制和代碼可以從 Flink 官網(wǎng)的下載頁面獲得，最新的 PyFlink 發(fā)布可以從 PyPI 獲得。

如果想要升級到 Flink 1.13，請參考發(fā)布說明。這一版本與之前 1.x 的版本在標記為@Public 的接口上是兼容的。

用戶也可以查看新版本修改列表與更新后的文檔來獲得修改和新功能的詳細列表。

原文鏈接：
https://flink.apache.org/news/2021/05/03/release-1.13.0.html

原文鏈接：https://developer.aliyun.com/article/784199?

版權聲明：本文內容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的官宣｜Apache Flink 1.13.0 正式发布，流处理应用更加简单高效！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。