ストリーミング - RDBMSの更新と削除イベントを段階的に処理する方法

Question

現在のデータパイプラインを再設計し、ストリーミングをデータ移動の代替手段と考えるかどうか検討しています。 RDBMSイベントには、既存データおよび履歴データに対するINSERT、UPDATEおよびDELETEが含まれます。これらすべてのイベントには、それらを一意的に識別するためのキーがあります。これらのイベントを処理している間に、正確さと完全性は重要です。また、潜在性はある程度犠牲にすることができます。すなわち、特定の鍵に基づいてマイクロバッチで事象を処理する必要があり、その鍵に対する後期事象が存在しないことが必要である（近似、発見的等）。さらに、このイベントは発注されません。すなわち、key1、key2データが一緒に到着することができる。ある時点でkey1のすべてのレコードが到着し、他の時点でkey2のすべてのデータが到着します。問題は、重要な方法でキー付きデータを処理する方法です。もう一度完全性が重要です。結果を増分で累積することができますが、指定されたキーの完全なデータが得られるまでは結果は有用ではありません。

私が考えることの1つの方法は、非SQLストアを使用して、主キーを行キーとして使用してこのイベントを格納し、非SQLストアで冪等更新を実行することです。しかし、私は、データが変更されたキーの状態を維持し、川下のユーザーが利用できるようにして、変更されたデータを知っておく必要があると思います。彼らは現在、非SQLストアからそのデータを読み取ることができます。しかし、今問題は、非SQLストアは揮発性であるため、下流で不整合なデータを処理する可能性があります。

もう1つの方法は、何らかの形でストリームからデータを処理するのではなく、no-sqlに依存しないことです。私は固定スライディングウィンドウ、セッションウィンドウ、ウォーターマークのようなストリーム処理のいくつかの概念を読んでいます。手元にある問題を解決できるかどうかはわかりません。私はデータ（キー）と イベントの各バッチの完了を示す発行元からのいくつかの信号に基づいて非整列ウィンドウが必要な場合がありますか？

Answer 1

私はこのプロジェクトを別にしましたが、私はgoogle dataflow、spark streaming、apache beamに関するかなりの文書を調べました。ストームとエイペックスはこの時点では複雑すぎるように見えました。

watermarksとtriggersのような概念があり、ウィンドウの完成時と処理を開始するタイミングを教えてくれます。処理を開始するように指示する各ストリームの透かしイベントを受け取るまで、イベントを蓄積し続けることができます。この「イベント完了」イベントを送信するには、データソースまたはそれらのイベントの発行者を変更する必要があります。これはパズルの最初の部分かもしれません。そのイベントのカスタムウィンドウを取得したら、処理を開始する前にそれらのイベントを調べ、データストア（hbase、cassandra）から追加のデータを取得するか、データストアのエントリを更新/削除する必要があります。さらに下流のユーザーがいる場合は、そのカスタムウィンドウで完了した変更や、そのイベントを既に持っているため、ダウンストリームにアクセスするのが難しくないアップストリーム処理をダウンストリームに伝えなければなりません。これらのイベントには、顧客ID、トランザクションID、時間帯などの複数のコンシューマ間でそれらを識別するための標準が必要です。