干货 | 携程平台化常态化数据治理之路

原创瑞强携程技术

作者简介

瑞强，携程高级大数据开发工程师，负责集团客户数据平台、数据资产管理平台的开发和数据治理的推进。

一、背景

数据的重要性不言而喻。每个数据工程师每天会产生大量数据，但这些数据占用的成本、带来的价值、质量如何，以及在保证安全的前提下是否能够更高效地使用，是每个公司在大数据发展到一定阶段后都会遇到的问题。而携程由于涉及的业务线多，数仓团队多，数据安全高效地流通也是一个治理难点。

二、治理思路

何为数据治理？数据治理和众多新兴学科一样，也有很多种定义。IBM认为，数据治理是根据企业的数据管控政策，利用组织人员、流程和技术的相互协作，使企业能够将“数据作为资产”来管理和应用。根据伯森和杜波夫的定义，数据治理是一个关注于管理信息的质量、一致性、可用性、安全性和可得性的过程。这个过程与数据的拥有和管理的职责紧密相关。

通常认为，数据治理是围绕数据资产展开的一系列工作，以服务组织各层决策为目标，是数据管理技术、过程、标准和政策的集合。

综上，数据治理离不开数据资产的沉淀，只有对数据有宏观地把控、明细地探究，才能贴合数据特性进行治理。所以要进行集团层面的数据治理，就需要集团层面的数据资产平台。携程数据资产管理平台（大禹）应运而生。携程数据治理体系的目标是可以让每一位数据生产者对各自拥有的数据进行常态化治理。而目前阶段数据治理的核心目标就是提升数据价值、提高数据质量、促进数据流通。

数据价值：首先要治理的就是低价值甚至无价值的数据，例如长期无访问、生命周期过长的数据。其次计算资源消耗较多的数据要进行归因分析，针对性优化。
数据质量：完善表的元数据信息包括责任人、数仓分层、主题、重要等级和敏感等级，配置数据质量监控，重点治理无人维护的数据。
数据流通：保障安全的前提下，提高权限审批效率，促进数据流转。

三、方案实施

3.1 元数据建设

数据治理的首要工作是搭建元数据数仓。元数据一般分为四类：技术元数据、操作元数据、管理元数据和业务元数据，分别描述了数据的物理化、处理过程、管理过程及数据定义。

技术元数据：存储相关数据，包括表的元数据、字段元数据等。
操作元数据：ETL相关数据，包括调度元数据、执行元数据、调度之间的血缘元数据等。
管理元数据：包括管理者信息、监控日志、管理日志、管理成效等。
业务元数据：包括数据标准、数据质量、数据指标、数据字典、数据代码、数据安全等。

现阶段最为丰富的数据是技术元数据和操作元数据，有了这些元数据就可以对计算/存储成本、元数据完整度、数据质量监控的覆盖率/通过率、临时表、无人维护表等进行统计分析，进而推进相关专项治理。

3.2 专项治理

3.2.1 成本治理

大多数的数据工程师关注的是需求交付，对存储、计算成本认识不足。目前集团大数据集群计算成本和存储成本比例是4：6，通过初步治理，可节约年成本数千万元。在大禹（数据资产管理平台）上可以直观地看到每个员工拥有的Hive表数、日均存储成本、日均计算成本和在完成数据治理后预计节省的年成本。

3.2.1.1 计算成本

计算成本主要来自于CPU资源的消耗，根据每个调度任务对CPU核数和时间的占用情况估算出成本。CPU的运行成本根据集群的运营情况，计为10元/1M VCS（每个CPU核占用的秒数）。

计算资源主要消耗在ETL调度和Adhoc查询，由此我们对典型低效SQL进行了归因分析。选择部分BU作为试点，针对单次消耗大于10元的高消耗调度进行优化。虽然集团内这些高消耗调度占比1%，但是占据了千万量级的年计算成本。

表1：高消耗问题归因及解决方案

对于Adhoc查询而言，1%超过30元/次，13%超过0.3元/次。仅这14%的查询就占据了超一半的算力成本。除了逻辑、业务、分区层面的优化，技术参数优化也进行全面推广。例如常见的几类MR优化：

1）合并小文件：配置Map输入合并、Map/Reduce输出合并。

2）合理控制reducer数量

参数1：hive.exec.reducers.bytes.per.reducer（默认1G）

参数2：hive.exec.reducers.max（默认为999）

