美团酒旅数据治理实践

• 一、背景

• 1. 为什么要做数据治理

• 2. 需要治理哪些问题

• 3. 美团酒旅数据现状

• 4. 治理目标

• 二、数据治理实践

• 1. 数据治理策略

• 2. 标准化和组织保障

• 3. 技术系统

• 4. 衡量指标

• 5. 治理效果总结

• 三、未来规划

• 四、作者简介

一、背景

1. 为什么要做数据治理

随着移动互联网的兴起，线下商业活动逐渐开始向线上化发展，数据的产生速度有了极大的提升。越来越多的公司开始认识到数据的重要性，并将其打造成为公司的核心资产，从而驱动业务的发展。在数据相关的领域中，“数据治理”这个话题近两年尤为火热，很多公司特别是大型互联网公司都在做一些数据治理的规划和动作。

为什么要做数据治理？因为在数据产生、采集、加工、存储、应用到销毁的全过程中，每个环节都可能会引入各种质量、效率或安全相关的问题。在公司早期的发展阶段，这些数据问题对公司发展的影响并不是很大，公司对问题的容忍度相对也比较高。但是，随着业务的发展，公司在利用数据资产创造价值的同时，对数据质量和稳定性要求也有所提升。此外，当数据积累得越来越多，公司对数据精细化运营程度的要求也随之提高，会逐渐发现有很多问题需要治理。

2. 需要治理哪些问题

数据治理是一项需要长期被关注的复杂工程，这项工程通过建立一个满足企业需求的数据决策体系，在数据资产管理过程中行使权力、管控和决策等活动，并涉及到组织、流程、管理制度和技术体系等多个方面。一般而言，数据治理的治理内容主要包括下面几个部分：

• 质量问题：这是最重要的问题，很多公司的数据部门启动数据治理的大背景就是数据质量存在问题，比如数仓的及时性、准确性、规范性，以及数据应用指标的逻辑一致性问题等。
• 成本问题：互联网行业数据膨胀速度非常快，大型互联网公司在大数据基础设施上的成本投入占比非常高，而且随着数据量的增加，成本也将继续攀升。
• 效率问题：在数据开发和数据管理过程中都会遇到一些影响效率的问题，很多时候是靠“盲目”地堆人力在做。
• 安全问题：业务部门特别关注用户数据，一旦泄露，对业务的影响非常之大，甚至能左右整个业务的生死。
• 标准问题：当公司业务部门比较多的时候，各业务部门、开发团队的数据标准不一致，数据打通和整合过程中都会出现很多问题。

3. 美团酒旅数据现状

2014年，美团酒旅业务成为独立的业务部门，到2018年，酒旅平台已经成为国内酒旅业务重要的在线预订平台之一。业务发展速度较快，数据增长速度也很快。在2017到2018两年里，生产任务数以每年超过一倍的速度在增长，数据量以每年两倍多的速度在增长。如果不做治理的话，根据这种接近指数级的数据增长趋势来预测，未来数据生产任务的复杂性及成本负担都会变得非常之高。在2019年初，我们面临着下面五种问题：

• 数据质量问题严重：一是数据冗余严重，从数据任务增长的速度来看，新上线任务多，下线任务少，对数据表生命周期的控制较少；二是在数据建设过程中，很多应用层数据都属于“烟囱式”建设，很多指标口径没有统一的管理规范，数据一致性无法进行保证，同名不同义、同义不同名的现象频发。
• 数据成本增长过快：某些业务线大数据存储和计算资源的机器费用占比已经超过了35%，如果不加以控制，大数据成本费用只会变得越来越高。
• 数据运营效率低下：数据使用和咨询多，数据开发工程师需要花费大量时间一对一解答业务用户的各种问题。但是这种方式对于用户来说，并没有提升数据的易用性，无法有效地积累和沉淀数据知识，还降低了研发人员的工作效率。
• 数据安全缺乏控制：各业务线之间可以共用的数据比较多，而且每个业务线没有统一的数据权限管控标准。
• 开发标准规范缺失：早期为快速响应业务需求，研发人员通常采用“烟囱式”的开发模式，由于缺乏相应的开发规范约束，且数据工程师的工作思路和方式差异性都非常大，导致数据仓库内的重复数据多，规范性较差。当发生数据问题时，问题的排查难度也非常大，且耗时较长。

