网易内部如严选、云音乐、传媒等数据团队对数据内容体系的治理思路都是将治理规范融入到开发过程中，将治理的动作提前，这其实就是“开发治理一体化”；事后依赖数据资产健康评估和治理工具进行数据的治理，建立事前加事后的数据治理体系。

随着网易数帆商业化的发展，遇到很多金融及大型国企客户，我们发现互联网的这套数据治理的打法并不能全部适应传统行业客户的场景。我们开始向客户和竞争对手学习，为此打磨出元数据管理，数据标准，数据资产目录等子产品，沉淀出一套数据治理的产品体系。

本文主要内容包括以下四个方面：

“先设计后开发”

在软件工程中良好的设计具有不可比拟的意义，它胜于需求、编码、维护等环节，秉承设计优先的原则会让软件开发变得简单高效，可以尽量避免掉因设计失误而导致的缺陷，一个健壮的程序必然有良好的设计。

网易数帆数据中台产品的特色之一“先设计后开发”，其目标就是将 数据标准定义、指标规范定义、模型设计和数据开发体系连接在一起 ，实现 “规范即设计，设计即开发” 、以设计驱动开发，并通过流程管控卡点保障元数据的生成是按照规范落地的。在开发的过程中保障数据标准，数据质量，数据安全的落地，这就是将 开发治理一体化 ，期望能达到“事半功倍”的事前治理方案。

在没有“数据标准”产品之前我们，我们推荐客户的数据体系构建工作流包含业务和需求调研，数据架构设计，指标规范定义，数据模型设计，数据开发五个过程。

再好的规范设计都需要工具来落地和约束，否则就是一纸空文，我们认为所有需求都可以拆解为指标和维度，指标和维度组合就是模型，所以用指标管理工具和模型设计中心去承载规范设计的落地：

dwd_{业务缩写/pub}_{数据域缩写}_{业务过程缩写}_[{自定义表命名标签缩写}]_{刷新周期标识}{单分区增量全量标识}dws_{业务缩写/pub}_{数据域缩写}_{数据主粒度缩写}_[{自定义表命名标签缩写}]_{统计时间周期范围缩写}/{刷新周期标识}{单分区增量全量标识}

在模型和指标的落地过程中，通过“庖丁解牛”式的产品配置将数据模型涉及的技术元数据/业务元数据进行标准化，标准化的好处是“车同轨，书同文，大家都说普通话”。可以说我们产品从一开始就实现了开发治理一体化。

“先污染后治理”

“先污染后治理”是当前数据治理的主流方案，与其说主流不如说是无奈的选择，因为“先设计再开发”意味着重构，重构虽然是最彻底的方案但也是最难实操执行的，毕竟很多数据团队最核心要交付的是短期业务价值，重构带来需求交付效率的下降且短期无明显价值增长，也有很多数据团队就会选择边开发边进行治理的方案，我们将网易的经验和过程也在这里做一个介绍。

2.1 运动式治理

随着业务的发展，网易内部业务线的计算和存储达到瓶颈，但业务方很难判断，是应该继续扩容增加资源，还是对劣质数据进行治理来降低资源危机，但这个过程中，如何定义劣质数据，定义了劣质资源后，要怎么对其进行治理，都是亟待确定和解决的问题；另一方面，数据本身的加工链路长，数据的加工处理没有统一的标准，整个团队内到底有哪些数据，数据的负责人是谁，这些数据是通过哪些任务产出的，这些数据有没有被有效的使用，数据的存在是否有意义，这些都是管理者比较关心的问题，但数据团队都很难回答。通过运动式的专项治理我们还是沉淀出部分工具

2.2 度量体系的构建

基于元数据的建设，我们将底层的表信息、计算任务信息和任务/表之间的血缘信息，汇总为计算、存储的元数据仓库，结合内部自己的账单体系对计算和存储均进行了定价，从而将调度任务、自助查询每次执行消耗的计算成本预估出来，对于存储成本，一方面包含数据表本身的存储成本，另一方面产出该表的计算任务也会分摊该数据表的成本，最终得到数据表总的存储成本。将计算和存储成本转化为费用，更加一目了然的对治理效果进行量化评估。为了方便用户理解，我们构建了统一的健康分度量体系

