❝本系列每篇文章都比较短小，不定期更新，从一些实际的 case 出发抛砖引玉，提高小伙伴的姿♂势水平。本文介绍 Flink sink schema 字段设计小技巧，阅读时长大概 2 分钟，话不多说，直接进入正文！
❞
sink schema 中添加 version 版本字段
如 title，直接上实践案例和使用方式。
实践案例及使用方式
- 「非故障场景下产出的每条记录的 version 字段值为 1」
- 「故障场景下，可以在同一 sink 中产出 version > 1（非 1）的数据，代表故障修复数据提供给下游消费」
可应对的故障场景
上游 flink 任务 A 发生故障导致产出脏数据至 kafka X，并且下游消费方可以按照下面两类进行划分：
- 「下游为 flink 任务」：flink 任务 B 消费 kafka X 中的脏数据，结果计算并产出错误数据
- 「下游为 OLAP 引擎以及 BI 看板」：结果导致看板展示数据异常
首先介绍下避免以及处理上述问题的整体思路：
- 「1.优化逻辑，保障上游任务稳定性」：首先通过一些优化手段，尽可能保证上游 flink 任务 A 不出现故障
- 「2.配置作业监控报警」：针对整条链路配置对应的监控报警等，以及时发现和定位问题
- 「3.制定故障处理、修复预案」：需要制定对应的故障处理、修复预案，一旦出现故障，需要有可处理故障的能力
- 「4.下游针对数据源特性改进消费和处理方式」：保障即使消费了脏数据也不会对业务逻辑产生影响
下文主要介绍「第 2 点」，出现上述故障时修复的方案，针对以上场景，目前有如下 3 种可选方案修复数据：
- 「方案 1 - 离线方式修复」：通过离线方式产出修复数据，对脏数据进行覆盖操作。缺点是故障修复延迟较高，需要切换离线、实时数据源，人工操作成本较高
- 「方案 2 - 实时方式修复」：重跑修数逻辑，产出修复数据至 kafka X-fix，下游 flink 任务 B 重新从 kafka X-fix 中的指定 offset 开始消费，计算并产出正确的数据。此方案对下游 flink 任务 B 来说，需要改动代码逻辑，存在修数 topic 和原 topic 切换逻辑，修复逻辑较为复杂
- 「方案 3 - 实时方式修复（本小节 version 字段方案）」：为避免下游产生数据源切换操作带来的高成本操作，可在原有 kafka topic 中产出修复数据，通过 version 字段区分正常产出数据以及修复数据，相对方案 1 和 2 的优点在于，不存在数据源切换逻辑，下游通过控制 version 字段值就可消费到对应的修复数据，明显降低人工操作成本，且修复逻辑相对简单
❝Note: 方案 3 需要对 Kafka X 预留一定的 buffer，否则在产出修复数据时，由于写入或读出 Kafka X 的 QPS 过高，会影响正常产出数据的任务。
❞
sink schema 中添加时间戳字段
实践案例及使用方式
有窗口场景中，sink schema 中可添加以下字段：
- 「flink_process_start_time(long)：代表 flink 窗口开始逻辑处理的时间戳」
- 「flink_process_end_time(long)：代表 flink 窗口结束逻辑处理的时间戳」
- 「window_start(long)：代表 flink 窗口开始时间戳」
- 「window_end(long)：代表 flink 窗口结束时间戳」
生产实践案例
- 「flink_process_start_time，flink_process_end_time 在开发、测试、验数阶段可帮助用户定位数据偏差原因」
- 「window_start，window_end 可以帮助用户定位每个窗口处理是否有丢数，及每个窗口处理的具体数据」
总结
本文主要介绍了在 sink schema 中添加 version（版本），时间戳扩展字段的小技巧，以帮助用户在生产环境中提升实时数据故障修复效率以及可用性。
公众号(mangodata)里回复 flink 关键字可以获取 flink 的学习资料以及视频。
