hi,
我问了下 如果配置在 flink-conf 情况下，则是会在jm 中打印相关的参数。如果是 api 配置的话，目前 log 中是不会打印相关信息的。
Best,
Shengkai
lxk 于2022年6月15日周三 16:10写道：
> 我大致理解为，watermark设置不合理，导致延迟的数据就丢失了，这块我会再去从测输出流去验证一下数据。
> 频繁更新应该不太有可能，因为程序在流转表之前已经做了一道过滤，订单header只取了一个支付状态的数据，订单item也进行了去重处理。
> 然后这是我的jm和tm日志，目前好像没看见表的ttl相关日志。
>
>
>
>
>
>
>
我大致理解了，数据其实是在关联之前就丢掉了。之前了解的最多的是interval join，目前来看我这种场景其实使用inner
join比较合适，这个水印确实感觉挺难很合理的去设置。
在 2022-06-15 12:06:56，"Zhiwen Sun" 写道：
>我猜测是 watermark 的问题， 看楼主的设置， watermark 是 -2s ，也就是说， order header 流，有数据晚了 2s
>，就会被丢弃。
>
>楼主之前看的也是 订单明细比订单主表晚几秒， 这只是同一个订单的数据生成时间差异。 如果是这样的话，使用一般的 inner joi
我猜测是 watermark 的问题， 看楼主的设置， watermark 是 -2s ，也就是说， order header 流，有数据晚了 2s
，就会被丢弃。
楼主之前看的也是 订单明细比订单主表晚几秒， 这只是同一个订单的数据生成时间差异。 如果是这样的话，使用一般的 inner join + ttl
就可以满足需求了。
BTW： watermark 我觉得很难使用好，实际使用场景非常有限。
Zhiwen Sun
On Wed, Jun 15, 2022 at 11:43 AM Shengkai Fang wrote:
> > 我在sql inner join里设
> 我在sql inner join里设置的状态ttl为20s,为什么20s的状态保留数据要比interval join开分钟级别的数据还要准确
不合理的 watermark 设置在 interval join 就会导致丢数据。设置 ttl 情况下，如果某个 key
的数据频繁访问情况下，那么这个数据就不会过期。
> 我的做法是排查了tm和jm的日志，没有看见写的表的配置的日志。
我记得日志是会打印相关的日志。能提一些相关的日志吗？
best,
Shengkai
lxk 于2022年6月14日周二 20:04写道：
> Hi,
> 我目前使用sql interval joi
Hi,
1、理论上来说inner join关联的数据量应该比interval
join更大吧。关于左右两边流速度不一致的情况，理论上应该问题不大，因为需要等到两边的watermark都到齐之后才会触发状态里过期数据的清除。
2、inner
join没有水印的情况下，就是到了就发，完全根据这条数据进入这个算子的时间来算，也就是“处理时间”。默认数据是不会过期的，会存全量数据。如果定义了ttl，得看join两侧的表的pk和join
key，分别用不同的state数据格式来存数据（ListState、MapState等），原则上是多长时间没更新数据之后，就清空过期数据，是按照的“处
