大數據面試題之Flink(3)

如何確定Flink任務的合理并行度??

Flink任務如何實現端到端一致??

Flink如何處理背(反)壓??

Flink解決數據延遲的問題?

Flink消費kafka分區的數據時flink件務并行度之間的關系?

使用flink-client消費kafka數據還是使用flink-connector消費?

如何動態修改Flink的配置，前提是Flink不能重啟?

Flink流批一體解釋一下?

說一下Flink的check和barrier?

說一下Flink狀態機制?

如何確定Flink任務的合理并行度??

1. 理解任務特性和需求

任務類型：CPU密集型任務可能需要較高的并行度來充分利用計算資源，而I/O密集型任務可能需要較低的并行度以減少資源競爭和網絡開銷。
數據分布：如果數據分布不均勻，可能會導致某些任務負載過重，影響整體性能。此時，調整并行度可以使數據分布更均勻。

2. 考慮集群資源限制

資源可用性：集群的資源（如CPU核心數、內存大小、網絡帶寬等）會限制可以設置的并行度。需要根據集群的實際情況來合理設置。
資源競爭：過高的并行度可能導致資源競爭加劇，反而降低整體性能。

3. 分析作業結構和數據流動

算子依賴關系：作業中不同算子之間的依賴關系會影響數據流動和并行度的設置。需要確保數據能夠高效地在算子之間傳遞。
數據傾斜：某些算子可能處理的數據量遠大于其他算子，導致數據傾斜。通過調整并行度可以減少數據傾斜的影響。

4. 實際應用中的設置方法

算子級并行度：通過調用setParallelism()方法可以在算子操作后設置其并行度。這種方法允許對特定算子進行精細控制。
作業級并行度：在創建執行環境后，可以通過調用setParallelism()方法設置全局的默認并行度。這種方法適用于對整個作業進行統一配置。
客戶端設置：在提交任務時，可以通過命令行接口（CLI）的-p參數或Java程序中的相應設置來指定并行度。
集群默認設置：在集群的配置文件（如flink-conf.yaml）中設置默認并行度，這將影響集群上提交的所有作業。

5. 監控和調整

監控執行情況：通過Flink的Web UI或其他監控工具監控作業的執行情況和集群資源利用率。
動態調整：根據實際情況動態調整并行度，以適應不同的工作負載和數據流量。

6. 注意事項

并行度與性能的關系：并行度并非越高越好，需要根據實際情況進行權衡。過高的并行度可能導致資源競爭和開銷增加，反而降低性能。
考慮未來擴展性：在設置并行度時，還需要考慮作業的擴展性和未來可能的需求變化。

綜上所述，確定Flink任務的合理并行度需要綜合考慮任務特性、集群資源限制、作業結構和數據流動等多個因素。通過實際應用中的設置方法和監控調整策略，可以不斷優化并行度設置，提高作業的執行效率和性能。

Flink任務如何實現端到端一致???

Apache Flink 實現端到端（End-to-End, E2E）一致性，主要是為了確保在分布式流處理過程中，每個數據記錄都被精確地處理一次（Exactly-Once），即使在面對系統故障時也不例外。以下是Flink實現端到端一致性的關鍵組成部分和步驟：

1、檢查點（Checkpoints）：

Flink 使用周期性的檢查點機制來保存流應用的快照，包括所有任務的狀態以及數據源的讀取位置。在發生故障時，系統可以從最近成功的檢查點恢復，確保狀態的一致性。

2、狀態一致性：

通過將狀態存儲在可持久化的狀態后端（如RocksDB State Backend），Flink能夠在故障恢復時重建任務狀態，保證狀態的一致性。

3、兩階段提交（Two-Phase Commit）：

在數據寫入外部系統（sink）時，Flink使用兩階段提交協議來保證輸出的一致性。在第一階段，數據被寫入臨時存儲；第二階段，一旦檢查點完成，數據才會被正式提交到sink。如果在這期間發生故障，數據將不會被正式提交，從而避免重復或丟失。

4、事務型sink：

為了確保sink端的一致性，Flink支持事務型sink。這些sink能夠與外部系統一起工作，使用事務來確保數據寫入的原子性和一致性。

5、Watermarks與Event Time處理：

Flink的watermark機制用于處理亂序事件，并在事件時間語義下保證結果的精確性。通過watermarks，Flink可以準確地識別處理進度，并在窗口聚合等操作中考慮時間界限，即使數據到達順序混亂也能保證結果的一致性。

