有赞DQC数据质量监控实践
The following article is from 有赞coder Author 有赞技术
部门：技术中台/测试开发
有赞数据报表中心为商家提供了多维度、多渠道、多周期的数据，帮助商家更合理、科学的运营店铺，同时也直接提供分析决策方法供商家使用。
多维度是指支持正逆向交易、商品、客户、流量、营销活动...
多渠道是指支持全渠道、H5、APP、小程序（微信、支付宝、百度...）...
多周期是指支持实时、自然日、自然周、自然月、近7天、近30天、季度、自定义
监控背景&解决的问题
因为数据涉及商家运营策略的制定，所以在商用数据及时性和准确性上都会有很高的要求，而数据除了发布可能引入问题之外，每日调度时依赖表缺失、组件异常或者数据异常等均可能造成数据问题，所以线上监控就显得非常重要，是发现和拦截问题的重要手段。本文主要分享有赞针对离线和实时数据做的一些监控实践，当前商家数据基本在7点前完成产出，所以线上监控规则大多是7点开始调度，为了更早的发现问题，我们也开始做业务层表（kylin）构建完成后触发监控。
章节分为5块：1.有赞的数据流图 2.离线数据（批处理）的线上监控详解 3.实时数据（流处理）的线上监控详解 4.线上监控效果 5.后期规划。
一、有赞的数据流图
有赞的数据主要来源于交易、商品、客户等各业务方和C端的埋点日志，在数据处理阶段提供离线和实时数据两个维度，在应用层不仅支持了通用的数据报表，也支持定制化的业务数据。
数据流图如下：
二、离线数据（批处理）的线上监控详解
1、离线数据描述
离线数据定义为昨天及以前时间的数据统计，周期维度有自然日、自然周、自然月、近7天、近30天、季度、自定义，主要是通过hivesql来处理和聚合。在梳理规则前，先简单了解下离线数据链路每层的特性。
1.1 准确性规则-线上监控梳理
离线数据的线上准确性监控分为指标、表和应用层三个维度，其中指标准确性又分为“跨表对比”、“同表逻辑性判断”和“自身判断”；表维度分为“行数判断”和“大小判断”；应用层分为“接口返回历史数据不变判断”。
指标维度
跨表对比：是指不同表相同指标之间的等值判断，有赞数据中心当前仍然存在着页面不同定义相同的指标，来源于不同的底层表，后期随着底层表统一模型的建设，此类对比监控比重会逐步下降。
同表逻辑性判断：是指同表不同指标之间的逻辑判断，比如支付人数<=支付订单数。
自身判断：是指做指标本身的规则判断，比如枚举值、唯一性、非空性判断。
表维度
行数判断：是指表全量或者分区表行数基于过去某时间数据的同比/环比的变化判断，同时也支持取值范围的判断。
大小判断：是指表全量或者分区表大小基于过去某时间数据的同比/环比的变化判断，同时也支持取值范围的判断。
应该用维度
历史数据不变判断：是指过去某天/周/月下，在指标定义不变的前提下，接口返回数据不变判断，属于数据回归部分。
基于上述描述，离线数据线上准确性监控模型的脑图如下 ：
监控维度确认后，下一步需要确认的是触发时机，离线数据处理流程长，每层的数据特性决定了对应的判断规则case，规则case详情描述如下 ：
1.2 及时性规则-线上监控梳理
离线数据产出时间，上层表象主要由作业的开始调度时间、执行时长、deadline时间和规则校验时间这4个因子影响，下层影响因子是作业开发平台和大数据组件的稳定性。
开始调度时间，是指作业的开始进入队列时间，不是开始执行时间。
执行时长，是指作业开始执行到结束的时间，通常是由作业优先级、执行引擎、SQL执行效率影响。
deadline时间，是指从作业开始调度，最长的可执行时间。
规则校验时间，是指针对表编写的校验规则(电话告警)执行时间，数据更新时触发，当前最多可执行8分钟，超过即开始下游调度。
通过上述描述的4个影响因子，同时结合上层表象是下层的体现，确认了商用指标工作流优先级P3及以上和数仓时间基线（待实现）的策略，以及deadline和电话告警耦合、接口返回指标数值判断兜底等保障方法（当数据未产出时，应用代码默认为0或者直接返回空，接口返回指标数值判断，更新为接口返回指标数值>0判断。），其中接口返回指标数值>0判断和deadline告警为线上监控，也是接下来着重介绍的。
2、线上监控规则的实现
针对不同层级数据，所有线上监控覆盖面参考下图：（实圈为覆盖项，空圈为无交集项）
平台监控职责以及保障维度拆解如下：（图中“BI报表”主要是做元数据管理平台监控数据的报表统计，本次不做详细介绍）
2.1 线上监控示例
2.1.1 准确性示例
基于元数据管理平台，实现“同表逻辑性”判断，数据变更时自动触发规则校验，具体实现如下图 ：
基于接口自动化平台，实现数据回归用例-“数据接口返回历史数据不变”判断，7-24点每10分钟定时触发，对于离线数据做10分钟间隔触发，也是为了监控数仓刷数和应用发布的动作。
准确性监控，示例数据中心全量指标，如下图 ：
2.1.2 及时性示例
基于接口自动化平台，实现“数据接口返回指标数值>0”判断，7点定时触发。
及时性监控，示例流量概况页面指标，如下图：
三、实时数据（流处理）的线上监控详解
1、实时数据描述
今日实时数据的统计时间均为今日零时截至当前更新时间，有赞数据中心实时数据主要分为店铺和商品两个维度，会对交易(正逆向)、流量、营销、商品多个业务方的数据做处理，最后结果数据落入底层存储，涉及的处理组件为Flink，底层存储为druid和TIDB。
1.1 准确性规则-线上监控梳理
实时数据的准确性校验分为上下游数据对比、昨日实时与昨日离线数据对比。
上下游数据对比：是指业务方binglog日志传到数据侧时，在TIDB存入明细数据，按指标统计规则处理后与底层存储对比。
昨日实时与昨日离线数据对比：是指昨日实时数据完全落库后，通过接口再提取出来与昨日离线的数据进行比较。
1.2 及时性规则-线上监控梳理
实时数据及时性，上层表象为实时指标不变或者变化缓慢，下层表象是kafka有积压，导致延迟的主要影响因子是Flink的配置和集群资源，对于集群和kafka的监控由运维同学cover，暂不做详细介绍。
2、线上监控规则的实现
上下游数据对比，执行时间为：全天每20分钟执行一轮，一轮校验500次，均不相等时，触发告警。
@Override
@Scheduled(cron="0 0/20 * * * ?")
public void teamOrderCheck() {
tidbCheck();
druidCheck();
}
public void druidCheck() {
boolean druidAlert = true;
try {
//druid
for (int i = 0; i < 500; i++){
boolean res = checkOnceTeamOrder();
if (res){
druidAlert = false;
break;
}
Thread.sleep(2000 );
}
String druidPayCnt = getDruidPayCnt();
String detailPayCnt = getDetailPayCnt();
if (druidAlert && !druidPayCnt.equals(detailPayCnt)){
log.warn("500次检测均不通过.");
String content = "实时交易数据异常预警:druid 统计支付订单数:%s, 交易明细支付订单数:%s";
alertBiz.commonAlert(String.format(content,druidPayCnt, detailPayCnt));
}
}catch(Exception e){
log.warn("team order check error.");
}
}
昨日实时和昨日离线数据对比，是基于接口自动化平台，分别调用数据应用的实时指标统计与离线接口，因依赖昨日离线数据，所以执行时间为每天早上7点，10分钟轮询调度方式，示例如下图：
四、线上监控效果
21年上半年以来，线上监控累计预警问题25+，其中18个是延迟性问题，有1个问题升级为故障，能够较好的在商家发现问题前，响应和处理，为商家正常使用准确的数据进行运营决策保驾护航。
五、后续规划
在数据质量线上监控实践中，仍有一些事项没有去落地，比如告警影响面评估、数据质量监控大盘等。
【告警影响面评估】出现告警时，需要确认监控的业务影响范围有哪些，不仅仅可以给到客满同学，在回复商家咨询问题时更精准，更是可以在问题修复后，可以进行准确的回归测试。
【数据质量监控大盘】BI报表承接了元数管理平台的监控统计，而当前监控涉及多个平台，需要对各平台的监控数据做实时聚合统计，会涉及指标设计、实时任务、前后端的开发。
猜你喜欢：伴鱼DQC数据质量平台实践
关注我们，一起进步！