另外,写到hdfs后文件命名为.开头,最近发现部分有..开头的。请问..开头和.开头什么区别呢,是不是..开头是没用了已经。
比如有检查点ckpt1,ckpt2,...然后失败,重启后,基于ckpt2重启,那么ckpt2之后生成的部分数据文件会被命名为..开头表示废弃,然后重启后重新创建.开头的文件这么写,是吗。

yidan zhao <hinobl...@gmail.com> 于2021年11月9日周二 上午10:50写道:

> 关于FlinkSQL写hive,orc格式,性能和稳定性方面有什么建议吗。
>
> 比如并行度设置多少合理,目前compact-coordinator并行度定死为1,不可更改应该,compact-operator是60,日常来看compact-operator经常是红色,busy100%。目前问题是偶尔会发现检查点失败,延迟等,导致实际现象是文件没合并,进而inode不足。(我们的inode的quota不足实际是)。
>
>
> 4个task节点,source、compact-coordinator、compact-operator、partition-commiter,分别考虑什么设置并行度呢,仅针对能设置的部分。
> 比如souce部分我主要考虑数据量,不清楚这个compact-operator的并行主要考虑啥,也是数据量吗?
>
>
> 此外,也没有可能kafka2hdfs和compact分成2个线做,互不影响。
>
> Caizhi Weng <tsreape...@gmail.com> 于2021年11月5日周五 下午1:35写道:
>
>> Hi!
>>
>> 1 换言之,是针对每个检查点,合并了多个并发subtask产生的文件对吧。
>>
>> 正确
>>
>> 2 除此以外,多个检查点之间的文件是没有办法合并的对吧。
>>
>> 正确
>>
>> 实际部分节点做的是后台IO了事情,是不是反映不到busy情况上
>>
>> 是的,busy 的计算方式是通过采样看有多少个线程正在工作。对于 sink 这种线程都在等待后台 io 的节点来说确实 busy 值不会很高。
>>
>> yidan zhao <hinobl...@gmail.com> 于2021年11月4日周四 下午5:57写道:
>>
>> > hi,还想继续问下。这个合并机制,根据文档介绍如下。
>> > Whether to enable automatic compaction in streaming sink or not. The
>> data
>> > will be written to temporary files. After the checkpoint is completed,
>> the
>> > temporary files generated by a checkpoint will be compacted. The
>> temporary
>> > files are invisible before compaction.
>> > 看文档,是指每次检查点完成后,会将单个检查点产生的文件进行合并。也就是说只有单个检查点产生的文件会被合并。
>> > 1 换言之,是针对每个检查点,合并了多个并发subtask产生的文件对吧。
>> >
>> > 2 除此以外,多个检查点之间的文件是没有办法合并的对吧。
>> >
>> > 3 另外一个问题:目前看flinksql写hive,streaming情况。从web
>> >
>> >
>> ui上看不开启compact情况下,几乎每个节点都是蓝色,而且数据量不大。开启compact情况,几乎也都是蓝色,数据量也不大,但只有compact节点是持续红色。
>> >
>> >
>> 按照我的理解写hive这种情况下,实际部分节点做的是后台IO了事情,是不是反映不到busy情况上,busy比如只考虑对接受元素的处理,至于这个元素导致这个算子有多少background的工作并反映不出来。对吗。
>> > 所以即使看起来都是蓝色的,也不能降低并行度,而是自行根据数据量采用一个差不多的并行度。
>> >
>>
>

回复