基于元数据的数据治理体系

无论“先设计后开发”亦或是“先污染后治理”，都少不了过程元数据的沉淀，这样才会让治理无论在任何阶段都变得轻松可靠。在商业化实践的过程中我们逐步地吸收了传统行业一些优点，例如在21年底我们上线了数据标准、元数据管理这两款产品，同时数据标准，元数据管理、数据质量、模型设计、指标管理、安全中心等产品做了打通能完成数据标准的校验，让数据标准不再是一纸空文。

越来越多行业的实践让我们开始思考我们的数据治理体系需要升级，首先是站在数据内容体系需要明确治理的范围。

3.1 明确数据治理的范围

3.1.1仓内数据全生命周期

数据管理能力成熟度评估模型给出了数据管理能力成熟度评估模型以及相应的成熟度等级，定义了数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生存周期等8个能力域。

我们的数据治理的范围参考了DCMM模型，同时也是围绕数据的全生命周期展开的，在数据生产阶段，需要对需求进行分析，明确业务口径，对数据进行规范采集、任务开发和监控运维；在数据消费阶段，涉及到快速地查找数据，对数据的分析和对数据质量的探查；在数据管理过程中，包含权限和成本管理等。整个流程涉及到成本、标准、质量、安全和价值，各个阶段都会面临对数据的治理工作。

在具体的数据治理产品层面做了一些微调：DCMM包含有数据标准，数据质量，数据安全，数据应用（我们叫数据价值），我们在这个标准的基础上一方面完善数据标准的内容，另一方面也将成本治理加入到治理的范围内。形成五大模块：

3.1.2 仓外元数据的治理

过去很长一段时间我们将数据治理的范围定在仓内，很多公司经历了多年的建设，拥有大量独立的数据应用体系，数据架构非常复杂，也是数据治理绕不开的一道墙。尤其是在构建数据资产大盘时就需要考虑仓外元数据的管理以及一些手工元数据的管理。

为此我们研发了元数据管理模块，用于统一管理仓内和仓外元数据。它包括元数据登记、元数据注册采集、元数据存储、元数据分析等，涵盖了元数据的全链路生命周期管理。支持元数据的自动采集和调度管理，支持手工创建和变更元数据，并配合版本管理，便于用户跟踪元数据整个生命周期动态和变化。

3.2 数据治理产品的优化

3.2.1 开发治理一体化

3.2.1.1 面临的问题

从网易内部的实践来看，过重的设计不行（例如使用ERwin、power designer类似的工具交付设计ER图），无设计也不行。开发治理一体化理想很完美，大家也很认可“先设计后开发”的理念，但很多业务中也面临执行不到位。例如：业务探索期/高速发展期需要快速获取运营数据，业务方能接受的排期不会超过1周，留给数据建设的周期并不长，很多报表直接从ODS源表进行加工，为了快速上线牺牲设计，效率优先，且缺乏协作。从商业化的客户来看有数产品体系中的指标管理和模型管理还是停留在治理体系，与开发体系的元数据管理、数据传输、数据质量的联动性不足。

3.2.1.2 更完善的“先设计后开发”

很长时间内我们在规范这块缺乏能平滑地将设计、开发和治理融合的产品，直到2021年推出了数据标准；同时为了更好的流程协作管理，我们优化了流程协作与消息中心，构建能自定义的流程引擎、企业组织架构和消息通知。

“先设计后开发”核心是元数据的规范，在设计阶段就约束元数据的定义，开发阶段则通过流程管控保证规范元数据的生成，这样就能保障逻辑与物理的统一。数据标准的目标就是完成元数据规范的定义，结合指标和模型两款产品，将 数据标准规范定义、指标规范定义、模型设计和数据开发体系通过流程引擎连接在一起 ，以实现 “规范即设计，设计即开发，开发即治理” 的开发治理一体化。

