＃Apache-flink：Flinkを使用したストリーム処理またはバッチ処理
私は既存のカタログプロセッサを再設計する任務を負っており、要件は次のとおりです要件ストアごとに「XML」ファイルを提供するベンダーが5〜10社あります（各ベンダーは複数のストアを持つことができます）。基本的に、ストアごとに1つの製品xmlファイル、およびベンダーごとに複数のストアファイル。最大ファイルサイズは500MB、最小ファイルサイズは100MBです。ファイルあたりの平均製品数は100,000です。
サンプルのxml形式は次のようになります
<?xml>
<catalog>
<product>...</product>
<product>...</product>
<product>...</product>
</catalog>
ストアごとにファイルをダウンロードするのに30分以上かかることはなく、これらのファイルは1日1回、または3〜6時間ごとに更新されます。
現在の優先要件は、製品の詳細が非常に整理されておらず、これらのファイルを整理、処理（10以上のプロセス）して別の共通オブジェクト（json）に変換してから、Cassandraにファイルを保存する必要があるということです。
私のテクノロジーヘッドは、ApacheFlinkとKafkaをHDFSの上に配置して設計するようにアドバイスしました。ここで、flinkはベンダーサーバーからファイルを直接ストリーミングし、ストリーミング中にファイルの処理を開始します。
私の見解では、どちらの場合もファイルは有限のサイズであり、ストリーミングする必要はあまりありません。そのため、スタンドアロンのスケジューラーにダウンローダーを使用してファイルをダウンロードしてHDFSにロードすることを考えました。ファイルがHDFSにロードされるとすぐに、Flink処理をトリガーして、Cassandraに保存できます。
ここでの私の質問は、ファイルが有限のサイズであり、ベンダーの数に関係なく有限の数であることを知っている、ストリーム処理はやり過ぎですか、それともバッチ処理は後で待ち時間の負担になりますか？
ストリーミングソリューションのレイテンシーは低くなりますが、それを第一に考慮する必要はないと思います。代わりに、システム全体の複雑さを調べます。ストリーミングでもバッチでも、コードはほとんど同じですが、ストリーミングを使用すると、エラーリカバリが向上し、スケジューラを設定する必要がありません。