Power BI Desktop での集計Aggregations in Power BI Desktop

Power BI で集計 を使用すると、以前は不可能だった方法でビッグ データを対話的に分析することが可能になります。Using aggregations in Power BI enables interactive analysis over big data in ways that previously weren't possible. 集計によって、意思決定のために大規模なデータセットをロック解除するコストを大幅に削減できます。Aggregations can dramatically reduce the cost of unlocking large datasets for decision making.

Microsoft Power BI Desktop での集計

集計を使用することの利点を次に示します。The following list provides advantages to using aggregations:

  • ビッグ データに対するクエリのパフォーマンス: ユーザーが Power BI レポートのビジュアルを操作するときに、DAX クエリがデータセットに送信されます。Query performance over big data - as users interact with visuals on Power BI reports, DAX queries are submitted to the dataset. 詳細レベルで必要なリソースの一部を使用して、集計レベルでデータをキャッシュすることでクエリ速度が向上します。Boost query speeds by caching data at the aggregated level, using a fraction of the resources required at the detail level. それ以外の方法では不可能な方法でビッグ データのロックを解除します。Unlock big data in a way that would otherwise be impossible.
  • データ更新の最適化: 集計レベルでデータをキャッシュすることで、キャッシュ サイズを削減し、更新時間を短縮します。Data refresh optimization - reduce cache sizes and refresh times by caching data at the aggregated level. データがユーザーに使用可能になるまでの時間を短縮します。Speed up the time to make data available for users.
  • 分散アーキテクチャを実現: Power BI のメモリ内キャッシュで集計クエリの処理を可能にすることで、効果的に処理します。Achieve balanced architectures - allow the Power BI in-memory cache to handle aggregated queries, which it does effectively. DirectQuery モードでデータ ソースに送信されるクエリを制限して、同時実行の制限内に収まるようにします。Limit queries sent to the data source in DirectQuery mode, helping stay within concurrency limits. 到着するクエリは、データ ウェアハウスとビッグ データ システムが通常に処理できる、フィルター処理された、トランザクション レベルのクエリになります。Queries that do get through tend to be filtered, transactional-level queries, which data warehouses and big-data systems normally handle well.

テーブルレベルのストレージTable-level storage

テーブルレベルのストレージは通常、集計機能で使用されます。Table-level storage is normally used with the aggregations feature. 詳細については、Power BI Desktop のストレージ モードに関する記事をご覧ください。See the storage mode in Power BI Desktop article for more information.

データ ソースの種類Data source types

集計は、データ ウェアハウスやデータ マート、Hadoop ベースのビッグ データ ソースなど、ディメンション モデルを表すデータ ソースと共に使用されます。Aggregations are used with data sources representing dimensional models, such as a data warehouses, data marts, and Hadoop-based big-data sources. この記事では、Power BI での一般的なモデリングの相違点を、データ ソースの種類ごとに説明します。This article describes typical modeling differences in Power BI for each type of data source.

Power BI のインポート (非多次元) と DirectQuery のすべてのソースが集計で機能します。All Power BI Import and (non-multidimensional) DirectQuery sources work with aggregations.

リレーションシップに基づく集計Aggregations based on relationships

リレーションシップに基づく集計は通常、ディメンション モデルで使用されます。Aggregations based on relationships are typically used with dimensional models. データ ウェアハウスおよびデータ マートをソースとする Power BI データセットは、ディメンション テーブルとファクト テーブル間のリレーションシップを持つスター/スノーフレーク スキーマと似ています。Power BI datasets that source from data warehouses and data marts resemble star/snowflake schemas with relationships between dimension tables and fact tables.

1 つのデータ ソースからの次のモデルを検討してください。Consider the following model, which is from a single data source. すべてのテーブルが最初に DirectQuery を使用しているとします。Let’s say all the tables are using DirectQuery to start with. Sales ファクト テーブルには、数十億の行が含まれています。The Sales fact table contains billions of rows. Sales のストレージ モードをキャッシュの [インポート] に設定すると、かなりの量のメモリを消費し、多額の管理オーバーヘッドがかかる可能性があります。Setting the storage mode of Sales to Import for caching would consume considerable memory and management overhead.

モデル内のテーブル

