Re: Re: Re: Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题

[Jingsong Li <ji...@gmail.com>]

Hi kandy~

有可能是https://issues.apache.org/jira/browse/FLINK-19166
这个问题导致的，即将发布的1.11.2会Fix它，希望你可以确认重试下~

Best,
Jingsong

On Fri, Aug 14, 2020 at 7:22 PM kandy.wang <ka...@163.com> wrote:

> @Jingsong  orc格式，都看过了，还是没有commit。感觉你们可以测一下这个场景
>
> 在 2020-08-12 16:04:13，"Jingsong Li" <ji...@gmail.com> 写道：
> >另外问一下，是什么格式？csv还是parquet。
> >有等到10分钟(rollover-interval)过后和下一次checkpoint后再看吗？
> >
> >On Wed, Aug 12, 2020 at 2:45 PM kandy.wang <ka...@163.com> wrote:
> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> 有的。就是写了一半，做了一个checkpoint ，然后程序 做一个savepoint cancel掉，
> >> 重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。
> >> 就是感觉停止之前正在写的那个分区，没有触发commit
> >>
> >>
> >>
> >>
> >> 在 2020-08-12 14:26:53，"Jingsong Li" <ji...@gmail.com> 写道：
> >> >那你之前的分区除了in-progress文件，有已完成的文件吗？
> >> >
> >> >On Wed, Aug 12, 2020 at 1:57 PM kandy.wang <ka...@163.com> wrote:
> >> >
> >> >>
> >> >>
> >> >>
> >> >> source就是kafka
> >> >>
> >>
> json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >> >>
> >> >>
> >> >>
> >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >> >>
> >> >> 在 2020-08-12 13:28:01，"Jingsong Li" <ji...@gmail.com> 写道：
> >> >> >你的source是exactly-once的source吗？
> >> >> >
> >> >> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >> >> >
> >> >> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang <ka...@163.com>
> wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> >@ Jingsong
> >> >> >>
> >> >> >> >导致的影响是停止前的那个分区，分区没有提交， 当程序起来之后，写的分区和之前分区不是同一个分区，没有_SUCCESS文件标记。
> >> >> >> 用presto查询查不了
> >> >> >> 举例：12：35分钟应当写的是 12：35 00秒 -12：39分 59秒 之间的数据，
> >> >> >>  'sink.partition-commit.trigger'='process-time',
> >> >> >>   'sink.partition-commit.delay'='0 min',
> >> >> >>
> >>  'sink.partition-commit.policy.kind'='metastore,success-file,custom',
> >> >> >>   'sink.rolling-policy.check-interval'='30s',
> >> >> >>   'sink.rolling-policy.rollover-interval'='10min',
> >> >> >>   'sink.rolling-policy.file-size'='128MB'
> >> >> >>    如果是12：39分 05秒左右做一次savepoint，然后
> >> >> >> 12：41分程序重启后，发现之前的12：35分区不再写入，里面的in-progress文件还在，但是分区没有提交，没有往hive
> add
> >> >> >> partition，就导致有数据，但是确查不 了。
> >> >> >>
> >> >>
> >>
> 按照你说的，in-progress文件对没影响，但是影响了分区提交。就没地方触发之前12：35分区提交逻辑了。相当于丢了一个分区。这种情况我试了一下，手动add
> >> >> >> partition 也能查了。
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >在 2020-08-12 12:11:53，"Jingsong Li" <ji...@gmail.com> 写道：
> >> >> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
> >> >> >> >>
> >> >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <im...@gmail.com>
> wrote:
> >> >> >> >>
> >> >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
> >> >> >> >>>
> >> >> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <ka...@163.com>
> >> wrote:
> >> >> >> >>>
> >> >> >> >>> > 1.StreamingFileWriter
> >> >> 测试下来目前发现，sql方式提交任务，不能从checkpoint、savepoint恢复。
> >> >> >> >>> >    举例：5min产生一个分区，数据按照process_time来落，hm= 2100 的分区， 在
> >> >> >> >>> > 21：04分左右的时候做一次checkpoint 或savepoint，重启任务的时候，hm
> >> >> >> >>> > =2100分区的数据还存在很多的in-progress文件。
> >> >> >> >>> >
> >> 另外，目前在hdfs目录下没看到pending文件，想了解一下这文件状态是如何转换的，跟之前的bucketsink好像实现不太一样。
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > 2. sql-client不支持 checkpoint savepoint恢复的问题，何时可以支持
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > 3.sql-client 提交任务，不支持StatementSet批量提交，何时可以支持
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>--
> >> >> >> >>Best, Jingsong Lee
> >> >> >>
> >> >> >
> >> >> >
> >> >> >--
> >> >> >Best, Jingsong Lee
> >> >>
> >> >
> >> >
> >> >--
> >> >Best, Jingsong Lee
> >>
> >
> >
> >--
> >Best, Jingsong Lee
>


-- 
Best, Jingsong Lee