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

データアナリティクス事業本部の武田です。今日は、Amazon QuickSightの「増分更新」について説明します。
2022.11.15

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

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

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

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

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

今すぐ更新画面

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

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

気になっていたこと

  • 日付列を持ってない場合は、やっぱり無理?
  • データを物理削除している場合、削除データはSPICEに残ってしまうよね?
  • 過去日付分は取り込まれるの?
  • 未来日付分は取り込まれるの?
  • 日付列を持ってない場合は、やっぱり増分更新は無理?

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

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

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

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

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

    削除前

    削除後

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

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

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

    結論:過去日付分は取り込まれません。(想定通り)

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

    更新前

    更新後 

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

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

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

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

    更新前 

    更新後

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

    取込履歴を見ると、取り込まれたデータ件数が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のカウント集計は「個別の値でカウント」で行うとか)

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

    ふりかえり

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