-1
Amazon Redshiftで構築したデータウェアハウスを使用しています。私が現在直面している問題は、約10のクライアントのデータを持つ私のスキーマには、巨大なファクトテーブル（約500M行）があります。私は定期的に（ほとんど毎日）このファクトテーブルのデータを生成し、リフレッシュが必要なプロセスを持っています。つまり、古いデータを削除し、新たに生成されたデータを挿入します。Redshift - データウェアハウスデータ更新
問題は、この一括削除挿入操作は、時間がかかり、即座に実行することができないVACUUMを必要とするファクトテーブルの穴を残してしまうことです。また、このファクト表（削除されたデータに起因する巨大な穴）は、ファクト表とディメンション表からデータを消費し、下流のプレゼンテーション領域でデータをリフレッシュするスナップショット時間に劇的に影響します。 DWH環境でバルクデータの更新を最適化するにはどうすればよいですか？
これはDWHでよく知られている問題で、解決すべきいくつかの推奨方法があるはずです。誰も推奨する解決策を指摘してもらえますか？
P.S：1つの解決策は、クライアントごとにテーブルを作成し、その上にすべての基礎となるテーブルを結合したビューを作成することです。この場合、クライアントごとにファクトテーブルを分割すると、かなり小さくなり、削除挿入後すぐに空にできますが、保守性の良いソリューションを探しています。
広すぎる質問、それはデータの性質とどのくらい正確にあなたが（テーブル全体またはその一部）を更新しないに依存 – AlexYes
@AlexYesだから私は10のためのデータを持って考えますテーブル内のクライアント。これらのクライアントのデータを異なるスケジュールで作成するジョブがあります（一部は毎日実行され、一部は毎週実行されます）。彼らがデータを生成するとき、私はdelete-insertであるこのテーブルの "置き換え"を行います。クライアントに応じて、一度に置き換えるデータは、テーブルサイズの10％から30％の範囲で変更できます。あなたはデータの性質によって何を意味するのか分かりませんか？ –
データの性質とは、エンティティが不変である場合（たとえば、ページビューのNを1日ごとに数えた場合）、N日の集計は翌日N + 1で計算した場合と同じになります。 N + 10日目にそれを計算すると、テーブル全体のリフレッシュをやめることができ、追加だけができます。エンティティが完全に不変ではなく、一定期間（例えば、リードコホートによる売上変換がリードから30日以内に起こる可能性があるなど）後に安定している場合は、最後のX日だけを再処理する毎回 – AlexYes