一、前言

携程度假包含跟团游、自由行、玩乐、门票、用车等十多条业务线，业务涵盖线上预定到线下门店，业务线之间的差异性大，业务系统之间的复杂度高。为了满足业务的快速发展与创新，前期数据团队都是以小数仓的方式来快速响应需求。经历了多年的发展演变，主要面临以下几个问题：

（1）各业务线端到端重复建设浪费资源，人力配置不均衡，团队效率低；

（2）大量重复建设的模型、报表及应用，需求场景不清晰，历史包袱重；

（3）维度不统一，数据整合难度大；指标口径不一致，数据理解成本高；

本文将介绍度假数据治理项目中需求梳理与模型设计的实践经验和思考，希望能够对大家有所借鉴和帮助。

二、实践篇

数据治理的问题并不仅仅只是治理数据本身，其最终目标是提升数据价值，它是一个包括组织、制度、流程、工具的管理体系。那我们就从对组织的思考拉开度假数据治理的介绍。

2.1 如何思考数据团队效率优化的问题

为了快速响应业务的发展，前期度假数据团队保持着小数仓的组织结构，如下图所示，每个业务线配置了一定资源的数仓开发人员，通过统一的接口人与业务方对接交付所有数据需求。

这种结构的好处是比较灵活，各业务线有自己固定独立的资源池，也比较适合当时度假组织架构快速变化的大背景。坏处也是显而易见的，一方面，比如服务域、流量域，业务数据源基本都是一致的，但每个小数仓都需要重起炉灶进行端到端的重复建设，资源浪费不可避免。另一方面，由于各业务线的投入不同，相较于大业务线兵多将广，小业务线往往人力匮乏，取数工作已占据了几乎所有的时间，也无暇做一些数据沉淀和业务赋能的事情。

2019年度假的数据团队进行了合并，带着什么样的组织结构能让数据团队效率更优的思考，我们对团队内部的组织结构进行了一些调整，如下图所示。仍然保留了原先的垂直化的结构，在其下方新增了一个中台化的公共组，它所带了的价值主要有三方面：

第一，将业务基本一致的数据域放到公共组进行建设，比如之前提到的服务域、流量域。这样做的目的是直接砍掉了各业务线的重复的轮子收口统一的标准，垂直业务线不需要构建端到端的整条数据链路；而对于像订单域、商品域这些业务差异性较大的数据域，仍然放在垂直的业务线进行建设并快速响应业务的需求。

第二，由公共组整合打通各业务线的数据，沉淀统一的数据资产，比如用户域、供应商域。这样做的目的是将原先孤岛或不标准的各业务线核心数据打通，形成完整的度假的资产沉淀，这样再反哺到业务线使用，不仅更丰富了数据，又提升了复用性，对于小业务线的受益就更大了。

第三，由公共组收口数据同步和数据运维的工作。数据同步的复杂度其实并不高，特别是平台已经提供了完善的可配置的操作界面，收口的目的更多的在于由专门的同学来操作既可以有一套标准熟练可执行的规范，同时保证在度假层面ODS表的唯一性。数据运维也是如此，通过元数据、血缘、平台工具等制定出标准流程及自动规则，来赋能各业务线的运维能力。

2.2 如何通过需求梳理，理清数据治理的范围

想要做好数据治理首先要明确我们要治理的数据范围是什么，打开平台的元数据，我们会发现，度假有上万个任务、上千个报表、上百个应用，这些是否就是我们所要寻找的范围？我们就通过需求梳理来解开这个问题的答案。

2.2.1 现状盘点

面对这么多的历史积累，我们首先要对现状做一个整体的盘点，清楚的知道每个模型、每个报表、每个应用它的用途是什么，包含了哪些维度和指标，与之关联的任务和表都有哪些。如下图所示是我们针对现状盘点梳理的部分模板。如何能够高效的完成这个繁重的任务是实践中的难点，我们做法是这样的：

第一，如何分配盘点任务？我们将所有的任务、报表、应用都按照数据域划分，明确梳理的owner是谁，做到责任到人，保证团队内部对于梳理的边界划分清晰，避免存在重复梳理的情况。

第二，如何提高盘点效率？我们利用了元数据和血缘关系将模型、报表、应用的基本信息和范围统一获取到，同时通过血缘的上下游可以找到上有的数据源及下游的影响面，尽可能减少人工梳理的成本。

报表	路径	是否下线	维度	指标
流量报表	/报表路径A	否	日期	页面
转化报表	/报表路径B	需重构	日期商品 …	UV 转化率 …

2.2.2 现状收敛

俗话说上线容易下线难，过去我们一直在做加法，并没有一套清晰标准的下线流程，或许从潜意识中对下线这个词就根本不太关注，也导致了数据运维的成本极高，资源浪费的情况严重。

为了能明确数据治理的准确范围，我们需要对已盘点的现状做收敛，明确哪些可下线，哪些可合并。通过现状收敛的梳理，对模型、报表及应用都标注了收敛的类型，分为：可使用、可下线、可合并。

在度假的数据治理开展中，大部分数据域收敛比例为20%-30%，某些数据域可以达到50%以上，当然这也和一些业务线的历史包袱有关。

