导读：在DataOps大会上，网易集团副总裁、网易数帆总经理汪源发表了《网易基于DataOps的数据开发治理一体化实践》的主题演讲，作为互联网公司的代表，网易的DataOps不仅是追逐热点，更是其数据发展的必然结果。
尊敬的各位领导、各位专家，非常荣幸来参加DataOps全球峰会。
今天我的主题是数据开发治理一体化。刚才在魏所的介绍里面，提到了像数据开发治理一体化，先设计后开发的理念，网易比较早实现了这一理念，在我们的内部和外部形成了一些案例，所以我称之为网易的DataOps的特色化实践。
网易杭州研究院成立于2006年，不仅仅是技术单位，在技术之外我们负责创新业务的培育。我相信今天在座的也有网易云音乐、云课堂以及网易严选的用户，这些都是研究院孵化的成果。在孵化这些业务的过程中，我们也在持续建设数据的能力，在2006年开始去研究分布式数据库。2014年开始做大数据的平台，2015年开始做BI等一系列的产品，不断地去发展。到了今天，我们把所有的实践汇聚到称之为“数据生产力”的统一模型——我们从2019年就提出“数据生产力”的概念，今天将所有的实践汇聚到数据技术、数据资产、数据应用和数据运营四个板块构建的“数据生产力”的模型。
我们从数据消费端着眼建立数据生产力的最终目标和愿景，就是“人人用数据，时时用数据”。这句话一开始是“人人用数据，天天用数据”，后来因为实时化发展，后半句演进成“时时用数据”。我们的核心是三个方法论：DataOps，DataFusion和DataProduct，其中DataProduct是以数据产品为核心的展现形式。经过多年的发展，我们构建了完整的大数据产品矩阵。包括底层的大数据基础平台NDH，中间是基于DataOps全生命周期的数据开发以及上层的很多模块。
DataOps 1.0实践：数据发布流水线
接下来重点介绍DataOps相关的工作。在网易，DataOps相关的工作分两个阶段：
第一个阶段（2019—2020年），我们建立了从数据的开发、测试到运维上线的流水线，这个阶段的DataOps，我们称之为DataOps1.0版本的实践。当时为什么做这件事情，是因为我们在业务上遇到一些挑战和问题。一个曾经出现过的真实问题，是在电商平台的活动中，因为数据有缺陷和Bug，导致了资产的流失。
分析这一问题的原因，最主要的是因为我们任务之间的依赖容易缺失，同时也缺少自动化的测试和发布的管控。那怎样解决这样的问题，在2019年“DataOps”这一概念在行业中还没这么流行。
我们当时的思路，研究院不是单纯做数据研发的，也做了很多软件研发，孵化了很多业务。几乎所有人都知道，软件研发有DevOps的概念，我说既然有DevOps，数据研发就参考通用软件工程的DevOps，把DevOps的概念应用到数据研发的领域和场景中来。这就形成了DataOps的1.0的实践。
这些实践今天看起来非常简单，大家实践的细节上有差异，但是整体架构差异不大，都包括从编码、编排、测试到代码审查、发布审核到部署上线，当然上线以后还有运维，这就是三年前的DataOps 1.0的实践，数据发布的流水线。
这一流水线解决了上面的问题，因为加了测试和代码审查，Bug就会减少。但是做了以后，数据开发的团队还是面临比较多的挑战。总结来说，最典型的是三个方面的问题：
一是规范缺失。包括命名结构的不规范，安全规范不一致等；
二是没有解决烟囱式开发。一个数据研发团队，可能是十个或者是几十个数据研发。我认为1.0的流水线从独立的开发者视角来说能够有效地保证工作产出的质量。但是从一个团队的视角、BU的视角和企业的视角是不够的，还是没有解决烟囱式开发的一些问题；
三是质量规则覆盖不佳，甚至很多相同数据项，稽核规则和阈值设置不一致。
这些问题怎样解决？2020年我们在探索，因为它一定要上升到管理性的思维，作为互联网公司，我们不希望把管理性的思维落得太重，那样会影响到数据开发敏捷的过程。很多企业有数据治理的实践，就是为了解决这些质量相关的问题，但是传统的数据治理方式，在开发的时候不是太注重治理，开发完成的时候再治理，运动式治理了一段时间以后，项目验收时候质量都很好，但是过了半年、一年质量又不好了。我们不希望出现这样的情况，还是要想办法解决这样的问题。
DataOps 2.0实践：数据开发治理一体化
我们提出了DataOps的2.0，就是数据开发和治理的一体化。什么叫数据开发和治理的一体化？这里面有两个关键：一是先设计、后开发；二是先标准、后建模。
在开发之前我们先进入设计阶段，这里面我们融入了必要的数据治理方法的落地。从制定数据标准开始来实施整个数据研发的链路和过程，通过制定数据标准，通过先进行指标设定，把这些规范更好融入后续的开发、测试以及常态化的质量监测和安全监测方面，在设计阶段的活动，持续地落到后面的各个环节。
这一思路其实很简单，但它是很有效的。对于绝大多数的团队和部门来说，通过这样的开发和治理一体化的实践，他们还是能够很好地保持敏捷性，同时获得高质量。这里强调的是，我们不是希望做一个非常重的数据治理，动不动搞半年。而是希望通过这样的方法，把数据治理方法沉淀到产品设计中去。指标定义出来以后，后续相关的校验、规则等，会在产品中自动落地，开发人员也不需要额外手动操作。
开发治理一体化的实践中有两个关键：
第一个是以数据标准为根本，这里展现了数据标准会落到很多个相关的模块。比如说数据的建模、质量和安全，这都是和标准相关的。这些标准与相关模块的联动，我们实现了产品化。
第二个是做开发治理一体化，可以获得全生命周期的元数据。通用的元数据的说法包括技术元数据、业务元数据、管理元数据，开发治理一体化的方法，它会对元数据带来增量的帮助。在开发治理一体化的体系里面，我们在设计阶段、开发阶段和后续的消费阶段，自然而然地就会创建很多的元数据。这些元数据是不需要投入额外的劳动获得的，有助于让企业中的数据资产实现“找得到、看得懂、信得过、管得了”，当然这四个效果也不是完全由开发治理一体化解决的，还需要其他的方法综合解决。但是开发治理一体化，在设计过程、开发过程、消费过程自动产生很多有用的元数据，对于这一目标的实现有比较大的帮助。
对比一些传统的做法，在数据开发之外确立一个数据治理的项目，我们认为以后一个成熟的企业不应该有一个数据治理的项目，数据治理是在开发中就做到了。如果还有一个独立的数据治理项目，就说明之前他在开发过程中有一些遗留的问题拖后腿了。传统的模式是先污染后治理，以及运动式治理。因为治理并未常态化地落到技术和产品中去，所以过一段时间又需要再做治理。我们的目标是要做一体化的模式，一步到位然后长效解决。
最后介绍开发治理一体化落地成果，在网易内从规范化上来讲，字段的标准化率达到80%。它对效率也有帮助。因为先设计后开发，公共层就可以沉淀更多的东西，就可以有更多的复用。
我们在一些外部的企业落地，这里举一个券商落地的成果。通过我们开发治理一体化的方式，他们在数据的标准、数据的质量、安全方面，也取得了一个比较好的结果。
给数据管理者的建议
最后给管理者提供一些建议，或者是我们的思路。我们觉得从数据相关的管理者来说，要坚持三个核心原则：
一是最核心的要关注数据的消费侧，因为数据创造价值是要通过消费来创造的。不管是开发还是治理，本身都是不创造价值。
二是建立合适的指标体系。刚才我看了农行赵总的指标体系建设非常完善，我们也是建立了相应的指标体系，有助于整个能力的持续提升。
三是探索很多智能化的行动。去年年底的时候，ChatGPT的出现对整个的软件开发带来了革命性的影响。刚才我们提到一个词叫“先设计后开发”，这里面还是会有设计和开发的，但是我认为后续在很大的程度上来讲，我们应该可以实现设计即开发。
也就是说，以后你只要做设计，开发过程几乎是完全自动化的，你不需要人工投入做开发的。以现在的技术进展，我觉得应该是在数据领域能够做到这一点，数据的开发复杂度比通用的软件开发要简单一些的。比如说我们现在自己研发的模型，把自然语言转化为SQL的角度，我们也达到了ChatGPT90%的水平了，这个相对来说还是更好做一些。所以我想后面我们会努力突破智能化技术的应用，将先设计、后开发进一步演变成“设计即开发”，大家只需要考虑设计过程，开发过程自动完成。另外我们也是会探索包括基于低代码的数据开发。
以上就是我今天的分享，重点介绍了数据开发治理一体化，其他的实践没有过多展开介绍，感兴趣的大家可以一起交流。