6、冪等寫入：

對于不支持事務的sink，推薦實現冪等寫入邏輯，即多次寫入同一數據記錄的效果與寫入一次相同，以此來防止重復寫入導致的不一致性。

7、上下游對齊：

在有多個sink或復雜拓撲結構的應用中，確保所有sink都按照相同的檢查點對齊，是實現端到端一致性的關鍵。這意味著所有sink要么都成功提交了數據，要么都沒有提交，確保數據的一致性。

通過這些機制的綜合運用，Flink能夠在流處理管道的每一個環節保證數據處理的一致性，從數據源到最終的sink，實現真正的端到端一致性。

Flink如何處理背(反)壓??

1. 背壓的定義與影響

定義：背壓（Backpressure）是指當下游算子處理數據的速度不及上游算子傳遞數據的速度時，導致數據在網絡層或內存中堆積的現象。
影響：背壓會導致系統效率下降，吞吐量降低，延遲增大，甚至可能引發內存溢出和節點崩潰。

2. Flink的背壓處理機制
分布式阻塞隊列：Flink中的數據傳輸通過有界容量的分布式阻塞隊列來實現。這些隊列作為邏輯數據流，通過生產流和消費流管理的緩沖池來實現有界容量。
?1) 緩沖區動態管理：
緩沖池：緩沖池是緩沖區的集合，它們在使用后會被回收并重新使用。
動態調整：緩沖池的大小在運行時會根據系統負載和可用內存動態變化。
?2) 任務間數據傳輸：
本地交換：如果兩個任務在同一工作節點（TaskManager）上運行，緩沖區可以直接傳遞給下一個任務。
遠程交換：如果任務分布在不同的工作節點上，緩沖區通過TCP通道發送，并在接收端復制到輸入緩沖池的緩沖區中。
?3) Watermark機制：Flink使用Watermark機制控制網絡中的數據傳輸量，避免過多數據在傳輸途中積壓。
3. Flink處理背壓的具體措施
動態調整并行度：
根據系統負載情況動態調整任務的并行度，將任務分配到更多的計算節點上，以提高系統的處理能力。
例如，如果Kafka作為數據源，且Flink任務的并行度小于Kafka的分區數，可以增加Flink任務的并行度以匹配Kafka的分區數。
使用緩沖區：
緩沖區可以暫時存儲無法立即處理的數據，避免數據丟失和延遲增加。
理想情況下，緩沖區應該是可持久化的，以防止在故障恢復時數據丟失。
優化資源配置：
增加計算資源，如CPU、內存和網絡帶寬，以提高系統的整體處理能力。
調整Flink配置，如增加緩沖數據的時間、開啟反壓機制等。
任務鏈調整：
根據任務的依賴關系和資源的分配情況，合理調整任務鏈，以提高任務的并行度和系統的處理能力。
4. Flink背壓處理的優勢
自然傳播：Flink的背壓機制能夠自然地在整個數據流管道中傳播，確保任務生產數據的速度不會超過消費的速度。
靈活性：Flink允許通過調整并行度、使用緩沖區、優化資源配置和任務鏈等方式來靈活應對背壓問題。
高效性：通過有界容量的分布式阻塞隊列和動態調整的緩沖池，Flink能夠在不犧牲數據一致性的前提下高效地處理背壓問題。
綜上所述，Flink通過其內部的數據流引擎和分布式阻塞隊列機制，結合動態調整并行度、使用緩沖區、優化資源配置和任務鏈調整等措施，能夠有效地處理背壓問題，確保數據流管道的穩定性和高效性。

Flink解決數據延遲的問題?

1. 優化數據輸入環節

增加并發度：當數據來源的數據增長速度過快時，可以通過增加Flink消費者的并發度來加快數據處理速度。使用分區和并行流的方式處理數據，確保消費者能夠快速地處理大量數據。
數據源優化：確保數據源穩定可靠，減少因數據源問題導致的延遲。

2. 優化數據輸出環節

優化輸出方式：使用緩存和批處理的方式輸出數據，以提高輸出速度，減少因輸出過程緩慢導致的數據延遲。

3. 優化中間處理環節

去除重復代碼：優化Flink程序自身，去除重復代碼，減少不必要的計算開銷。
避免任務堆積：確保程序中的任務不會堆積，避免資源過度消耗。
監控與調優：使用合適的檢測工具來監測程序性能和運行狀態，及時發現并解決潛在的性能瓶頸。

