数据工程成功的核心

作者 | 马小强，陈健

什么是数据工程

数据工程是软件工程的一部分，但不是传统软件工程在数据领域的简单重现。数据工程是一套完整的体系，其包含了需求探索、架构设计、平台构建、测试、维护演进等一系列阶段，涵盖了项目管理、开发过程管理、工程工具与方法、构建管理、质量管理等，是一套为了应对规模化生产和使用数据、为业务提供数据支撑，最终产生价值的体系。

数据工程与软件工程的差异

从广义来讲，数据平台也属于计算机软件的一种，只不过通常意义上我们所说的计算机软件是指应用程序、工具和库等，其主要目的是为用户提供功能和服务，以满足他们的个人或商业需求；而数据平台则是指用于存储、处理和管理数据的基础设施和工具集合。数据平台通常包括硬件、操作系统、数据库、数据仓库、数据湖、ETL管道、数据可视化和数据分析工具等，它们的主要目的是为企业提供可靠、高效、安全和可扩展的数据处理和管理能力，以支持业务决策和数据驱动的战略。这里我们将软件工程从产出物类型的角度划分为数据类和应用类，可以从如下三个视角来对比数据类和应用类：

• 使用方不同：数据类主要面向数据分析师、数据科学家等数据专业人士，提供数据处理、数据存储、数据分析等方面的技术支持，帮助用户从海量数据中提取有用信息，支持数据驱动的业务决策；而应用类主要面向企业的业务人员以及终端用户。
• 系统关注点不同：数据类主要关注数据处理、数据存储、数据分析、数据可视化等方面的技术，重点在于数据的准确性、完整性、一致性和安全性等方面；而应用类主要关注软件的功能、性能、可靠性和安全性等方面的技术，重点在于软件的功能实现、用户体验和代码质量等方面。
• 产出物不同：数据类的产出物主要是数据处理流程、数据仓库、数据分析报告、数据可视化报表等数据相关的产品和服务；而应用类的产出物主要是软件系统、软件模块、软件组件、软件文档等软件相关的产品和服务。

为什么要做好数据项目的工程化

虽然数据平台和应用类软件面向的用户不同、考虑的首要需求不同、面对的数据量和工具也不尽相同，但是要进行长久的运营，是一定要面对功能性、健壮性、易用性、拓展性、可维护性等关键指标，而要满足这些指标，就要进行科学的工程化。并且一般而言数据平台的生命周期也远远大于传统软件，所以，数据工程落地的好坏，直接关系到数据能否快速产生价值。

数据项目工程化是加速数据到价值过程规模化的最佳实践，那么我们就需要了解在实现数据到价值过程中所经历的数据接入、集成、清洗、处理、分析、使用等环节所涉及到的痛点和挑战都有哪些。

• 数据治理年年做，但又年年做不好。在面对多链路、多业态的企业数据平台中，需要接入众多部门/系统的业务数据，然而数据平台并不涉及业务流程，也就意味着数据的生产源头、流程、业务逻辑等信息的梳理、主题域的划分、数据血缘管理、元数据的管理等就显得非常重要。否则，就会遇到需求方不知道当前企业有哪些可用的数据，数据质量如何，数据由谁负责，当前数据做过什么样的处理，数据如何使用等问题。
• 如何降低数据平台的维护成本。在数据平台的维护过程中，业务/需求侧，会面临源头的业务梳理、业务变动、需求变动等；技术侧，需要维护分布式的数据平台基座，面对不同异常情况的数据处理，数据处理逻辑和数据的版本维护等。
• 怎么能高效地进行数据处理。高效地数据处理不仅仅是引入强大高效的计算引擎就可以解决的，需要考虑在常规和异常情况下如何能够处理“仅需要”处理的数据，从而避免造成时间和资源的浪费。
• 怎么设计才能满足业务的变动和快速变化的需求。数据平台如何进行分层，解耦，需要做哪些解耦，来响应变化和多样的需求场景。
• 数据平台如何赋能业务。数据平台找不到高价值的业务场景，无法清晰度量业务价值。
• ...

面对上述的痛点和挑战，仅仅使用大数据的相关组件是无法解决的，只有进行系统地设计规划才能做好数据项目的工程化。我们总结了多年数据工程交付的经验，提炼了一些核心思想，这些往往是大家在进行数据工程落地时容易忽略的点。

