如何做好元数据质量管理？

赵良：一般数据质量出错的环节会有哪些？

欧阳烈：数据质量出现的问题，我在卷皮网的工作经历中大概归纳了一下，有以下几类：

第一个是数据采集、埋点、规范问题。埋点问题包括埋点的代码被覆盖、错埋、漏埋。这种情况是因为负责埋点一般是业务的同学兼任，大多数公司都不会有专门负责埋点的团队来处理这些问题。在业务规则上线之后，埋点的功能才能开始：开发、测试、回归。在这个过程中，埋点的代码就有可能被覆盖、错埋、漏埋。规范问题的话，我们给业务方制定一些URL规范或者其它数据接入规范，但是业务方不能完全遵守，或者是研发人员的离职、交接导致的一些问题；

第二个是数据处理方面的问题，比如说ETL的逻辑写错、异常值的处理写的有问题；

第三个是业务变更的问题，比如维度上枚举值的变更，或者更夸张的情况——业务规则考虑不周，导致数据层无法兼容，或者数据仓库设计上的缺陷导致无法兼容，对后续应用层的影响会比较大。还有一些口径变更类的问题，比如说销售总额的口径变更了，以前是由用户实付金额加上满减金额，变成用户实付金额加上满减金额加上优惠金额，这样的话，从源数据层，到数仓层，到后续应用层修复并刷数的成本比较大，导致一部分数据出现问题。

数据治理的话，大多数公司一般都会经历三个阶段，第一个是根据需求来治理，就是所谓的被动治理，解释来说，业务方反馈出来数据有问题，然后由专门负责数据治理的小伙伴来处理；第二个阶段是建立一些监控体系；在监控体系比较完善以后，会思考怎样把数据治理更为智能化，我们会建立一个指标体系，这就是第三个阶段，用指标体系做数据治理的阶段。

赵良：数据出错最多是哪个环节？

欧阳烈：根据我们的经验，数据出现问题最多还是数据采集阶段，在卷皮网快速发展的阶段，踩了无数的坑，就是我刚刚总结的，有可能埋点代码被覆盖、被错埋、漏埋等情况反复出现。后续我们对埋点做了很多优化，包括建立规范的流程，如果不按流程来会追加一些责任，迫使前端的小伙伴重视这方面。

赵良：一般分几个维度来建立监控体系？

欧阳烈：这里说一下我们经历的数据监控的分类。一是波动范围，看销售额、销量、UV/PV的波动。二是一致性检查，分为多种情况。比如我们的数据在hive,Mysql两个不同的数据库，我们会检查这两个的销售额是否一致、数据层是否一致，比如从线上抽过来的数据我们会放到ODS层，ODS层处理之后我们放到DW层 。那ODS层和DW层也涉及到是否一致，这个统称叫一致性检查；

三是业务逻辑检查。比如看用户是从哪个终端进来的，PC、微信、M站、安卓或者IOS，在业务逻辑上是不会出现第六种情况的，那就需要看例外情况会有多少。如果比例较大，可以判断这个数据质量无法通过。额外补充一点，数据质量检查有级别。有一些作业质量检查比较严重，我们会将其定义为阻断性检查。如果这项作业质量检查失败，则需要停下，由研发或者架构的人来干预这个过程。另外一种就是非阻断性的质量检查，这意味着我们只需要知道这个事情但不需要去干预，可以第二天再去处理。质量检查也分一些时间节点，有些会放在作业执行之后，比如跑一个订单表，跑完之后马上会和DW和ODS做一个一致性的检查。还有的会在数据层做质量检查，比如流量的数据，我们在kafka消费完之后，会检查一下日志的记录条数。还有时间点上的数据质量检查，比如我们会在凌晨7点钟看一下当天的销售额是否波动过大，甚至boss看到后的问责等问题。

赵良：我们进入到了第三个阶段，即数据治理指标性的检查，那这些指标是分别是什么，又说如何呈现的？

欧阳烈：分为三种不同类型，基础指标，衍生指标，复合指标。衍生指标就是在基础指标的基础上加上一些过滤条件，比如用来表示当天的访客数的商详UV，则对应会有一个衍生指标。UV，表示访问过商详页面的访客数。复合指标则由多个基础指标组成，比如实付金额和优惠金额，二者相加等于销售总额，销售总额就是一个复合指标。

赵良：我们回到第一个阶段，可能很多初创型公司会比较关心，在没有成熟的数据处理的情况下，容易引起头痛医头脚痛医脚，在这样的情况下，对于数据需求治理您有什么可以分享的经验吗？

欧阳烈：很多公司都会经过根据需求来进行数据质量治理的阶段，这个阶段越短越好，尽快地跨过第一个阶段，直接进入第二个阶段，尽快搭建起一个监控体系。在初创时期如果人员有限，大家要集中精力做一些更有价值的东西的话，就得保证一个重要指标的监控。比如销售额指标，UV、PV这些基础指标至少没有太大问题。总体来说就是尽快缩短被动治理数据的阶段。

赵良：从数据的准确度来看，数据质量占据很大一部分，相信数据口径也是重要的一部分。您能否谈谈如何统一数据口径，这个过程存在哪些难点？做好数据口径的统一，对企业的意义又在哪里？