4. 治理目标

2019年，美团酒旅数据团队开始主动启动数据治理工作，对数据生命周期全链路进行体系化数据治理，期望保障数据的长期向好，解决数据各个链路的问题，并保持数据体系的长期稳定。具体的目标包含以下几个方面：

1. 建立数据开发全链路的标准规范，提高数据质量，通过系统化手段管理指标口径，保障数据一致性。
2. 控制大数据成本，避免大数据机器成本膨胀对业务营收带来的影响，合理控制数据的生命周期，避免数据重复建设，减少数据冗余，及时归档和清理冷数据。
3. 管理数据的使用安全，建立完善的数据安全审批流程和使用规范，确保数据被合理地使用，避免因用户数据泄露带来的安全风险和商业损失。
4. 提高数据工程师的开发和运维效率，减少他们数据运营时间的投入，提高数据运营的自动化和系统化程度。

二、数据治理实践

其实早在2018年以前，酒旅数据组就做过数据治理，当时只是从数仓建模、指标管理和应用上单点做了优化和流程规范。之后，基于上面提到的五个问题，我们又做了一个体系化的数据治理工作。下面将介绍一下美团酒旅数据团队在数据治理各个方向上的具体实践。

1. 数据治理策略

数据治理方案需要覆盖数据生命周期的全链路，我们把数据治理的内容划分为几大部分：组织、标准规范、技术、衡量指标。整体数据治理的实现路径是以标准化的规范和组织保障为前提，通过做技术体系整体保证数据治理策略的实现。同时，搭建数据治理的衡量体系，随时观测和监控数据治理的效果，保障数据治理长期向好的方向发展。

2. 标准化和组织保障

我们制定了一个全链路的数据标准，从数据采集、数仓开发、指标管理到数据生命周期管理，全链路建立标准，在标准化建立过程中联合组建了业务部门的数据管理委员会。

2.1 标准化

数据标准化包括三个方面：一是标准制定；二是标准执行；三是在标准制定和执行过程中的组织保障，比如怎么让标准能在数据技术部门、业务部门和相关商业分析部门达成统一。

从标准制定上，我们制定了一套覆盖数据生产到使用全链路的数据标准方法，从数据采集、数仓开发、指标管理到数据生命周期管理都建立了相应环节的标准化的研发规范，数据从接入到消亡整个生命周期全部实现了标准化。

2.2 组织保障

根据美团数据管理分散的现状，专门建立一个职能全面的治理组织去监督执行数据治理工作的成本有点太高，在推动和执行上，阻力也会比较大。所以，在组织保障上，我们建立了委员会机制，通过联合业务部门和技术部门中与数据最相关的团队成立了数据管理委员会，再通过委员会去推动相关各方去协同数据治理的相关工作。

业务部门的数据接口团队是数据产品组，数据技术体系是由数据开发组负责建设，所以我们以这两个团队作为核心建立了业务数据管理委员会，并由这两个团队负责联合业务部门和技术部门的相关团队，一起完成数据治理各个环节工作和流程的保障。组织中各个团队的职责分工如下：

数据管理委员会：负责数据治理策略、目标、流程和标准的制定，并推动所有相关团队达成认知一致。业务数据产品组：负责数据标准、需求对接流程、指标统一管理、数据安全控制以及业务方各部门的协调推动工作。技术数据开发组：负责数据仓库、数据产品、数据质量、数据安全和数据工具的技术实现，以及技术团队各个部门的协调推动工作。

3. 技术系统

数据治理涉及的范围非常广，需要协作的团队也很多，除了需要通过组织和流程来保障治理行动正常开展，我们也考虑通过技术系统化和自动化的方式进一步提效，让系统代替人工。下面我们将从数据质量、数据成本、数据安全和运营效率等几个方向，来逐一介绍技术实现方案。

3.1 数据质量