代わりに、集計テーブルとして Sales Agg テーブルを作成します。Instead, we create the Sales Agg table as an aggregation table. これは Sales よりも粒度が高いため、含まれる行は大幅に少なくなります。It's at a higher granularity than Sales, so it'll contain far fewer rows. 行数は、CustomerKeyDateKey、および ProductSubcategoryKey でグループ化された SalesAmount の合計と等しくなるはずです。The number of rows should equal the sum of SalesAmount grouped by CustomerKey, DateKey, and ProductSubcategoryKey. 数十億行ではなく、数百万行になり、はるかに管理しやすくなります。Instead of billions, it might be millions of rows, which are much easier to manage.

次のディメンション テーブルは、高いビジネス価値を持つクエリに最もよく使用されるとします。Let's assume that the following dimension tables are the most commonly used for the queries with high business value. これらのテーブルは、一対多 (または多対一) リレーションシップを使用して、Sales Agg をフィルター処理できます。They're the tables that can filter Sales Agg using one-to-many (or many-to-one) relationships.

  • 地理Geography
  • 顧客Customer
  • 日付Date
  • 製品サブカテゴリProduct Subcategory
  • Product Category (製品カテゴリ)Product Category

次の図に、このモデルを示します。The following image shows this model.

モデル内の集計テーブル

注意

Sales Agg テーブルはよくあるテーブルなので、さまざまな方法で読み込める柔軟性があります。The Sales Agg table is just another table, so it has the flexibility of being loaded in a variety of ways. たとえば、集計は、ソース データベースで ETL/ELT プロセスを使用して実行することも、テーブルの M 式で実行することもできます。For example, aggregation can be performed in the source database using ETL/ELT processes, or by the M expression for the table. 集計では、Power BI Premium での増分更新の有無にかかわらず、インポート ストレージ モードを使用できます。または DirectQuery にして列ストア インデックスを使用して高速クエリ用に最適化することもできます。It can use Import storage mode with or without incremental refresh in Power BI Premium, or it can be DirectQuery and optimized for fast queries using columnstore indexes. この柔軟性により、ボトルネックを避けるためにクエリ負荷を分散する分散アーキテクチャが可能になります。This flexibility enables balanced architectures that spread query load to avoid bottlenecks.

ストレージ モードStorage mode

使用している例を使って続けましょう。Let's continue with the example we're using. クエリを高速化するため、Sales Agg のストレージ モードを [インポート] に設定します。We set the storage mode of Sales Agg to Import to speed up queries.

ストレージ モードの設定

これを行うと、関連するディメンション テーブルを [デュアル] ストレージ モードに設定できることを知らせる次のダイアログが表示されます。When we do so, the following dialog appears, letting us know that the related dimension tables can be set to storage mode Dual.

[ストレージ モード] ダイアログ

これらを [デュアル] に設定すると、関連するディメンション テーブルを、サブクエリに応じてインポートまたは DirectQuery として機能させることができます。Setting them to Dual allows the related dimension tables to act as either Import or DirectQuery depending on the subquery.

  • Sales Agg テーブル (インポート) からメトリックを集計するクエリと、関連するデュアル テーブルからの groupby 属性は、メモリ内キャッシュから返すことができます。Queries that aggregate metrics from the Sales Agg table, which is Import, and group by attribute(s) from the related Dual tables can be returned from the in-memory cache.
  • Sales テーブル (DirectQuery) 内でメトリックを集計するクエリと、関連するデュアル テーブルからの groupby 属性は、DirectQuery モードで返すことができます。Queries that aggregate metrics in the Sales table, which is DirectQuery, and group by attribute(s) from the related Dual tables can be returned in DirectQuery mode. グループ化操作を含むクエリ ロジックが、ソース データベースに渡されます。The query logic including the group by operation will be passed down to the source database.

デュアル ストレージ モードに関する詳細については、ストレージ モードに関する記事を参照してください。For more information on the Dual storage mode, see the storage mode article.

リレーションシップの強弱Strong vs. weak relationships

リレーションシップに基づいて集計をヒットさせるには、強いリレーションシップが必要です。Aggregations hits based on relationships require strong relationships.

強いリレーションシップには、両方のテーブルが "単一ソース" からのものである以下の組み合わせが含まれます。Strong relationships include the following combinations where both tables are from a single source.

*多の側のテーブルTable on the *many sides 1 側のテーブルTable on the 1 side
デュアルDual デュアルDual
インポートImport インポートまたはデュアルImport or Dual
DirectQueryDirectQuery DirectQuery またはデュアルDirectQuery or Dual

