实际业务的确是这样的。 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? >