有赞数据报表中心为商家提供了多维度、多渠道、多周期的数据，帮助商家更合理、科学的运营店铺，同时也直接提供分析决策方法供商家使用。

• 多维度是指支持正逆向交易、商品、客户、流量、营销活动...
• 多渠道是指支持全渠道、H5、APP、小程序（微信、支付宝、百度...）...
• 多周期是指支持实时、自然日、自然周、自然月、近7天、近30天、季度、自定义

监控背景&解决的问题

因为数据涉及商家运营策略的制定，所以在商用数据及时性和准确性上都会有很高的要求，而数据除了发布可能引入问题之外，每日调度时依赖表缺失、组件异常或者数据异常等均可能造成数据问题，所以线上监控就显得非常重要，是发现和拦截问题的重要手段。本文主要分享有赞针对离线和实时数据做的一些监控实践，当前商家数据基本在7点前完成产出，所以线上监控规则大多是7点开始调度，为了更早的发现问题，我们也开始做业务层表（kylin）构建完成后触发监控。

章节分为4块，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报表承接了元数管理平台的监控统计，而当前监控涉及多个平台，需要对各平台的监控数据做实时聚合统计，会涉及指标设计、实时任务、前后端的开发。

最后欢迎更多的朋友加入我们一起去落地这些规划

招募优秀的你加入👇