"ソース間" のリレーションシップが強いと見なされる唯一のケースは、両方のテーブルがインポートである場合です。The only case where a cross-source relationship is considered strong is if both tables are Import. 多対多リレーションシップは常に弱いと見なされます。Many-to-many relationships are always considered weak.

リレーションシップに依存しない "ソース間" の集計のヒットについては、グループ化列に基づく集計に関する以下のセクションをご覧ください。For cross-source aggregation hits that don't depend on relationships, see section below on aggregations based on group-by columns.

集計テーブルにアドレスを指定することはできませんAggregation tables are not addressable

データセットへの読み取り専用アクセス権を持つユーザーは、集計テーブルにクエリを実行できません。Users with read-only access to the dataset cannot query aggregation tables. これにより、RLS とともに使用する場合のセキュリティの問題が回避されます。This avoids security concerns when used with RLS. コンシューマーとクエリは、集計テーブルではなく、詳細テーブルを参照するため、集計テーブルの存在を知る必要はありません。Consumers and queries refer to the detail table, not the aggregation table; they don't even need to know the aggregation table exists.

このため、Sales Agg テーブルは非表示にする必要があります。For this reason, the Sales Agg table should be hidden. 非表示になっていない場合、[すべて適用] をクリックすると、[集計の管理] ダイアログ ボックスが非表示に設定されます。If it is not, the Manage aggregations dialog will set it to hidden upon clicking the Apply all button.

[集計の管理] ダイアログManage aggregations dialog

次に、集計を定義します。Next we define the aggregations. Sales Agg テーブルを右クリックして、 [集計の管理] コンテキスト メニューを選択します。Select the Manage aggregations context menu for the Sales Agg table, by right-clicking on the table.

[集計の管理] メニューの選択

[集計の管理] ダイアログが表示されます。The Manage aggregations dialog is displayed. Sales Agg テーブル内の各列の 1 行が表示され、ここで集計動作を指定できます。It shows a row for each column in the Sales Agg table, where we can specify the aggregation behavior. Sales テーブルを参照する Power BI データセットに送信されたクエリは、Sales Agg テーブルへ内部的にリダイレクトされます。Queries submitted to the Power BI dataset that refers to the Sales table are internally redirected to the Sales Agg table. データセットのコンシューマーが、Sales Agg テーブルの存在を知る必要はありません。Consumers of the dataset don't need to know the Sales Agg table even exists.

[集計の管理] ダイアログ

次のテーブルは、Sales Agg テーブルの集計を示しています。The following table shows the aggregations for the Sales Agg table.

集計テーブル

概要作成関数Summarization function

[概要作成] のドロップダウンでは、選択肢として次の値が提供されます。The Summarization drop-down offers the following values for selection.

  • カウントCount
  • GroupByGroupBy
  • 最大Max
  • 最小Min
  • 合計Sum
  • テーブル行数のカウントCount table rows

検証Validations

ダイアログによって次の重要な検証が適用されます。The following notable validations are enforced by the dialog:

  • 選択された詳細列には、カウントとテーブル行数のカウントの概要作成関数を除き、集計列と同じデータ型がある必要があります。The detail column selected must have the same datatype as the aggregation column except for the Count and Count table rows summarization functions. カウントとテーブル行数のカウントには、整数の集計列のみが提供されます。一致するデータ型は必要ありません。Count and Count table rows are only offered for integer aggregation columns, and don't require a matching datatype.
  • 3 つ以上のテーブルをカバーするチェーン集計は許可されていません。Chained aggregations covering three or more tables aren't allowed. たとえば、テーブル C を参照する集計を持つテーブル B を参照するテーブル A に集計を設定することはできません。For example, it is not possible to set up aggregations on Table A referring to Table B that has aggregations referring to Table C.
  • 2 つのエントリが同じ概要作成関数を使用し、同じ詳細テーブル/列を参照する重複した集計は許可されません。Duplicate aggregations where two entries use the same summarization function and refer to the same detail table/column aren't allowed.
  • 詳細テーブルは、インポートではなく、DirectQuery にする必要があります。Detail table must be DirectQuery, not Import.

このような検証のほとんどは、次の図のように、ドロップダウンの値を無効にして、ツールヒントの説明テキストを表示することで適用されます。Most such validations are enforced by disabling dropdown values and showing explanatory text in the tooltip, as shown in the following image.

