导读：2021年，网易数帆大数据团队正式提出数据生产力的理念，数据生产力从广义上讲，是指“通过使用数据，带来组织生产力的提升”;从狭义上讲，是指“数据采集、清洗、加工、可视化等数据处理和数据治理的软件生产能力以及持续运营能力”。
数据生产力的愿景是构建“人人用数据，时时用数据”的企业数据文化，愿景代表的是目标和方向，支撑这个目标的达成，必然需要一系列的方法论。方法论，是以解决问题为目标，通过对具体方法的分析和总结，提出的一般性原则。方法论可以指引技术的发展方向。很多从事数据分析的人，容易沉溺于技术实现，而忽视技术背后的方法论。在数据分析的历史上，其实诞生过很多优秀的方法论，这些方法论指导了数据分析技术的不断演进和迭代。
1、历史上出现过的方法论
1970年，IBM的研究员，有“关系数据库之父”之称的埃德加·弗兰克·科德(Edgar Frank Codd或E. F. Codd)博士在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks(大型共享数据库的关系模型)”的论文，文中首次提出了数据库的关系模型的概念，奠定了关系模型的理论基础。
1973年，Don Chamberlin博士在研发System R项目时，使用结构化英语查询语言作为关系数据库的操作语言，SQL由此诞生。关系数据库和SQL语言提供了基础的信息表达和统计能力，在此指引下，Oracle 无疑是关系数据库时代最成功的商业化产品。
在1991年出版的“Building the Data Warehouse”，数据仓库之父比尔·恩门首次提出数据仓库的概念，数据仓库是一个面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理决策。维度建模是数据仓库建设中的一种数据建模方法，由Ralph Kimball提出，是一种将数据结构化的逻辑设计方法，它将客观世界划分为度量和维度。维度建模是一种自下而上的建模方法，它是从需求出发构建模型，所以能够较好的应对快速变化的业务场景。
1993年关系数据库之父埃德加·弗兰克·科德提出联机分析处理的概念，即OLAP，它是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取，从而获得对数据更深入了解的一类软件技术。数据仓库和OLAP提供了构建部⻔级及企业级多维分析系统的方法，Apache Kylin™就是一个开源的、分布式的分析型数据仓库，提供SQL 查询接口和多维分析(OLAP)能力以支持超大规模数据的多维分析。
数据挖掘是基于人工智能、机器学习、模式识别、统计学、数据库、可视化技术等，高度自动化地分析企业的数据，做出归纳性的推理，从中挖掘出潜在的模式，帮助决策者调整市场策略，减少风险，做出正确的决策，常用的数据挖掘方法包括聚类、回归分析、偏差分析等，数据挖掘提出了超越基础统计的知识发现方法;
数据可视化主要是借助于图形化手段，清晰有效地传达与沟通信息。数据可视化技术的基本思想，是将数据库中每一个数据项作为单个图元元素表示，大量的数据集构成数据图像，同时将数据的各个属性值以多维数据的形式表示，可以从不同的维度观察数据，从而对数据进行更深入的观察和分析。数据可视化提供了有效利用人类直觉的信息呈现和知识发现方法。数据可视化技术广泛应用于以tableau为代表的BI分析工具中。
1996年全球顶级数据分析研究机构Gartner提出“商业智能”概念，它是将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具，它包含了数据仓库、联系分析处理(OLAP)和数据挖掘，是融合式创新的典范。商业智能提出了综合性的分析理论，定义了“描述-预测-解释-规范”等分析层次。在商业智能方法论的指导下，tableau、powerbi等被广泛的应用于企业的决策分析。
从2003年开始，作为全球最大的搜索引擎Google先后发表了Google File System，MapReduce，BigTable三篇论文，在其引领下大数据开始在互联网行业广泛应用。大数据提供了全体而非抽样、相关而非因果等思想，促成了从ETL到ELT的转变。在大数据的方法论的指引下，Hadoop成为最流行的大数据计算、存储基础设施。
数据治理(Data Governance)是组织中涉及数据使用的一整套管理行为，国际数据管理协会(DAMA)给出的定义：数据治理是对数据资产管理行使权力和控制的活动集合。数据治理主要从管理学角度提出了质量、标准、主数据、元数据、安全等众多领域的管理方法。Informatica是目前相对成熟的数据治理的产品。
2016年阿里首次提出数据中台的方法论，数据中台方法论包括OneModel，OneEntity，OneService，强调构建企业统一的数据公共层，由一个统一的数据中台组织负责实施。数据中台提出了组织角度的实践方案。
通过回顾历史中出现过的数据分析领域的方法论，我们发现任何方法论都不是一个孤立的个体，这些方法论之间都有着相互联系，例如商业智能中包含数据挖掘的方法，数据中台中包含了数据治理的方法。所以我们提出的数据生产力的方法论，它同样不是一个全新的概念，它是在前面的方法论基础上，融合了新的思想，进行的融合式创新。那接下来，我们就来看看，网易数帆提出的数据生产力的方法论，到底包含什么内容。
2、网易数帆数据生产力方法论
网易数帆数据生产力的方法论，我们将其称为3个Data：DataOps、DataFusion和DataProduct。
2.1 DataOps
在软件工程领域有一个非常经典且被互联网公司广泛推崇的方法论，叫CI/CD：可持续集成(Continus Integration)、可持续交付(Continus Delivery)和可持续部署(Continus Deployment)。
·可持续集成：是指开发人员将代码变更尽可能早的、高频的合入主干分支，且进行有效的测试，提高代码的发布频率。
·可持续交付：是指开发人员对于项目的变更代码， 可以通过自动化回归测试，构建出一个可被运维人员在生产环境部署的可执行包或者容器镜像。
·可持续部署：是指通过高效的自动化部署工具将代码发布到用户使用的生产环境。
那为什么会有这样一个方法论的诞生呢?
原来传统软件开发采用的是瀑布式软件开发模式，项目经理会将软件开发过程严格划分为若干个阶段，例如需求，设计，编码，集成，测试和部署，每个阶段都有序进行且依赖上个已完成的阶段。因为项目管理简单，流程清晰，该模式一度成为传统软件的标准开发模式。
但是随着互联网时代的到来，业务高速发展，让我们在项目开发过程中随时可能面临需求变更的问题，所以我们需要采取更加敏捷的方式应对变化中的需求，将一个大的目标拆成若干个可交付的小目标，通过不断的持续迭代，以”小步快跑”的方式实现持续交付，能够让业务不断看到新的进展的同时，阶段性验证成果，避免最后交付的软件与最初的业务需求大相径庭。
再者，因为瀑布式开发，所有的测试都集中在代码集成之后，导致发现问题时间过晚，软件要持续的返工，最终影响交付时间。一个比较理想的状态是在软件开发过程中就能够开始进行测试，开发和测试交替进行，代码一旦发生变更，通过自动化的方式构建可执行的代码包，自动化回归测试确保代码包的功能正确性和稳定性。
最后，原先代码部署上线，都是全靠IT运维人工操作，不仅效率低下，同时还因为各种人工操作疏漏，导致线上事故频发。随着业务服务架构升级，系统逐步从单体服务过渡到分布式微服务状态，原先运维管理的几个服务，变成了几百个，甚至上千个服务，每天都有大量的服务需要发布更新上线，完全靠人工的方式已经成为软件研发的瓶颈。通过自动化的发布工具将代码包发布到生产环境，成为必然的发展趋势。
在这样的背景下，可持续集成、可持续交付和可持续部署成为软件开发的必然选择，三者共同构筑了一个软件开发的流水线，以更高效的开发、更频繁的发布、更稳定的质量为目标，实现了开发、测试、运维一体化，也就是后来被频繁提起的DevOps。
那CI/CD 跟我们今天要讲的DataOps又有什么关系呢?如果我们把数据看作是一种软件，用软件开发的视角来审视数据开发的过程，我们会惊奇的发现，在这两个完全不同的技术领域，竟然面临着相似的问题。
首先，数据分析支撑的是企业日常运营活动，由于运营更加趋向于高频且常态化，我们在淘宝上每天都能看到各个商家在搞各种促销活动，企业对数据分析的结果时效性要求越来越高，一个活动从上线到下线可能只需要几天时间，在活动过程中，可能还面临的活动策略需要不断调整，数据分析的需求也面临随时变化，我们必须使用更加敏捷迭代的方式，才能满足业务数据分析快速试错的需求。
其次，数据的正确性校验比软件功能校验更加复杂，每个任务都依赖其上游任务的数据产出的正确性，所以更加需要在每个任务开发完，就能够及时的对数据进行验证。但是很可惜，我们发现在数据开发领域，数据测试还大量依赖数据开发的手工测试，这不仅导致测试的质量面临很大的风险，还导致测试的效率非常低下，也难以做到每个任务开发完就能够及时的验证数据。据网易内部业务统计，有超过50%以上的数据线上事故都是由于数据开发的任务变更引起的。所以，数据开发也需要将自动化测试融入开发流程中。
最后，数据领域同样也面临着架构的升级，原先烟囱式的数据架构逐步过渡到数据中台模式下高度复用的公共数据分层架构，一个大的任务被拆分成若干个小的可独立调度运行的任务，任务之间相互依赖，任务发布的频率和复杂度大幅提升，对自动化部署提出更高的要求。
基于这样相似的一个背景，我们不妨用相同的解药跨界应用在数据开发的领域，至此便有了DataOps。DataOps 其实并不是网易数帆第一个提出来的方法论，早在2014年，InformationWeek的特约编辑Lenny Liebmann 在“ DataOps对大数据成功至关重要的三个原因”中首次提出了DataOps的概念。DataOps(数据操作)是一门新兴学科，将DevOps团队与数据工程师和数据科学家角色结合在一起，提供一些工具、流程和组织结构服务于以数据为中心的企业。
DataOps 真正被业界开始广为熟悉，要到2018年，Gartner 正式将DataOps纳入到Data Management技术能力成熟度曲线，作为全球顶级权威研究机构，Gartner对DataOps定义如下：
“DataOps is a collaborative data management practice focused on improving the communication, integration and automation of data flows between data managers and data consumers across an change management of data, data models and related artifacts. DataOps uses technology to automate the design, deployment and management of data delivery with appropriate levels of governance, and it uses metadata to improve the usability and value of data in a dynamic environment.”
这个定义中值得我们关注的是，DataOps 的目标是实现更敏捷的数据交付，运用的技术手段是自动化设计，部署和交付，同时Gartner 强调DataOps必须要结合基于元数据的数据治理。
Wiki 对DataOps 定义如下：
“DataOps is an automated, process-oriented methodology, used by analytic and data teams, to improve the quality and reduce the cycle time of data analytics. ”
Wiki对DataOps的定义目标非常明确，DataOps的核心是减少数据分析的周期，改善数据分析的质量。
下面是来自Techopedia的定义：
The DataOps approach seeks to apply the principles of agile software development and DevOps (combining development and operations) to data analytics, to break down silos and promote efficient, streamlined data handling across many segments.
DataOps是一种敏捷的软件开发模式，它将DevOps理念应用于数据分析领域，打破了数据孤岛，促进了数据处理的效率。
从各种对DataOps的定义来看，大家对DataOps的一个核心共识，就是DataOps追求的是敏捷、高质量的数据需求交付。网易数帆对DataOps的定义是，DataOps是一种将软件工程CI/CD的方法融入数据开发的流程，基于自动化的数据测试、任务发布等技术，构建数据发布流水线，使得数据开发效率更高、交付更加频繁，交付质量更有保障。
DataOps的核心是要构建一条数据发布的流水线，接下来我们要讨论的是应该如何构建这条流水线。我们不妨再次参考一下软件开发领域的DevOps，看看DevOps 的流水线包括哪些环节。
软件开发的流水线以编码作为起点，紧接着是代码构建，单元测试，集成测试，全部通过后代码才能被合入主干分支，此时可持续集成阶段完成。然后进行代码的发布，首先需要进行代码的审核，经过审核后的代码被打包成可用于生产环境执行的发布包，这个阶段为可持续交付阶段。最后通过自动化部署工具完成发布包在生产环境的部署，可持续部署完成。
如果我们参照软件开发的流水线构建一条数据开发的流水线，可以同样将数据开发划分为以下几个阶段。
编码：DataOps 同样以编码作为起点，为了支持高效的代码开发，必须拥有一个能够支持丰富的算子进行数据开发的IDE。IDE需要具备代码格式化、语法检查、高亮显示、代码执行、执行结果展示、日志跟踪等功能。同时代码还必须具备多版本管理的能力，能够进行不同版本的差异对比。另外数据开发与软件开发的差异，在于数据开发存在大量的UDF，所以必须有一个统一的UDF 开发和管理的工具。此外，任务模板也是编码阶段不可缺失的技术能力，因为很多数据清洗任务可以抽象为任务模板，只需要通过参数化的注入表名称或者字段名称，就可以完成任务代码的复用，对于提高编码效率非常重要。
编排：在数据中台的模式下，任务被切割为很多不同的子任务(Job)，多个Job可以被编排为一个工作流(Flow)，Flow可以被设置周期性调度。最常见的编排是基于时间的调度模式，可以通过任务依赖实现有相互数据依赖关系的任务有序进行。但是基于时间的调度会产生很多的间隙，一个比较理想的状态是能够直接根据任务的依赖关系进行调度。另外任务的依赖需要通过数据血缘能够自动识别，减少创建任务依赖的复杂度。同时，任务运行参数的配置和管理，需要引入参数组的方式，一个参数组是可以被多个job或者flow共享的参数列表，通过修改参数组中的参数，就可以控制多个job或者flow的参数变更。最后在数据开发过程中，还经常需要引用一些Jar，通过资源组的方式，可以将这些jar方便的在不同的job或者flow中引用。
测试：测试是数据开发最容易被遗漏的环节，数据测试的目标是验证数据的正确性。常见的数据测试主要包括3类。第一类是数据形态探查，它主要是通过对数据的扫描，对主键是否唯一、空值\零值比例、枚举值的分布比例、字段的均值、最大值、最小值等给出分析报告，通过报告，我们可以清楚的了解数据形态，发现可能存在的数据质量的问题。数据形态探查既可能发生在数据开发任务之前，尤其是当我们刚刚从业务系统源数据库抽取数据到ods层时，我们需要通过探查任务了解源系统的数据分布，为后续制订数据标准，进行数据建模提供依据。同时，数据探查也可能发生在我们开发任务之后，我们需要对产出数据进行探查，确保符合设计预期。第二类常见的数据测试是数据比对。对已经发布的模型进行局部的修改，例如增加或者删除字段，是数据开发非常常见的现象。我们经常关注新增的字段是否逻辑正确，但是往往会忽略这种调整可能会影响已经存在的字段，导致未修改的字段的产出数据被修改，最终影响了下游依赖的任务。所以我们必须要通过数据比对，去分析对比一个模型修改前和修改后，数据变化是否符合预期，对于未修改的字段，要确保修改前和修改后数据是完全一致的。数据比对，通过全量或者抽样扫描，针对每个对比字段，给出一致性比例。最后一类数据测试就是自动化回归测试。由于在数据中台中，为了避免烟囱式的数据开发，我们设计了高复用的公共数据层，任务之间依赖大幅度增加，我们不仅要确保我们当前开发的任务正确性，还要同时确保下游任务的逻辑正确性。所以我们需要通过在测试环境，运行当前任务，自动调起下游的任务，通过每个任务上配置的稽核规则，校验数据的产出逻辑是否符合预期。数据测试，除了测试技术本身之外，另外一个难题在于测试数据的准备，一般在企业级数据平台架构中，开发环境和生产环境会独立部署两个物理集群，但是如果每次做数据测试，需要将生产集群的数据全量导入到测试集群，那将会非常影响测试的效率。所以一个比较理想的架构，就是我可以在开发集群，直接使用生产集群的脱敏数据进行验证，而不需要去导入生产集群的数据，此时就需要引入数据沙箱的技术，确保在开发集群，可以直接运行任务，读取生产环境脱敏数据进行测试，同时又只能写入开发环境，避免了污染生产环境的问题，既保证了两个环境的隔离，又解决了跨环境数据测试的难题。
代码审查：任务发布之前，我们需要对代码进行的审查。代码审查主要有系统和人工两种方式。SQL Scan是一种系统静态代码扫描技术，通过自动扫描任务代码，我们可以发现很多规范类、语法类的问题。例如我们在代码提交上线时使用了固定的分区，未替换成调度时间参数，这种情况在测试提交到生产的时候尤为常见，因为我们在测试阶段经常使用固定分区的方式调试，到生产环境又要将这些固定分区替换成时间参数，由于生产环境的代码可能非常复杂，有上百行，所以经常遗漏，通过静态代码扫描可以很容易发现此类问题。人工的代码审查就是我们日常经常讲的CodeReivew，一般是有由另外一名有经验的代码开发人员对代码进行阅读，在阅读过程中针对代码的编码规范、逻辑正确、异常处理、抽象封装等问题进行审查，对于发现的问题，需要在代码发布之前进行修复。一般来说，CodeReview需要包括代码完整性检查、代码一致性检查、代码正确性检查、代码可维护性检查、代码可预测性检查、代码健壮性检查、代码结构性检查、代码可理解性检查、代码可验证性检查。在实际操作过程中，CodeReview是容易被忽略的环节，主要是因为大部分的CodeReview的过程都是在线下完成的， 如果我们可以将CodeReview作为一个检查项融入到代码的发布流程中，同时对Review的人在任务出现问题的时候进行追责，就可以确保该项工作可以高质量的完成。
发布审核：任务发布上线需前要经过发布审核流程，一方面是提高任务发布规范性，确保相关的人和各级主管都能够了解发布过程，有完整的上线发布记录，另外一方面也是再次对发布过程进行审核，例如调度的配置信息，报警配置信息，代码是否经过完整的测试，稽核规则是否配置正确等进行审核。发布审核的对象是发布包，所以首先需要生成发布包，一个完整的发布包既要包括任务代码以及相关的调度配置、参数配置、报警配置等，同时还应该包括任务相关的模型。在实际操作环节，经常会出现模型发布了，任务忘记发布，或者任务发布，模型遗漏的情况，所以通过发布包的形式，可以有效杜绝此类问题。发布包同时需要支持多版本，可以实现不同的版本的一键发布。在数据中台模式下，任务依赖层次增多，经常会出现修改上游任务，影响下游任务的情况，所以在发布包正式发布前，必须要经过基于数据血缘的全链路影响检测，一方面，是明确发布包的影响范围，通过影响的下游数据的重要性(一般是依赖数据资产等级)以及数据上的资产标签，确定发布审核的流程，例如如果检测到下游链路中涉及带资损的表，则需要在发布审核流程中增加数据中台负责人的审批。另外一方面，检测到受影响的下游表之后，被影响的下游表的负责人或者应用的负责人同样可以受到上游任务发布变更的通知。所以全链路的影响检测对于发布审核来说非常关键。最后，如果所有的发布包都需要经过非常繁杂的审核发布流程，会大幅度影响发布的效率，所以一个比较理想的方式，是结合受影响的数据的资产等级来构建发布的审核流程，根据不同的资产等级，制订不同的审核流程。当然，我们还可以在表上增加一些资产标签，例如资损，财报之类的，可以基于下游影响的表的标签，制订审批流程。审批过程本身要支持多级审批。
部署上线：数据发布流水线的最后一个环节是部署上线。在金融级的数据平台架构中，除了有开发集群和生产集群，还有测试集群和预发布集群。预发布集群和生产集群都属于线上环境，由运维管理。开发集群和测试集群属于非生产环境，由开发管理。生产环境和非生产环境网络完全隔离。发布包在非生产环境经过审核后，导入预发布集群，在预发布集群运维可以使用生产集群的脱敏数据进行线上仿真测试，验证通过后发布到生产集群。通过预发布集群的验证，我们可以在任务部署上线前直接使用真实生产数据进行验证，发布质量得到进一步增强。由于资源竞争导致任务之间的相互影响是线上任务产出时间不稳定的一个重要因素，为了确保核心任务能够更优先的获取运行资源，所以必须要借助基于优先级的运行资源调度策略。同时对于海量任务的日常管理，我们也必须要通过基线的方式进行运维。基线，代表的是中台承诺的最晚任务产出时间，我们把任务挂载到基线上，然后按照基线的方式，监控任务的完成进度，在大规模任务运维中非常实用。此外，由于日常的任务运维和任务开发往往不是一个人，为了提高异常问题的排查效率，我们必须要能够有任务智能诊断的能力，基于错误的异常堆栈，可以快速的定位问题，有效提高运维效率。
这六个环节共同构建了一个数据发布流水线，在保障质量的前提下，实现了数据开发的敏捷交付。在整个流水线中，实际涉及到了多个角色，包括开发、测试、运维等，一个成熟的DataOps工具，必须构建在一个流程引擎之上，而流程引擎可以完成数据流水线上不同角色之间的相互协作。同时参照DevOps，当整个流水线打通的同时，配套需要建设的一定是效能平台，统计各个阶段，各个角色的耗时，实现需求的全流程跟踪和项目管理。
DataOps是数据中台架构下对数据研发的必备要求。其一，数据中台对需求交付效率要求非常高。数据中台构建了一个企业的公共数据层，同时也限定业务必须基于这个公共层去分析数据。如果这个公共层无法快速满足业务的需求，那必然会面临业务的严峻挑战。同时，由于数据中台的终极目标是让数据更广泛的使用起来，必然面临着需求爆炸式增长。DataOps提供了一种更为敏捷的数据交付模式，可以快速满足业务需求。其二，数据中台对质量要求严苛。在数据中台模式下，数据高度共享，任务依赖繁杂，一旦某个任务出错，可能导致下游成百上千个任务或者应用无法按时产出，所以数据中台，必须要依赖DataOps提供的数据测试、代码审查和发布审核过程，确保数据高质量产出。
2.2 DataFusion
DataFusion是数据生产力的第二个方法论，援引Wiki对Fusion的定义，“Fusion, is the process of combining two or more distinct entities into a new whole.” Fusion 意味着两个不同的个体组合成一个新的整体的过程。之所以取名Fusion，就是因为在原先的数据开发过程中，因为烟囱式的开发模式，导致数据架构上形成了很多数据竖井，为了解决指标口径的一致性，提效降本，沉淀企业的数据资产，我们需要构建企业的公共数据层，也就是我们经常听到的数据中台，通过数据中台的方式重塑我们的数据架构，这个过程与Fusion所要表达的融合之意相同，所以我们取名为DataFusion。
既然DataFusion是数据中台建设方法论，那在数据中台建设上，业界还有哪些成熟的方法论呢?
数据中台业界最被熟知的方法论，就是阿里的OneData体系，在2019年云栖大会上，阿里官方对OneData体系给出了明确的定义，OneData体系的核心包OneModel，OneEntity和OneService。
OneModel，统一模型构建与管理。通过全域数据集成、数据分层架构、业务视角标准规范定义数据和处理数据，致力于统一数据口径、消除指标二义性;OneModel将数据模型作为数仓构建的基础，以Kimball的维度建模作为基础建模方法论，在此基础上，抽象业务过程，划分主题域，构建总线矩阵，设计明细表和一致性维度表，然后定义原子指标，修饰词，派生词，最终可以通过自动化的方式生成可用于业务分析的派生指标。OneModel的优势，一方面从根本上解决了指标口径二义性的难题，另外一方面，通过设计高度规范、可复用的数据模型，达到了数据开发降本提效的目的。但是也要特别指出的是OneModel 在宣传中会过分的强调自动化代码的构建，实际上代码的自动化构建是发生在明细数据表构建完成之后，自动化并不能完全取代数据清洗和原子指标的开发过程。此外，OneModel中虽然也有对表命名、字段命名的规范性要求，但是相比数据标准，缺少对每个字段，甚至是字段内容的规范化约束。
OneEntity，核心商业要素资产化。以业务和自然对象为基础，以标签数据为核心，能够实现全域实体识别与连接，数据价值深度萃取，助力企业构建标签体系、完成核心商业要素资产化;这里的核心商业要素指的是什么呢?对电商平台来说，最重要的当然就是人、货、场。OneEntity有两个重点，第一个是对于核心商业要素，全域要有唯一的标识，且基于这个标识，可以实现不同业务过程的数据连接，支撑全域数据分析。简单的来说，就是在供应链仓储管理业务流程中的商品ID和在交易下单业务流程中的商品ID必须是一致的，这其实用数据治理的视角来看，属于主数据的范畴。第二个重点，是基于这个核心商业要素，构建丰富的标签体系，且这些标签可以作为企业的数据资产，可以让每个业务都能够使用。
OneService，统一数据服务。即由数据中台提供统一的数据接入和数据查询服务。统一出口的目的，是为了实现数据规范化交付，提高数据接入的效率，屏蔽底层的异构数据源，提供基于逻辑表的主题式查询服务。
从OneData体系中我们能够看到很多传统数据治理的身影，例如在OneModel中有部分数据标准的因素，在OneEntity中又有主数据的因素，当然OneData体系本身对数据治理进行了进一步的创新，例如全域数据标萃取和数据服务化，这些都是互联网数据智能场景中经常用到的技术，可以说OneData是互联网版的数据治理。当然这种经验对网易数帆的数据生产力建设也非常具有指导意义，DataFusion 继承自OneData体系，同时又在OneData体系中又融入了具有网易数帆特色的实践。
网易数帆OneFusion 方法论具体包括以下内容：
(1)构建统一的指标管理体系
指标是数据和业务的交汇点，是数据分析需求的载体。如果指标口径定义不一致，就会导致看数据的人对数据的理解产生很大的障碍，最终导致数据失去分析价值。确保指标口径一致，就必须要实现指标的统一管理。指标统一管理需要组织架构、流程规范和工具产品的三者结合。首先，要有能够统一管理指标的组织，这个组织必须是跨业务部门的，一般就是数据中台部门。其次，要有统一的指标管理流程规范，包括指标的规范化定义，指标分类管理以及审批流程等。最后，指标的管理必须还要有与规范相配合的工具产品。
(2)设计高复用、规范的数据模型
网易数帆同样认为数据模型是构建数据中台的基石，推崇基于维度建模的数据模型设计的方法论。但是网易数帆认为，一个面向数据中台的模型设计，必须有一套可以量化的衡量标准，能够评价当前数据模型设计的质量。网易数帆推荐的数据中台的建设方式是采用迭代式构建，所以必须要对建设过程中模型的设计质量进行持续跟踪，确保模型的设计符合数据中台建设的规范和高复用的设计目标。为此，网易数帆提出了业界首个面向数据中台的模型设计标准，提出通过跨层引用率、模型引用系数等指标评价模型设计质量。
(3)基于ROI的数据资产沉淀
网易数帆认为一个企业中并不是所有的数据都能称之为数据资产，数据资产需要通过ROI的方式进行精细化管理。我们需要从数据应用的角度，计算整个数据加工链路上每个模型、任务消耗的资源，同时还要基于这个模型以及下游应用的用户使用情况进行价值衡量，最终要沉淀高价值的数据作为资产，消灭高成本低价值的数据。在数据中台模式下，数据分析需求一定面临井喷式增长，在有限的资源内，如何实现价值的最大化，必须依赖基于ROI方式的精细化管理。
(4)组合式数据服务
网易数帆认为数据服务一方面作为服务网关，提供了鉴权、日志、限流、熔断等能力，实现了数据的规范化交付，提高了数据交付的效率。同时，数据服务还必须具备编排的能力，通过API之间的组合，可以创建出满足不同应用场景的服务。此外，数据服务还能够提升数据管理的效率，数据服务打通了数据应用和数据模型的血缘，实现了数据血缘从源系统到数据应用的全链路覆盖。一方面出现问题的时候，数据中台可以快速评估影响范围，另外一方面，也可以通过数据服务，快速的对脏数据进行止损。
(5)数据标准化
网易数帆认为在数据规范化建模之前，还要增加数据标准化作为前置步骤。在数据标注的制订过程中，需要明确每个数据元的唯一标识，枚举值范围，值域约束等。基于数据标准，一方面我们可以进行规范化建模，数据元可以形成数据模型中的字段。另外一方面，数据标准对应的值域约束，可以形成稽核规则，在模型上线后进行生产环境的稽核监控。
(6)主数据治理
主数据是指参与业务事件的主题或者资源，是具有高业务价值的、跨流程和跨系统重复使用的数据。虽然一般意义上认为，主数据的建设并不在数据体系构建的范围内，它是面向业务系统的，但是主数据却深刻影响着数据分析的质量。我们经常会发现不同业务过程中的相同实体标识不一致，最终导致无法跨业务流程联合分析。一般来说，构建企业全域实体数据标识统一有两种方式，第一种是通过主数据的方式，保证业务系统产生的数据本身就是统一的。第二种方式是在数据中台内部通过算法映射的方式进行转换连接。但是前者治本，后者治标。
2.3 DataProduct
虽然Tableau倡导的敏捷式自助分析极大的提升了数据分析的效率，但是不可否认的是Tableau的主要使用者还是一些数据分析师。前面我们提出，数据生产力的目标是实现人人用数据，时时用数据，要让能够参与企业运营的一线业务人员也能使用数据，网易数帆认为达成这样一个目标，就必须通过数据产品的方式实现。
数据产品的核心思想是打造一个数据驱动的业务决策执行的闭环。数据产品首先要完成数据组织，数据的组织结构中包含了用户应该要看哪些数据，看数据的逻辑是什么。接下来会进入一个循环，这个循环的起点是监控数据，发现异常指标。然后是针对异常指标进行根因分析，找到问题的原因。再下来就是根据原因，产生计划建议，这个时候要告诉用户，应该如何做才能解决问题。最后是用户采纳该建议，完成决策执行。
围绕这个流程，DataProduct 包含以下内容：
通过“数据门户”组织数据，聚焦业务场景。我们看到一个企业中，经常会存在多个BI工具，每个BI工具的报表的组织是通过目录树的方式进行组织，目录可能是分析师个人，也可能是组织部门，这样的一个数据分布非常零散，对一线业务人员来说，使用数据的成本非常高，他必须要知道我要看哪些数据，知道去哪里看这些数据，最终可能就导致他没办法真正去使用这些数据。解决这个问题的关键，是我们要从业务过程的视角去组织数据，而数据门户是数据组织的载体。
例如，在严选，我们针对不同的业务场景，设计了一系列的数据产品，在商品运营场景中，我们有大麦，在用户行为分析场景中，我们有神相，在供应链场景中，我们有河洛，在商品舆情监控场景中，我们有谛听，在市场渠道管理场景中，我们有刑天。这些数据产品，共同构建了严选全场景的数据消费，满足了不同场景下数据分析的需求。对于一个业务人员来说，他可以根据他从事的业务，去选择对应的数据产品，了解整个业务数据分析的思路。当然数据门户并不局限于PC端，我们为了服务于严选管理层看数，设计了VipApp，可以随时随地的看到管理层希望看到的数据。
通过“智能预警”，发现业务问题。针对核心指标，可以设计灵活的规则，基于规则设置预警策略，进行实时监测，发现异常的数据，从而监控整个业务过程。例如，我们在商品运营场景中，商品销量是一个核心指标，我们设计一个规则，就是监控近7日主站在架商品0销量(不含赠品)的天数，预警策略就是大于等于3天，通过该异常监控，我们能够发现所有主站慢动销的商品，而这些产品是属于需要运营介入处理的商品。
通过“异动分析”，并找到问题原因。针对慢动销的商品，我们必须找出慢动销的原因，才能采取有效的措施进行干预。根因分析，首先要对指标进行拆解，指标拆解的方法可以参考经典的杜邦分析法，在前面的例子中，我们可以从转化分析的角度将商品销量按照支付用户数、人均支付件数进行拆解，支付用户数又可以进一步按照访问uv和转化率进行拆解。对于转化率我们又可以按照商品因素进一步拆解为sku缺货率和商品累计差评率以及商品详情页质量等因素。通过逐层分析，我们最终可以找到慢动销商品的原因。
通过“决策引擎”，将数据转化为有效决策。根据根因分析的结果，我们可以采取不同的措施进行干预。数据转化为决策可以依赖规则，也可以依赖算法。基于规则的就需要提前预置好决策流，基于决策引擎，发起计划建议。例如，在前面例子中，我们发现是商品缺货率最终导致了商品转化率下降，那就应该发起补货建议，根据过往的销量，我们可以设计规则，补多少货，向谁补货。
通过“机器学习”，智能化产生计划建议。在一些复杂的场景中，我们有必要借助一些机器学习算法来提升计划建议的精准性。例如在前面的案例中，我们也可以借助算法，实现销量预测，根据预测的结果发起最终的补货建议。
通过“连接中心”，完成决策执行。决策最终是要在业务系统中完成执行落地的，所以我们必须要将数据产品产生的决策建议能够方便的推送到业务系统中，完成决策的执行落地。例如，在前面的例子中，最终的补货建议必须推送给采购系统，在采购系统中完成补货流程，这个连接可以通过API的形式进行集成。
数据产品的设计必须结合业务场景，我们根据不同的业务场景，可以构建出一个企业的全场景数据产品矩阵，最终实现人人用数据，时时用数据的企业数据文化愿景。
3、数据生产力方法论与过往方法论的关系
从数据分析发展的历史轨迹来看，任何一个有生命力的方法论，它都不是凭空出现的，数据生产力的方法论也是如此，它是在过往数据分析理论的基础之上进行的融合式创新，与历史上的数据分析的方法论一脉相承，汇集了主流数据分析方法论的核心要素。
在DataOps要构建的数据发布流水线中 ，需要用到大数据、数据仓库和关系数据库的相关技术。在DataFusion要建设的企业公共数据层中，包含了数据中台、数据治理的相关内容。在DataProduct 所要构建的全场景数据产品矩阵中，包括了商业智能、数据可视化以及数据挖掘的相关理论。数据生产力的三大方法论，是支撑我们实现“人人用数据，时时用数据”这个愿景的指导原则。
作者简介：孙仲谋，网易数帆大数据专家，大数据平台负责人，曾任网易云数据库产品负责人，十多年互联网数据研发和管理经验，网易数据中台建设的亲历者和实践者。
