[解決済み] Apache BeamがSpark/Flinkよりもバッチ処理に優れている点は何ですか？

質問

Apache Beam は、Apache SparkやFlinkを含む複数のランナーバックエンドをサポートしています。私はSpark/Flinkに精通しており、バッチ処理のためのBeamの長所/短所を見ようとしています。

を見てみると Beamの単語数の例 を見ると、ネイティブのSpark/Flinkの同等品と非常に似ているように感じますが、おそらくもう少し冗長な構文になっています。

このようなタスクでSpark/FlinkではなくBeamを選択する大きなメリットは今のところ見当たりません。今のところ私ができる唯一の観察です。

• Pro: 異なる実行バックエンドに対する抽象化。
• Con: この抽象化は、Spark/Flinkで何が実行されるかを正確に制御することができないという代償を伴います。

Beam モデルの他の長所/短所を強調する、より良い例はありますか？また、制御の喪失がパフォーマンスにどのような影響を与えるかについての情報はありますか？

ストリーミングの違いについて聞いているのではないことに注意してください。 この質問 で要約しています。 この記事 (にまとめています（Spark 1.Xのため古いです）。

どのように解決するのですか？

Beamは、既存の多くのエンジンに比べて、いくつかの点で優れています。

• バッチとストリーミングを統一する。 多くのシステムはバッチとストリーミングの両方を扱うことができますが、それらはしばしば別々のAPIを介して行われます。しかしBeamでは、バッチとストリーミングは、レイテンシ、完全性、コストのスペクトル上の2つのポイントにすぎません。バッチからストリーミングへの学習・書き換えの崖はない。ですから、今日バッチ処理でパイプラインを書いたとしても、明日にはレイテンシーのニーズが変わっていたとしても、驚くほど簡単に調整することができるのです。このような旅は、以下のサイトで見ることができます。 モバイル ゲームの例 .

• 抽象度を上げるAPI : BeamのAPIは、ランタイムの詳細を漏らさないように、データやロジックのプロパティを取得することに重点を置いています。これはポータビリティ（次の段落参照）の鍵であり、またランタイムの実行方法に多くの柔軟性を与えることができます。ParDoフュージョン（別名、関数合成）のようなものは、ランナーの大半がすでに行っている、かなり基本的な最適化です。その他の最適化については、一部のランナーでまだ実装されています。例えば、Beamの ソースAPI は、パイプライン内のシャーディングのオーバースペックを避けるために特別に構築されています。その代わり、ランナーに適切なフックを与えて、利用可能なマシン間で動的に作業をリバランスさせます。これは、本質的にストラグラーシャードを排除することで、パフォーマンスに大きな違いをもたらすことができます。一般に、ランナーにはより多くの賢さを組み込むことができれば、より良い結果が得られるでしょう。最も注意深く手作業でチューニングしても、データ、コード、および環境が変化すると失敗することがあります。

• ランタイム間の移植性。 : データの形と実行時の要件がきちんと分かれているため、同じパイプラインを複数の方法で実行することができます。つまり、オンプレミスからクラウドへ、あるいは従来のシステムから最先端のシステムへ移行する際にも、コードを書き換える必要はありません。選択肢を比較することで、現在のニーズに最適な環境とパフォーマンスの組み合わせを簡単に見つけることができます。たとえば、オープンソースのランナーを使ってオンプレミスで機密データを処理し、クラウドのマネージド サービスで他のデータを処理するといったことです。

Beamモデルを、多くの異なるエンジンの上で有用な抽象化であるように設計することは、難しいことです。Beamは、すべてのエンジンの機能の交差点でもなければ（限定的すぎる！）、統合でもありません（キッチンシンクすぎる！）。その代わり、Beamはデータ処理の最前線に立とうとし、ランタイムエンジンに機能を押し込んだり、ランタイムエンジンからパターンを引き出したりしています。

• キーとなる状態 は、様々なエンジンに存在し、興味深い一般的なユースケースを可能にする機能の素晴らしい例ですが、元々Beamでは表現可能なものではありませんでした。私たちは最近、Beam のモデルを拡張し、この機能のバージョンを Beam の 設計方針 .
• そして逆に、Beamが様々なエンジンのロードマップに影響を与えることも期待しています。例えば、FlinkのDataStreamsのセマンティクスは に影響されました。 Beam（旧Dataflow）モデルから影響を受けています。
• これはまた、ある時点で異なる Beam ランナー間で能力が必ずしも完全に同じになるとは限らないことを意味します。そのため、私たちは ケイパビリティマトリックス を使用して、物事の状態を明確に伝えようとしているわけです。