数据治理实操

|0x00 数据治理的思路

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

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

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

因此，我们有三种解决问题的思路：

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

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

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

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

|0x01 数据质量的治理

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

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

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

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

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

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

|0x02 数据资产的治理

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

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

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

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

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

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

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

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

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

|0xFF 治理工具的选择

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

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

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

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

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

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