前言 实时数据是指对规模巨大的数据利用大数据技术高效的快速完成统计，达到近似实时的效果。对于商家来说，它的最基础价值是体现店铺当天的营业、访问等情况，进一步价值是可以去支撑商家及时更新针对用户的营销策略，提高商品访问到成交的转化等等，它不仅能提升商家的GMV，也能给用户带来好的体验，高效的买到自己心仪的商品，对此如何快速识别实时数据的质量问题，尽而快速止血，本文主要是从线上监控的质量方向来保障实时数据的质量。
文章主要分为5块：
- 监控背景
- 监控方案梳理
- 监控方案实现
- 监控告警处理
- 监控效果以及未来展望。
一、监控背景
实时数据在上线前，会经过精准、全面的测试，保证上线的数据无问题，但也无法避免因为底层组件升级、资源不足、硬件问题等等不可控因素导致的线上问题，同时以前的实时任务基本是线上裸奔的状态，没有很好的监控方式，对于数据问题很大程度上依赖于商家的主动上报，在这个背景下，急需一套完整的实时数据线上监控体系，来保障商家可以制定出合理的经营策略。
此监控体系最基础的需求是要覆盖数据的准确和及时性维度，同时能在分钟级别发现线上问题。
二、监控方案梳理
当前有赞数据中心大多实时指标为今日实时数据，统计时间为今日凌晨0时至当前时间，主要有店铺和商品两个维度，会对交易(正逆向)、流量、商品多个业务方的数据通过实时计算框架(Flink)做处理，最后结果数据落入底层存储（druid和TIDB等）
常规的实时指标统计流程如下：
实时数据出现问题的表象一般可以分为以下三种：
- 数据错误，体现数据不准，可能是指标实现逻辑有问题，是准确性特性。
- 数据变化缓慢，体现数据可能有积压，实时任务或者资源问题引起数据延迟产出，是及时性特性。
- 数据不变，体现数据不准或者有积压等，可能是准确性也可能是及时性特性 。
基于上述提到的数据问题表象，同时整理我们有的能力：1.Flink SQL的本地调试 2.Flink实时任务开发 3.接口自动化平台，给出“实时任务输入输出校验”、“上下游数据对比”、“昨日实时与昨日离线数据对比”三种解决策略，它们的主要功能描述如下：
- 实时任务输入输出校验，主要是基于Flink SQL本地调试功能，对某一个实时任务进行监控。
- 上下游数据对比，将最上游kafka明细数据，按照指标统计口径实现聚合，与开发的结果表数据对比，是覆盖全链路实时任务监控。
- 昨日实时与昨日离线数据对比，是指昨日实时数据完全落库以及离线数据完全产出后，通过应用层接口(http/dubbo)将两个维度的数据提取出来进行比较，是对于结果层以及应用层修改的监控。
针对三个方案分别对应的保障维度、优点、不足、触发时机以及主要覆盖的问题参考如下：
三、监控方案实现
针对实时数据整理的三个方案，做的线上监控都是在接口自动化平台实现以及统一管理的，通过对接口的返回做断言，判断失败，会触发相关告警。
01
Flink本地调试，适合监控有逻辑处理的实时任务
本地调试支持三种数据验证方式：手动输入数据、上传数据文本、从kafka随机读取数据，主要用于上线前的任务逻辑准确性检测，可以极大提高开发效率，同时已支持任务中存在多个source和多个sink表的调试，详细的功能设计方案如下：
做实时节点监控主要是用到了“手动输入数据”场景，入口如下图：
通过本地调试实现单任务监控的流程如下图，核心是拿到入参消息体和返回，通过固定的入参消息，对返回做断言：
详细步骤解析：
- 拿到topic信息； 通过在线计算平台，查看实时任务，找到创建source表配置，关注connector.topic参数，可以拿到对应的kafka topic信息。
- 拿到kafka消息体； 同时平台提供kafka管理，找到对应的topic，拿到kafka消息体，可以复制及编辑成想要的入参。
- 拿到返回，添加用例； 通过本地调试，输入步骤2的消息体，拿到实时任务处理后的返回，在接口自动化平台添加用例及断言，后续在线计算平台会支持事件订阅，实时任务变更发布即触发自动化用例。
02
上下游数据对比，适合用于监控实时流链路长、指标统计口径复杂，输入场景多&核心的指标
上下游数据对比，业务binlog数据通过nsq传给kafka后，将此明细数据落库，指标按统计口径实现，与开发的结果表数据对比，此处明细数据落库的必要性是为了方便排查线上监控问题。
具体步骤参考如下图：
详细步骤解析：
- 第1和第2步是前置准备动作，需要梳理消息域对应的kafka信息，是编写实时任务创建source表时必备的。
- 指标统计口径梳理及确认，需要开发、测试、产品经理一起参与。
特别关注点，对于源数据信息直接处理，以及消息按线上流程产出到结果表，这两者存在一定的时间差，因此需要多次对比，示例店铺维度支付金额、支付订单数指标，每10秒轮询一次，对比10次，10次全不相同触发告警，如果存在准确性/及时性问题，最早10*10=100秒左右发现。
03
昨日实时与昨日离线数据对比，重心是保障实时和离线数据的口径一致
昨日实时和昨日离线数据对比，分别调用数据应用的实时与离线指标接口，对两类指标做等值判断。
有赞数据中台对于离线数据存储主要使用kylin，实时主要使用druid，两类组件使用HLL估计值算法来计算去重指标的近似值，示例访客数、支付人数等，在断言时，需要做下差值范围判断。
示例如下：
四、监控告警处理
上述补充的监控用例触发告警后，问题的排查流程可以参考下图，对于数据延迟告警，可以看kafka积压现状，本次不赘述，流程中核心的步骤(标红)为：
- 查看&分析明细数据
- 重放数据
针对核心步骤“查看&分析明细数据”，在“上下游数据对比”方案中有将明细数据落库，通过接口调用展示到页面，减少捞数据/查询数据的时间，如图：
“重放数据”操作亦有平台支撑，通过和开发大哥一起搞“实时数据恢复演练”，优化和补充脚本，产出了操作文档。同时可以让开发能够熟练的进行数据修复，减少误操作和花费不必要的时间，将实时数据修复时间控制在半小时左右。
五、监控效果以及未来展望
在上下游数据对比方案上，目前因为时间、资源等原因，只覆盖了核心指标，包括店铺正向，商品正向和逆向，占整体实时指标30%左右，对于流量、加购等指标仍需要去补充；而且数据中心大部分实时指标仍然是通过Flink jar的方式实现，本地调试功能不太适用，对于此类单节点任务的线上监控暂时没有好的解决方法，好的消息是后续会逐步往Flink sql迁移。
线上实时数据质量的保障，除常规的测试方法覆盖外，线上实时监控针对目前线上实时数据质量保障策略中作为强有力质量辅助手段，填补了实时数据线上监控空白，从可观测层提前感知数据质量的健康情况，对后续数据故障演练，快速止血修复建立了基础承接。
