在业界，大家都为如何做好数据治理而感到困惑。数据治理工作一定要先摸清楚数据的家底，规划好路线图，再进行决策。

本文从数据治理的误区、元数据管理、数据质量管理、数据标准管理等4个方面整理出数据治理的一套经验总结，给予数据治理相关工作的同仁们一些借鉴参考。

01 数据治理有哪些误区？

大数据时代，数据成为社会和组织的宝贵资产，像工业时代的石油和电力一样驱动万物，然而如果石油的杂质太多，电流的电压不稳，数据的价值岂不是大打折扣，甚至根本不可用，不敢用，因此，数据治理是大数据时代我们用好海量数据的必然选择。
但大家都知道，数据治理是一项长期而繁杂的工作，可以说是大数据领域中的脏活累活，很多时候数据治理厂商做了很多工作，但客户却认为没有看到什么成果。大部分数据治理咨询项目都能交上一份让客户足够满意的答卷，但是当把咨询成果落地到实处的时候，因为种种原因，很可能是另一番截然不同的风景。如何避免这种情况发生，是每一个做数据治理的企业都值得深思的问题。

可以说在业界，大家都为如何做好数据治理而感到困惑。

笔者涉猎大数据治理领域有6年多的时间，负责过政府、军工、航空、大中型制造企业的数据治理项目。在实践当中有过成功的经验，当然也经历过很多失败的教训，在这些过程中，笔者一直在思考大数据治理究竟是在治理什么？要达到什么样的合理目标？中间应该怎么避免走一些弯路？下面是笔者曾经趟过的坑，希望对大家有一些借鉴意义。

误区一：客户需求不明确

客户既然请厂商来帮助自己做数据治理，必定是看到了自己的数据存在种种问题。但是做什么，怎么做，做多大的范围，先做什么后做什么，达到什么样的目标，业务部门、技术部门、厂商之间如何配合做……很多客户其实并没有想清楚自已真正想解决的问题。数据治理，难在找到一个切入点。

以笔者的经验来看，如果客户暂时想不清楚需求，建议先请厂商帮助自己做一个小型的咨询项目，通过专业的团队，大家一起找到切入点。这个咨询项目工作的重点应该是数据现状的调研。通过调研数据架构、现有的数据标准和执行情况，数据质量的现状和痛点，客户目前已经具有的数据治理能力现状等，来摸清楚数据的家底。

在摸清家底的基础上，由专业的数据治理团队帮助客户设计切实可行的数据治理路线图，双方取得一致的基础上，按照路线图来执行数据治理工作。

其实客户很多时候并不是没需求，只是需求相对比较笼统，模糊不清晰，双方可以花费一定的时间和精力找到真正目标，磨刀不误砍柴工，这样才不致于后续花更多的钱来交学费。

总结：数据治理工作，一定要先摸清楚数据的家底，规划好路线图，切忌一上来就搭平台。

误区二：数据治理是技术部门的事

在大数据时代，很多组织认识到了数据的价值，也成立了专门的团队来负责管理数据，有的叫数据管理处，有的叫大数据中心，有的叫数据应用处，名称不一而足。这些机构往往由技术人员组成，本身的定位也属于技术部门，它们的共同点是：强技术，弱业务。当数据治理项目需要实施的时候，往往就是由这些技术部门来牵头。技术部门大多是以数据中心或者大数据平台为出发点，受限于组织范围，不希望扩大到业务系统，只希望把自已负责的范围管好。

但数据问题产生的原因，往往是业务>技术。可以说大部分的数据质量问题，都是来自于业务，如：数据来源渠道多，责任不明确，导致同一份数据在不同的信息系统有不同的表述；业务需求不清晰，数据填报不规范或缺失，等等。很多表面上的技术问题，如ETL过程中某代号变更导致数据加工出错，影响报表中的数据正确性等，在本质上其实还是业务管理的不规范。

笔者在与很多客户做数据治理交流的时候，发现大部分客户认识不到数据质量问题发生的根本原因，只想从技术维度单方面来解决数据问题，这样的思维方式导致客户在规划数据治理的时候，根本没有考虑到建立一个涵盖技术组、业务组的强有力的组织架构，能有效执行的制度流程，导致效果大打折扣。

总结：数据治理既是技术部门的事，更是业务部门的事，一定要建立多方共同参与的组织架构和制度流程，数据治理的工作才能真正落实到人，不至于浮在表面。

误区三：大而全的数据治理

出于投资回报的考虑，客户往往倾向于做一个覆盖全业务和技术域的，大而全的数据治理项目。从数据的产生，到数据的加工，应用，销毁，数据的整个生命周期他们希望都能管到。从业务系统，到数据中心，到数据应用，里面的每个数据他们希望都能被纳入到数据治理的范围中来。

