什么是数据治理？
我们时常听到周围同事如下的声音：
数据分析师小A：这个表里面的字段连个注释都没有，不知道如何用，也不知道要问谁。
数据分析师小B：为啥这两个统计出来的数据对不上呢，到底哪个数据是对的啊。
数据平台工程师小C：最近这段时间跑批任务天天延迟，集群都快崩了，还在不停的加任务，咋这么多数据跑批，真的有用嘛 。
BI工程师小D：报表越做越多，也不知道那些报表做好了有没有人看哦。
数据运维工程师小E：存储告急了，又得额外采购机器了，也不知道今年领导给不给批。
或者偶尔看到如下的网文标题：
《南京银行副行长周文凯：数字化转型是中小银行发展的关键战略，最大痛点是数据治理》
《欧盟数据治理战略大逆转，正在启动个人数据市场，隐私还存在吗？》
无论是同事的反馈还是网文，其实都涉及同一个范畴-数据治理，那么什么是数据治理呢？
我采访了周围的几位产品同事：
同事A：提供准确的数据，并且能够提供稳定的数据相关服务给到上游
同事B：准确理解需求方的需求，并帮助其处理数据，并且持续的维护这些数据
同事C：业务持续发展，数据表的设计不尽合理，需要重新整理
同事D: 数据治理，第一直觉就是对数据质量进行监控，处理数据质量相关的问题
看来大家对数据治理的理解不尽相同，而且似乎特别强调了数据质量的管控对于数据治理的重要性。事实上，到目前为止业界对数据治理也还没有形成统一的定义，那什么是数据治理呢？以及数据治理和我们大家有什么切身的利益关系？为什么要做数据治理？怎么做数据治理呢？这些问题我们暂且按下不表，先看看大半年以前我们折腾的一个项目。
数据治理项目
背景——
大半年以前，某一天石头哥召集数仓，BI，平台几个同事，说了下目前大数据平台表现出的一些问题：近一段时间比较突出的如跑批任务延迟，impala的ad-hoc查询速度慢等等这些优化师集中反馈的问题，以及长久以来在数据治理方面的欠缺点，比如资源不均衡，信息不对称，监控不完善等等问题。石头哥希望大家想办法，集中资源，在一段时间内通过项目的形式解决或者改善这些问题。关于需求方的痛点，我们做了一些整理，看起来什么都有。
项目分析——
我们的资源使用，无论是存储资源、计算资源，本质上是因为在维持业务运转过程中需要提供各种数据服务或者数据分析工作，而这个过程中会伴随大量的作业，ad-hoc查询以及对相应的数据表的存储。我们在对这些作业，查询，表的监控数据基础上，了解到资源使用的情况即所谓的数据准确性，数据时效性，数据复用效率等等之后，从中发现数仓设计，作业调度等等待优化的点。
在这样的方法论指导下，我们对项目所涉及的范围做了如下的拆分，底层建立和完善关于资源和服务的监控，以此作为基础，之上针对性的重新构造数仓以及优化作业调度，并对集群做了迁移和优化，最后从需求方角度，解决大家比较关心的一些涉及元数据管理的问题，同时建立双边的沟通机制。其中针对数仓和作业调度的优化，我们在引入专家经验的同时，也纳入了算法研究，寄希望于在算法上有一些突破，从而实现一定程度上自动化或者智能化的数据治理。
数据监控体系搭建——
针对计算资源的监控我们做如下的一个梳理：
平台：impala，hive，spark
应用类型：报表，ad-hoc查询，数据跑批任务（例如数仓ETL，业务数据产品/服务，SLA)等等
指标：query数，耗时，vcore，内存，失败/成功比例，badquery比例等等
存储资源监控相对比较简单，我们对表的大小做每日snapshot，观察动态的数据增长以及当前静态数据存储情况。
这里提到都是离线数据，针对实时的资源利用数据，除了大数据平台自身配置的实时运维监控，我们还针对性的做了关于impala平台的使用监控，以期解决分析师的一些痛点。实时采集impala的资源使用日志，获取进行中脚本。在此基础上，在查询平台的前端做一些实时资源，TOP N脚本以及用户在各种平台(使用了impala资源)执行中的脚本的监控，目的一是让分析师根据当前集群资源合理选择运行脚本的时间从而避开高峰期，二是管理自己的脚本，比如自行kill差的脚本。
在做数据监控体系的过程中，同时也做了一些比较容易落地的优化措施：
1：针对大家平时使用频率比较高的表，对其历史数据和每天增量数据都添加了统计信息，从而提升这些表在join时的效率；
2：针对报表应用平台的中间层任务，增加mongodb的缓存；
3：针对数据查询平台，在提交脚本时增加前端校验提示，尽量减少“应加分区未加分区”，“cross join”等不当写法导致的bad query，而且类似这样的校验可以包成接口，其他调用impala资源的平台可以方便接入对提交的脚本进一步检查;
4：根据应用的查询日志，针对一些无访问日志的应用做下线处理(必要时结合业务的反馈)，比如自动删除过期的报表；
5：针对数据应用做web负载均衡；
6：针对一些ad-hoc查询，为减少资源滥用，当扫描数据块达到一定数量之后，通过衡量耗时和查询完成度来做一些自动化的kill操作。
当然过程中，我们也碰到了一些前期被忽视的点，这里一并提出来，供大家参考：
1：我们的一些资源调用使用了公共查询账号，这个不太利于后续的问题query的owner定位，所以应该在账号权限管控方面更加精细化一些，这个无论是从安全角度，还是资源分析角度都是必要的；
2：应用在调用查询资源的时候，我们在日志中只能获取最终提交的脚本，而无法定位到具体的应用，因此需要在应用端，提交脚本时，增加额外的任务id，时间戳等标准化脚本注释，从而在提交脚本后，相关的注释可以被日志捕获，从而便于后续精细化的分析。
前面提到的主要是计算资源，再说说存储资源。我们主要做了如下两方面的优化：
1：历史数据经评估后，可采用定期转储，做到冷热数据隔离；
2：减少snap的频率。
虽然这里只是轻描淡写两句话，实际上在做存储优化过程中，还是碰到了不小的困难：一来模型有时候需要回溯的历史数据，如果减少snap的数据，则需要设计好回溯的方案，有时不一定能设计出来；二来定义业务无效并不完全依赖于访问日志分析，而是依赖业务的确认，比如是否最近业务线暂停了什么测试，或者业务收缩了等等导致数据访问异常；三来如何从数据部门发起存储优化(被动滞后且不高效)变为业务自发的优化行为，如何从机制上解决，比如有同事提过的简单粗暴对资源限额的方式，还有对计算和存储资源资产化的方式，此时优化存储的行为会被引导为降低成本的手段，这些方法都值得我们深一步思考。
数仓优化&作业调度——
说完上面的资源监控，下面先说下资源消耗的其中的大户之一-数仓任务，这里我们把数据产品/服务中所涉及的数据表任务也定义为数仓任务。针对数仓的优化，一是依赖数仓专家经验和分析做一些优化，常规的比如：
1：通过对业务的需求分析，提取共性需求，做出可复用的数仓表，减少业务对ods表的依赖，降低查询复杂度并且增加使用数据的便利性；
2：针对资源消耗的TOP N的脚本进行教科书式的sql优化；
3：全量作业改为增量作业；
4：针对已经废弃的数仓的表任务下线，当然是在和业务确认的前提下。
另一方面，人工在优化过程中发现其实有不少任务的脚本存在片段相似性或者甚至是子过程的简单重复性，这样的检查依赖人工检查显然是不高效的，于是乎我们求助了算法同事。涉及知识过于专业，算法小伙们可另开一篇技术文来介绍。这里只是勉强解释一下过程，首先我们分析的对象是sql脚本(文本)，通过一定方法把sql脚本解析成抽象语法树（AST），在对抽象语法树基础上经过一系列处理，提取出了血缘向量，最后通过向量两两相似度比较，得到相似度的排序，再把相似度排序靠前的脚本队(pair)给到数仓同事排查，相当于通过算法事先做了机器筛选提高排查效率。
数仓任务的资源消耗一方面受自身脚本的影响，当然另一方面也受到调度的影响，合理的调度可以有效地提高数仓任务整体的时效性，另一方面也是做到资源最大化利用。同样的，调度的问题我们也求助了算法同事，算法同事在这里把调度优化抽象成了一个带约束的优化问题：优化目标：任务总耗时缩短
约束条件：Hive集群Vcore和内存资源总量，SLA任务约定最晚完成时间
但实际操作过程中，这个问题比预想的要复杂很多。算法小姐姐如是说：1：Azkaban的调度时间配置单元是Flow工作流，而执行单元是Job任务，这意味着我们无法准确控制每一个Job的调度时间；
2：在MapReduce执行原理下，Hive任务在执行过程中的资源占用时间不一定是连续的，每个时点的资源消耗量也不一定是等值的。这意味着我们无法准确量化每个时点的资源使用与剩余情况。
由于算法暂时还没有落地到业务实操，我这里就不再展开了，等到算法小姐姐不忙的时候(可能等不到小姐姐不忙的时候了)，可以继续这项伟大的事业。
元数据管理——
截止目前，我们讨论的内容主要集中在系统资源层面的治理，但是和分析师日常工作相关且大家经常抱怨的就不得不提到元数据管理。元数据管理范畴很大，这里我只说下数仓的数据字典、报表和接口。关于数据字典，我们在原有的元数据管理平台基础上做了下如下的完善：
1：对数仓基本信息，字段信息，表变更说明，已知数据问题等信息的维护；
2：对数仓框架(树图形式)的信息维护；
3：纳入对业务核心数仓表的管理和信息维护；
4：提供基于表级别的上下游调用的血缘关系查询。
目前数据字典表相关的修改信息(比如业务调整导致的表的字段枚举值变更，字段的计算逻辑变更等等)主要是依赖于人工在平台维护，会存在更新不及时或者遗漏的情况，后续会考虑和操作表或者操作任务的平台的信息打通，在流程中加入对数仓知识的添加和修改要求，而后把这些知识自动同步到知识管理平台。分析师或者业务运营同事平时接触的最常见的数据产品形式就是报表，说到报表有几个痛点：
1：因为特别的原因，同时存在2套报表系统，可能同一业务线的报表需要在两个系统里面搜索；
2：对报表的搜索主要限于报表标题的搜索，而无法对报表里面指标，维度，备注信息，涉及的数据集等等相关内容进行搜索，不便于进行更精准的内容搜索；
3：搜索的时候只限于单个关键词，在需要缩小搜索范围时显得不是很方便。
针对上述的痛点，我们在元数据管理平台对两套报表系统的搜索进行集成，并且提供了基于多个关键词的搜索，而搜索的内容也从报表搜索扩充到了报表里面指标，维度，备注信息，涉及的数据集等等。
提到接口，可能不同公司的痛点都不太一样，这里说一个比较特殊的场景。我们分析师平时对离线数据进行分析时会发现一些有用的特征变量，这时势必会需要研发协助把这样的变量开发到线上去，用于线上的风控流程，此时就会需要了解这样的数据链路：数仓表-线下表-线上表-线上接口，其中链路的前半段”数仓表-线下表-线上表”我们已经基本打通，”线上表-线上接口”暂时信息还有欠缺。研发同事搭建了接口信息整合平台(接口超市)，同时也建立了对线上各种接口调用信息日志收集和监控的平台。首先我们借助接口信息调用日志解析出我们需要的线下表和接口的关联信息，然后再通过接口信息去查询接口超市，最终打通”线上表-线上接口”后半段链路，不过因为如下的一些原因：
1.不同的研发团队管理接口的方式不一样，有些在confluence里面，有些使用swagger，整合需要时间。
2.线上接口调用信息日志收集，有些非java的应用还没有接入，比如python或者go的应用，另外一些不是走接口的信息还有缺失，比如走消息。
我们暂时搁置了这个方案，待时机成熟时再继续打通这个链路。
关于元数据管理，除了前面提到的数仓知识、报表知识和接口，实际业务开展过程中有很多需要完善的地方，这里就不再展开。
沟通机制——
前面都是在说各种问题的优化，回到问题本身的提出者我们的同事，实际上建立一种良好的双边沟通机制也是重要和必要的。为此我们发起了一个员工关怀计划，旨在更好的服务大家。业务部门确定接口人，和相关工程同事一起定期的沟通双方都相互关心的问题，事实上我们前期确实收到了大量的反馈，很多优化点也是在这些反馈中提炼出来的，可能我们的同事“等待了”太久。
我从中举两个例子：
1.之前线上数据同步到线下大数据平台，需要走冗长的流程，无论是中间的审批，还是等待工程同事的操作，后来在大数据同事和DBA积极努力下，现在已经实现了单库单表，分库分表的自动化同步。
2.之前业务同事需要看实时报表，但是内部的kudu资源比较紧缺，后来在大数据部门开发了相应的变量计算平台之后，顺势把业务实时报表需求也接入了进来，需求一直存在，但是具体的解决方案其实可以灵活多变。
截止项目结束时，我们收集到的各种和数据治理相关的诉求约34个，少部分受限于条件暂时hold，或者cancel掉了，其余大部分都已经解决了。
人——
为什么需要把人单独拿出来讲呢，因为21世纪“人”才最重要。总结几个点：
人要多：因为数据治理牵涉到团队很多，纵向的看数据的上下游从生产到消费都涉及到，横向看各条业务线也都会涉及到，所以需要配合的人力资源也相对比较多。
人要高：数据治理不直接推动业务增长，可能短期内也看不到除资源优化的其他效益，所以需要决策者承受一定的组织压力，因此决策的人职级相对需要高，数据治理的决策一般是自上而下的。
人要想：实际上很多时候，不是所有问题都能通过技术或者机制来很好解决，更多的时候需要人的自觉配合，积极主动，设身处地的想要把数据治理落实到位，因此涉及的人只有自己“想”，才会发挥更多的主观能动性。
真是因为这几点，所以才会特别强调人在数据治理项目里面的重要性。
行文至此，虽然还有很多很多故事要讲，不过受限于篇幅的限制，关于项目的内容我们先告一段落。
数据治理的知识体系
说了这么多，大家的脑海可能陷入了各种优化的手段和具体细节点之中去，缺乏对数据治理的更宏观理解，因此我们有必要引入数据治理的知识体系，让大家既见树木又见森林。好在数据治理不是什么新的话题，已经有很多前辈对此进行的研究和总结，这里就特别提一下DAMA，不要误会，我说的不是中国“大妈”。DAMA International （国际数据管理协会）成立于1980年，是一个由技术和业务专业人员组成的国际性数据管理专业协会，作为一个非营利的机构，独立于任何厂商，旨在世界范围内推广并促进数据管理领域的概念和最佳实践，为数字经济打下理论和实践基础。全球会员近万人，在世界48个国家成立有分会。
此协会致力于数据管理的研究、实践及相关知识体系的建设，在数据管理领域累积了极为深厚的知识沉淀和丰富经验，出版了“DAMA数据管理的知识体系和指南”（DAMA-DMBOK），包含数据治理、架构、数据仓库等十余项职能的内容，目前最新的版本为DMBOK 2.0，而且DMBOK也已经成为国际大数据管理领域的事实标准。
如下是知识体系中提到的数据治理的11大知识领域
- 数据治理：通过建立一个能够满足企业需求的数据决策体系，为数据管理提供指导和监督。这些权限和责任的建立应该考虑到组织的整体需求。
- 数据架构：定义了与组织战略协调的管理数据资产的“蓝图”，指导基于组织的战略目标，指定符合战略需求的数据架构。
- 数据建模和设计：以数据模型（data model.）的精确形式，进行发现、分析、展示和沟通数据需求的过程。
- 数据存储和操作：以数据价值最大化为目标，包括存储数据的设计、实现和支持活动，以及在整个数据生命周期中，从计划到销毁的各种操作活动。
- 数据安全：这一活动确保数据隐私和安全，数据的获得和使用必须要有安全的保障。
- 数据集成和互操作：包括与数据存储、应用程序和组织之间的数据移动和整合相关的过程。
- 文档和内容管理：用于管理非结构化媒体的数据和信息的生命周期过程，包括计划、实施和控制活动，尤其是指支持法律法规遵从性要求所需的文档。
- 参考数据和主数据管理：包括核心共享数据的持续协调和维护，使关键业务实体的真实信息，以准确、及时和相关联的方式在各系统间得到一致使用。
- 数据仓库和商务智能：包括计划、实施和控制流程，来管理决策支持数据，并使知识工作者通过分析报告从数据中获得价值。
- 元数据管理：包括规划、实施和控制活动，以便能够访问高质量的集成元数据，包括定义、模型、数据流和其他至关重要的信息（对理解数据及其创建、维护和访问系统有帮助）。
- 数据质量管理：包括规划和实施质量管理技术，以测量、评估和提高数据在组织内的适用性。
看起来，数据治理的内容是相当的宽泛，方方面面都涉及到。关于此知识体系，笔者水平有限，不在这里展开了。大家有兴趣可以买本小册子《穿越数据的迷宫 – 数据管理执行指南》（算是DMBOK的精简版）自己学习一下，而后我们多多线下交流吧，这里算是给大家开一扇窗。
最后的最后
说完了项目，也引入了知识体系，再回到一开始我们的那些问题，可能每个人心中或多或少都有一些答案。不过想特别强调的一点因为数据作为一种重要的资产里面蕴含了极大的价值，所以数据治理特别重要，但是数据治理是一项长期且复杂的工程，需要通过一系列流程、机制、技术能力建设来保障治理工作的持续推进。正所谓优化项目终有尽，数据治理无绝期。
让我们用一句”名人名言”来结尾——“虽然数据还没有被列入企业的资产负债表，但这只是一个时间问题”。
本文来自信也科技拍黑米，经授权后发布，本文观点不代表信也智慧金融研究院立场，转载请联系原作者。
shyant