大家好，
我这边想做一个实时数仓项目。但随着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之间的依赖或者说血缘关系的？有没有比较好的方案？
谢谢大家！
谢谢
徐涛
