实时链路中的Kafka数据发现某字段值错误

0、背景

今天分享的是一个生产环境中遇到的问题：早晨8点之后发现kafka的record中某个字段的值出现了错误，现在已经10点了，需要对kafka进行数据订正，怎么样定位和解决这个问题，达到最快响应和最小影响。

一、解决思路

首先，我们在做数据开发的过程中涉及到一些基本要素：时效性保障、质量保障、稳定性保障，此外还有敏捷性、可管理性等其他要素。根据公司业务场景和重要性不同，重点也有所侧重。

1.1 时效性保障

时效性保障主要关注的几个方面：

• Kafka延迟监控：Flink消费产生的lag、业务数据下发的延迟；

• 在分层和时效延迟上做好平衡，保证链路的可复用的同时避免链路过程产生额外的时效问题；

• 数据乱序；

• 压测，应对流量高峰期，特别是大促场景下，提前做好资源保障、任务优化等措施；

• 设置延时基线，通过优化程序代码、资源、解决倾斜与反压等问题，使其控制在基线内；

• 指标监控，监控任务FailOver情况、CheckPoint指标、GC情况、作业反压等，出现异常告警。

1.2 数据质量保障

这是个老生常谈的话题了。我们在离线时代已经有了非常完善的数据质量监控体系。大家重点看加粗内容即可。

1.2.1 数据一致性监控

1. 实时计算端到端的一致性。 常用手段就是通过输出幂等方式保障，这种方式要求输出使用存储介质支持重写，对于不支持幂等的存储，比较常用的就是DWD层的kafka， 可能会产生重复的数据，那么在下游使用的时候可以使用row_number()语法进行去重，保证相同的key不会被多次计算；

2. 离线与实时的一致性，需要保证使用数据源一致、加工业务逻辑一致。

1.2.2 数据完整性监控

保证数据从源头到数据加工再到前端数据展示，不能因为加工逻辑权限，存储异常，前端展现异常等原因导致数据丢失。例如：

1. 数据源层出现背压时，导致数据源头（mq,Kafka）消息积压，积压严重时导致资源耗尽，进而导致数据丢失；

2. 数据处理层数据加工未按照需求进行加工，导致目标有效数据丢失；

3. 数据存储层的存储容量写满时，导致新数据无法继续写入导致数据丢失；

4. 数据加工正确性、数据加工及时性、数据快速恢复性构成数据完整性

1.2.3 数据加工正确性监控

目标源数据按照业务需求加工成目标有效数据，目标有效数据根据不同维度不同指标计算成需要展示的不同指标数据。例如：

1. 数据源层原始数据包含不同联盟的点击数据，那么数据处理层过滤掉不需要的联盟点击数据，并将目标联盟的点击数据根据媒体和创意信息补齐当前点击所属的账号、计划、单元;

2. 业务层根据媒体，账号、计划、单元不同维度计算出对应的点击总量;

1.2.4数据快速恢复性

数据在流转路径中因为异常导致流转中断，数据停止在某一个环节中，当异常解决，系统恢复正常时，停止的数据（停止的数据）需要快速恢复流转，并且这种恢复是正确的，不应该存在重复的消费和加工或者遗漏。例如：

1. 数据处理层因为消费程序性能问题导致消息积压，性能问题解决后数据挤压问题逐步得到缓解直到恢复正常水平;

2. 数据处理层因为消费程序bug导致程序崩溃，重启后数据消费正常;

1.3 稳定性保障

• 任务压测：提前压测应对流量高峰期，特别是大促场景下，提前做好资源保障、任务优化等措施。

• 任务分级：制定保障等级，从任务影响面大小、数据使用方来划分，一般情况公司层面优先于部门层面，外部使用优先于内部使用，高优先级任务需要优先/及时响应、必要情况下做双链路保障机制。

• 做好指标监控：指标监控，监控任务failover情况、checkpoint指标、GC情况、作业反压等，出现异常告警。

• 高可用HA：整个实时Pipeline链路都应该选取高可用组件，确保理论上整体高可用；在数据关键链路上支持数据备份和重放机制；在业务关键链路上支持双跑融合机制。

• 监控预警：集群设施层面，物理管道层面，数据逻辑层面的多方面监控预警能力

• 自动运维：能够捕捉并存档缺失数据和处理异常，并具备定期自动重试机制修复问题数据

二、解决方案

再回答问题本身，我们可以从下面三个方面回答：

• 事前：本问题是从数据质量角度产生的问题，可以从数据质量监控的角度，有必要的数据质量监控和对应的报警；
• 事中：在问题发生后，要有正确的SOP流程处理数据异常。例如，通过公告、默认值、开关等方法，降低数据质量带来的舆情影响；
• 事后：要进行数据修复。是否需要进行数据回溯，或者通过离线回补等方式进行修复。

当然这只是一个思路，你能结合工作中的具体场景，举例说明就更好啦。

参考资料：

1.wx公众号（大数据技术与架构）-《生产环境中的面试问题，实时链路中的Kafka数据发现某字段值错误，怎么办？》