• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

Tips | Flink sink schema 字段设计小技巧

kafka 来源:mangodata 16次浏览

本系列每篇文章都比较短小,不定期更新,从一些实际的 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 的学习资料以及视频。


版权声明:本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。
喜欢 (0)