Re: Re: Re: Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
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 wrote: > @Jingsong orc格式，都看过了，还是没有commit。感觉你们可以测一下这个场景 > > 在 2020-08-12 16:04:13，"Jingsong Li" 写道： > >另外问一下，是什么格式？csv还是parquet。 > >有等到10分钟(rollover-interval)过后和下一次checkpoint后再看吗？ > > > >On Wed, Aug 12, 2020 at 2:45 PM kandy.wang wrote: > > > >> > >> > >> > >> > >> > >> > >> 有的。就是写了一半，做了一个checkpoint ，然后程序 做一个savepoint cancel掉， > >> 重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。 > >> 就是感觉停止之前正在写的那个分区，没有触发commit > >> > >> > >> > >> > >> 在 2020-08-12 14:26:53，"Jingsong Li" 写道： > >> >那你之前的分区除了in-progress文件，有已完成的文件吗？ > >> > > >> >On Wed, Aug 12, 2020 at 1:57 PM kandy.wang wrote: > >> > > >> >> > >> >> > >> >> > >> >> source就是kafka > >> >> > >> > json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。 > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >> >> > >> >> > >> >> > >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >> >> > >> >> 在 2020-08-12 13:28:01，"Jingsong Li" 写道： > >> >> >你的source是exactly-once的source吗？ > >> >> > > >> >> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >> >> > > >> >> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang > 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" 写道： > >> >> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 > >> >> >> >> > >> >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu > wrote: > >> >> >> >> > >> >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 > >> >> >> >>> > >> >> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang > >> 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
Re:Re: Re: Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
@Jingsong orc格式，都看过了，还是没有commit。感觉你们可以测一下这个场景 在 2020-08-12 16:04:13，"Jingsong Li" 写道： >另外问一下，是什么格式？csv还是parquet。 >有等到10分钟(rollover-interval)过后和下一次checkpoint后再看吗？ > >On Wed, Aug 12, 2020 at 2:45 PM kandy.wang wrote: > >> >> >> >> >> >> >> 有的。就是写了一半，做了一个checkpoint ，然后程序 做一个savepoint cancel掉， >> 重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。 >> 就是感觉停止之前正在写的那个分区，没有触发commit >> >> >> >> >> 在 2020-08-12 14:26:53，"Jingsong Li" 写道： >> >那你之前的分区除了in-progress文件，有已完成的文件吗？ >> > >> >On Wed, Aug 12, 2020 at 1:57 PM kandy.wang wrote: >> > >> >> >> >> >> >> >> >> source就是kafka >> >> >> json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。 >> >> >> >> >> >> >> >> >> >> >> >> >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ >> >> >> >> >> >> >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ >> >> >> >> 在 2020-08-12 13:28:01，"Jingsong Li" 写道： >> >> >你的source是exactly-once的source吗？ >> >> > >> >> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ >> >> > >> >> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang 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" 写道： >> >> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 >> >> >> >> >> >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: >> >> >> >> >> >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 >> >> >> >>> >> >> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang >> 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
Re: Re: Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
另外问一下，是什么格式？csv还是parquet。 有等到10分钟(rollover-interval)过后和下一次checkpoint后再看吗？ On Wed, Aug 12, 2020 at 2:45 PM kandy.wang wrote: > > > > > > > 有的。就是写了一半，做了一个checkpoint ，然后程序 做一个savepoint cancel掉， > 重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。 > 就是感觉停止之前正在写的那个分区，没有触发commit > > > > > 在 2020-08-12 14:26:53，"Jingsong Li" 写道： > >那你之前的分区除了in-progress文件，有已完成的文件吗？ > > > >On Wed, Aug 12, 2020 at 1:57 PM kandy.wang wrote: > > > >> > >> > >> > >> source就是kafka > >> > json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。 > >> > >> > >> > >> > >> > >> > >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >> > >> > >> > >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >> > >> 在 2020-08-12 13:28:01，"Jingsong Li" 写道： > >> >你的source是exactly-once的source吗？ > >> > > >> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >> > > >> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang 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" 写道： > >> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 > >> >> >> > >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: > >> >> >> > >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 > >> >> >>> > >> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang > 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
Re:Re: Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
有的。就是写了一半，做了一个checkpoint ，然后程序 做一个savepoint cancel掉， 重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。 就是感觉停止之前正在写的那个分区，没有触发commit 在 2020-08-12 14:26:53，"Jingsong Li" 写道： >那你之前的分区除了in-progress文件，有已完成的文件吗？ > >On Wed, Aug 12, 2020 at 1:57 PM kandy.wang wrote: > >> >> >> >> source就是kafka >> json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。 >> >> >> >> >> >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ >> >> >> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ >> >> 在 2020-08-12 13:28:01，"Jingsong Li" 写道： >> >你的source是exactly-once的source吗？ >> > >> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ >> > >> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang 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" 写道： >> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 >> >> >> >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: >> >> >> >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 >> >> >>> >> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang 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
Re: Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
那你之前的分区除了in-progress文件，有已完成的文件吗？ On Wed, Aug 12, 2020 at 1:57 PM kandy.wang wrote: > > > > source就是kafka > json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。 > > > > > > > in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > > > > in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > > 在 2020-08-12 13:28:01，"Jingsong Li" 写道： > >你的source是exactly-once的source吗？ > > > >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > > > >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang 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" 写道： > >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 > >> >> > >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: > >> >> > >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 > >> >>> > >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang 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
Re:Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
source就是kafka json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。 in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ 在 2020-08-12 13:28:01，"Jingsong Li" 写道： >你的source是exactly-once的source吗？ > >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ > >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang 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" 写道： >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 >> >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: >> >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 >> >>> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang 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
Re: Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
你的source是exactly-once的source吗？ in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？ On Wed, Aug 12, 2020 at 12:51 PM kandy.wang 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" 写道： > >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 > >> > >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: > >> > >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 > >>> > >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang 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
Re:Re: flink 1.11 StreamingFileWriter及sql-client问题
@ Jingsong 导致的影响是停止前的那个分区，分区没有提交， 当程序起来之后，写的分区和之前分区不是同一个分区，没有_SUCCESS文件标记。 用presto查询查不了 在 2020-08-12 12:11:53，"Jingsong Li" 写道： >in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响 > >On Wed, Aug 12, 2020 at 11:05 AM Jark Wu wrote: > >> 与我所知，(2) & (3) 有希望能在 1.12 中支持。 >> >> On Tue, 11 Aug 2020 at 21:15, kandy.wang 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