ツールヒントで表示される検証

グループ化列Group by columns

この例では、3 つの GroupBy エントリは省略可能です。これらは集計動作には影響しません (この後の画像に示されている、DISTINCTCOUNT サンプル クエリを除く)。In this example, the three GroupBy entries are optional; they do not affect aggregation behavior (except for the DISTINCTCOUNT example query, shown in the upcoming image). これらは主に読みやすくする目的のために含まれています。They are included primarily for readability purposes. これらの GroupBy エントリがなくても、集計はリレーションシップに基づいてヒットされます。Without these GroupBy entries, the aggregations would still get hit based on the relationships. これは、この記事で後述するビッグ データの例で説明する、リレーションシップなしで集計を使用した場合の動作とは異なります。This is different behavior from using aggregations without relationships, which is covered by the big data example that follows later in this article.

非アクティブなリレーションシップInactive relationships

非アクティブなリレーションシップによって使用されている外部キー列によるグループ化と、集計ヒットで USERELATIONSHIP 関数に依存することはサポートされていません。Grouping by a foreign key column used by an inactive relationship and relying on the USERELATIONSHIP function for aggregation hits is not supported.

集計がクエリでヒットまたはミスされるかどうかを検出するDetecting whether aggregations are hit or missed by queries

クエリがメモリ内キャッシュ (ストレージ エンジン)、または SQL Profiler を使用して (データ ソースにプッシュされる) DirectQuery から返されるかどうかを検出する方法については、ストレージ モードに関する記事を参照してください。For more information about how to detect whether queries are returned from the in-memory cache (storage engine), or DirectQuery (pushed to the data source) using SQL Profiler, see the storage mode article. このプロセスは、集計がヒットされるかどうかを検出するためにも使用することができます。That process can also be used to detect whether aggregations are being hit, too.

さらに、SQL Profiler では、次の拡張イベントも提供されます。Additionally, the following extended event is provided in SQL Profiler.

Query Processing\Aggregate Table Rewrite Query

次の JSON スニペットでは、集計が使用されている場合のイベントの出力例を示しています。The following JSON snippet shows an example of the output of the event when an aggregation is used.

  • matchingResult は、集計がサブクエリに使用されたことを示します。matchingResult shows that an aggregation was used for the subquery.
  • dataRequest は、サブクエリで使用されたグループ化列と集計列を示します。dataRequest shows the group-by column(s) and aggregated column(s) used by the subquery.
  • mapping は、マップ先の集計テーブル内の列を示します。mapping shows the columns in the aggregation table that were mapped to.

集計が使用されたときのイベントの出力

クエリ例Query examples

次のクエリでは、Date テーブル内の列が集計をヒットできる粒度であるため、集計がヒットされます。The following query hits the aggregation, because columns in the Date table are at the granularity that can hit the aggregation. SalesAmount には、Sum 集計が使用されます。The Sum aggregation for SalesAmount will be used.

クエリの例

次のクエリでは、集計はヒットしません。The following query doesn't hit the aggregation. SalesAmount の合計を要求しているにもかかわらず、これは Product テーブル内の列に対するグループ化操作を実行します。これは集計をヒットできる粒度ではありません。Despite requesting the sum of SalesAmount, it's performing a group by operation on a column in the Product table, which is not at the granularity that can hit the aggregation. モデル内のリレーションシップを観察すると、1 つの製品サブカテゴリが複数の Product (製品) 行を持っている場合があり、クエリでは、集計する製品が判断できません。If you observe the relationships in the model, a product subcategory can have multiple Product rows; the query wouldn't be able to determine which product to aggregate to. このケースでは、クエリによって DirectQuery に戻され、データ ソースに SQL クエリが送信されます。In this case, the query reverts to DirectQuery and submits a SQL query to the data source.

クエリの例

集計の目的は、わかりやすい合計を求める単純な計算だけではありません。Aggregations aren't just for simple calculations that perform a straightforward sum. 複雑な計算にも役立ちます。Complex calculations can also benefit. 概念的には、複雑な計算は SUM、MIN、MAX、COUNT のそれぞれのサブクエリに分割され、各サブクエリは集計がヒットするかどうかを判断するために評価されます。Conceptually, a complex calculation is broken down into subqueries for each SUM, MIN, MAX and COUNT, and each subquery is evaluated to determine if the aggregation can be hit. クエリ プランの最適化のため、このロジックはすべてのケースには当てはまりませんが、大抵のものには当てはまります。This logic doesn't hold true in all cases due to query-plan optimization, but in general it should apply. 次の例では、集計がヒットします。The following example hits the aggregation:

