数据治理实践

数据治理实践

导读：

本文主要介绍数据治理的历程和实践经验，以及业务发展各个阶段中

数据体系遇到的问题和解决方案。最后，将探讨数据治理在现阶段的建设思

路和发展方向。

一、背景介绍

数据治理这个话题这两年非常火热，很多公司尤其大型互联网公司都

在做一些数据治理的规划和动作。为什么大家都要做数据治理？我个人的

理解是，从数据产生、采集、生产、存储、应用到销毁的全过程中，可能在

各环节中引入各种问题。初始发展阶段，这些数据问题对我们的影响不大，

大家对问题的容忍度比较高。但是，随着业务发展数据质量和稳定性要求提

升，并且数据积累得越来越多，我们对一些数据的精细化要求也越来越高，

就会逐渐发现有很多问题需要治理。数据开发过程中会不断引入一些问题,

而数据治理就是要不断消除引入的问题，以高质量、高可用、高安全的方式

为业务提供数据。

为什么要做数据治理?

数据开发

产生问题

1.需要治理哪些问题

数据治理过程中哪些问题需要治理？总结了有五大类问题。

需要治理哪些问题?

数据常见问题

•数据质量

•标准规范

•成本控制

•数据安全

•研发及管理效率

・质量问题，是最重要的问题，很多公司数据部门或者业务线组做数据

治理的一个大背景就是数据质量存在很多问题，比如数仓的及时性、

准确性、一致性、规范性和数据应用指标的逻辑一致性问题。

•成本问题，互联网行业数据膨胀速度非常快，大型互联网公司在大数

据基础设施上的成本投入占比非常高，而且随着数据量的增加成本也

将继续攀升。

・安全问题，尤其是业务特别关注的用户类数据，一旦泄露，对业务的

影响非常大，甚至能影响整个业务的生死。

・标准化问题，当公司业务部门比较多的时候，各业务部门、开发团队

的数据标准不一致，在数据打通和整合过程中会出现很多问题。

・效率问题，在数据开发和数据管理过程中都会遇到一些效率低的问题，

很多时候是靠堆人力在做。

2.数据现状

从2014年成立为独立业务部门，到2018年成为国内重要的在线预订

平台，业务发展速度比较快，数据增长速度也非常快。2017到2018两年

里，生产任务数以每年超过一倍的速度增长，数据量的增长速度每年两倍多。

如果不做治理，按指数级增长趋势，未来数据生产任务的复杂性还是成本负

担都非常大。

针对我们当时面临的情况，总结了五大类问题：

•标准化的规范缺失，开始建设的时候业务发展非常快，但多个业务线

之间的标准化和规范化建设都只是以规范文档的形式存在，每个人的

理解不一致，导致多个研发同学开发出来的数据标准就很难达到一致。

•数据质量问题比较多，突出在几个方面，第一个是数据冗余很多，从

数据任务增长的速度来看，新上线人多，下线任务少，数据表的生命

周期控制较少。第二个是在数据建设过程中很多应用层数据都是烟囱

式建设，很多指标口径没有统一的管理规范，数据一致性无法保证。

.成本增长非常快，在某些业务线大数据存储和计算资源的机器费用占

比已经超过了35%,如果不加以控制，大数据成本费用只会越来越

iWlo

・数据安全的控制，各业务线之间可以共用的数据比较多，而且每个业

务线没有统一的数据权限管理。

•数据管理和运维效率低，数据使用和咨询多，数据RD需要花费大量

时间解答业务用户的问题。

二、治理实践

2018年以前数据组也做过数据治理，从数仓建模、指标管理和应用上

做优化和流程规范，当时没有做体系化的数据治理规划。从2018年以后我

们基于上面提到的五个问题，我们做了一个整体的数据治理策略。

我们把数据治理的内容划分为几大部分：组织、标准规范、技术、衡量

指标。整体数据治理的实现路径是以标准化的规范和组织保障为前提，通过

做技术体系整体保证数据治理策略的实现。同时会做数据治理的衡量体系,

随时观测和监控数据治理的效果，保障数据治理长期向好发展。

数据治理策略

数据治理的内容数据治理的实现路径

标准化规范及组织保障

技术体系

陆a浅,■成小■支主

元数据

衡量指标

1.标准化和组织保障

每个公司在做数据治理时都会提到标准化，我们总体思路也没有太大

区别。数据标准化包括三个方面：第一是标准制定，第二是标准执行，第三