但殊不知广义上的是一个很大的概念，包括很多内容，想在一个项目里就做完通常是不可能的，而是需要分期分批地实施，所以厂商如果屈从于客户的这种想法，很容易导致最后哪个也做不好，用不起来。所以，我们需要引导客户，从最核心的系统，最重要的数据开始做数据治理。

怎么引导客户呢？这里要引入一个众所周知的概念：二八原则。实际上，二八原则在数据治理中同样适用：80%的数据业务，其实是靠20%的数据在支撑；同样的，80%的数据质量问题，其实是由那20%的系统和人产生的。在数据治理的过程中，如果能找出这20%的数据，和这20%的系统和人，毫无疑问，将会起到事半功倍的效果。

但如何说服客户，从最重要的数据开始做起呢？这就是我们在误区一中谈到的：在没有摸清楚数据的家底之前，切忌贸然动手开始做。通过调研，分析，找出那20%的数据和20%的系统和人，提供真实可靠的分析报告，才有可能打动客户，让客户接受先从核心系统，核心数据开始做起，再渐渐覆盖到其他领域。

总结：做数据治理，不要贪大求全，而要从核心系统，重要的数据开始做起。

误区四：工具是万能的

很多客户都认为，数据治理就是花一些钱，买一些工具，认为工具就是一个过滤器，过滤器做好了，数据从中间一过，就没问题了。结果是：一方面功能越做越多，另一方面实际上线后，功能复杂，用户不愿意用。

其实上面的想法是一种简单化的思维，数据治理本身包含很多的内容，组织架构、制度流程、成熟工具、现场实施和运维，这四项缺一不可，工具只是其中一部分内容。大家在做数据治理最容易忽视的就是组织架构和人员配置，但实际上所有的活动流程、制度规范都需要人来执行、落实和推动，没有对人员的安排，后续工作很难得到保障。

一方面治理推广工作没人做，流程能否坚持执行得不到保障。另一方面没有相关的数据治理培训，导致大家对数据治理的工作不重视，认为与我无关，从而导致整个数据治理项目注定会失败。建议大家在做数据治理的时候将组织架构放在第一位，有组织的存在，就会有人去思考这方面的工作，怎么去推动，持续把事情做好，以人为中心的数据治理工作，才更容易推广落地。

有一位国外的数据治理专家说得好，Data Governance is governance of people; Data behaves what people behave。翻译过来就是：数据治理是对人的行为的治理。对于组织而言，无论是企业还是政府，数据治理实质上是一项覆盖全员的、有关数据的“变革管理”，会涉及到组织架构，管理流程的变革。

当然，这是一种理想的状态。话说回来，我们看看国内的情况，在金融业和一些大的企业，可能会建立专门的组织来负责数据治理工作，但是某些政府和中小型企业，他们出于成本的考虑，往往没有这方面的预算。这种时候就需要折衷考虑，让已有岗位上的人，兼职负责数据治理的某个流程或功能。这样会加大现有岗位人员的工作负担，但是不失为一种折衷的方式，重点是要责任到人。

现场的实施和运维也非常重要，尽管数据治理有向自动化的方向发展的趋势，但是到目前为止，数据治理更多还是一种服务工作，而不仅仅是一套产品。因此，配置足够强的实施顾问和实施人员，帮助客户逐步打造自身的数据治理能力，是一项非常重要的工作。

总结：记住，做数据治理不是去逛逛shopping mall，选几样称心应手的工具回来就万事大吉了。开展好数据治理不能迷信工具，组织架构、制度流程、现场的实施和运维也非常重要，缺一不可。

误区五：数据标准难落地

很多客户一说到数据治理，马上就说我们有很多数据标准，但是这些标准却统统没有落地，因此，我们要先做数据标准的落地。数据标准真正落地了，数据质量自然就好了。

但这种说法其实混淆了数据标准和数据标准化。首先要明白一个道理：数据标准是一定要做的，但是数据标准化，也就是数据标准的落地，则需要分情况实施。

要做数据标准，我们首先需要全面梳理数据标准。而数据标准的全面梳理，范围很大，包括国家标准，行业标准，组织内部的标准等等，需要花费很大的精力，甚至都可以单独立一个项目来做。所以，首先需要让客户看到梳理数据标准的广度和难度。

其次，就算是花很大精力梳理，也很难看到效果，结果往往是客户只看到了一堆Word和Excel文档，时间一长，谁也不会再去关心这些陈旧的文档。这是最普遍的问题。

在金融业，或者像国家安全等一些特殊行业，数据标准的执行力度较好，而在普通企业，数据标准基本上就是一种摆设。

造成这种问题的原因有两个：

一是大家对数据标准工作的不重视。