数据梳理

数据梳理就是要全域分析数据粒度，规划数据层次以及统一数据口径。这么做的目的是整理清楚数据所代表的业务含义、去除跨部门和跨场景在理解上的不一致、寻找使用数据和计算的统一口径、找到能够维护数据的管理者，最终构建在企业内部能够描述数据流转过程、数据变化过程的全景。这么做的好处是让数据使用者能够对数据的变化有全面的认识，对于后续数据项目开展提供扎实的基础。

数据的背后是信息、是业务知识，因此我们想要理清楚有哪些数据，就需要先对业务流程进行梳理，根据项目类型的不同需要梳理的业务流程范围也会有所不同，比如:围绕整个公司视角的梳理、围绕某个场景的梳理，但无论是哪种范围，都需要把业务流程梳理出来。业务流程的梳理仅仅是第一步，业务流程梳理的目的是在于产出基于业务流程关键节点有哪些数据，通常来讲我们需要精确到字段级。对于数据工程而言数据梳理可以从以下视角来审视。

• 数据分级分类。面对企业多业态、多链路复杂流程的场景下，会涉及不同角色不同部门的不同级别和类别的数据，因此在前期我们需要对齐数据的分级分类。数据梳理的核心其实是领域模型、实体模型和业务流程的梳理，需要从组织架构、业务流程等进行主题域的分组划分以及确定所涉及的实体和实体属性的信息。分级分类一方面可以更好的理解业务和数据，从而更清晰的得到数据全景图，为后续的数据处理和使用做准备，另一方面可以了解其数据分布，在运营阶段更好的进行数据管理。此外，基于数据的分级分类，可以更清晰的划分数据边界，帮助业务更好的梳理和优化业务流程。同时，也需要基于安全的视角对数据进行分级分类，从公开数据、内部数据、机密数据等级别进行划分，从而决定后续的数据共享策略。

• 统一口径。在上述梳理完数据的分级分类后，应该已经对整个业务流程所涉及的实体有了清晰的认知，那么口径的统一是在统一什么?这里提到的主要是实体的口径统一和实体内指标的口径统一。对于实体的口径，在业务系统的设计开发阶段，通常都是围绕业务流程进行，也就意味着并不会过多考虑同一个实体跨业务系统的定义，导致同一实体在不同业务系统的业务定义、业务边界等不相同，但是口语间的业务传递描述又是相同的实体，即相同现实世界中的实体在数据视角下的业务定义和边界可能不同。实体的边界划分通常是基于业务决定。对于指标的口径，通常在使用数据进行分析或数据挖掘时，指标信息的业务逻辑定义就尤为关键，在业务复杂的场景下，指标信息的定义从大分组上定义相似，但是又有细微的逻辑差别。
• 约定数据Owner。在业务流程中，不同的部门和系统会使用已有的数据，并可能会对已有的数据在某个业务流程的节点上进行修改，同时也可能基于现有数据产生新的数据。那么面对多版本、多边界的实体数据，如何保证使用数据的部门和系统所使用的数据就是所期望的数据呢?因此我们需要进行数据的owner梳理。这里与其说是梳理数据owner，倒不如说是梳理业务流程中不同实体的生命周期变化的关键负责人。当然这里所讲的数据并非一个实体，而是会细粒度到实体的某个属性，甚至是某个属性的某个值，如订单状态的值。同样，到底是粗粒度的实体还是细粒度的属性值定义边界，依然是由业务决定，即是基于业务流程中的核心节点来决定。通常来讲数据owner与数据在映射管理关系是一个一对多的过程，即一个数据owner会负责至少一个数据或者是一类数据。企业根据数据owner所处的部门、负责的业务域、所对接的业务部门、所处的权限级别，可以将分级分类后的数据域数据owner进行映射，形成企业自己的数据管理体系。数据owner需要定义数据的业务含义、业务边界、数据标准和数据的使用权限等。
• 构建数据标准管理流程。我们知道了要找谁来修改数据，可是如果数据被修改错误、或者是修改的不符合业务场景和标准，可能会引发一系列新的问题。我们约定数据管理者的初衷是能够让数据得到正确的修改，而不是引发新的问题。因此我们需要的是让数据管理者根据技术对数据的要求、业务对数据的要求对数据进行修改，所以构建的数据标准管理体系要包括数据标准、数据安全权重。到目前为止，我们有了管理数据的人、管理数据的方式，我们就拥有了可用的数据，无论是将数据提供给其他系统还是为即将开展的项目提供数据基础就已经具备一定的基础了。从数据使用的视角来看这些数据可以通过集中管理的方式来提供出去。