クエリの例

COUNTROWS 関数は集計を利用できます。The COUNTROWS function can benefit from aggregations. Sales テーブル用に定義されたテーブル行数のカウントの集計があるため、次のクエリでは集計がヒットします。The following query hits the aggregation because there is a Count table rows aggregation defined for the Sales table.

クエリの例

AVERAGE 関数は集計を利用できます。The AVERAGE function can benefit from aggregations. AVERAGE が COUNT で除算される SUM に内部的に折りたたまれるため、次のクエリでは集計がヒットします。The following query hits the aggregation because AVERAGE internally gets folded to a SUM divided by a COUNT. UnitPrice 列には SUM と COUNT の両方に対して定義された集計があるため、集計がヒットします。Since the UnitPrice column has aggregations defined for both SUM and COUNT, the aggregation is hit.

クエリの例

場合によっては、DISTINCTCOUNT 関数は集計を利用できます。In some cases, the DISTINCTCOUNT function can benefit from aggregations. 集計テーブルで CustomerKey の差異を維持する CustomerKey 用の GroupBy エントリがあるため、次のクエリでは集計がヒットします。The following query hits the aggregation because there is a GroupBy entry for CustomerKey, which maintains the distinctness of CustomerKey in the aggregation table. この手法も、約 200 万から 500 万を超える個別値がクエリのパフォーマンスに影響する可能性があるパフォーマンスしきい値の対象となります。This technique is still subject to the performance threshold where over approximately two to five million distinct values can affect query performance. ただしこれは、詳細テーブル内に何十億もの行があり、列内に 200 万から 500 万の個別値があるようなシナリオで役に立ちます。However, it can be useful in scenarios where there are billions of rows in the detail table and two to five million distinct values in the column. このケースでは、何十億もの行を含むテーブルをスキャンするよりも、たとえテーブルがメモリ内にキャッシュされている場合でも、個別のカウントの方が速く実行できます。In this case, the distinct count can perform faster than scanning the table with billions of rows, even if it were cached into memory.

クエリの例

RLSRLS

行レベル セキュリティ (RLS) 式を正常に動作させるには、集計テーブルと詳細テーブルの両方をフィルター処理する必要があります。Row level security (RLS) expressions should filter both the aggregation table and the detail table to work correctly. 例を見ると、Geography テーブルの RLS 式が機能します。これは、Sales テーブルと Sales Agg テーブルの両方に対し、Geography はリレーションシップをフィルタリングする側にあるからです。Following the example, an RLS expression on the Geography table will work because Geography is on the filtering side of relationships to both the Sales table and the Sales Agg table. 集計テーブルでヒットするクエリとヒットしないクエリに RLS が正常に適用されます。Queries that hit the aggregation table and those that do not will have RLS successfully applied.

集計管理ロール

Product テーブルの RLS 式は、Sales Agg テーブルをフィルタリングせず、Sales テーブルのみをフィルタリングします。An RLS expresson on the Product table would filter only the Sales table, not the Sales Agg table. これは推奨されません。This is not recommended. このロールを使用してデータセットにアクセスするユーザーによって送信されたクエリは、集計ヒットの恩恵を受けません。Queries submitted by users who access the dataset using this role would not benefit from aggregation hits. 集計テーブルは詳細テーブルで同じデータを別の方法で表現したものであり、RLS フィルターを適用できないため、集計テーブルからクエリに応答するのは安全ではありません。Since the aggregation table is another representation of the same data in the detail table, it would be insecure to answer queries from the aggregation table because the RLS filter cannot be applied.

SalesAgg テーブル自体の RLS 式では、詳細テーブルがフィルタリングされず、集計テーブルだけがフィルタリングされます。An RLS expression on the Sales Agg table itself would filter only the aggregation table and not the detail table. これは許可されていません。This is disallowed.

集計管理ロール

グループ化列に基づく集計Aggregations based on group-by columns