二是国内的企业做数据标准，动机往往不是为了做好数据治理，而是应付上级检查，很多都是请咨询公司，借鉴同行业企业的标准本地化修改而成，一旦咨询公司撤离，企业本身是没有数据标准落地的能力的。

但数据标准的落地，也就是数据标准化，其实一定要注意分情况进行，至少要分两种情形：

一类是已经上线运行的系统，对于这部分信息系统，由于历史原因，很难进行数据标准的落地。因为改造已有系统，除了成本以外，往往还会带来不可知的巨大风险。

第二类是对于新上线的系统，是完全可以要求其数据项严格按照数据标准落地的。

当然，数据标准是否能顺利落地，还与负责数据治理的部门所获得的权限直接相关，倘若没有领导的授权和强力支持，你是无论如何无法推动“书同文车同轨”的，要做到这一点，请先确认你背后站着说一不二的秦始皇，或者你本身就是秦始皇。别抱怨，这就是每个做数据治理的团队面临的现状。

总结：数据标准落地难是数据治理中的普遍性问题，实施过程中需要区要分遗留系统和新建系统，分别来执行不同的落地策略。

误区六：数据质量问题找出来了，然后呢？

辛辛苦苦建立起来平台，业务和技术人员通力合作，配置好了数据质量的检核规则，也找出来了一大堆的数据质量问题，然后呢？半年之后，一年之后，同样的数据质量问题依旧存在。

发生这种问题的根源在于没有形成数据质量问责的闭环。要做到数据质量问题的问责，首先需要做到数据质量问题的定责。定责的基本原则是：谁生产，谁负责。数据是从谁那里出来的，谁负责处理数据质量问题。

这种闭环不一定非要走线上流程，但是一定要做到每一个问题都有人负责，每一个问题都必须反馈处理方案，处理的效果最好是能够形成绩效评估，如通过排名的方式，来督促各责任人和责任部门处理数据质量问题。

这其实还是要追溯到我们在误区二里谈到的：要建立组织架构和制度流程，否则数据治理工作中的种种事情，没有人负责，没有人去做。

总结：数据质量问题的解决，要形成每一个环节都有确定责任人的闭环机制和反馈机制。

误区七：你们好像什么也没做？

很多数据治理的项目难验收，客户往往有疑问：你们做数据治理究竟干了些啥？看你们汇报说干了一大堆事情，我们怎么什么都看不到？发生这种情况，原因往往有前面误区一所说的客户需求不明确，误区三所说的做了大而全的数据治理而难以收尾等，但还有一个原因不容忽视，那就是没有让客户感知到数据治理的成果。用户缺乏对数据治理成果的感知，导致数据治理缺乏存在感，特别是用户方的领导决策层，自然不会痛快地对项目进行验收。

遇到这种情况，一句“宝宝心里苦，但宝宝不说”是无济于事的。一个项目从销售、售前、到组织团队实施，多少人付出了辛勤的汗水。重要的是让客户认识到项目的重要价值，最终为所有人的付出买单啊。

在我看来，在数据治理的项目需求阶段，就应该坚持业务价值导向，把数据治理的目的定位在有效地对数据资产进行管理，确保其准确、可信、可感知、可理解、易获取，为大数据应用和领导决策提供数据支撑。并且在这个过程中，一定要重视并设计数据治理的可视化呈现效果，诸如：

管理了多少元数据，是否应该用数据资产地图漂亮地展示出来。

管理了多少数据资产，哪些来源，哪些主题，来自于什么数据源，是否应该用数据资产门户的方式展示出来。

数据资产用什么方式对上层应用提供服务，这些对外服务是如何管控的，谁使用了数据，用了多少数据，是否应该用图形化的方式进行统计和展现。

建立了多少条清洗数据的规则，清洗了多少类数据，是否应该用图表展示出来。

发现了多少条问题数据，处理了多少条问题数据，是否应该有一个不断更新的统计数字来表示。

数据质量问题逐月减少的趋势，是否应该用趋势图展现出来。

数据质量问题根据部门、系统的排名，是否应该加在数据质量报告中，提供给决策层，帮助客户进行绩效考核。

数据分析、报表等应用，因为数据问题而必须回溯来源和加工过程的次数，是否应该统计逐月下降的趋势；之前的回溯方式，和现在通过血缘管理更清楚地定位问题数据产生的环节，这两者之间进行对比，节省了客户多少时间和精力，是否应该有一个公平的评估，并提交给客户。

用户之前找数据平均使用的时间，现在找数据平均需要的时间，是否能通过访谈的方式得到公平的结论，提交给客户。

……

以上这些都是提升数据治理存在感的手段。除了这些之外，时常组织交流和培训，引导客户认识到数据治理的重要性，让客户真正认识到数据治理工作对他们业务的促进作用，逐步转移数据治理的能力给客户等，这些都是平时需要注意的工作。

