一线券商教你如何保障大数据质量

作者简介：

刘宏霞

平安证券 大数据测试组负责人

2014年加入平安证券，正值互联网金融潮流兴起，组织并参与大数据自动化以及监控体系的搭建、应用和优化。熟悉券商核心业务，对数据有着浓厚的兴趣，并把相关的技术应用到数据质量上，不断地探索券商数据质量之路。

前言

这两年对于大数据来讲，大家看到有很多产品出来，很多公司也在利用数据做些东西，包括现在的一些电影。

前两天的时候，同事给我推荐一部叫做《庭审专家》的美剧，大概花了一天时间把它看完，故事讲的很简单：在美国庭审当中包含陪审团概念，通过大数据分析陪审团行为模式，然后预测他们的想法。这样来讲，大数据应用完全掌握在拥有数据的人身上。

那如果数据质量本身存在问题，就会导致数据分析出现误差，甚至错误的预测或者误导性的描述。所以今天我给大家分享的主题是券商的大数据保障之道 。

在分享券商大数据保障之道之前，我们先看一下平安证券在大数据方面都做了哪些。

1、平安大数据做些什么

经常使用平安证券 APP 炒股的人会发现，我们平安证券 App 过去一年变化非常大，在刚刚过去不久，由证券日报主办的第十二届证券市场年会中，我们平安证券 App 被评为最佳金融 App 大奖。

我们为用户提供个性化的服务，比如 App 功能上有一些千人千面，猜你喜欢的内容，推送的一些功能。其中包括资产收益的功能，这些数据是来自用户大数据，帮助更好为用户推荐产品，也帮助用户更方便获取信息。

在行情方面我们也会做一些股价预警，智能选股等等，可以帮助用户化繁为简，准确操盘。另外是我们的资讯，炒股人都知道，资讯很重要，帮助用户获取最新、最全的金融资讯。

我们还有大数据产品，比如牛人牛股，帮助用户追踪牛人们在买卖什么股票。还有收益类的计算器，辅助客户进行投资决策。

另外比如客户不知道要买股票还是买基金，或者买其他产品，我们也会提供智能化服务，这些都是为客户提供个性化的服务，这是一些大数据相关的产品。

除此之外，我们平安证券还会利用大数据为我们的业务人员做一些科学的决策，依据自动化的数据平台。

比如自动化报表平台，大数据自助分析平台等。我们做了这么多事情，最大的问题是怎么保障这些数据的准确性。

我首先给大家介绍一下系统，我们大数据的组成部分，其次我们在测试数据中面临哪些挑战，之后是我们解决思路是什么，最后是总结以及未来的规划。

2、平安大数据系统的组成部分

先看一个最简单的情况，比如我现在有一个需求，西红柿炒鸡蛋，可能大家都比较熟悉这个场景， 我给你一个需求是西红柿炒鸡蛋，你怎么做？

• 一种方式直接拿了西红柿和鸡蛋放锅里炒，那这是不是西红柿炒鸡蛋，是的。但是你吃的时候可能有蛋壳和西红柿皮。

• 另外一种方式通过各种工序，鸡蛋和西红柿清洗干净，鸡蛋加点盐打散，西红柿去到蒂部，切成块，锅里放油，加入材料，也是一盘西红柿炒鸡蛋；

大家会吃哪盘西红柿炒鸡蛋也就一目了然了。

同样的道理，平安证券自己常用的系统大概在50个左右，另外还有数据来源于平安旗下其他子公司。如果每个分析人员都根据自己的需求直接取源数据，你会发现同一个需求不同的人做，结果都不对等的。

另外比如重复的工作量、低效的工作，无法快速响应业务需求等等问题，为了解决这些问题，我们实现了统一底层，对各个系统提供的数据都来自于统一底层。由统一底层来保障数据的质量。

