齐乐娱乐

数匠专访|第8期 欧阳烈:如何做好元数据质量管理?

${website.getHeaderOriginal(${article.taxonomyName})}



出品|中国统计网(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体系··|--。


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




数匠往期专访回顾


LoveData大数据100+系列访谈第001期——

LoveData大数据100+系列访谈第002期——

LoveData大数据100+系列访谈第003期——

LoveData大数据100+系列访谈第004期——

LoveData大数据100+系列访谈第005期——

LoveData大数据100+系列访谈第006期——

LoveData大数据100+系列访谈第007——

${website.getFooterOriginal(${article.taxonomyName})}

发布者 :齐乐娱乐_齐乐娱乐qile518_齐乐娱乐最新网址 - 分类 齐乐娱乐最新网址