4. 利用Flink內置機制
?1) Watermarks（水位線）：
定義：水位線是Flink中用于標識事件時間進展的機制，通過水位線來觸發窗口計算。
作用：通過設置適當的水位線，可以容忍一定程度的亂序和延遲，確保數據在正確的時間窗口內被處理。
配置：可以使用assignTimestampsAndWatermarks方法為數據流分配時間戳和水位線。
?2) 窗口處理機制：
定義：Flink的窗口操作對處理延遲數據提供了很好的支持，窗口會根據水位線來劃分時間。
allowedLateness：允許在窗口關閉后繼續接受延遲到達的數據，并設置最大延遲時間。
側輸出（Side Output）：將延遲的數據發送到一個額外的流中，以便單獨處理，不影響主窗口的計算邏輯。
定時器（Timers）：
在Keyed Stream上注冊定時器，用于處理延遲事件。
當定時器觸發時，可以執行自定義的處理邏輯，如重新觸發窗口計算或發出警告。
5. 配置與執行

合理設置并行度：根據集群資源和任務特性，合理設置Flink任務的并行度，以提高數據處理效率。
執行環境配置：在創建Flink執行環境時，根據需求配置相關參數，如時間特性、狀態后端等。

6. 監控與調優

實時監控：通過Flink的Web UI或其他監控工具實時監控作業的執行情況和集群資源利用率。
動態調整：根據監控結果動態調整并行度、緩沖區大小等參數，以應對不同的工作負載和數據流量。

7. 外部因素處理

增加計算集群資源：如內存、CPU等，以提高系統整體處理能力。
優化網絡連接：確保網絡穩定可靠，減少因網絡問題導致的數據延遲。
處理硬件故障：及時發現并處理硬件故障，避免對系統性能造成影響。

綜上所述，Flink通過優化數據輸入輸出環節、中間處理環節、利用內置機制、合理配置與執行、監控與調優以及處理外部因素等多方面措施，有效解決數據延遲問題，確保流處理任務的實時性和準確性。

Flink消費kafka分區的數據時flink件務并行度之間的關系?

一、Flink并行度的定義
在Flink中，并行度是指一個算子（Operator）被拆分成多個并行實例（subtask）的數量。這些并行實例可以分布在不同的機器或容器上執行，以提高數據處理的并發性和吞吐量。

二、Kafka分區的定義
Kafka中的Topic被分成多個分區（Partition），每個分區都是一個有序的消息隊列。分區是Kafka實現水平擴展和提高吞吐量的關鍵機制。

三、Flink并行度與Kafka分區數量的關系
?1) 并行度大于分區數：

情況：當Flink任務的并行度大于Kafka分區的數量時，多余的并行度將處于空閑狀態，因為它們無法從Kafka分區中獲取數據來消費。
影響：這會導致資源浪費，因為空閑的并行度沒有執行任何有用的工作。同時，如果Flink任務配置了檢查點（Checkpoint）機制，空閑的并行度可能會影響檢查點的執行，因為檢查點需要所有并行度都參與才能完成。

?2) 并行度小于分區數：
情況：當Flink任務的并行度小于Kafka分區的數量時，每個Flink并行度將需要消費多個Kafka分區的數據。
影響：

數據傾斜：如果Kafka分區之間的數據量分布不均勻，那么消費多個分區的Flink并行度可能會面臨更大的處理壓力，導致數據傾斜問題。
吞吐量受限：如果數據量大且并行度較低，單個Flink并行度可能無法及時處理所有數據，從而影響整體的吞吐量。

?3) 并行度等于分區數：
情況：這是最理想的情況，Flink的每個并行度都對應一個Kafka分區，形成一對一的映射關系。
影響：

資源利用最大化：每個Flink并行度都能充分利用其處理能力，不會有空閑的并行度。
負載均衡：數據在Flink并行度之間均勻分布，有助于實現負載均衡，避免數據傾斜問題。
高效吞吐量：在資源充足的情況下，可以實現較高的數據吞吐量。

四、總結
因此，在設置Flink消費Kafka數據時，建議將Flink任務的并行度設置為與Kafka分區的數量相等或略大于分區數（但不宜過多），以平衡資源利用、負載均衡和吞吐量之間的關系。如果Kafka分區數量較多，而Flink集群資源有限，可以考慮通過增加Flink集群的資源（如節點數量、CPU和內存）來提高并行處理能力。同時，也可以根據實際的數據處理需求和性能要求，靈活調整并行度以達到最佳效果。

