フリンクストリーミングまたはバッチ処理

Question

私は既存のカタログプロセッサーを再設計することを義務付けられています。要件は次の通りです。要件5つのベンダー（各ベンダーは複数のストアを持つことができます）が店舗ごとに「XML」ファイルを提供します。基本的に、ストアごとに1つのxmlファイルと、ベンダーごとに複数のストアファイルがあります。最大ファイルサイズは500 MB、最小値は100 MBです。ファイルあたりの平均製品数は100,000です。

サンプルXML形式は... ... ...このようなことができ

これは、店舗ごとにファイルをダウンロードするために30以上の分を取るdoesntの、およびこれらのファイルは、1日1回更新またはすべての3にしている

6時間。

ここで重要な要件は、製品の構成が高度に組織化されておらず、これらのファイルを別の共通オブジェクト（json）に変換して処理してから、カサンドラに保存する必要があることです。

私の技術チームは、Flinkがベンダーサーバーからファイルを直接ストリームし、ストリーミング中に処理を開始するHDFSの上にApache FlinkとKafkaを使用して設計するようアドバイスしました。

私の見解では、どちらの場合でもファイルは有限のサイズであり、ストリームする必要はあまりありません。スタンドアローンのスケジューラをダウンロードしてHDFSにダウンロードすることを考えました。ファイルがHDFSにロードされるとすぐに、私はFlinkの処理をトリガーしてCassandraに保存することができます。

ここで私の質問は、ファイルが有限のサイズであり、ベンダーの数に関係なく有限の数であることを知っています。ストリーム処理が過度に処理されているか、バッチ処理が後で待ち時間になりますか？

Answer 1

質問は、使用するツールによって大きく異なります。あなたがFlinkに行くなら、私はストリームを使っても問題ないと思っています。関数とジョブを適切に記述すると、必要に応じてDataStream APIからDataSet APIへの移行が容易になります。ここでのバッチ処理は無駄な遅延を招き、それ以上の情報がなければ適切なアプローチとは思われません。とにかくうまくいくと思いますが、待ち時間が厳しい要件であるかどうかは不明です。

それは、私はそれ自体が過度のものであると信じています。この特定のユースケースでは、より伝統的なSparkのようなものがユーザビリティの面でより良い選択肢になりますが、Flinkに投資したいのであれば、それは完全にうまくいき、ユースケースを考えれば、現在は/ sparkと統合されていますが、Flinkでは欠けています。