先设计后开发，先标准后建模，网易 DataOps 实践

1 简介

在当今数据驱动的时代，企业面临着越来越多的数据管理和治理挑战。为了有效地利用数据，许多企业开始采用 DataOps 方法论，以实现数据开发流程、数据消费流程和数据运营流程的整合。

在 ArchSummit 全球架构师峰会上海站，我们邀请了网易数帆大数据产品技术负责人郭忆分享了网易基于 DataOps 的敏捷、高质量数据开发实践，本文为演讲整理，期待对你有所启发。

我来自网易数帆大数据团队，隶属网易杭州研究院，我们研究院主要为整个网易集团提供云计算、大数据和人工智能相关的平台建设。我们的服务覆盖了网易云音乐、网易严选、网易有道等业务，这些业务都在我们提供的平台上，通过不同租户形式进行业务层面的隔离。此外，我们还负责网易集团的公共数据层的建设，包括用户画像数据等，我们利用这些数据为网易严选和网易有道新闻导流。

我们的数据技术部门成立于 2006 年，初期主要做数据库、分布式文件系统和分布式搜索引擎，这三大技术也支撑了网易在互联网 2.0 时代的产品，如网易博客、网易相册以及后来的网易云音乐等。2014 年，我们上线了大数据平台，以及有数 BI 工具，大大推动了网易在数据分析领域的应用。现在，我们的平台有超过 3000 人的日活，他们利用我们的平台完成日常的数据分析工作。

2018 年，我们开始建设数据中台，网易严选、考拉、云音乐业务也相继通过数据中台进行数据体系的重构。2020 年，我们开始实践 DataOps，以提高我们的数据分析效率，提供端到端的数据提速。2022 年，我们开始实践开发、治理一体化的 DataOps。我们的最终目标是构建一个人人用数据和时时用数据的企业数据文化。

在构建这样的数据文化上，我们有一套完整的方法论，其中 DataOps 是一个核心的方法论。我们要提供端到端的 DataOps，这需要我们首先构建数据技术，比如数据中台的技术、开发治理一体化的技术等。然后在这个平台上，我们需要沉淀丰富的企业数据资产，比如企业的公共模型、指标体系、标签体系、数据标准、数据质量稽核规则等。有了这些数据资产，我们就可以开始输出，让更多的企业人员使用这个平台。

在这个过程中，数据产品化是一个非常重要的环节，我们需要开发大量的数据产品，让数据触及到一线的业务人员。同时，我们还需要有数据运营的过程，能够把整个流程串联起来。为了推动这个过程，我们每年举办数据分析领域的三大赛事，包括数据治理大赛、数据分析大赛和数据可视化大赛，以此来挖掘并推广一些优秀的数据使用案例。

我们的技术架构总体上包括四层。

最底下一层是大数据的计算和存储引擎，包括湖仓一体技术、存算分离技术和在线离线混合调度技术等。上一层是基于 DataOps 的全生命周期开发平台，其中包括数据测试环节，通过自动化的数据测试和任务发布技术提升整个数据开发流程的效率。再上一层是数据治理和数据中台体系，以指标系统模型设计中心和数据服务为核心的数据中台体系和以数据标准为核心的数据治理体系。最上一层是数据应用层，包括 BI 应用、标签画像和数据产品等应用。

总的来说，我们的所有工作都围绕着如何发挥数据的生产力，构建一个人人用数据，时时用数据的企业数据文化。

2 DataOps 1.0 敏捷、高质量实践

整个网易 DataOps 主要分为两个阶段。

第一个阶段，我们专注于数据中台内部的 DataOps 实践，以实现敏捷且高质量的开发。以下我将分享一些我们选择实行 DataOps 的案例，这些都是从一些痛苦的教训中获得的。

