很高兴今天有机会跟大家做一个交流。做数据质量是我们做大数据的难题，很多问题都会聚焦在这里。去年在硅谷的时候我做和大数据相关的演讲，我印象特别深刻，上来一个印度裔的哥们问：“数据质量有没有捷径可走？”我当时特别想告诉他没有捷径，只能脚踏实地，躲不过去，这是做大数据、做数据质量都会面临的问题。
今天看到这么多人能聚在这儿谈数据质量我非常欣慰，为什么这样说？2005年我们面临的问题就是今天大家想的问题，这些数据怎么去保证它的质量，收集完了以后这些质量问题暴露出来你怎么处理它，等等一系列的问题我们在做大数据的过程中都会碰到。我今天将围绕数据质量跟大家做一些分享。
2001年的规划主要是指数据仓库，2003年开始建设，2005年的时候，数据质量影响到我们项目能否搞下去。一路走来，我们的合作伙伴跟我们一起参与了整个数据质量的治理全过程，每一年我们都在要上面持续投入，每年都在做相关的工作。
这张PPT是我们一个省的真实案例，BI系统接入41个系统，数据仓库里面20.9万张库表，每月新增32534张表。13个子系统，1766个分析应用，536套报表，11959个任务命令，5128个调度流程，每月对外提供378个数据接口。中国移动的数据量大概600个PB，央企里面是数一数二的。这样大的数据规模，数据质量工作的难可想而知。
以一个几年前的案例跟大家分享下。这个案例中，数据处理过程中会产生很多的业务数据，产生的错误也是五花八门的，包括逻辑错误、运行错误、接口文件的错误，甚至是指标统计口径的错误，包括编码的错误，等等。我们当时做一个应用得到的结论，用通俗说法就是，我们发现在在商场内男性比女性还愿意逛商场。我们的业务人员还出去宣传这个结论，结果后来搞了实名制后，我们的数据资料质量重新刷新，最后的结论还是女同志更愿意逛商场。这就可以看出，如果没有做数据质量整理，你的结论有可能是反的。数据质量整理是做任何分析的时候，最基础的东西。
还有数据处理过程存在包括ETL涉及到逻辑的错误、涉及到调度的异常等。我们曾经做过一个比较实的小应用，在数据模型方面做了大量的工作。当时我们也是先做应用，并通过应用来驱动。当时我们在全国范围内调研大数据，，但是到2005年刚建大数据仓库时候发现两个问题：一是应用的价值没那么明显，二是数据资产报不出来。所以刚才讲2005年是我们最艰难的时候，要判断是不是把这个数据仓库继续走下去，但后来我们还是继续坚持下来，到现在真的是柳暗花明了。
我说这些是希望跟各位分享，将来各位做大数据系统的时候，我们之前经过的坎坷和吃过的苦，各位一个也少不了。
当年我们做的第一件事不是数据质量，是元数据。首先把业务元数据和技术元数据说清楚，我们当时做的接口文档的word版就两三百页。做这种模型的设计当时借鉴的是CWM，最后我们叫它“数据字典”。什么叫数据字典？就是把概念给确定下来，取值做一些确定。这个数据字典我们花了大量的精力做相关的工作，每年都在更新，这是我们做数据质量、做数据治理少不了的工作。
做一个数据质量管理，它的全流程大概是这么几块，第一个是管理。做数据质量，今天给大家看的更多是偏技术的内容，但是实际上做数据质量的过程中，我们感悟第一件事还是管理。所以做数据质量很像数据安全。为什么这样说？说得通俗一点两者都是无底洞，都得靠问题驱动。比如我们做安全，你不出问题大家都不花钱，一出问题才想花钱，数据质量也是一样。而且数据安全首先强调管理问题，其次才是技术问题，在数据质量也上一样。现在一般讨论更多的侧重在技术，但是后头花了很多的精力做流程的梳理、流程的不规范等等，这些都管理上的疏漏，后头反思做亡羊补牢的工作。
第二是需求的开发，包括日常运维。这些运维包括借助元数据、监控、工作流建立数据全流程的保障机制。我们当时在设计的时候引入了火车站的套路“铁路各管一段”，把数据处理的过程也分成多段，每个人管自己那一段。最后评估总结，对数据质量进行评估，形成问题的通报机制。
这是功能架构图的展示，下面是业务系统，再上面是涉及到的相关功能，包括元数据、数据源的管理。这是在当中分了不同的子级，我们的系统比较庞杂，涉及到的人员比较多，几年前统计大概有十多万人。这是我说的全线的管理，包括认证。
我们做数据质量最大的问题是，开始建立数据仓库的时候都没太把数据当回事，但是真正做的时候发现数据质量问题极其繁重，比如数据质量错了，最后的结论是反过来的，这个影响很大。怎么做这种数据质量的评估？后来发现一个最重要的问题是，所谓的数据质量问题大家看的是大数据系统，实际上都是前端的业务系统。当时的管理不规范，该输的数据没输，导致出现了缺失，出现了空缺，或者是数据对不上。我们当时真实的情况，一个客户的年龄数据能达到一万多岁，真是五花八门的问题都能碰到。这就是我们面临的实际问题，数据质量需要增加规范。
数据源怎么做管理，我们做数据质量管理要记住一点，它是一个动态的，运行起来会不断产生新的数据，产生新的报表的需求，以及应用的需求。怎么能够建立一个动态的管理，动态的管理要复杂得多，所以它管理起来有很多的内容要考虑。包括怎么上线，上线后怎么保证监控。比如现在经常用到的，大型央企基本上都是问题驱动，只要指标正常就正常运转下去，如果某个指标确认异常，老大第一件事要判断什么原因导致异常。
所以大家数据质量的管理，第一是动态的，第二是有很多理论，但都不一定靠谱，这都是我们实践过程中碰到的问题。涉及到变更、涉及到下线，整个生命周期怎么对它进行相关的管控？上线的流程怎么管控？这些流程职责要说清楚。包括溯源故障，ETL处理的步骤。为什么给大家讲这个？举一个例子，我们因为系统太多，接口也太多，经常导致上游的系统改了一个接口或者文件后没告诉我们，在导入库的时候，ETL的过程中出错报错。再去找他，他会说不好意思，我有一个接口改了，或者有一个维度增加了，这导致下游极其被动，因为你的数据已经跑进去了，这个时候怎么改？用什么样的方式改？怎么做修订？后来我们采取的策略是什么？上端的数据要改必须先经过我大数据的数据质量管理员同意才能改，我觉得你这个改完以后接口太多，导致后面全乱套了，就不能改。
刚才说了做大数据第一件事就是模型。数据间的模型怎么表述他们之间的关系，不管是主题还是相关的属性。当时我们做三家数据仓库，三家在物理上没有办法保持一致，最后我们采取逻辑上一致，相关的字段要求、属性的要求、关系的要求必须一致，在物理模型可以有出入。这种模型是不是能完全统一还有很重要的点，是不是业务完全一致，中国移动的业务量太大，各省之间的业务有差异，这是我们面临的问题。
这是模型的编码，从基础层模型，几大主题域，这是用电信的模型，这个模型大概是从2003年、2004年开始做的。然后是应用层、还有编码号，甚至要把维度的值确定下来。后来发现做统计的时候，如果大家的编码不统一，最后的结果就五花八门。
这些模型运营的角度怎么审核、怎么流程提交相关的文档做更新，包括一些模型的维护，维护的过程怎么做。模型维护里最要命的就是一致性，因为物理模型和逻辑模型只要一转起来，无论是业务员还是管理者，都会发生一些变化，要定期做一致性的检查，包括逻辑模型可用性的检查。这里面涉及到模型开发的背景情况，刚才说的管理过程能够用一个模型管理工具，这样的话整个模型的添加过程都是通过这样一个工具来做的，而不是自己手动写的，管理更规范，工作的量可以降下来，强度也可以降下来。使用这样的工具后，模型的对比、模型的查询、模型的订阅、关系的映射，使用效果提高了1-2倍。
还有指标的标准体系，像中国移动一个省大概是上千个指标，这些指标怎给它进行标准定义？举一个例子，数据业务收入，这个概念可能太泛了，张三的理解是A+B，李四的理解是A+B+C，那边是A+B+C+D，怎么把所有的接口说清楚？这种指标的歧义有管理因素，也有其他的因素。大家质疑你的第一个问题就是指标对不上，A省的数和B省的数对不上，很多问题都能从指标上看出来。
指标体系做相关的管理工作，这个过程中我们需要考虑指标的目录，包括指标管理、数据分层、指标的评议、应用，再一个是涉及到接口对外服务，把这些指标发布出去，在真正运转过程中都会涉及到比较细的点。这个指标体系里面有运营监控，有做运营评价，也有做决策支持的。2003年的时候，我们要做数据挖掘的，很看不起报表，后来发现80%以上全是报表，实际情况想的有很大出入，而且报表和大家的考核各方面都是衔接的。这是真正用的时候会碰到的问题。
还有数据质量管理平台。这是一个大致的界面，数据检测的情况，正常与否都可以在这个监控平台上看到。全息信息图刚才给大家看了，是血缘分析和影响分析，这两个告警会影响到哪些指标、哪些表产生告警。这个说起来容易，如果这个表有上万个就不那么容易了。包括定制问题的处理流程，管理中都会涉及到。这是ETL工具，ETL做的时候，当时我们用了云化的方法来降低瓶颈，这是在做大数据的时候碰到的问题，每天要加很多数据进来，像运营商系统一天的量都是很大的。
这是2014年的材料，包括怎么监控可视化，怎么做相关的工作，把整个数据处理的各个层级打散，每一个层级进行监控，出现问题的时候就得倒查，数据库还涉及到回馈，成本极高。怎么做立体化的监控，真正做的话这是多个维度，做数据质量管控是一个大数据的问题，本身就会产生很多的数据。还有一些相关的监控配置表都要设计好，之后形成结论，通过这些表格可以看出每天、每月的数据处理情况。还有做异动的监控，业务人员一拍脑门波动不能超过5%或者不能超过10%，要用数据的方法来判断它的值，这不是拍脑子得出来的，是计算出来的。
半个小时的时间跟大家只能粗略汇报，让大家感受一下我们在数据质量方面做的相关工作，也是特别感谢信通院，提供这个很难得的机会。