数据质量是影响数据价值最重要的因素，高质量的数据给带来准确的数据分析，错误的数据会把业务引导到错误的方向。数据质量涉及范围较广，在数据链路的每一个环节都有可能出现数据质量问题，酒旅业务现阶段的主要质量问题包括：

• 数仓规范性差，数仓架构无统一的强制规范执行约束，数仓历史冗余数据严重。
• 应用层数据属于“烟囱式”建设，指标在多个任务中生产，无法保证数据的一致性。
• 数据下游应用的数据使用无法把控，数据准确较差，接口稳定性无法得到保障。
• 业务方对多个数据产品的指标逻辑无统一的定义，各个产品中数据不能直接对标。

数据组的治理数据质量方案覆盖了数据生命周期的各个环节，下面将介绍一下整体的技术架构。

• 统一数仓规范建模（One Model）：通过统一数仓规范建模系统化保障数仓规范执行，做到业务数仓规范标准化，并及时监控和删除重复和过期的数据。
• 统一指标逻辑管理（One Logic）：通过业务内统一的指标定义和使用，并系统化管理指标逻辑，数据应用层的数据指标逻辑都从指标管理系统中获取，保障所有产品中的指标逻辑一致。
• 统一数据服务（One Service）：通过建设统一的数据服务接口层，解耦数据逻辑和接口服务，当数据逻辑发生变化后不影响接口数据准确性，同时监控接口的调用，掌握数据的使用情况。
• 统一用户产品入口（One Portal）：分用户整合数据产品入口，使同一场景下数据逻辑和使用方式相同，用户没有数据不一致的困惑。

3.1.1 统一数仓规范建模（One Model）

在业务发展初期，数据团队集中精力在快速建设数仓来支持业务，数仓建模规范疏于管理。随着业务的发展，数仓中的数据急剧增多，数据产品和下游应用快速增加，数据工程师和数据使用方也变得越来越多，数仓的问题日益突显。业务数据仓库从初期发展到现在主要暴露了3方面的问题：

• 数据规范性较差，不同时间的数仓规范不同，数仓规范的执行审核需要较多的人力。
• 数据不一致问题多，同一指标在多个ETL中生产，数据更新同步也不及时。
• 历史数据冗余严重，数据存储方式较多，业务方查询不知道该用哪个数据。

数据团队主要通过数仓规范化制定、数仓分层架构和数仓规范化系统来解决上述问题，下面是我们的具体解决方案。

制定标准-数仓规范

做好数仓规范化最基本的前提是要制定一系列标准化的规范，并推动组内同学执行。标准化的适用性、全面性和可执行性直接影响到规范的执行效果。数仓规范主要从3个方面制定数据标准化：

• 数仓建模规范，数仓建设最基础的规范，包括分层、命名、码值、指标定义、分层依赖等维度。
• 主数据管理规范，数仓各个主题的数据只有一份，团队共建复用，不能重复开发。
• 数据使用规范，在查询数据时优先查询主题层，不再提供明细层和ODS层的查询访问入口。

工具保障-数仓规范化开发系统-Dataman

在执行数据规范化的过程中，我们发现团队中每个人对规范的理解不一致，很可能造成数据规范不统一，审核人在审核上线任务时需要考虑规范的全部规则，审批需要投入的人力较多。在这样的流程下，数据规范性无法从根源上进行控制，因此需要建设数据规范化的工具，通过系统保障规范的一致性。数据组使用的数据层规范化工具-Dataman，主要包括3个功能模块：标准化规范、配置化开发和规则化验证。

• 标准化规范：制定业务数据仓库的标准规范并配置在系统中，包括架构分层、字段管理、词根管理、公共维度和码值管理等，在ETL开发时通过统一的数仓规范开发，通过配置化实现数仓的命名、分层和码值，保障数仓长期的规范性。

• 配置化开发：系统化保障工程师在开发ETL过程中遵守数仓规范，Dataman可以用配置化的方式生成XT任务模板，模板中包含数据模型的基础信息，研发同学只需要在任务模板中开发数据生产逻辑。

• 规则化验证：跟进数据仓库底层元数据和标准化配置信息，定期扫描数仓的规范性情况，判断出不符合数仓规范的任务和高相似度的数据表。