总结：传统的数据治理工作不重视效果的呈现，我们做数据治理工作，一定要从需求开始，就想办法让客户直观地看到成果。

在激烈的市场竞争下，大数据厂商提出来数据治理的各种理念，有的提出覆盖数据全生命周期的数据治理，有的提出以用户为中心的自服务化数据治理，有的提出减少人工干预、节省成本的基于人工智能的自动化数据治理，在面对这些概念的时候，我们一方面要对数据现状有清晰的认识，对数据治理的目标有明确的诉求，另一方面还要知道数据治理中各种常见的误区，跨越这些陷阱，才能把数据治理工作真正落到实处，项目取得成效，做到数据更准确，数据更好取，数据更好用，真正地用数据提升业务水平。

02 数据治理之元数据管理

从关于元数据的三个概念谈起，讲到元数据的分布范围和如何获取元数据，最后从几个常见的应用出发，谈谈元数据的一些实际应用场景。

一、元数据到底是个啥？

元数据是一个相当抽象、不易理解的概念，所以第一个章节，我们先把元数据是什么搞懂。这一章节共提出三个概念。

1、元数据（Meta Data）是描述数据的数据。

这是元数据的标准定义，但这么说有些抽象，技术同学能听懂，倘若听众缺乏相应的技术背景，可能当场就懵逼了。产生这个问题的根源其实是一个知识的诅咒：我们知道某件事情，向不了解的人描述时却很难讲清楚。

要破解这个诅咒，我们不妨借用一个比喻来描述元数据：元数据是数据的户口本。让我们想想一个人的户口本是什么，是这个人的信息登记册：上面有这个人的姓名，年龄，性别、身份证号码，住址、原籍、何时从何地迁入等等，除了这些基本的描述信息之外，还有这个人和家人的血缘关系，比如说父子，兄妹等等。所有的这些信息加起来，构成对这个人的全面描述。那么所有的这些信息，我们都可以称之为这个人的元数据。

同样的，如果我们要描述清楚一个实际的数据，以某张表为例，我们需要知道表名、表别名、表的所有者、数据存储的物理位置、主键、索引、表中有哪些字段、这张表与其他表之间的关系等等。所有的这些信息加起来，就是这张表的元数据。

这么一类比，我们对元数据的概念可能就清楚很多了：元数据是数据的户口本。
2、元数据管理，是数据治理的核心和基础。

为什么我们说元数据管理是数据治理的核心和基础？为什么在做数据治理的时候要先做元数据管理？它的地位为何如此特殊？

让我们想象一下，一位将军要去打仗，他必不可少，必须要掌握的信息是什么？对，是战场的地图。很难相信手里没有军事地图的一位将军能打胜仗。而元数据就相当于是所有数据的一张地图。

在这张关于数据的地图中，我们可以知道：

我们有哪些数据？

数据分布在哪里？

这些数据分别是什么类型？

数据之间有什么关系？

哪些数据经常被引用？哪些数据无人光顾？

……

所有的这些信息，都可以从元数据中找到。如果我们要做数据治理，但是手里却没有掌握这张地图，做数据治理就犹如是瞎子摸象。后续的文章中我们要讲到的数据资产管理，知识图谱，其实它们大部分也是建立在元数据之上的。所以我们说：元数据是一个组织内的数据地图，它是数据治理的核心和基础。
3、元数据是描述数据的数据，那么有没有描述元数据的数据？

有。描述元数据的数据叫元模型(Meta Model)。元模型、元数据、数据之间的关系，可以用下面这张图来描述。

对于元模型的概念，我们不做深入的讨论。我们只需要知道下面这些：

元数据本身的数据结构也是需要被定义和规范的，定义和规范元数据的就是元模型，国际上元模型的标准是CWM(Common Warehouse Metamodel，公共仓库元模型)，一个成熟的元数据管理工具，需要支持CWM标准。

二、元数据是从哪里来的？

在大数据平台中，元数据贯穿大数据平台数据流动的全过程，主要包括数据源元数据、数据加工处理过程元数据、数据主题库专题库元数据、服务层元数据、应用层元数据等。下图以一个数据中心为例，展示了元数据的分布范围：

业内通常把元数据分为以下类型：

技术元数据：库表结构、字段约束、数据模型、ETL程序、SQL程序等。

业务元数据：业务指标、业务代码、业务术语等。

管理元数据：数据所有者、数据质量定责、数据安全等级等。

元数据采集是指获取数据生命周期中的元数据，对元数据进行组织，然后将元数据写入数据库中的过程。

要获取到元数据，需要采取多种方式，在采集方式上，使用包括数据库直连、接口、日志文件等技术手段，对结构化数据的数据字典、非结构化数据的元数据信息、业务指标、代码、数据加工过程等元数据信息进行自动化和手动采集。