是在标准制定和执行过程中的组织保障，比如怎么让标准能在数据技术部

门、业务部门和相关商业分析部门统一。

标准化及组织保障

制定数据管理委员会

「

标准化，1

执行组织

分

后

产

业

大

商

析

台

品

务

数

业

工

开

及

销

据

分

具

发

全链路数据标准化建设运

售

析

平

中

S团

部

都

台

心

队

・数据采集部

・数仓开发

・指标管理

业务部门技术团队

•数据应用

・数据生命周期管理

从标准制定上，我们制定了一个全链路的数据标准方法，从数据采集、

数仓开发、指标管理到数据生命周期管理建立了很多标准，在标准化建立过

程中联合组建了一个业务部门的数据管理委员会。管理委员会是一个虚拟

的组织，主要组成是技术部门和业务部门，技术部门是业务数据的开发团队，

业务部门是业务数据的产品团队，这两个团队作为实现的负责人，各自对接

技术团队和业务团队，比如技术团队负责协调后台开发团队、大数据平台团

队、数据分析系统团队等。业务则会协调商业分析、产品运营和一些业务部

门。业务各个部门分别出人把数据管理委员会运行起来，为标准制定、执行

提供组织保障。让大家对标准化制定能有更加统一的认知，执行过程阻力也

更小，还能定期在组织内同步信息。

2.技术体系

在执行过程中也不希望完全通过人力和组织来推动达成，总体希望以

一些自动化的方式进行。下面介绍一下我们的技术体系。

①数据质量，数据质量是数据质量中最重要的一个问题，现在数据治理的

大部分问题都属于数据质量。这里有四大问题：

.数据仓库的综合性比较差，虽然有一些规范文档，但更依赖个人理解

去执行。

・数据一致性问题多，主要表现在数据指标的管理上。指标管理以前在

文档中定义指标，没有系统化的统一管理逻辑和查询逻辑。

•数据应用非常多，使用数据的方式包括数据表同步、接口消息推送、

OLAP引擎查询等，不能保证数据应用端的数据一致性。

.产品非常多，业务数据产品入口有十多个，没有统一的入口，也没有

人对这些产品统一把关，导致数据应用和使用方式有很多分歧。

我们的技术实现方式是为了解决上面这四大类质量问题，首先在数据仓库

规范性上进行统一，然后统一指标逻辑，在此之上统一数据服务接口，最后

在产品上统一用户产品入口。从这四大方向将常见的数据质量问题管控起

来，具体技术实现方式如下。

数据质量

技术实现

常见问题

•数仓规范性基

­数据一致性何息多

•数据应用无法把控

•多个产品中指标逻辑不同

数仓建模规范

统一数仓建模规范分三大部分实现，以前我们只有事前的一些标准化

规范，大家按自己的理解去建模实现。在这个基础上增加了事中和事后两个

部分，针对事中开发了系统化工具，做数仓配置化开发。事后做规则化验证。

事前会有标准化文档给大家提前理解、宣贯，事中很多标准化的事项会通过

配置化自动约束规范，事后会有上线时的检验和上线后每周定期检验，检验

数据仓库的建模规范是否符合标准，把不符合标准的及时提示出来、及时改

进。

统一数仓规范建模

事中|事后

I事前II

I标」化夜范I髭般化开发|规则।化验证！

模型设计规范模型开发工具数仓规范监控

•收仓分层和主题•模里多砒信息•数仓分层

•命名、矣契、词根•抬仓主愿和分层•敬搪血缘

・公共维度、关取关系•E"代码生成•数仓相似度

模能开发规范命名规则工具数仓规范报告

・开发流程

•模型命名标准化•数仓规范报告

•代码编写

・自瑞命名标用化・数相冗余报告

•注释信息

上线规则监测工具

•效仓规范性监测

•依据依赖监测

事前的标准化规范几个方向，第一是数据仓库的设计规范，在做一个新

业务或模块之前，以文档形式做一些设计规范。第二是开发规范，包括一些

开发流程、代码编写规范和注释信息。

这些形成之后还想在事中以系统化的方式进行控制，保证不会因为每

个人的不同理解而对数仓的规范化构成影响。这里主要包含三部分工具：

•模型开发过程中的开发工具，主要控制模型的基础信息、数仓主题和

分层以及ETL代码生成。

•命名规范工具，针对模型、表、字段、指标建了很多一些规范化的系

统实现，控制这些命名的标准化。

•上线规则监控工具，上线过程中会监控一些数据规范，还有一些性能

