网易内部数据治理体系演进简介
大数据科学导读：
网易内部如严选、云音乐、传媒等数据团队对数据内容体系的治理思路都是将治理规范融入到开发过程中，将治理的动作提前，这其实就是“开发治理一体化”；事后依赖数据资产健康评估和治理工具进行数据的治理，建立事前加事后的数据治理体系。
本文主要内容包括以下四个方面：
“先设计后开发”
“先污染后治理”
基于元数据的数据治理体系
基于逻辑数据湖的数据治理介绍
正文开始
随着网易数帆商业化的发展，遇到很多金融及大型国企客户，我们发现互联网的这套数据治理的打法并不能全部适应传统行业客户的场景。我们开始向客户和竞争对手学习，为此打磨出元数据管理，数据标准，数据资产目录等子产品，沉淀出一套数据治理的产品体系。
“先设计后开发”
在软件工程中良好的设计具有不可比拟的意义，它胜于需求、编码、维护等环节，秉承设计优先的原则会让软件开发变得简单高效，可以尽量避免掉因设计失误而导致的缺陷，一个健壮的程序必然有良好的设计。
网易数帆有数数据中台产品的特色之一“先设计后开发”，其目标就是将数据标准定义、指标规范定义、模型设计和数据开发体系连接在一起，实现“规范即设计，设计即开发”、以设计驱动开发，并通过流程管控卡点保障元数据的生成是按照规范落地的。在开发的过程中保障数据标准，数据质量，数据安全的落地，这就是将开发治理一体化，期望能达到“事半功倍”的事前治理方案。
在没有“数据标准”产品之前我们，我们推荐客户的数据体系构建工作流包含业务和需求调研，数据架构设计，指标规范定义，数据模型设计，数据开发五个过程。
数据架构设计指以维度建模为理论基础，基于业务和需求调研的结果，通过需求联动设计，对数仓进行整体规划，包含确定数据域，抽象业务板块，定义数据域下的业务过程；
指标规范定义，包括原子指标，业务限定如修饰词、时间周期，派生指标则由原子指标和业务限定组合而成；也包含维度及属性的规范定义；
数据模型设计是指基于原子指标，派生指标，维度属性组合的维表、明细事实表和汇总事实表的模型设计；
数据开发：将逻辑模型变成物理模型，是设计与物理实现的统一。
再好的规范设计都需要工具来落地和约束，否则就是一纸空文，我们认为所有需求都可以拆解为指标和维度，指标和维度组合就是模型，所以用指标管理工具和模型设计中心去承载规范设计的落地：
数据研发同学在指标管理中配置化定义维度、业务过程、原子指标、时间周期的中英文名称；这个过程已经完成维表和事实表的定义；
分析师或者数据口径管理者负责定义派生指标的业务元数据，通过选择原子指标和业务限定自动生成派生指标，派生指标全局唯一，这样就轻松的消除数据的二义性；在这个过程其实就已经完成汇总表的定义。
通过前面两步基本完成指标和模型的定义，数据研发同学就可以结合当前模型的情况在模型设计中心完成模型的设计或者修改。当前市面有些公司也是基于这个逻辑将模型设计和指标管理合二为一形成半AutoETL产品，自动生成指标/模型/调度关系。附模型设计原则：
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年推出了数据标准；同时为了更好的流程协作管理，我们优化了流程协作与消息中心，构建能自定义的流程引擎、企业组织架构和消息通知。
“先设计后开发”核心是元数据的规范，在设计阶段就约束元数据的定义，开发阶段则通过流程管控保证规范元数据的生成，这样就能保障逻辑与物理的统一。数据标准的目标就是完成元数据规范的定义，结合指标和模型两款产品，将数据标准规范定义、指标规范定义、模型设计和数据开发体系通过流程引擎连接在一起，以实现“规范即设计，设计即开发，开发即治理”的开发治理一体化。
数据标准：通过制定数据的标准保障数据的内外部使用和交换的一致性和准确性的规范性约束。对指标的元数据进行规范定义，从业务属性、技术属性、管理属性三个方面对元数据进行描述。在实践过程中将数据元与指标关联打通，并可以对指标在数据质量、数据安全、模型设计规范等方面的执行情况进行事后检查评估。
指标管理：自动化生成指标，消除数据的二义性。指标的设计需要符合数据标准的规范，完善指标的技术、业务、管理元数据。
模型设计：负责数据模型的设计，也需要遵循数据标准的规范，将指标与模型挂钩，规范表和字段的元数据；
数据开发体系：将数据开发的过程与数据规范结合实现业务规则的数字化落地。负责将设计的数据模型实现，将技术元数据（血缘，质量，负责人，调度任务信息等）和标准规范结合，实现模型设计与数据开发的协同，真正意义的完成了元数据的标准化落地。
规范约束：数据标准负责定义“好数据”的标准，包含质量、安全等；指标工具负责设计好的指标和维度；每个指标需要与数据标准关联；模型设计中心负责设计好的数据模型，模型的每个字段必须来自指标管理的定义好的指标和维度才能完成物理建表；数据开发体系按照设计要求完成代码的开发，负责生产“好数据”和“好元数据”。
指标、模型设计这块的落地方案，我在第一章已有详细的介绍，这里就不单独再介绍了。再强调一下再好的规范没有工具产品来匹配落地就是一纸空文。工具产品必须有所卡点才能保障设计和落地的一致性，需要通过流程引擎保障先设计后开发的流程、保障规范的落地。这些卡点包含：
数据标准的规范在指标和模型的引用率，事后需要检查规范的执行情况
指标系统的指标需要自动生成，且保障唯一性，同时也需要检验指标的相似度。
模型的设计时模型的分层，数据域，业务过程，时间周期等变量的定义是选择题而非填空题，模型设计与建表一体化，建议关闭其他通道DDL执行。同时模型的规范事后需要检测：如相似度，复用度，穿透率，覆盖率，闲置率等，如有必要保障模型建表唯一通道
上线前数据模型、质量、安全等规范未落地不允许发布上线。
将数据开发与数据治理结合起来既是对开发过程的管控，也是保障数据质量的有效方法。需求阶段主要对业务数据进行调研、拆解数据、确定词根、数据项以及业务指标。设计阶段基于调研的内容进行标准和指标的设计并应用于模型和质量，设计完成后进行元数据的注册并完成业务信息的录入。开发阶段根据设计阶段的规范进行数据开发、约束开发流程，通过元数据扫描完成元数据技术信息的录入，最后将元数据进行审核并发布。在数据的全生命周期内各个模块协同的案例：
数据标准与模型设计：在数据模型设计中关联数据标准，数据标准中字段命名可以直接应用在模型字段上。
数据标准与数据质量：数据标准中的数据元对应的值阈约束可以关联稽核规则。
数据标准与数据安全：数据标准中的数据元可以关联数据安全的数据敏感等级和数据脱敏规则。
数据质量与模型设计：数据模型关联的数据元所关联的数据质量稽核规则，可以直接应用到这个模型的稽核任务上。
数据安全与模型设计：模型发布，自动应用安全中心的脱敏规则。
开发治理一体化对于很多公司意味着数据体系的重构。在重构的过程中用流程约束元数据的生成，保证元数据的规范性。事前治理的方案对客户数据建设所处的时机要求就会比较高，虽然也可以按照数据域逐一重构迁移，整体建设周期较长，价值也不能立竿见影；但是数据体系的建设本就是数据“熵增”的过程，我们在建设中对他做功，这样熵增加的比例是在可控的范围内，事前做功对数据治理来说事“事半功倍”的选择。对过程做功会带来效率的降低，未来如果搭配可视化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）强化管理属性
统一数据治理控制台作为所有治理项的入口，一方面是系统预置治理规则扫描的待治理项，包含成本、质量、安全、规范和价值五个方面；另一方面是通过工单形式指派给相关治理管理者的治理项；
用户分层，从项目组、项目和用户角度呈现待治理和已治理项，强化数据治理专员这个角色；
自定义数据治理流程，例如待我治理/待处理工单，数据消费者、项目负责人、数据治理专员都可以发起资产的治理工单（比如字段描述缺失、数据质量分较低等）系统会将治理工单下发给资产负责人，所有工单信息都会体现在“待我治理”模块；
数据治理的流程定义与企业组织架构、消息系统如IM等进行打通，形成管理闭环。
3.3 产品整体方案
经过上面的介绍可知我们的数据治理产品包含事前和事后两条路线。覆盖数据的全生命周期（从元数据的注册到数据应用消费），包含”先设计再开发“的事前治理、数据健康评估与优化（事后治理）这两条线，以实现建设“规范的元数据”和“好的数据”。同时在消费端将健康的资产通过业务分类和标签等方式来组织，便于普通用户在数据消费时能“找的到、读的懂、信的过”。
数据消费者对数据资产有任何问题可以一键发起数据治理工单，资产责任人则需要完成响应。
资产责任人需要完成系统识别的治理内容和数据消费者、负责人、治理负责人发起的治理内容。
项目负责人，治理负责人可以发起数据治理工单。
治理负责人包含数据治理专员及治理负责人，对企业数据资产质量负责。
3.4 元数据数据治理满足的场景
元数据管理，包含仓内、仓外，手工元数据的整体纳管，数据资产一体化构建企业统一数据资产地图，让数据消费者找的到、读的懂、信的过；
通过覆盖元数据注册-采集-扫描-审批-发布-使用-变更-废弃的全生命周期，构建一条完整的元数据治理链路；
覆盖数据研发，数据治理，数据服务，到数据应用的全链路数据血缘，从而构建基于ROI的数据资产沉淀体系和”剥洋葱“式的从应用到底层的数据下线机制；
制定和管理企业的数据标准，保障数据的内外部使用和交换的一致性和准确性的规范性
构建统一指标库，消除数据的二义性；
数仓模型优化，从规范性，复用性，应用价值上构建健康的数据体系；
成本治理，包含存储，计算成本优化，降本增效；
数据质量治理，通过数据开发前数据比对，形态探查，数据测试报告，数据任务运行中的强弱规则阻断下游任务防止数据污染，事后提升数据质量监控覆盖率等方式全面提升数据质量；
数据安全治理，包含数据资产的分类分级，脱敏加密，安全扫描，安全审计，权限治理等。
基于逻辑数据湖的数据治理介绍
我们在调研外部用户需求的过程中，经常会碰到的问题：每个企业用户的技术建设情况不同，业务复杂度也不一，很多传统企业已有的IT系统已运行了很多年，只是无法再支持日益增长的数据需求，他们在大数据技术体系的经验几乎空白，当面对一个比如lambda架构的大数据解决方案时，往往会觉得过于复杂和难以掌握，对落地成效心存疑虑。还有部分用户的业务在现有技术框架上（比如MPP）运行良好，出于对未来发展的前瞻性考虑，需要提前进行大数据的基础技术建设，这部分用户对于大数据未来的必要性是肯定的，但是会特别关心其适用的场景、业务覆盖度以及如何平滑地进行业务的迁移。
数据湖&Hadoop解决的是数据统一汇聚的问题，而统一元数据则是解决数据连接、资产、管理的问题，对于相当部分的用户而言，当前最大的痛点不是海量数据的存储，而是如何将散落到各个子数据系统的数据孤岛统一管控起来。因此通过构建一个逻辑层面的数据湖，实现统一的元数据+分散的物理存储，避免不必要的物理数据入仓（湖），从而将产品上层功能比如主题域构建、数据地图等等及早给用户使用才是解决问题的根本之道，逻辑数据湖方案，依然可以使用物理湖&Hadoop，同时提供通过虚拟表直连数据源的方案将其他类型的数据源也纳入平台的管控中，用户可以根据实际的需要选择适合的存储方案。
我们的构建方法论主要分为如下三个大的层面：
数据源支持类型：除了Hadoop（Hive）体系，MPP、RDMS、HTAP、KV、MQ等都需要支持，并且一视同仁，都可以作为具体逻辑数据湖具体对象的物理存储。
统一数据源 & 统一元数据：统一数据源要做的是规范每种数据源的登记注册，包括数据源URL格式、数据源Owner、唯一性校验、账号映射、联通性校验、支持的版本、特定的参数等；统一元数据，则是将数据源的技术（物理）元信息和业务元信息进行关联，提供统一的查询修改接口。
统一数据开发、治理和查询分析：这三个属于构建在统一元数据&数据源基础之上的应用层。统一的数据开发，包括不同物理数据源之间的交换、离线&实时开发、同源&跨源查询；统一的数据治理，则包括数据主题建设、权限管控、数据生命周期、资产地图等；统一查询分析，则是在完成数据主题建设、数据开发产出以后，提供同源&跨源的模型分析能力。
