二维码
文章 > 真实数据分析

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

2017-09-13 13:53:13

卷皮网数据仓库负责人,熟悉性能调优、数据建模、数据接入、元数据管理、OLAP


出品|中国统计网(ID:cntongji)

嘉宾|欧阳烈

采访|赵良

审核|赵良

编辑|惊渡



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


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


第一个是数据采集、埋点、规范问题。埋点问题包括埋点的代码被覆盖、错埋、漏埋。这种情况是因为负责埋点一般是业务的同学兼任,大多数公司都不会有专门负责埋点的团队来处理这些问题。在业务规则上线之后,埋点的功能才能开始:开发、测试、回归。在这个过程中,埋点的代码就有可能被覆盖、错埋、漏埋。规范问题的话,我们给业务方制定一些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体系。


谢谢欧阳烈先生给大家精彩的分享。