KafkaSource检查点的end to end duration较长（1min）原因

[yidan zhao <hi...@gmail.com>]

如题，我任务的检查点（对齐检查点）大多数时间成功，偶现失败。目前针对超时类失败做了分析，存在部分特点，希望大佬们分析下原因。

（1）KafkaSouce的e2e时间达到1min+，正常xxx
ms就结束了。同时对应e2e达到1min+的情况下，sync、async、alignment、start delay等都为0，偶尔几个x
ms的。   这个不是很明白什么情况会是这样呢？

（2）对于部分task，start delay假设为31s，alignment duration为43s，但是processed
data才xxxKB（几十到几百KB）。从我任务的正常处理情况对比来说，这个数据量几乎不需要时间就能处理完。

（3）有个window算子（前边是hash进来，keyBy的），检查点时间1m14s。然后看了下subtask的检查点，大多数都是2s内完成，其中1个subtask耗时1m14s。这个subtask对应的start-delay为1m13s。
 这个就更奇怪了，首先前边是keyBy，所以是hash分区方式进入window算子。那么，对于正常subtask0，其start_delay为1s，那么subtask0收到第一个barrier耗时1s，假设这个barrier来自上游算子的
0 号子任务（preTask0）。那么preTask0既然已经发送了barrier，对于window任务的异常subtask就应该也能很快收到barrier，可是实际却耗时1min14s（start
delay）。

Re: KafkaSource检查点的end to end duration较长（1min）原因

[yidan zhao <hi...@gmail.com>]

存在间断性周期性反压。  因为有window算子，时间窗口触发。

熊云昆 <xi...@163.com> 于2021年6月21日周一 下午11:03写道：
>
> 我觉得问题是不是出在反压上面，你的job是不是有反压？
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 在 2021-06-21 10:38:36，"yidan zhao" <hi...@gmail.com> 写道：
> >如题，我任务的检查点（对齐检查点）大多数时间成功，偶现失败。目前针对超时类失败做了分析，存在部分特点，希望大佬们分析下原因。
> >
> >（1）KafkaSouce的e2e时间达到1min+，正常xxx
> >ms就结束了。同时对应e2e达到1min+的情况下，sync、async、alignment、start delay等都为0，偶尔几个x
> >ms的。   这个不是很明白什么情况会是这样呢？
> >
> >（2）对于部分task，start delay假设为31s，alignment duration为43s，但是processed
> >data才xxxKB（几十到几百KB）。从我任务的正常处理情况对比来说，这个数据量几乎不需要时间就能处理完。
> >
> >（3）有个window算子（前边是hash进来，keyBy的），检查点时间1m14s。然后看了下subtask的检查点，大多数都是2s内完成，其中1个subtask耗时1m14s。这个subtask对应的start-delay为1m13s。
> > 这个就更奇怪了，首先前边是keyBy，所以是hash分区方式进入window算子。那么，对于正常subtask0，其start_delay为1s，那么subtask0收到第一个barrier耗时1s，假设这个barrier来自上游算子的
> >0 号子任务（preTask0）。那么preTask0既然已经发送了barrier，对于window任务的异常subtask就应该也能很快收到barrier，可是实际却耗时1min14s（start
> >delay）。

Re:KafkaSource检查点的end to end duration较长（1min）原因

[熊云昆 <xi...@163.com>]

我觉得问题是不是出在反压上面，你的job是不是有反压？

















在 2021-06-21 10:38:36，"yidan zhao" <hi...@gmail.com> 写道：
>如题，我任务的检查点（对齐检查点）大多数时间成功，偶现失败。目前针对超时类失败做了分析，存在部分特点，希望大佬们分析下原因。
>
>（1）KafkaSouce的e2e时间达到1min+，正常xxx
>ms就结束了。同时对应e2e达到1min+的情况下，sync、async、alignment、start delay等都为0，偶尔几个x
>ms的。   这个不是很明白什么情况会是这样呢？
>
>（2）对于部分task，start delay假设为31s，alignment duration为43s，但是processed
>data才xxxKB（几十到几百KB）。从我任务的正常处理情况对比来说，这个数据量几乎不需要时间就能处理完。
>
>（3）有个window算子（前边是hash进来，keyBy的），检查点时间1m14s。然后看了下subtask的检查点，大多数都是2s内完成，其中1个subtask耗时1m14s。这个subtask对应的start-delay为1m13s。
> 这个就更奇怪了，首先前边是keyBy，所以是hash分区方式进入window算子。那么，对于正常subtask0，其start_delay为1s，那么subtask0收到第一个barrier耗时1s，假设这个barrier来自上游算子的
>0 号子任务（preTask0）。那么preTask0既然已经发送了barrier，对于window任务的异常subtask就应该也能很快收到barrier，可是实际却耗时1min14s（start
>delay）。