3.1.2 统一指标逻辑管理（One Logic）

业务使用数据的第一步是搭建业务指标体系，业务的目标和策略的执行情况需要通过指标来分析，指标体系的合理性和指标数据的质量直接影响到业务决策，指标的重要性不言而喻。我们通过系统化地管理数据指标，从根源上解决指标口径一致性问题，主要从以下3个方向入手：

• 指标定义规范化
• 指标管理系统化
• 数据查询智能化

指标定义规范化

此处主要从指标的生成和管理上做好规范，确保业务同学和研发人员对指标体系管理的认知一致，确保指标的新建、更改和使用都按照规范执行。我们通过下面2个方向来实现指标定义的规范统一。

• 业务指标体系的规范化：我们在业务线内统一了指标体系规范，指标分为原子指标、计算指标和复合指标，通过使用这3类指标支持业务的数据分析需求，业务未来新增指标也要按照这个标准分类。
• 指标的管理规范化：我们与商业分析团队一起梳理业务指标逻辑标准和录入流程，通过制定指标的新增和变更规范SOP，解决由指标管理流程引起的质量问题，使得指标定义、系统录入、指标认证和使用各个环节都有严格的流程管控，经由业务侧数据产品经理、业务侧数据治理数据管理员和数据工程师共同审批，确保标准规范的落地执行。

指标管理系统化

物理数据表管理：数据表管理的信息主要包括表的基础元数据信息、表类型（维表或事实表）、表的推荐度、描述信息和样例数据等。数据表管理主要是面向数据开发同学，通过维护数据表信息，为数据模型和指标管理提供数据基础支持。

数据模型管理：是对物理数据表的模型构建，通过一个物理模型可以查询到指标和相关的维度数据。数据模型可以是星型模型或宽表，星型模型中维护多个数据表的关联方式、关联字段、维度表包含字段和模型的ER图等信息。

指标管理：主要包括2部分的内容，指标的业务信息和技术信息。

• 业务信息：为了保障业务的指标信息准确且统一，指标的业务信息需要数据产品经理与商业分析团队讨论确定后录入，录入后需要指标所属数据主题的负责人审批后才能上线。
• 技术信息：技术信息主要包括指标对应的物理模型以及指标的计算逻辑，技术信息的填写需要数据工程师配置。技术信息配置后会在系统里生成技术元数据，指标管理系统通过技术元数据生成数据查询语句，提供给下游应用。

指标查询智能化

在指标管理系统中创建指标时，我们系统化管理了指标与数仓物理模型的关联关系和取数逻辑，通过数据物理模型获得指标对应的字段和可以关联的维度，以此把指标解析为数据查询SQL语句，通过数据查询引擎执行生产的SQL，智能化获得指标数据。

在查询解析过程中，经常出现指标绑定了多个底层数据表的情况，此时需要我们手动的选一个物理模型作为指标生产的底层数据。但问题是，如果一个指标对应的模型太多，每次解析都需要手动指定，研发人员不确定选择哪个模型的性能最好。另外，随着物理模型的增多，大量旧的指标配置的关联模型不是最优解，就需要手动优化更改。为了解决这个问题，指标管理系统增加了智能解析模块，在选择智能模式查询时，系统会根据指标管理模型的数据量、存储性能和查询次数等信息自动选取最优的物理模型。

3.1.3 统一数据服务（One Service）

数据仓库对外提供数据的需求越来越多，除了管理层、分析师和产品运营同学使用数据产品和报表外，数据还需要提供到各个业务系统中使用。常用的提供数据的方式主要包括同步数据表、提供SQL和为下游服务开发定制化API接口等方式，但存在以下几个方面的问题：

• 数据一致性无法保障，当数据指标逻辑更改时，业务系统不能及时调整，导致不同业务系统的数据不一致。
• 数据同步到业务系统后，我们就无法管控数据的使用方式，也不能监控到数据是否被其他下游使用的情况。
• 数据开发效率比较低，数据服务稳定性比较差，数据工程师开发一个定制化API接口需要几天时间，各个接口服务单独维护，服务稳定性也比较差。

