数据工程和软件工程长期以来一直存在分歧，各自都有自己独特的工具和最佳实践。一个关键的区别在于，在构建数据产品时需要专用的编排。在本文中，我们将探讨数据编排器所扮演的角色，以及该行业的最新趋势如何使这两个学科比以往任何时候都更紧密地结合在一起。
数据编排的现状
投资数据功能的主要目标之一是统一整个企业的知识和理解。这样做的价值可能是巨大的，但它涉及集成越来越多的系统，这些系统的复杂性通常会增加。数据编排为组合这些系统提供了一种原则性的方法，其复杂性来自：
- 许多不同的数据源，每个数据源都有自己的语义和限制
- 数据产品的多个目标、利益相关者和使用案例
- 创建最终产品所涉及的异构工具和流程
典型数据堆栈中有几个组件可帮助组织这些常见方案。
组件
数据工程的主流行业模式称为提取、加载和转换 （ELT）。数据 （E） 从上游源提取，（L） 直接加载到数据仓库中，然后 （T） 转换为各种特定于域的表示形式。存在变体，例如 ETL，它在加载到仓库之前执行转换。所有方法的共同点是三个高级功能：摄取、转换和服务。需要协调这三个阶段之间，但也需要在每个阶段内进行协调。
摄入
摄取是将数据从源系统（例如数据库）移动到存储系统的过程，以便转换阶段能够更轻松地访问数据。此阶段的编排通常包括将任务安排在需要新数据上游时运行，或者在数据可用时主动侦听来自这些系统的通知。
转型
转换的常见示例包括从原始结构中解压缩和清理数据，以及将其拆分或联接到与业务域更紧密一致的模型中。SQL 和 Python 是表示这些转换的最常用方式，现代数据仓库为它们提供了出色的支持。在此阶段，编排的作用是对转换进行排序，以便有效地生成利益相关者使用的模型。
服务
服务可以指非常广泛的活动。在某些情况下，最终用户可以直接与仓库交互，这可能只涉及数据管理和访问控制。更常见的是，下游应用程序需要访问数据，而这反过来又需要与仓库的模型同步。加载和同步是业务流程协调程序在服务阶段发挥作用的地方。
图 1.从源通过数据仓库到最终用户应用程序的典型数据流
摄取引入数据，在仓库中进行转换，并将数据提供给下游应用程序。
这三个阶段构成了用于分析系统的有用心智模型，但对业务来说重要的是它们支持的功能。数据编排有助于协调从源系统（可能是核心业务的一部分）获取数据并将其转化为数据产品所需的流程。这些流程通常是异构的，不一定是为了协同工作而构建的。这可能会给编排器带来很多责任，使其负责制作副本、转换格式和其他临时活动，以将这些功能整合在一起。
工具
从本质上讲，大多数数据系统都依赖于一些调度功能。当只需要在可预测的基础上管理有限数量的服务时，一种常见的方法是使用简单的计划程序，例如 .以这种方式协调的任务可以非常松散地耦合。在任务依赖关系的情况下，很容易将一个任务安排在另一个任务预计完成之后的某个时间开始，但结果可能对意外延迟和隐藏的依赖关系很敏感。cron
随着流程复杂性的增加，明确它们之间的依赖关系变得很有价值。这就是 Apache Airflow 等工作流引擎提供的。Airflow 和类似系统通常也被称为 “编排器”，但正如我们将看到的，它们并不是编排的唯一方法。工作流引擎使数据工程师能够指定任务之间的显式排序。它们支持运行计划任务，这与运行计划任务非常相似，并且还可以监视应触发运行的外部事件。除了使管道更加健壮之外，它们提供的依赖项鸟瞰图还可以提高可见性并实现更多治理控制。cron
有时，“任务”的概念本身可能具有局限性。任务本质上将对批量数据进行操作，但流式处理世界依赖于连续流动的数据单元。许多现代流式处理框架都是围绕数据流模型构建的，Apache Flink 就是一个常见的示例。这种方法放弃了独立任务的排序，转而支持组合可以对任何大小的块进行操作的细粒度计算。
从编排到组合
这些系统之间的共同点是它们捕获依赖项，无论是隐式的还是显式的，批处理的还是流式的。许多系统需要这些技术的组合，因此一致的数据编排模型应该将它们全部考虑在内。这是由更广泛的组合概念提供的，该概念捕获了数据编排器今天所做的大部分工作，并且还扩展了将来如何构建这些系统的视野。
可组合数据系统
数据编排的未来正在朝着可组合的数据系统发展。编排器一直背负着连接越来越多的系统的沉重负担，这些系统从未被设计为相互交互。组织已经建立了大量的 “胶水” 来将这些流程结合在一起。通过重新思考数据系统如何组合在一起的假设，新方法可以大大简化其设计。
开放标准
数据格式的开放标准是可组合数据移动的核心。Apache Parquet 已成为列式数据的实际文件格式，而 Apache Arrow 是其内存中的对应格式。围绕这些格式的标准化非常重要，因为它减少甚至消除了困扰许多数据管道的昂贵的复制、转换和传输步骤。与原生支持这些格式的系统集成可实现原生 “数据共享” ，而无需所有胶水代码。例如，摄取过程可能会将 Parquet 文件写入对象存储，然后简单地共享这些文件的路径。然后，下游服务可以访问这些文件，而无需创建自己的内部副本。如果工作负载需要与本地进程或远程服务器共享数据，则可以使用 Arrow IPC 或 Arrow Flight，开销几乎为零。
标准化正在堆栈的所有级别进行。Apache Iceberg 和其他开放表格格式在 Parquet 成功的基础上，定义了一种用于组织文件的布局，以便它们可以解释为表格。这为文件访问添加了微妙但重要的语义，可以将文件集合转换为原则性数据湖仓一体。结合目录（例如最近孵化的 Apache Polaris），组织可以进行治理控制，以构建权威的事实来源，同时从底层格式实现的零副本共享中受益。这种组合的力量怎么强调都不为过。当业务的事实来源与生态系统的其余部分零副本兼容时，只需共享数据即可实现许多编排，而不是构建繁琐的连接器流程。
图 2.由开放标准组成的数据系统
将数据作为 Parquet 写入对象存储后，无需任何转换即可共享数据。
解构堆栈
数据系统始终需要对文件、内存和表格式做出假设，但在大多数情况下，它们已隐藏在其实现的深处。用于与数据仓库或数据服务供应商交互的狭窄 API 有助于实现简洁的产品设计，但它并不能最大限度地增加最终用户可用的选择。考虑图 1 和图 2，它们描述了旨在支持类似业务功能的数据系统。
在封闭系统中，数据仓库在内部维护自己的表结构和查询引擎。这是一种一刀切的方法，可以轻松上手，但可能难以扩展到新的业务需求。锁定可能很难避免，尤其是在涉及治理和访问数据的其他服务等功能时。云提供商在其生态系统中提供无缝和高效的集成，因为他们的内部数据格式是一致的，但这可能会关闭在该环境之外采用更好产品的大门。相反，导出到外部提供商需要维护专为仓库的专有 API 构建的连接器，这可能会导致跨系统的数据蔓延。
一个开放的、解构的系统对其最低级别的细节进行了标准化。这使企业能够为服务挑选最佳供应商，同时获得以前只有在封闭生态系统中才能实现的无缝体验。在实践中，开放数据系统的主要关注点是首先将数据源复制、转换和陆地为开放表格格式。完成此操作后，可以通过将仅写入一次的数据的引用共享到组织的真实来源来实现许多编排。正是这种在各个层面实现数据共享的举措，促使组织重新思考数据的编排方式，并构建未来的数据产品。
结论
编排是现代数据系统的支柱。在许多企业中，它是解开复杂且相互关联的流程的核心技术，但开放标准的新趋势为如何协调这些依赖关系提供了新的视角。系统不是将更高的复杂性推向编排层，而是从头开始构建系统以协作共享数据。云提供商一直在增加与这些标准的兼容性，这有助于为未来的最佳解决方案铺平道路。通过采用可组合性，组织可以将自己定位为简化治理，并从我们行业发生的最大进步中受益。
