实际业务的确是这样的。 state 永不过期， 要全量的数据计算，全量的数据放到 state 里面。
目前看来只有等 flink table store 了。 Zhiwen Sun On Fri, Sep 23, 2022 at 8:29 AM casel.chen <casel_c...@126.com> wrote: > > 我这里只是举了一个例子表示Flink用于OLAP实时关联场景会遇到的一个问题，实际业务中确实会出现两张关联表都需要更新情况，不管哪一边更新数据业务都想获取到最新关联结果，而不是旧的关联状态。引出我想问的另一个问题是如果查询模式固定，Flink实时关联是否能取代OLAP系统例如Doris呢？ > 1. 一般双流join为避免state无限膨胀，都会设置ttl，你这边的业务场景ttl需要保留n个月？ > 确切地说不应该设置ttl，业务数据有长尾效应，大多数都在当天更新完毕，短的几秒种，长的甚至会在半年后还发生更新 > > > 2. order流和user流在业务场景上要求的state ttl时长是不是不一样？ > 同上 > > > 3. order流和user流的数据规模/state size规模大概可以到什么级别？ > TB级别 > > > > > > > > > > > > > > > 在 2022-09-20 10:28:49，"Jinzhong Li" <lijinzhong2...@gmail.com> 写道： > >hi，casel, 关于你们的业务场景，我有几个问题, 希望可以交流一下。 > >1. 一般双流join为避免state无限膨胀，都会设置ttl，你这边的业务场景ttl需要保留n个月？ > >2. order流和user流在业务场景上要求的state ttl时长是不是不一样？ > >（从你描述上来看，user流的ttl需要几个月，order流可以比较短些？） > >3. order流和user流的数据规模/state size规模大概可以到什么级别？ > > > >casel.chen <casel_c...@126.com> 于2022年9月17日周六 10:59写道： > > > >> 请教一个flink实现实时双流驱动join问题： > >> > >> > >> order cdc流字段：order_id, order_status, order_time, user_id （order_id是主键） > >> user cdc流字段：user_id, user_name, user_phone, user_address（user_id是主键） > >> 关联结果流字段：order_id, order_status, order_time, user_name, user_phone, > >> user_address（order_id是主键） > >> 期望当order流数据更新或user流数据更新时，关联结果流数据都会得到更新。inner join不满足是因为两条流distinct > >> id都很大，状态会很大，且不能TTL，因为user流更新时间不定，短的几小时，长达上月。 > >> > >> > >> 请问这种场景下要如何使用flink实现实时双流驱动join？ >
