谢谢

考虑过group by , 实际中 一个好多字段的表, 保不准就是那个字段发生了变化.

请问 类似的双流操作在开发中常见吗, 怎么都搜不到相似的使用, 按理谁流依赖另一个流做处理 应该算常见吧

还是说我这样的需求呀 实现呀 是野路子?

Yuan,Youjun <yuanyou...@baidu.com> 于2020年1月14日周二 下午8:22写道:

> 取决于具体的场景。想到的有如下几种方案:
> 1,group by student_id和student_name,而不是只group by
> student_id。当然前提是修改同名名字不会推送一条消息到流1.
> 2,过滤掉update的消息
> 3,基于时间窗口的聚合,对于student表的数据,每n秒输出一个唯一的student_id,然后再与score流join。
>
> -----邮件原件-----
> 发件人: xin Destiny <nj18652727...@gmail.com>
> 发送时间: Tuesday, January 14, 2020 6:39 PM
> 收件人: user-zh@flink.apache.org
> 主题: Re: 求助帖: 流join场景可能出现的重复计算
>
> Hi,
> 如果说插入两条update操作呢,一次分数是-97,一次是97
>
>
>
>
> Ren Xie <xiere...@gmail.com> 于2020年1月14日周二 下午6:20写道:
>
> > 实际场景还是有点复杂的, 便于理解 我简化成这样的,  简化后的这个, 没有实际的代码, 抱歉
> >
> > 大致 写一下 也就是这样了
> > ```sql
> > select sum(score)
> > from
> >     student t1 inner join score t2 on t1.student_id = t2.std_id where
> >     t1.student_id = 11
> > ```
> > 然后
> >
> > ```Java
> > String sql = ↑;
> > Table t = tEnv.sqlQuery(sql);
> > DataStream<Integer> stream1 = tEnv.toAppendStream(t, Integer.class);
> > stream1.keyBy("xxxx").sum("xxxx");
> > ```
> >
> > 这样的一个sql, 在student表插入一个数据, score表插入2个数据后, 会执行一次计算出一个结果97 + 98
> >
> > update 学生表的name后, 一个新事件进入student的流, 还会触发一次计算, 得到97 + 98
> >
> > 因为可能有新的成绩插入, 所以对 stream1进行sum操作, 导致 97和98 都被重复计算了一次
> >
> >
> > Caizhi Weng <tsreape...@gmail.com> 于2020年1月14日周二 下午5:49写道:
> >
> > > Hi,
> > >
> > > 有可能的话,是否方便提供一下代码呢?
> > >
> > > Ren Xie <xiere...@gmail.com> 于2020年1月14日周二 下午5:38写道:
> > >
> > > > 学生
> > > > student_id name
> > > > 11 foo
> > > >
> > > > 学科分数
> > > > id name score std_id
> > > > 100 math 97 11
> > > > 101 english 98 11
> > > >
> > > > 有如下一个场景(假设只有一个学生)
> > > >
> > > > 基于binlog检测这2个表的变化, 计算这个学生的总分数, 使用了Table/SQL API join操作计算
> > > >
> > > > 假设insert以上数据后到达某时刻, 以上数据都进入了flink, 计算出这个学生总分数 97 + 98 = 195
> > > >
> > > > 但此时发现学生姓名登记错误, 于是进行了修改,
> > > > 结果此时Flink中学生流中有2个事件(insert的一个+update的一个), 分数流中有2个事件, 计算的总分数就会是 2 *
> > > > (97
> > +
> > > > 98) = 390
> > > >
> > > > Q: 请问这种场景下使用什么能够解决, 计算出正确的结果 97 + 98 = 193
> > > >
> > > > 接触flink不久, 不是太了解, 请大佬给个提示, 谢谢!!
> > > >
> > >
> >
>

回复