OracleからApache Parquetへ：結果整合性の処理方法
既存の本番用Oracleデータベースがあります。ただし、データの量やクエリの複雑さのため、特定の種類の操作ではパフォーマンスの問題があります。
そのため、定期的に各OracleテーブルをCSVにエクスポート/ダンプしています。次に、そのようなCSVはParquetファイルに変換され、Sparkで非常に高いパフォーマンスのクエリが可能になります。しかし、私の懸念は強い整合性の利点を失うことです。
次のようなOracleの2つのテーブルがあるとします。
data (id, value, fk_metadata_types_id)
metadata_types (id, label)
現在、私は定期的にそのような2つのテーブルをエクスポートし、それをParquetファイルに変換します（各Oracleテーブルには独自のParquetファイルのセットがあります）。Sparkクエリの準備ができています。
問題は一貫性についてです。 2つのバッチがあり、1つはデータテーブルをCSV（次にParquet）にダンプし、もう1つはメタデータテーブルをCSVにダンプします。
つまり、基本的に、ある時点でSparkでデータテーブルを読み取るfk_metadata_types_idが、対応するメタデータパーケットテーブルにまだ存在しない場合があります。
そのような一貫性の問題をどのように処理しますか？ここでの考え方は、Sparkでパフォーマンスの高いクエリを作成することですが、Sparkによってデータがクエリされたときに、対応するmetadata_typesを（最終的にはOracle結合のような結合によって）常に取得できる（強い整合性）ことも保証します。
ありがとう
フロントエンドでは、ほとんどのデータベースに スナップショット分離レベル があり、同じデータベース状態に対して複数のコマンドを実行できます。これが意味することは、あなたのトランザクションが利用可能なままになる前に完了したすべてのトランザクションと、トランザクションが利用できないままになった後に開始されたすべてのトランザクションです。このようなトランザクションで複数のエクスポートを実行する場合、参照整合性を維持する必要があります。
バックエンドでは、ETLで言うと、この問題は 遅延到着ディメンション として知られています。不完全なレコードを抑制する、一時的な値を使用するなど、複数の戦略があります。後者の場合、ラベルは、たとえば、future_label_labelidを読み取り、次の実行で更新されます。