看下我们统一底层的框架，从下往上看，最底层是数据源，数据源来自平安证券的所有系统（比如账户系统、交易系统、基金系统、个股期权、融资融券等等）以及部分平安旗下其他子公司的数据。

• RAW 层
  所有数据的处理都由统一底层进行，统一底层分为四层，最底层是raw层，也是数据同步层，数据采集过来会放到raw，raw层的数据与源数据一样，不做任何的操作。

• MID 层
  数据采集完成后，会到 MID 层，MID 层是数据的清洗层，MID 层会根据源数据的特性做相应的清洗，比如：日期类型的转换、身份证15位到18位的转换、空格、null 值等处理。在清洗层对于常用的清洗方式，我们会通过自定义的函数进行清洗，以保证不同的开发人员清洗后的结果一致。

• BASE 层
  数据清洗完成后，就到我们的 base 层，base 层是业务流水层，base 层根据主题进行设计，比如客户主题，交易主题，产品主题等等。

• FACT&VIEW层
  Fact 层和 view 层是业务实现层，在这个层级上根据业务的需求进行指标的产生、指标的聚合、汇总等等。固化的业务数据在fact层，未固化业务数据在view层。

我们当前已完成指标有8万多个，这些指标是指以客户为方向，每个客户涉及标签有8万多个，每天还有不断新增的指标。

我们重点关注的是中间这部分，因为我们只有保证这部分数据准确性，我们才能保证对外提供的数据准确。

3、实施大数据面临的挑战

那我们怎么保证中间这一层数据准确性呢？同样我们也面临着很大的挑战。

挑战一：指标繁多

8万多指标，仅仅用一年把它全部加进去的，对于我们测试人员来讲，8万多个指标涉及到业务，涉及到底层的很多表，那我们怎么进行处理，这是我们面临的挑战。

挑战二：数据的准确性

如果数据错了，我们往外提供的数据就是有问题的，如果每天都有业务人员跟你讲，指标好像有问题，如果把所有精力都在回答大家的问题，根本没有精力做测试。

挑战三：数据稳定性

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

挑战四：口径一致性

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

挑战五：规模化服务

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 公司做清算等，这些清算规则也是不一样的，不同基金清算方式不一样的。

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

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

• DT分布
  先是 RAW 层和 MID 层，这两个层的数据基本与原数据保持一致的，唯一不同是我们的清洗层会对相应数据进行处理，比如 dt 分布诊断。可以判断每天的数据是不是存在问题。
  

  另外还可以判断底层为了上层进行汇总的时候，第一天数据起始日期是否一致，因为数据来源于不同系统，而且我们所有系统开始日期都是不一样的。

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

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

• 重复观测
  重复观测，比如一个客户同一天有多笔交易，需要判断客户是因为买了这么多次交易，还是因为交易流水本身出现问题，客户是否是一模一样的交易记录，这两种方式最终处理方式是不一样的。

• 单变量的诊断
  我们会做单变量的诊断，一般情况下，业务人员或者研发人员会告诉你市值从哪里获取，但是获取的时候会发现市值有空的情况，那就要分析这个客户有没有股票，如果客户有股票，市值为空的话，那就是有问题，就需要重新在判断。

• 数据诊断
  数据诊断，如果说不对数据进行诊断，就不清楚这个业务什么样子，可能有些人会认为，业务人员都很资深的，对这些都很了解，那是否还知道十年前的数据是什么样的吗，只有通过深入分析，才能对数据上层进行汇总，保证它的质量。

  以我的资金为例，可以看到这个客户的资金流水是在哪个范围之内，才能确保上层汇总出来的数据是否正确。如果已经对客户总资产算出来一个范围，在上层汇总的时候，发现明显有大的变化，那只能说明在实现业务的过程中数据数出现了问题。

