文章目录
前言
终于遇到一篇数据开发治理一体化的实践分享, 逆向的数据治理成本确实非常高，大部分的企业是先有数据再去建设数据开发，数据资产，数据调度，数据监控，数据集成…等等管理与开发平台然后再去做数据的治理。
要做好数据治理个人认为的有两个方向可以去尝试：1.像网易做的一体化方案，直接从数据开发，数据建模源端就开始进行管控 2.先定义好标准, 数据治理平台便是数据抽象层(标准层),实现一种数据注册的机制将原先的开发过程+设计+需求抽象到标准的数据治理平台中。
其1方案方向建造成本较大，目前来看是所有ToB的厂商统一的方向
其2方案方向建设成本稍小，可对各样的来源数据进行解耦进行治理，模块化灵活落地
不管是啥方向，数据治理的最终目标还得是降低落地的成本与使用的复杂性，同时完成对企业全域数据整个生命周期的管控与规范标准化，帮助企业更好的实现数据驱动未来(市值的增长~~~)
接下来内容我们来拜读下网易数帆-郭忆的分享：
- 本文出品平台：DataFunTalk
- 分享嘉宾：郭忆 网易数帆
导读
随着大数据的进一步发展，网易数帆大数据团队提出了数据生产力的理念。秉承“人人用数据，时时用数据”的愿景，构建了网易数帆数据中台支撑技术体系，支撑了网易云音乐、严选、传媒、有道、邮箱等数据中台项目建设。数据中台和数据治理有非常密切的关系，如果没有做好数据治理，数据中台就好比空中楼阁，会出现各种各样的问题，因此数据治理对于数据中台的构建非常的关键。本文将分享网易数帆在数据治理，包括数据中台、数据分析领域的一些实践经验，会围绕下面五点展开：
- 网易数帆大数据
- 为什么数据治理项目经常失败
- 网易数帆数据治理2.0
- 网易数帆数据治理的实践案例
0X01 网易数帆大数据
首先介绍一下网易数帆大数据的背景。
1. 网易数帆大数据的发展历史
网易数帆是网易杭州研究院孵化的ToB业务的商业化品牌，主要是为企业提供数字化转型所需的技术和服务。网易杭州研究院成立于2006年，定位是网易互联网业务的公共技术部门，在成立之初，我们主要做了三个分布式系统：分布式数据库、分布式文件系统、分布式搜索引擎，作为三驾马车支撑了后来互联网2.0时代的网易一系列产品，包括我们熟知的网易博客、相册等。
2009年网易就率先开始基于Hadoop做数据分析和运维，网易的技术体系非常开放，我们看好开源社区对一个基础软件持续发展带来的动能。2014年，网易大数据平台（内部有个更熟悉的名字叫网易猛犸）和网易有数BI上线，推动了网易数据分析的大规模应用，包括网易考拉、严选、音乐、新闻、有道都是基于这个平台去构建自己的数据分析体系的。
2017年网易大数据开始正式对外商业化。到了2018年，随着网易内部数据分析规模的快速增长，网易在数据分析领域遇到很多问题和挑战，主要表现在数据使用效率、质量、成本和安全领域，面临来自业务的巨大压力，我们开始采用数据中台方式重塑整个数据架构，提出并发布了“全链路数据中台”解决方案。在2020年网易数帆提出了“数据生产力”理念，强调基于数据中台之上，构建面向业务场景的数据产品矩阵，并进一步提炼出“数据产品化”的方法论，这也是数据生产力三大核心方法论之一。大规模的使用数据，加速了对数据治理的解决方案的迫切需求，在2022年，提出了“数据开发和数据治理一体化”理念，这也是网易数帆“数据治理2.0”最核心的内涵。
2. 网易数帆大数据产品矩阵
上图是数帆大数据产品技术体系，包括四层架构：
（1）基础设施层
大数据计算、存储引擎，里面包括了当前一些比较火热的技术，例如存算分离技术，实时数据湖技术、离线和在线业务混合调度技术等，在网易新闻，我们已经实现了离线数据分析任务和在线事务处理业务统一采用k8s调度，在低峰期，把一些离线业务调度到在线业务的服务器上，资源利用率得到了显著提升。在网易云音乐的海外业务上，我们和AWS合作，已经率先采用存算分离的技术，使用云的对象存储替换了HDFS，构建了云原生的数据平台架构。在云音乐，我们已经使用网易开源的arctic实时数据湖方案，使得数据湖具备分钟级别的实时更新能力。
（2）基于DataOps全生命周期的数据开发平台
囊括了数据集成、开发、测试、发布、运维的一整套完整的DataOps的工具链，可以实现DEV/SIT/UAT/PRD多套环境之间的高效测试和无缝发布。
（3）数据治理技术平台
网易数帆的数据治理体系，既包括我们经常看到的传统数据治理的三大件：数据质量、元数据管理、数据标准，还包括了数据中台的相关系统，例如指标系统、模型设计中心和数据服务，我们将其融合成网易数帆数据治理2.0的体系。
（4）数据产品层
BI是数据分析最重要的窗口，包括做一站式数据门户、自助取数、数据大屏，还有一些通用数据产品，比如CDP等。此外，我们将机器学习平台也放入了数据产品层，主要是在数据之上，能够接入一些智能算法，提高决策的精准性。
3. 网易数帆大数据商业化定位
经过网易集团内部业务的长期实践，具备了领先的方法论，并积累了很多行业落地案例，同时也明确了网易数帆大数据的商业化定位。
- 我们是一个基础软件提供商，我们不是一个云厂商；
- 我们必须支持跨云的战略；
- 我们认为一个健康的大数据软件市场一定是分层的。
4. 用户案例墙
0X02 为什么数据治理项目经常失败
下面，重点分享下为什么要做数据治理？
1. 我们为什么要做数据治理
我们将一个企业的数字化转型划分为两个阶段，第一个阶段是在线化，主要是使用信息化系统取代线下流程，在这个阶段会形成非常多的业务系统。第二个阶段，我们将其定义为数智化，就是利用数据和算法，取代拍脑袋决策。要实现数智化，就必须要做到数据生产力，而我们将数据生产力定义为，通过使用数据带来组织生产力的提升。我们观察了很多的企业后发现：凡是真的能做到数据生产力的企业，他们都有一个相同的特征，就是做到了企业人人用数据，时时用数据，所以我们将其作为数据生产力的愿景。而要实现这个愿景，网易数帆提出，必须要靠三大方法论：
- 数据研发（DataOps）：全数据生命周期研发体系
- 数据治理（DataFusion）：数据治理2.0
- 数据产品（DataProduct）：数据通过产品化，让用户很容易把数据用起来
2. 网易数帆数据生产力架构
在整个数据生产力架构中，有三个角色，业务系统、数据中台和数据产品。业务系统主要负责流程的管理，不同的业务系统，产生了数据孤岛，当我们要想按照业务的全流程进行数据分析的时候，我们就必须将这些不同业务系统的数据汇聚到一个统一的数据中台中，形成一个企业的公共数据底座。数据中台最重要的职责是构建一个企业的公共数据层，产出高质量，口径一致的指标，呈现在数据产品之上。数据产品，主要负责将数据转化为业务决策，使得业务流程的运转更加智能化。所以在整个架构中，数据来源于业务，最终数据转化为决策，又会回到业务，这个循环就是我们所说的数智化循环。
那这个跟我们今天要讲的数据治理又有什么关系呢？数据治理在这个里面发挥了什么作用？这个还要从我们遇到的问题讲起。我们前面说，要让一些的业务人员能够真正把数据有效使用起来，但是业务人员真的能把数据用的起来么？数据在使用过程中到底有什么问题？
我们把问题归结为：找不到、看不懂、信不过和管不住，其实背后是整个数据生产的效率低和质量差。
3. 传统数据治理1.0
传统数据治理，我们将其称为三大件，包括元数据管理、数据质量和数据标准。一般的数据治理流程，会先从数据标准开始，制定数据标准的过程称之为定标。定好标准之后，就要完成落标，这个过程中需要用到元数据采集、元数据注册以及元数据审批发布。落标完成了数据模型和数据标准之间的连接，接下来，我们就可以利用数据标准里面定义的数据元约束，对数据质量进行稽核，将不符合标准的数据质量问题抓出来，推动进行整改。这就是一个非常标准的数据治理流程。这套流程对于存量数据有明显的提升效果，但是忽视了增量数据的长效治理， 这就导致企业需要不断的通过数据治理项目来维持数据治理的效果。
所以，网易数帆认为，要实现数据的长效治理，就必须要从数据的生产环节来解决问题，确保生产出来的数据，本身就是符合标准的。
传统数据治理1.0存在的问题总结如下：
（1）数据开发与数据治理脱节
具体表现在：
- 数据质量与数据开发脱节：经常会有人问，如何确保数据质量稽核规则的完备性，我们发现，生产出来的数据，只有10%的核心表有稽核规则，相同的数据项，不同的开发设置的稽核规则都不一致。
- 数据标准与数据建模脱节：分享一组数据，在网易，37%的表存在命名不规范问题，相同的字段，有8种以上的字段命名。
- 数据标准与数据安全脱节：数据安全策略与数据标准不一致。
- 数据开发与数据标准脱节：字典映射与ETL不一致
- 元数据与任务运维和开发脱节：任务无法按照资产登记进行有效管理
逆向的数据治理成本是非常高的，因为表已经建好了，任务已经上线了,再催着他们去改成本就相对比较高了。如果我们能够在表或者分析任务上线之前进行模型设计，先进行数据标准化，再进行建模，这样出来的表一定是符合标准的，这样的成本也是最低的，所以我们强调数据开发和治理一体化。
（2）缺少对不同平台的统一管理
不同计算、存储引擎，增加了用户找数据，理解数据，用数据的成本。
（3）忽视了数据开发过程中的效率、质量问题
上图是两个真实案例，由此可见在数据生产过程中就要融入数据治理，而不是上线后再去治理。
（4）没有解决烟囱式的数据开发
烟囱式的数据开发会造成指标口径不一致，数据重复开发带来的效率问题，以及数据重复计算带来的资源使用问题。
（5）对数据价值和成本评估不足
（6）数据治理的过程缺少量化的手段
应该有一些量化的手段去监控整个治理的过程。
（7）数据治理的过程缺少持续反馈的闭环
元数据缺少持续改进的闭环
数据质量缺少持续改进的闭环
资源精细化管理缺少持续反馈的闭环
0X03 网易数帆数据治理2.0
1. 到底什么是数据治理？
行业权威机构DAMA规定了数据治理的11个职能象限，但它缺少具体的落地方法和经验。
DCMM是我国在数据治理领域的第一个国家标准，它给出了客观的评价方法，但仍然缺少具体行动方法。
2. 网易数帆对数据治理的理解？
网易按照数据治理的目的将其分为两个部分：
- 面向业务系统的数据治理：解决业务系统的跨业务、跨系统、跨流程的企业核心数据一致性、权威性和正确性问题。
- 面向数据分析的数据治理：解决的是数据分析过程中效率、质量、安全、成本、标准、价值问题。
3. 网易数帆数据治理的方法论DataFusion
网易数据治理的方法论，将传统的数据治理方法融入数据开发的全生命周期中，基于DataOps全生命周期数据开发底座，采用数据中台的数据架构，结合了网易特色的基于ROI的数据资产化实践，我们将其称为数据治理2.0
核心亮点：
- 开发与治理一体化
- 基于DataFabric的逻辑数据湖
- 采用DataOps的数据开发底座
- 数据中台架构，解决烟囱式数据开发
- 基于ROI的数据资产沉淀
（1）数据开发与治理一体化
- 通过数据探查、生成值域约束
- 数据标准在数据元、元模型上绑定稽核规则
- 数据建模引用数据标准中数据元和元模型
- 根据表绑定的数据标准所关联的稽核规则，自动添加到表的稽核监控
（2）基于DataFabric逻辑数据湖
基于DataFabric逻辑数据湖的核心思想是构建一个跨平台的统一的数据集市。把HIVE、MySQL、Greenplum构建统一的聚合层，在此之上直接输送给BI，通过圈选数据集、物化视图完成业务开箱即用的效果，对用户来说，能够屏蔽底层不同数据源之间的数据实现过程。
（3）基于DataOps的数据开发底座
基于DataOps的数据开发底座，是将软件工程中CI/CD的方法论应用于数据开发领域，覆盖了可持续集成和可持续交付、可持续部署。具体包括编码、编排、测试、代码审查、发布审核和部署上线六个阶段。
（4）数据中台的架构
数据中台包括三大核心：统一指标管理体系，高复用、规范公共层模型，以及数据服务化。
（5）基于ROI的数据资产沉淀
基于ROI的数据资产沉淀，我们通过可视化分析页面可以看到每个任务精细化的场景管理，能够让业务人员对于没用的数据进行持续的治理下线。
- 核算每个任务、查询、表的计算、存储资源消耗，并折算到钱，且分摊到每个数据报表，数据服务API应用层面；
- “剥洋葱”式数据下线：从下游不再使用的数据应用开始，逐层向上游任务和数据下线归档，释放资源。
- 任务和查询成本预估，对于高消耗的任务和查询，进行审批管控
4. 量化的指标监控和分析
通过监控仪表盘里面的数据治理健康分，可以有不同维度的扣分，最终我们基于这个健康分，做不同业务之间的红黑榜，也是绩效管理的一种手段。
5. 持续运营-元数据质量发现和反馈
我们在持续运营过程中，数据资产消费者发现数据质量有问题的时候，可以去申请数据治理。数据管理部门可以指派工单的形式要求业务部门在规定的时间规定的地点完成数据对应问题的修复。
6. 企业数据文化建设
数据文化：
- 数据分析大赛、数据治理大赛、数据可视化大赛
- 数据开发工程师、数据可视化分析工程师资格认证
组织建设：
- 数据治理部，作为数据治理运营部门
- 业务部门配备数据治理专员
- 制定数据治理分数，作为红黑榜，推动业务部门的重视
- 与公司内部流程引擎结合，实现数据治理流程的工具化流转
7. 数据生产力组织架构
8. 面向治理的体系建设
技术是数据治理的基础，但有了技术还不够，还需要上面的组织、流程、考核以及政策，完善整个体系，才能最终实现人人用数据、时时用数据的愿景。
9. 数据战略
10. 企业数据资产门户——一站式的数据消费平台
通过一站式数据消费平台和门户,业务人员可以在门户上看到企业有哪些数据、哪些核心的报表、哪些核心的数据治理应用。
0X04 网易数帆数据治理的实践案例
1. 某大型运营商
在引入网易数帆一站式工具平台前面临的问题：
- 数据标准、数据质量与数据开发严重脱节，规范只能停留在字典层面，无法融入数据生产的流程中，不能有效的落地执行和监督。
- 不同厂商，不同工具之间严重割裂，数据质量的稽核规则无法和数据标准中数据元的值域约束打通，数据标准中数据元无法跟数据建模工具无法联动，元数据管理中的数据安全等级和安全中心的数据脱敏无法联动。
最终导致反复做数据治理，没有从根本上去解决问题。
2. 数据开发与治理一体化
引入网易数帆，由数据中台统一为仓库、经分、网络集群提供数据采集、建模、开发、调度、治理等一体化能力。在生产过程中对于程序上下线，建表等操作实现在线化、流程化操作，一方面减少人工提升效率，一方面完善数据管控的过程。
重点是把数据治理整个过程融入到数据开发的全链路上，在设计之前先去做数据的标准化，然后再去做数据建模，围绕数据标准去做数据质量和数据安全以及数据资产，实现了整个开发治理一体化的数据治理场景的落地。
3. 成果一览
上图展示了我们数据治理的成果。大家也可以从质量、价值、安全、成本、标准和效率这些方面去发现问题。
0X05 QA
Q1：面向业务的数据治理和面向分析的数据治理怎么去做协同？
A1：这个问题问得非常好，类似问题我们要不要做面向业务的数据治理？我们要不要做数据分析的数据治理？我到是先做业务的数据治理还是先做分析的数据治理？其实他们之间是有很强的衔接关系，因为数据来源于业务系统最终会回到业务系统。所以我们做了面向业务的数据治理，那在业务系统这边其实也有对应的数据标准，数据标准里面它也有对应的数据质量规则,数据资产等级。
当然做了业务的数据治理是不是我就不用做数据分析的治理？不是的！我刚才其实讲了很很重要的一个点就是分析系统和业务系统的建模方式是不一样的，业务系统的建模方式是采用的实体关系建模，分析系统的建模方式是采用的是维度建模，这两个之间是有一个衔接的关系的，是通过业务实体的方式可以衔接起来的。如果你在业务系统做数据治理以后，业务系统的数据治理可以直接应用到分析系统的数据治理上，我们可以把标准同步过来，可以把标准所对应的数据质量的规则同步过来，这些规则在分析系统里面它会形成不同的数据质量稽核任务，但是定标这样的一个过程，其实可以大大的降低工作的复杂度和难度，所以他俩之间的一个协同的关系，就是可以把面向业务系统去做的数据治理的这些数据质量的规则、数据标准、数据模型,同步给我们面向分析的数据治理，用同一个平台去管理，在同一个平台上的分析的和业务的能够通过业务实体能够关联起来。这就是两个之间的一个协同的过程，其实也是体现在一个工具、技术、产品上面去实现的。
Q2：数据测试这个环节你们是怎么开展的，基于什么样的一个理念来落实和实施的？
A2：数据测试是我们整个CI/CD的一个非常重要的一个环节。就是我们去做数据测试,它是测试的一个非常重要的手段，我们会去做很多的卡点，怎么来保证这个东西能够实施到位，其实是需要有一些卡点的，就是有一些能够卡住的一个点，让他能够必须去执行，就是我们去做数据测试，它是测试的一个非常重要的手段，我们会去做很多的卡点，就是怎么来保证这个东西能够实施到位呢，其实是需要一些能够卡住的点，让它能够必须去执行。这里面的卡点其实会根据什么呢？你所有的数据都卡，不太现实。所以需要数据先设计再开发，你在设计环节就会去做数据资产的分类分级，定义好数据的安全等级。我们可以根据数据的影响的范围和数据等级，去制定对应的审批流程，比如说对于核心数据上线，我们必须要有对应的数据测试报告。包括了对应数据测试的一些业务规则和技术规则，比如说是不是主键唯一的，会不会存在空值等相关的一些情况进行稽核，我们会把这些对应的数据质量报告自动的通过平台在任务提交上线的时候，掺杂到业务的提交上线流程中，这时候上线的流程会根据它对下游的影响范围和对应的数据资产等级去自动的触发审批流，审批的人就会去看他的数据测试报告和代码是否匹配，有没有对应的数据测试的结果，如果数据测试结果符合预期，这个任务才能上线，通过这样的一种方式，能够强制性的保障我们所有的核心数据都是要进行测试的。
Q3：数据治理2.0在金融场景应用的案例，您觉得最成功的是什么？
A3：实事求是地讲，其实也看了很多的案例，包括证券行业、银行理财、资管很多的行业，对于数据开发治理一体化这块都是才刚开始摸索阶段，包括前段时间我们跟很多证券行业的CIO、数据治理的负责人去交流，他们都特别希望把数据治理能够落地，当然这个落地过程中会有很多的问题。比如说我们工具开发平台可能在很多年前就已经有了，那数据治理平台又是另外一个，那这样会存在很多的不同的平台之间打通的问题，带来非常高的成本,最终导致没办法落地，就跟我刚才分享的运营商的案例一样。但是从整体上来看，我觉得这是一个大家比较认可的趋势和方向，就是在生产数据、生产环节中去完成整个治理过程的落地。而不是这种事后的反复的去做这种治理的过程。给大家分享一个心得，对于新数据来说，可能对业务的价值会更大，老数据，反而可能价值是比较有限的，所以我们要更加关注的是新数据的产生，新数据治理的过程。
附录
- 本文出品平台：DataFunTalk
- 分享嘉宾：郭忆 网易数帆
版权归原作者 Pushkin. 所有， 如有侵权，请联系我们删除。