报表	路径	是否下线	维度	指标
商品报表	/报表路径C	是	日期商品 …	指标1 指标2 …

2.2.2.1 可下线

可下线的标准原则有以下三点：

低访问频率：报表及应用近三个月被业务方访问的总频次小于3次；
无维护责任人：责任人缺失、离职，并且没有业务方能够描述清楚其背景和口径；
报错无下游：长期报错的模型且无人报修，或者已无下游使用，这里说的下游使用包含了依赖关系和即席查询；

2.2.2.2 可合并

可合并的标准原则有以下两点：

重复建设：维度和指标相同或者有包含的关系，可以直接合并；
口径统一：原先的指标口径不一致，通过梳理进行了统一后可合并；

2.2.3 明确场景

对于很多数仓的同学来说，他们对于业务的理解是存在很大的局限性的，往往习惯于接需求与解决需求，但并没有询问需求背后到底要解决什么，更做不到举一反三。另一方面，我们的归纳也只是一种猜测，是否是真实的需求场景？没有偏差或错误？

此处就是一个大大的问号，明确场景就是要走近业务，探求数据背后的真相与本质。让数据的同学能够更多的了解业务，至少能完整的知道业务使用数据在做些什么，怎么做的，同时让更多的业务场景能够沉淀下来，也是一种对于知识体系的传承。明确场景需要清晰描述以下几点：

第一，需求场景的背景是什么，能够解决什么样的问题；

第二，需要看什么样的数据，从哪些维度，哪些指标来看；

第三，业务是如何利用需求的数据来进行分析和运营的；

第四，最终如何落地待解决问题，如何通过数据可衡量；

需求场景	维度	指标
场景：背景是什么，能够解决什么样的问题分析：如何利用数据来进行分析和运营落地：如何落地待解决问题，如何通过数据可衡量	日期商品用户 …	指标1 指标2 指标3 …

2.3 如何通过模型设计来规范治理数据？

2.3.1 数仓分层

数据仓库的分层主要解决的是数据的存储与管理，是对数据的横向管理，对于数据权限的控制以及边界的清晰定义也都有着重要的作用。其优势主要体现在以下三点：

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解数据；
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够极大降低重复计算，减少烟囱式开发；
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径，避免同一指标不同口径的情况发生；

我们对于数仓分层进行了明确的定义，共分为四层：

分层	定义说明
ODS	数据直接从生产同步过来，保留原始数据，便于定位问题
EDW	存放明细事实数据，只是做简单的数据清洗以及存放退化维度属性，不存放派生指标、衍生指标
CDM	面向数据域建模，为减少存储通常存放 EDW 的汇总数据，含具体口径的指标的明细数据也应属于该层，进一步进行维度属性退化，可以存放派生指标、衍生指标，但是不可以跨数据域存放事实、指标。如涉及用户/订单/流量等多个域的模型时不应放置在该层
ADM	面向应用建模，数据不跨应用访问，数据基于 EDW、CDM 生成，可以跨数据域存放事实

规范后的表名会明确带有所属分层的前缀，比如edw_，通过平台的元数据，就可以很方便的知道各分层的模型数量及比例情况。结合上述分层的目的，我们对四层做了一定的约束：

第一，CDM和AMD层必须基于EDW层进行加工，这就对EDW层的完整性提出了要求，数据进入数仓，必须要经过规范约束，同时做到清晰加工。

第二，指标加工必须在CDM层或以上进行加工，这就对CDM层的指标收口和复用性提出了要求，指标的加工出口必须统一，同时上层的查询优先应该走到CDM。

第三，EDW和CDM层中加工的数据不跨数据域，如果需要加工多个数据域的数据，必须在ADM层进行，比如用户域的资产沉淀。

2.3.2 划分数据域

数据域是面向业务分析，将业务过程或者维度进行抽象的集合。当你面对一个全新的业务领域时，做数据域的划分会帮助你认识全局，规划底层的整体建设。

数据域的划分主要是从纵向来管理数据，将有较强关联的数据进行概念层次的归类。如上文提到，我们的数据治理中数据域不光是用于归纳数据，同时也是项目开展的一个最细的颗粒度，项目的进度和资源的投入都是以数据域的划分来进行跟踪和分配的。

我们对于数据域的划分遵从了集团统一的定义，共分为十四个域：

数据域中文名	定义
日期	对自然日的描述信息
地理	对于国家/城市、经纬度等地理信息的描述
用户	主要指携程注册用户有关的数据集
交易	交易就是买卖双方对某一样产品或服务进行磋商谈判的一旦生意。双方以货币为没接的价值交换
资源	例如：商户、供应商、门店等
产品	产品和资源在不同 BU 间的概念可能是相反的，在数据域中的定义一般需要站在集团层面考虑概念的分类，资源更多的是指集团外部对象，产品则是指集团内部创建的对象
市场	例如：营销优惠券、引流渠道、语言站点
组织	用于维护集团、BU 等组织结构的信息
服务	例如：投诉、点评、客服
财务	例如：汇率
日志	用户行为触发的每一次操作的记录
元数据	元数据是描述数据的数据，打通了数据源、数据仓库、数据应用，记录了数据从生产到消费的全过程
系统设备	关于设备相关的维度
人事	用以存放员工类型的维度信息，或者人力资源相关的事实，比如考勤事实

