你可以试试在sink上攒个小batch，大部分retract 和后面的add都能合并消除掉，不会对下游产生压力
> 在 2019年11月5日，上午10:18，hb <[email protected]> 写道： > > > > 是因为Retract, 相比于upsert会发送很多false的 中间数据, 想用 upsert 对下游(k/v系统)效率高些, > 这个bug,下个版本会修复么? > > 在 2019-11-05 09:07:56，"Wenlong Lyu" <[email protected]> 写道： >> Hi， >> hb，这个是因为优化器目前的bug，只考虑了sink是upsertSink，没有考虑到还有filter，最后优化的结果变成agg没有发出retract(1,3)的消息了，你可以把你的sink改成RetractSink应该就不会有问题了。 >> >>> 在 2019年11月4日，上午11:06，hb <[email protected]> 写道： >>> >>> SQL 如下: >>> INSERT INTO upsertTable >>> SELECT * FROM ( >>> SELECT cnt0 as id, count(id) as cnt FROM >>> (SELECT id, count(*) as cnt0 FROM orderTable GROUP BY id) >>> GROUP BY cnt0 >>> ) >>> WHERE cnt > 0 >>> 输入数据: >>> 1L, "hz" >>> 2L, "hz" >>> 3L, "hz" >>> 1L, "hz" >>> >>> >>> 当最后的WHERE 条件cnt >0(或者不加),结果是: >>> (true,1,3) // 会被后面的(true,1,2)覆盖 >>> (true,1,2) >>> (true,2,1) >>> 这个结果理解是对的, 最后结果是 (true,1,2) 和 (true,2,1) >>> >>> >>> 但是如果WHERE 条件是 cnt > 2 >>> 结果就是 >>> (true,1,3) >>> 这个就不理解了 >>> 为什么会输出中间结果(true,1,3),这样就和批处理上的sql结果不一致了 >>> 而不应该是没有输出么,或者 先发(true,1,3)再发(false,1,3) >>> >>> >>> >>> >>>
