腾讯欧拉数据治理平台思考与实践

01 

欧拉平台建设思路和目标

首先简单介绍数据治理平台的建设思路。

1. 数据治理的终态

数据治理似乎成了一个人人都似懂非懂的词，甚至大有“人人要参与治理数据”的趋势，人人都知道数据治理要做啥、要做成啥，但人人都不知道数据治理啥时候能有结局。我觉得数据治理的最终目标是实现数据生产和应用的工业化。要实现数据工业化，可能会有 2 种场景案例：

• 业务流程或数据模型较为固化、存算技术选型较为单一：如传统制造业信息管理系统（如 SAP）一类，很少听他们大规模搞数据治理，我认为主要原因是业务流程和数据模型经过多年发展，形成了相对比较固化、标准的流程和模型(其实工业 4.0 也在强调从“大规模生产“转为”大规模定制“,主张灵活、快速响应多样化的定制需求，那时的工业 4.0 我想也需要类似现在互联网的数据治理平台)。

• 基于多种技术构建系统性解决方案应对复杂多变的业务场景：互联网在过去一直高速发展，业务流程复杂多变，各种玩法层出不穷，导致数据平台很难快速响应变化的同时又能保证数据不乱，业务数据需求多样无法用单一数据库满足，又导致必须要用多种技术组件满足特定场景需求，多组件增加了技术架构的复杂性。

互联网数据治理平台需要具备 3 点核心能力才能应对这种复杂多变：高效的业务流程定制能力、高效的数据模型管理能力、统一的存算服务。

其中统一的存算服务是底座，目前头部互联网公司相对比较成熟。但前两点听起来简单，但到实际数据驱动业务的全流程中，就包含业务过程建模、数据开发建模、数据治理等一系列能力，下面主要介绍这些能力的建设思路。

欧拉数据治理的整体思路是通过平台能力+治理专项的推进来互相牵引，实现数据治理的最佳实践落地。主要有以下 4 方面措施：

需要数据规范与标准，拉齐各业务数据标准。

需要完整的全链路元数据能力，从而明确数据到底发生了什么，什么地方需要治理，提升数据的可观测性、空间感。

需要构建统一数据实体、统一数据模型、统一数据服务，做到数据生产即治理。

需要统一的治理评价体系，配合治理专项，推动和牵引治理落地。

首先，我们需要一个简单可理解的量化目标，牵引业务和治理平台双向奔赴：

欧拉中台从数据的规范、质量、安全、成本、应用 5 个维度定义了资产化的标准。基于这个指标牵引，业务的数据治理的目标就是实现数据的资产化，业务和中台就会一起去努力提升资产化率，通过运营手段，治理专项配合平台进行日常运营，修复不符合资产化率的问题。同时对于新增数据，可以通过平台来实现“生产即治理”，让数据在生产过程中就符合资产化率的要求，最终得到存量和新增数据整体的治理。稍微需要注意的是，资产化率的分子度量需要大量的元数据分析，一开始可能会让人望而生畏，但是我们要坚持 “粗略的正确好过精确的错误”，逐步迭代，一开始绝对准确不可能做到。

混乱是惯性，对抗混乱必须要创造内部驱动力、外部推动力两方面条件，欧拉内部驱动力是提升平台能力，外部推动力是依托 BG 技术战略推动治理专项落地，

从推力上来讲，主要是资产化率目标的要求、成本方面的要求和安全管理方面的要求，寻求管理层支持。从拉力的角度来看，业务方希望中台能提供资产化认证为业务的治理结果提供依据，此外也有资产共享的激励以及从集团层面出发的关于成本控制和安全管理的需求拉动数据治理的落地。

有推力跟拉力之后，数据治理需要从存量治理和新增治理两方面入手实现全部的数据治理。对存量数据，从应用、安全、规范、质量、成本这几个维度，通过治理的扫描平台追踪需要扫描哪些数据，有什么问题需要去修复；对新增数据，只需要新增数据在欧拉平台上进行建模生产，数据即符合资产化率要求。最终治理好的数据可以在统一的数据服务门户上申请应用，从而实现降低成本，保护数据安全，提升治理公信力和业务的配合度。

欧拉治理平台的解决方案从事前的数据埋点、采集，到事中进行规范化的数据规划、模型设计和管理维护，再到事后进行资产治理展示，实现了全链路的治理。

02

