如果数据本身没什么倾斜，且并发也能打上去。那在 sql 这边也没什么其他办法了。得从 rocksdb 的角度去调优看看。比如： 1. 是否有使用 SSD? 2. 调整 write buffer 和 block cache 3. 更多可以看下这些 state 调优文章[1][2].
Best, Jark [1]: https://mp.weixin.qq.com/s/r0iPPGWceWkT1OeBJjvJGg [2]: https://mp.weixin.qq.com/s/YpDi3BV8Me3Ay4hzc0nPQA On Thu, 19 Nov 2020 at 12:19, jindy_liu <286729...@qq.com> wrote: > 很感谢jark！ > 1、昨天将status表设置成时态表（Temporal > Tables），然后连续join试了下。确实有你说的问题，status表的更新不会触发任务计算，所有的数据实时变更需要test流来驱动。 > > 同时时态表TTL设置问题，太小i/o有问题，太大结果不及时，与应用场景要求不符合，主要我们的场景下，status表也并不是维表，并且也数据量也大，变化也多。 > > 2、并发度1的话，可以预见的是有主要性能问题，表大的情况下，join导致的反压厉害。 > > 3、因为多并发度（10，20，40，80）测试中，我将join的两个表（test, > status）的数据完全对称，没有倾斜问题（200w，200w，并且join的key对称，test 1 -- status1, test 2 -- > status2, ....test 2000000 -- status2000000），source仍然存在着反压，只是并发度高的反压慢点出现一些， > 这里的flink state后端用的是rokcsdb+本地文件。磁盘i/o看也就在2w block/s的，难道是默认的rokcsdb配置性能不够？ > > 这个数据反压上，jark你有啥建议吗？ > > > > -- > Sent from: http://apache-flink.147419.n8.nabble.com/