reducer的计算公式为：min（参数2，总输入数据量/参数1），也可以通过设置mapred.reduce.tasks直接控制reducer个数。

3）使用相同的连接键：当对 3 张或更多表进行 join 时，如果 on 条件使用相同字段，会合并为一个 MapReduce Job。

4）SMB（sort merge bucket join）：用于两张大表进行join，但需要预先给每张大表基于join的字段建立桶。

set hive.enforce.bucketing = true; --启用桶表

set hive.optimize.bucketmapjoin = true;

set hive.optimize.bucketmapjoin.sortedmerge = true;

set hive.input.format=org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;

还有将数据倾斜的异常值打散或单独处理、启用压缩、矢量化执行等。

3.2.1.2 存储成本

存储成本重点治理长期无访问数据和用户行为数据（UBT），其次统一表存储格式为ORC，采用冷热存储、EC存储，最后清理重复的大文件和业务不再需要的数据。通过这些治理手段，新增存储需求缩减50%，占总存储的20%。

1）近30天无访问表的成本占据总存储的20%，其中99%是临时表。这些无访问表由BU内部进行确认清理，一些日志表或者集团的用户行为数据等需要长期保存的会加入白名单，没有加入白名单的表会自动删除。

2）用户行为数据之前全链路保存了三年的历史，通过逐渐缩短整个流程数据的生命周期达到缩减成本的目的。为了做到治理过程中下游无感知，将原表改为备份表再创建一个原表表名的视图，逐渐缩短视图可读的时间范围，待下游使用无异常之后可将备份表的生命周期缩短。这个优化节省了大量存储成本。

3）由于历史遗留问题，之前表的数据格式未完全统一。RCFile占比13.46%，Avro占比1.99%，压缩表占比5.4%，非结构化数据占比24.15%。所以将这些表转化为ORC格式，同时提升计算效率和存储能力。

4）将不常用但需要保存的数据进行冷存储。冷存储的成本为热存储的40%，使用EC技术可进一步压缩到20%。但是冷存储会影响查询的性能，需要根据数据的使用场景综合考虑。这个优化也节省了不小的存储成本。

3.2.2 质量规范

首先完善表的元数据信息，配置数据质量监控（DQC），其次重点治理无人维护的表和临时表。

1）完善元数据信息：

表的元数据信息

目前统计到的表和字段的元数据信息见上图，从中选取了12个重要指标作为完整性维度的统计，如下图。历史表的完整性也会按照设定的截止时间进行批量补充，同时新建正式表严格按照完整性的规范建立，否则无法创建。

2）配置DQC：原则上每个正式使用的表都需要配置DQC校验，比如保证调度完成后的数据要大于一定数量，今天和昨天的数据波动要在一定的范围，某些情境下需要主键唯一，或者自定义校验规则。校验规则分为强规则、弱规则。强规则会熔断下游，防止错误数据影响到下游的使用，对生产造成不可逆的影响。弱规则会触发邮件警告。

3）无人维护表治理：因为离职转岗等原因，有些表的责任人缺失，给下游使用造成了一些困难。我们首先将无人维护表的明细开放给各BU，推动BU补全责任人信息。后期开发了资源转移系统，离职或转岗前会将责任人名下的资源进行一键转移。

4）临时表治理：临时表数量占总表数量的比例较高，需要进行治理。我们明确了临时表的使用规范，只是作为临时使用，七天后自动删除。可以用来进行探索性分析、排障，但是不可用于报表依赖、调度依赖、数据传输。调度任务中产生的中间表需要在任务结束后删除。

3.2.3 数据流通

数据流通主要关注的是共享数据。有两个来源：跨BU合作的项目，中台提供的服务于全业务的数据比如：统一订单数据等。重点治理的是跨BU合作的项目中由于组织架构的改变、项目组变动、数据源变更等原因产生的权限外溢。

现阶段的治理考虑两个方面：既要增加BU之间的数据流通性、提高数据价值，又要及时治理权限外溢、敏感数据泄露。易用性与安全性之间的平衡存在一定挑战。为此我们上线级联审批功能。对于设置级联审批的表，其下游表的权限审批需要上游表owner共同参与，进一步加强了数据安全性。同时上线了基于密级的差异化审批流程。对于高密表从严把控，低密表则尽量简化审批流程，方便数据快速流通。

四、平台化与常态化

数据资产管理平台目前有三大功能模块，分别是资产盘点、治理工具、健康分析。三个模块的关系如下图所示：