为了规范新增数据、治理存量数据，腾讯基于 DataOps 的理念来打造规范化的数据开发建模平台。首先看一个数仓混乱的具体 Case，如下图：

假设有一张 ODS 表，包括事件、时间、用户ID、IP、渠道、位置、页面属性等。数仓开发人员会使用这个 ODS 表加 DIM 维表（如用户的维度表或渠道维度表）构建 DWD 的明细宽表，在此之上轻度聚合生成 DWS 表，用户会基于 DWS 表产生各类 ADS 表或报表。这个过程中至少会出现三类问题：

由于表的开发者不统一，导致计算加工逻辑和口径不一致的问题。同一个“曝光次数”在 3 个 ADS 表中加和后却不相等。

有一些数据冗余、跨层依赖的问题。

用户不知道自己想要的指标从哪个表里取数。

解决方案主要以下四点，在下会详细介绍主要做法：

通过规范化维度建模、可视化建模等能力提升数据生产效率。

建设 DataOps 能力，提升数据编排过程的效率和规范性。

基于指标平台统一指标口径，半自助式配置生产 DWS、ADS 表、统一指标出口，提升数据一致性。

建设完备数据知识库或数据信息网络，形成构建统一数据地图和服务。

1. 规范化数据建模平台设计理念

使用规范的数据模型的话有三点好处：

第一，因为模型相对来讲比较规范的，它的变更也是比较规范的，因此模型质量跟开发效率得到提升，同时降低安全风险。

第二，模型比代码更容易理解，可视化模型或逻辑模型能让数据使用者轻松看清数据的关系，便于数据的理解与协作，也便于定位问题。

第三，规范的建模平台会保障数据的存储、计算效率，降低物理资源成本

从模型来讲，数据模型可以分为三个层次。

物理模型是基于具体引擎定义了数据的具体实现。

逻辑模型定义了数据或者字段之间的关系，而不区分是底层用的引擎是什么，它是定义两份数据之间的映射关系或转换关系。

概念模型定义了数据的范畴、业务域、主题域等在业务过程层面的含义和规则，通常说的数仓的分层分域就是在概念模型上的定义，此外一些树形结构或者些图结构也会被用来表达数据之间的业务流程。

只有建模的能力还不够，还需要构建一套 DataOps 的流程和平台，保障建模开发的过程是高效的，DataOps 可以分为两个层面，一是像 DevOps 一样实现生产流程的编排，包括数据的需求与协作、设计与规划、开发与建模、集成测试、环境管理、发布运维、数据治理、监控和服务与应用这些环节。二是从价值输出层面的业务流程编排，定义数据使用的业务流程，例如一份数据 Ready 后触发广告投放。目前欧拉主要的能力主要集中在生产流程编排。

2. 欧拉平台基础能力七大亮点

欧拉数据中台具备一站式建模开发、测试发布、质量运维和版本管理的基础能力。

数仓的规划和规范配置的能力，可以配置数仓业务过程，以及定义数仓规范。

开发规范，如注释规范、CR规范、资源使用规范。

治理平台化能力，欧拉数据中台可以自动扫描开发好的数据或存量导入的数据，进行问题检测，实现数据治理。

全链路的质量运维的能力。上下游依赖重跑、通知、基线控制。

Everything is code，code review 及发布管理。

历史代码、配置、模型变更可视化比对，版本管理和回滚。

可视化维度建模。

3. 治理引擎

欧拉中台的治理引擎和 DQC 是统一的一套平台，在数据开发里 DQC（Data Quality Center，数据质量中心）是很重要的一个能力，它主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控，包括对数据内容和各种元数据的监控。欧拉统一质量治理引擎在最底层会有统一的基础元数据层，包括埋点元数据、上报链路元数据、离线数仓、实时数仓、报表、指标的各种元数据，整合后有统一的特征提取层，基于元数据的基础特征（如负责人、产出时间、大小等）、离线或实时（抽样）统计特征（如数据的波动、数据的记录数等）和一些用户定义的特征构建数据画像，再上一层会有统一的规则引擎定义各种异常，第四层判定层根据事件或者根据规则来判定数据是不是发生了异常，应用层可以实现告警和治理策略推送，比如通过规则判定，发现一部分数据存在问题需要被治理，那么应用层就会推送到数据的 Owner 方进行治理。

整体来看数据治理是通过元数据及其特征制定治理方案，推动治理执行，最终反馈到资产评价体系里面实现资产健康分效果的提升，治理闭环。