例如，我们有一个电商业务，在这个业务中，消费者购买三次后会得到一个优惠券。因为上游任务的改变，其中一个任务在我们的网易严选平台上有 17 层的任务嵌套关系。当上游任务变更后，下游资损表的计算逻辑受到了影响，结果消费者即使没有购买三次，也收到了优惠券，这些优惠券被核销了 30 万，这些直接计入当年数据部门的成本。另一个例子是，任务依赖配置丢失，导致上游任务数据未完成，下游任务提前调度，导致数据空跑，造成了 20 万的资损。

在网易，这类涉及到资损的事故都是 P1 级别的，对我们数据团队的打击非常大。我们做过一次统计，因为数据开发任务变更导致的数据质量问题占比达到了 65%。而且我们非常关注一个指标，这个指标就是需求的按期交付率。所有的需求，都会在我们平台上开发的数据分析任务，在建立任务时候必须会关联一个 JIRA 的链接，所有的任务都必须进入 JIRA 进行统一项目管理。

在 JIRA 中，我们会设定任务的交付时间。当任务上线时，JIRA 会自动关闭。我们发现只有 70% 的需求能按时交付，大量的任务会延期交付。

此外，任务依赖关系极其复杂，我们曾经有一个烟囱式的架构，但在 2018 年，我们改变了，开始构建数据中台。在这里我们构建了整个企业的公共模型层，所有的上下游任务都在依赖这个公共模型层，这使得依赖关系异常复杂。再加上缺少整个发布管控环节，我们可能随意上线修改，没有任何的卡点，没有任何的 Check。缺少自动化的测试，数据质量就难以保证。

因此，我们的目标是提高整个数据开发的敏捷性和效率、提高整个数据的质量。对于一个数据中台团队来说，其核心目标是提升效率并降低成本。在提升效率的过程中，质量的保证尤为关键。我们开始思考有没有一种工程化的方法，能够帮助我们更高效地做任务的发布，减少在多套环境之间的发布时大量的手动操作和改配置，甚至需要改代码。

因此，我们采用了 DataOps，希望通过软件工程的方法，来改进整个数据开发流程。基于自动化的数据测试和任务的发布技术，来提高我们整个数据交付的效率，确保我们的需求交付更有保障。

我们构建了一个数据发布流水线，包括可持续集成、可持续交付和可持续部署三个阶段，按照编码、编排、测试、代码审查、发布审核和部署上线六个流程。

每一个流程都会有工具平台的支持和流程规范的制定。在这个过程中，我们会使用一些关键的技术，比如数据沙箱技术，进行不同环境之间的数据隔离，进行数据比对。我们还会进行代码审查，发布审核，通过发布包的形式，实现多环境的高效发布。

举个例子，我们去年为多家券商做了金融行业的数据运营。在这个行业，常规的操作流程一般会有四个环节，即 DEV 环境（开发环境）、SAT 环境（系统集成环境）、UAT 环境（用户可用性验证环境）、和 PRD 环境（生产环境）。DEV 和 SAT 环境通常是由开发团队或外包团队负责，而 PRD 环境则是由运维团队负责。

然而，运维团队可能对业务不熟悉，而开发团队又无法接触到生产环境，这就存在一个 gap。我们期望的是整个发布流程尽量自动化，减少人工干预。因此，我们构建了一个发布中心，通过发布包的形式在不同环境中进行操作。发布包能够自动识别并注入对应环境的配置，这样就能在不同环境之间流转。

在这个过程中，我们需要考虑到任务的依赖关系，比如，如果一个任务依赖于上游的另一个任务，那么上游任务未上线可能会导致下游任务出问题。因此，我们期望能够自动打包，根据任务之间的依赖关系生成发布包，以便在不同环境之间打包和部署。另外，我们还经常遇到一些协同问题，比如任务已上线，但相关的模型表却未上线，或者模型表已上线，但任务未上线。为解决这些问题，我们需要进行多资源整合打包。

