Flink 任務管理器重啟后不處理數據

Question

我是 flink 的新手，我部署了我的 flink 應用程序，它基本上執行簡單的模式匹配。 部署在Kubernetes集群，1個JM，6個TM。 我每 10 分鍾向 eventthub 主題發送大小為 4.4k 和 200k 的消息並執行負載測試。 我添加了重啟策略並檢查指向如下，我沒有在我的代碼中明確使用任何狀態，因為不需要它

 StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

 // start a checkpoint every 1000 ms
 env.enableCheckpointing(interval, CheckpointingMode.EXACTLY_ONCE);
 // advanced options:
 // make sure 500 ms of progress happen between checkpoints
 env.getCheckpointConfig().setMinPauseBetweenCheckpoints(1000);
 // checkpoints have to complete within one minute, or are discarded
 env.getCheckpointConfig().setCheckpointTimeout(120000);
 // allow only one checkpoint to be in progress at the same time
 env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
 // enable externalized checkpoints which are retained after job cancellation
 env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
 // allow job recovery fallback to checkpoint when there is a more recent savepoint
 env.getCheckpointConfig().setPreferCheckpointForRecovery(true);

 env.setRestartStrategy(RestartStrategies.fixedDelayRestart(
         5, // number of restart attempts
         Time.of(5, TimeUnit.MINUTES) // delay
 ));

最初我遇到網絡緩沖區的Netty服務器問題，我點擊了這個鏈接https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/config.html#taskmanager-network-memory-floating -buffers-per-gate flink 網絡和堆 memory 優化並應用以下設置，一切正常

taskmanager.network.memory.min: 256mb
taskmanager.network.memory.max: 1024mb
taskmanager.network.memory.buffers-per-channel: 8
taskmanager.memory.segment-size: 2mb
taskmanager.network.memory.floating-buffers-per-gate: 16
cluster.evenly-spread-out-slots: true
taskmanager.heap.size: 1024m
taskmanager.memory.framework.heap.size: 64mb
taskmanager.memory.managed.fraction: 0.7
taskmanager.memory.framework.off-heap.size: 64mb
taskmanager.memory.network.fraction: 0.4
taskmanager.memory.jvm-overhead.min: 256mb
taskmanager.memory.jvm-overhead.max: 1gb
taskmanager.memory.jvm-overhead.fraction: 0.4

但我有以下兩個問題

1. 如果任何任務管理器由於任何故障而重新啟動，則任務管理器將成功重新啟動並注冊到作業管理器，但在重新啟動的任務管理器不執行任何數據處理后，它將處於空閑狀態。 這是正常的 flink 行為還是我需要添加任何設置以使任務管理器再次開始處理。

2. 抱歉，如果我的理解有誤，請糾正我，flink 在我的代碼中有重啟策略，我限制了 5 次重啟嘗試。 如果我的 flink 作業沒有成功克服任務失敗會發生什么整個 flink 作業將保持在空閑 state 並且我必須手動重新啟動作業或者我可以添加任何機制來重新啟動我的作業，即使它超過了重新啟動的限制工作嘗試。

3. 是否有任何文件可以根據我的系統接收數據的數據大小和速率來計算核心數和 memory 我應該分配給 flink 作業集群？

4. 有沒有關於 flink CEP 優化技術的文檔？

5. 這是我在作業管理器中看到的錯誤堆棧跟蹤

5. 在模式匹配之前，我在作業管理器日志中看到以下錯誤

   原因：org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException：遠程任務管理器'/10.244.9.163:46377'意外關閉連接。 這可能表明遠程任務管理器丟失了。 at org.apache.flink.runtime.io.network.netty.CreditBasedPartitionRequestClientHandler.channelInactive(CreditBasedPartitionRequestClientHandler.java:136) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java: 257) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:243) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive( AbstractChannelHandlerContext.java:236) at org.apache.flink.shaded.netty4.io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:393) at org.apache.flink.shaded.netty4.io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:358) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext .java:257) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:243) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext .fireChannelInactive(AbstractChannelHandlerContext.java:236) at org.apache.flink.shaded.netty4.io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1416) at org.ZB6EFD606D118D0F6 2066E31419FF04CCZ.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:257) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:243 ) at org.apache.flink.shaded.netty4.io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:912) at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannel$AbstractUnsafe$8. run(AbstractChannel.java:816) at org.apache.flink.shaded.netty4.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) at org.apache.flink.shaded.netty4.io. netty.util.concur rent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:416) at org.apache.flink.shaded.netty4.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:515) at org.apache.flink.shaded. netty4.io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918) at org.apache.flink.shaded.netty4.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74 ) 在 java.lang.Thread.run(Thread.java:748)

在此先感謝，請幫助我解決我的疑問

Answer 1

各種點：

如果您的模式涉及匹配時間序列（例如，“A 后跟 B”），那么您需要 state 來執行此操作。 Flink 的大部分 source 和 sink 也在內部使用 state 來記錄偏移量等，如果你關心完全一次性保證，這個 state 需要檢查點。 如果模式是動態流入的，那么您也需要將模式存儲在 Flink state 中。

代碼中的一些注釋與配置參數不匹配：例如，“500 ms 的進度”vs. 1000，“檢查點必須在一分鍾內完成”vs 120000。另外，請記住文檔的部分您從中復制這些設置並不是推薦最佳做法，而是說明如何進行更改。 特別是env.getCheckpointConfig().setPreferCheckpointForRecovery(true); 是個壞主意，並且該配置選項可能不應該存在。

您在 config.yaml 中的一些條目與此有關。 taskmanager.memory.managed.fraction相當大（0.7）——這僅在您使用 RocksDB 時才有意義，因為托管 memory 沒有其他流媒體用途。 而taskmanager.memory.network.fraction和taskmanager.memory.jvm-overhead.fraction都很大，這三個分數的和是1.5，沒有意義。

通常，默認網絡配置適用於廣泛的部署場景，需要調整這些設置是不常見的，除非在大型集群中（這里不是這種情況）。 你遇到過什么樣的問題？

至於你的問題：

1. 在 TM 故障和恢復后，TM 應自動從最近的檢查點恢復處理。 要診斷為什么沒有發生這種情況，我們需要更多信息。 要獲得正確處理此問題的部署經驗，您可以嘗試Flink Operations Playground 。

2. 一旦配置的重啟策略執行完畢，作業將失敗，Flink 將不再嘗試恢復該作業。 當然，如果你想要更復雜的東西，你可以在 Flink 的 REST API 之上構建自己的自動化。

3. 關於容量規划的文檔？ 不，不是。 這通常是通過反復試驗來解決的。 不同的應用程序往往以難以預料的方式具有不同的要求。 諸如您選擇的序列化程序、state 后端、keyBy 的數量、源和接收器、密鑰偏移、水印等都會產生重大影響。

4. 關於優化 CEP 的文檔？ 不，對不起。 要點是

   • 盡你所能限制比賽； 避免必須無限期保留 state 的模式
   • getEventsForPattern可能很昂貴