随着“数据要素X”、“人工智能+”计划的推出，新一轮的技术对产业产生了变革性的影响。近日，由中国通信标准化协会主办，中关村科学城管委会支持、中国通信标准化协会大数据技术标准推进委员会(CCSA TC601)承办的“2024DataOps发展大会”在京举办。

　　大会吸引了来自通信、金融、互联网等领域的业内学者、专家共同探讨数据治理相关前沿话题，进一步激活数据要素潜能。中国信通院云大所大数据与智能化部高级业务主管尹正在演讲时表示，DataOps作为数据工程的流程引擎，正在被更多企业重视，也将成为企业数据战略中必要的一环。

　　在会上，网易数帆产研负责人郭忆被中国信通院大数据技术标准推进委员会聘为“DataOps专家委员”，其本人及网易数帆在业内的领先成就与突出贡献受到认可。

　　作为DataOps长期、有积累的先锋和践行者，网易数帆拥有全面、稳定的大数据产品矩阵，引入DataOps理念和技术，搭建完整、成熟的工具链。去年3月，网易数帆与中国信通院云大所联合建设国内首个DataOps 创新孵化基地，共同完善标准体系，探索和沉淀优秀实践。去年11月，网易数帆成为首家通过中国信通院DataOps系统工具四项全部能力评估的企业。与此同时，网易数帆始终积极输出DataOps理念及能力，为各行业头部企业提供强有力的支撑，助力全面释放数据价值。

　　在大会现场，网易数帆产研负责人郭忆带来题为《网易DataOps最新实践:NoETL》的演讲。

　　以下为演讲实录：

　　首先简单介绍我所在的网易数帆。网易数帆是网易数智旗下的大数据业务，聚焦全链路数据开发、治理及分析，为企业量身打造稳定、可控、创新的数据生产力平台，服务“看数”、“管数”、“用数”等业务场景，盘活数据资产，释放数据价值。

　　接下来，我将重点介绍DataOps相关的实践，以及我们最新的成果与思考。在网易，我们经历了三个阶段：

　　一、DataOps 1.0实践：打造高效、高质量的数据开发流水线

　　第一个阶段（2019-2020年），我们的核心是构建数据开发、测试、发布到运维的流水线，称之为DataOps1.0版本。

　　当时我们遇到的最大挑战，主要来自数据开发团队内部的研发效率和数据质量问题。据统计，每年我们有300起数据质量问题，而65%是因为数据开发任务的变更导致，有30%的数据分析需求存在交付延期。

　　通过复盘，我们发现这主要是因为整个数据开发的过程缺少一个“范式”，尤其是在诸如数据测试、代码审查、发布审核、跨环境发布、数据沙箱、基线运维等关键能力中缺失。

　　我们解决这个问题的思路，就是借用软件工程领域非常成熟的DevOps方法论，将CI/CD引入到数据分析领域中来，结合数据开发的具体场景，从编码、编排、测试、代码审查、发布审核、部署上线以及任务运维，构建一个高效、高质量的数据开发流水线，最终形成一套效能平台，这就形成了网易DataOps最初的原型，后来我们将其定义为1.0版本。

　　DataOps 1.0 解决的核心问题，就是数据团队内部的交付效率和数据质量问题，而敏捷和高效就是它的关键词。

　　经过在网易内部实践，DataOps 1.0 大幅度降低数据开发过程中产生的数据质量问题，从原先65%降低到10%以内，需求的延期交付率从30%下降到1%以内。

　　二．DataOps 2.0：开发治理一体化

　　到了2021年-2022年，基本解决数据团队内部的开发效率和质量问题后，我们面临的核心问题是如何加速业务人员数据消费。

　　传统的数据治理往往是先污染后治理，运动式的治理，不仅治理成本高，而且治理效果难以持续。网易解决这个问题的核心思路，是将数据治理的过程前置到数据开发阶段，通过“先设计，后开发，先标准，后建模”，确保数据在生产环节就符合数据质量、数据标准、数据安全要求，从源头解决数据治理的难题。

　　所以，在这个阶段，开发治理一体化成为DataOps 2.0 的核心内涵。

　　原先，我们的数据团队接到一个分析需求，上来就开始确定数据来源业务系统，计算逻辑，抽数据，写代码，然后让需求方验数。但是其实，我们都不知道业务系统产生的数据是不是符合标准和规范的。

　　如果业务系统的数据本身就不符合标准规范，那我们辛辛苦苦算出来的那个指标，是没有任何价值的，甚至还会导致错误的商业决策。所以数据标准，是贯穿业务系统、数据中台的核心。

　　开发治理一体化的核心也都是围绕数据标准化展开的。我们在接到需求以后，应该花更多的时间和心思在设计阶段，而不是一上来就开发。在设计阶段，我们要围绕数据标准来开展模型的设计，如果我们是基于标准进行的数据建模，那就可以基于标准自动生成数据质量的稽核规则，也可以生成相应的数据的分类分级规则及数据脱敏规则。

　　那数据标准又从哪里来呢？主要是两个来源，一个是行业的标准，例如在证券、保险、期货行业，有SDOM模型；二是行业的其他同业竞争者的优秀实践；三是可以利用一些工具，通过对业务系统的探查，进行标准拾取。我们应该重点关注那些跨业务系统的字段，重点将这些字段进行标准拾取。

　　只要把前面的设计阶段、标准阶段做扎实，后面的开发阶段其实是越来越简单，越来越轻松，甚至未来开发可以实现自动化。

　　我们总结起来，DataOps 2.0在网易的实践，解决的最核心问题就是：找得到、看得懂、信得过、管得住，让数据走向业务，让业务人员能够感知到数据的存在。