统一指标 tMetric

数据开发和建模的流程重点说明了如何提升开发效率，如何挖掘治理动作，这一部分介绍如何对数仓产生的很多表实现口径收敛。我们打造了统一的 Metric Store 来提升口径一致性的问题。

1. 指标生产应用现状

现在我们有各种指标的出口，比如说报表平台、分析平台、实验平台，以及业务发布日报的平台，大家一般在数仓里进行表的开发，之后将数据导入各个平台进行二次加工，这样会导致指标的统计口径出现差别，存在建模难复用、数据可信度低等问题。因此需要打造统一的 Metric Store 来收敛口径，大家取指标或口径时都从统一的 Metric Store 来产出。达成此种目标有四方面的能力需要建设，第一是需要标准化的指标建模的能力，第二是统一的指标口径管理和口径收敛的能力，第三是具备官方的认证机制，第四是需要建设一个指标生态，使得指标平台中的指标可以实现全平台复用，从而保证口径逐步收敛。

2. 欧拉统一指标 tMetric 模型

从整体架构来看，最底层有各种来源的数据，我们在这些数据上面定义指标和口径的模型，通过可视化方法定义指标生产逻辑的聚合。定义好后，可以配置指标的物化加速，平台会由调度系统自动执行物化生成，最后由统一的 API 接口实现各个系统使用统一指标服务进行查询。

为达成这样的效果，具体来说，指标平台允许用户去注册各类数据源，允许用户在这些数据源上做数据维度建模，建好模型后就产生了逻辑宽表，在此之上可以定义指标的聚合口径。

我们把指标分为两个层次，原子指标（原子口径）指的是基于业务过程的度量值，不可以再进行拆分。派生指标，是对原子指标进行维度过滤后得到的指标。使用 API 对接下游的指标应用生态，如报表、日报等。定义好指标之后，只要一键创建指标加速，那么我们就自动物化指标的 Cube，最后可以通过指标 API 进行查询，下游的一些报表平台就可以实现指标口径的收敛。指标使用出口有 2 种形式：

通过指标API 对接各种报表、数据门户平台

基于指标口径定义生产 DWSADS 表，用于灵活的数据集分析

04

前面部分介绍了治理开发的工具和平台，但酒香也怕巷子深，用户没有及时可用的信息网络找数据、用数据的话，那后果往往又会导致数据重复做、口径继续变乱的恶性循环。欧拉数据发现期望基于元数据构建一个 Data Fabric，让用户能方便地找数据、用数据。通过自动化和增强集成、联合治理以及元数据治理等技术，构建数据的信息网络，从而寻找数据之间的关系，构建一个数据信息知识库，使用户找到想用的数据，其实核心是数据管理平台。

识别用户的意图，本质上需要构建一种关系。例如我们发现 DS 用户来寻找DAU 指标的时候，我们优先给他出 DAU 这个指标，那用户可以根据 DAU 得到它对应的数仓表是什么，可用的维度是什么，对应维度的枚举值是什么，分别表示什么含义等一连串的信息。如果只是进行全局模糊检索，那找到的结果需要逐个点进去浏览或者询问相关人员，这就避免不了有时对方直接丢一个 Wiki 或者简单使用口口相传的信息交互方式。只有建立完善的信息网络才能让大家真正容易地进行检索。

前面说明了怎么找数据、用数据、申请数据，接下来介绍腾讯内部用的比较多的数据服务的能力。之前我们数据团队向业务团队交付数据的方式是产生 ADS 表、DWS 表或者数仓表。假设有电影播放量的指标需要在终端上进行展示，就需要数据同学去实时或者离线地统计电影的播放量，统计出来之后把它导入到数据库里面，再交给业务开发的同学去写后台 Server，再跟业务平台去对接。这样流程比较长，而且当团队建制不是很全的话，就会出现责任不清晰的问题，使用欧拉做数据服务可以解决 API 生产沟通流程上成本花费高的问题。

此外我们数据服务还解决了离线数据共享的问题，用户可以申请一些数据去接出应用。这个流程简单说是数据开发人员开发好的数据可以一键在数据上配置 API，由后台自动根据用户的使用场景把数据导入到 Redis、ClickHouse、MySQL 等生成 API 进行调用，在以上过程中会自动包装监控和自动扩缩容的能力，用户可以零代码实现数据 API 化。

往期精彩推荐

▼