• 业务诊断
  业务诊断，另外还有根据业务的行为，确认上层怎么进行汇总。经过诊断之后，才能根据这样的情况做上层，就是 BASE 层，BASE 会根据客户和产品粒度进行汇总，比如客户买了哪支股票，他的收益额是什么情况，或者不同的股票，不同的基金等等。
  

  BASE 层汇总，还是一样要做相关的数据诊断和业务诊断，我们也会根据原始业务诊断结果，确定上层业务场景是不是做了全部覆盖。

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

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

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

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

5、平安大数据监控平台

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

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

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

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

二是，数据相关的监控指标，对数据指标进行监控。

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

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

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

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

5.1 任务状态运行的监控

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

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

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

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

5.2 依赖关系监控

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

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

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

5.3 数据规则监控

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

我们会在监控平台进行设置，还有一些是测试人员，或者我们业务人员他有自己的想法，他不想按照常规的方式，可能常规方式也不符合需求，因为这是大体上的监控，并不能保证里面的数据是不是存在问题。

5.4 自定义监控

在自定义监控上，开发人员和业务人员可以根据自己的需求设置相应的指标，这个平台相对而言，它灵活性比较高一些，可以被我们所有相关人员进行使用，根据需求进行监控。

除了数据监控之外，我们业务人员会根据自己的需求，从业务角度制定相关的监控。比如一些核心指标，可以在监控平台进行设置，也可以通过报表的方式进行监控，关注了哪些指标，这是业务人员可以根据自己的方式进行相关监控。

6、总结

最后总结下，我们是从开发阶段、测试阶段、监控阶段，来保证大数据的数据准确性，在开发阶段主要是一站式服务，从创建到执行，到比对，开发阶段完成之后，才能够转测试，在测试阶段，我们会进行数据诊断，自动化测试。

自动化测试完成后确认脚本没有问题之后，可以上线，测试人员评审，评审通过之后，就意味着调度是可以进行上线的，就发布到预上线过程，通知运维人员调度已经完成测试，可以进行上线，后面的操作就会由运维人员进行处理。

上线之后监控平台监控调度、数据、业务是否存在问题，如果存在问题，就会快速通知到相关的开发人员或者运维人员进行相应的处理，这是目前已经实现的情况。

对于未来我们有什么考虑呢？第一我们会考虑平台互通，目前我们开发平台、测试平台、监控平台，都是相对独立的。

目前开发平台和监控平台之间还有一些关联关系，但是我们自动化平台是没有跟它们进行打通的。后面会考虑，比如说开发完一个调度之后，自动到自动化平台进行运行，可以快速保证，完成测试的过程。

另外还有一个部分，我们会考虑自动化平台和监控平台打通，打通的目的比如一个指标出现问题，可能并不清楚是哪个客户指标出现问题了，如果和监控打通的话，快速知道是哪个客户的指标出现问题。

第二部分，我们会对我们的平台进行丰富，后续我们会把很多东西加入到自动化平台来，真正的产品化。另外是监控体系，目前监控体系有一部分是由数据分析人员分析出来一些值和数据提供给我们，进行监控。

但是这些是被动的，我们后期会把一些统计分析其机器学习方法运用到监控当中，丰富监控指标。

另外当前我们做的数据都是离线数据，每天晚上交易结束之后，会把数据进行迁移，对于实时数据目前没有验证，后续我们也要考虑怎么保证实时数据的准确性。

近期好文：

《一套高实用性基础架构，专治电商运维各种痛点》

《我是运维，我就这样挽救了800万用户》

《爱奇艺在搭建集群时遇到的那些“坑”》

《腾讯上万节点大规模集群的跨城自动迁移》

《腾讯游戏这么赚钱，他们的运维服务是什么样的？》

《我是一个普通运维，我就这样拯救了一个百亿互金平台》

GOPS · 深圳站， 运维人实现运维梦

GOPS2017·深圳站

GOPS

用运维的视角

创造运维的世界

• 会议地点：南山区圣淘沙酒店（翡翠店）

• 会议时间：2017年4月21日-22日

您可点击 “阅读原文”，享受特惠折扣购票