この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「増分更新」について気になっていたことを試したところ、データが二重で登録されてしまうという状況に陥ってしまいました。そうなってしまった理由を、仕様とともに解説します。
増分更新は、使える場面と使えない場面があるので、「仕様を正しく理解して、使い分ける」ことが大事だということがわかりました。
Amazon QuickSightのデータ更新には「フル更新」と「増分更新」の２パターンがある
Amazon QuickSightのデータ更新には「フル更新」と「増分更新」の２パターンがあります。 データ全件を取り込み直すより、更新された分だけを取り込めたらデータ取り込み量を減らすことができます。
更新スケジュール登録画面
今すぐ更新画面
増分を判定するために、日付列を指定して範囲を限定するんだろうというイメージはできるものの、「こういう場合はどうなるんだろう？」と気になっていたことがいくつかあったので、試してみました。
「増分更新」の気になることを試してみた
気になっていたこと
日付列を持ってない場合は、やっぱり増分更新は無理？
結論：日付列がないと無理です。
増分プロパティの設定画面で、必ず日付列を設定するので、必須です。
データを物理削除している場合、削除データは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のカウント集計は「個別の値でカウント」で行うとか）
しかし、この場合、ダッシュボードの作り手全員に対して、データが二重にありえること周知しておかねばならないですし、本当に見たい形でのダッシュボード表現ができなくなる可能性があります。ので、やっぱりオススメできないです。
ふりかえり
今までなかなか「増分更新」を使う場面がなかったので、触ってみてスッキリしました。仕様に対する私の勝手な思い込みがあったせいで、二重登録された瞬間は「なんで？」となりましたが、「仕様はちゃんと確認してからやろうね」ということで終わりたいと思います。
2
