这种场景是不是可以直接用批的方式来处理呢？那就不需要维表了，正常join即可， 这样可以用到批里面一些特有的join优化。
魏烽 <[email protected]> 于2020年8月28日周五 上午9:58写道： > 各位好： > > > 现在有一个应用场景是使用流的方式读取hdfs文件进行处理（StreamEnv.readTextFile），实际可以看成是批处理，现需要进行维表join，维表不会变更，现有两种方案： > > 1.直接将维表一次性加载到内存进行join； > > 2.使用mysql或者hbase外部存储每条数据进行查询join； > > 但是方案一不能保证数据量一定可以全部加载到内存，方案二又需要额外的外部存储，增加了系统结构的复杂度 > > 请问各位有什么更好的建议嘛？感谢 > > 原始邮件 > 发件人: Leonard Xu<[email protected]> > 收件人: Jark Wu<[email protected]> > 抄送: user-zh<[email protected]>; Benchao Li<[email protected]> > 发送时间: 2020年8月27日(周四) 20:11 > 主题: Re: Flink 维表延迟join > > > 多谢 Jark 提议 > > Issue[1] 建好了, 大家可以在issue下讨论。 > > 祝好 > Leonard > [1] https://issues.apache.org/jira/browse/FLINK-19063 < > https://issues.apache.org/jira/browse/FLINK-19063> > > > > 在 2020年8月27日，19:54，Jark Wu <[email protected]<mailto:[email protected]>> > 写道： > > > > @Leonard 可以先建个 issue，收集下大家的需求，大家也可以在 issue 下讨论下解决思路。 > > > > On Thu, 27 Aug 2020 at 11:12, Leonard Xu <[email protected]<mailto: > [email protected]> <mailto:[email protected]<mailto:[email protected]>>> > wrote: > > > > Hi, all > > > > 看起来维表延迟join是一个common case, 我在邮件列表里看到蛮多小伙伴反馈了， > > 感觉可以考虑支持下 维表 延迟 join，大家可以一起分享下主要的业务场景吗？ > > > > Best > > Leonard > > > > > 在 2020年8月27日，10:39，china_tao <[email protected]<mailto: > [email protected]> <mailto:[email protected]<mailto: > [email protected]>>> 写道： > > > > > > 一般来说，是先有维表数据，再有流数据。如果出现了你这样的情况，两个方式，一个使用left > > > > join，使流表数据的维表信息为null，后期通过etl再补录；或者碰到异常，把消息打到另外一个kafka中，再进行异常处理或者补录处理，也可以理解为您说的那种5分钟，10分钟join一次。 > > > 个人推荐先用null存储，后期etl补录。 > > > > > > > > > > > > -- > > > Sent from: http://apache-flink.147419.n8.nabble.com/ < > http://apache-flink.147419.n8.nabble.com/> > > > > > > -- Best, Benchao Li