指标、模型设计这块的落地方案，我在第一章已有详细的介绍，这里就不单独再介绍了。再强调一下再好的规范没有工具产品来匹配落地就是一纸空文。工具产品必须有所卡点才能保障设计和落地的一致性，需要通过流程引擎保障先设计后开发的流程、保障规范的落地。这些卡点包含：

将数据开发与数据治理结合起来既是对开发过程的管控，也是保障数据质量的有效方法。需求阶段主要对业务数据进行调研、拆解数据、确定词根、数据项以及业务指标。设计阶段基于调研的内容进行标准和指标的设计并应用于模型和质量，设计完成后进行元数据的注册并完成业务信息的录入。开发阶段根据设计阶段的规范进行数据开发、约束开发流程，通过元数据扫描完成元数据技术信息的录入，最后将元数据进行审核并发布。在数据的全生命周期内各个模块协同的案例：

开发治理一体化对于很多公司意味着数据体系的重构。在重构的过程中用流程约束元数据的生成，保证元数据的规范性。事前治理的方案对客户数据建设所处的时机要求就会比较高，虽然也可以按照数据域逐一重构迁移，整体建设周期较长，价值也不能立竿见影；但是数据体系的建设本就是数据“熵增”的过程，我们在建设中对他做功，这样熵增加的比例是在可控的范围内， 事前做功对数据治理来说事“事半功倍”的选择 。对过程做功会带来效率的降低，未来如果搭配可视化ETL和AutoETL工具就能在效率和治理上实现双丰收。

3.2.2 数据健康评估与优化工具

3.2.2.1 面临的问题

数据治理的诉求在互联网公司早期并不那么强烈，一般的关注点也只是在 成本不足、数据产出不及时、指标口径对不上、数据质量出现重大问题 的时候会发起治理专项，然后等着再污染再治理。这个阶段主要呈现出的特点是：被动式（无抓手），运动式。一套基于数据建设的健康度评估体系加优化工具就应运而生。

在网易的实践过程中我们发明了一套基于ROI的数据资产沉淀方法，我们研发了基于Hadoop的元数据分析服务，可以精准计算出每个任务消耗了多少计算，存储资源，同时打通数据生产和消费的全链路的数据血缘，按照任务引用进行下游分摊，最终可测算出每个应用（数据报表、数据API）消耗了多少资源，同时还有数据应用的使用情况（PV/UV/重要程度），可以找到没有使用却消耗很大资源的应用，同时采用“剥洋葱”式的数据下线方式，从上层数据应用开发逐层推动数据下线。依托于这套方法我们构建了基于成本、规范、质量、安全、价值的数据健康分体系。

我们希望通过”评分赛马”的机制来驱动开发同学自助完成数据治理，也取得了很多成效，严选/音乐/传媒在这套治理体系内在成本/质量/标准规范上都有显著的提升。那么这一套治理体系为什么不能在传统行业快速应用起来呢，我的理解有两点：

（1）传统行业的开发及治理方面其实更偏 “管理” ，以银行证券行业为例一方面业务层面被强监管，业务过程非常稳定，主管单位会下发国家标准，合规性非常重要；另一方面数据团队的构成上有大量的外包人员，由一个甲方领导几十个外包人员，安全和稳定是第一位的，所以管理流程是非常必要，而互联网更重视效率，所以我们的产品在管理上很松散的，也导致管理元数据的缺乏；

（2）互联网公司很多时候其实依赖的是人治，依赖数据开发同学的个人专业能力去减少后期治理的事情，就像阿里的OneData体系也只是给开发人员使用，我们也推荐“先设计后开发”的开发治理一体化。传统行业有专职数据治理团队负责治理体系，而 我们的产品缺乏为这类角色服务 ，没有符合他们使用场景的功能和流程。

3.2.2.2 更完善的事后治理体系

（1）构建数据治理的价值体系

