Apache Beamは、ApacheSparkやFlinkなどの複数のランナーバックエンドをサポートしています。私はSpark / Flinkに精通しており、バッチ処理のBeamの長所/短所を確認しようとしています。
Beamの単語数の例を見ると、ネイティブのSpark / Flinkの同等のものと非常に似ているように感じますが、構文が少し冗長になっている可能性があります。
私は現在、そのようなタスクにSpark / FlinkよりもBeamを選択することに大きなメリットは見られません。私がこれまでに行うことができる唯一の観察：
ビームモデルの他の長所/短所を強調するより良い例はありますか？制御の喪失がパフォーマンスにどのように影響するかについての情報はありますか？
この質問で部分的にカバーされ、この記事で要約されているストリーミングの側面の違いを求めていないことに注意してください（Spark 1.Xのために古くなっています）。
回答:
Beamが既存のエンジンの多くに追加するものがいくつかあります。
バッチとストリーミングを統合します。多くのシステムはバッチとストリーミングの両方を処理できますが、多くの場合、別々のAPIを介して処理します。しかし、Beamでは、バッチとストリーミングは、レイテンシー、完全性、およびコストの範囲の2つのポイントにすぎません。バッチからストリーミングへの学習/書き換えの崖はありません。したがって、今日バッチパイプラインを作成し、明日はレイテンシーを変更する必要がある場合、調整は非常に簡単です。この種の旅は、モバイルゲームの例で見ることができます。
抽象化のレベルを上げるAPI：BeamのAPIは、基になるランタイムの詳細を漏らすのではなく、データとロジックのプロパティをキャプチャすることに重点を置いています。これは移植性の鍵であり（次の段落を参照）、ランタイムに実行方法の柔軟性を与えることもできます。ParDoフュージョン（別名関数合成）のようなものは、大多数のランナーがすでに行っている非常に基本的な最適化です。他の最適化は、一部のランナーに対してまだ実装されています。たとえば、BeamのソースAPIパイプライン内のシャーディングの過剰仕様を回避するために特別に構築されています。代わりに、利用可能なマシン間で作業のバランスを動的に再調整するための適切なフックをランナーに提供します。これは、ストラグラーシャードを本質的に排除することにより、パフォーマンスに大きな違いをもたらす可能性があります。一般的に、ランナーに組み込むことができるスマートさが多ければ多いほど、より良い結果が得られます。データ、コード、および環境が変化すると、最も注意深い手動チューニングでさえ失敗します。
ランタイム間の移植性。：データの形状と実行時の要件が適切に分離されているため、同じパイプラインを複数の方法で実行できます。つまり、オンプレミスからクラウドに移行したり、実証済みのシステムから最先端のシステムに移行したりする必要があるときに、コードを書き直す必要がないということです。オプションを非常に簡単に比較して、現在のニーズに最適な環境とパフォーマンスの組み合わせを見つけることができます。そして、それは、オープンソースランナーを使用してオンプレミスで機密データを処理することと、クラウド内のマネージドサービスで他のデータを処理することの組み合わせである可能性があります。
多くの異なるエンジンを抽象化するのに役立つようにBeamモデルを設計するのは難しいです。ビームは、すべてのエンジンの機能の交差点（制限が多すぎる！）でも、ユニオン（キッチンシンクが多すぎる！）でもありません。代わりに、Beamは、ランタイムエンジンに機能をプッシュしたり、ランタイムエンジンからパターンを引き出したりして、データ処理が行われる最前線にいることを試みます。