集計を実装する
セマンティック モデルが大規模なファクト テーブル (数億行または数十億行のテーブル) に対してレポートを提供する場合、最適化された DAX やカーディナリティの低下さえ十分ではない可能性があります。 集計では、詳細テーブル全体をスキャンする代わりに、一般的なクエリが小さく高速なメモリ内キャッシュから結果を返すように、事前にデータを集計する方法が提供されます。
集計が役立つタイミングを理解する
集計は、次の 3 つの条件が存在する場合に最も重要です。
- 大規模なファクト テーブル。 メモリ全体に効率的に読み込まれない数億行のテーブル。
- 一般的なクエリ パターン。 ユーザーは、個々のトランザクション レベルではなく、サマリー レベル (月別、リージョン別、製品カテゴリ別) で頻繁にクエリを実行します。
- DirectQuery または複合モデル。 詳細データは外部ソースに存在し、ラウンドトリップ クエリは低速です。
集計は、クエリ エンジンが最初にチェックするインポート モード テーブルに事前計算済みの概要データを格納することで機能します。 集計からクエリに応答できる場合、結果はメモリからすぐに返されます。 そうでない場合、クエリは詳細テーブルに分類されます。
長いレポートの先頭にあるエグゼクティブサマリーのような集計を考えてみましょう。 ほとんどの読者は、概要から必要なものを取得します。 完全な詳細が必要なユーザーのみがドキュメント全体を読みます。
ユーザー定義集計の操作
ユーザー定義集計を使用すると、集計および格納される内容を完全に制御できます。 それらを実装するには:
- 集計テーブルを作成します。 Power Query で、ファクト テーブルを目的の粒度で集計するテーブルを作成します。 たとえば、個々のトランザクションではなく、製品カテゴリと地域別に日次売上を集計します。
- 集計マッピングを構成します。 Power BI Desktop のモデル ビューで、集計テーブルを選択し、Manage 集計を開きます。 各列を対応する詳細テーブル列にマップし、集計関数 (Sum、Count、Min、Max、GroupBy) を指定します。
- 集計テーブルを非表示にします。 集計テーブルは、レポート作成者に対して非表示にする必要があります。 クエリ エンジンでは自動的に使用されます。ユーザーは存在することを知る必要はありません。
- ストレージ モードを設定します。 集計テーブルでは、メモリ内の高速アクセスにインポート モードが使用されます。 詳細テーブルでは通常 DirectQuery が使用されるため、数十億行をメモリに読み込む必要はありません。
ビジュアルが集計の粒度と関数に一致するデータを照会すると、エンジンがインポート テーブルから結果を返します。 クエリで細かい粒度が必要な場合は、DirectQuery の詳細テーブルに透過的に移動します。
Note
ユーザー定義集計には、複合モデル (ストレージ モードが混在するテーブル) が必要です。 集計テーブルは Import で、詳細テーブルは DirectQuery です。 両方のテーブルで、同じディメンション テーブルに対して一致するリレーションシップが必要です。
自動集計を使用する
自動集計では、機械学習を使用して集計対象を決定することで、このプロセスが簡略化されます。 集計テーブルを手動で作成してマッピングする代わりに、Power BIはクエリ ログを分析し、実際の使用パターンに基づいて集計を自動的に作成、更新、および削除します。
自動集計を有効にするには:
- セマンティック モデルの Settings をPower BI サービスで開きます。
- 自動集計トレーニングを有効にします。
- 1 つ以上の更新をスケジュールします。
最初のトレーニングと更新サイクルでは、Power BIはクエリ ログ (7 日間のクエリ データを格納) を評価し、メモリ内集計テーブルを作成します。 システムは継続的に適応します。クエリ パターンが変化すると、集計は最も頻繁に要求される概要に優先順位を付けるために調整されます。
自動集計には、いくつかの要件があります。
- Premium、Premium Per User、または Fabric の容量
- 集計が必要なテーブルの DirectQuery ストレージ モード
- サポートされているデータ ソース (Azure SQL Database、Synapse、Databricks、Snowflake など)
ユーザー定義集計と自動集計の両方を同じモデルで使用できます。 ユーザー定義集計は既知の静的パターンを処理しますが、自動集計は変化するクエリ動作に適応します。
集計の有効性を監視する
集計を実装した後、それらが使用されていることを確認します。
- 更新履歴を確認します。 モデルの設定では、更新履歴には、集計キャッシュが使用するメモリの量と、それが提供するクエリの数が表示されます。
- Azure Log Analytics を使用します。 容量がAzure Log Analyticsに接続されている場合は、集計によって処理されるクエリの割合と、データ ソースに直接ヒットしたクエリの割合を分析できます。 これにより、DAX および SQL クエリ レベルでの集計ヒット 率の詳細なビューが提供されます。
クエリに集計が不足している (DirectQuery に入る) 場合は、クエリ パターンを確認します。 集計では、ユーザーが要求しているグレインや関数が対象にならない場合があります。
集計とDirect Lake
Microsoft Fabricでは、Direct Lake ストレージ モードを使用するセマンティック モデルは、メモリにデータをインポートしたり DirectQuery クエリを送信したりすることなく、OneLake の Delta テーブルから直接読み取ります。 Direct Lake は、データインポートと外部クエリラウンドトリップのオーバーヘッドを回避するため、多くのシナリオで既に高速です。
集計は、次の場合に Direct Lake を補完できます。
- 基になる Delta テーブルは非常に大きく、一般的なクエリでは概要レベルの結果のみが必要です。
- 頻繁にクエリを実行するパターンの列セグメントに読み込まれるデータの量を減らす必要があります。
ほとんどの Direct Lake モデルでは、まず集計なしでパフォーマンスをテストします。 測定で明確なニーズが示されている場合にのみ、それらを追加します。