使用flink-client消費kafka數據還是使用flink-connector消費?

使用flink-connector-kafka
flink-connector-kafka是Flink官方提供的一個連接器，用于將Flink與Kafka集成。通過這個連接器，你可以很方便地在Flink程序中讀取Kafka中的消息，也可以將處理后的數據寫入Kafka。

優點：

官方支持：由Apache Flink官方開發和維護，穩定性和兼容性有保障。
功能豐富：支持多種Kafka版本，提供了靈活的序列化/反序列化接口，以及多種消費模式（如exactly-once語義）。
易于集成：只需在項目中添加相應的依賴，即可在Flink作業中通過簡單的API調用來消費Kafka數據。

使用示例：
在Flink項目中，你首先需要添加flink-connector-kafka的依賴到你的pom.xml（如果是Maven項目）或build.gradle（如果是Gradle項目）中。

然后，在你的Flink作業中，你可以使用FlinkKafkaConsumer來創建一個Kafka數據源，并配置相應的參數（如Kafka集群地址、主題、序列化方式等）。

Properties props = new Properties(); ?
props.setProperty("bootstrap.servers", "localhost:9092"); ?
props.setProperty("group.id", "testGroup"); ?FlinkKafkaConsumer<String> myConsumer = new FlinkKafkaConsumer<>( ?"my-topic", ? ? ? ? ? ? ? ? // Kafka主題 ?new SimpleStringSchema(), ? // 序列化模式 ?props); ?DataStream<String> stream = env.addSource(myConsumer);

總結
因此，當你想在Flink中消費Kafka數據時，你應該使用flink-connector-kafka，而不是flink-client。flink-client主要用于與Flink集群進行交互，如提交作業、查看作業狀態等，而不直接參與數據處理流程。

如何動態修改Flink的配置，前提是Flink不能重啟?

1. 使用配置中心
配置中心（如Apollo、Nacos、Spring Cloud Config等）能夠集中管理應用的配置，并在配置修改后實時推送到應用端。對于Flink作業來說，可以通過集成這些配置中心來動態獲取配置變更。

步驟概述：

引入依賴：首先，需要在Flink項目中引入所選配置中心的客戶端依賴。
配置連接信息：在Flink作業的初始化階段，配置連接到配置中心所需的信息，如服務地址、命名空間等。
監聽配置變更：通過配置中心提供的API監聽特定配置項的變化。當配置變更時，配置中心會通知Flink作業。
應用新配置：Flink作業在接收到配置變更通知后，需要解析新的配置值，并根據需要更新作業中的相關組件或邏輯。

示例（以Nacos為例）：

// 引入Nacos客戶端依賴 ?
// ... ?// 在Flink作業的Source中監聽Nacos配置變更 ?
public class NacosConfigSource extends RichSourceFunction<String> { ?private ConfigService configService; ?private String config; ?@Override ?public void open(Configuration parameters) throws Exception { ?super.open(parameters); ?// 初始化Nacos連接并監聽配置變更 ?Properties properties = new Properties(); ?properties.put("serverAddr", "nacos服務地址"); ?properties.put("namespace", "命名空間ID"); ?configService = NacosFactory.createConfigService(properties); ?String dataId = "配置ID"; ?String group = "配置組"; ?config = configService.getConfig(dataId, group, 5000); ?configService.addListener(dataId, group, new Listener() { ?@Override ?public void receiveConfigInfo(String configInfo) { ?// 收到配置變更通知后，更新config變量 ?config = configInfo; ?// 可能還需要觸發Flink作業中的某些邏輯來應用新配置 ?} ?@Override ?public Executor getExecutor() { ?return null; // 使用默認執行器 ?} ?}); ?} ?@Override ?public void run(SourceContext<String> ctx) throws Exception { ?// 在這里可以周期性地打印或處理config變量 ?while (isRunning) { ?// ... ?} ?} ?
}

2. 自定義Source讀取配置
如果不想使用配置中心，也可以通過自定義Source來讀取配置變更。這種方法需要自行實現配置的存儲、讀取和變更通知機制。

步驟概述：

設計配置存儲：確定配置信息的存儲方式，可以是文件、數據庫或內存等。
實現自定義Source：創建一個Flink Source Function，用于從配置存儲中讀取配置信息。
輪詢或監聽配置變更：在自定義Source中，實現輪詢機制或監聽機制來檢測配置變更。
輸出配置變更：當檢測到配置變更時，將新的配置信息作為數據流輸出。
處理配置變更：在Flink作業的其他部分，通過連接自定義Source輸出的數據流來接收配置變更，并應用新配置。

注意事項

動態修改Flink配置時，需要確保新配置的有效性，避免因為配置錯誤導致作業異常。
配置變更的實時性取決于配置中心的通知機制和Flink作業的輪詢/監聽頻率。
某些配置可能無法在不重啟Flink作業的情況下更改，這取決于Flink的內部實現和配置項的性質。

Flink流批一體解釋一下?

一、概念概述

流批一體：指Flink能夠在同一個框架和API下，無縫地處理實時數據流（無界數據流）和批處理數據（有界數據流），而不需要為不同的數據處理模式編寫不同的代碼。

二、主要優勢

低延遲和高吞吐量：Flink的設計使其在處理實時數據流時具有極低的延遲，并且能夠保持高吞吐量，這對于需要快速響應的應用場景至關重要。
代碼復用：用戶可以使用相同的API和算法處理實時數據和歷史數據，降低了開發和維護成本。
統一的數據處理模型：Flink提供了一個統一的數據處理模型，使得用戶可以更容易地構建復雜的數據處理流程。

三、核心機制

DataStream API：Flink的DataStream API提供了一個統一的編程模型，可以同時處理無界和有界數據流。這意味著用戶可以使用相同的API來處理實時數據和歷史數據。
狀態管理：Flink是一種有狀態的流計算引擎，它提供了內置的狀態管理機制，可以把工作狀態存儲在Flink內部，而不需要依賴外部系統。這有助于降低對外部系統的依賴，提高性能和可維護性。
容錯恢復：Flink通過Checkpoint機制來實現容錯恢復。Checkpoint能夠定期將Flink的狀態進行存儲，相當于做一次快照，以便在發生故障時從最后一個成功的Checkpoint恢復狀態。

四、應用場景
Flink流批一體的特性使其在多個領域都有廣泛的應用，包括但不限于：

實時數據處理：如從IoT設備、社交媒體、金融交易等來源獲取的數據。
數據分析：對大量數據進行實時或離線分析，如計算數據的平均值、最大值、最小值等。
模型訓練和預測：使用Flink對批處理數據進行模型訓練，并將訓練好的模型應用于實時流數據的預測和分析。

五、實現原理

SQL層：Flink的SQL層支持bound和unbound數據集的處理，使得用戶可以使用SQL語句來執行流計算和批計算。
DataStream API層：DataStream API是Flink中用于處理數據流的主要API，它提供了豐富的操作符來支持數據的轉換、過濾、聚合等操作。無論是無界數據流還是有界數據流，都可以使用DataStream API來處理。
Scheduler層：Scheduler層主要負責將作業的DAG（有向無環圖）轉化為在分布式環境中可以執行的Task。Flink的Scheduler支持多種調度策略，以確保作業的高效執行。

六、總結
Flink流批一體的特性使得它成為處理大數據和實時數據的強大工具。通過提供統一的數據處理模型和API，Flink降低了開發和維護成本，提高了數據處理的靈活性和效率。無論是在實時數據處理還是批處理領域，Flink都展現出了卓越的性能和廣泛的應用前景。

說一下Flink的check和barrier?

Flink的Checkpoint機制
1. 基本概念

Checkpoint：是Flink中用于實現容錯的一種機制，通過周期性地創建應用流圖狀態的全局快照來實現。當系統發生故障時，可以從最近成功的Checkpoint快照恢復，從而實現Exactly-Once處理語義。

2. 工作原理

Checkpoint Coordinator：在Flink應用啟動時，由JobManager創建Checkpoint Coordinator，負責發起和協調整個作業的Checkpoint過程。
Barrier Injection：Checkpoint Coordinator定期向數據流中的Source算子發送Barrier，Barrier在數據流中按順序傳播，每個算子接收到Barrier后暫停處理新的數據記錄，并將其當前狀態snapshot化。
狀態持久化：各算子將本地狀態異步寫入預設的持久化存儲，如HDFS、RocksDB等。
確認完成與全局一致性：所有算子完成狀態快照后，會通知Checkpoint Coordinator，只有當所有參與Checkpoint的算子都成功完成了狀態持久化，這個Checkpoint才會被標記為“已完成”。
故障恢復：若在處理過程中某部分失敗，Flink會從最近的已完成Checkpoint進行狀態恢復，重新構建出一致的數據流視圖。

3. 關鍵參數與配置

Checkpoint間隔：設置Checkpoint的觸發間隔，需要根據實際工作負載和性能要求進行調整。
超時時間：Checkpoint需要在一定時間內完成，超時未完成則會被取消，需要設置合理的超時時間。
狀態大小管理：大型狀態可能導致Checkpoint時間過長或存儲壓力過大，需要監控和優化狀態大小，必要時可采用分片或增量Checkpoint策略。
失敗策略：配置失敗后的處理策略，如是否禁用作業或選擇重試次數。

Barrier的作用
1. Barrier的生成與傳播

Barrier是由Checkpoint Coordinator生成的，并隨著數據流傳播到各個算子。
每個算子在接收到Barrier后，會暫停處理新的數據記錄，并準備進行狀態的快照。

2. Barrier的對齊

當一個算子有多個輸入流時，Barrier需要對齊以確保所有輸入流在同一時間點進行快照。
快的Barrier到達后會等待慢的Barrier，直到所有Barrier都到達后，算子才進行快照。
Barrier對齊是實現Exactly-Once語義的關鍵。

3. Barrier的變種

Unaligned Checkpoint：Flink 1.11后引入了Unaligned Checkpoint，允許在不完全對齊的Barrier下進行Checkpoint，以優化性能。
Unaligned Checkpoint會立即對當前算子及其已接收的數據進行快照，而不必等待所有輸入流的Barrier都到達。

總結
Flink的Checkpoint機制和Barrier是實現容錯和狀態一致性管理的核心。通過定期創建全局快照，并在發生故障時從最近的Checkpoint恢復，Flink能夠確保數據處理的一致性和可靠性。同時，Barrier的生成、傳播和對齊機制是實現Exactly-Once語義的關鍵。在配置和使用時，需要根據實際情況調整Checkpoint的間隔、超時時間等參數，并關注狀態大小管理和失敗策略的配置。

說一下Flink狀態機制?

一、狀態類型
Flink支持兩種主要類型的狀態：

?1) 算子狀態（Operator State）：

與單個算子或任務相關聯的狀態，通常用于維護整個算子跨并行子任務（Subtask）間的共享數據。
例如，在窗口操作中，可以在算子狀態中存儲累加器值。
算子狀態通常是局部的，每個任務都有自己的一份，不能由相同或不同算子的另一個任務訪問。
具體類型包括聯合列表狀態（Union list state）、廣播狀態（Broadcast state）等。

2) 鍵控狀態（Keyed State）：

