flink-user-zh mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hequn Cheng <chenghe...@gmail.com>
Subject Re: Flink如何实现Job间的协同联系?
Date Fri, 21 Jun 2019 13:21:34 GMT
Hi 徐涛,

最后四个问题,3和4和业务逻辑关系大些,我大致说下1和2的想法,

1. 因为每个变化都要发一个message,Kafka中的消息数可能很大。
这个问题,可以借助一些攒批的策略来减少数据量,比如在自定义的sink里加些cache,每1000条刷一次,刷的时候对这1000条按key去重。需要注意的是,攒批需要结合checkpoint一起来考虑,防止丢数据,可以参考下JDBCOutputFormat的实现(做checkpoint的时候需要flush)。此外,blink里面aggregate也有miniBatch的逻辑,也会减少输出的数据量(不过,flink里面还没有miniBatch)。

2. 下游做幂等的时候,因为要对每个Key做Group by,因此消耗的资源也很大。
这个是的,目前应该没有很好的办法。后期,如果支持了RetractSource,下游job可以不用再做groupBy+last。只需要上游job用RetractSink输出存一份数据到Kafka。

一些其他问题:
> ① 需要实现一个retract kafka sink
这里应该是需要实现一个upsert kafka sink,目前flink还没法输入retract message。

Best,Hequn

On Wed, Jun 19, 2019 at 1:18 PM 徐涛 <xutao_ustc@163.com> wrote:

> 大家好,
>
> 我这边想做一个实时数仓项目。但随着Flink间Job的数量越来越多,发现很多Job之间的代码存在大量的重复,且迫切需要一个类似于Batch的中间层解决方案来减少冗余,增加整体的清晰度和层次感。
>     我这边能想到的解决方案是:采用Kafka作为Job之间的联系纽带,例如有两个Job
>     Job_1:   从原始kafka topic TOPIC_ORIG获取数据, 进行一定的业务逻辑处理后,写到另一个kafka
topic,
> TOPIC_JOB_1_SINK 。注意
>                ① 需要实现一个retract kafka sink
>                ② 没有使用kafka exactly-once sink
>                ③ TOPIC_JOB_1_SINK 中的每条记录应该有一个 unique key.
>                ④ 每个Key相同的记录应该被发往相同的kafka partition.
>     Job_2:    从TOPIC_JOB_1_SINK读取数据, 接着做幂等(先对唯一Key做group
by取最新),
> 然后运行Job_2的逻辑 , 最后把数据写道最终Sink中(例如es, hbase, mysql)。
之所以要对unique
> key做一轮幂等处理,因为Job_1可能会失败重试,TOPIC_JOB_1_SINK中可能会有一些重试脏数据。
>
>
> 从整体上看,结构大概如下图所示:
> Job_1Job_2
> -------------------------------------------------------------------------------------
>
>  -----------------------------------------------------------------------------------------------------------------------------------------------------------
> |      TOPIC_ORIG -> Logic_Job_1 -> TOPIC_JOB_1_SINK      |           ——>
>    |     TOPIC_JOB_1_SINK -> GROUP_BY_UNIQUE_KEY_GET_LATEST -> Logic_Job_2
> -> FINAL_JOB_2_SINK    |
> -------------------------------------------------------------------------------------
>
>  -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> 即:每个Job往下游发送的数据整体有唯一Key;每个下游需要对上游发来的数据做幂等处理。
> 但是,可能存在的问题有:
> 1. 因为每个变化都要发一个message,Kafka中的消息数可能很大。
> 2. 下游做幂等的时候,因为要对每个Key做Group by,因此消耗的资源也很大。
> 3. 如果上游逻辑更改,重新跑数据,那么可能会存在最开始的那天数据不完整,导致污染下游数据
> 4. 如果上游逻辑更改,重新跑数据,但是某条数据这个时候已经不应该出现了,下游的数据得不到更新
>
>
> 请问大家是如何管理Flink Job之间的依赖或者说血缘关系的?有没有比较好的方案?
> 谢谢大家!
>
>
> 谢谢
> 徐涛
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message