数据仓库-数据治理

为什么要做数据治理

数据治理主要解决的问题，用通俗的话讲就是，我们有什么数据，数据对不对，为什么还没有跑出来。

数据治理思路

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

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

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

我理解的数据治理

我理解的数据治理是：数据治理 = 数据质量治理 + 数据资产治理

所谓的治理，是站在数据从生产到最终消费的全链路视角上，利用平台技术提升所带来的红利，以从研发视角出发所推动的运营工作为锚点，让数据的治理变得“可持续”，并且提升研发同学的“幸福感”。

数据质量的治理

总的原则

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

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

及时性

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

存在问题1：数据没有及时产出，导致下游看板当日数据没有及时更新
可能原因：集群中出现了慢sql，任务优先级过低，抢不到资源
解决方式：优化解决；加基线，提高任务优先级

准确性

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

存在问题1：同一个口径的数据，数据对不上；
可能原因：口径问题，各方对口径没有明确
解决方式：明确口径，最好以书面形式进行梳理，整理成文档
存在问题2：数据波动过大，比如昨日单量和今日单量有了50%的涨幅
可能原因：上游对代码加工逻辑进行修改，但是没有通知下游，导致下游以老逻辑进行计算，数据肯定是不对的
解决方式：数据发生变更后，需要通知下游变更时间、变更原因、变更逻辑等信息；对任务配置DQC监控，对里面的表，字段设置命名监控、波动监控，主键唯一性监控，空值监控等，监控到异常后进行告警
存在问题3：代码提交前后没有进行代码审查
可能原因：个人原因，没有自查
解决方式：本地环境先进行自测，通过后进行代码提交；代码评审工作

举例：7月份有合作的商家：
一个是在7月份刚签合同的商家
一个是在6月份签了合同的商家，但是7月份合同还没有到期
这两种定义都是对7月份有合作的商家的理解，但是属于口径不一致的形况。

一致性

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

一致性表示数据来源、数据加工逻辑、数据格式是否统一
可能原因：口径问题、校验问题
解决方式：统一口径、人工校验+机器校验

数据资产的治理

（这个可以看离线性能优化部分）

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

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

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

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

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

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

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

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

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

治理工具的选择

这里讨论下我们需要的平台技术应该包括哪些。
其一，任务维护，以DataWorks运维中心为模板构建，包括任务的运行状况维护；
其二，任务调度，类似DolphinScheduler提供的完整能力；
其三，元数据管理，包括表的信息、血缘信息、备注的业务信息等内容；
其四，资产可视，包括表的数量、占用的存储资源、每日任务消耗的计算资源等，为治理提供依据
其五，学习中心，包括开发的规范、常见优化技巧等方法的集合，提供实操的手册。