Hadoop ベースのビッグ データ モデルには、ディメンション モデルとは異なる特性があります。Hadoop-based big data models have different characteristics than dimensional models. 大規模なテーブル間の結合を避けるため、多くの場合これらはリレーションシップに依存しません。To avoid joins between large tables, they often don't rely on relationships. 代わりに、ディメンション属性がファクト テーブルに非正規化されることがよくあります。Instead, dimension attributes are often denormalized to fact tables. このようなビッグ データ モデルは、グループ化列に基づく集計を使用して、対話型の分析のためにロックを解除することができます。Such big data models can be unlocked for interactive analysis using aggregations based on group-by columns.

次のテーブルには、集計対象の Movement の数値列が含まれています。The following table contains the Movement numeric column to be aggregated. その他のすべての列は、グループ化への属性です。All other columns are attributes to group by. このテーブルには、IoT データと多数の行が含まれています。It contains IoT data and a massive number of rows. ストレージ モードは、DirectQuery です。The storage mode is DirectQuery. データセット全体を集計するデータ ソースに対するクエリは、その膨大な量により低速になります。Queries on the data source that aggregate across the whole dataset are slow because of the sheer volume.

IoT テーブル

このデータセットで対話型の分析を有効にするため、経度と緯度などの高いカーディナリティ属性を除くほとんどの属性をグループ化する集計テーブルを追加します。To enable interactive analysis on this dataset, we add an aggregation table that groups by most of the attributes but excludes the high cardinality attributes like longitude and latitude. これにより行数が大幅に削減され、メモリ内キャッシュに余裕で収まるサイズに縮小されます。This dramatically reduces the number of rows, and is small enough to comfortably fit into an in-memory cache. Driver Activity Agg のストレージ モードはインポートです。The storage mode of Driver Activity Agg is Import.

Driver Activity Agg テーブル

次に、 [集計の管理] ダイアログで、集計マッピングを定義します。Next, we define the aggregation mappings in the Manage aggregations dialog. このダイアログには、Driver Activity Agg テーブル内の各列の 1 行が表示され、ここで集計動作を指定できます。It displays a row for each column in the Driver Activity Agg table, where we can specify the aggregation behavior.

Driver Activity Agg テーブルの [集計の管理] ダイアログ

次のテーブルは、Driver Activity Agg テーブルの集計を示しています。The following table shows the aggregations for the Driver Activity Agg table.

Driver Activity Agg 集計テーブル

グループ化列Group by columns

この例では、GroupBy エントリは省略できません。これがないと、集計がヒットしません。In this example, the GroupBy entries are not optional; without them the aggregations wouldn't get hit. これは、この記事で前述したディメンション モデルの例で説明した、リレーションシップに基づいて集計を使用するのとは異なる動作です。This is different behavior to using aggregations based on relationships, which is covered by the dimensional model example provided previously in this article.

クエリ例Query examples

Activity Date 列が集計テーブルの対象に含まれているため、次のクエリでは集計がヒットします。The following query hits the aggregation because the Activity Date column is covered by the aggregation table. テーブル行数のカウントの集計は、COUNTROWS 関数によって使用されます。The Count table rows aggregation is used by the COUNTROWS function.

クエリの例

ファクト テーブルにフィルター属性が含まれているモデルには特に、テーブル行数のカウントの集計を使用することをお勧めします。Especially for models that contain filter attributes in fact tables, it's a good idea to use Count table rows aggregations. Power BI では、ユーザーによって明示的に要求されていない場合に、COUNTROWS を使用してデータセットにクエリを送信することができます。Power BI may submit queries to the dataset using COUNTROWS in cases where it is not explicitly requested by the user. たとえば、[フィルター] ダイアログには、各値の行数が表示されます。For example, the filter dialog shows the count of rows for each value.

[フィルター] ダイアログ

RLSRLS

RLS 式で集計テーブル、詳細テーブル、または両方をフィルタリングできるかどうかに関する、リレーションシップに基づく集計のための上述の同じ RLS ルールは、group by 列に基づく集計にも適用されます。The same RLS rules detailed above for aggregations based on relationships, regarding whether an RLS expression can filter the aggregation table, detail table or both, also apply to aggregations based on group by columns. この例では、集計テーブルのすべての group by 列が詳細テーブルで網羅されているため、Driver Activity テーブルに適用されている RLS 式を利用し、Driver Activity Agg テーブルをフィルタリングできます。In the example, an RLS expression applied to the Driver Activity table can be used to filter the Driver Activity Agg table because all the group by columns in the aggregation table are covered by the detail table. 一方、Driver Activity Agg テーブルの RLS フィルターは、Driver Activity テーブルに適用できず、許可されません。An RLS filter on the Driver Activity Agg table on the other hand cannot be applied to the Driver Activity table so is disallowed.

