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

• 多维度是指支持正逆向交易、商品、客户、流量、营销活动...

• 多渠道是指支持全渠道、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.");
        }
    }123456789101112131415161718192021222324252627282930

昨日实时和昨日离线数据对比,是基于接口自动化平台,分别调用数据应用的实时指标统计与离线接口,因依赖昨日离线数据,所以执行时间为每天早上7点,10分钟轮询调度方式,示例如下图

四、线上监控效果

21年上半年以来,线上监控累计预警问题25+,其中18个是延迟性问题,有1个问题升级为故障,能够较好的在商家发现问题前,响应和处理,为商家正常使用准确的数据进行运营决策保驾护航。

五、后续规划

在数据质量线上监控实践中,仍有一些事项没有去落地,比如告警影响面评估、数据质量监控大盘等

【告警影响面评估】出现告警时,需要确认监控的业务影响范围有哪些,不仅仅可以给到客满同学,在回复商家咨询问题时更精准,更是可以在问题修复后,可以进行准确的回归测试。

【数据质量监控大盘】BI报表承接了元数管理平台的监控统计,而当前监控涉及多个平台,需要对各平台的监控数据做实时聚合统计,会涉及指标设计、实时任务、前后端的开发。