另外，所有的任务发布上线都需要进行严格的管理，包括审批、SQL Scan 以及 Code Review，这个过程可能会让团队不堪重负。因此，我们需要进行分类分级管理，对关键任务进行强管控。如何确定哪个任务是关键任务？我们需要进行任务影响检测，如果一个任务的下游涉及到 S 级报表或数据产品，那么这个任务就需要走强制审核流程。

所以我们需要建立全链路的血缘关系，要能够去做全链路的影响分析，并且基于这种分析结果，去制定分类分级的管理策略。

另外，数据沙箱功能也很重要，它需要在多个集群上运行，能够在开发模式下读取生产模式下的数据，同时又不能污染生产环境的数据，只能写入其自己的环境。在实现这个功能时，需要解决在两个环境隔离的情况下，如何读取生产环境的数据，同时又不让它写回到生产环境的问题。这需要在两个集群之间实现元数据的通信，网易是通过权限隔离等方式来实现。

第三个是做数据的测试和数据的验证。我们在进行数据开发时，通常会从接收需求开始，然后验证数据、编码，最后发布上线。然而，这样的流程往往带来大量的后期问题和 bug，因此，在开始编码前，我们需要对上游业务系统进行数据探查。以我们的经验来说，我们在进行数据探查时，发现了十几个业务系统的 bug。因此，接到需求后，我们并不急于开始编程，而是对业务系统的数据进行深入探查。如果系统中的大量数据都是空值，那么我们得出的统计结果将无实质意义。

当然，开发完成后，我们也需要对结果表进行检查，看看结果是否符合我们对数据的预期。我们需要关注各种细节，例如枚举值的分布、范围、最大值和最小值等，以确保它们符合我们对数据的定义。

我们还需要对代码进行审查。我们经常听到同事们抱怨代码写得不规范或者质量差。特别是业务部门，他们可能会无视技术规范，提交一些复杂的 SQL 查询，给系统带来压力。然而，简单的抱怨并不能解决问题，我们需要采取有效的措施。我们采取的方法是提前扫描并拦截代码。

我们可以设定一些规范，例如禁止全表扫描，必须指定分区。然而，我们不能仅仅告诉他们这些规则，我们还要强制执行这些规则，通过扫描他们的代码，如果代码不符合规范，我们就采取相应的策略。

如果他们的代码触发了我们设定的 S 级或 P0 级策略，我们可以直接拦截 SQL，而不是让任何代码都可以执行，从而避免对系统产生影响。这是我们在第一阶段的主要工作，目标是提高数据开发团队的效率和数据质量。

3 DataOps 2.0 开发治理一体化实践

我们的工作有了明显的成果，数据质量提高了不少。但是，业务团队对此是否满意呢？

数据应该是端到端的，一端是消费者，一端是供应者，我们的数据中台就是中间环节。我们还需要确保数据的消费能够顺畅无阻。

例如，如何帮助业务人员在大量的表中找到需要的数据，如何解释缺失的数据，如何处理业务部门频繁提出的数据质量问题，如何管理和控制大量的无用数据等。总的来说，我们每天都在处理大量的需求，但我们需要反思这些需求是否真正有用，是否真正被使用，而不是盲目地增加系统的计算和存储负担。

开发与治理一体化核心原则是“先设计后开发，先标准后建模”。许多人问我如何确保数据质量稽核规则的完备性。以我们原先在网易严选的数据质量稽核规则为例，这非常依赖于数据开发者对需求和业务的理解。如果开发者对业务理解深入，就能够添加更多的稽核规则。然而，如果他们不了解业务，可能就不会添加规则。这就导致了核心表的数据质量稽核覆盖率很低，完整性差，同一字段在不同表中的稽核规则也不一致。因此，我们需要建立企业数据标准。

在编码阶段，我们希望尽可能减少对业务的理解，所以在设计阶段就将业务相关的内容沉淀到数据标准中。以数据标准为核心，我们可以自动生成数据质量稽核规则，制定分类分级管理策略、数据脱敏策略、数据安全管理策略。只要设计阶段做得好，后面的步骤就会更简单。

