检查点的start-delay、alignment duration理解。

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

如题，文档
https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/
。

我目前情况是，有个任务，从kafka读取数据，写hive，orc格式，带了compact功能，align 模式。
目前发现DAG为4个Task，分别为：
Task1: Source: TableSourceScan.... ... ... -> streaming-writer 并行度60
Task2: compact-coordinator 并行度1
Task3: compact-operator 并行度60
Task4: PartitionCommitter -> Sink: end 并行度1

目前观察到检查点存在超时，我给一个ckpt数据，耗时18min30s，如下是E2E时长。
Task1: 49s。
Task2: 1s。
Task3: 18min20s。
Task4: 18min30s。
继续观察Task3的subtask的detail信息，compact-operator算子ckpt显示数据是非常小，几乎没有。同时alignment
duration都是0ms，也就是不存在对齐时长。 但是 start-delay 却很长，有的达到16min左右，不清楚这个是为啥？

目前根据文档分析下来，start-delay是从第一个barrier创建 到
该barrier到达该subtask的时长，不清楚我这个DAG任务情况下，是什么导致这个情况呢？
为什么第一个barrier到达都这么耗时。

Re: 检查点的start-delay、alignment duration理解。

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

我根据webui的task2节点（coordinator）的watermark来看，部分情况会出现task2被反压。

我目前理解是，ckpt完成后，才开始compcat。如果task2出现反压，意味着ckpt2发生时，ckpt1对应的compact可能还未完成。
不清楚理解是否正确呢？

yidan zhao <hi...@gmail.com> 于2021年11月25日周四 下午3:34写道：

> Task3就是compact，具体jstack可能有点复杂，本身每个算子在每个机器上都有，jstack也不好分辨具体那个线程。
>
> 目前来看我1h有100G的数据，使用的60并行度，这个配置按照我的其他流统计是没问题了，消费肯定没问题，不清楚是否受到hdfs性能的影响。
>
> Caizhi Weng <ts...@gmail.com> 于2021年11月25日周四 上午10:32写道：
>
>> Hi！
>>
>> 这个 checkpoint 时间的差距确实不太符合预期，因为 compact 一般都是比较快的。建议看一下 task3 的 jstack 以及 gc
>> 情况，确认是不是 task3 gc 严重阻塞 checkpoint，以及 task3 具体在做什么。
>>
>> yidan zhao <hi...@gmail.com> 于2021年11月24日周三 下午7:03写道：
>>
>> > 如题，文档
>> >
>> >
>> https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/
>> > 。
>> >
>> > 我目前情况是，有个任务，从kafka读取数据，写hive，orc格式，带了compact功能，align 模式。
>> > 目前发现DAG为4个Task，分别为：
>> > Task1: Source: TableSourceScan.... ... ... -> streaming-writer 并行度60
>> > Task2: compact-coordinator 并行度1
>> > Task3: compact-operator 并行度60
>> > Task4: PartitionCommitter -> Sink: end 并行度1
>> >
>> > 目前观察到检查点存在超时，我给一个ckpt数据，耗时18min30s，如下是E2E时长。
>> > Task1: 49s。
>> > Task2: 1s。
>> > Task3: 18min20s。
>> > Task4: 18min30s。
>> >
>> 继续观察Task3的subtask的detail信息，compact-operator算子ckpt显示数据是非常小，几乎没有。同时alignment
>> > duration都是0ms，也就是不存在对齐时长。 但是 start-delay 却很长，有的达到16min左右，不清楚这个是为啥？
>> >
>> > 目前根据文档分析下来，start-delay是从第一个barrier创建 到
>> > 该barrier到达该subtask的时长，不清楚我这个DAG任务情况下，是什么导致这个情况呢？
>> > 为什么第一个barrier到达都这么耗时。
>> >
>>
>

Re: 检查点的start-delay、alignment duration理解。

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

Task3就是compact，具体jstack可能有点复杂，本身每个算子在每个机器上都有，jstack也不好分辨具体那个线程。

目前来看我1h有100G的数据，使用的60并行度，这个配置按照我的其他流统计是没问题了，消费肯定没问题，不清楚是否受到hdfs性能的影响。

Caizhi Weng <ts...@gmail.com> 于2021年11月25日周四 上午10:32写道：

> Hi！
>
> 这个 checkpoint 时间的差距确实不太符合预期，因为 compact 一般都是比较快的。建议看一下 task3 的 jstack 以及 gc
> 情况，确认是不是 task3 gc 严重阻塞 checkpoint，以及 task3 具体在做什么。
>
> yidan zhao <hi...@gmail.com> 于2021年11月24日周三 下午7:03写道：
>
> > 如题，文档
> >
> >
> https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/
> > 。
> >
> > 我目前情况是，有个任务，从kafka读取数据，写hive，orc格式，带了compact功能，align 模式。
> > 目前发现DAG为4个Task，分别为：
> > Task1: Source: TableSourceScan.... ... ... -> streaming-writer 并行度60
> > Task2: compact-coordinator 并行度1
> > Task3: compact-operator 并行度60
> > Task4: PartitionCommitter -> Sink: end 并行度1
> >
> > 目前观察到检查点存在超时，我给一个ckpt数据，耗时18min30s，如下是E2E时长。
> > Task1: 49s。
> > Task2: 1s。
> > Task3: 18min20s。
> > Task4: 18min30s。
> >
> 继续观察Task3的subtask的detail信息，compact-operator算子ckpt显示数据是非常小，几乎没有。同时alignment
> > duration都是0ms，也就是不存在对齐时长。 但是 start-delay 却很长，有的达到16min左右，不清楚这个是为啥？
> >
> > 目前根据文档分析下来，start-delay是从第一个barrier创建 到
> > 该barrier到达该subtask的时长，不清楚我这个DAG任务情况下，是什么导致这个情况呢？
> > 为什么第一个barrier到达都这么耗时。
> >
>

Re: 检查点的start-delay、alignment duration理解。

[Caizhi Weng <ts...@gmail.com>]

Hi！

这个 checkpoint 时间的差距确实不太符合预期，因为 compact 一般都是比较快的。建议看一下 task3 的 jstack 以及 gc
情况，确认是不是 task3 gc 严重阻塞 checkpoint，以及 task3 具体在做什么。

yidan zhao <hi...@gmail.com> 于2021年11月24日周三 下午7:03写道：

> 如题，文档
>
> https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/
> 。
>
> 我目前情况是，有个任务，从kafka读取数据，写hive，orc格式，带了compact功能，align 模式。
> 目前发现DAG为4个Task，分别为：
> Task1: Source: TableSourceScan.... ... ... -> streaming-writer 并行度60
> Task2: compact-coordinator 并行度1
> Task3: compact-operator 并行度60
> Task4: PartitionCommitter -> Sink: end 并行度1
>
> 目前观察到检查点存在超时，我给一个ckpt数据，耗时18min30s，如下是E2E时长。
> Task1: 49s。
> Task2: 1s。
> Task3: 18min20s。
> Task4: 18min30s。
> 继续观察Task3的subtask的detail信息，compact-operator算子ckpt显示数据是非常小，几乎没有。同时alignment
> duration都是0ms，也就是不存在对齐时长。 但是 start-delay 却很长，有的达到16min左右，不清楚这个是为啥？
>
> 目前根据文档分析下来，start-delay是从第一个barrier创建 到
> 该barrier到达该subtask的时长，不清楚我这个DAG任务情况下，是什么导致这个情况呢？
> 为什么第一个barrier到达都这么耗时。
>