元数据采集完成后，被组织成符合CWM模型的结构，存储在关系型数据库中。

三、有了元数据，我们能做些什么？

这一章节我们主要讲元数据的几个典型的应用。

先看一张元数据管理的整体功能架构图，有了元数据，我们能做些什么，从这张图里一目了然：

1.元数据查看

一般是以树形结构组织元数据，按不同类型对元数据进行浏览和检索。如我们可以浏览表的结构、字段信息、数据模型、指标信息等。通过合理的权限分配，元数据查看可以大大提升信息在组织内的共享。

2.数据血缘和影响性分析

数据血缘和影响性分析主要解决“数据之间有什么关系”的问题。因其重要价值，有的厂商会从元数据管理中单独提取出来，作为一个独立的重要功能。但是笔者考虑到数据血缘和影响性分析其实是来自于元数据信息，所以还是放在元数据管理中来描述。

血缘分析指的是取到数据的血缘关系，以历史事实的方式记录数据的来源，处理过程等。

以某张表的血缘关系为例，血缘分析展示如下信息：

数据血缘分析对于用户具有重要的价值，如：当在数据分析中发现问题数据的时候，可以依赖血缘关系，追根溯源，快速地定位到问题数据的来源和加工流程，减少分析的时间和难度。

数据血缘分析的典型应用场景：某业务人员发现“月度营销分析”报表数据存在质量问题，于是向IT部门提出异议，技术人员通过元数据血缘分析发现“月度营销分析”报表受到上游FDM层四张不同的数据表的影响，从而快速定位问题的源头，低成本地解决问题。

除了血缘分析之外，还有一种影响性分析，它能分析出数据的下游流向。当系统进行升级改造的时候，如果修改了数据结构、ETL程序等元数据信息，依赖数据的影响性分析，可以快速定位出元数据修改会影响到哪些下游系统，从而减少系统升级改造带来的风险。从上面的描述可以知道：数据影响性分析和血缘分析正好相反，血缘分析指向数据的上游来源，影响性分析指向数据的下游。

影响性分析的典型应用场景：某机构因业务系统升级，在“FINAL_ZENT ”表中修改了字段：TRADE_ACCORD长度由8修改为64，需要分析本次升级对后续相关系统的影响。对元数据“FINAL_ZENT”进行影响性分析，发现对下游DW层相关的表和ETL程序都有影响，IT部门定位到影响之后，及时修改下游的相应程序和表结构，避免了问题的发生。由此可见，数据的影响性分析有利于快速锁定元数据变更带来的影响，将可能发生的问题提前消灭在萌芽之中。
3.数据冷热度分析
冷热度分析主要是对数据表的被使用情况进行统计，如：表与ETL程序、表与分析应用、表与其他表的关系情况等，从访问频次和业务需求角度出发，进行数据冷热度分析，用图表的方式，展现表的重要性指数。

数据的冷热度分析对于用户有巨大的价值，典型应用场景：我们观察到某些数据资源处于长期闲置，没有被任何应用调用，也没有别的程序去使用的状态，这时候，用户就可以参考数据的冷热度报告，结合人工分析，对冷热度不同的数据做分层存储，以更好地利用HDFS资源，或者评估是否对失去价值的这部分数据做下线处理，以节省数据存储空间。
4.数据资产地图

通过对元数据的加工，可以形成数据资产地图等应用。数据资产地图一般用于在宏观层面组织信息，以全局视角对信息进行归并、整理，展现数据量、数据变化情况、数据存储情况、整体数据质量等信息，为数据管理部门和决策者提供参考。

5.元数据管理的其他应用

元数据管理中还有其他一些重要功能，如：

元数据变更管理。对元数据的变更历史进行查询，对变更前后的版本进行比对等等。

元数据对比分析。对相似的元数据进行比对。

元数据统计分析。用于统计各类元数据的数量，如各类数据的种类，数量等，方便用户掌握元数据的汇总信息。

诸如此类的应用，限于篇幅，不一一列举。

四、总结

元数据就相当于是数据的户口本和地图，是数据治理的核心和基础。

元数据产生于从数据生产、数据接入、数据加工、数据服务到数据应用的各个环节，整体上可以分为三类：技术元数据、业务元数据和管理元数据。

元数据采集入库后，可以产生冷热度分析、血缘关系分析、影响性分析，数据资产地图等应用。元数据管理可以让数据被描述得更加清晰，更容易被理解，被追溯，更容易评估其价值和影响力。元数据管理还可以大大促进信息在组织内外的共享。

03 数据治理之数据质量管理

