Amazon QuickSightのPRE_AGGとPRE_FILTERを理解して、計算順序と"全体と部分"の分析をマスターしよう

Amazon QuickSightのPRE_AGGとPRE_FILTERを理解して、計算順序と"全体と部分"の分析をマスターしよう

QuickSightで「全体の売上比率」と「フィルター後の構成比」を正しく計算するため、PRE_AGGとPRE_FILTERの使い分けを実データで解説します。
Clock Icon2025.01.31

データアナリティクス事業本部インテグレーション部機械学習チーム・新納(にいの)です。

Amazon QuickSightではレベルアウェア計算(LAC)という機能があり、ウィンドウ関数と集計関数を使う際に関数を適用する粒度を指定できます。

この機能を使う際に考慮すべきことは計算順序です。QuickSightでは特定の順序で計算処理をしてから数値を表示するため、場合によっては計算レベルを適切に設定しておかないと意図しない結果となるケースがあります。QuickSightではPRE_AGGPRE_FILTERという計算レベルがあります。本エントリではそれぞれの使い分けやユースケースを説明します。

レベルアウェア計算(LAC)についておさらい

レベルアウェア計算(LAC)は、ウィンドウ関数と集計関数を使う際に関数を適用する粒度を指定できるQuickSightの機能です。主に以下の2つの計算レベルがあります。

  1. LAC-A関数:集計のグループ化レベルを指定可能
// 例:国とプロダクトでグループ化して集計
sum({sales}, [{Country},{Product}])
  1. LAC-W関数:計算のウィンドウ(範囲)やパーティション(区切り)を指定可能
// 例:地域ごとの売上を計算
sumOver(
    sales,      // 計算対象
    [region], // パーティション(区切り)
    PRE_AGG       // 計算タイミング(PRE_FILTER/PRE_AGG)
)

この機能により、分析の目的に応じて柔軟なディメンション・適切なタイミングやパーティションで計算を実行できます。詳細については以下ブログをご参照ください。

https://dev.classmethod.jp/articles/quicksight-level-aware-calculations/

QuickSightの計算順序とは

QuickSightでは、以下の順序で計算が実行されます:

1. LAC-W(PRE_FILTER)

  • フィルター適用前の計算
  • 元のテーブルレベルでの計算

2. LAC-W(PRE_AGG)

  • フィルター適用後、集計前の計算
  • 分析時に追加されたフィルターはここで適用

3. LAC-A

  • カスタムレベルでの集計
  • ビジュアルでの集計前に実行

4. ビジュアルレベル

  • 最終的な集計処理
  • 表計算やその他の計算

この計算順序を理解することで、意図した結果を得るために適切な計算レベルを選択できます。詳細は以下のドキュメントをご参照ください。

https://docs.aws.amazon.com/ja_jp/quicksight/latest/user/order-of-evaluation-quicksight.html

PRE_AGGとPRE_FILTERの使い分け

QuickSightで計算順序を決定する計算レベルのパターンは以下の通りです。

  • PRE_FILTER
    • フィルター適用前に計算
  • PRE_AGG
    • フィルター適用後、集計前に計算
  • POST_AGG_FILTER(デフォルト)
    • フィルター適用後、集計前の段階で計算
    • sumOver関数などで計算レベルを指定しない場合のデフォルト動作

例えば以下のような違いがあります。

// デフォルト(POST_AGG_FILTER)
sumOver(sales)
// 結果:ビジュアル表示時に計算。フィルターと集計の影響を受ける

// PRE_AGGを明示的に指定
sumOver(sales, [], PRE_AGG)
// 結果:集計前に計算。より正確な構成比などが計算可能

実際に使ってみる

以下のような店舗別売上のデータセットを準備しました。

  • 8つの店舗
  • 2つの商品カテゴリー(パン、おでん)
  • プロモーション実施店舗の判別(フラグ:1)
日付 店舗ID 店舗名 都道府県 製品カテゴリ 売上 売上目標 プロモーションフラグ
2025/1/29 10 馬喰町店 東京 パン 150000 200000 1
2025/1/29 20 喜連瓜破店 大阪 パン 120000 150000 0
2025/1/29 21 放出店 大阪 パン 100000 150000 0
2025/1/29 22 四條畷店 大阪 パン 70000 150000 1
2025/1/29 30 雑餉隈店 福岡 パン 80000 100000 1
2025/1/29 30 雑餉隈店 福岡 おでん 50000 60000 1
2025/1/29 40 京終店 奈良 おでん 1000 10000 0
2025/1/29 41 榛原店 奈良 パン 2000 10000 0

PRE_FILTERを使った分析

1. 売上合計を算出する