从2018年开始，数据BP中心与分析系统中心合作建设了统一数据API服务平台（Buffalo），通过开发可配置的数据接口服务平台实现数据对外的灵活提供，并实现对数据服务的下游使用及性能的可监控。统一的数据服务平台解决了几个比较关键的问题：

• 数据逻辑统一收口：数据服务接口和数据逻辑解耦，当数仓更改和数据指标逻辑变更后下游无感知。
• 数据服务的更好管控：研发同学能够了解到数据被哪些下游使用、调用了多少次和数据服务是否稳定等信息。
• 开发效率大幅提升，服务稳定性大幅提高：通过统一服务平台可以在1小时内完成一个接口的配置化开发，与此同时，接口稳定性统一运维，服务稳定性有了很好的保障。

3.1.4 统一用户产品入口（One Portal）

如果不加控制，数据产品就会建设得越来越多。酒旅业务在2018年有超过10个数据相关产品的入口，用户很难快速地找到自己想要查的数据产品和报表。不同产品面对的用户不一样，数据的使用场景和展示方式也各不相同，业务方在使用数据时不知道从哪里能看到最全面的数据产品。

此外，也存在因为适用场景不一样，导致面向不同用户的数据逻辑不同的情况，比如某些业务同学查看的GMV不包含民宿数据，但是商业分析团队要看的GMV是包含民宿数据的。为了能够让业务方能够在一个数据产品门户中找到更全面的数据，且这个产品门户中多个产品的数据逻辑是一致的，我们将数据门户按照使用用户和应用场景划分为3类：

• 决策分析使用“大圣”（美团内部的数据平台），面向管理者和商业分析团队，所有业务管理者和商业分析团队成员需要的数据都可以从大圣数据产品里查看。
• 业务数据查询使用“天狼” （美团内部的数据平台），用户主要是销售，在天狼里能查看销售所需的各种数据。
• 数据资产信息查询使用“大禹”（美团内部的数据平台），用户是研发人员和检索数据信息的业务方，在大禹数据门户里可以找到数据资产的信息，能更快地找到想要的数据，更全面地了解相关的元数据。

3.1.5 整体系统架构

整体的技术架构分为三层，从统一数据建模到统一指标逻辑、统一数据服务和统一产品入口，整体保障了数据的质量，同时配合数据管理的组织保障体系和流程规范，将整体数据质量相关的架构搭建起来。

3.2 数据运营效率

数据工程师在日常工作中的主要工作包括两大部分：数据开发和数据运营。我们在前面介绍了通过数据开发和指标管理相关的工具系统建设，开发效率得到了大幅提升。而数据运营是另一大类工作，他们的主要时间投入在数据使用咨询和数据问题答疑，大概占数据工程师日常工作5%～10%的时间。

数据工程师日常投入到运营的人力多的主要原因是信息不对称和信息检索能力弱，数据团队建设了很多数据模型和数据产品，但是用户不知道怎么快速地找到和使用这些数据，问题主要体现在下面3个方面：

• 找数难：所需要的数据有没有？在哪里能找到？
• 看不懂：数据仓库是以数据表和报表等方式提供，数据的逻辑和含义不够清晰易懂。
• 不会用：数据指标的查询逻辑是什么？多个表怎么关联使用？

3.2.1 方案思路

数据团队通过数据资产信息的系统化的方式建设易用的数据检索产品，帮助用户更快捷、更方便地找到数据，并指导用户正确地使用数据，提高数据信息的易用性，以此减少数据工程师的数据答疑和运维时间。实现策略是通过用户的问题分类，通过数据信息系统化的方式分类解答80%的问题，最后少量的问题透传到研发人员再进行人工答疑。系统化方式主要分两层，数据使用智能和数据答疑机器人。

3.2.2 数据使用指南系统

数据使用指南的定位是业务数据信息的知识白皮书，提供最新、最全、最准确的指标口径、项目指标体系、数据表用法等信息，以简洁、流畅的操作支持数据指南中的内容及时更新，降低业务方的数据答疑和数据使用成本。

