美团酒旅数据治理实践
The following article is from DataFunTalk Author 李建舒
正文开始
导读：本文主要介绍美团酒旅数据治理的历程和实践经验，以及业务发展各个阶段中数据体系遇到的问题和解决方案。最后，将探讨数据治理在现阶段的建设思路和发展方向。
数据治理这个话题这两年非常火热，很多公司尤其大型互联网公司都在做一些数据治理的规划和动作。为什么大家都要做数据治理？我个人的理解是，从数据产生、采集、生产、存储、应用到销毁的全过程中，可能在各环节中引入各种问题。初始发展阶段，这些数据问题对我们的影响不大，大家对问题的容忍度比较高。但是，随着业务发展数据质量和稳定性要求提升，并且数据积累得越来越多，我们对一些数据的精细化要求也越来越高，就会逐渐发现有很多问题需要治理。数据开发过程中会不断引入一些问题，而数据治理就是要不断消除引入的问题，以高质量、高可用、高安全的方式为业务提供数据。
数据治理过程中哪些问题需要治理？总结了有五大类问题。
质量问题，是最重要的问题，很多公司数据部门或者业务线组做数据治理的一个大背景就是数据质量存在很多问题，比如数仓的及时性、准确性、一致性、规范性和数据应用指标的逻辑一致性问题。
成本问题，互联网行业数据膨胀速度非常快，大型互联网公司在大数据基础设施上的成本投入占比非常高，而且随着数据量的增加成本也将继续攀升。
安全问题，尤其是业务特别关注的用户类数据，一旦泄露，对业务的影响非常大，甚至能影响整个业务的生死。
标准化问题，当公司业务部门比较多的时候，各业务部门、开发团队的数据标准不一致，在数据打通和整合过程中会出现很多问题。
效率问题，在数据开发和数据管理过程中都会遇到一些效率低的问题，很多时候是靠堆人力在做。
2. 美团酒旅数据现状
美团酒旅业务从2014年成立为独立业务部门，到2018年成为国内酒旅业务重要的在线预订平台，业务发展速度比较快，数据增长速度也非常快。2017到2018两年里，生产任务数以每年超过一倍的速度增长，数据量的增长速度每年两倍多。如果不做治理，按指数级增长趋势，未来数据生产任务的复杂性还是成本负担都非常大。
针对我们当时面临的情况，总结了五大类问题：
标准化的规范缺失，开始建设的时候业务发展非常快，但多个业务线之间的标准化和规范化建设都只是以规范文档的形式存在，每个人的理解不一致，导致多个研发同学开发出来的数据标准就很难达到一致。
数据质量问题比较多，突出在几个方面，第一个是数据冗余很多，从数据任务增长的速度来看，新上线人多，下线任务少，数据表的生命周期控制较少。第二个是在数据建设过程中很多应用层数据都是烟囱式建设，很多指标口径没有统一的管理规范，数据一致性无法保证。
成本增长非常快，在某些业务线大数据存储和计算资源的机器费用占比已经超过了35%，如果不加以控制，大数据成本费用只会越来越高。
数据安全的控制，各业务线之间可以共用的数据比较多，而且每个业务线没有统一的数据权限管理。
数据管理和运维效率低，数据使用和咨询多，数据RD需要花费大量时间解答业务用户的问题。
2018年以前酒旅数据组也做过数据治理，从数仓建模、指标管理和应用上做优化和流程规范，当时没有做体系化的数据治理规划。从2018年以后我们基于上面提到的五个问题，我们做了一个整体的数据治理策略。
我们把数据治理的内容划分为几大部分：组织、标准规范、技术、衡量指标。整体数据治理的实现路径是以标准化的规范和组织保障为前提，通过做技术体系整体保证数据治理策略的实现。同时会做数据治理的衡量体系，随时观测和监控数据治理的效果，保障数据治理长期向好发展。
1. 标准化和组织保障
每个公司在做数据治理时都会提到标准化，我们总体思路也没有太大区别。数据标准化包括三个方面：第一是标准制定，第二是标准执行，第三是在标准制定和执行过程中的组织保障，比如怎么让标准能在数据技术部门、业务部门和相关商业分析部门统一。
从标准制定上，我们制定了一个全链路的数据标准方法，从数据采集、数仓开发、指标管理到数据生命周期管理建立了很多标准，在标准化建立过程中联合组建了一个业务部门的数据管理委员会。管理委员会是一个虚拟的组织，主要组成是技术部门和业务部门，技术部门是业务数据的开发团队，业务部门是业务数据的产品团队，这两个团队作为实现的负责人，各自对接技术团队和业务团队，比如技术团队负责协调后台开发团队、大数据平台团队、数据分析系统团队等。业务则会协调商业分析、产品运营和一些业务部门。业务各个部门分别出人把数据管理委员会运行起来，为标准制定、执行提供组织保障。让大家对标准化制定能有更加统一的认知，执行过程阻力也更小，还能定期在组织内同步信息。
2. 技术体系
在执行过程中也不希望完全通过人力和组织来推动达成，总体希望以一些自动化的方式进行。下面介绍一下我们的技术体系。
① 数据质量，数据质量是数据质量中最重要的一个问题，现在数据治理的大部分问题都属于数据质量。这里有四大问题：
数据仓库的综合性比较差，虽然有一些规范文档，但更依赖个人理解去执行。
数据一致性问题多，主要表现在数据指标的管理上。指标管理以前在文档中定义指标，没有系统化的统一管理逻辑和查询逻辑。
数据应用非常多，使用数据的方式包括数据表同步、接口消息推送、OLAP引擎查询等，不能保证数据应用端的数据一致性。
产品非常多，业务数据产品入口有十多个，没有统一的入口，也没有人对这些产品统一把关，导致数据应用和使用方式有很多分歧。
我们的技术实现方式是为了解决上面这四大类质量问题，首先在数据仓库规范性上进行统一，然后统一指标逻辑，在此之上统一数据服务接口，最后在产品上统一用户产品入口。从这四大方向将常见的数据质量问题管控起来，具体技术实现方式如下。
统一数仓建模规范分三大部分实现，以前我们只有事前的一些标准化规范，大家按自己的理解去建模实现。在这个基础上增加了事中和事后两个部分，针对事中开发了系统化工具，做数仓配置化开发。事后做规则化验证。事前会有标准化文档给大家提前理解、宣贯，事中很多标准化的事项会通过配置化自动约束规范，事后会有上线时的检验和上线后每周定期检验，检验数据仓库的建模规范是否符合标准，把不符合标准的及时提示出来、及时改进。
事前的标准化规范几个方向，第一是数据仓库的设计规范，在做一个新业务或模块之前，以文档形式做一些设计规范。第二是开发规范，包括一些开发流程、代码编写规范和注释信息。
这些形成之后还想在事中以系统化的方式进行控制，保证不会因为每个人的不同理解而对数仓的规范化构成影响。这里主要包含三部分工具：
模型开发过程中的开发工具，主要控制模型的基础信息、数仓主题和分层以及ETL代码生成。
命名规范工具，针对模型、表、字段、指标建了很多一些规范化的系统实现，控制这些命名的标准化。
上线规则监控工具，上线过程中会监控一些数据规范，还有一些性能监控，有问题会及时发现。
事后会定期监控，生成报告来看每个业务线、每个组、具体每个人的数仓规范性情况。
对于具体的实现方案，我举一个简单的例子，一个数仓开发配置化的命名规范工具。我们工具的实质还是从规范化、标准化再到工具化，所以在前期做了一些规范化、标准化，在通过工具化把标准化和规范化通过系统实现，有了工具之后，比如人在数仓时，都会统一按相同的方式来命名，即便在几千个ETL里都有这个字段也能非常快地进行定位。命名工具和数仓建模ETL工具也进行了打通，命名审核通过后，直接点击就能在ETL工具的平台中生成一段代码，只需要将查询逻辑补充进去就可以了。这样就达到了控制数仓命名规范的目的。
统一指标管理系统
指标在数仓中非常重要，所有数据应用都是以指标方式使用的。指标管理系统化主要做了流程管理标准化、指标定义标准化和指标使用标准化。系统化分三层，第一层是物理表管理，第二层是模型管理，第三层是指标管理，这些信息在元数据管理中统一进行。
统一规范只是指标管理的第一步，除了指标管理外，所有数据应用还能通过这个工具查询数据。具体做法，一个应用无非要查询两种数据，一是维度，二是指标。在查询指标时，可能会有一些维度限制条件。在指标管理模块中通过指定指标定位到数仓模型，了解指标的获取方式（是sum还是count等）。相应的数仓模型可是能是星型模型、宽表、循环模型，从模型中解析出对应的底层物理表。解析后，结合指标、维度和筛选条件，经过不同的存储引擎，解析成不同的查询语句。这样控制好数据指标管理之后，数据应用可以通过指标管理模块获得一致性的解析。
统一数据服务
我们的数据被很多下游系统使用，比如数据产品、业务系统、运营系统、管理系统等。有些下游既需要我们提供数据表，还要提供接口，但数据组开发和维护后台接口难度较大，而且接口提供后很难把控数据的用途。所以我们做了一个统一的数据服务平台。平台目标是提高效率、提高数据准确性、提供数据监控、将整个数据仓库和数据应用链路打通。提供的方式有两种，一种是对于B端应用，提供按需使用，每天提供几万次的调用额度；一种是对于C端，通过推送的方式，比如每天推送一次最新数据。以推和拉两种方式保证服务功能的全面性，具体实现，大家可以参考下图：
分为几大层次：
导入层。
存储层，数据根据不同的使用场景会有很多种不同的存储方式，比如根据条件查询一条数据的情况KV最合适，一些对定性条件要求很高的简单汇总用MySQL，一些数据量非常大但频率低的用OLAP引擎。
服务层，对存储引擎查询进行一些封装。
控制层，进行权限管理、参数校验和业务资源隔离。
接口层，提供不同的查询方式，如聚合查询、KV查询、详情查询和分组查询。
统一用户产品入口
因为数据入口非常多，我们又做了一个数据入口的统一，分成三大类：
管理者和商业分析使用的分析决策产品
业务销售运营用的业务销售数据产品
数据资产管理产品
通过这种方式，某一类用户只需要在一类入口里访问一类产品，不会出现同一类产品中的数据不一致。我们又通过数据仓库的统一建模、数据指标管理保证了三大类底层数据集市的一致，从而保证了所有数据的一致性。
整体的技术架构分为三层，从统一数据建模到统一指标逻辑、统一数据服务和统一产品入口，整体保障了数据的质量，同时配合数据管理的组织保障体系和流程规范，将整体数据质量相关的架构搭建起来。
② 数据运营效率
作为数据提供方，我们有很多数据资产，但数据使用方能不能快速找到、找到怎么用、有哪些数据，有三大类问题：
找不到，不知道数据有没有、在哪里。
看不懂，有很多业务方不是技术研发团队的，看不懂数据到底什么含义、怎么关联查询、来源于哪个业务系统。
不会用，如何写SQL或者哪些产品里面能查询到自己想要的数据指标。
基于此有三大目标：找得到、看得懂、用得对。为了提效，我们选用一些智能化系统代替人工。对于运营相关的数据问题，先提供系统化的数据指南。该指南包含三大类信息：指标类、数仓模型、推荐使用方式。这个方式能解决可能60%的问题，剩下的40%再通过答疑机器人，用一些机器的方式替人回答问题，这又能解决其中60%的问题。最后还有一些还是没找到的，落到人工答疑环节就非常少了，通过自动化把需要人工做的事情降到原来的20%以下。
美团业务的数据成本也很大，每一年的数据存储、计算相关的成本增长非常快。美团目前大概的比例是70%的计算成本、20%是存储成本、10%为采集日志。针对这三大类，我们也分别做了一些数据成本治理的方案。
针对计算类，主要做了如下事情：
无效任务治理
超长任务优化
提高资源满用率
资源统一管理
针对存储类：
冷数据治理
重复数据治理
数据生命周期管理
存储格式压缩
日志采集类：
日志下游应用监控
日志上报方式优化
无效埋点优化
整体的方案策略方面做了精细化拆分，比如按租户（每个业务线的用户）来看，租户下有队列，队列有离线、有实时。队列下面有计算、存储、采集，计算之中又分离线、实时，有些配置量、使用量。这样可以非常容易地定位到哪些租户、哪些数仓是有问题的，对应快速治理。
这方面也做了很多系统化的事情，比如有一个数据冗余判断的逻辑，每次做完数仓建模之后，会做冗余判断。元数据生成之后进行预处理，根据现有的数据做预判，看是否已存在。通过配置的对比逻辑，如果认为数据重复，会做标记并每周推送到数据治理的看板上，及时将冗余数据治理掉。
④ 数据安全
数据安全我们是以事前预防、事中监控、事后追踪三个方式来进行的。实践经验上，通过三层系统控制加五个使用原则实现。从数据产生的源头业务系统里就会将一些非常敏感的用户数据加密，数据仓库层会对各分层的数据进行脱敏和二次加密，第三层专门做一些数据审计，在数据使用全流程中提供信息提示和审计报告。
数据使用过程中应当遵循的五个原则：
密文处置原则，所有高敏感的数据都要密文传输。
最晚解密原则，在应用层产品使用的话，不要在数据仓库层解密。
最小范围提取原则，如果只用一万条数据只能对一万条数据解密。
最小授权原则，用多少给多少。
全程审计原则，从系统流出到使用全过程都是有措施保障。
3. 衡量指标
未来能够全面的衡量数仓治理的效果，我们新建了数据衡量指标体系，总体分为五大类：质量类、成本类、安全、易用性和价值。在监控方式上分为日常监控和定期监控（周、月、季度监控），让我们知道整体数据治理是整体向好、平稳还是向坏的。
总体来说，数据治理分为三个大阶段：被动治理、主动治理、自动治理。
第二阶段是主动治理，有长期的统筹规划，能覆盖到数据生命周期的各个链路，在治理过程中把一些手段和经验流程化、标准化、系统化，长期解决一些数据问题，让数据治理长期可控。
第三阶段是自动治理，也是智能治理，希望长期规划和数据生命周期个环节链路确定好之后，把已经有的经验、流程和标准做成策略。一旦出现问题，自动监控，通过一些系统化的方式解决。自动治理的第一步还是治理方案的落地和策略化，这就非常依赖于元数据，把数据治理各个过程中的一些经验技术都沉淀起来。做完策略沉淀之后做自动化，把策略用工具的方式实现，当系统发现数据有问题时，自动去处理。
现在酒旅的数据治理还在第二阶段和第三阶段之间，虽然有整体治理计划、技术架构和组织保障，但还需要投入很多人力去做。之后，酒旅数据也会继续朝着智能化的方向做，把自动化治理做好。
右下角分享、点赞、在看，三连、三连