博客 浅谈数据治理

浅谈数据治理

   小美   发表于 2021-12-22 16:51  511  0

来源:数据仓库与Python大数据

|0x00 数据治理的格局

数据治理是互联网公司中,普遍遇到的痛点,不论是作为业务支持的“数据仓库”部门,还是承担辅助角色的“数据分析”部门,天天被人追着问:“我们有什么数据?这数据对吗?为什么还没跑出来?你到底能不能做?”

当矛盾对喷到“忍无可忍”时,数据治理工程便提上了“台面”,因为开发没了服务对象等于丢了饭碗,而业务脱离数据在互联网时代又等同于“裸奔”,双方打的难解难分。

但其实数据治理是一项比较大的工程,在实际工作中,我们需要缩小范围,“把好钢用在刀刃上”。因此,个人倾向于如下的概念,即:数据治理 = 数据质量治理 + 数据资产治理。所谓的治理,是站在数据从生产到最终消费的全链路视角上,利用平台技术提升所带来的红利,以从研发视角出发所推动的运营工作为锚点,让数据的治理变得“可持续”,并且提升研发同学的“幸福感”。

因此,我们有三种解决问题的思路:

第一种是从全局角度出发,由部门制定相应的规范、标准、执行策略,在日常的研发工作中,将治理的任务放在最高的位置上。这样做虽然会最有成效,但落地成本也会非常大,成果的产出周期也很长。

第二种是现有问题出发,即发现局部的问题,就解决这些问题,有明确的执行方法和结果数据来衡量。

第三种是面向危机改动,当团队业务线非常分散、同时需求压力有很大时,往往难以推动一些内部治理工作的开展,这时候只能遇到问题、再解决问题,用危机来反推工作的落实。

以上三种是面对问题的态度,接下来讨论面对问题的方法,即数据质量与数据资产治理的思路。

|0x01 数据质量的治理

有道是:“数据质量是开发同学的红线,是一定要恪守的原则”。如果交付的数据是存在问题的,那么得出的结论往往也就是错误的。

如果用简洁的语言来概括,那么就是及时、准确与一致

及时性,是数据研发的第一道“红线”。通常情况下,我们会设置相应的基线,由每天值班的研发来观察和保障运行情况,数据任务一旦报错,则通知相应负责人处理,或执行降级运行策略。如果上游数据产出存在问题,也能够收集相应的问题清单,与上游共同解决。这是一条基本的执行策略,通常配置任务和安排值班也不会特别费事,因此也是最容易解决的问题。

准确性,是数据研发的第二道“红线”,大体上可以总结为两个特点,即数据的准确性测试、以及数据的准确性监控。关于数据的准确开发、运维,上一篇文章已经给出来了详细论述,参考:《》。

一致性,是数据研发的第三道“红线”,大致可以理解为,提供给下游使用的数据,要有统一的口径和解释。通常情况下,指标是由分析师定义,但实际开发中,业务、产品、甚至是研发自己,也往往会定义一些指标,往往又会因为数据范围的不同,导致结果不一致。比如剔除某几个商品,就会对整体GMV产生影响。因此,不论谁来定义指标,都要有完整的说明文档,否则就是“不承认”的。其次,数据的结果一定要有验证的过程,不论是分析师还是业务同学,人工的校验是必须要做的事情,至少能够让最熟悉数据的同学来验证数据。

通过上述三个角度,基本能够覆盖90%的问题,剩下的10%通常是需要Case by case来看待和验证的。

|0x02 数据资产的治理

数据资产,通常是指数据的存储和计算资源的管理情况,以及维护现有的数据资产,包括我们有什么数据、有什么指标、能做怎样的事情,避免各团队重复开发的事情出现。

数据的存储和计算资源管理,往往是要与运维团队配合,数据集群会给出一份账单数据,研发团队保障成本是可控的,如果预算超支较多,则需要进行治理。

关于数据存储治理,通常指对数据表进行下线、缩减生命周期等操作。在实际开发过程中,由于长时间的项目积累,我们往往会发现很多不再使用的表仍在在运行,或者是一些不怎么使用的数据,存储的周期非常长,这都是要治理的重点对象。解决的方法也很简单,一是开发前的需求与模型评审,一个是监控数据表或者数据应用的访问情况,对于低频或者无访问的数据,则确认必要性后,进行下线或者缩减生命周期的操作。

关于数据计算治理,则把重心集中在慢SQL的治理上,检查那些消耗资源多、或运行时间长的任务,如果存在数据倾斜则进行优化,如果数据量确实大则考虑极限存储或者进行裁剪,当然最基础的,如对表的暴力扫描这种不合理的临时任务,也是需要及时发现和关闭的。

最后,我们需要整理数据的文档,有能力的团队可以把握文档开发成一个录入和查询的平台工具。这个文档或者工具,要解决诸如我们有什么数据、有什么指标、能做怎样的事情的问题。

文档要有如下的几个基本要素:

其一,要有源系统的模型设计,明确业务过程有哪些、业务发生时的数据流向、数据之间的ER关系等信息;

其二,要有指标字典,指标字典是非常重要的,一定要在需求沟通的过程中沉淀下来,当我们回头去看的时候,大量的时间在沟通指标和维度的定义;

其三,要有开发和需求规范,很多时候我们处于效率的考量,会做很多“私下”的工作,但这些工作往往不在正式的列表中,因此流程上还是要规范一些,不要把有限时间放到无限的沟通中去。

|0xFF 治理工具的选择

这里讨论下我们需要的平台技术应该包括哪些。

其一,任务维护,以DataWorks运维中心为模板构建,包括任务的运行状况维护;

其二,任务调度,类似DolphinScheduler提供的完整能力;

其三,元数据管理,包括表的信息、血缘信息、备注的业务信息等内容;

其四,资产可视,包括表的数量、占用的存储资源、每日任务消耗的计算资源等,为治理提供依据;

其五,学习中心,包括开发的规范、常见优化技巧等方法的集合,提供实操的手册。

免责申明:

本文系转载,版权归原作者所有,如若侵权请联系我们进行删除!

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群