数据生产力的愿景是构建“人人用数据，时时用数据”的企业数据文化，愿景代表的是目标和方向，支撑这个目标的达成，必然需要一系列的方法论。方法论，是以解决问题为目标，通过对具体方法的分析和总结，提出的一般性原则。方法论可以指引技术的发展方向。很多从事数据分析的人，容易沉溺于技术实现，而忽视技术背后的方法论。在数据分析的历史上，其实诞生过很多优秀的方法论，这些方法论指导了数据分析技术的不断演进和迭代。 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是目前相对成熟的数据治理的产品。
那为什么会有这样一个方法论的诞生呢？ 原来传统软件开发采用的是瀑布式软件开发模式，项目经理会将软件开发过程严格划分为若干个阶段，例如需求，设计，编码，集成，测试和部署，每个阶段都有序进行且依赖上个已完成的阶段。因为项目管理简单，流程清晰，该模式一度成为传统软件的标准开发模式。 但是随着互联网时代的到来，业务高速发展，让我们在项目开发过程中随时可能面临需求变更的问题，所以我们需要采取更加敏捷的方式应对变化中的需求，将一个大的目标拆成若干个可交付的小目标，通过不断的持续迭代，以”小步快跑”的方式实现持续交付，能够让业务不断看到新的进展的同时，阶段性验证成果，避免最后交付的软件与最初的业务需求大相径庭。 再者，因为瀑布式开发，所有的测试都集中在代码集成之后，导致发现问题时间过晚，软件要持续的返工，最终影响交付时间。一个比较理想的状态是在软件开发过程中就能够开始进行测试，开发和测试交替进行，代码一旦发生变更，通过自动化的方式构建可执行的代码包，自动化回归测试确保代码包的功能正确性和稳定性。 最后，原先代码部署上线，都是全靠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 DataFusionDataFusion是数据生产力的第二个方法论，援引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。