バーク処理のためのApache Beam over Spark/Flinkのメリットは何ですか？

Question

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

Beam word count exampleを見ると、元のSpark/Flink同等物と非常によく似ていますが、やや冗長な構文が考えられます。

私は現在、このようなタスクのためにスパーク/ FLINKの上にビームを選択する大きな利益が表示されません。これまでに行った唯一の観察：

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

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

this questionで部分的にカバーされ、this article（スパーク1.Xのために古い）にまとめられているストリーミングの側面の違いを求めていないことに注意してください。

Answer 1

Beamが既存のエンジンの多くに追加するものがいくつかあります。

• バッチとストリーミングを統一する。多くのシステムでは、バッチとストリーミングの両方を処理できますが、別々のAPIを使用して行うことがよくあります。しかし、Beamでは、バッチとストリーミングは、待ち時間、完全性、およびコストの点で2つのポイントにすぎません。バッチからストリーミングまで、学習/書き換えの絶壁はありません。したがって、今日バッチパイプラインを作成しても明日のレイテンシは変わる必要がある場合、調整するのは非常に簡単です。この種の旅行はMobile Gaming examplesで見ることができます。抽象のレベルを上げる

• APIは：ビームのAPIは、あなたのデータとあなたのロジックの性質をキャプチャ、代わりの貫通根本的なランタイム漏れの詳細をさせるに焦点を当てます。これは移植性の鍵でもあります（次の段落を参照）。また、実行時に実行時に多くの柔軟性を与えることができます。 ParDo融合（別名関数の構成）のようなものは、大部分のランナーが既に行う非常に基本的な最適化です。他の最適化はまだいくつかのランナーに実装されています。たとえば、BeamのSource APIsは、パイプライン内のシャーディングの過度の指定を避けるために特別に作成されています。代わりに、ランナーに適切なフックを与えて、使用可能なマシン間で作業を動的に再調整します。これは、本質的にストラグラーシャードを排除することで、パフォーマンスに大きな違いをもたらす可能性があります。一般的に、我々はランナーに構築することができますよりスマート、私たちが良いでしょう。データ、コード、環境の変化に伴い、最も慎重なハンドチューニングも失敗します。ランタイム全体

• ポータビリティ。：データシェイプと実行時の要件がきちんと分かれているため、同じパイプラインを複数の方法で実行できます。つまり、オンデマンドからクラウドへ、または試行錯誤したシステムから最先端のものへと移行する必要があるときには、コードの書き換えを終了しないということです。オプションを非常に簡単に比較して、現在のニーズに最適な環境とパフォーマンスの組み合わせを見つけることができます。オープンソースのランナーとの前提にある機密データの処理や、クラウド内の管理対象サービス上の他のデータの処理など、さまざまなものが混在する可能性があります。

ビームモデルを、多くの異なるエンジンよりも優れた抽象化として設計するのは難しいです。ビームはすべてのエンジンの機能の交差点（あまりにも限定されていません！）でも組合も（キッチンシンクのあまりにも！）ではありません。代わりに、Beamはデータ処理がどこに行くかの最前線に立つことを試み、ランタイムエンジンに機能をプッシュしたり、ランタイムエンジンからパターンを引き出したりします。

• Keyed Stateは、さまざまなエンジンに存在し、興味深い一般的な使用例を有効にした機能の優れた例ですが、もともとはBeamで表現できませんでした。私たちは最近、Beamのdesign principlesに従ってこの機能のバージョンを組み込むようにBeamモデルを拡張しました。
• また、その逆もありますが、Beamはさまざまなエンジンのロードマップにも影響を与えることを願っています。たとえば、FlinkのDataStreamのセマンティクスは、Beam（nee Dataflow）モデルによってinfluencedでした。
• これはまた、指定された時点で異なるBeam​​ランナー間で機能が常に同じになるとは限りません。だからこそ、我々は物事の状態を明確に伝えるためにcapability matrixを使っているのです。