导读 随着公司业务方规模的增长，面对大量不同类型的数据，如何治理这些来源不同、数据量大的数据是一个值得思考的问题。
本次分享结合腾讯内部数据管理方法，围绕数据治理技术实践，展开介绍腾讯在数据治理领域中做的相关工作，本次分享围绕以下三点展开：
1. 数据治理简介
2. 腾讯数据治理体系简介
3. 数据治理技术实践
分享嘉宾｜赵磊 腾讯 腾讯元数据系统负责人
编辑整理｜韩城 新浪微博
出品社区｜DataFun
数据治理简介
首先介绍一下数据治理相关理论知识和概念，以便大家对数据治理有一定了解和认识。
个人理解的数据治理是整个数据相关组织架构以及各种活动能力的集合，因此，数据治理并不是单一组织或者系统能够完成的事情。数据治理和数据管理是分不开的，数据治理的职能是指导其他数据管理职能的执行，数据治理是在高层上执行的数据管理。
2. 数据治理目的
数据治理的目的有很多，比如数据共享、提升数据资产价值、提升数据质量等等，从下图中的某机构调查结果可以看到，提升数据质量是数据治理的最大动机。除此之外，国家对数据相关法律规定，各个公司也有相关的规范要求，数据合规也是数据治理需要考虑的问题。
3. 数据治理面临的困难
数据治理面临着诸多挑战：比如数据多样化缺乏统一标准、多种异构类型的数据源、数据链路长、数据合规保障、数据价值如何评估等等。
4. 数据治理方法
了解了数据治理面临的问题后，该如何解决这些问题？我们的方法就是知治管（先知后治再管）。
先知就是要知道治理的数据对象，知道数据的形式，存储位置等；后治是使用相关技术进行治理比如规范化、标准化等处理；再管就是尽力去提升新数据的质量，这样才算是真正把整个数据治理按体系做好。数据治理其实是一个闭环的体系，所以还需要将数据治理反馈到整个数据管理流程上。
5. 数据治理过程
数据治理由图示的四个步骤构成：
一是现在盘点，理清楚数据现状，确定归属和职能。
二是数仓建设，这里的数仓包含了传统意义上的数仓和元数据数仓，对这些数据进行统一采集和保存。
三是质量检测，确定评估标准，输出数据质量报告。
四是持续改进，根据数据质量报告推动数据持续改进，比如建立数据地图、分析血缘关系、持续监控数据质量、优化数据使用流程。将数据的产生和治理相结合结合，形成闭环，从而保证数据的采集和数据治理变得更好。
02
腾讯数据治理体系简介
这部分主要介绍腾讯内部数据治理体系的建设思路和策略。
1. 组织管理体系
在腾讯内部，我们建立了统一组织，规划和协调整个公司的数据治理、数据安全工作，以 OTeam 形式规划和实施整个相关领域的平台建设和规范协同；建立企业级标准，规范测评体系；构建平台协同，建设开箱即用的一站式数据治理工具平台；形成社区运营，通过分享或宣传的方式，让大家意识到数据治理以及数据质量的重要性。
2. 腾讯数据治理业务框架
腾讯这样量级的公司，动辄几千万上亿甚至百亿级别的数据，数据的采集和存储都是很大的问题。在上亿量级的数据治理建设过程中，我们一步步实践，踩过很多坑。通过制定数据治理标准，搭建了以资产创建、资产评估、资产运营、资产管控四部分构成的数据治理平台，构建全域元数据服务，形成了元数据采集、存储、数仓、数据血缘的整个数据生命周期链路，结合底层采用多种存储方式，逐步建设了一个可以管理和区分优质资产与数据垃圾、相对较好的元数据管理体系平台。
3. 元数据管理
我们从如何采、怎么存、引导治出发，来思考和逐步完善元数据的管理。
4. 数据资产管理
我们建立区分优质资产，减少垃圾数据的数据资产管理平台，由四个部分组成：
首先是确定数据归属，如果数据归属都没明确，则数据治理工作是很难展开，像腾讯这样级别的大公司，经过多次组织架构的变更，数据归属问题尤其凸显，比如说经过组织调整，单个 BG 的数据拆成了多个 BG 的数据导致，数据管理问题在组织架构变迁变得非常混乱，因此确定归属关系是数据治理一个非常关键的环节。
其次是价值分析，通过业务属性和数据访问这两个维度对数据进行评估数据的价值，业务属性也即是公司在各个领域的业务比如账号体系等等。如数据访问的量或者访问频次越高，就认为该数据重要或者具有更高的价值。
然后是数据清理，为了避免数据清理或者减少权限变更影响的范围，需要进行影响分析判断，同时结合自动化清理工具完成整个数据清理或是权限变更。只是做好数据清理工作是不够，因为在实际操作数据过程中，可能会出现误删或故意删除的情况；为了保证数据数据情况的可靠性，我们还建立一套数据可恢复的机制，从而保证出现上述情况时，能够快速进行数据恢复，尽可能地降低影响范围。
最后是生命周期，结合数据血缘和访问频次等学习，为用户设置数据生命周期时，对该数据的生命周期进行智能化推荐；当然，这只是推荐的生命周期，数据最终的生命周期要结合着人工审核判断，给定一个比较合理的周期。
5. 腾讯数据治理测评体系：元数据管理成熟度
我们对元数据管理制定了测评体系，用于对公司整个数据管理和评估，可以看到图中从下到上分为五个等级，一二级是一些初始或基本管理方法，第三级则是相对来说已经比较成熟，但是完全不够的，还需要将数据驱动和数据治理与数据使用形成闭环，以便做好元原数据的管理，此时已经是第四级，是比较优秀的程度。第五级则是比较卓越管理体系，需要具备自我完善和自我改进的功能，同时能够在公司内或业界有一定影响力，元数据管理真正能做到这个级别的少之又少 。
6. 数据安全治理
数据安全也是数据使用过程中一个非常重要的环节，在这过程中，我们首先对数据进行了分类分级处理，为数据确定安全等级和标记，并与数据资产进行关联。其次在进行数据管控，根据数据的分类分级结果，定制不同数据级别的申请流程，比如动态或静态数据，数据加密和脱敏，在数据使用中对数据进行管控。最后是安全审计，支持一些安全审计相关功能比如数据权限访问监控、访问记录、下载日志等等，并可以输出安全报告。
7. 腾讯数据治理测评特征-安全管理能力成熟度
我们对数据安全能力管控也制定了评测体系，即安全管理能力成熟度，包含了 12 个管理域以及 86 个控制项。数据安全管理能力从低到高分成五个等级。
制定了数据安全管理能力标准后，数据治理通过 OTeam 进行统一组织和协调，各个部门自行申请或者参与到整个评测的工作中。
03
这部分是本次分享的最核心部分：腾讯内部元数据管理、数据血缘相关技术和相关的后台技术实现。
1. 技术架构
下图是我们内部统一元数据系统的技术架构。对外来说，上层可以支持不同类型元数据，可以满足各种分析引擎对元数据相关的要求，同时对接各种自定义或者标准化的数据源。这套底层统一的元数据服务既要满足公司内部的要求，同时也要满足外部的用户对整个数据治理的需求。目前这套元数据管理除了内部使用外，也支持了腾讯云上的产品比如 WeData 等，我们统一元数据平台目前对公司内外及相关产品都可以提供支持。
从下往上看，整个统一元数据可分成两个垂直的领域。
左边是数据治理体系，主要面向的是离线采集、存储，然后做数据检索、生命周期、数据安全、数据血缘和数据质量的管理，这些就是数据治理提供的基础服务。在线元数据是支持引擎侧的实时元数据写入，比如大数据领域最典型的 Hive、RDBMS、Strom，通过 thrift 协议，将数据实时写入到元数据服务。离线数据治理和在线数据治理所面临领域和技术的差异是比较大的，数据治理更关注的是大数据量基础上，如何做好分析、检索和工作。因此在底层存储的选型方面结合了各种数据库，比如 HBase、ES、图数据库以及关系型数据库来支撑整个离线治理工作。在线元数据服务因为有部分事务工作，比如建库建表，实时写入时，需要考虑到事务、数据一致性和高可靠等因素，因此，在底层存储时，选择了传统的关系型数据库进行存储。需要事务和一致性、高可靠的方式去完成。像腾讯体量的公司，数据量是非常庞大的，单纯的靠单机 MySQL、PQ 是很难支持这种海量数据存储。因此，我们在这个基础上进行分库分表，并利用公司内部 TDSql 分布式数据库存储。
右边在是统一元数据服务基础，提供公共的平台能力，比如认证、鉴权、任务调度、用户租户以及运营监控。
2. 微服务划分
上图是我们整个元数据治理服务后台微服务划分，上层是元数据产品、计算引擎、数据源，第二层是在第一层基础上提供后台能力，比如数据地图、元数据采集、数据血缘和资产管理等功能，最底层就是整个支撑这套体系的技术服务。
后台的技术服务又分成了两层：第一层是数据层或接入层，主要由databus、center、metastores 组成，其中 hybirs 是元数据服务内部代号。databus 的作用是统一消费经过 MQ 转发的消息并落库，http 服务和 Thrift 服务经过接入层服务后，通过 RPC 协议进入基础服务层并在基础服务层进行业务逻辑处理，最后写入到底层存储。
接入层分为两层是为了底层存储能够提供通用的服务能力。接入层的第二层更灵活，可以支持不同产品和引擎，以及不同数据源对接和适配。从图中可以看到，databus 有一条直通底层数据库的链路。考虑到 databus 的职责所在,因为 databus 是对 mq 消息进行统一消费，考虑到数据量，databus 对写入效率的要求非常高。http 服务和 Thrift 服务的数据量相比而言就少 很多，为了减少数据消费的延迟，我们将 databus 消费的数据直接落库，减少 http/Thrift 服务中的 RPC 调用，缩短链路，进一步提升数据入效率，从而将采集的数据及时地存储底层存储中。
3. 数据采集
首先是统一元数据的数据采集，数据采集可以分成两个方向：定时采集和实时采集。
定时就是通过定时任务或调度定期连接数据源，对上游的元数据进行采集。采集的过程又分为增量采集和全量采集。因此定时采集可以分为定时增量采集和定时全量采集；定时增量就是每次只采最近一段时间的数据，通过积累采集全部历史数据。定时全量就是每次将全部数据一次性采集完，然后落地。
在实际工作中，往往是将增量采集和全量采集结合使用。数据采集并不是最初就进行全量采集，而是待数据积累到一定量后才对元数据采集或治理工作。首次采集时，通常是使用全量采集的方式将历史数据采集，后续的数据往往是通过定时增量的方式采集。
对于那些必须要定时增量的数据，为了减少后续链路的压力，我们做了针对性的优化：通过 redis 对定时增量做了过滤处理，比如采集周期内，对库信息、表信息以及分区信息计算 md5 值并存储在 redis，然后对采集的元数据进行 md5 计算，再与 Redis 中对应的值进行比对，在源头过滤掉没有差异的数据，从而减少重复数据的发送。
面临的另一个问题就是全量采集时全量删除和全量覆盖。在增量化处理时，数据删除是面临问题的：上一次是全量处理，后续则是增量处理，比如在某个周期内，有五个库，这一次采集，需要删了一个库(表),增量采集的方式是没办法直接找到要删除的库(表) ，也即是删除些信息没办法透彻到下游。
针对数据删除无法发现，我们对数据源所在库和表做了缓存，在后续的数据采集时，与 redis 中缓存数据做全量对比取交集和差集，从而判断数据的修改情况比如删除、新增或修改，在源头去掉重复的数据，同时有又能发现删除的情况，最后把过滤处理后的数据发到消息中间件。经过后续的消费、分发(采集的数据源是有多种多样的，因此会有分发器来识别和和处理不同类型元数据)最终分发不同的数据存储的流程。比如血缘信息、元数据 DDL 信息、审计日志信息的数据，针对不同类型信息数据有不同的处理链路，根据数据特点落入不同的存储，比如血缘信息数据写入图数据库，元数据 DDL 信息存储到 HBase。
数据治理产品前端交互是通过 ES 完成，打上宽表满足前端交互和数据发现以及数据管理的需求。数据审计的日志流水，则使用内部 hermes ，hermes 是一个类似 ES 的产品，但在存储方面做了针对性优化。
传统关系数据库都有唯一的主键，根据这个主键就可以增删改查等处理。但是在元数据管理中，对于非采用非关系数据库，该如何处理呢？比如上游采集好的一条元数据信息传递过来，我们需要对数据进行判断，比如是否存在或者是否修改。首先是查询，根据库(表)名查询是否存在，若存在则是更新操作；不存在则是新增操作。这个过程会与数据库发生两次交互，对整个链路会产生较大的影响 。
为了处理这个问题，我们引入了 guid 生成器（guid generator），将库和表的信息和数据源信息输入到 guid 生成器，生成一个统一编码的 guid，作为底层存储的唯一标识。然后用生成的 guid 对数据库进行一个类似叫 replace into 的方式，从而实现通过一次跟数据库的交互就能新增或修改操作。这样处理对整个写入流程是一个很大的提升。比如 hbase，直接使用 upsert，将新数据写入数据库，无需关心是新增还是修改。为了保证数据的最终一致性，我们将实时与周期性全量或增量的方式结合，去实现数据的最终一致性。在发生数据实时采集不及时或者链路有问题的情况下，通过全量采集的方式进行补漏处理。
血缘分析对整个数据价值体验是非常重要的，如何做血缘分析呢？首先是血缘的来源，最直接的方式就是用户通过执行引擎的客户端或者直连执行引的 server 提交的 sql。比如基于 hive 或者腾讯内部的 thive 提交 sql 后，我们通过 hook 或者 spark 的 listener 或者 hbase 的协处理器的方式拦截到具体 query plan，query plan里面记录了用户提交的 sql 以及整个执行过程中 context 的上下游信息，包括 intoput、output 等信息。对 query plan 进一步解析，从而形成了数据血缘的 mode，然后写到 MQ，最后获取 sql 数据进行解析，将血源信息落到图数据库。
另外一种就是通过定时调度产生的血缘，感知到用户提交的 sql 表信息之外。还需要将用户调度任务信息与库和表的关系进行一个呈现。同时会将通过其他方式提交的历史任务记录的日志消息存储在 HDFS。我们会定时抓取这些日志并对日志做统一分析处理，比如 mr 、spark、sql 分析，形成血缘模型，发送到 mq，最终写入数据库。
sql 解析是血缘解析过程的关键技术，业界有很对 sql 解析和开源的技术，我们内部是基于 Druid 进行封装和改进构建了sql guru，并进行 sql 解析。相比于 hive 的 antlr 解析器，通过实际效果对比，我们选择了在性能稳定性以及支持的场景更有优势的 Druid。Druid 处理广泛使用的连接池之外，它数据 sql 解析方面也是比较强悍的。除了常见的血缘解析能力之外，我们还扩展了一些比如像物化视图、像临时表 with as，join 等复杂 sql 的解析。基于相对全面元数据采集，结合强悍的 sql 解析能力以及语法支持，我们将血缘分析的场景尽可能做得完善。
5. 数数据血缘存储
图数据库是血缘存储的常见方式，因此图数据库也作为了我们内部血缘存储的一种方式。当数据量级比较小时，图数据库并不是血缘存储的唯一方式，基于传统的关系数据库可以表达出来血缘的关系，血缘无非就是各种实体以及它们之间关系的记录。
以图中的 case 所示，图中有两个调度任务，第一个调度任务里面有两段 sql，执行第一个 task 是会执行两个独立的 sql，第一个 sql 是 a 和 b 的关系，第二个 sql 是 d 和 c 的关系。第二个 task 只有一个 sql，它是 a 和 b 的关系，那这个时候就会有一个问题：数据血缘图数据库里面怎么呈现的呢？
图数据库存储的无非就是点和边以及中间的线，横向来看，我们把表和任务作为点来存储，可以看到左边这种情况 那我们看 比如像 task A 把 a 和 b 关联，同时将 c 和 d 关联。因此，它们的血缘关系如图左上角所示。因为是通过同一个 task 关联，当我们去寻找与 c 有关联的血缘时，会找到 b 和 d 都找到了。从图中可以看到 task A 一个特性里面看到有两段的 sql，但 a 和 b 才有真正但血缘关系，c 和 b 之间是没血缘关系的。c 与 b 之间有血缘关系是因为错乱导致的。
因此我们做了针对性优化，如右上图所示，可以看到右边这种情况。将任务节点拆成两个节点，虽然两个节点输入同一个任务，但是每个节点都有唯一的标识记录，这样就可以区分出来，建立关系清晰的血缘链路。从 a 出发，就只会知道与它有血缘关系的 b，这样就解决了上面所说的错乱的问题。
另一种思路就是将表作为点,任务去作为边,那这种情况会有什么问题呢？可以看到 a 和 b 通过 task A 和 taskB 分别建立这个血缘关系。除了这个表的血缘关系之外还需要体现任务的血缘关系。而在图数据库中两个相同的点之间，只能有唯一的一条边，按这种方式处理前面提到的情况，是首先是 a 和 b 建立血缘关系，后面 b 则会再和 a 建立血缘关系。这样就会将出现任务信息覆盖的情况，导致整个血缘关系的不完整。结合在血缘关系处理过程中可能出现的各种情况以及它们带来的问题，我们最终选择图数据库的方式将表和任务均作为点，然后用边建立血缘关系，记录整个血缘。
以上就是本次分享的内容。本次分享主要是我们腾讯内部数据治过程遇到的问题以及处理方法。希望通过本次分享能够给在做数据治理和建设的同学一些指导，帮助大家规避一些在日常工作中可能出现的问题。