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

大家可能会看到,对于大数据来讲,每个指标都是数据,这个指标你测试之前可能它都是正确的,但是如果某一天有新的数据进来,因为每天都会有新的数据在进来的过程中,你还能保证你的指标结果的正确性吗,怎么保证这是我们需要考虑的.

挑战四：口径一致性

因为我们业务人员很多,每个业务人员口径都是不一样的,比如场外基金,对于有些业务人员指的场外基金就是场外基金,有些业务人员认为场外基金就是场外的公募基金,所以我们怎么保证对外提供的口径的一致性.

挑战五：规模化服务

8万多指标,如果不对外提供服务,其实它都是一堆死的东西,没有任何意义的,你要让它产生效益,就要对接平安所有的平台.

挑战六：人力

我们平安证券测试团队有一百多人,看起来人力还是很多的,但是我们这些人力都分散在各个子系统下,比如交易系统、基金系统,这些都是一个个的子系统,这些人力都分散在各个子系统上,对于统一底层仅有十个人力,十个人力要对接8万多个指标,这是我们当前面临的挑战.

4、我们的解决思路和方案

4.1 我们的解决思路

为了解决这些问题,我们的解决思路是：围绕数据本身,需要相关的规范和流程去保证每个环节的准确性,规范和流程需要工具去管控.

规范、流程、工具应用到开发、测试、监控各个环节来保证最后指标数据的准确性.

在数据开发平台会有 DSP 数据服务平台,和 CM 公共服务平台,这两个平台保证开发过程中数据的准确性；然后数据到自动化测试平台.

我们团队最初的时候,三个人力测试一百张底表,几乎花了一周时间.最后我们状态是什么,所有人把表分析完了,再也不想看数据了,因为那个数据看的自己都想吐的过程.

所以通过自动化平台减少我们的重复劳动,把精力花在分析数据上.数据上线后,通过监控系统来每天监控数据的准确运行.

我们先看一下在开发平台当中怎么保证数据一致性的,在我们平台每天会运行几千个脚本,那怎么保证所有开发人员它的操作是同步一致性的,我们是从这几个方面保证的.

4.2 DSP数据服务平台解决方案

所有开发人员在创建调度会保证创建调度一致性,调度创建之后开发人员进行执行,执行之后会进行比对,比对完成之后会由相关人员进行审核,审核完成之后,这些数据才能合并到主表当中.

4.3 创建调度如何保证

创建调度这个环节我们是怎么保证的呢?我们主要分成下面几个层面来处理.

• DB 到 RAW 层
  数据从 DB 到 RAW 层,也就是同步层,我们会看一下我们的数据来源于哪个数据库,因为我们有几十个数据库.这时大家都可以选择相应的数据库和模式,输入表名,会自动检测出来这张表当中有多少字段,以及这些字段转化的类型,数据到 RAW 层的时候,类型是需要处理的.有些开发人员可能会发现,生成的字段类型不符合预期,是可以修改的.
• RAW 层到 MID 层
  创建都是自动的,只需要点击一个按钮就可以自动生成 MID 层,并且生成相应的清洗 sql,对于一些常用的字段会有一些自定义函数,生成的 sql 会自动套用自定义函数.比如日期类型等.在我们 MID 层,会统一处理成一样的方式,比如客户是十五位身份证,需要把这些身份证做18位转化,这些都是我们通过自定义函数在 MID 层做清洗的.

  有些开发人员可能会觉得有些字段清洗方式还不够的情况下,你可以在外围增加清洗的方式,但是不能更改当前的清洗方式,这是流程会监控到的.

• BASE 层
  然后是 BASE 层,BASE 完成之后到 fact 层,对于指标系统,我们会涉及到对应的指标,以及我需要对这些指标做一些相应的聚合、汇总或者求一些值,这些都是在相应系统里自动配置,然后生成相应的脚本,是不存在人工处理的方式.

4.4 测试如何执行

我们在创建调度环节,通过自动化的方式,来保证我们在开发过程当中,所有的生成的调度是一样的.

这时候调度创建成功了,需要进行验证,也就是我们测试执行的过程,在这个过程当中,我们开发人员需要进行自测,因为这个版本是待上线版本,需要验证,选择执行的日期,比如一些存量表要执行一天.

对于增量表可能需要执行很多天,执行以后这些数据会放在临时位置上,需要对临时数据进行校验.

4.5 测试如何比对

我们还有一个测试比对环节,在测试比对环节所有模板都已设置,在模板当中我们会完成哪些功能呢?

第一,我们字段里表结构,这些最基本的,我们会进行全面的验证.

第二,一些 count、max、min、sum,还有空值、空格、NULL 值,长度、频度诊断,还有数据比对.

这样我们在整个开发流程当中,可以保证 RAW、MID 层不用再转测试,BASE 层和 fact 层,因涉及业务逻辑,需要测试人员进行验证.

4.6 我们的测试方法

在我们测试的时候,常用的方法有很多,最重要的一点是我们需要对源数据进行分析,这就是数据诊断过程.

1. 我们会进行 DT 分布诊断,比如对于全量表,dt 分布应该是曲线上升的,如果某天变成曲线波动,就说明出现了问题.
2. 我们会做重复观测诊断,重复观测诊断可以判断,来确定这张表的组件是什么,如果数据主键存在重复数据的情况下,就要确认这张表是不是迁移的时候就有问题还是源数据有问题,这是需要分析的.
3. 单变量诊断,这里有频度、长度、截取前XX位的.
4. 数据类型分布诊断,有 sum、均值、标准差、max、min、分位数、中位数等.

其次,我们会做业务诊断.我们对业务诊断过程中,大家会发现对于底层表可能有几十个,我们需要分析字段和字段之间存在一对一,还是一对多,还是多对一的关系,避免数据虚增；

数据关系映射,表间映射关系,诊断通过哪些字段进行关联；

另外我们还会进行表间 HITRATE 诊断,不同表间 ID 类字段的匹配率,来确定哪张表是主表.

只有通过诊断,才能发现哪些数据或者业务存在问题,不是说业务告诉我什么样子就是什么样的情况.大家可能会很奇怪,你们做这么多诊断,你们在项目中是怎么做的.

举个例子,经常使用平安证券 App 的人会知道,我们页面上会有收益额,比如收益额 = 期末市值 – 期初市 + 卖出 – 买入.

因为交易处理方式是不一样的,比如晚上我们要做清算,可能有些公司不是这样的情况,我们要跟交易所做清算,跟 TA 公司做清算等,这些清算规则也是不一样的,不同基金清算方式不一样的.

并且我们数据来自不同系统,比如账户系统、交易系统、基金系统、融资融券等.

（编辑：ASP站长网）