集計の優先順位Aggregation precedence

集計の優先順位により、1 つのサブクエリで複数の集計テーブルを対象にすることができます。Aggregation precedence allows multiple aggregation tables to be considered by a single subquery.

次の例を考えてみましょう。Consider the following example. これは、複数の DirectQuery ソースが含まれている複合モデルです。It's a composite model containing multiple DirectQuery sources.

  • Driver Activity Agg2 インポート テーブルは、group-by 属性が少なくカーディナリティが低いため、粒度が高くなっています。The Driver Activity Agg2 Import table is at a high granularity because the group-by attributes are few and low cardinality. 行数は、メモリ内キャッシュに余裕で収まるように、数千程度に抑えることができます。The number of rows could be as low as thousands, so it can easily fit into an in-memory cache. これらの属性は、幹部のダッシュボードで使用されることがあるため、それらを参照するクエリはできるだけ高速にする必要があります。These attributes happen to be used by a high-profile executive dashboard, so queries referring to them should be as fast as possible.
  • Driver Activity Agg テーブルは、DirectQuery モードの中間の集計テーブルです。The Driver Activity Agg table is an intermediate aggregation table in DirectQuery mode. Azure SQL DW の 10 億を超える行を含み、列ストア インデックスを使用してソースで最適化されます。It contains over a billion rows in Azure SQL DW and is optimized at the source using columnstore indexes.
  • Driver Activity テーブルは DirectQuery で、ビッグ データ システムをソースとする IoT データの数兆を超える行が含まれています。The Driver Activity table is DirectQuery and contains over a trillion rows of IoT data sourced from a big-data system. これは、制御されたフィルター コンテキストで IoT の個別の読み取りを表示するドリルスルー クエリを提供します。It serves drillthrough queries to view individual IoT readings in controlled filter contexts.

注意

詳細テーブルと異なるデータ ソースを使用する DirectQuery 集計テーブルは、集計テーブルが SQL Server、Azure SQL または Azure SQL DW ソースからのものである場合にのみサポートされます。DirectQuery aggregation tables that use a different data source to the detail table are only supported if the aggregation table is from a SQL Server, Azure SQL or Azure SQL DW source.

このモデルのメモリ占有領域は比較的小さいものの、大きなデータセットのロックを解除します。The memory footprint of this model is relatively small, but it unlocks a huge dataset. これはクエリの負荷を、それを使用するアーキテクチャのコンポーネントの長所に基づいて分散するため、分散アーキテクチャを表します。It represents a balanced architecture because it spreads the query load across components of the architecture utilizing them based on their strengths.

大きなデータセットをロック解除するメモリ占有領域の小さいモデルのテーブル

Driver Activity Agg2[集計の管理] ダイアログの [優先順位] フィールドには、Driver Activity Agg よりも高い 10 が示されています。これは、集計を使用するクエリで最初に考慮されることを意味します。The Manage aggregations dialog for Driver Activity Agg2 shows the Precedence field is 10, which is higher than that of Driver Activity Agg, which means it will be considered first by queries using aggregations. Driver Activity Agg2 で対応できる粒度ではないサブクエリでは、代わりに Driver Activity Agg が考慮されます。Subqueries that are not at the granularity that can be answered by Driver Activity Agg2 will consider Driver Activity Agg instead. いずれの集計テーブルでも対応できない詳細クエリは、Driver Activity に向けられます。Detail queries that cannot be answered by either aggregation table will be directed to Driver Activity.

チェーン集計が許可されていないため (この記事で前述した「検証」を参照)、 [詳細テーブル] 列には、Driver Activity Agg ではなく Driver Activity テーブルが指定されています。The table specified in the Detail Table column is Driver Activity, not Driver Activity Agg because chained aggregations are not allowed (see validations earlier in this article).

[集計の管理] ダイアログ

次のテーブルは、Driver Activity Agg2 テーブルの集計を示しています。The following table shows the aggregations for the Driver Activity Agg2 table.

Driver Activity Agg2 集計テーブル

リレーションシップと結合したグループ化列に基づく集計Aggregations based on group-by columns combined with relationships

