平安证券刘宏霞：教你如何保障大数据质量(3)

我们看算一个收益指标是怎么做的.

• DT分布
  先是 RAW 层和 MID 层,这两个层的数据基本与原数据保持一致的,唯一不同是我们的清洗层会对相应数据进行处理,比如 dt 分布诊断.可以判断每天的数据是不是存在问题.另外还可以判断底层为了上层进行汇总的时候,第一天数据起始日期是否一致,因为数据来源于不同系统,而且我们所有系统开始日期都是不一样的.

  比如交易股票,可能很早之前就有数据了,但是我们场外基金是最近几年才有的,如果拉历史数据少拉一年或者少拉一天数据,算出客户最终收益都是不对的.

  只有把底表历史数据拉出来以后看开始日期是不是正确的,这样才能保证上层汇总的数据是不是正确的.

• 重复观测
  重复观测,比如一个客户同一天有多笔交易,需要判断客户是因为买了这么多次交易,还是因为交易流水本身出现问题,客户是否是一模一样的交易记录,这两种方式最终处理方式是不一样的.
• 单变量的诊断
  我们会做单变量的诊断,一般情况下,业务人员或者研发人员会告诉你市值从哪里获取,但是获取的时候会发现市值有空的情况,那就要分析这个客户有没有股票,如果客户有股票,市值为空的话,那就是有问题,就需要重新在判断.
• 数据诊断
  数据诊断,如果说不对数据进行诊断,就不清楚这个业务什么样子,可能有些人会认为,业务人员都很资深的,对这些都很了解,那是否还知道十年前的数据是什么样的吗,只有通过深入分析,才能对数据上层进行汇总,保证它的质量.以我的资金为例,可以看到这个客户的资金流水是在哪个范围之内,才能确保上层汇总出来的数据是否正确.如果已经对客户总资产算出来一个范围,在上层汇总的时候,发现明显有大的变化,那只能说明在实现业务的过程中数据数出现了问题.
• 业务诊断
  业务诊断,另外还有根据业务的行为,确认上层怎么进行汇总.经过诊断之后,才能根据这样的情况做上层,就是 BASE 层,BASE 会根据客户和产品粒度进行汇总,比如客户买了哪支股票,他的收益额是什么情况,或者不同的股票,不同的基金等等.BASE 层汇总,还是一样要做相关的数据诊断和业务诊断,我们也会根据原始业务诊断结果,确定上层业务场景是不是做了全部覆盖.

BASE 层之后是业务实现层,这时候就比较简单了,我们可以根据客户粒度进行汇总,客户收益是什么样的,这种情况下,除了做诊断之外,还会做一些比较,只有这样才能算出真正收益是什么样的.

只有在不同层级保证之后,才能保证最顶层数据是不是正确的.那要做这么多数据诊断,纯粹靠人工做是不现实的事情.

所以搭建了自动化平台,会对 RAW、MID、BASE 层做各种诊断,把相应的诊断sql录入到自动化平台,后续所有执行都是由自动化平台执行的,执行出来的结果再作分析.比如现在有一个新的指标,需要对哪些字段进行相应诊断的时候,只要运行下自动化脚本,看一下结果图就可以了.

这样大大方便了测试人员,降低了手工测试成本,只需要维护测试脚本就可以了.在运行结果之后,可以看到这次运行多少个,失败多少个,看下失败的是什么造成的.

5、平安大数据监控平台

除了测试,数据是要进行上线的,上线之后不可能每天再进行测试,也没有那么多精力,对已经上线的指标通过监控平台进行监控数据运行情况.

监控平台主要从几个方面进行监控.

我们会对每个层级进行监控,监控主要分为几个部分.

一是,调度监控,因为所有大数据实现的业务逻辑都是通过调度实现的,我们就会对调度进行监控.

二是,数据相关的监控指标,对数据指标进行监控.

三是,还有业务口径相关的监控指标,这个是IT人员业务口径.

四是,还有是业务人员自己要监控的一些业务指标,通过设置要监控的参数,放到监控平台里面.

如果说每天跑完之后,有异常数据,会由告警平台发出相关邮件,通知大家要进行相应的处理.

我们现在看一下调度监控都会监控哪些东西?

5.1 任务状态运行的监控

目前我们运行的调度大概在1300多个,每天都会监控运行的情况,还有一部分存在依赖关系的调度,如果之前调度没有运行完的话,会定时发送邮件告诉开发人员调度是延时了,这是业务运行状态进行监控.

可能很多人会觉得,一个调度运行一个小时,两个小时觉得是很正常的事情.但在我们平台上,一个调度运行超过十分钟就要分析,这个调度的代码是否是有问题的.

有些开发人员可能说写的结果是对的,它能够跑出结果就可以.但是调度运行时间长了,往往会影响到后面整个运行的过程,那就会导致今天一天数据可能都没有办法算完.

所以我们对于每个脚本运行时间是有限制的,如果超过十分钟,开发人员就要检测是不是代码是否存在问题.

5.2 依赖关系监控

我们还有一种监控,就是依赖关系监控,大家可以看出,我们一个调度可能你的上层依赖很多调度,你的下层也依赖很多调度,那调度和调度之间是存在依赖关系的,一个调度失败可能会影响到其他调度的失败.

那么怎么监控?我们会监控到你上层依赖多少调度,下层依赖多少调度,因为这个脚本比较特殊,依赖特别多,原因它是我们最后一个调度,它需要向我们数据库推送8万个指标的,所以它的依赖特别大.

在我们调度依赖会有一些设置,如果它依赖的上层调度或者下层调度存在问题的话,就会立即停止运行,由运维人员进行处理.

5.3 数据规则监控

另外是对于数据规则的监控,一个是基本规则的监控,第二自定义规则监控,基本规则监控相对比较简单,大家在测试和开发过程当中会做的一些长度诊断或者频度诊断等,这是作为基本功能的监控.

（编辑：ASP站长网）