2.3.3 定义统一维度

维度建模中最重要的概念是“一致性维度”，为了实现及规范，通过系统化方式来管理，提升维度表复用，减少烟囱开发。

维度的定义与维护，需要管理维度主题、维度、维度类型、维度属性与维表之间的关联关系，提供创建维度、关联维表、维护维度属性等功能，需要事先定义好维度主题，从需求中抽象出主题，有机构、产品、资源、用户、时间、设备、地理、营销、财务、元数据等一级主题，一些情况需要分出二级主题。

维度也可以近似地认为是维表主键对应的含义。维度类型，又称SCD缓慢变化维类型，有四种分类：每日快照、属性值不变（保留原始值）、属性值直接变更（重写）、拉链表，根据实际需求选择。

产品目的地对度假各业务线的数据分析而言是一个至关重要的维度，但在度假这个维度存在这二义性，跟团游产品的目的地使用的是酒店的城市维度，而邮轮产品的目的地使用的却是攻略的POI维度。

当在度假层面我们想做一些上层的数据整合应用时，比如做用户对目的地的偏好时问题就来了，两个目的地的维度的维度属性和属性值根本就不一致，没有办法将数据直接进行整合，还需要进行后续的长链路的转化加工处理。

类似的问题还有很多，所以一致性维度的作用就是为了解决维度统一的问题，使数据能够在统一维度下进行整合与分析，在度假的数据治理中，我们会在全度假的视角下进行维度的统一，对于一些像地理、组织等公共维度，我们还会做到与集团的维度保持一致。

2.3.4 构建总线矩阵

总线矩阵对于做过数仓的同学应该都很熟悉，目的就是要明确每个数据域下有哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

\业务过程一致性维度\|下单	分单	…	支付	退订
日期	1	1	1	1
渠道	1	1	1	1
用户	1	0	0	1
…	…	…	…	…

2.3.5 明确指标口径

2.3.5.1 指标梳理

指标口径的不一致使得数据使用的成本极高，经常出现口径打架、反复核对数据的问题。在数据治理中，我们将需求梳理到的所有指标进行进一步梳理，明确其口径，如果存在两个指标名称相同，但口径不一致，先判断是否是进行合并，如需要同时存在，那么在命名上必须能够区分开。

另外，如在数仓分层的约束中提到，指标口径的加工我们会约束在CDM层或以上来收口，如果指标不存在复用性，则允许在ADM层直接加工，否则，只能在CDM层进行加工，而且只能有唯一一个出口。

业务过程	指标中文名称	指标口径
下单	指标A	指标A的口径
下单	指标B	指标B的口径
下单	指标C	指标C的口径

2.3.5.2 指标管理

指标管理是借助于集团上线的指标管理工具，分为原子指标维护和派生指标维护。

原子指标：

1）选择原子指标的归属产线、业务板块、数据域、业务过程

2）选择原子指标的统计数据来源于该业务过程下的原始数据源

3）录入原子指标的英文名称、中文名称、概述

4）填写指标函数

5）系统根据指标函数自动生成原子指标的定义表达式

6）系统根据指标定义表达式以及数据源表生成原子指标SQL

派生指标：在原子指标的基础之上选择了一些维度或者修饰限定词。

另外，我们从指标的开始创建上线到最终下线，提供了审批功能，实现指标的生命周期的闭环管理，同时统计指标的派生次数和查看次数，提供产品或者开发掌握热点指标的使用情况。

三、总结

最后我们再来聚焦开头提出的几个问题，总结一下数据治理都是怎么帮我们解决的：

各业务线端到端重复建设浪费资源，人力配置不均衡，团队效率低

通过公共化的组织结构沉淀，将部分数据整合、数据资产、数据运维进行统一，减少资源浪费、人力不均衡，同时也进一步提升团队效率。

大量重复建设的模型、报表及应用，需求场景不清晰，历史包袱重

通过体系化的需求梳理，盘清现状、分清包袱，从残酷的现状里洞察并甄别那些真正业务需要的场景，以这个范围作为数据治理的起点与目标。

维度不统一，数据整合难度大；指标口径不一致，数据理解成本高

通过标准化的维度建模方法，构建统一的一致性维度，梳理并收口指标口径定义，通过指标管理工具维护及查看指标的计算口径及生产加工链路。

其实很多的实践或者是落地的产物还都是基于规范或者文档的形式，目前我们也在与携程平台、公共和其他相关事业部的同学一起推进规范标准产品化的落地，相信在不久之后，这些规范和实践经验也能够帮助更多同学收获数据治理所带来的益处。

作者介绍：

Leon Gu，携程数据仓库专家，负责度假数据中台和数据仓库等工作，专注于大数据、数据仓库、数据治理等领域。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

数据治理落地难？携程度假数据治理需求设计实践

创作场景

数据治理落地难？携程度假数据治理需求设计实践