　　首先，找得到。

　　构建以数据目录为核心的数据资产门户，同时构建“数据专辑”能力。数据用得好的人可以依据自身思维习惯组织、形成数据专辑，同时把它分享给其他同事，这样一来，经验就可以复用。

　　第二，看得懂。

　　如果元数据不完备、不标准，那业务团队一定难以理解。我们统计发现，网易内部元数据完整度偏低，只有78%。因此，我们建立数据注册、发布的全流程管控机制，将元数据完整度提升到100%，方便业务团队找得到、看得懂这些数据。

　　第三，信得过。

　　以数据标准为核心自动稽核，数据资产稽核规则完整度覆盖率达100%。

　　第四，管得住。

　　在互联网公司，一个表占几百T是非常常见的。据统计，原先我们有21%的数据在30天内都是零访问，而这些数据占据着大量的计算和存储资源，形成了极大的浪费。如果只上线表，不下线表，对数据成本和价值不做精细化管理，就会导致这样的浪费越来越多。

　　同时，在面对业务提出的各种紧急需求时，我们往往缺少有效的量化数据，去判断到底哪些需求是有价值的。通过构建ROI机制，我们可以清晰地看到，每个需求产生的成本以及被业务消费的情况，反向推动业务部门更准确地提需求，优先把更有价值的需求提出来。

　　三．DataOps 的新实践：NoETL

　　然而，在DataOps2.0时代，虽然采用了更高效、更科学的数据开发、治理体系，但是仍然无法改变的是：因为数据开发的门槛高，只要业务团队提出需求，都需要数据团队的专业开发人员承接、操作，不仅对IT资源占用程度高，也导致仍有大量的数据需求无法得到满足，数据资产也无法被激活和产生更多价值。

　　所以，从去年下半年开始，网易DataOps 的实践重点放在了降低业务人员用数门槛上，通过NoETL的方式，实现更广泛的数据资产消费。

　　在这之中，我们发现，指标中台是NoETL的优秀实践场景。为什么这么说呢？从数据分析架构的变化来看，在以往的传统的架构中（类似下图左侧），下方是数据仓库，上方是BI，BI承载数据可视化和大量的指标定义、指标计算的职能。但这容易导致BI指标口径不一致，并产生数据对不上、指标查询慢等问题。

　　所以，我们需要演化成右边的这幅图，也就是数据中台的架构。指标中台就是基于这一结构下，定位于公共层模型和BI之间的平台，核心解决指标的统一计算和管理问题。

　　关于指标中台，2022年，Gartner也曾在《指标中台创新洞察报告》(Innovation Insight: Metrics Stores)给出完整的定义：为业务决策和管理提供单一、可信的数据源，实现一次定义，多次复用，通过自动计算，解决指标重复开发带来的口径不一致的问题。

　　这当中的关键，就在于“一次定义，多次复用”。围绕这一点，我们在指标中台的搭建上考虑了四个方面：

　　第一， 拖拉拽配置化的方式生成指标，降低指标开发门槛；借助指标中台，业务人员也能通过配置化的方式完成指标的创建和分析，大大降低指标开发的门槛。从实际实践来看，有25%的数据分析类需求的实现可以不依赖专业数据开发。

　　第二， 一次定义，多次复用，消除指标口径二义性；一次定义能够在多个BI报表引用，保持业务口径、计算逻辑、数据来源一致，也便于集中化管理，避免重复计算。

　　第三，基于“物化视图”对指标预计算，提升查询分析速度；系统可以根据用户定义的指标，把可分析维度相同的一组指标以及这组指标的公共可分析维度构建出指标模型，再基于指标模型生成物化视图。用户在查询时，虽然可能只是查询单个或几个指标，但系统会识别到这些指标强关联的宽表，即物化视图，大大提升了用户查询速度。

　　第四，与BI集成打通，利于指标资产消费；指标中台定义指标后，业务人员可以通过可视化的方式，直接在BI工具上拖拽指标，用于数据分析、制作报表、报告。依据资产地图，业务人员还可以在指标平台上直接看到指标的相关数据，并按照不同维度进行根因分析，实现从数据的生产、开发、消费一站式的完整闭环。

　　四．指标中台在头部券商中实际应用成效

　　目前，网易数帆已经将DataOps的经验在金融等行业实践落地，并取得了明显的成效。以某头部券商为例，虽然积累了大量的数据，但在取数、用数的过程遇到了IT侧人力压力大、指标资产少、指标查询慢等问题。

　　针对此，网易数帆基于DataOps的理念，引入指标中台，梳理了如下的指标开发与管理流程图。

　　在此框架下，在业务团队中设置指标管理员，负责评估指标的需求并基于现有的数据模型，通过可视化配置的方式创建、发布指标，提供给业务团队直接使用。这样，专业技术侧的数据开发团队可以更加专注于公共层模型构建。

　　在该头部券商的实践过程中，我们发现指标中台的确带来了明显的效果：

　　第一，20%的数据分析需求可以不再依赖于技术人员，并且这一比例会随着模型完整度的提升而逐步提升。

　　第二，查询速度明显提升。通过系统自动制作物化视图管理，取代了原先依赖人工制作指标的宽表，用户可以直接查询几十个关联表聚合后的结果表，查询速度的提升是显而易见的。

　　第三，解决指标口径的二义性问题，构建了企业内统一、权威的指标口径管理机制。

　　第四，该头部券商的数据资产变现加速。截至目前已经沉淀指标2000多个，指标的开放和沉淀促进了基于指标的消费，UV达到300以上，也让企业内更多人能感知到数据资产的价值。

　　以上就是我今天的分享，谢谢。