MktKb
July 30, 2025, 5:45am
1
1つの分析シートにおいて、
複数のデータセットを用いたダッシュボードを作成しています。
データセットAをもとに集計した数値
例)購入ユーザ数
:計算フィールドにて、distinct_count(purchaser_id)で集計
データセットBをもとに集計した数値
例)アクティブユーザ数
:計算フィールドにて、distinct_count(user_id)で集計
これらの数値を使い、
購入ユーザ数/アクティブユーザ数
というように組み合わせて、購入率を算出できると良いのですが、
計算フィールドにて異なるデータセットをもとに集計した値を組み合わせることができなそうなため、
何か解決方法はございますでしょうか…?
@MktKb さん、ご質問ありがとうございます。
ご記載の通り複数のデータセットに跨って計算フィールドを作成することができません。
解決策としてはデータセットAとデータセットBをJOINした新たなデータセットを作成し、そのデータセットから作成した分析内で計算フィールドを作成いただくことが考えられます。purchaser_idとuser_idが同じID体系で結合キーとして使える、かつアクティブユーザーは購入ユーザーを包含するという関係でしたら、以下のようにRIGHT JOINし、分析内でdistinct_count({purchaser_id})/distinct_count({user_id})と言う計算フィールドを作ることで目的の購入率を計算できると思いますがいかがでしょうか。
1 Like
MktKb
July 31, 2025, 6:41am
3
回答いただきありがとうございます!
purchaser_idとuser_idが同じID体系で結合キーとして使える、かつアクティブユーザーは購入ユーザーを包含するという関係でしたら、以下のようにRIGHT JOINし、分析内でdistinct_count({purchaser_id})/distinct_count({user_id}) と言う計算フィールドを作ることで目的の購入率を計算できると思いますがいかがでしょうか。
本来はアクティブユーザーの中に購入ユーザーが内包されるはずですが、
アクティブユーザーがシステム上一部取得できず、完全に内包する関係にはなっておりません。
購入データの値は正確な値を求めており、アクティブユーザの値は一部取得できていない分の誤差がある程度あっても許容するという方針で進めているのですが、
試しにRIGHT JOINではなくFULL JOINで結合したら求めている数値になりそうです。
あまりFULL JOINをする機会がないのですが、使い方として合っておりますでしょうか…?
@MktKb ご確認ありがとうございます。
本来はアクティブユーザーの中に購入ユーザーが内包されるはずですが、
アクティブユーザーがシステム上一部取得できず、完全に内包する関係にはなっておりません。
購入データの値は正確な値を求めており、アクティブユーザの値は一部取得できていない分の誤差がある程度あっても許容する
はい、その前提でしたらFULL JOINでよろしいかと思います。
MktKb
September 16, 2025, 8:42am
5
以前いったん解決したのですが、
B.アクティブユーザーに対して、更にFULL JOINで「C.全ユーザ」というテーブルを結合してみたところ、
The combined size of all secondary tables must be less than 1 GB for datasets with cross-source JOIN operation.
The primary table is “A.購入データ”, and all other tables are secondary tables.
というエラーになりました。
試しにプライマルテーブルを入れ替えても同様のエラーになります。
こちらのエラーを回避する方法はございますでしょうか…?
ytakahr
September 16, 2025, 2:36pm
6
@MktKb さん、ご質問ありがとうございます。
データセットのJOINで利用するセカンダリテーブルには以下ページに記載のサイズ制限がございます。
同じソーステーブル – テーブルが単一のクエリデータソースから発信された場合、Quick Sight は結合サイズに制限を適用しません。ソースクエリエンジンが設定している結合サイズの制限が上書きされることはありません。
クロスソースのデータセット – このタイプの結合には、SPICE に保存されていないさまざまなデータソースからのテーブルが含まれます。これらのタイプの結合の場合、Quick Sight はデータセット内の最大のテーブルを自動的に識別します。他のすべてのセカンダリテーブルの合計サイズは 1 GB 未満である必要があります。
SPICE に保存されているデータセット — このタイプの結合には、すべて SPICE に取り込まれているテーブルが含まれます。この結合内のすべてのセカンダリテーブルの合計サイズは 20 GB を超えることはできません。
エラーメッセージから推察するに、恐らく現在は異なるデータソースのデータセットをJOINしているものと思いますが、認識に相違あればご指摘ください。
これを回避する方法は2つあります。
JOINしているデータセットがQuick Sight上では異なるデータソース定義から作成されているが、物理的には同一のデータソース(例. Redshiftクラスタ)を参照している場合。この場合、両データセットをQuick Sight上の同一のデータソース定義から作成しなおすことで同一データソース (same-source)のJOINとなり、セカンダリテーブルのサイズ制限は無くなります。(上記の1点目に該当)
JOINしているデータセットが物理的にも異なるデータソースを参照している場合。この場合、各データセットを直接クエリからSPICEに切り替え、SPICEデータセット同士の結合とすることで、セカンダリテーブルの制限が1GB→20GBに拡張されます。
データセットのJOINにかかる制限は以下の動画にもわかりやすく解説されていますので、合わせてご覧ください。
なお恐れ入りますが、今後、既に解決済みのトピックにご質問をいただく場合には、Solutionは解除せず、前回の投稿リンクを含め新規のトピックでご投稿いただけますと幸いです。どうぞよろしくお願いいたします。