低运维

数据类平台最核心的功能就是计算数据，通常来讲，数据平台需要维护的数据流水线能达到上百条，要管理、维护几百条数据流水线的运维成本往往是最容易被忽略的。自动化是降低数据平台运维成本和提高效率的关键。通过自动化工具和流程，可以减少手动干预和人工错误。例如，自动化部署、自动化监控和自动化故障恢复等。自动化部署和自动化监控一般都有开源的实现数据组件可以实现，相对而言比较易于实现，但是数据流水线的自动化故障恢复则困难重重。常常会遇到数据计算到一半需要刷数据重新跑、难以debug等各种问题。我们将低运维中最重要的三个点摊开，帮助减少手动干预和人为错误，提高可靠性和可用性，并降低数据平台的运维成本。

1.幂等性

幂等性是数据流水线自动化故障恢复的核心，幂等性的定义是相同的参数重复执行得到相同的结果。ETL 的幂等性就要求 ETL 可以被重复多次执行，且不会影响最终的计算结果。在面对复杂的数据流时，数据处理过程中的异常或日常 运维需求都意味着 ETL 可能会随时停止、随时启动，那么如何在 ETL 重复多次执行的情况下确保数据的准确性和一致性就极为关键。满足 ETL 幂等性的核心逻辑在于处理数据阶段待处理批次的数据队列清晰有序且可控，同时对于所涉及数据要满足业务依赖。从运维视角看，运维人员可以在不同需求场景下对 ETL 进行手动触发，而不用担心是否会影响数据的准确性，从而可以在保证数据质量的前提下降低运维成本。从设计视角来看，则是要将调度依赖和数据依赖进行解耦，这样就能确保调度层面的异常不会影响到数据本身。从混沌工程的原则看，能确保在满足数据质量的前提下，降低计算资源浪费。

基于幂等性的大原则下，实现任务和调度的解耦，层与层之间的解耦，异常分级分类的解耦，都能实现低运维，同时可以保证任务的高效运行。这里的高效运行不是靠强大的计算引擎来提高任务的执行效率，更多指的是无需浪费额外的计算资源，实现任务处理的资源最小化原则。

2.日志分级分类

数据处理会涉及到任务调度服务、资源调度管理、计算、存储等多种技术组件，而在数据处理阶段，每一个组件的异常都会导致数据处理的失败，那么在定位问题时就需要去各个组件中查看问题的根源，这就导致了运维成本大大增加。因此需要将日志进行分类解耦，资源层面、调度层面、 计算层面、数据层面等不同数据问题进行分类，可以帮助我们更便捷地开展运维工作。同时，对数据的错误也进行了分级，在数据处理阶段，对于异常数据不能进行一刀切的方式处理，而应当根据业务来决定异常数据的错误级别，哪些数据可以流入数据平台，哪些需要被清理掉，在数据处理阶段需要明确定义各类数据错 误的处理规范。

在运维场景下，要求运维人员了解所维护的数据流水线中的各种业务上下文和实现细节是不现实的。那么如何做到面对复杂数据流、复杂组件和复杂任务的场景中，快速识别和定位异常问题呢？因此结合上述对于日志的分级以及数据层面异常分类，可以将复杂的运维场景进行切分，同时结合统一的门户或工作台进行日志查询，更好的实现低运维。 

3.完善的数据监控机制 

在数据平台的数据使用阶段，我们要尽可能的避免数据异常问题在数据使用阶段被暴露发现，这样不仅会导致平台的数据信誉度下降，异常数据流入下游系统或对一些分析决策造成影响，都会严重影响到业务。因此我们期望数据从开始接入到使用阶段，应当有完善的数据监控机制。在数据接入阶段，我们需要有识别上游变更的能力，即主动识别上游的系统变更、通道变更、数据结构变更等。在数据处理阶段，基于业务定义的错误数据的级别分类，配置不同的预警，确保需要业务配合的异常数据调整及时预警并调整数据。在数据使用阶段，通过贴合业务的数据测试自动化流程来识别异常数据。

完善的数据监控机制目的是为了将异常问题更早的暴露出来，同时可以推动业务系统或流程的完善。

数据测试

测试，是交付前必不可少的一道环节，是为了确保交付产物的正确性、完整性和安全性等而进行的一系列操作的过程，其最终目标是为了保证数据流水线的品质，对于保障软件的稳定性和可靠性具有重要意义。

测试金字塔理论是传统软件工程指导测试工作的核心理论，在数据工程领域，测试金字塔理论也同样适用，只不过需要进行一些改造。

我们将测试金字塔重新定义为：

• 单元测试为基础确保最小逻辑的准确。其涵盖两方面:一、数据工程的基础是 ETL，大部分数据工程均会有 一些工具来自动生成 ETL，而 ETL 自动生成代码，就必然少不了单元测试。二、有了 ETL 之后，ETL 内部 仍然是由多个功能活方法组合而成，针对 ETL 内部方法的单元测试仍然不可或缺。由于单元测试相对独立， 编码成本较低，可以以小的代价运行。并且 ETL 为数据工程事实上的基本单位，对其进行的单元测试可以 覆盖大部分细粒度的逻辑。 
• 分层测试确保单个模型的数据质量。在数据工程当中，为了快速响应变化、提高重复利用率以及减少性能瓶 颈，大部分的数据架构是纵向分层的架构，而不同层次有不同的数据处理逻辑，那么就需要先对每一层先进 行独立测试验证，再重点测试层与层之间的集成与功能。测试关注:元数据验证、数据值、处理逻辑与处理 性能等。在保证每层数据、逻辑正确的情况下，才能为更高层次的功能与数据质量提供保证。
• 数据端到端测试确保交付需求的质量。端到端测试是从数据源到最终结果的验证过程。覆盖了数据全链路层 与层之间的耦合逻辑。一般而言，从数据源头到最终数据应用链路很长，计算资源消耗也比较高，进行端到 端测试的方法一般是通过构建源数据，直接对比处理末端或应用端数据结果是否符合预期。数据端到端测试 虽然可以从最终结果上校验功能，但其存在成本较高，数据用例构造复杂度较高、发现 Bug 定位困难、运 行时间超长等弊端，所以这层一般更多的是进行 happy path 的验证与端到端性能测试，不会大范围覆盖所 有分支逻辑。
• 性能与安全测试。测试金字塔一般用来当做面向功能的测试策略。除了以上讲到的在金字塔内部的多层测 试，在数据领域，由于数据量巨大以及数据往往会涉及到各种机密与隐私，所以数据安全测试、性能测试同 样很重要。数据安全一般会根据具体项目情况涉及不同的测试策略，详情可参阅数据安全篇章。而数据性能 则是另一个比较重要的点，一般的步骤为:预计数据量级，构造数据、准备生产仿真环境、准备测试用例、 产出性能测试报告、分析与改造等。 
• 人员与能力标准。数据工程测试金字塔从下到上技术细节逐渐减少，业务含义逐渐增多，通常来讲，底层 ETL 测试主要由数据开发人员负责。中部数据分层测试由于包含对数据模型的验证，需要有一定业务理解能 力的人员参与测试用例的制定，一般由数据测试、数据业务分析师以及数据工程师共同参与。而顶层的测试 用例由于很少涉及编码细节，其测试基本可以由数据分析师和数据测试共同完成。 

小结

综上所述，做好数据项目的工程化具有重要的意义和价值。数据平台和应用类软件虽然面向不同的用户和需求，但长期运营的关键指标是功能性、健壮性、易用性、拓展性和可维护性，而科学的工程化可以满足这些指标。数据项目工程化是加速数据到价值过程规模化的最佳实践，因此我们需要了解数据项目中的痛点和挑战，其中包括数据治理、降低维护成本、高效数据处理、灵活设计以满足业务变化和赋能业务。