基于数据的全生命周期，包含了成本、质量、安全、标准和价值五个方面，针对每个方面，都要建立大家认同的可量化的指标，通过指标去衡量数据治理的价值， 统一数据健康诊断的度量衡 。

对于成本，包括计算和存储成本的费用量化，对无用数据的下线治理等；对于价值，需要能够评估每个数据模型、数据报告和API的应用价值；对于质量，会包含监控任务覆盖了多少稽核规则，涵盖了多少强弱规则；对于标准规范，需要对数据标准、指标和模型进行规范度和复用性的评估；对于安全，会包含数据安全等级和数据权限的治理等内容的评估。

（2）体系化治理手段

数据治理不是一个临时性要做的工作，从数据生命周期的全过程到治理体系的健康运行，需要一个长效的治理机制来保证，体系化的数据治理。

整体通过发现问题-->解决问题-->持续运营和持续沉淀形成资产治理的闭环。

（3）强化管理属性

3.3 产品整体方案

经过上面的介绍可知我们的数据治理产品包含事前和事后两条路线。覆盖数据的全生命周期（从元数据的注册到数据应用消费），包含”先设计再开发“的事前治理、数据健康评估与优化（事后治理）这两条线，以实现建设“规范的元数据”和“好的数据”。同时在消费端将健康的资产通过业务分类和标签等方式来组织，便于普通用户在数据消费时能 “找的到、读的懂、信的过” 。

3.4 元数据数据治理满足的场景

基于逻辑数据湖的数据治理介绍

我们在调研外部用户需求的过程中，经常会碰到的问题：每个企业用户的技术建设情况不同，业务复杂度也不一，很多传统企业已有的IT系统已运行了很多年，只是无法再支持日益增长的数据需求，他们在大数据技术体系的经验几乎空白，当面对一个比如lambda架构的大数据解决方案时，往往会觉得过于复杂和难以掌握，对落地成效心存疑虑。还有部分用户的业务在现有技术框架上（比如MPP）运行良好，出于对未来发展的前瞻性考虑，需要提前进行大数据的基础技术建设，这部分用户对于大数据未来的必要性是肯定的，但是会特别关心其适用的场景、业务覆盖度以及如何平滑地进行业务的迁移。

数据湖&Hadoop解决的是数据统一汇聚的问题，而统一元数据则是解决数据连接、资产、管理的问题，对于相当部分的用户而言，当前最大的痛点不是海量数据的存储，而是如何将散落到各个子数据系统的数据孤岛统一管控起来。因此通过构建一个逻辑层面的数据湖，实现统一的元数据+分散的物理存储，避免不必要的物理数据入仓（湖），从而将产品上层功能比如主题域构建、数据地图等等及早给用户使用才是解决问题的根本之道，逻辑数据湖方案，依然可以使用物理湖&Hadoop，同时提供通过虚拟表直连数据源的方案将其他类型的数据源也纳入平台的管控中，用户可以根据实际的需要选择适合的存储方案。

我们的构建方法论主要分为如下三个大的层面：

数据源支持类型： 除了Hadoop（Hive）体系，MPP、RDMS、HTAP、KV、MQ等都需要支持，并且一视同仁，都可以作为具体逻辑数据湖具体对象的物理存储。

统一数据源 & 统一元数据： 统一数据源要做的是规范每种数据源的登记注册，包括数据源URL格式、数据源Owner、唯一性校验、账号映射、联通性校验、支持的版本、特定的参数等；统一元数据，则是将数据源的技术（物理）元信息和业务元信息进行关联，提供统一的查询修改接口。

统一数据开发、治理和查询分析： 这三个属于构建在统一元数据&数据源基础之上的应用层。统一的数据开发，包括不同物理数据源之间的交换、离线&实时开发、同源&跨源查询；统一的数据治理，则包括数据主题建设、权限管控、数据生命周期、资产地图等；统一查询分析，则是在完成数据主题建设、数据开发产出，提供同源&跨源的模型分析能力。