まずはシンプルに店舗ごとの売上合計をテーブル形式で算出してみましょう。グループ化の条件に店舗を、値に売上を指定するだけです。

  • 全店舗の売上合計:573,000円

20250129_quicksight_filters_salesagg

今度は、プロモーションフラグをフィルタに追加してみましょう。これでプロモーションフラグを持つ店舗別の売上合計を確認できるようになりました。フラグを1に設定すると、売上の合計金額もフラグが1の店舗の売上に絞って合算されます。

  • プロモーション実施店舗の売上合計:350,000円

20250129_quicksight_filters_controladd

2. PRE_FILTERを使わないと…(間違いパターン)

各行に全店舗の売上合計を表示させたいとします。sumOver(sum({売上}))を計算フィールドにセットして値に指定すると573000円が各行に表示されるようになりました。

20250129_quicksight_filters_preagg2

各店舗の売上達成率と全体の売上達成率を並べて見るために以下の計算フィールドを作成しました。

  • 各店舗の売上達成率:sum(売上目標)/sum(売上)

  • 全体の売上達成率:sumOver(売上目標)/sumOver(sum(売上))

20250129_quicksight_filters_noprefilter3

しかし、先ほど追加したフィルタを操作すると売上の合計も全体の売上達成率が変わってしまいました。フラグが1の店舗の売上合計350000円が表示されています。これでは意図した数値とはなっておらず、誤った分析結果につながる可能性があります。

20250129_quicksight_filters_noprefilter4

3. PRE_FILTERを使って解決

前項で数値が変わってしまった原因はQuickSightの計算順序にあります。先ほど利用したsumOver関数はデフォルトではビジュアルが表示される際に処理されます。つまり、フィルタ適用後に計算されます。今回のケースではフラグが1のレコードだけ表示→表示されたレコードを集計という流れですね。このように、フィルタ適用前に計算処理を実施したい場合はPRE_FILTERを使います

店舗全体の売上合計はフラグが1でも0でも同じ数値でないといけません。以下の通り計算フィールドを再作成しました。

  • 全店舗の売上合計: sumOver(売上, [], PRE_FILTER)

  • 全体の売上達成率:sumOver(売上, [], PRE_FILTER) / sumOver(売上目標, [], PRE_FILTER)

すると、フィルタ結果に左右されない数値が表示されるようになりました。

20250129_quicksight_filters_prefilter

PRE_AGGを使った分析

1. カテゴリー別の売上構成比を算出する

先ほどのデータセットを使って、今度は商品カテゴリー別の売上構成比を見てみましょう。グループ化の条件に商品カテゴリーを、値に売上を指定します。

20250129_quicksight_filters_preagg

パンカテゴリーの売上は522,000円、おでんカテゴリーの売上は51,000円となっています。これらの売上が全体に占める割合を計算してみましょう。

2. PRE_AGGを使わないと…(間違いパターン)

カテゴリー別の売上構成比を計算するために、以下の計算フィールドを作成してみました。

sum(売上) / sumOver(sum(売上), [], PRE_FILTER)

都道府県別で商品カテゴリごとの構成比を確認したいとします。都道府県でフィルタできるようにコントロールを追加し、福岡でフィルタリングすると、以下の結果になりました。

  • パンの売上構成比:80,000 / 573,000 = 13.96%
  • おでんの売上構成比:50,000 / 573,000 = 8.73%

これは全国の総売上(573,000円)に対する構成比を示しているため、構成比を合算しても100%になりません。福岡店舗内での商品カテゴリー別の構成比を知りたい場合は、この計算では適切ではありません。

20250129_quicksight_filters_preagg2

3. PRE_AGGを使って解決

フィルター後のデータの中での構成比を見たい場合は、PRE_AGGを使います。以下のように計算フィールドを作り直してみましょう。

sum(売上) / min(sumOver(売上, [], PRE_AGG))

福岡県でフィルタリングすると以下の結果が取得できました。

  • パンの売上構成比:80000 / 130000 = 61.5%
  • おでんの売上構成比:50000 / 130000 = 38.5%

20250129_quicksight_filters_preagg3

このように、福岡店舗内での正確な商品カテゴリー構成比を計算できるようになりました。フィルター後のデータの中での正確な構成比を計算できています。

最後に

PRE_AGGとPRE_FILTERの使いどころについてご紹介しました。それぞれの計算レベルは分析の目的によって使い分けが必要です。ざっくりと以下のように捉えておくといいかもしれません。

  • PRE_FILTER:全体を基準にした比率を保持したい場合
    • 例:全店舗の売上に対するプロモーション店舗の貢献度、全体の売上目標に対する達成率
  • PRE_AGG:フィルター後のデータ内での比率を見たい場合
    • 例:地域別の商品カテゴリー構成比、プロモーション店舗内での地域別シェア

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.