美高梅游戏官网app先设计后开发先标准后建模网易 DataOps 实践

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

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

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

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

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

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

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

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

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

　　第一个阶段，我们专注于数据中台内部的 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 级报表或数据产品，那么这个任务就需要走强制审核流程。

　　所以我们需要建立全链路的血缘关系，要能够去做全链路的影响分析，并且基于这种分析结。