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

一、背景

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

二、治理思路

何为数据治理？数据治理和众多新兴学科一样，也有很多种定义。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 共同参与，进一步加强了数据安全性。同时上线了基于密级的差异化审批流程。对于高密表从严把控，低密表则尽量简化审批流程，方便数据快速流通。

四、平台化与常态化

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

其中资产盘点主要是资产数据看板，包含集团、BU 组织和个人的资产概览，成本分析，质量和数据共享相关指标。

第二个模块是数据治理。数据属主可以在“我的工作台”对有问题的数据进行便捷地治理。需要治理的数据都会以问题标签的形式进行分类展示。

第三个模块是数据健康分析。分为资源利用、管理规范、成果交付、数据安全四个维度对数据的健康状态进行统计。BU 内部想要提质降本、提高开发效率，健康分会是一个最直观的指标。如果有 BU 疏于数据治理，那么相应的健康分和 BU 之间的排名就会下降，以此来促进常态化治理。下图为数据健康分总览。

资源利用：考察近 7 天 CPU 离散系数、高消耗调度成本系数及近 45 天无访问表成本占比。

资源利用健康分

管理规范：考察表的元数据（数仓分层、责任人、重要等级、基线、敏感等级和主题等）完整性。

管理规范健康分

成果交付：考察失败调度占比和查询时长。

成果交付健康分

数据安全：重点考察对敏感数据的使用是否存在风险。

五、总结

数据治理是一个比较宽泛的概念，每个公司需要治理的数据不一样，并且同一公司不同的发展阶段治理的内容也不一样。需要决策层根据数据体系发展的阶段确定本阶段治理的核心目标，以此来展开治理。

现阶段我们针对数据的成本、质量、流通三个维度的重点问题进行了治理。下阶段将会有更高的治理要求。同时由于数据在不断产生，治理也不是一劳永逸的，所以借助平台让每个数据生产者可以便捷地进行常态化治理是必经之路。

本文转载自：携程技术中心（ID：ctriptech）

原文链接：干货 | 携程平台化常态化数据治理之路