监控，有问题会及时发现。

事后会定期监控，生成报告来看每个业务线、每个组、具体每个人的数

仓规范性情况。

对于具体的实现方案，我举一个简单的例子，一个数仓开发配置化的命

名规范工具。我们工具的实质还是从规范化、标准化再到工具化，所以在前

期做了一些规范化、标准化，在通过工具化把标准化和规范化通过系统实现，

有了工具之后，比如人在数仓时，都会统一按相同的方式来命名，即便在几

千个ETL里都有这个字段也能非常快地进行定位。命名工具和数仓建模ETL

工具也进行了打通，命名审核通过后，直接点击就能在ETL工具的平台中

生成一段代码，只需要将查询逻辑补充进去就可以了。这样就达到了控制数

仓命名规范的目的。

数仓开发配置化-命名规范工具

险财：（时间周期词卜［修饰词卜字段描述词+ouj

扬康畲名概财：【闾」修饰词卜字段描述词♦［后媚/度■卜［时间周期同j

英文词根

近义同修

n丁

同电车

08英文修饰一

统一指标管理系统

指标在数仓中非常重要，所有数据应用都是以指标方式使用的。指标管

理系统化主要做了流程管理标准化、指标定义标准化和指标使用标准化。系

统化分三层，第一层是物理表管理，第二层是模型管理，第三层是指标管理,

这些信息在元数据管理中统一进行。

统一指标管理系统

1.标准化

•流程管理标准化

•指标定义标准化

•指标使用标准化

2.系统化

•指标僖息管理系统化

・查询解析系统化

・元数据管理系统化

统一规范只是指标管理的第一步，除了指标管理外，所有数据应用还能

通过这个工具查询数据。具体做法，一个应用无非要查询两种数据，一是维

度，二是指标。在查询指标时，可能会有一些维度限制条件。在指标管理模

块中通过指定指标定位到数仓模型，了解指标的获取方式（是sum还是

count等）。相应的数仓模型可是能是星型模型、宽表、循环模型，从模型

中解析出对应的底层物理表。解析后，结合指标、维度和筛选条件，经过不

同的存储引擎，解析成不同的查询语句。这样控制好数据指标管理之后，数

据应用可以通过指标管理模块获得一致性的解析。

指标一致性查询

数据应用

统一数据服务

我们的数据被很多下游系统使用，比如数据产品、业务系统、运营系统、

管理系统等。有些下游既需要我们提供数据表，还要提供接口，但数据组开

发和维护后台接口难度较大，而且接口提供后很难把控数据的用途。所以我

们做了一个统一的数据服务平台。平台目标是提高效率、提高数据准确性、

提供数据监控、将整个数据仓库和数据应用链路打通。提供的方式有两种，

一种是对于B端应用，提供按需使用，每天提供几万次的调用额度；一种

是对于C端，通过推送的方式，比如每天推送一次最新数据。以推和拉两

种方式保证服务功能的全面性，具体实现，大家可以参考下图：

统一数据服务平台

敷据应用方

的售工作台商家后台运法索烧

应用

数据服务平台-Buffalo

at-

Kii«Hj

统一依据服务平台

