可攜性框架路線圖

概述

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 harness 是一個 SDK 提供的程式，負責執行使用者程式碼，並且與執行器分開執行。Fn API 定義了 SDK harness 和執行器之間的執行時二進位合約，該合約描述了如何管理執行任務以及如何傳輸資料。此外，執行器需要以有效且語言中立的方式處理進度和監控。SDK harness 初始化依賴於Provision 和 Artifact API 來獲取已暫存的檔案、管道選項和環境資訊。Docker 在執行器和 SDK/使用者環境之間提供隔離，這對雙方都有好處，如同容器合約所定義。SDK 的容器化使其（以及使用者，除非 SDK 是封閉的）可以完全控制自己的環境，而沒有依賴性衝突的風險。執行器在如何管理 SDK harness 容器方面具有很大的自由度。

目標是所有（非直接）執行器和 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 wordcount

Beam Flink 執行器可以在批次和串流模式下執行 Python 管道。請參閱Flink 執行器頁面，以獲取有關如何在 Flink 上執行可攜式管道的更多資訊。

在 Spark 上執行 Python wordcount

Beam Spark 執行器可以在批次模式下執行 Python 管道。請參閱Spark 執行器頁面，以獲取有關如何在 Spark 上執行可攜式管道的更多資訊。

Spark 尚不支援 Python 串流模式。

SDK Harness 組態

請參閱這裡，以獲取有關 SDK harness 部署選項的更多資訊，並參閱這裡，以獲取有關如何編寫可攜式 SDK 的資訊。