数据使用指南通过把业务场景和数据使用场景打通，从业务场景分析到使用到的数据表、指标和数据产品打通，在系统中能够快速找到数据表、指标定义、数据查询SQL、指标所在数据产品等信息，一站式解决数据查找、使用和分析的全部场景。主要功能包括指标信息和数据表信息及使用。

• 指标信息：包括业务分类指标和指标的详细信息，在指标详细信息页面可以查看指标定义、指标使用场景、指标统计维度、指标对应数据表、指标所在数据产品和指标的SQL查询示例等信息，把指标信息与数据表和数据产品关联，方便用户快速根据指标信息查找到数据。
• 数据表信息及使用方式：包括数据表的基础信息、表的使用推荐度、SQL查询样例、数据更新时间和数据就绪时间等信息，帮助使用者快速定位需要的数据表和数据SQL的查询使用。

3.2.3 数据答疑机器人

用户在使用数据时，经常咨询数据工程师一些问题，比如想找的数据在哪个表？指标怎么取？业务系统的一个字段怎么在数仓里面取到？很多问题会被重复问到，每次解答都需要研发人员花费一定的时间，而通过Wiki的方式维护效果较差，于是我们考虑用自动化答疑的方式，把数据工程师在日常答疑过程中积累问题和答案，通过一定的规则匹配，当再次被问到时系统可以自动地给出解答。

使用日常答疑中积累的咨询问题和答案作为基础答疑知识库，数据答疑机器人使用美团AI平台的摩西机器人搭建，配合问题答疑的策略，实现对历史已有问题和答案通过搜索匹配后发送给用户，具体实现方式如下：

3.3 数据成本

大数据的主要成本构成有3大部分，计算资源、存储资源和日志采集资源，其中计算资源和存储占总成本超过90%，我们的数据成本治理主要是针对大数据计算和存储这两个部分。

大数据成本优化方案

• 计算资源

• 无效任务清理，通过任务生产出来数据的使用情况判断是否为无效任务，通过下线无效任务，减少任务执行使用的计算资源。
• 超长任务优化，经过任务的计算资源使用数据可以发现，某几个大任务在执行时会占用大部分的计算资源，导致其他任务执行时间变长，或者占用配置外的弹性计算资源，导致计算成本增加。数据组会统计和监控每天任务的执行情况，发现执行时间长（超过2个小时）或者占用资源多的任务会及时进行优化。
• 分散利用计算资源，数仓的夜间批处理任务使用计算资源的实际一般都集中在早晨2点到上午10点前，这就导致在一天中只有三分之一的资源被充分利用，而且这段时间内通常资源都是不够用的，需要使用平台提供的配置外弹性资源。而其他时间段的计算资源闲置，对资源有较大的浪费。为了把全天的资源都有效地利用起来，我们会把一些对就绪时间不敏感的任务（比如算法挖掘、用户标签、数据回刷等）放到10点之后，把配置的计算资源充分利用起来。
• 租户拆分和整合统一管理，提高资源池总量和资源总体的使用率。

• 存储资源

• 数仓架构优化和重构：通过统一数仓建模规范，把相似或相同模型进行整合和去重，确保每个主题数据只保留一份。
• 数据存储压缩：在数据仓库建设初期，很多Hive表的存储格式是txt，通过压缩为ORC格式可以减少大量的存储空间。
• 冷数据处理：把数据分为冷、热两大类数据，通过每天对全部数仓表扫描识别出冷数据，发给数据负责人及时处理。
• 数据生命周期控制：按照数仓分层的应用场景配置数据的生命周期，明细数仓层保留的全部历史数据，主题层保留5年数据，应用层保留1～3年数据。通过数据生命周期控制，极大地减少了数据存储成本。

• 日志采集资源

• 下线冷数据的上游日志数据收集任务，数据收集费用主要来自两类数据，业务系统数据库的Log同步和后台日志数据收集，通过对收集数据的使用情况监控，及时下线下游无应用的数据收集任务。

3.4 数据安全

