可移植性框架路线图

概述

SDK 和运行器之间的互操作性是 Apache Beam 的关键方面。以前，大多数运行器只支持 Java SDK，因为每个 SDK-运行器组合都需要在两端进行大量工作。大多数运行器当前也用 Java 编写，这使得对非 Java SDK 的支持变得更加昂贵。可移植性框架 解决了这种情况并为整个 Beam 生态系统提供了完全的互操作性。

可移植性框架在 SDK 和运行器之间引入了明确定义的、与语言无关的数据结构和协议。这个互操作层（称为可移植性 API）确保 SDK 和运行器可以以统一的方式相互协作，将 SDK 和运行器的互操作性负担减少到恒定的工作量。它特别确保新的 SDK 可以自动与现有运行器协作，反之亦然。该框架引入了一个新的运行器，即通用本地运行器 (ULR)，作为一个补充直接运行器的实用参考实现。最后，它支持跨语言管道（跨 SDK 共享 I/O 或转换）和用户自定义的执行环境（“自定义容器”）。

可移植性 API 由一组较小的契约组成，这些契约将 SDK 和运行器隔离以进行作业提交、管理和执行。这些契约使用 protobufs 和gRPC 以实现广泛的语言支持。

• 作业提交和管理：运行器 API 定义了与语言无关的管道表示，其中转换指定执行环境为 docker 容器镜像。后者既允许执行端设置正确的环境，也为自定义容器和跨环境管道打开了大门。作业 API 允许统一管理管道执行和配置。

• 作业执行：SDK 组件是 SDK 提供的程序，负责执行用户代码，并与运行器分开运行。Fn API 定义了 SDK 组件和运行器之间的执行时二进制契约，描述了如何管理执行任务以及如何传输数据。此外，运行器需要以高效且与语言无关的方式处理进度和监控。SDK 组件初始化依赖于供应和工件 API 以获取分段文件、管道选项和环境信息。Docker 根据容器契约的定义，在运行器和 SDK/用户环境之间提供隔离，有利于两者。SDK 的容器化使其（以及用户，除非 SDK 是封闭的）能够完全控制自己的环境，而无需担心依赖冲突。运行器在管理 SDK 组件容器方面具有很大的自由度。

目标是最终所有（非直接）运行器和 SDK 都支持可移植性 API，也许是独占地支持。

如果你有兴趣深入研究设计，你可以在Beam 开发人员维基 上找到它们。另一个概述可以在这里 找到。

状态

所有 SDK 目前都支持可移植性框架。还有一个 Python 通用本地运行器和共享的 java 运行器库。性能良好，并支持多语言管道。目前，Flink 和 Spark 运行器支持可移植管道执行（默认情况下，用于 Java 以外的 SDK），使用Dataflow 运行器 v2 时，Dataflow 也是如此。有关详细信息，请参见可移植性支持表。

问题

可移植性工作涉及每个组件，因此使用“可移植性”标签来标识所有与可移植性相关的问题。纯设计或 proto 定义应该使用“beam-model”组件。新的可移植性功能的常见模式是，总体功能在“beam-model”中，每个 SDK 和运行器在各自的组件中都有子任务。

问题： 查询

先决条件：Docker、Python、Java 8

在 Flink 上运行 Python 字数统计

Beam Flink 运行器可以在批处理和流式模式下运行 Python 管道。有关如何在 Flink 之上运行可移植管道的更多信息，请参见Flink 运行器页面。

在 Spark 上运行 Python 字数统计

Beam Spark 运行器可以在批处理模式下运行 Python 管道。有关如何在 Spark 之上运行可移植管道的更多信息，请参见Spark 运行器页面。

Spark 尚不支持 Python 流式模式。

SDK 组件配置

有关 SDK 组件部署选项的更多信息，请参见此处，有关编写可移植 SDK 的内容，请参见此处。