数据治理的理论和实践不断向前发展，但数据质量管理始终是数据治理的初衷，也是最重要的目的。下面从数据质量管理的目标，质量问题产生的根源，质量评估标准，质量管理流程，质量管理的取与舍几个方面进行阐述。

一、数据质量管理的目标

数据质量管理主要解决“数据质量现状如何，谁来改进，如何提高，怎样考核”的问题。

最开始的关系型数据库时代，做数据治理最主要的目的，就是为了提升数据质量，让报表、分析、应用更加准确。时至今日，虽然数据治理的范畴扩大了很多，我们开始讲数据资产管理、知识图谱、自动化的数据治理等等概念，但是提升数据的质量，依然是数据治理最重要的目标之一。
为什么数据质量问题如此重要？

因为数据要能发挥其价值，关键在于其数据的质量的高低，高质量的数据是一切数据应用的基础。

如果一个组织根据劣质的数据分析业务、进行决策，那还不如没有数据，因为通过错误的数据分析出的结果往往会带来“精确的误导”，对于任何组织来说，这种“精确误导”都无异于一场灾难。

根据统计，数据科学家和数据分析员每天有30%的时间浪费在了辨别数据是否是“坏数据”上，在数据质量不高的环境下，做数据分析可谓是战战兢兢。可见数据质量问题已经严重影响了组织业务的正常运营。通过科学的数据质量管理，持续地提升数据质量，已经成为组织内刻不容缓的优先任务。

二、数据质量问题产生的根源

做数据质量管理，首先要搞清楚数据质量问题产生的原因。原因有多方面，比如在技术、管理、流程方面都会碰到。但从根本上来时，数据质量问题产生的大部分原因在于业务上，也就是管理不善。许多表面上的技术问题，深究下去，其实还是业务问题。

笔者在给客户做数据治理咨询的时候，发现很多客户认识不到数据质量问题产生的根本原因，局限于只想从技术角度来解决问题，希望通过购买某个工具就能解决质量问题，这当然达不到理想的效果。经过和客户交流以及双方共同分析之后，大部分组织都能认识到数据质量问题产生的真正根源，从而开始从业务着手解决数据质量问题了。

从业务角度着手解决数据质量问题，重要的是建立一套科学、可行的数据质量评估标准和管理流程。

三、数据质量评估的标准

当我们谈到数据质量管理的时候，我们必须要有一个数据质量评估的标准，有了这个标准，我们才能知道如何评估数据的质量，才能把数据质量量化，并知道改进的方向，比较改进后的效果。

目前业内认可的数据质量的标准有：

“
准确性: 描述数据是否与其对应的客观实体的特征相一致。

完整性: 描述数据是否存在缺失记录或缺失字段。

一致性: 描述同一实体的同一属性的值在不同的系统是否一致。

有效性: 描述数据是否满足用户定义的条件或在一定的域值范围内。

唯一性: 描述数据是否存在重复记录。

及时性: 描述数据的产生和供应是否及时。

稳定性: 描述数据的波动是否是稳定的，是否在其有效范围内。

以上数据质量标准只是一些通用的规则，这些标准是可以根据数据的实际情况和业务要求进行扩展的，如交叉表校验等。

四、数据质量管理的流程

要提升数据质量，需要以问题数据为切入点，注重问题的分析、解决、跟踪、持续优化、知识积累，形成数据质量持续提升的闭环。
首先需要梳理和分析数据质量问题，摸清楚数据质量的现状；然后针对不同的质量问题选择适合的解决办法，制定出详细的解决方案；接着是问题的认责，追踪方案执行的效果，监督检查，持续优化；最后形成数据质量问题解决的知识库，以供后来者参考。上述步骤不断迭代，形成数据质量管理的闭环。

很显然，要管理好数据质量，仅有工具支撑是远远不够的，必须要组织架构、制度流程参与进来，做到数据的认责，数据的追责。

五、数据质量管理的取与舍

企业也好，政府也好，从来不是生活在真空之中，而是被社会紧紧地包裹。解决任何棘手的问题，都必须考虑到社会因素的影响，做适当的取舍。

第一个取舍：数据质量管理流程。前面讲到的数据质量管理流程，是一个相对理想的状态，但是不同的组织内部，其实施的力度都是不同的，以数据追责为例：在企业内部推行还具有一定的可行性，但是在政府就很难适用。因为政府部门的大数据项目，牵头单位无论是谁，很可能没有相关的权限。

遇到这种问题，我们只能迂回地做些事情，尽量弥补某个环节缺失带来的不利影响，比如和数据提供方一起建立起数据清洗的规则，对来源数据做清洗，尽量达到可用的标准。

第二个取舍：不同时间维度上的数据采取不同的处理方式。从时间维度上划分，数据主要有三类：未来数据、当前数据、历史数据。在解决不同种类的数据质量问题时，需要考虑取舍之道，采取不同的处理方式。