数据资产对业务来说既是价值，也是风险。数据安全作为业务部门“事关生死”的核心工作，在技术架构上会从数据产生到数据应用各个环节进行控制，保障数据应用事前有控制、事中有监控和事后有审计。数据安全控制从业务系统开始对用户高敏感数据加密，在数仓进行分级和脱敏，在应用层做密文数据权限和密钥权限的双重保障，管控用户相关的高敏感数据，按照三层系统控制加五个使用原则实现如下：

4. 衡量指标

业务部门在业务发展初级就会建立指标体系，并使用数据指标对各个业务过程做精细化的分析，衡量业务目标的达成情况和行动的执行程度。数据治理也需要一套成熟稳定的衡量指标体系，对数据体系做到长期、稳定和可量化的衡量。我们通过制定体系化的数据衡量指标体系，来及时监测数据治理过程中哪些部分做的好，哪些部分还有问题。

4.1 衡量指标建设

为了能够不重不漏地把指标都建立起来，我们从2个方面进行考虑：

• 技术分类，按照数据团队关注的问题和目标，把数据治理的指标体系分成质量、成本、安全、易用性和效率这5大类。
• 数据流环节，分别从数据的采集、生产、存储、指标管理、应用和销毁等环节监控关注的指标。

4.2 衡量指标保障数据治理

根据PDCA原则，将数据治理作为日常的运营项目做起来，底层依赖数据指标体系进行监控，之上从发现问题到提出优化方案，然后跟进处理，再到日常监控，构成一个完整的循环。

5. 治理效果总结

数据治理覆盖了数据生命周期全链路，通过围绕数据从产生到价值消亡全部生命周期，建立数据治理组织、制定治理衡量体系和建设治理技术系统来达到数据治理目标。经过体系化的数据治理，数据系统的治理、成本、安全和运营效率都有了比较大的改善。

• 数据质量：技术架构优化后，通过标准化规范和系统保障数据的准确性，并在治理过程中清除和整合了历史冗余数据，数据质量问题有很大的改善。2019年数据生产任务的增长率比2018年减少了60%左右。
• 数据成本：经过数据成本优化后，在支持2019年酒旅业务高速增长的同时，大数据的单均成本费用降低了40%左右。
• 数据安全：通过业务系统数据加密和数据仓库数据脱敏，双重保障高敏感数据安全，避免数据泄露。通过数据安全规范和数据敏感性的宣导，加强业务同学的数据安全意识，业务没有严重数据安全问题的发生。
• 运营效率：运营工具化减少了研发同学超过60%的日常答疑时间，极大地减少了研发同学工作被打扰的次数，提高了开发效率。

三、未来规划

数据治理分为三个大阶段：被动治理、主动治理、自动治理。

• 第一阶段我们做的是被动治理，也就是阶段性治理，确少统筹考虑，主要是基于单个问题的治理，而且治理之后过一段时间可能还要做重复治理。这个阶段更多是人治，一个项目成立，协调几个人按照项目制完成，没有体系规划，也没有组织保障。
• 第二阶段是主动治理，有长期的统筹规划，能覆盖到数据生命周期的各个链路，在治理过程中把一些手段和经验流程化、标准化、系统化，长期解决一些数据问题，让数据治理长期可控。
• 第三阶段是自动治理，也是智能治理，在长期规划和数据生命周期各环节链路确定好之后，把已经有的经验、流程和标准做成策略。一旦出现问题，自动监控，通过一些系统化的方式解决。自动治理的第一步还是治理方案的落地和策略化，这非常依赖于元数据，把数据治理各个过程中的一些经验技术都沉淀起来。做完策略沉淀之后做自动化，把策略用工具的方式实现，当系统发现数据有问题时，自动就去处理。

目前，美团酒旅业务数据治理处在第二阶段和第三阶段之间，虽然有整体治理计划、技术架构和组织保障，但仍需要投入一定的人力去做。未来，数据治理会继续朝着智能化的方向进行探索，真正把自动化治理工作做得更好。

四、作者简介

• 建舒，2015年加入美团，数据科学与平台部数据工程师。
• 王磊，2017年加入美团，数据科学与平台部数据工程师。
• 罗茜，2017年加入美团，数据科学与平台部数据产品经理。