Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

729...@qq.com> Sent: Friday, December 11, 2020 11:24 To: user-zh@flink.apache.org Subject: Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend 感谢指正！这里我验证了下你的说法，确实我理解有误了，我以为这个参数write buffer count以及max write buffer是taskmanager所有的slots的。从web ui来看，确实是很多算子都出现了is_stop_write。你的推断是正确的,老的配置参

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

感谢指正！这里我验证了下你的说法，确实我理解有误了，我以为这个参数write buffer count以及max write buffer是taskmanager所有的slots的。从web ui来看，确实是很多算子都出现了is_stop_write。你的推断是正确的,老的配置参数下，看了下，确实经常出现is_stop_write=1的情况，然后线程就阻塞sleep了。 昨天调整了一版参数：改了下Slot为2，还是6台机器，job并发度设置成12。结果是之前的阻写没有了。跑一晚上10个小时左右，能跑21000W每张表的速度了，并且现在看也没有阻写的情况，硬盘的读写iops与util都很低，

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

/config.html#state-backend-rocksdb-metrics-is-write-stopped 祝好 唐云 From: jindy_liu <286729...@qq.com> Sent: Thursday, December 10, 2020 16:22 To: user-zh@flink.apache.org Subject: Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend 补充

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

补充一个，当我把state.backend.rocksdb.writebuffer.count: 48调小到10的话， jstack来看，从https://spotify.github.io/threaddump-analyzer/分析来看 top类的方法基本都在rocksdb的io上了。并且很多线程都在等待 -- Sent

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

flink sql主要涉及到9张mysql表（snapshot+cdc）,任务的解析后的算子较多，大概60~70个，但主要是join，和4~5个GroupAggregate算子，最后sink，sink不是瓶颈已经排除。 恩，已经调过几版参数了我的机型的配置是一样的，12核+24G内存 + ssd 50G，共6台（任务并行度设置为60，除去了flink mysql cdc流的并行度为1，其它算子并行度都为60） taskmgr的flink-conf主要参数为，其它为默认： taskmanager.numberOfTaskSlots: 10 taskmanager.memory.process

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

: Thursday, December 10, 2020 11:04 To: user-zh Cc: Yun Tang Subject: Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend 关于 rocksdb 的性能调优, @Yun Tang<mailto:myas...@live.com> 会更清楚。 On Thu, 10 Dec 2020 at 11:04, Jark Wu mailto:imj...@gmail.com>> wrote: 建议大状态还是用 rock

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

关于 rocksdb 的性能调优, @Yun Tang 会更清楚。 On Thu, 10 Dec 2020 at 11:04, Jark Wu wrote: > 建议大状态还是用 rocksdb，生产上会稳定很多。你说的这个量级感觉相差比较大，可能还没有对 rocksdb 调优导致的。 > > 你可以参考下这几篇文章尝试调优下 rocksdb： > > https://mp.weixin.qq.com/s/YpDi3BV8Me3Ay4hzc0nPQA > https://mp.weixin.qq.com/s/mjWGWJVQ_zSVOgZqtjjoLw > https://mp.we

Re: 关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

建议大状态还是用 rocksdb，生产上会稳定很多。你说的这个量级感觉相差比较大，可能还没有对 rocksdb 调优导致的。 你可以参考下这几篇文章尝试调优下 rocksdb： https://mp.weixin.qq.com/s/YpDi3BV8Me3Ay4hzc0nPQA https://mp.weixin.qq.com/s/mjWGWJVQ_zSVOgZqtjjoLw https://mp.weixin.qq.com/s/ylqK9_SuPKBKoaKmcdMYPA https://mp.weixin.qq.com/s/r0iPPGWceWkT1OeBJjvJGg Best,

关于flink cdc的N流join状态后端的选择问题： ‎FsStateBackend和‎RocksDBStateBackend

场景上： 目前都是mysql里的带主键的表（亿级别）的join操作后，得到的实时宽表（视图)上做一些规则筛选或计数等，并且场景上状态（join算子）都基上上不设置TTL。 目前mysql中的都是些有主键数据，且量级不会有太大的变化，并且可以预见，可能一年也就增加个200w左右，但表里的数据变更较频繁。所以处理上需要吞吐量较大，延时低。 目前测试了一版本flink sql算子使用Rocksdb做后端发现吞吐与延时都比较大，一条数据变化，可能要10秒中才能生效，但换FsStateBackend时，速度就很快了，性能较好；两者相差10倍多。 所以产生以下想法，不