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

作者简介

 

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

一、前言

 

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

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

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

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

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

 

二、实践篇

 

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

 

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

 

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

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

 

 

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

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

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

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

 

 

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

 

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

 

2.2.1 现状盘点

 

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

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

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

 

报表	路径	是否下线	维度	指标
流量报表	/报表路径A	否	日期 页面 …	PV UV …
转化报表