欧阳烈：首先谈一下难点。难点主要分为两部分，第一部分是数据口径会跨部门，各个部门都有自己的玩法，并且数据口径对于各个部门的意义也存在差异；第二部分，数据口径变更比较频繁，特别是初创公司或业务正在发展的公司，如果没有建立一个口径变更的规范流程，可能会产生刚开始梳理的口径一致，但后来不一致的情况。而且，这个维护工作也需要大量的人来做。当然有这些难点的话，做好了之后对于企业来说，意义也是比较重大的，口径相当于是各个部门在数据沟通上的一个语言就是基础的语言，如果口径管理的好，大家在各个部门之间的沟通会特别的顺畅。

总结一下：如果口径处理的好，第一，可以减少很多的人力成本，沟通起来会比较顺畅；第二，可以发现新的业务价值；第三，可以减少不必要的一些损失。

赵良：您这边能否简单的给大家介绍一下，治理数据口径一般由谁发起的以及最终验收的环节？

欧阳烈：这里介绍一下我们公司的一些经验吧，我们公司是由BI来负责去做这一整套的数据口径的。开始全都维护一遍，对所有的口径都梳理一遍，后期如果有指标口径的变更，一般是由需求方提出需求，然后我们来评审这个口径变更的需求，评审完如果BI觉得没有问题的话，会发邮件到各个部门的老大，然后抄送给BOSS，给一个时间结点。各个部门的老大如果觉得没有异议的话，再由BI去修改整个数据链路上的口径。当我们建立起了一整套的规范之后，口径管理应该是比较顺畅的。

赵良：您能否从技术的角度谈谈BI这方面是如何操作的呢？

欧阳烈： 这个话题有点大，对我们来说，应该是历经了两年多。首先建立要指标变更体系。第一种，以人工形式进行维护，从流程上我们以指标变更发起方以邮件形式，抄送到各个总监去审批，进一步知会我们的BOSS，再终审批通过的时候我们才会去做指标的新增，或者是指标的变更，由人工去维护。人工维护数仓层还包括应用层的一些指标，比如说我们同时有好几张报表都有销售总额这个指标，那我们会记录报表里面哪一个字段是销售总额。在应用层和数仓层的表不多的时候，我们可以采用这个方案，通过人工的方式去维护指标。当业务发展的越来越多，表也越来越多，不仅是源表层越来越多，数仓层也越来越多，应用层也越来越多，这一套人工维护的东西，可能就成本会越来越高。因为原来的数据不仅在增与改，改的话，后面所有的链路都需要去变更，维护成本会特别大，所以要去做技术元数据。

第二种，简单说就是血缘关系来相互验证解决数据口径问题。各个表里可能都会出现同样的指标，同样的维度，怎么去判断，是通过技术元数据达到的。解析释口，数据处理的过程都是通过释口，或者有些公司可能用的是ETL的工具，比如kettle之类的可以转换成SQL的一个过程。通过解析SQL里的字段是通过哪个字段映射过来的，或者不仅仅是简单的映射，可能做了一些计算，比如乘、除或者通过一个函数转换过来的。这些都可以通过技术手段去把它解析出来的，我们公司现在是这么去实现一个血缘关系的展示。这个血缘关系展示做完之后，还有很好的一点——数据字典就可以自动地去维护起来了。紧接着我们就要去把业务源数据，业务元素是指标口径的一个数列，即公司关心的维度、指标和技术元数据解析的释口的这些内容，可以存在数据库里面去，然后把它打通。

举个简单的例子，比如我们用count distinct 访客ID作为【UV】口径。我们会在数据库里存这么一条信息，函数调用，是count distinct去重，累计，字段为访客ID，它对应的一个指标口径是【UV】。那么在技术元数据里解析到的所有的函数调用，调用的count distinct全部都是UV。区别是有些是衍生指标，有些是复合指标。在做完这些之后，技术源数据和业余元数据就全部打通，建立了自动指标体系。在自动指标体系建立完之后，当有一个指标进行变更时，你可以很快速地查询到这个指标影响到了哪些应用层，影响到了哪些储藏层，要去做哪些改动，都可以一目了然。

赵良：初创企业如果要建一个数据中心，整个数据平台建设从人员的配置、到架构和功能上，您有什么好的建议吗？

欧阳烈：首先说团队的规模，主要是根据大家业务的变更，业务是否太复杂，业务是否进步的太快。数仓和ETL至少需要两到三个人来处理，包括流量还有业务方面的。架构至少需要一个能力特别强的人来带队，辅助一些可能不需要技术太强的但是能干具体实事的人，大概是需要一个四到五人的团队。还需要一个产品的团队，一到两人就可以了，一定要对数据产品比较熟悉。要强调的是数据产品，因为如果不是对数据产品比较熟悉的话，你的BI团队很可能就沦为了一个做报表的团队。就业务方来，我们看什么样的数据，产品的话画原型，出来是一个报表的原型，然后研发的人员去做数据研发，其实就是做一个报表，站在一个数据产品的高度来去建设我们的BI体系。

End.

本文为中国统计网原创文章，需要转载请联系中国统计网（小编微信：ishujiang），转载时请注明作者及出处，并保留本文链接。