数据编排的现代时代：从数据碎片到协作第一部分

[导读]数据工程和软件工程长期以来一直存在分歧，各自都有自己独特的工具和最佳实践。一个关键的区别是在构建数据产品时需要专门的编排。在本文中，我们将探讨数据协调器所扮演的角色，以及行业的最新趋势如何使这两个学科比以往任何时候都更加紧密地结合在一起。

数据工程和软件工程长期以来一直存在分歧，各自都有自己独特的工具和最佳实践。一个关键的区别是在构建数据产品时需要专门的编排。在本文中，我们将探讨数据协调器所扮演的角色，以及行业的最新趋势如何使这两个学科比以往任何时候都更加紧密地结合在一起。

数据编排的现状

投资数据能力的主要目标之一是统一整个企业的知识和理解。这样做的价值可能是巨大的，但它涉及集成越来越多的系统，而且复杂性往往越来越高。数据编排为构建这些系统提供了一种原则性的方法，其复杂性来自于：

· 许多不同的数据源，每个都有自己的语义和限制

· 数据产品的许多目的地、利益相关者和用例

· 创建最终产品涉及的异构工具和流程

典型数据堆栈中有多个组件可以帮助组织这些常见场景。

组件

数据工程的流行行业模式被称为提取、加载和转换，或ELT。数据 (E) 从上游源中提取，(L) 直接加载到数据仓库中，然后 (T) 转换为各种特定于领域的表示形式。存在变体，例如ETL，它在加载到仓库之前执行转换。所有方法的共同点是三种高级功能：摄取、转换和服务。这三个阶段之间以及每个阶段内部都需要编排来协调。

食入

摄取是将数据从源系统(例如数据库)移动到存储系统中的过程，该存储系统允许转换阶段更轻松地访问它。此阶段的编排通常涉及安排任务在上游有新数据时运行，或者在这些系统可用时主动侦听来自这些系统的通知。

转型

转换的常见示例包括从原始结构中解包和清理数据，以及将其拆分或连接到与业务领域更紧密结合的模型中。 SQL 和 Python 是表达这些转换的最常见方法，现代数据仓库为它们提供了极好的支持。此阶段编排的作用是对转换进行排序，以便有效地生成利益相关者使用的模型。

服务

服务可以指非常广泛的活动。在某些情况下，最终用户可以直接与仓库交互，这可能只涉及数据管理和访问控制。更常见的是，下游应用程序需要访问数据，这反过来又需要与仓库的模型同步。加载和同步是协调器在服务阶段发挥作用的地方。

从源到数据仓库，再到最终用户应用程序的典型数据流摄取引入数据，在仓库中进行转换，并将数据提供给下游应用程序。

这三个阶段构成了用于分析系统的有用心理模型，但对业务来说重要的是它们所支持的功能。数据编排有助于协调从源系统(可能是核心业务的一部分)获取数据所需的流程，并将其转化为数据产品。这些流程通常是异构的，并且不一定是为了协同工作而构建的。这可能会给协调器带来很多责任，让其负责制作副本、转换格式和其他临时活动以将这些功能整合在一起。

工具

大多数数据系统的核心都依赖于一些调度功能。当仅需要在可预测的基础上管理有限数量的服务时，常见的方法是使用简单的调度程序，例如cron.以这种方式协调的任务可以非常松散地耦合。在任务依赖性的情况下，可以直接安排一个任务在另一个任务预计完成后一段时间开始，但结果可能对意外延迟和隐藏依赖性很敏感。

随着流程变得越来越复杂，明确它们之间的依赖关系变得很有价值。这就是Apache Airflow等工作流引擎所提供的功能。 Airflow 和类似的系统通常也被称为“编排器”，但正如我们将看到的，它们并不是唯一的编排方法。工作流引擎使数据工程师能够指定任务之间的明确顺序。它们支持运行计划任务，并且还可以监视应触发运行的外部事件。除了使管道更加健壮之外，它们提供的依赖关系鸟瞰图还可以提高可见性并实现更多治理控制。cron