1.历史数据

当你拿着一堆历史问题数据，找信息系统的负责人给你整改，对方通常不会给你好脸色看，可能会以“当前的数据问题都处理不过来，哪有时间给你处理历史数据的问题”为理由，拒你以千里之外。这时候你即便是找领导协调，一般也起不到太大的作用，因为这确实是现实情况：一个组织的历史数据通常是经年累月的积累，已经是海量的规模，很难一一处理。

那么难道就没有更好的办法了吗？——对于历史数据问题的处理，我们可以发挥技术人员的优势，用数据清洗的办法来解决，对于实在清洗不了的，我们要让决策者判断投入和产出的效益比，结果往往是需要接受这种现状。

从另一个角度来看：数据的新鲜度不同，其价值往往也有所区分。一般来说，历史数据的时间越久远，其价值越低。所以，我们不应该把最重要的资源放在历史数据质量的提升上，而是应该更多地着眼于当前产生和未来即将产生的数据。

2.当前数据

当前数据的问题，需要从我们通过前面第四个章节讲过的梳理和发现问题，分析问题，解决问题，问题认责、跟踪和评估等几个流程环节来解决，管理过程中必须严格遵循流程，避免脏数据继续流到数据分析和应用环节。

3.未来数据

管理未来的数据，一定要从数据规划开始，从整个组织信息化的角度出发，规划组织统一的数据架构，制定出统一的数据标准。借业务系统新建、改造或重建的时机，在创建物理模型、建表、ETL开发、数据服务、数据使用等各个环节遵循统一的数据标准，从根本上提升数据质量。这也是最理想、效果最好的数据质量管理模式。

这样，通过对不同时期数据的不同处理方式，能做到事前预防、事中监控、事后改善，从根本上解决数据质量问题。

总结
提升数据质量，是数据治理最重要的目标之一。做数据质量管理，首先要弄清楚数据质量问题产生的根源大部分在于业务管理出了问题。

其次，我们要根据组织架构，建立一套数据质量评估的标准和数据质量管理的流程。

最后，在做数据质量管理过程中，我们要充分考虑到现状，对历史数据、当前数据、未来数据分别制定不同的处理策略。

04 数据治理之数据标准管理

一、大数据标准体系

根据全国信息技术标准化技术委员会大数据标准工作组制定的大数据标准体系，大数据的标准体系框架共由七个类别的标准组成，分别为：基础标准、数据标准、技术标准、平台和工具标准、管理标准、安全和隐私标准、行业应用标准。本文主要阐述其中的第二个类别：数据标准。

二、关于数据标准认识的几个误区

数据标准这个词，最早是在金融行业，特别是银行业的数据治理中开始使用的。数据标准工作一直是数据治理中的基础性重要内容。但是对于数据标准，不同的人却有不同的看法：

有人认为数据标准极其重要，只要制定好了数据标准，所有数据相关的工作依标进行，数据治理大部分目标就水到渠成了。

也有人认为数据标准几乎没什么用，做了大量的梳理，建设了一整套全面的标准，最后还不是被束之高阁，被人遗忘，几乎没有发挥任何作用。

首先亮明作者的观点：这两种看法都是不对的，至少是片面的。实际上，数据标准工作是一项复杂的，涉及面广的，系统性的，长期性的工作。它既不能快速地发挥作用，迅速解决掉数据治理中的大部分问题，同时也肯定不是完全没有作用，最后只剩下一堆文档——如果数据标准工作的结局真是如此，那只能说明这项工作没有做好，没有落到实处。本文主要的目的，就是分析为什么会出现这种情况，以及如何应对。而首先需要做的是厘清数据标准的定义。

三、数据标准的定义

何为数据标准，各相关组织并没有统一的，各方都认可的定义。结合各家对数据标准的阐述，从数据治理的角度出发，我尝试着给数据标准做一个定义：数据标准是对数据的表达、格式及定义的一致约定，包含数据业务属性、技术属性和管理属性的统一定义；数据标准的目的，是为了使组织内外部使用和交换的数据是一致的，准确的。

四、如何制定数据标准

一般来说，对于政府，会有国家或地方政府发文的数据标准管理办法，其中会详细规定相关的数据标准。所以在此主要讲企业如何制定数据标准。

企业的数据标准来源非常丰富，有外部的监管要求，行业的通用标准，同时也必须考虑到企业内部数据的实际情况，梳理其中的业务指标、数据项、代码等，将以上的所有的来源都纳入数据标准是没有必要的，数据标准的范围应该主要集中在企业业务最核心的数据部分，有的企业也称作关键业务数据或核心数据，只要制定出这些核心数据的标准，就能够支撑企业数据质量、主数据管理、数据分析等需要。

