该文章已同步到语雀公开知识库《大数据技术架构手册-1》中;公众号后台回复“小程序注册码”可免费查看面试题小程序
前言
作为一名数据人，常常自嘲为SQL Boy，某天突然发现原来SQL boy还有一些更高级的工作内容：数据治理。这两年也有很多的大佬分享了很多关于数据治理、数字化转型的干货，个人也从中学习到了很多东西。但真正掌握这些内容和学习编程还是有很大的区别：学习编程可以通过一些简单的demo实践达到知行合一，但治理工作需要结合组织、流程、文化、制度等多因素，需要站在更高的层次，也就是常说的天时地利人和，才能让自己真正的达到知行合一。
有趣的是，前不久跟几个好朋友聊起最近各自工作内容，发现大家或多或少都在做一件事：降本增效。这也不难看出疫情叠加宏观经济放缓等大趋势影响下，企业开始将转型、降本增效作为首要目标。当前很多企业的目标和治理工作不谋而合，这也为很多数据同学提供了更好的发展机会。去年笔者有幸主导推进企业治理工作，该文一方面作为工作复盘，另一方面希望该文章其中的一些内容能够帮助到正在参与治理工作的同学。
由于笔者能力和水平有限，如有错误之处，还请多多指点。
治理前
回顾过去，早期团队在治理的道路上一直是属于短暂式填补的方式进行，直到21年最后一个季度才算是真正的成体系的开始治理工作。结合企业当前现状，在开展治理工作之前，团队内部做了大量的准备工作：
1、目前内部存在哪些痛点？
2、治理的边界及深度到哪里？
3、如何制定治理工作的执行路径？
4、如何建立适用自身的治理评估体系？
5、如何在治理工作和日常业务支撑之间做好平衡？
常言道：有道无术，术尚可求；有术无道，止于术。如果同学储备了一些数据治理的知识的话，以上几点都可以从相关书籍中找到其中的影子
接下来将针对以上几点进行具体的介绍:
痛点
痛点一：数仓早期为了快速支撑业务，再加上人员迭代比较快，文档意识比较薄弱，导致目前很多历史任务无法追踪其业务需求来源以及应用价值，陷入了不敢下线的尴尬局面（业务元数据缺失）
痛点二：集团的业务发展变化非常之快，早期设计划分的数仓主题及域已经出现部分不清晰、不适用的情况，且工具层面的不完善无法保障规范度，对于数仓人员的后期维护成本非常之高（模型设计不清晰、不规范）
痛点三：目前平台上承载着7000多任务，其中很多任务的计算逻辑是重复引用的，但由于缺失表粒度的引用信息以及缺少统一指标管理，无法精准定位到具体哪些任务出现重复计算（重复计算、缺失统一指标管理）
痛点四：每日的0~10点是集群负载最高的时间段，且随着时间推移，任务数量的不断增加，集群资源也越来越紧张，任务的稳定性和及时性都无法得到保障。（任务稳定及时性差）
痛点五：在整个数据流转环节中，质量问题一直未得到真正意识层面上的重视，源头数据脏、加工环节缺少监控、事后未运营等问题，目前仅是通过业务层面的反馈来改善质量（数据质量差）
痛点六：数仓是围绕着“以业务为本，数据为核”的原则重点建设，但在整个入仓、仓内加工、出仓的全链路监控环节上意识比较薄弱，例如任务稳定性、及时性、模型好坏、价值体现等指标都未得到有效衡量（监控环节薄弱、价值体现不明显）
治理边界及深度
如上图所示，数据治理的内容包括数据架构、数据模型设计、数据存储、数据质量、元数据管理、数据安全、主数据和参考数据、文件内容管理、数据集成操作等多个板块。也就是说治理内容从数据的定义、生产、存储、处理、使用、共享整个生命周期全部都涵盖在内。
笔者根据内部实际情况以及人力投入等综合因素考虑，基于以上六大痛点，即主要围绕着数据生命周期、数据质量、元数据管理、数据模型、效益评价这几个方向展开阶段性工作，同时根据痛点的紧急程度制定阶段性目标进行不同程度的治理。
结合内部实际情况，对于痛点一、四、六是属于紧急且重要的优先治理对象，本文也只对这三块痛点进行介绍；
需要注意的是：治理工作不是阶段性的，而是长期持续不断进行的；治理不是刻板僵硬的，而是根据实际环境或优先级进行不断变化调整的，也就是说每个阶段都要有每个阶段的治理目标。最佳的方式应该把治理内容融入到日常标准流程中。
治理执行路径
DAMA数据管理知识体系指南一书对数据治理的定义如下：数据治理(Data Governance,DG)是在管理数据资产过程中行使权力和管控，包括计划、监控和实施。其目的是确保根据数据管理制度和最佳实践正确的管理数据，而数据管理整体的驱动力就是保障组织可以从数据中获取价值。
指导方针
笔者认为治理其实是对数据资产的一种管理，而管理数据资产的过程中，必不可缺的是元数据。因此在开展治理工作之前，制定了“基于元数据驱动，对资产进行分级运营、分步执行”的指导方针。
资产定级
基于内部实际情况，并按照治理指导方针开展工作。由于内部在元数据管理方面已经做了很多的工作，相对来说比较成熟。而在对数据资产方面相对比较薄弱，因此笔者参考了《阿里MaxCompute平台数据资产制定标准》对内部数据资产进行盘点定级工作，同时根据不同的级别采取不同的运营手段来实现最终的目标。
通过对数据资产进行等级划分定义，可以有序的推动治理和运营工作，其最终目的是要来保障数据质量准确性、完整性、一致性、及时性等多项特性，而不是像无头苍蝇到处乱撞。资产等级的制定标准也不固定，大家可以根据企业自身的实际情况来约定，一般是根据其重要性、对业务的影响程度来划分（以下等级来自阿里MaxCompute的制定）：
● 毁灭性质：数据一旦出错，将会引起重大资产损失，面临重大收益损失等。标记为A1。
● 全局性质：数据直接或间接用于企业级业务、效果评估和重要决策等。标记为A2。
● 局部性质：数据直接或间接用于某些业务线的运营、报告等，如果出现问题会给业务线造成一定的影响或造成工作效率降低。标记为A3。
● 一般性质：数据主要用于日常数据分析，出现问题带来的影响极小。标记为A4。
● 未知性质：无法明确数据的应用场景。标记为Ax。
这些性质的重要性依次降低，即重要程度为A1>A2>A3>A4>Ax。如果一份数据出现在多个应用场景汇总，则根据其最重要程度进行标记。
资产等级的打标应该从数据入仓时到出仓应用整个链路，这样可以通过逆向推导重新更改具体某项资产的等级。笔者在对内部数据资产定级的时候设定了四种等级，下图为截取部分任务的占比情况：
注意：大家在对数据资产进行定级的时候，可以根据实际情况，选取不同的衡量标准进行定级，其最终目标就是便于管理
成本治理
前面提到过，笔者结合所处的实际情况以及问题紧急度，将及时性、稳定性、知识库沉淀、全链路监控、价值体现这几块内容作为第一阶段治理对象。
其中及时性和稳定性的保障是属于成本治理的范畴，关于成本治理的手段相信很多朋友也有一个比较清晰的认知，稍后为大家介绍笔者在这块内容上所采取的手段。
全链路监控是为后续治理工作的开展和日常运营提供一个可靠的基础支撑。从数据的入仓、存储、规范度、复用度、计算耗时产出及资源占用情况、数据出口类型及频次等每个环节进行监控，当然要想监控到每个环节，基础数据是不可或缺的，比如调度数据、平台审计日志、资源分配数据、配置数据等等诸多支撑数据都需要收集进行分析监控。（图片做了脱敏处理，清晰度较低）
数据治理工作往往是属于吃力不讨好的，而且需要得到高层领导的大力支持才能持续开展，因此建立完善价值指标体系是作为治理成果的最好体现。
接下来为大家介绍一下笔者在及时性和稳定性方面上采取的一些措施（这里需要结合前面的资产盘点定级，优先处理哪个级别并采取什么样的措施完全可以根据大家实际情况各自抉择）：
任务优化
这里的任务优化包括：小文件优化、分区优化、资源分配过大或者过小等一些可以从代码层面进行解决的问题。
任务下线
对于一些僵尸任务、空跑任务、超过正常生命周期的等无价值的任务进行下线清理。
计算推移/任务降级
每日夜间集群处于高负载运行状态下，在这期间很多任务会因为资源抢占问题而出现异常情况。而对于一些不重要的任务可以进行降级处理，将资源优先分配给高优先级的任务，保障高优先级任务及时产出
引擎切换
目前内部采用hive on mr，spark两种计算引擎。虽然spark具有内存迭代计算的特性，但早期由于没有形成严格的资源申请标准，成员随意指派引擎进行任务调度，随着时间的推移，任务越来越多，反而导致组件稳定性下降，任务产出迟缓。为了解决该类问题，对于资源的分配和引擎的选择制定了严格的标准，高优先级的任务优先采取spark引擎，尽可能地保障高优先级的任务产出。
模型优化
其中有一些高优先级的任务是属于宽表模型类型的，无法进行降级或者经过其他各种手段处理后已经没有优化空间了，这个时候会选择模型优化，必要时进行拆或者合的操作。当然模型治理是属于下一个阶段的内容，在成本治理阶段是属于短暂填补式的。
异常推送
早期数仓任务告警推送的方式仅有邮件，后续增加了短信、企微。但由于数仓任务复杂度较高，监控维度丰富(比如重试、失败、依赖缺失、质量监测、枚举管理等等)，经常出现大量的告警邮件推送。随着时间的推移，成员逐渐对该种通知方式产生了麻痹心理，不能及时处理异常任务，且告警邮件数量较多很容易掩埋重要邮件，造成漏阅。
为了解决多渠道推送带来的麻痹心理，保障解决问题的及时性，简化了推送方式，同时采取了公开透明、告警升级等多方向来保障问题及时解决率。
驱动治理
在治理的过程中，需要不定期的对团队成员进行宣讲和培训学习，让每一位成员都能够到清晰的认识到目前所做事情的目的及意义，让每位成员能够自觉地按照规范标准做事，提高个人意识，培养自驱力。在有些资料中提到过评分卡的衡量标准，以此来驱动各责任方进行治理。当然就笔者所参与的第一阶段治理，并未引入评分卡标准，从长远来看，评分卡是有必要存在的，特别是涉及到跨团队协作，成本结算、绩效考核的时候。
治理评估体系
目标
团队在开展治理工作准备阶段时，制定了“问题标准化、过程策略化、治理可量化、运营有抓手”四大原则。关于目标的衡量标准和规定值，大家可以根据实际情况自行制定。笔者不在这里絮述。简单分享一下笔者当时所在团队主要从成本收益、质量收益、人效收益、价值收益四块进行制定了相关目标，比如节约存储量、人力节约、问题减少次数、时效达标率、质量合格率等。
治理工作和业务支持的平衡点
要想开展治理工作，就需要找到和业务相关的契合点，得到领导的支持，否则就成了无水之鱼。当得到领导的支持并不意味着治理就一定能成功，同时也不意味着日常的支撑就不做了，这里就需要在人员分配上和工作安排上做好平衡，前面也提到过业务为本这句话，所以大家在做治理工作的时候需要分清主次关系，如果能做到人力all in的情况那是最理想的，总之要做到“人停事不停，换人不换事”。
治理成果
关于治理成果，不是本文的重点，简单分享一下团队经过一个季度左右的努力所做出的成绩，尤其在及时性和稳定性得到了质的飞跃，整体链路提升了2~3个小时产出，稳定性较同期提升了80%，问题解决及时性控制在1d内，同时在治理的过程当中也沉淀出对应的知识库。按照制定的规划，那么下一个阶段将围绕着模型治理、指标管理方面展开。待第二阶段完成后，同样以文章的形式分享给大家。