有时“任务”的概念本身可能是有限制的。任务本质上是对批量数据进行操作，但流世界依赖于连续流动的数据单元。许多现代流框架都是围绕数据流模型构建的——Apache Flink就是一个流行的例子。这种方法放弃了独立任务的排序，有利于组合可以对任何大小的块进行操作的细粒度计算。

从编曲到作曲

这些系统之间的共同点是它们捕获依赖关系，无论是隐式的还是显式的、批处理的还是流式的。许多系统需要结合使用这些技术，因此一致的数据编排模型应该将它们全部考虑在内。这是由更广泛的组合概念提供的，该概念捕获了数据编排器今天所做的大部分工作，并扩展了未来如何构建这些系统的视野。

可组合数据系统

数据编排的未来正在转向可组合的数据系统。编排器一直承担着连接越来越多的系统的沉重负担，而这些系统从未被设计为相互交互。组织已经建立了数量惊人的“粘合剂”来将这些流程粘合在一起。通过重新思考数据系统如何组合在一起的假设，新方法可以大大简化其设计。

开放标准

数据格式的开放标准是可组合数据移动的核心。Apache Parquet已成为列式数据事实上的文件格式，而Apache Arrow是其内存中的对应项。围绕这些格式的标准化非常重要，因为它减少甚至消除了困扰许多数据管道的昂贵的复制、转换和传输步骤。与本机支持这些格式的系统集成可以实现本机“数据共享”，而无需所有粘合代码。例如，摄取过程可能会将 Parquet 文件写入对象存储，然后简单地共享这些文件的路径。然后，下游服务可以访问这些文件，而无需制作自己的内部副本。如果工作负载需要与本地进程或远程服务器共享数据，它可以使用Arrow IPC或Arrow Flight，开销接近于零。

标准化正在堆栈的各个级别上进行。Apache Iceberg和其他开放表格式基于 Parquet 的成功，定义了用于组织文件的布局，以便将它们解释为表。这为文件访问添加了微妙但重要的语义，可以将文件集合转变为有原则的数据湖库。加上一个目录，比如最近孵化的Apache Polaris，组织拥有治理控制来构建权威的事实来源，同时受益于底层格式支持的零拷贝共享。这种组合的力量怎么强调都不为过。当业务的真实来源与生态系统的其他部分零复制兼容时，只需共享数据即可实现很多编排，而不是构建繁琐的连接器流程。一旦数据以 Parquet 形式写入对象存储，无需任何转换即可共享。

解构堆栈

数据系统始终需要对文件、内存和表格式做出假设，但在大多数情况下，它们都隐藏在其实现的深处。用于与数据仓库或数据服务供应商交互的狭窄 API 可以实现简洁的产品设计，但它并不能最大化最终用户可用的选择。它们描述了旨在支持类似业务功能的数据系统。

在封闭系统中，数据仓库内部维护自己的表结构和查询引擎。这是一种一刀切的方法，可以轻松上手，但可能难以扩展以满足新的业务需求。锁定可能很难避免，尤其是在涉及治理和其他访问数据的服务等功能时。云提供商在其生态系统内提供无缝且高效的集成，因为它们的内部数据格式是一致的，但这可能会关闭在该环境之外采用更好产品的大门。相反，导出到外部提供商需要维护专为仓库专有 API 构建的连接器，并且可能导致数据跨系统蔓延。

开放的、解构的系统标准化了其最低级别的细节。这使得企业能够挑选最佳的服务供应商，同时获得以前只能在封闭的生态系统中才能实现的无缝体验。在实践中，开放数据系统的主要关注点是首先将源数据复制、转换并转化为开放表格式。完成此操作后，可以通过共享对仅写入组织事实来源一次的数据的引用来实现许多编排。正是这种在各个层面共享数据的趋势，促使组织重新思考数据的编排方式并构建未来的数据产品。

结论

编排是现代数据系统的支柱。在许多企业中，它是负责理清复杂且相互关联的流程的核心技术，但开放标准的新趋势为如何协调这些依赖关系提供了新的视角。系统不是从头开始构建以协作共享数据，而是将更大的复杂性推入编排层。云提供商一直在增加与这些标准的兼容性，这有助于为未来的最佳解决方案铺平道路。通过采用可组合性，组织可以简化治理并从行业中发生的最伟大进步中受益。