Apache Flink 中文用户邮件列表

flink 1.11 StreamingFileWriter及sql-client问题

Classic

List

Threaded

12 messages Options

kandy.wang

flink 1.11 StreamingFileWriter及sql-client问题

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批量提交，何时可以支持

Jark

Re: flink 1.11 StreamingFileWriter及sql-client问题

Administrator

与我所知，(2) & (3) 有希望能在 1.12 中支持。

On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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批量提交，何时可以支持

Jingsong Li

Re: flink 1.11 StreamingFileWriter及sql-client问题

in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响

On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:

> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
>
> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

kandy.wang

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

@ Jingsong
导致的影响是停止前的那个分区，分区没有提交，当程序起来之后，写的分区和之前分区不是同一个分区，没有_SUCCESS文件标记。用presto查询查不了

在 2020-08-12 12:11:53，"Jingsong Li" <[hidden email]> 写道：

>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
>
>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
>
>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
>>
>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

kandy.wang

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

>@ 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" <[hidden email]> 写道：
>>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
>>
>>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
>>
>>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
>>>
>>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

Jingsong Li

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 <[hidden email]> 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" <[hidden email]> 写道：
> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
> >>
> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
> >>
> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
> >>>
> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

kandy.wang

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" <[hidden email]> 写道：

>你的source是exactly-once的source吗？
>
>in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
>
>On Wed, Aug 12, 2020 at 12:51 PM kandy.wang <[hidden email]> 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" <[hidden email]> 写道：
>> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
>> >>
>> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
>> >>
>> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
>> >>>
>> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

Jingsong Li

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

那你之前的分区除了in-progress文件，有已完成的文件吗？

On Wed, Aug 12, 2020 at 1:57 PM kandy.wang <[hidden email]> wrote:

>
>
>
> source就是kafka
> json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。
>
>
>
>
>
>
> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
>
>
>
> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
>
> 在 2020-08-12 13:28:01，"Jingsong Li" <[hidden email]> 写道：
> >你的source是exactly-once的source吗？
> >
> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >
> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang <[hidden email]> 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" <[hidden email]> 写道：
> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
> >> >>
> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
> >> >>
> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
> >> >>>
> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

kandy.wang

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

有的。就是写了一半，做了一个checkpoint ，然后程序做一个savepoint cancel掉，重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。
就是感觉停止之前正在写的那个分区，没有触发commit

在 2020-08-12 14:26:53，"Jingsong Li" <[hidden email]> 写道：

>那你之前的分区除了in-progress文件，有已完成的文件吗？
>
>On Wed, Aug 12, 2020 at 1:57 PM kandy.wang <[hidden email]> wrote:
>
>>
>>
>>
>> source就是kafka
>> json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。
>>
>>
>>
>>
>>
>>
>> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
>>
>>
>>
>> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
>>
>> 在 2020-08-12 13:28:01，"Jingsong Li" <[hidden email]> 写道：
>> >你的source是exactly-once的source吗？
>> >
>> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
>> >
>> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang <[hidden email]> 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" <[hidden email]> 写道：
>> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
>> >> >>
>> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
>> >> >>
>> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
>> >> >>>
>> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]> 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

Jingsong Li

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 <[hidden email]> wrote:

>
>
>
>
>
>
> 有的。就是写了一半，做了一个checkpoint ，然后程序做一个savepoint cancel掉，
> 重启的时候，从最新的savepoint恢复，但是重启的时候已经属于新分区了。
> 就是感觉停止之前正在写的那个分区，没有触发commit
>
>
>
>
> 在 2020-08-12 14:26:53，"Jingsong Li" <[hidden email]> 写道：
> >那你之前的分区除了in-progress文件，有已完成的文件吗？
> >
> >On Wed, Aug 12, 2020 at 1:57 PM kandy.wang <[hidden email]> wrote:
> >
> >>
> >>
> >>
> >> source就是kafka
> >>
> json格式，是exactly-once，按照process-time处理就已经写完了呢。起来的时候，process-time已经属于新的分区了，很正常。但以前的老分区状态还没提交呢。
> >>
> >>
> >>
> >>
> >>
> >>
> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >>
> >>
> >>
> >> in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >>
> >> 在 2020-08-12 13:28:01，"Jingsong Li" <[hidden email]> 写道：
> >> >你的source是exactly-once的source吗？
> >> >
> >> >in-progress还在，就证明了这个分区的数据还没写完，理论上源头数据需要回退消费，那为什么你重启后作业不会再写这个分区了呢？
> >> >
> >> >On Wed, Aug 12, 2020 at 12:51 PM kandy.wang <[hidden email]> 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" <[hidden email]> 写道：
> >> >> >>in-progress文件带来了什么具体问题吗？它们是多余的文件，对流程没有影响
> >> >> >>
> >> >> >>On Wed, Aug 12, 2020 at 11:05 AM Jark Wu <[hidden email]> wrote:
> >> >> >>
> >> >> >>> 与我所知，(2) & (3) 有希望能在 1.12 中支持。
> >> >> >>>
> >> >> >>> On Tue, 11 Aug 2020 at 21:15, kandy.wang <[hidden email]>
> 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

kandy.wang

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

@Jingsong orc格式，都看过了，还是没有commit。感觉你们可以测一下这个场景

在 2020-08-12 16:04:13，"Jingsong Li" <[hidden email]> 写道：

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

Jingsong Li

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 <[hidden email]> wrote:

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