五、数据标准化的难题

数据标准好制定，但是数据标准落地相对就困难多了。国内的数据标准化工作发展了那么多年，各个行业，各个组织都在建设自己的数据标准，但是你很少听到哪个组织大张旗鼓地宣传自己的数据标准工作多么出色，换句话说，做数据标准取得显著效果的案例并不多。为什么会出现这种情况，主要有两个原因：

一是制定的数据标准本身有问题。有些标准一味地追求先进，向行业领先看齐，标准大而全，脱离实际的数据情况，导致很难落地。

第二个原因，是标准化推进过程中出了问题。这是我们重点阐述的原因，主要有以下几种情况：

对建设数据标准的目的不明确。某些组织建设数据标准，其目的不是为了指导信息系统建设，提高数据质量，更容易地处理和交换数据，而是应付监管机构检查，因此需要的就是一堆标准文件和制度文件，根本就没有执行的计划。

过分依赖咨询公司。一些组织没有建设数据标准的能力，因此请咨询公司来帮忙规划和执行。一旦咨询公司撤离，组织依然缺乏将这些标准落地的能力和条件。

对数据标准化的难度估计不足。很多公司上来就说要做数据标准，却不知道数据标准的范围很大，很难以一个项目的方式都做完，而是一个持续化推进的长期过程，结果是客户越做遇到的阻力越大，困难越多，最后自己都没有信心了，转而把前期梳理的一堆成果束之高阁，这是最普遍的问题。

缺乏落地的制度和流程规划。数据标准的落地，需要多个系统、部门的配合才能完成。如果只梳理出数据标准，但是没有规划如何落地的具体方案，缺乏技术、业务部门、系统开发商的支持，尤其是缺乏领导层的支持，是无论如何也不可能落地的。

组织管理水平的不足：数据标准落地的长期性、复杂性、系统性的特点，决定了推动落地的组织机构的管理能力必须保持在很高的水平线上，且架构必须持续稳定，才能有序地不断推进。以上这些原因，导致数据标准化工作很难开展，更难取得较好的成效。数据标准化难落地，是数据治理行业的现状，不容回避。

六、如何应对这些难题

应对以上这些难题，最经济、最理想的模式当然是：做大数据建设，首先做标准，再做大数据平台，数据仓库等。但一般的不大可能有这样的认识，很多时候大家都是先建设再治理。先把信息系统、数据中心建好，然后标准有问题，质量不高，再建数据标准，但实际上这时候已经是回过头来做一些亡羊补牢的事情，客户的投资肯定有一部分是浪费。

正因为其太过理想化，所以这种模式几乎是见不到的。在实践中，我们往往还是需要更多地考虑如何把数据标准落地到已有的系统和大数据平台中。

数据标准落地有三种形式：

源系统改造：对源系统的改造是数据标准落地最直接的方式，有助于控制未来数据的质量，但工作量与难度都较高，现实中往往不会选择这种方式，例如有客户编号这个字段，涉及多个系统，范围广、重要程度高、影响大，一旦修改该字段，会涉及到相关的系统都需要修改。但是也不是完全不可行，可以借系统改造，重新上线的机会，对相关源系统的数据进行部分的对标落地。

数据中心落地：根据数据标准要求建设数据中心（或数据仓库），源系统数据与数据中心做好映射，保证传输到数据中心的数据为标准化后的数据。这种方式的可行性较高，是绝大多数组织的选择。

数据接口标准化：对已有的系统间的数据传输接口进行改造，让数据在系统间进行传输的时候，全部遵循数据标准。这也是一种可行的方法。

在数据标准落地的过程中，需要做好6件事情，如下图所示：

事先确定好落地的范围：哪些数据标准需要落地，涉及到哪些IT系统，都是需要事先考虑好的。

事先做好差异分析：现有的数据和数据标准之间，究竟存在哪些差异，这些差异有多大，做好差异性分析。

事先做好影响性分析：如果这些数据标准落地了，会对哪些相关下游戏厅产生什么样的影响，这些影响是否可控。元数据管理中的影响性分析可以帮助用户确定影响的范围。

制定落地的执行方案：执行方案要侧重于可落地性。不能落地的方案，最终只能被废弃。一个可落地的方案，要有组织架构和人员分工，每个人负责什么，如何考核，怎么监管，都是必须纳入执行方案中的内容。

具体地执行落地方案：根据执行方案，进行数据标准落地执行。

事后评估：事后需要跟踪、评估数据落地的效果如何，做对了哪些事，哪些做得不足，如何改进。

七、总结

数据标准的建设大致可以分成两个阶段：

1、梳理和制定数据标准。

2、数据标准的落地和实施。

其中后者是公认的难题。本文分析了其中的原因，提供了一些如何让数据标准更快更好落地的方法。