数仓模式拖后腿，我们设计了可借鉴的数据治理模型

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

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

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

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

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

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

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

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

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

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

1） 现状盘点

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

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

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

2）现状收敛

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

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

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

① 可下线

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

②可合并

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

③ 明确场景

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

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

• 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解数据；

• 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够极大降低重复计算，减少烟囱式开发；

• 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径，避免同一指标不同口径的情况发生。

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

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

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

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

2） 划分数据域

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

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

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

3）定义统一维度

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

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

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

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

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

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

4） 构建总线矩阵

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