ポータビリティフレームワークのロードマップ

概要

SDKとランナー間の相互運用性は、Apache Beamの重要な側面です。以前は、各SDKとランナーの組み合わせで両側にかなりの作業が必要だったため、ほとんどのランナーがJava SDKのみをサポートするのが現実でした。また、ほとんどのランナーは現在Javaで記述されているため、Java以外のSDKのサポートはさらにコストがかかります。ポータビリティフレームワークは、この状況を是正し、Beamエコシステム全体で完全な相互運用性を提供しました。

ポータビリティフレームワークは、SDKとランナー間で明確に定義された、言語に依存しないデータ構造とプロトコルを導入します。この相互運用レイヤー（ポータビリティAPIと呼ばれます）は、SDKとランナーが相互に均一に連携できるようにし、SDKとランナーの両方の相互運用性の負担を一定の労力に軽減します。特に、新しいSDKが既存のランナーと自動的に連携し、その逆も同様であることを保証します。このフレームワークでは、直接ランナーを補完する実用的なリファレンス実装として、新しいランナーであるユニバーサルローカルランナー（ULR）が導入されています。最後に、クロスランゲージパイプライン（SDK間でI/Oまたは変換を共有）と、ユーザーがカスタマイズした実行環境（「カスタムコンテナ」）を可能にします。

ポータビリティAPIは、ジョブの送信、管理、実行のためにSDKとランナーを分離する、より小さなコントラクトのセットで構成されています。これらのコントラクトは、幅広い言語サポートのためにprotobufとgRPCを使用します。

目標は、すべての（非直接）ランナーとSDKが最終的に、おそらく排他的にポータビリティAPIをサポートすることです。

設計を詳しく調べたい場合は、Beam開発者向けWikiで確認できます。別の概要はこちらにあります。

ステータス

現在、すべてのSDKがポータビリティフレームワークをサポートしています。また、Pythonユニバーサルローカルランナーと共有Javaランナーライブラリもあります。パフォーマンスは良好で、マルチランゲージパイプラインがサポートされています。現在、FlinkおよびSparkランナーはポータブルパイプラインの実行をサポートしており（Java以外のSDKではデフォルトで使用）、Dataflow Runner v2を使用する場合、Dataflowもサポートしています。詳細については、ポータビリティサポートテーブルを参照してください。

課題

ポータビリティの取り組みはすべてのコンポーネントに影響するため、すべてのポータビリティ関連の問題を特定するために「ポータビリティ」ラベルが使用されます。純粋な設計またはproto定義では、「beam-model」コンポーネントを使用する必要があります。新しいポータビリティ機能の一般的なパターンは、全体的な機能が「beam-model」にあり、各SDKおよびランナーのサブタスクがそれぞれのコンポーネントにあることです。

課題: クエリ

前提条件: Docker, Python, Java 8

Beam Flinkランナーは、バッチモードとストリーミングモードでPythonパイプラインを実行できます。Flinkでのポータブルパイプラインの実行方法の詳細については、Flink Runnerページを参照してください。

SparkでPythonのwordcountを実行する

Beam Sparkランナーは、バッチモードでPythonパイプラインを実行できます。Sparkでのポータブルパイプラインの実行方法の詳細については、Spark Runnerページを参照してください。

Pythonストリーミングモードは、Sparkではまだサポートされていません。

SDKハーネスの構成

SDKハーネスのデプロイオプションの詳細についてはこちらを、ポータブルSDKの作成内容についてはこちらを参照してください。