この記事で既に説明したように、集計の 2 つの手法を組み合わせることもできます。You can even combine the two techniques for aggregations described earlier in this article. リレーションシップに基づく集計では、非正規化されたディメンション テーブルを複数のテーブルに分割する必要がある場合があります。Aggregations based on relationships may require the denormalized dimension tables be split into multiple tables. これがコストがかかる場合または特定のディメンション テーブルでは実行が難しい場合は、他に使用されている特定のディメンションとリレーションシップのために集計テーブル内で必要な属性をレプリケートすることができます。If this is costly or impractical for certain dimension tables, the necessary attributes can be replicated in the aggregation table for certain dimension(s) and relationships used for others.

次のモデルでは、Sales Agg テーブル内の Month (月)、Quarter (四半期)、Semester (半期)、Year (年) をレプリケートします。The following model replicates Month, Quarter, Semester, and Year in the Sales Agg table. Sales Agg テーブルと Date テーブル間にはリレーションシップはありません。There is no relationship between Sales Agg and the Date table. CustomerProduct Subcategory へのリレーションシップはあります。There are relationships to Customer and Product Subcategory. Sales Agg のストレージ モードはインポートです。The storage mode of Sales Agg is Import.

集計方法を組み合わせる

次のテーブルは、Sales Agg テーブルの [集計の管理] ダイアログ内のエントリ セットを示しています。The following table shows the entries set in the Manage aggregations dialog for the Sales Agg table. Date が詳細テーブルの GroupBy エントリは、Date 属性でグループ化するクエリで集計をヒットするために必須です。The GroupBy entries where Date is the detail table are mandatory to hit aggregations for queries that group by the Date attributes. 前の例と同じく、リレーションシップが存在するため、CustomerKey と ProductSubcategoryKey の GroupBy エントリは集計のヒットには影響しません (これも DISTINCTCOUNT の例外によるものです)。As in the previous example, the GroupBy entries for CustomerKey and ProductSubcategoryKey do not affect aggregation hits because of the presence of relationships (again with the exception of DISTINCTCOUNT).

Sales Agg 集計テーブル

クエリ例Query examples

次のクエリでは、CalendarMonth が集計テーブルでカバーされ、CategoryName は一対多のリレーションシップを使用してアクセスできるため、集計がヒットします。The following query hits the aggregation because CalendarMonth is covered by the aggregation table, and CategoryName is accessible via one-to-many relationships. SalesAmount には、Sum 集計が使用されています。The Sum aggregation for SalesAmount is used.

クエリの例

CalendarDay が集計テーブルの対象に含まれていないため、次のクエリでは集計がヒットしません。The following query doesn't hit the aggregation because CalendarDay is not covered by the aggregation table.

クエリの例

次のタイム インテリジェンス クエリでは、集計がヒットしません。これは、DATESYTD 関数によって集計テーブルではカバーされない CalendarDay 値のテーブルが生成されるためです。The following time-intelligence query will not hit the aggregation because the DATESYTD function generates a table of CalendarDay values, which is not covered by the aggregation table.

クエリの例

キャッシュの同期状態を保つCaches should be kept in sync

DirectQuery とインポートおよびデュアルのいずれかまたは両方のストレージ モードを組み合わせる集計では、メモリ内キャッシュとソース データとの同期が保持されない場合、異なるデータが返される場合があります。Aggregations that combine DirectQuery and Import and/or Dual storage mode may return different data if the in-memory cache is not kept in sync with the source data. クエリを実行しても、たとえばキャッシュされた値と一致するように DirectQuery の結果をフィルター処理するなどして、データに関する問題に対処することはありません。Query execution won't attempt to mask data issues by, for example, filtering DirectQuery results to match cached values. これらの機能は、パフォーマンスの最適化で、ビジネス要件に対応する能力を損なわない方法でのみ使用する必要があります。These features are performance optimizations and should be used only in ways that do not compromise your ability to meet business requirements. お客様がご自身のデータ フローを把握し、それに応じて設計してください。It's your responsibility to know your data flows, so please design accordingly. 必要に応じて、ソースでそのような問題を処理する手法が確立されています。There are established techniques to handle such issues at the source, if necessary.

次の手順Next steps

以下の記事では、複合モデルと DirectQuery について詳しく説明しています。The following articles describe more about composite models, and also describe DirectQuery in detail.

DirectQuery に関する記事:DirectQuery articles: