此外，按照event time分区的情况下，迟到数据怎么处理的。如果是streaming情况，window算子，迟到数据是丢弃的。对于flinksql这种从kafka写到hive，只是依靠event time做分区的情况，迟到数据是什么表现呢。
yidan zhao <[email protected]> 于2021年11月10日周三 下午1:03写道： > 另外，写到hdfs后文件命名为.开头，最近发现部分有..开头的。请问..开头和.开头什么区别呢，是不是..开头是没用了已经。 > > 比如有检查点ckpt1，ckpt2，...然后失败，重启后，基于ckpt2重启，那么ckpt2之后生成的部分数据文件会被命名为..开头表示废弃，然后重启后重新创建.开头的文件这么写，是吗。 > > yidan zhao <[email protected]> 于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 <[email protected]> 于2021年11月5日周五 下午1:35写道： >> >>> Hi！ >>> >>> 1 换言之，是针对每个检查点，合并了多个并发subtask产生的文件对吧。 >>> >>> 正确 >>> >>> 2 除此以外，多个检查点之间的文件是没有办法合并的对吧。 >>> >>> 正确 >>> >>> 实际部分节点做的是后台IO了事情，是不是反映不到busy情况上 >>> >>> 是的，busy 的计算方式是通过采样看有多少个线程正在工作。对于 sink 这种线程都在等待后台 io 的节点来说确实 busy 值不会很高。 >>> >>> yidan zhao <[email protected]> 于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的工作并反映不出来。对吗。 >>> > 所以即使看起来都是蓝色的，也不能降低并行度，而是自行根据数据量采用一个差不多的并行度。 >>> > >>> >>
