download：百度网盘
复制下崽ZY：https://www.97yrbl.com/t-1454.html
1“先设计后开发”
在软件工程中良好的设计具有不可比拟的意义，它胜于需求、编码、维护等环节，秉承设计优先的原则会让软件开发变得简单高效，可以尽量避免掉因设计失误而导致的缺陷，一个健壮的程序必然有良好的设计。
网易数帆有数数据中台产品的特色之一“先设计后开发”，其目标就是将数据标准定义、指标规范定义、模型设计和数据开发体系连接在一起，实现“规范即设计，设计即开发”、以设计驱动开发，并通过流程管控卡点保障元数据的生成是按照规范落地的。在开发的过程中保障数据标准，数据质量，数据安全的落地，这就是将开发治理一体化，期望能达到“事半功倍”的事前治理方案。
在没有“数据标准”产品之前我们，我们推荐客户的数据体系构建工作流包含业务和需求调研，数据架构设计，指标规范定义，数据模型设计，数据开发五个过程。
- 数据架构设计指以维度建模为理论基础，基于业务和需求调研的结果，通过需求联动设计，对数仓进行整体规划，包含确定数据域，抽象业务板块，定义数据域下的业务过程；
- 指标规范定义，包括原子指标，业务限定如修饰词、时间周期，派生指标则由原子指标和业务限定组合而成；也包含维度及属性的规范定义；
- 数据模型设计是指基于原子指标，派生指标，维度属性组合的维表、明细事实表和汇总事实表的模型设计；
- 数据开发：将逻辑模型变成物理模型，是设计与物理实现的统一。
再好的规范设计都需要工具来落地和约束，否则就是一纸空文，我们认为所有需求都可以拆解为指标和维度，指标和维度组合就是模型，所以用指标管理工具和模型设计中心去承载规范设计的落地：
-
数据研发同学在指标管理中配置化定义维度、业务过程、原子指标、时间周期的中英文名称；这个过程已经完成维表和事实表的定义；
-
分析师或者数据口径管理者负责定义派生指标的业务元数据，通过选择原子指标和业务限定自动生成派生指标，派生指标全局唯一，这样就轻松的消除数据的二义性；在这个过程其实就已经完成汇总表的定义。
-
通过前面两步基本完成指标和模型的定义，数据研发同学就可以结合当前模型的情况在模型设计中心完成模型的设计或者修改。当前市面有些公司也是基于这个逻辑将模型设计和指标管理合二为一形成半AutoETL产品，自动生成指标/模型/调度关系。附模型设计原则：
dwd_{业务缩写/pub}_{数据域缩写}_{业务过程缩写}_[{自定义表命名标签缩写}]_{刷新周期标识}{单分区增量全量标识}
dws_{业务缩写/pub}_{数据域缩写}_{数据主粒度缩写}_[{自定义表命名标签缩写}]_{统计时间周期范围缩写}/{刷新周期标识}{单分区增量全量标识}
在模型和指标的落地过程中，通过“庖丁解牛”式的产品配置将数据模型涉及的技术元数据/业务元数据进行标准化，标准化的好处是“车同轨，书同文，大家都说普通话”。可以说我们产品从一开始就实现了开发治理一体化。
2“先污染后治理”
“先污染后治理”是当前数据治理的主流方案，与其说主流不如说是无奈的选择，因为“先设计再开发”意味着重构，重构虽然是最彻底的方案但也是最难实操执行的，毕竟很多数据团队最核心要交付的是短期业务价值，重构带来需求交付效率的下降且短期无明显价值增长，也有很多数据团队就会选择边开发边进行治理的方案，我们将网易的经验和过程也在这里做一个介绍。
2.1 运动式治理
随着业务的发展，网易内部业务线的计算和存储达到瓶颈，但业务方很难判断，是应该继续扩容增加资源，还是对劣质数据进行治理来降低资源危机，但这个过程中，如何定义劣质数据，定义了劣质资源后，要怎么对其进行治理，都是亟待确定和解决的问题；另一方面，数据本身的加工链路长，数据的加工处理没有统一的标准，整个团队内到底有哪些数据，数据的负责人是谁，这些数据是通过哪些任务产出的，这些数据有没有被有效的使用，数据的存在是否有意义，这些都是管理者比较关心的问题，但数据团队都很难回答。通过运动式的专项治理我们还是沉淀出部分工具
2.2 度量体系的构建
基于元数据的建设，我们将底层的表信息、计算任务信息和任务/表之间的血缘信息，汇总为计算、存储的元数据仓库，结合内部自己的账单体系对计算和存储均进行了定价，从而将调度任务、自助查询每次执行消耗的计算成本预估出来，对于存储成本，一方面包含数据表本身的存储成本，另一方面产出该表的计算任务也会分摊该数据表的成本，最终得到数据表总的存储成本。将计算和存储成本转化为费用，更加一目了然的对治理效果进行量化评估。为了方便用户理解，我们构建了统一的健康分度量体系
3基于元数据的数据治理体系
无论“先设计后开发”亦或是“先污染后治理”，都少不了过程元数据的沉淀，这样才会让治理无论在任何阶段都变得轻松可靠。在商业化实践的过程中我们逐步地吸收了传统行业一些优点，例如在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年推出了数据标准；同时为了更好的流程协作管理，我们优化了流程协作与消息中心，构建能自定义的流程引擎、企业组织架构和消息通知。
“先设计后开发”核心是元数据的规范，在设计阶段就约束元数据的定义，开发阶段则通过流程管控保证规范元数据的生成，这样就能保障逻辑与物理的统一。数据标准的目标就是完成元数据规范的定义，结合指标和模型两款产品，将数据标准规范定义、指标规范定义、模型设计和数据开发体系通过流程引擎连接在一起，以实现“规范即设计，设计即开发，开发即治理”的开发治理一体化。
