Amazon QuickSightで増分更新したらデータが二重に？増分更新が使える場合と使えない場合をまとめてみた

「増分更新」について気になっていたことを試したところ、データが二重で登録されてしまうという状況に陥ってしまいました。そうなってしまった理由を、仕様とともに解説します。

増分更新は、使える場面と使えない場面があるので、「仕様を正しく理解して、使い分ける」ことが大事だということがわかりました。

Amazon QuickSightのデータ更新には「フル更新」と「増分更新」の２パターンがある

Amazon QuickSightのデータ更新には「フル更新」と「増分更新」の２パターンがあります。 データ全件を取り込み直すより、更新された分だけを取り込めたらデータ取り込み量を減らすことができます。

更新スケジュール登録画面

今すぐ更新画面

増分を判定するために、日付列を指定して範囲を限定するんだろうというイメージはできるものの、「こういう場合はどうなるんだろう？」と気になっていたことがいくつかあったので、試してみました。

「増分更新」の気になることを試してみた

気になっていたこと

日付列を持ってない場合は、やっぱり無理？

データを物理削除している場合、削除データはSPICEに残ってしまうよね？

過去日付分は取り込まれるの？

未来日付分は取り込まれるの？

日付列を持ってない場合は、やっぱり増分更新は無理？

結論：日付列がないと無理です。

増分プロパティの設定画面で、必ず日付列を設定するので、必須です。

データを物理削除している場合、削除データはSPICEに残ってしまうよね？

結論：物理削除したデータは、SPICEに残ってしまいます。

最初に「フル更新」でDBの状態とSPICEの状態を一致させた後に、データを物理削除して「増分更新」を実行しました。

削除前

削除後

増分更新の設定は下記の状態でデータ取り込みしています。

取込履歴を見ると、取り込まれたデータ件数が０件となっており、取り込まれていないことがわかります。

過去日付分は、取り込まれるの？

結論：過去日付分は取り込まれません。（想定通り）

更新日を過去日付で更新します。

更新前

更新後　

増分更新の設定は下記の状態でデータ取り込みしています。

取込履歴を見ると、取り込まれたデータ件数が０件となっており、取り込まれていないことがわかります。

未来日付分は取り込まれるの？

結論：未来日付分は取り込まれる（想定通り） でも、データが二重になってしまいました！（想定外）

更新前　

更新後

増分更新の設定は下記の状態でデータ取り込みしています。

取込履歴を見ると、取り込まれたデータ件数が1件、全部で10001件となっており、1件増えていることがわかります。なんで？？？

データが二重になったのはなぜ？

指定した範囲のSPICEのデータをdeleteしてinsertするというのが、QuickSightの仕様でした。指定した範囲を超えたものは、deleteされません。

増分更新では、更新ごとに照会および転送されるデータが少なくなります。たとえば、1 月 1 日から 6 月 30 日までのデータを含む 180,000 レコードのデータセットがあるとします。7 月 1 日に、7 日間のルックバック ウィンドウでデータの増分更新を実行します。QuickSight はデータベースにクエリを実行し、6 月 24 日 (7 日前) 以降のすべてのデータ (7,000 レコード) を要求します。

その後、QuickSight は 6 月 24 日以降、現在 SPICE にあるデータを削除し、新しくクエリされたデータを追加します。

翌日 (7 月 2 日)、QuickSight は同じことを行いますが、6 月 25 日 (再び 7,000 レコード) からクエリを実行し、同じ日付の既存のデータセットから削除します。毎日 180,000 レコードを取り込む必要がなく、7,000 レコードを取り込むだけで済みます。

指定した範囲外のデータを更新（削除）された場合、SPICEに元々あったデータはdeleteされません。そのまま、指定範囲のデータがinsertされることになります。

「増分更新」は、SPICE側で同じIDかどうかで判定してupdateするという仕様ではないのです。←これが私の思い込みでした。

ということは、今回の物理削除の検証は、たまたま指定範囲外データが残りましたが、もし指定した範囲内だったら、きちんと連動していたということですね。

変更される日付列の特性をしっかり把握してから、「増分更新」の設定をしよう。

「増分更新」を設定したい場合は、「ある一定期間が経過したデータは、更新されないこと」を事前にしっかり確認しておきましょう。

「増分更新」が設定できないと考えられるパターン

日付列を持っていない

物理削除がありえる

古いデータへの更新があり得る（データ更新期間が絞れない）

「増分更新」が設定できると考えられるパターン

日付列を持っている

物理削除されることはない

データ更新期間が絞れる

例えば、

insertしかないログデータ

締日の概念がある会計系データ（その締日を超えたらデータ更新される可能性はない）

なら可能だと思います。

二重登録されてしまうけど、どうしても「増分更新」を使いたい

二重登録覚悟でSPICEを作っておき、ダッシュボード作成時にID重複前提で作り込むということも、できるかもしれません。（例えば、IDのカウント集計は「個別の値でカウント」で行うとか）

しかし、この場合、ダッシュボードの作り手全員に対して、データが二重にありえること周知しておかねばならないですし、本当に見たい形でのダッシュボード表現ができなくなる可能性があります。ので、やっぱりオススメできないです。

ふりかえり

今までなかなか「増分更新」を使う場面がなかったので、触ってみてスッキリしました。仕様に対する私の勝手な思い込みがあったせいで、二重登録された瞬間は「なんで？」となりましたが、「仕様はちゃんと確認してからやろうね」ということで終わりたいと思います。