[

低据仓库

数据仓库

分为几大层次：

•导入层。

・存储层，数据根据不同的使用场景会有很多种不同的存储方式，比如

根据条件查询一条数据的情况KV最合适，一些对定性条件要求很高

的简单汇总用MySQL,一些数据量非常大但频率低的用OLAP引擎。

•服务层，对存储引擎查询进行一些封装。

・控制层，进行权限管理、参数校验和业务资源隔离。

・接口层，提供不同的查询方式，如聚合查询、KV查询、详情杳询和

分组查询。

统一用户产品入口

因为数据入口非常多，我们又做了一个数据入口的统一，分成三大类：

・管理者和商业分析使用的分析决策产品

・业务销售运营用的业务销售数据产品

•数据资产管理产品

通过这种方式，某一类用户只需要在一类入口里访问一类产品，不会出

现同一类产品中的数据不一致。我们又通过数据仓库的统一建模、数据指标

管理保证了三大类底层数据集市的一致，从而保证了所有数据的一致性。

统一用户产品入口

整体系统架构

整体的技术架构分为三层，从统一数据建模到统一指标逻辑、统一数据

服务和统一产品入口，整体保障了数据的质量，同时配合数据管理的组织保

障体系和流程规范，将整体数据质量相关的架构搭建起来。

整体系统架构

②数据运营效率

作为数据提供方，我们有很多数据资产，但数据使用方能不能快速找到、

找到怎么用、有哪些数据，有三大类问题：

・找不到，不知道数据有没有、在哪里。

•看不懂，有很多业务方不是技术研发团队的，看不懂数据到底什么含

义、怎么关联查询、来源于哪个业务系统。

・不会用，如何写SQL或者哪些产品里面能查询到自己想要的数据指

标。

基于此有三大目标：找得到、看得懂、用得对。为了提效，我们选用一

些智能化系统代替人工。对于运营相关的数据问题，先提供系统化的数据指

南。该指南包含三大类信息：指标类、数仓模型、推荐使用方式。这个方式

能解决可能60%的问题，剩下的40%再通过答疑机器人，用一些机器的方

式替人回答问题，这又能解决其中60%的问题。最后还有一些还是没找到

的，落到人工答疑环节就非常少了，通过自动化把需要人工做的事情降到原

来的20%以下。

数据运营效率-解决思路

用户

具体的实现方式，针对数据使用指南做了一个系统，把指标元数据、

维度元数据、数据表和各种产品元数据等管理起来。用户从入口查询能够

快速定位，支持分类检索和重点词检索，还会提供排序进行重点推荐，对

每一个主题数据分类描述。通过数据指南能解决很多问题，不能解决的就

进入答疑机器人系统，这里主要解决一些元数据里没有的问题。我们日常

通讯工具上会有问答，把这些问题和答案总结成一个知识库，进行清洗和

规则匹配。对这类问答的解析成一个问题对应一个答案，通过一些规则和

关键字匹配后存起来。之后再查的时候只输入一个问题时，根据这个解析

出来他想问的可能有几个问题，将这几个答案抛给他。

数据运营系统化

平台元数据数据问题和答疑知识库

③数据成本

业务的数据成本也很大，每一年的数据存储、计算相关的成本增长非常

快。目前大概的比例是70%的计算成本、20%是存储成本、10%为采集日

志。针对这三大类，我们也分别做了一些数据成本治理的方案。

数据成本

成本治理分类成本精细化拆分

大数据资源成本占比

无效任务治现

超长任务优化

计算

提高资源满用窣

资源统一曾理

•冷被据治理

・复数据管理

存储St

・数据生命周期管理

•存储格式压樵

日志下的应用监控

日志•

・日志上接方式优化

采集

・无效埋点优化

-HJI•存储日本采集

针对计算类，主要做了如下事情：

•无效任务治理

.超长任务优化

・提高资源满用率

・资源统一管理

针对存储类：

・冷数据治理

・重复数据治理

・数据生命周期管理

•存储格式压缩

日志采集类：

・日志下游应用监控

.日志上报方式优化

・无效埋点优化

整体的方案策略方面做了精细化拆分，比如按租户（每个业务线的用户）

来看，租户下有队列，队列有离线、有实时。队列下面有计算、存储、采集，

计算之中又分离线、实时，有些配置量、使用量。这样可以非常容易地定位

到哪些租户、哪些数仓是有问题的，对应快速治理。

这方面也做了很多系统化的事情，比如有一个数据冗余判断的逻辑，每

次做完数仓建模之后，会做冗余判断。元数据生成之后进行预处理，根据现

有的数据做预判，看是否已存在。通过配置的对比逻辑，如果认为数据重复，

会做标记并每周推送到数据治理的看板上，及时将冗余数据治理掉。

④数据安全

数据安全我们是以事前预防、事中监控、事后追踪三个方式来进行的。

实践经验上，通过三层系统控制加五个使用原则实现。从数据产生的源头业

务系统里就会将一些非常敏感的用户数据加密，数据仓库层会对各分层的

数据进行脱敏和二次加密，第三层专门做一些数据审计，在数据使用全流程

中提供信息提示和审计报告。

安全规范及系统实现

三层系统控制+五个使用原则

依据使用展

全程监控审计数据使用原则

・密文传嫡原则

・•晚寿原则

数据存储层•・小范围提取原则

分居脱壁加及

・■少授权原则

・全程审计原则

依据源头展

生成过程加史

数据使用过程中应当遵循的五个原则：

•密文处置原则，所有高敏感的数据都要密文传输。

•最晚解密原则，在应用层产品使用的话，不要在数据仓库层解密。

•最小范围提取原则，如果只用一万条数据只能对一万条数据解密。

•最小授权原则，用多少给多少。

•全程