與特定鍵（key）相關聯的狀態，用于存儲每個鍵的狀態數據。
例如，在分組操作中，可以使用鍵控狀態來存儲每個分組的累加器值。
鍵控狀態可以被不同的任務共享，以實現全局狀態共享。
具體類型包括ValueState、ListState、ReducingState、AggregatingState、MapState等。

二、狀態后端
?1) MemoryStateBackend：
將狀態數據存儲在內存中，適用于小規模狀態。
由于內存限制，可能不適用于大規模或長時間運行的作業。
?2) FsStateBackend：
將狀態數據存儲在分布式文件系統中，如HDFS。
提供了更大的存儲能力，但訪問速度可能略慢于內存存儲。
?3) RocksDBStateBackend：
使用RocksDB數據庫引擎來管理狀態，適用于大規模狀態和長時間運行的作業。
將部分狀態數據存儲在RocksDB數據庫中，利用磁盤空間進行擴展，同時保持較高的訪問性能。
三、狀態生命周期
狀態的生命周期與作業的生命周期相關：

狀態在作業啟動時創建。
在作業運行期間，狀態數據會根據需要進行更新和訪問。
在作業取消時，狀態數據會被清除。

四、一致性模式
Flink支持不同的鍵控狀態一致性模式：

?1) At-Least-Once：
確保在發生故障時不會丟失任何狀態數據，但可能會有重復的數據。
?2) Exactly-Once：
確保每個鍵的狀態數據在發生故障時不會丟失，也不會重復。
需要與檢查點（Checkpoint）機制結合使用，以實現精確的狀態一致性。
?3) None（無狀態）：
不提供一致性保障，適用于不需要狀態管理的情況。
五、檢查點（Checkpoint）機制
Flink的狀態機制與檢查點機制緊密結合：