バッチ処理でのSpark / FlinkよりもApache Beamの利点は何ですか？
Apache Beam は、Apache SparkおよびFlinkを含む複数のランナーバックエンドをサポートします。 Spark/Flinkに精通しており、バッチ処理のビームの長所/短所を確認しようとしています。
Beam Word count example を見ると、ネイティブのSpark/Flinkの同等物と非常によく似ているように感じられます。
現在、このようなタスクにSpark/FlinkよりもBeamを選択することの大きな利点はありません。これまでにできる唯一の観察：
- プロ：異なる実行バックエンドの抽象化。
- 欠点：この抽象化には、Spark/Flinkで実行される内容を正確に制御できないという代償が伴います。
Beamモデルの他の長所/短所を強調するより良い例はありますか？コントロールの喪失がパフォーマンスに与える影響に関する情報はありますか？
Beamが既存のエンジンの多くに追加するものがいくつかあります。
バッチとストリーミングの統合。多くのシステムはバッチとストリーミングの両方を処理できますが、多くの場合、別々のAPIを介して処理します。しかし、Beamでは、バッチとストリーミングは、待ち時間、完全性、およびコストの範囲における2つのポイントにすぎません。バッチからストリーミングまで、学習/書き換えの崖はありません。したがって、今日バッチパイプラインを作成しているが、明日、レイテンシを変更する必要がある場合、非常に簡単に調整できます。 モバイルゲームの例 でこの種の旅を見ることができます。
抽象化レベルを上げるAPI：BeamのAPIは、基礎となるランタイムの詳細を漏らすのではなく、データとロジックのプロパティをキャプチャすることに焦点を当てています。これは、移植性の鍵であり（次の段落を参照）、ランタイムの実行方法に大きな柔軟性を与えることもできます。 ParDo融合（別名関数合成）のようなものは、ほとんどのランナーがすでに行っている非常に基本的な最適化です。一部のランナー向けに、他の最適化がまだ実装されています。たとえば、Beamの ソースAPI は、パイプライン内のシャーディングの過剰な指定を避けるために特別に構築されています。代わりに、利用可能なマシン間で作業を動的に再調整するための適切なフックをランナーに提供します。これにより、ストラグラーシャードが本質的に排除されるため、パフォーマンスに大きな違いが生じます。一般に、ランナーに組み込むことができるスマートなものほど、より良い結果になります。データ、コード、および環境が変化すると、最も慎重な手動調整でさえ失敗します。
ランタイム間の移植性。：データ形状とランタイム要件がきちんと分離されているため、同じパイプラインを複数の方法で実行できます。つまり、オンプレミスからクラウドに移行したり、実証済みの真のシステムから最先端の何かに移行したりする必要があるときに、コードを書き直さなくて済むということです。オプションを非常に簡単に比較して、現在のニーズに最適な環境とパフォーマンスの組み合わせを見つけることができます。そして、それは、オープンソースのランナーでオンプレミスで機密データを処理し、クラウド内のマネージドサービスで他のデータを処理すること-物事が混在しているかもしれません。
多くの異なるエンジンの便利な抽象化になるようにビームモデルを設計するのは難しいです。 Beamは、すべてのエンジンの機能の交差点（制限が多すぎる！）でも、結合（キッチンシンクが多すぎる！）でもありません。代わりに、Beamは、データ処理が行われる場所の最前線にいるようにし、機能をランタイムエンジンにプッシュし、ランタイムエンジンからパターンを引き出します。
- Keyed State は、さまざまなエンジンに存在し、興味深い一般的なユースケースを可能にした機能の優れた例ですが、Beamでは元々表現できませんでした。 Beamの 設計原則 に従って、この機能のバージョンを含むようにBeamモデルを最近拡張しました。
- 逆に、Beamがさまざまなエンジンのロードマップにも影響を及ぼすことを願っています。たとえば、FlinkのDataStreamsのセマンティクスは、Beam（néeDataflow）モデルによって influenced でした。
- また、これは、特定の時点で異なるビームランナー間で機能が常に正確に同じとは限らないことを意味します。それが、物事の状態を明確に伝えようとするために capability matrix を使用している理由です。