我们的核心思想是将数据治理前置，融入到数据开发的全生命周期中，希望能将数据治理的成本尽量前置到开发阶段。

在设计阶段，我们需要规范数据的命名、格式、值域质量和安全规范。参与制定数据标准的包括业务人员、需求方、数据架构师和数据产品。到了编码阶段，甚至可以将其外包给第三方公司，因为整个设计已经完成了一个闭环。

我们可以基于标准进行数据质量探查，生成事后的数据质量稽核规则，生成数据安全规则。数据标准实际上是企业最核心的元数据。这样，我们才能实现从设计、开发到消费，再到运营的端到端运转流程。

总而言之，有两种模式：一种是先污染后治理，即不管三七二十一先上线，然后不断修复问题；另一种是我们推崇的一体化模式，即在开发阶段就建立数据标准体系。

在我们的实践中，基于标准建模可以提高规范性、效率和质量。原来我们需要做很多模型的评审、改造和重构，现在我们都是基于标准去做建模。另外，我们的数据质量问题也得到了大幅改进，尤其是数据质量稽核规则的完整度、覆盖率，因为集合规则是由系统自动生成的，不需要开发者自己编写。所以，一旦你的标准制定好，并与数据模型关联，数据模型上的数据质量稽核规则就会自动生成。

从管理者的角度来看，我们更关心的是数据的消费。简单来说，我们需要有量化的数据来作为衡量标准。我们会从计算价值、规范、质量、安全和存储的角度对各个业务线进行评分，以推动各个业务线更重视数据治理。我们需要这样一个衡量标准，来评估各个业务线在数据治理中的工作，包括其在价值、规范和质量等方面的表现。比如，如果他的数据质量稽核规则覆盖率很低，或者数据质量稽核规则经常出错，都会扣除他的分数。

当我们说数据是端到端的，这个"端"包括四个环节，设计、开发、消费和运营。运营是非常重要的环节。但是在企业内部，数据人员可能是一个相对弱势的群体。有时候，我们希望业务部门能使用数据，但业务部门可能会说他们没有需求或不需要数据。因此，我们需要举办一系列赛事，让企业内的每个人都能感受到数据的力量。比如，中国南方电网也采用了这样的模式，通过比赛来提高员工的数据意识，这对推广数据和平台非常有帮助。

4 小结

最后，我想给大家介绍几个外部客户案例。

第一个是浙江电信。虽然他们已经做了很多年的数据治理，有数据标准和数据质量的稽核规则，但是这些标准和规则并没有很好地打通。原因在于各个平台和工具之间完全不通。因此，他们重要的一步就是构建了开发、治理一体化的流程，从设计、开发、测试、上线到整个数据治理的标准化管控体系。

第二个案例是东北证券，他们做这个项目是为了推广和使用数据。他们的数据质量存在很大的问题，甚至整个企业都没有一个统一的数据资产门户。所以，他们开始进行全平台的打通和改革。全面展开了规范化建设。

第三个案例是中国人寿海外业务，一家位于深圳的国有企业。他们面临的问题包括效率极低，规范性差，平台割裂不统一，技术栈繁多，缺乏开发流程的管控，以及整体安全性管控的不足。为了解决这些问题，他们也采用了我们刚刚介绍的开发治理一体化流程。从业务探查、设计，到开发、测试、部署以及上线，他们成功地构建了完整的数据资产体系。

这样的实践不仅出现在互联网行业，也在金融行业、制造行业，甚至许多国有企业积极探索和落实。深层次的背景在于，每个企业都需要充分使用数据，需要高频度地使用数据，将数据作为生产过程中不可或缺的环节。有时候，如果数据的产出有所延迟，会有很多人在群里抱怨，这说明数据的重要性已经提高了，说明真的有很多人在用，很依赖它。最怕的情况是，当数据出问题时，却没人知道。

嘉宾 | 郭忆

编辑 | 李忠良

https://c.m.163.com/news/a/I9HHFMMJ0511D3QS.html