Power BI で DirectQuery を使用するUsing DirectQuery in Power BI

Power BI Desktop または Power BI サービスを使用すると、あらゆる種類のデータ ソースに、さまざまな方法で接続できます。You can connect to all sorts of different data sources when using Power BI Desktop or the Power BI service, and you can make those data connections in different ways. Power BI へのデータの "インポート" は、最もよく使われるデータ取得方法です。または、元のソース リポジトリ内のデータに直接接続することもでき、これは DirectQuery と呼ばれます。You can either import data to Power BI, which is the most common way to get data, or you can connect directly to data in its original source repository, which is known as DirectQuery. この記事では DirectQuery とその機能について説明します。内容は次のとおりです。This article describes DirectQuery and its capabilities, including the following topics:

  • DirectQuery のさまざまな接続オプションDifferent connectivity options for DirectQuery
  • インポートではなく DirectQuery の使用を検討する必要があるときのためのガイダンスGuidance for when you should consider using DirectQuery rather than import
  • DirectQuery を使用する欠点Drawbacks of using DirectQuery
  • DirectQuery を使用する場合のベスト プラクティスBest practice for using DirectQuery

インポートと DirectQuery を使用する場合のベスト プラクティスを比較すると次のようになります。In short, the best practice for using import versus DirectQuery is the following:

  • 可能な場合は常に、Power BI にデータをインポートする必要があります。You should import data to Power BI wherever possible. この方法は、Power BI の高パフォーマンス クエリ エンジンを活用し、データに対する高い対話性とあらゆる機能を備えたエクスペリエンスを提供します。This takes advantage of the high performance query engine of Power BI, and provides a highly interactive and fully featured experience over your data.
  • データのインポートでは目的を達成できない場合にのみ、DirectQuery の使用を検討します。If your goals can't be met by importing data, then consider using DirectQuery. たとえば、頻繁に変更されるデータの最新の状態をレポートに反映する必要がある場合は、DirectQuery が最適である可能性があります。For example, if the data is changing frequently and reports must reflect the latest data, DirectQuery may be best. ただし、一般に、DirectQuery を使うのが適しているのは、基になるデータ ソースが一般的な集計クエリに対する対話型クエリを (5 秒未満で) 提供でき、生成されるクエリの負荷を処理できる場合のみです。However, using DirectQuery is generally only be feasible when the underlying data source can provide interactive queries (less than 5 seconds) for the typical aggregate query, and is able to handle the query load that will be generated. さらに、DirectQuery の使用に付随する制限事項の一覧を慎重に検討し、それでも目的を達成できることを確認する必要があります。Additionally, the list of limitations that accompany use of DirectQuery should be considered carefully, to ensure your goals can still be met.

インポートと DirectQuery の両方の接続モードに対して Power BI が提供する機能のセットは、今後も徐々に拡充されます。The set of capabilities offered by Power BI for both connectivity modes – import and DirectQuery - will evolve over time. これには、インポートしたデータを使用するときの柔軟性の向上 (インポートを使用できるケースの増加など) や、DirectQuery を使用するときのいくつかの欠点の除去などが含まれます。This will include providing more flexibility when using imported data, such that import can be used in more cases, as well as eliminating some of the drawbacks of using DirectQuery. 機能強化に関係なく、DirectQuery を使うときは、基になるデータ ソースのパフォーマンスが常に大きな考慮事項になります。Regardless of improvements, when using DirectQuery the performance of the underlying data source will always remain a major consideration. 基になるデータ ソースが遅い場合、そのソースで DirectQuery を使うことはできません。If that underlying data source is slow, then using DirectQuery for that source it will remain unfeasible.

このトピックでは、Power BI での DirectQuery の使用について説明します。SQL Server Analysis Services については説明しません。This topic covers DirectQuery with Power BI, and not SQL Server Analysis Services. DirectQuery は SQL Server Analysis Services の機能でもあり、ここで説明する詳細の多くは SQL Server Analysis Services にも当てはまりますが、重要な相違点もあります。DirectQuery is also a feature of SQL Server Analysis Services, and many of the details described below apply to its use, there are also important differences. SQL Server Analysis Services での DirectQuery の使用については、SQL Server Analysis Services 2016 での DirectQuery の詳細に関するホワイトペーパーをご覧ください。For information about using DirectQuery with SQL Server Analysis Services, see the whitepaper that details DirectQuery in SQL Server Analysis Services 2016.

この記事で注目する DirectQuery の推奨されるワークフローではレポートを Power BI Desktop で作成しますが、Power BI サービスでの直接接続についても説明します。This article focuses on the recommended workflow for DirectQuery, where the report is created in Power BI Desktop, but also covers connecting directly in the Power BI service.

Power BI の接続モードPower BI connectivity modes

Power BI は、次のような非常に多くの多様なデータ ソースに接続します。Power BI connects to a very large number of varied data sources, encompassing:

  • オンライン サービス (Salesforce、Dynamics 365、その他)Online services (Salesforce, Dynamics 365, others)
  • データベース (SQL Server、Access、Amazon Redshift、その他)Databases (SQL Server, Access, Amazon Redshift, others)
  • 単純なファイル (Excel、JSON、その他)Simple files (Excel, JSON, others)
  • その他のデータ ソース (Spark、Web サイト、Microsoft Exchange、その他)Other data sources (Spark, Web sites, Microsoft Exchange, others)

これらのソースについて、通常は Power BI にデータをインポートできます。For these sources, it's usually possible to import the data to Power BI. 一部については、DirectQuery を使って接続することもできます。For some it is also possible to connect using DirectQuery. DirectQuery をサポートしているソースについて詳しくは、「DirectQuery でサポートされるデータ ソース」をご覧ください。The exact set of sources that support DirectQuery is described in the Data Sources supported by DirectQuery article. 今後、主に優れた対話型クエリ パフォーマンスを提供できるソースという観点から、DirectQuery に対応するソースが増えるものと思われます。More sources will be DirectQuery enabled in the future, focusing primarily on sources that can be expected to deliver good interactive query performance.

SQL Server Analysis Services は特殊なケースです。SQL Server Analysis Services is a special case. SQL Server Analysis Services に接続するときは、データのインポートまたは "ライブ接続" の使用を選択できます。When connecting to SQL Server Analysis Services, you can choose to import the data, or use a live connection. ライブ接続は、データがインポートされず、表示を更新するときに基になるデータ ソースが常にクエリされる点は DirectQuery と似ていますが、"ライブ接続" は他の多くの点で異なるため、異なる用語 ("ライブ" と "DirectQuery") が使われています。Using a live connection is similar to DirectQuery, in that no data is imported, and the underlying data source is always queried to refresh a visual, but a live connection is different in many other regards, so a different term (live versus DirectQuery) is used.

以下では、これら 3 つのデータ接続オプション (インポートDirectQueryライブ接続) について詳しく説明します。These three options for connecting to data – import, DirectQuery, and live connection – are explained in detail in the following sections.

インポートの接続Import connections

Power BI Desktop[データの取得] を使用して SQL Server などのデータ ソースに接続し、[インポート] を選択した場合、接続の動作は次のようになります。When using Get Data in Power BI Desktop to connect to a data source like SQL Server, and you choose Import, the behavior of that connection is as follows:

  • 最初の [データの取得] エクスペリエンスの間に、選択した各テーブル セットによってデータ セットを返すクエリが定義されます (データを読み込む前にこれらのクエリを編集し、フィルターの適用、データの集計、異なるテーブルの結合などを行うことができます)。During the initial Get Data experience, the set of tables selected each define a query that will return a set of data (those queries can be edited prior to loading the data, for example to apply filters, or aggregate the data, or join different tables).
  • 読み込みでは、クエリによって定義されているすべてのデータが Power BI のキャッシュにインポートされます。Upon load, all of the data defined by those queries will be imported into the Power BI cache.
  • Power BI Desktop で視覚エフェクトを作成するときに、インポートされたデータのクエリが行われます。Upon building a visual within Power BI Desktop, the imported data will be queried. Power BI ストアにより非常に高速なクエリが行われるため、視覚エフェクトに対する変更はすべてすぐに反映されます。The Power BI store ensures the query will be very fast, hence all changes to the visual will be reflected immediately.
  • 基のデータに対する変更は、どの視覚エフェクトにも反映されません。Any changes to the underlying data will not be reflected in any visuals. データが再インポートされたら直ちに、"更新" を行う必要があります。It is necessary to Refresh, whereupon the data will be re-imported.
  • レポート (.pbix ファイル) を Power BI サービスに発行すると、データセットが作成されて、Power BI サービスにアップロードされます。Upon publishing the report (the .pbix file) to the Power BI service, a dataset is created and uploaded to the Power BI service. インポートされたデータは、そのデータセットに含まれます。The imported data is included with that dataset. その後は、そのデータの更新スケジュールを設定できます (たとえば、毎日データを再インポート)。It is then possible to set up scheduled refresh of that data, for example, to re-import the data every day. 元のデータ ソースの場所によっては、オンプレミス データ ゲートウェイの構成が必要になる場合があります。Depending upon the location of the original data source, it might be necessary to configure an on-premises data gateway.
  • 既存のレポートを Power BI サービスで開くと、または新しいレポートを作成すると、インポートされたデータのクエリが再び行われて、対話性が保証されます。When opening an existing report in the Power BI service, or authoring a new report, the imported data is queried again, ensuring interactivity.
  • 視覚エフェクトまたはレポート ページ全体を、ダッシュボード タイルとしてピン留めできます。Visuals, or entire report pages, can be pinned as dashboard tiles. 基になるデータセットが更新されるたびに、タイルは自動的に更新されます。The tiles will be automatically refreshed whenever the underlying dataset is refreshed.

DirectQuery の接続DirectQuery connections

Power BI Desktop[データの取得] を使用してデータ ソースに接続し、[DirectQuery] を選択した場合、接続の動作は次のようになります。When using Get Data in Power BI Desktop to connect to a data source, and you choose DirectQuery, the behavior of that connection is as follows:

  • 最初の [データの取得] エクスペリエンスの間に、ソースが選択されます。During the initial Get Data experience, the source is selected. リレーショナル ソースの場合、一連のテーブルが選択され、それぞれにおいて論理的にデータ セットを返すクエリが定義されます。For relational sources, this means a set of tables are selected and each still define a query that logically returns a set of data. SAP BW などの多次元ソースでは、ソースのみが選択されます。For multidimensional sources like SAP BW, only the source is selected.
  • ただし、読み込み時には、データは実際には Power BI ストアにインポートされません。However, upon load, no data will actually be imported into the Power BI store. 代わりに、Power BI Desktop での視覚エフェクトの作成時に、クエリが基になるデータ ソースに送信されて、必要なデータが取得されます。Instead, upon building a visual within Power BI Desktop, queries will be sent to the underlying data source to retrieve the necessary data. 視覚エフェクトの更新にかかる時間は、基になるデータ ソースのパフォーマンスによって異なります。The time then taken to refresh the visual will depend on the performance of the underlying data source.
  • 基のデータに対する変更は、既存の視覚エフェクトにすぐには反映されません。Any changes to the underlying data will not be immediately reflected in any existing visuals. 更新を行う必要があります。各視覚エフェクトに必要なクエリが再送信され、必要に応じて視覚エフェクトが更新されます。It is still necessary to Refresh, whereupon the necessary queries will be resent for each visual, and the visual updated as necessary.
  • レポートを Power BI サービスに発行すると、インポートと同じように、Power BI サービスにデータセットが作成されます。Upon publishing the report to the Power BI service, it will again result in a Dataset in the Power BI service, just as for import. ただし、そのデータセットに "データは含まれません"。However, no data is included with that dataset.
  • Power BI サービスで既存のレポートを開くか、新しいレポートを作成すると、基になるデータ ソースのクエリが再び行われて、必要なデータが取得されます。When opening an existing report in the Power BI service, or authoring a new one, the underlying data source is again queried to retrieve the necessary data. インポート モードでのデータ更新と同様に、元のデータ ソースの場所によっては、オンプレミス データ ゲートウェイの構成が必要になる場合があります。Depending upon the location of the original data source, it might be necessary to configure an on-premises data gateway, just as is needed for Import mode if the data is refreshed.
  • 視覚エフェクトまたはレポート ページ全体を、ダッシュボード タイルとしてピン留めできます。Visuals, or entire report pages, can be pinned as Dashboard tiles. ダッシュボードがすばやく開くように、タイルはスケジュール (たとえば、1 時間ごと) に従って自動的に更新されます。To ensure that opening a dashboard will be fast, the tiles are automatically refreshed on a schedule (for example, every hour). この更新頻度は、データの変更頻度や、最新のデータを表示する重要性を反映するように、制御できます。The frequency of this refresh can be controlled, to reflect how frequently the data is changing, and how important it is to see the very latest data. したがって、ダッシュボードを開くと、タイルに反映されるのは最終更新時のデータであり、必ずしも基になるソースに対して行われた最新の変更ではありません。Thus, when opening a dashboard, the tiles will reflect the data as of the time of the last refresh, and not necessarily the very latest changes made to the underlying source. 開かれているダッシュボードは常に更新されて、最新の状態であることが保証されます。An open dashboard can always be Refreshed to ensure it is up-to-date.

ライブ接続Live connections

SQL Server Analysis Services (SSAS) に接続するときは、選択したデータ モデルからデータをインポートするか、またはデータ モデルにライブ接続するかを選択できます。When connecting to SQL Server Analysis Services (SSAS), there is an option to either import data from, or connect live to, the selected data model. インポートを選択する場合は、その外部 SSAS ソースに対するクエリを定義します。データは普通にインポートされます。If you select import, then you define a query against that external SSAS source, and the data is imported as normal. ライブ接続を選択する場合は、クエリを定義しません。外部モデル全体が、フィールド一覧に表示されます。If you select to connect live then there is no query defined, and the entire external model is shown in the field list. DirectQuery を選択すると、視覚エフェクトが作成されるときに、クエリが外部 SSAS ソースに送信されます。If you select DirectQuery, as visuals are built, queries are sent to the external SSAS source. ただし、DirectQuery とは異なり、新しい "モデル" を作成しても意味はありません。つまり、新しい計算列、階層、リレーションシップなどを定義することはできません。However, unlike DirectQuery, there is no sense in which a new model is being created; in other words, it's not possible to define new calculated columns, hierarchies, relationships, and so on. 代わりに、外部の SSAS モデルに直接接続するだけです。Instead you are simply connecting directly to the external SSAS model.

前の段落で説明した状況は、データをインポートするオプションがないことを除けば、次のソースへの接続にも当てはまります。The situation described in the previous paragraph applies to connecting to the following sources as well, except that there is no option to import the data:

  • Power BI データセット (たとえば、新しいレポートを作成するために、前に作成してサービスに発行した Power BI データセットに接続する場合)Power BI datasets (for example, when connecting to a Power BI dataset that has previously been created and published to the service, to author a new report over it)
  • Common Data ServiceCommon Data Services

Power BI サービスに発行するときの SSAS に対するレポートの動作は、次の点で DirectQuery レポートに似ています。The behavior of reports over SSAS, upon publishing to the Power BI service, is similar to DirectQuery reports in the following ways:

  • Power BI サービスで既存のレポートを開くか、新しいレポートを作成すると、基になる SSAS ソースのクエリが実行されます (オンプレミス データ ゲートウェイが必要な場合があります)When opening an existing report in the Power BI service or authoring a new report, the underlying SSAS source is queried (possibly requiring an on-premises data gateway)
  • ダッシュボードのタイルは、スケジュール (1 時間ごとなどの定義されている頻度) に従って自動的に更新されます。Dashboard tiles are automatically refreshed on a schedule (such as every hour, or whatever frequency is defined)

ただし、重要な相違点もあります。たとえば、ライブ接続では、レポートを開いたユーザーの ID が、基になる SSAS に常に渡されます。However, there are also important differences, including that for live connections the identity of the user opening the report will always be passed to the underlying SSAS source.

これらの比較は本題ではないので、これ以降は DirectQuery のみに注目します。With these comparisons out of the way, let's focus solely on DirectQuery for the rest of this article.

DirectQuery が役に立つ状況When is DirectQuery useful?

次の表では、データを元のソースに残しておくのがよいと思われる場合など、DirectQuery による接続が特に役に立つシナリオを説明します。The following table describes scenarios where connecting with DirectQuery could be especially useful, including cases where leaving the data in the original source would be considered beneficial. 指定したシナリオが Power BI で使用できるかどうかについても説明します。The description includes a discussion about whether the specified scenario is available in Power BI.

制限事項Limitation 説明Description
データが頻繁に変更され、ほぼ "リアルタイム" でのレポート作成が必要であるData is changing frequently, and near ‘real-time’ reporting is needed インポートされたデータのモデルでは、更新できるのは多くても 1 時間に 1 回です。Models with Imported data can be refreshed at most once per hour. そのため、データが継続的に変更され、レポートで最新データを表示する必要がある場合は、スケジュールされた更新でのインポートを使うのは単にニーズを満たしていない可能性があります。Hence, if the data is continually changing, and it is necessary for reports to show the latest data, then using Import with scheduled refresh might simply not meet those needs. また、Power BI にデータを直接ストリーミングすることもできますが、この場合はサポートされるデータ量に制限があることに注意してください。Note also that it is also possible to stream data directly into Power BI, though there a limits on the data volumes supported for this case.

一方、DirectQuery を使った場合は、レポートまたはダッシュボードを開くか更新すると、ソースの最新データが常に表示されます。Using DirectQuery, by contrast, means that opening or refreshing a report or dashboard will always show the latest data in the source. さらに、ダッシュボードのタイルはさらに頻繁に更新できます (最高で 15 分ごと)。Additionally, the dashboard tiles can be updated more frequently (as often as every 15 mins).
データが非常に大きいData is very large データが非常に大きい場合、すべてを確実にインポートすることはできません。If the data is very large, then it certainly would not be feasible to import it all. これに対し、DirectQuery を使うと、その都度クエリが行われるので、大量のデータ転送は必要ありません。DirectQuery, by contrast, requires no large transfer of data, as it is queried in place.

ただし、大量のデータでは、基になるソースのクエリのパフォーマンスが遅くなりすぎる可能性もあります (後の「DirectQuery を使用する影響」の説明を参照)。However, large data might also imply that the performance of the queries against that underlying source are too slow (as discussed in Implications of using DirectQuery section, later in this article). もちろん、常に詳細データを完全にインポートする必要があるわけではありません。And of course it is not always necessary to import the full detailed data. 代わりに、インポートの間にデータを事前集計することもできます (クエリ エディターを使うと簡単にできます)。Instead the data can be pre-aggregated during import (and Query Editor makes it easy to do exactly this). 極端な例では、各視覚エフェクトに必要な集計データだけをインポートすることができます。In the extreme it would be possible to import exactly the aggregate data needed for each visual. ですから、大規模なデータには DirectQuery が最も簡単な方法ではありますが、基になるソースが遅すぎる場合は集計データのインポートが解決策になる可能性があることに常に留意する必要があります。So while DirectQuery is the simplest approach to large data, you should always keep in mind that importing aggregate data might offer a solution if the underlying source is too slow.
基になるソースでセキュリティ規則が定義されているSecurity rules are defined in the underlying source データをインポートするとき、Power BI は、現在のユーザーの資格情報 (Power BI Desktop から)、または更新スケジュールの構成の一部として定義される資格情報 (Power BI サービスから) を使って、データ ソースに接続します。When the data is imported, Power BI will connect to the data source using the current users credentials (from Power BI Desktop), or the credentials defined as part of configuring scheduled refresh (from the Power BI service). したがって、そのようなレポートを発行および共有するときは、同じデータの表示を許可されているユーザーとだけ共有するか、またはデータセットの一部として行レベル セキュリティを定義することに、注意する必要があります。Thus, in publishing and sharing such a report, care must be taken to only share with users allowed to see the same data, or to define Row Level Security as part of the dataset.

DirectQuery は基になるソースを常にクエリするので、理想的には、このようにするとその基になるソースにおけるセキュリティを適用できます。Ideally, because DirectQuery always queries the underlying source, this would allow any security in that underlying source to be applied. ただし、現在の Power BI は、インポートの場合と同じ資格情報を使って、基になるソースに常に接続します。However, today Power BI will always connect to the underlying source using the same credentials as would be used for Import.

したがって、Power BI がレポート ユーザーの ID を使って基になるソースにパススルーできるようになるまでは、データ ソースのセキュリティに関して DirectQuery に利点はありません。Thus, until Power BI allows for the identity of the report consumer to pass through to the underlying source, DirectQuery offers no advantages with regard to data source security.
データ主権の制限が適用されるData sovereignty restrictions apply 組織によっては、データ主権に関するポリシーが設けられている場合あります。つまり、データを組織外に持ち出すことができません。Some organizations have policies around data sovereignty, meaning that data cannot leave the organization premises. インポートに基づくソリューションでは、明らかに問題があります。A solution based on import would clearly present issues. これに対し、DirectQuery では、データは基になるソースに残っています。By contrast, with DirectQuery that data remains in the underlying source.

ただし、DirectQuery でも、視覚エフェクト レベルでデータのキャッシュがいくつか Power BI サービスに保持されることに注意する必要があります (タイルのスケジュールされた更新のため)。However, it should be noted that even with DirectQuery, some caches of data at the visual level are retained in the Power BI service (due to scheduled refresh of tiles).
基になるデータ ソースがメジャーを含む OLAP ソースであるUnderlying data source is an OLAP source, containing measures 基になるデータ ソースに "メジャー" が含まれている場合 (SAP HANA や SAP Business Warehouse など)、データをインポートすると他の問題が発生します。If the underlying data source contains *measures *(such as SAP HANA or SAP Business Warehouse) then importing the data brings other issues. つまり、インポートされるデータは、クエリによって定義された特定のレベルで集計されたものです It means that the data imported is at a particular level of aggregation, as defined by the query. (たとえば、Class、Year、City によるメジャー TotalSales など)。For example, measure TotalSales by Class, Year, and City. その場合、視覚エフェクトがさらに高いレベルの集計データ (Year 別の TotalSales など) で作成される場合、集計値をさらに集計することになります。Then if a visual is built asking for data at a higher level aggregate (such as TotalSales by Year) it is further aggregating the aggregate value. これは、加法メジャー (Sum、Min など) の場合は問題ありませんが、非加法メジャー (Average、DistinctCount など) では問題になります。This is fine for additive measures (such as Sum, Min) but it's an issue for non-additive (such as Average, DistinctCount).

ソースから直接 (特定の視覚エフェクトで必要な) 正しい集計データを簡単に取得するには、DirectQuery のように、視覚エフェクトごとにクエリを送信する必要があります。To make it easy to get the correct aggregate data (as needed for the particular visual) directly from the source, it would be necessary to send queries per visual, as in DirectQuery.

SAP Business Warehouse (BW) に接続するときは、DirectQuery を選ぶと、このようなメジャーの処理に対応できます。When connecting to SAP Business Warehouse (BW), choosing DirectQuery allows for this treatment of measures. SAP BW のサポートについて詳しくは、「DirectQuery と SAP BW」をご覧ください。Support for SAP BW is covered further in DirectQuery and SAP BW.

ただし、現在は、SAP HANA に対する DirectQuery ではリレーショナル ソースと同じように扱われるので、インポートと同様の動作になります。However, currently DirectQuery over SAP HANA treats it the same as a relational source, and hence provides similar behavior to import. 詳しくは、「DirectQuery と SAP HANA」をご覧ください。This is covered further in DirectQuery and SAP HANA.

まとめると、Power BI における DirectQuery の現在の機能では、メリットのあるシナリオは次のようになります。So in summary, given the current capabilities of DirectQuery in Power BI, the scenarios where it offers benefits are the following:

  • データが頻繁に変更され、ほぼ "リアルタイム" でのレポート作成が必要であるData is changing frequently, and near ‘real-time’ reporting is needed
  • 事前集計の必要がない、非常に大きなデータを処理するHandling very large data, without the need to pre-aggregate
  • データ主権の制限が適用されるData sovereignty restrictions apply
  • ソースがメジャーを含む多次元ソースである (SAP BW など)The source is a multi dimensional source containing measures (such as SAP BW)

上記の一覧の詳細は Power BI の使用にのみ関連することに注意してください。Note that the details in the previous list relate to the use of Power BI alone. 常に、代わりに外部の SQL Server Analysis Services (または Azure Analysis Services) モデルを使ってデータをインポートし、Power BI を使ってそのモデルに接続することもできます。There is always the option of instead using an external SQL Server Analysis Services (or Azure Analysis Services) model to import data, and then using Power BI to connect to that model. この方法では追加のスキルが必要になりますが、柔軟性は大きくなります。While that approach would require additional skills, it does provide greater flexibility. たとえば、はるかに大量のデータをインポートすることができ、データを更新する頻度に制限はありません。For example, much larger volumes of data can be imported, and there is no restriction on how frequently the data can be refreshed.

DirectQuery を使用する影響Implications of using DirectQuery

DirectQuery を使うと、ここで詳しく説明するような悪影響が発生する可能性があります。Use of DirectQuery does have potentially negative implications, as detailed in this section. これらの制限の一部は、使われているソースにより若干異なります。Some of those limitations are slightly different depending upon the exact source that is being used. 該当する場合は明記されており、大幅に異なるソースについては別のトピックで説明されています。This will be called out where applicable, and separate topics cover those sources that are substantially different.

基になるソースでのパフォーマンスと負荷Performance and load on the underlying source

DirectQuery を使う場合、全体的なエクスペリエンスは基になるデータ ソースのパフォーマンスに大きく依存します。When using DirectQuery, the overall experience depends very much on the performance of the underlying data source. 各視覚エフェクトの更新 (たとえば、スライサーの値を変更した後) に数秒 (5 秒以下) かかる場合、エクスペリエンスとしては妥当かもしれませんが、Power BI にデータをインポートするときの即時応答と比較すると、遅く感じられる可能性があります。If refreshing each visual (for example, after changing a slicer value) takes a few seconds (<5s) then the experience would be reasonable, yet might still feel sluggish compared to the immediate response we are used to when importing the data to Power BI. ソースの遅さにより個別の視覚エフェクトにそれより長くかかる場合 (数十秒)、エクスペリエンスは非常に悪くなり、クエリがタイムアウトする可能性もあります。If instead the slowness of the source means that individual visuals take longer than that (tens of seconds), then the experience becomes extremely poor, possibly even to the point of queries timing out.

基になるソースのパフォーマンスと共に、ソースに対する負荷にも注意を払う必要があります (もちろん、多くの場合、パフォーマンスに影響します)。Along with the performance of the underlying source, careful consideration should be paid to the load that will be placed upon it (that of course then often impacts the performance). 以下でさらに説明するように、共有レポートを開く各ユーザーおよび定期的に更新される各ダッシュボード タイルは、視覚エフェクトごとに少なくとも 1 つのクエリを基になるソースに送信します。As discussed further below, each user that opens a shared report, and each dashboard tile that is periodically refreshed, will be sending at least one query per visual to the underlying source. このため、ソースはこのようなクエリ負荷を処理しながら、適切なパフォーマンスを維持できることが必要です。This fact requires that the source be able to handle such a query load, while still maintaining reasonable performance.

1 つのソースへの制限Limited to a single source

データをインポートするときは、複数のソースのデータを 1 つのモデルに結合できます。たとえば、社内の SQL Server データベースからのデータと Excel ファイルで保持されているローカル データを、簡単に結合することができます。When importing data, it is possible to combine data from multiple sources into a single model, for example, to easily join some data from a corporate SQL Server database with some local data maintained in an Excel file. DirectQuery を使うとこのようなことはできません。This is not possible when using DirectQuery. ソースに対して DirectQuery を選択すると、その 1 つのソース (単一の SQL Server データベースなど) からのデータしか使うことができません。When selecting DirectQuery for a source, it will then only be possible to use data from that single source (such as a single SQL Server database).

データ変換の制限Limited data transformations

同様に、クエリ エディターで適用できるデータ変換にも制限があります。Similarly, there are limitations in the data transformations that can be applied within Query Editor. インポートしたデータの場合は、高度な変換のセットを簡単に適用して、データをクリーンアップおよび再形成してから、視覚エフェクトを作成できます (JSON ドキュメントの解析や、列指向形式から行指向形式へのデータのピボットなど)。With imported data, a sophisticated set of transformations can easily be applied to clean and re-shape the data before using it to create visuals (such as parsing JSON documents, or pivoting data from a column to a row orientated form). これらの変換は DirectQuery では大きく制限されます。Those transformations are more limited in DirectQuery. 最初に、SAP Business Warehouse などの OLAP ソースに接続するときに、変換をまったく定義できず、外部の "モデル" がそのままソースから取得されます。First, when connecting to an OLAP source like SAP Business Warehouse, no transformations can be defined at all, and the entire external ‘model’ is taken from the source. SQL Server のようなリレーショナル ソースの場合は、クエリごとに変換のセットを定義できますが、パフォーマンス上の理由からその変換も制限されます。For relational sources like SQL Server, it is still possible to define a set of transformations per query, but those transformations are limited, for performance reasons. そのような変換は、データ更新時に 1 回ではなく、基になるソースに対するすべてのクエリで適用する必要があるため、1 つのネイティブ クエリに無理なく組み込むことができる変換に制限されます。Any such transformation will need to be applied on every query to the underlying source, rather than once on data refresh, so they are limited to those transformations that can reasonably be translated into a single native query. 複雑すぎる変換を使うと、エラーが発生し、変換を削除するか、モデルをインポート モードに切り替える必要があります。If you use a transformation that is too complex, then you will receive an error that either it must be deleted, or the model switched to Import mode.

さらに、[データの取得] ダイアログまたはクエリ エディターで作成したクエリが、視覚エフェクトに必要なデータを取得するために生成されて送信されるクエリ内のサブセレクトで使われます。Additionally, the query that results from the Get Data dialog or Query Editor will be used in a subselect within the queries generated and sent to retrieve the necessary data for a visual. したがって、このようなコンテキストで有効なクエリをクエリ エディターで定義する必要があります。Thus the query defined in Query Editor must be valid within this context. 具体的には、共通テーブル式を使うクエリや、ストアド プロシージャを呼び出すクエリを使うことはできません。In particular this means it is not possible to use a query using Common Table Expressions, nor that invokes Stored Procedures.

モデリングの制限事項Modelling limitations

このコンテキストでの "モデリング" という用語は、レポート作成の一環としての生データの調整や補強を意味します。The term modelling in this context means the act of refining and enriching the raw data, as part of authoring a report using it. 次のようなものです。Examples include:

  • テーブル間のリレーションシップの定義Defining relationships between tables
  • 新しい計算の追加 (計算列とメジャー)Adding new calculations (calculated columns and measures)
  • 列やメジャーの名前変更や非表示Renaming and hiding columns and measures
  • 階層の定義Defining hierarchies
  • 列の書式、既定の概要作成、並べ替え順序の定義Defining the formatting, default summarization and sort order for a column
  • 値のグループ化またはクラスタリングGrouping or clustering values

DirectQuery を使うと、これらのモデル強化の多くを行うことができ、後での使用の改善に関しては確かに生データが強化される原則があります。When using DirectQuery, many of these model enrichments can still be made, and certainly there is still the principle that the raw data is being enriched, so as to improve later consumption. ただし、DirectQuery では、いくつかのモデリング機能は使用できないか、制限されます。However, there some modeling capabilities are not available, or are limited, when using DirectQuery. 制限事項は、一般にパフォーマンスの問題を回避するために適用されます。The limitations are generally applied to avoid performance issues. すべての DirectQuery ソースに共通する制限を次にまとめて示します。The set of limitations that are common to all DirectQuery sources are listed in the following bulleted list. 後の "データ ソース固有の詳細" で説明するように、個別のソースについて追加の制限が適用される可能性があります。Additional limitations might apply to individual sources, as described in Data source specific details found near the end of this article.

  • 組み込みの日付階層がない: データをインポートするときは、すべての日付/日時列で組み込みの日付階層を既定で使用できます。No Built in-date hierarchy: When importing data, then by default every date/datetime column will also have a built-in date hierarchy available by default. たとえば、OrderDate 列を含む受注テーブルをインポートし、視覚エフェクトで OrderDate を使用する場合、適切なレベル (Year、Month、Day) を選択して使用できます。For example, if importing a table of sales orders including a column OrderDate, then upon using OrderDate in a visual, it will be possible to choose the appropriate level (Year, Month, Day) to use. DirectQuery モードではこの組み込み日付階層を使用できません。This built-in date hierarchy is not available when using DirectQuery mode. ただし、基になるソースに利用可能な日付テーブルがある場合は (多くのデータ ウェアハウスで一般的)、DAX タイム インテリジェンス関数を通常どおり使用できることに注意してください。Note however that if there is Date table available in the underlying source (as is common in many data warehouses) then the DAX Time Intelligence functions can be used as normal.
  • 計算列での制限事項: 計算列は集計関数を使用しない行内に制限されます。たとえば、同じテーブルの他の列の値だけを参照できます。Limitations in calculated columns: Calculated columns are limited to being intra-row, as in, they can only refer to values of other columns of the same table, without the use of any aggregate functions. さらに、許可される DAX スカラー関数 (LEFT() など) は基になるソースに単純にプッシュできるものに制限され、したがってソースの正確な機能によって異なります。Additionally, the DAX scalar functions (such as LEFT()) that are allowed will be limited to those which can simply be pushed to the underlying source, hence will vary depending upon the exact capabilities of the source. 計算列の DAX を作成するときはサポートされない関数はオートコンプリートに表示されず、使うとエラーが発生します。Functions that are not supported will not be listed in autocomplete when authoring the DAX for a calculated column, and would result in an error if used.
  • 親子 DAX 関数がサポートされない: DirectQuery モデルでは、一般に親子構造 (アカウントのグラフや従業員の階層など) を処理する DAX PATH() 関数ファミリを使うことはできません。No support for parent-child DAX functions: When in DirectQuery model, it is not possible to use the family of DAX PATH() functions, that generally handle Parent-Child structures (such as chart of accounts, or employee hierarchies).
  • メジャーに対する制限 (既定): 既定では、メジャーで使用できる DAX 関数と式が制限されます。Limitations (by default) for measures: By default, the DAX functions and expressions that can be used in measures is restricted. やはり、オートコンプリートに表示される関数は制限され、無効な関数または式を使うとエラーが発生します。Again, autocomplete will restrict the functions listed, and an error will occur if an invalid function or expression is used. 理由は単に、メジャー自体がパフォーマンスの問題の原因にならないように、既定では簡単なメジャーに制限することです。The reason is simply to ensure that, by default, measures are restricted to simple measures that are unlikely by themselves cause any performance issues. 詳しい知識のあるユーザーなら、[ファイル] > [オプション]、次に [設定] > [オプション] > [DirectQuery] の順に選んでから、オプション [DirectQuery モードで無制限のメジャーを許可する] を選べば、この制限を回避できます。Advanced users can choose to bypass this limitation by selecting File > Options and then Settings > Options > DirectQuery, then selecting the option Allow unrestricted measures in DirectQuery mode. このオプションを選ぶと、メジャーに使用できる DAX 式ならどれでも使用できるようになります。When that option is selected, any DAX expression that is valid for a measure can be used. しかし、ユーザーが注意すべき点として、データのインポート時のパフォーマンスが良好な式の中には、DirectQuery モードでバックエンド ソースにクエリを実行する際に非常に低速になるものがあります。Users must be aware, however, that some expressions that perform well when the data is imported may result in very slow queries to the backend source when in DirectQuery mode.

    • たとえば、既定では次のようになります。For example, by default:

      • 単に売り上げ高を集計するメジャーを作成することができます。It would be possible to author a measure that simply summed the sales amount:

        SalesAmount = SUMX(Web_Sales, [ws_sales_price]* [ws_quantity])
      • すべての Item についてその SalesAmount を平均するメジャーを作成することは "できません"。It would not be possible to author a measure that then averaged that SalesAmount over all of the Items:

        AverageItemSalesAmount = AVERAGEX('Item', [SalesAmount])

      理由は、Item の数が非常に多い場合、このようなメジャーによりパフォーマンスが低下する可能性があるためです。The reason is that such a measure could result in poor performance if there were a very large number of items.

  • 計算テーブルがサポートされない: DirectQuery モードでは、DAX 式を使って計算テーブルを定義する機能はサポートされません。Calculated tables are not supported: The ability to define a calculated table using a DAX expression is not supported in DirectQuery mode.
  • リレーションシップのフィルタリングが一方向に制限される: DirectQuery を使うと、リレーションシップでのクロス フィルターの方向を "両方" に設定することはできません。Relationship filtering is limited to a single direction: When using DirectQuery, it is not possible to set the Cross Filter direction on a relationship to “Both”. たとえば、次の 3 つのテーブルで、各 Customer[Gender] が購入した Product[Category] の数を表示する視覚エフェクトは作成できません。For example, with the three tables below, it would not be possible to build a visual showing each Customer[Gender], and the number of Product[Category] bought by each. このような双方向フィルタリングの使用について詳しくは、このホワイトペーパーをご覧ください (SQL Server Analysis Services のコンテキストでの例が示されていますが、基本的なポイントは Power BI にも同じように当てはまります)。Use of such bi-directional filtering is described in this detailed whitepaper (the paper presents examples in the context of SQL Server Analysis Services, but the fundamental points apply equally to Power BI).

    やはり、制限の理由はパフォーマンスへの影響です。Again, the limitation is imposed due to the performance implications. これの具体的な応用で重要なアプリケーションの 1 つは、レポートの一部として行レベル セキュリティを定義する場合です。一般的なパターンでは、ユーザーとユーザーがアクセスを許可されるエンティティの間には多対多のリレーションシップがあり、これを適用するには双方向のフィルターが必要です。One particularly important application of this is when defining Row Level Security as part of the report, as a common pattern is to have a many-many relationship between the users and the entities they are allowed access to, and use of bi-directional filtering is necessary to enforce this. ただし、DirectQuery モデルでの双方向フィルタリングは、パフォーマンスへの悪影響を考慮して慎重に使う必要があります。However, use of bi-directional filtering for DirectQuery models should be used judiciously, with careful attention paid to any detrimental impact on performance.

  • クラスタリングがない: DirectQuery を使うと、クラスタリング機能を使って自動的にグループを検索することはできません。No Clustering: When using DirectQuery, it is not possible to use the Clustering capability, to automatically find groups

レポート作成の制限事項Reporting limitations

ほとんどすべてのレポート機能は、DirectQuery モデルでもサポートされます。Almost all reporting capabilities are supported for DirectQuery models. そのため、基になるソースが適切なレベルのパフォーマンスを提供する限り、同じ視覚エフェクトのセットを使うことができます。As such, so long as the underlying source offers a suitable level of performance, the same set of visualizations can be used. ただし、以下で説明するように、レポートを発行した後に Power BI サービスで提供される他の機能の一部には重要な制限があります。However, there are some important limitations in some of the other capabilities offered in the Power BI service after a report is published, as described in the following bullets:

  • クイック分析情報がサポートされない: Power BI のクイック分析情報は、興味がある可能性のある情報を検出するために一連の高度なアルゴリズムを適用しながら、データセットのさまざまなサブセットを検索します。Quick Insights is not supported: Power BI Quick Insights searches different subsets of your dataset while applying a set of sophisticated algorithms to discover potentially-interesting insights. 非常に高いパフォーマンスのクエリを必要とするため、この機能は DirectQuery を使うデータセットでは利用できません。Given the need for very high performance queries, this capability is not available on datasets using DirectQuery.
  • Q&A がサポートされない: Power BI の Q&A を使うと、直感的な自然言語の機能を使ってデータを調査し、チャートやグラフの形式で質問に対する回答を受け取ることができます。Q&A is not supported: Power BI Q&A enables you to explore your data using intuitive, natural language capabilities and receive answers in the form of charts and graphs. ただし、現時点では、DirectQuery を使うデータセットではサポートされていません。However, it is currently not supported on datasets using DirectQuery.
  • Excel で分析を使うとパフォーマンスが低下する可能性がある: データセットで "Excel で分析" 機能を使ってデータを調べることができます。Using Explore in Excel will likely result in poorer performance: It is possible to explore your data by using the “Explore in Excel” capability on a dataset. この機能を使うと、Excel でピボットテーブルとピボットグラフを作成できます。This will allow Pivot Tables and Pivot Charts to be created in Excel. DirectQuery を使うデータセットでもこの機能はサポートされますが、一般にパフォーマンスは Power BI で視覚エフェクトを作成する場合より遅く、したがって Excel の使用が重要なシナリオの場合、DirectQuery の使用を判断する際に考慮する必要があります。While this capability is supported on datasets using DirectQuery, the performance is generally slower than creating visuals in Power BI, and therefore if the use of Excel is important for your scenarios, this should be accounted for in your decision to use DirectQuery.


前に説明したように、DirectQuery を使うレポートでは、Power BI サービスに発行された後、基になるデータ ソースに接続するときに常に同じ固定の資格情報が使われます。As discussed earlier in this article, a report using DirectQuery will always use the same fixed credentials to connect to the underlying data source, after publish to the Power BI service. 繰り返しますが、これは DirectQuery に固有の問題であり、SQL Server Analysis Services へのライブ接続では異なることに注意してください。Again, note this refers specifically to DirectQuery, not to live connections to SQL Server Analysis Services, which is different in this respect. そのため、DirectQuery レポートを発行したら直ちに、使用されるユーザーの資格情報を構成する必要があります。Hence immediately after publish of a DirectQuery report, it is necessary to configure the credentials of the user that will be used. これが完了するまで、Power BI サービスでレポートを開くとエラーになります。Until this is done, opening the report on the Power BI service would result in an error.

ユーザーの資格情報を指定した後は、"レポートを開くユーザーに関係なく" これらの資格情報が使われます。Once the user credentials are provided, then those credentials will be used, irrespective of the user who opens the report. この点に関して、レポートの一部として行レベル セキュリティを定義しない限り、すべてのユーザーに同じデータが表示されるのは、インポートされたデータの場合と同じです。In this regard it is exactly like imported data, in that every user will see the same data, unless Row Level Security has been defined as part of the report. そのため、基になるソースでセキュリティ ルールが定義されている場合、レポートの共有に同じ注意を払う必要があります。Hence the same attention must be paid to sharing the report, if there are any security rules defined in the underlying source.

Power BI サービスでの動作Behavior in the Power BI service

このセクションでは、Power BI サービスでの DirectQuery レポートの動作について説明します。主として、レポートとダッシュボードを共有するユーザーの数、レポートの複雑さ、および行レベル セキュリティがレポートで定義されているかどうかに応じて、バックエンド データ ソースで発生する負荷の大きさを理解することが目的です。This section describes the behavior of a DirectQuery report in the Power BI service, primarily so as to be able to understand the degree of load that will be placed on the back end data source, given the number of users that the report and dashboard will be shared with, the complexity of the report, and whether Row Level Security has been defined in the report.

レポート - 表示、操作、編集Reports – opening, interacting with, editing

レポートを開くと、表示されるページ上のすべての視覚エフェクトが更新されます。When a report is opened, then all the visuals on the currently visible page will refresh. 各視覚エフェクトでは、通常、基になるデータ ソースに対して少なくとも 1 回クエリを実行する必要があります。Each visual will generally require at least one query to the underlying data source. 視覚エフェクトによっては、複数回のクエリが必要になります (たとえば、2 つの異なるファクト テーブルの集計値を表示する場合、複雑なメジャーが含まれる場合、Count Distinct のような非加法メジャーの合計が含まれる場合など)。Some visuals might require more than one query (for example, if it showed aggregate values from two different fact tables, or contained a more complex measure, or contained totals of a non-additive measure like Count Distinct). 新しいページに移動すると、これらの視覚エフェクトは更新され、結果として基になるソースに対して新しい一連のクエリが実行されます。Moving to a new page will result in those visuals being refreshed, resulting in a new set of queries to the underlying source.

レポートでのすべてのユーザー操作により、視覚エフェクトが更新される可能性があります。Every user interaction on the report might result in visuals being refreshed. たとえば、スライサーで別の値が選択されると、影響を受けるすべての視覚エフェクトを更新するために新しいクエリ セットを送信する必要があります。For example, selecting a different value on a slicer will require sending a new set of queries to refresh all of the effected visuals. 視覚エフェクトをクリックして他の視覚エフェクトをクロス強調表示したり、フィルターを変更したりする場合も同様です。The same is true for clicking on a visual to cross-highlight other visuals, or changing a filter.

同様に、新しいレポートを編集しても、パスの各手順でクエリを送信して最終的な目的の視覚エフェクトを生成する必要があります。Similarly of course, editing a new report with require queries to be sent for each step on the path to produce the final desired visual.

結果のキャッシュがいくつかあり、まったく同じ結果が最近取得されている場合は視覚エフェクトがすぐに更新されます。There is some caching of results, so that the refresh of a visual will be instantaneous if the exact same results have recently been obtained. レポートの一部として行レベル セキュリティが定義されている場合、このようなキャッシュはユーザー間で共有されません。Such caches are not shared across users, if there is any Row Level Security defined as part of the report.

ダッシュボードの更新Dashboard Refresh

個々の視覚エフェクトまたはページ全体を、タイルとしてダッシュボードにピン留めできます。Individual visuals, or entire pages, can be pinned to dashboard as tiles. DirectQuery データセットに基づくタイルはスケジュールに従って自動的に更新され、結果としてバックエンド データ ソースにクエリが送信されます。Tiles based on DirectQuery datasets are then refreshed automatically according to a schedule, resulting in queries being sent to the backend data source. 既定では 1 時間ごとに更新されますが、データセットの設定の一部として、毎週から 15 分間隔の範囲で構成することができます。By default, this occurs every hour, but can be configured as part of Dataset settings to be between weekly, and every 15 minutes.

行レベル セキュリティがモデルで定義されていない場合は、各タイルは 1 回で更新され、すべてのユーザーが結果を共有します。If no Row Level Security is defined in the model, this means that each tile would be refreshed once, and the results shared across all users. 行レベル セキュリティが定義されている場合は、大きな相乗効果が発生する可能性があります。つまり、各タイルがユーザーごとに異なるクエリを、基になるソースに送信する必要があります。If Row Level Security is defined, then there can be a large multiplier effect – each tile requires separate queries per user to be sent to the underlying source.

したがって、10 個のタイルを含み、100 人のユーザーによって共有されるダッシュボードが、行レベル セキュリティを設定された DirectQuery を使うデータセットに作成され、15 分ごとに更新するように構成されている場合、15 分ごとに少なくとも 1000 個のクエリがバックエンド ソースに送信されます。Hence a dashboard with ten tiles, shared with 100 users, created on a dataset using DirectQuery with Row Level Security, and configured to refresh every 15 minutes, would result in at least 1000 queries being sent every 15 minutes to the back end source.

そのため、行レベル セキュリティの使用および更新スケジュールの構成については、慎重に検討する必要があります。Hence careful consideration must be paid to the use of Row Level Security, and the configuring of the refresh schedule.


Power BI サービスでは個々のクエリに対して 4 分のタイムアウトが適用され、それより長い時間がかかるクエリは失敗します。A timeout of four minutes is applied to individual queries in the Power BI service, and queries taking longer than that will simply fail. 前に説明したように、DirectQuery は対話形式に近いクエリ パフォーマンスを提供するソースに対して使うことが推奨されるので、この制限は過度に長い実行時間による問題を回避するためのものです。As stressed earlier, it is recommended that DirectQuery be used for sources that provide near interactive query performance, so this limit is intended to prevent issues from overly long execution times.

その他の影響Other implications

DirectQuery の使用に伴うその他の一般的な影響は次のとおりです。Some other general implications of using DirectQuery are the following:

  • データが変更された場合、更新して最新データを表示する必要がある: キャッシュを使っている場合、視覚エフェクトに常に最新データが表示されている保証はありません。If data is changing, it is necessary to Refresh to ensure the latest data is shown: Given the use of caches, there is no guarantee that the visual is always showing the latest data. たとえば、視覚エフェクトに前日のトランザクションが表示されている可能性があります。For example, a visual might show the transactions in the last day. スライサーの変更により、ごく最近の新たに到着したトランザクションを含む過去 2 日間のトランザクションが表示される可能性があります。Then due to a slicer being changed, it might refresh to show the transactions for the last two days, including some very recent, newly arrived transactions. スライサーを元の値に戻すと、以前に取得されたキャッシュの値が再び表示され、新しく到着したトランザクションが含まれなくなることがあります。Returning the slicer to its original value would result in it again showing the cached value previously obtained, that would not include the newly arrived transaction seen before.

    更新を選択すると、すべてのキャッシュがクリアされ、ページ上のすべての視覚エフェクトが更新されて最新のデータが表示されます。Selecting Refresh will clear any caches, and refresh all the visuals on the page to show the latest data.

  • データが変化している場合、視覚エフェクト間の一貫性が保証されない: 異なる視覚エフェクトは、同じページ上でも別のページ上でも、異なるタイミングで更新される可能性があります。If data is changing, there is no guarantee of consistency between visuals: Different visuals, whether on the same page or on different pages, might be refreshed at different times. したがって、基になるソースのデータが変更された場合、各視覚エフェクトにまったく同じ時点のデータが表示される保証はありません。Thus if the data in the underlying source is changing, there is no guarantee that each visual will be showing the data at the exact same point of time. 実際、単一の視覚エフェクトに対して複数のクエリが必要であると (たとえば、詳細情報と合計を取得する場合など)、1 つの視覚エフェクト内であっても整合性は保証されません。Indeed, given that sometimes more than one query is required for a single visual (for example, to obtain the details and the totals) then consistency even within a single visual is not guaranteed. これを保証するには、基になるデータ ソースでのスナップショット分離のようなコストの高い機能の使用と併せて、いずれかの視覚エフェクトが更新されるときは常にすべての視覚エフェクトを更新するオーバーヘッドが必要になります。To guarantee this would require the overhead of refreshing all visuals whenever any visual refreshed, in tandem with the use of costly features like Snapshot Isolation in the underlying data source.

    やはり、更新を選択してページ上のすべての視覚エフェクトを更新することで、この問題を大幅に軽減できます。This issue can be mitigated to a large extent by again selecting Refresh, to will refresh all of the visuals on the page. また、インポート モードを使っている場合でも、複数のテーブルからデータをインポートする場合は、整合性の保証に関する同様の問題があることに注意してください。And it should be noted that even if using Import mode, there is a similar problem of guaranteeing consistency if importing data from more than one table.

  • メタデータの変更を反映するには Power BI Desktop での更新が必要である: レポートを発行した後の更新では、レポートの視覚エフェクトが更新されるだけです。Refresh in Power BI Desktop is needed to reflect any metadata changes: After a report is published, Refresh will simply refresh the visuals in the report. 基になるソースのスキーマに対する変更は、フィールド リストで使用可能なフィールドの変更には自動的に適用されません。If the schema of the underlying source has changed, then those changes are not automatically applied to change the available fields in the field list. したがって、基になるソースからテーブルや列を削除した場合、更新時にクエリが失敗する可能性があります。Thus if tables or columns have been removed from the underlying source, it might result in query failure upon refresh. Power BI Desktop でレポートを開き、[更新] を選択すると、モデルのフィールドが更新されて変更が反映されます。Opening the report in Power BI Desktop, and choosing Refresh, will update the fields in the model to reflect the changes.
  • クエリで返される行が 100 万行に制限される: 基になるソースに対する 1 回のクエリで返される行の数には、100 万行という固定の制限があります。Limit of one million rows returned on any query: There is a fixed limit of one million rows placed on the number of rows that can be returned in any single query to the underlying source. 一般に、これによる実際的な影響はなく、視覚エフェクト自体でこれだけ多くのポイントは表示されません。This generally has no practical implications, and visuals themselves aren’t going to display that many points. ただし、Power BI で送信されるクエリが完全に最適化されておらず、制限を超える中間結果が要求される場合、この制限が発生する可能性があります。However, the limit can occur in cases where Power BI is not fully optimizing the queries sent, and there is some intermediate result being requested that exceeds the limit. また、視覚エフェクトの作成中に、より適切な最終状態への過程でも、発生することがあります。It can also occur whilst building a visual, on the path to a more reasonable final state. たとえば、顧客が 100 万を超える場合、フィルターが適用されるまで、Customer や TotalSalesQuantity を含めるとこの制限に達します。For example, including Customer and TotalSalesQuantity would hit this limit if there were more than 1m customers, until some filter were applied.

    "外部データ ソースに対するクエリの結果セットが、許可されている最大サイズの '1000000' 行を超えています" というエラーが返ります。The error that would be returned would be “The resultset of a query to external data source has exceeded the maximum allowed size of '1000000' rows.”

  • インポート モードから DirectQuery モードに変更できない: DirectQuery モードからインポート モードを使うようにモデルを切り替えることは一般に可能ですが、これは必要なすべてのデータをインポートする必要があることを意味することに注意してください。Cannot change from import to DirectQuery mode: Note that while it's generally possible to switch a model from DirectQuery mode to use import mode, this means all the necessary data must be imported. また、元に戻すこともできません (主として、DirectQuery モードでサポートされていない機能セットのため)。It is also not possible to switch back (primarily due to the set of features not supported in DirectQuery mode). SAP BW などの多次元ソースに対する DirectQuery モデルでは、外部メジャーの処理が完全に異なるため、DirectQuery からインポートに切り替えることもできません。DirectQuery models over multidimensional sources like SAP BW also cannot be switched from DirectQuery to import, due to the completely different treatment of external measures.

Power BI サービスでの DirectQueryDirectQuery in the Power BI service

すべてのソースは Power BI Desktop からサポートされます。All sources are supported from Power BI Desktop. 一部のソースは、Power BI サービス内から直接使用することもできます。Some sources are also available directly from within the Power BI service. たとえば、ビジネス ユーザーは Power BI を使って Salesforce のデータに接続し、Power BI Desktop を使わずにダッシュボードをすぐに取得できます。For example, it is possible for a business user to use Power BI to connect to their data in Salesforce, and immediately get a dashboard, without use of Power BI Desktop.

サービスで直接利用できる DirectQuery 対応のソースは次の 2 つだけです。Only two of the DirectQuery enabled-sources are available directly in the service:

  • SparkSpark
  • Azure SQL Data WarehouseAzure SQL Data Warehouse

ただし、これら 2 つのソースに対する DirectQuery の使用はすべて Power BI Desktop 内で始めることを強くお勧めします。However, it is strongly recommended that any use of DirectQuery over those two sources start within Power BI Desktop. なぜなら、Power BI サービスで最初に接続するときは、多くの重要な制限が適用されます。つまり、最初は簡単ですが (Power BI サービスで開始)、結果のレポートをさらに強化する場合は制限があります (たとえば、計算の作成、多くの分析機能の使用、基になるスキーマの変更を反映するためのメタデータの更新などは不可能です)。The reason is that when the connection is initially made in the Power BI service, many key limitations will apply, meaning that while the start point was easy (starting in the Power BI service), there are limitations on enhancing the resulting report any further (for example, it's not possible then to create any calculations, or use many analytical features, or even refresh the metadata to reflect any changes to the underlying schema).

DirectQuery を正常に使用するためのガイダンスGuidance for using DirectQuery successfully

DirectQuery を使う場合は、このセクションで提供する確実に成功する方法についての概要的なガイダンスを参考にしてください。If you're going to use DirectQuery, then this section provides you with some high level guidance on how to ensure success. このセクションのガイダンスは、これまでに説明してきた DirectQuery を使用したときの影響から得られたものです。The guidance in this section is derived from the implications of using DirectQuery that have been described in this article.

バックエンド データ ソースのパフォーマンスBackend data source performance

簡単な視覚エフェクトが適切な時間で更新できるかどうかを検証することを強くお勧めします。It is strongly recommended to validate that simple visuals will be able to refresh in a reasonable time. 妥当な対話型操作のためには、これは 5 秒以内である必要があります。This should be within 5 seconds to have a reasonable interactive experience. 視覚エフェクトの更新に 30 秒以上かかるようでは、レポートを発行した後でさらに問題が発生する可能性が高く、ソリューションが動作しなくなります。Certainly if visuals are taking longer than 30 seconds, then it's highly likely that further issues will occur following publication of the report, which will make the solution unworkable.

クエリが遅い場合は最初に、基になるソースに送信されるクエリを調べて、観察されるクエリのパフォーマンスの理由を明らかにします。If queries are slow, then the first point of investigation is to examine the queries being sent to the underlying source, and the reason for the query performance being observed. このトピックでは、可能性のあるすべてのソースに対するデータベース最適化のベスト プラクティスについて広範には説明しませんが、ほとんどの状況に適用される標準的なデータベース プラクティスに当てはまります。This topic doesn't cover the wide range of database optimization best practices across the full set of potential underlying sources, but it does apply to the standard database practices that apply to most situations:

  • 通常、整数型の列に基づくリレーションシップの方が、他のデータ型の列での結合よりパフォーマンスがよくなりますRelationships based on integer columns generally perform better than joins on columns of other data types
  • 適切なインデックスを作成する必要があります。一般に、これは列ストア インデックスをサポートするソース (たとえば、SQL Server) ではそれらを使用することを意味します。The appropriate indexes should be created, which generally means the use of column store indexes in those sources that support them (for example, SQL Server).
  • ソースで必要なすべての統計を更新する必要がありますAny necessary statistics in the source should be updated

モデルの設計のガイダンスModel Design Guidance

モデルを定義するときは、次のことを考慮します。When defining the model, consider doing the following:

  • クエリ エディターで複雑なクエリを作成しない。Avoid complex queries in Query Editor. クエリ エディターで定義したクエリは単一の SQL クエリに変換されて、そのテーブルに送信されるすべてのクエリのサブセレクトに組み込まれます。The query that's defined in the Query Editor will be translated into a single SQL query, that will then be included in the subselect of every query sent to that table. そのクエリが複雑な場合、送信されるクエリでパフォーマンスの問題が発生する可能性があります。If that query is complex, it might result in performance issues on ever query sent. 一連の手順に対する実際の SQL クエリは、クエリ エディターで最後のステップを選択し、コンテキスト メニューから [ネイティブ クエリを表示] を選択することによって取得できます。The actual SQL query for a set of steps can be obtained by selecting the last step in Query Editor, and choosing View Native Query from the context menu.
  • メジャーを単純に保つ。Keep measures simple. 少なくとも最初は、単純な集計にメジャーを制限することをお勧めします。At least initially, it is recommended to limit measures to simple aggregates. その後、パフォーマンスに問題がなければさらに複雑なメジャーを定義してもかまいませんが、それぞれのパフォーマンスに注意するようにします。Then if those perform in a satisfactory manner, more complex measures can be defined, but paying attention to the performance for each.
  • 計算列ではリレーションシップを使用しない。Avoid relationships on calculated columns. これは、複数列の結合を実行する必要があるデータベースに特に関係があります。This is particularly relevant to databases where it is necessary to perform multi-column joins. 現在、Power BI では、FK/PK として複数列に基づくリレーションシップは許可されません。Power BI today does not allow a relationship to be based on multiple columns as the FK/PK. 一般的な回避策は、計算列を使って列を連結し、それを基にして結合することです。The common workaround is to concatenate the columns together using a calculated column, and base the join on that. この回避策はインポートされたデータの場合は妥当ですが、DirectQuery の場合は、式での結合になり、一般にインデックスを使用できず、パフォーマンスの低下につながります。While this workaround is reasonable for imported data, in the case of DirectQuery it results in a join on an expression, that commonly prevents use of any indexes, and leads to poor performance. 唯一の回避策は、基になるデータベースで実際に複数の列を 1 つの列に具体化することです。The only workaround is to actually materialize the multiple columns into a single column in the underlying database.
  • uniqueidentifier の列ではリレーションシップを使用しない。Avoid relationships on uniqueidentifier columns. Power BI は、データ型 uniqueidentifier をネイティブにサポートしていません。Power BI does not natively support a datatype of uniqueidentifier. したがって、uniqueidentifier 型の列の間にリレーションシップを定義すると、キャストを含む結合を使用するクエリになります。Hence defining a relationship between columns of type uniqueidentifier column will result in a query with a join involving a Cast. この場合も、一般にパフォーマンスが低下します。Again, this commonly leads to poor performance. このケースが特に最適化されるまでの唯一の回避策は、基になるデータベースで代替型の列を具現化することです。Until this case is specifically optimized, the only workaround is to materialize columns of an alternative type in the underlying database.
  • リレーションシップの to 列を非表示にする。Hide the to column on relationships. リレーションシップの to 列 (通常は、to テーブルの主キー) を非表示にして、フィールド リストに表示されないようにし、それによって視覚エフェクトで使うことができないようにする必要があります。The to column on relationships (commonly the primary key on the to table) should be hidden, so that it does not appear in the field list, and therefore cannot be used in visuals. 多くの場合、リレーションシップの基になっている列は実際には "システム列" であり (たとえば、データ ウェアハウス内のサロゲートキー)、このような列を非表示にするのはいずれにしてもよいことです。Often the columns on which relationships are based are in fact system columns (for example, surrogate keys in a data warehouse) and hiding such columns is good practice anyway. 列に意味がある場合は、表示され、主キーと同等になる単純な式を持つ、計算列を導入します。If the column does have meaning, then introduce a calculated column that is visible, and that has a simple expression of being equal to the primary key. 例:For example:

    ProductKey_PK   (Destination of a relationship, hidden)
    ProductKey (= [ProductKey_PK],   visible)

    このようにする理由は、視覚エフェクトに主キー列が含まれている場合に発生する可能性があるパフォーマンスの問題を回避することです。The reason for doing this is simply to avoid a performance issue that can occur otherwise if a visual includes the primary key column.

  • 計算列とデータ型の変更の使用をすべて調べる。Examine all uses of calculated columns and data type changes. これらの機能を使っても必ずしも有害ではありませんが、基になるソースに送信されるクエリに単純な列参照ではなく式が含まれるようになり、インデックスが使われなくなる可能性があります。Use of these capabilities are not necessarily harmful, they result in the queries sent to the underlying source containing expressions rather than simple references to columns, that again might result in indexes not being used.
  • (プレビューの) 双方向クロス フィルタリングをリレーションシップで使わない。Avoid use of the (preview) bi-directional cross filtering on relationships.
  • 設定 [参照整合性を想定] で実験する。Experiment with setting Assume referential integrity. リレーションシップで [参照整合性を想定] を設定すると、OUTER JOIN ではなく INNER JOIN ステートメントをクエリで使えるようになります。The Assume Referential Integrity setting on relationships enables queries to use INNER JOIN statements rather than OUTER JOIN. 一般的にはこれによりクエリのパフォーマンスが向上しますが、データ ソースの仕様に依存します。This generally improves query performance, though it does depend on the specifics of the data source.
  • クエリ エディターで相対データ フィルタリングを使わない。Do not use the relative data filtering in Query Editor. クエリ エディターでは相対データ フィルタリングを定義できます。It's possible to define relative date filtering in Query Editor. たとえば、日付が過去 14 日間である行をフィルター処理するような場合です。For example, to filter to the rows where the date is in the last 14 days.

    ただし、クエリが作成されたときの固定の日付に基づくフィルター処理に変換されます。However, this will be translated into a filter based on the fixed date, as at the time the query was authored. これは、ネイティブ クエリの表示から確認できます。This can be seen from viewing the native query.

    これは、ほぼ確実に望んだことではありません。This is almost certainly not what was wanted. レポート実行時の日付に基づいてフィルターが適用されるようにするには、代わりにレポート フィルターとしてレポートでフィルターを適用します。To ensure the filter is applied based upon the date as at the time the report is executed then instead apply the filter in the report as a Report Filter. 現在、これを実現するには、過去の日数を計算する計算列を作成し (DAX DATE() 関数を使用)、それをフィルターで使います。Currently this would be done by creating a calculated column calculating the number of days ago (using the DAX DATE() function), and then using that calculated column in a filter.

レポートの設計のガイダンスReport Design Guidance

DirectQuery 接続を使ってレポートを作成する場合は、次のガイドラインに従います。When creating a report using a DirectQuery connection, adhere to the following guidance:

  • フィルターを最初に適用する: 常に、視覚エフェクト作成の最初の段階で該当するフィルターを適用します。Apply filters first: Always apply any applicable filters at the start of building a visual. たとえば、TotalSalesAmount と ProductName をドラッグしてから特定の年でフィルター処理するのではなく、最初に年でフィルターを適用します。For example, rather than drag in the TotalSalesAmount, and ProductName, then filter to a particular year, apply the filter on Year at the very start. これは、視覚エフェクト作成の各ステップでクエリが送信され、最初のクエリが完了する前に別の変更を加えることができるので、基になるソースに不要な読み込みが残る可能性があるためです。This is because each step of building a visual will send a query, and whilst it is possible to then make another change before the first query has completed, this still leaves unnecessary load on the underlying source. 最初にフィルターを適用することで、一般にこれらの中間クエリのコストが低下します。By applying filters early, it generally makes those intermediate queries less costly. また、最初にフィルターを適用しないと、100 万行の上限に達する可能性があります。Also, failing to apply filters early can result in hitting the 1m row limit above.
  • ページ上の視覚エフェクトの数を制限する: ページを開くと (または、ページ レベルのスライサーやフィルターを変更すると)、ページ上のすべての視覚エフェクトが更新されます。Limit the number of visuals on a page: When a page is opened (or some page level slicer or filter changed) then all of the visuals on a page are refreshed. また、並列に送信されるクエリの数にも制限があるので、視覚エフェクトの数が増えると、一部の視覚エフェクトは順番に更新されるようになり、ページ全体の更新にかかる時間が増えます。There is also a limit on the number of queries that are sent in parallel, hence as the number of visuals increases, some of the visuals will be refreshed in a serial manner, increasing the time taken to refresh the entire page. このため、1 ページの視覚エフェクトの数を制限し、代わりに単純なページを多数作成します。For this reason it's recommended to limit the number of visuals on a single page, and instead have more, simpler pages.
  • 視覚エフェクト間の相互作用を無効にすることを検討する: 既定では、レポート ページ上の 1 つの視覚エフェクトを使って、そのページ上の他の視覚エフェクトに処理とクロス強調表示を適用できます。Consider switching off interaction between visuals: By default, visualizations on a report page can be used to cross-filter and cross-highlight the other visualizations on the page. たとえば、円グラフで "1999" を選択すると、縦棒グラフが "1999" のカテゴリの売上を表示するようにクロス強調表示されます。For example, having selected “1999” on the pie chart, the column chart is cross highlighted to show the sales by category for “1999”.

    ただし、この相互作用は、こちらの記事で説明されているように制御できます。However, this interaction can be controlled as described in this article. DirectQuery でクロス フィルター処理やクロス強調表示を行うには、基になるソースにクエリを送信する必要があるので、ユーザー選択への応答に非常に長い時間を要する場合は、相互作用をオフにする必要があります。In DirectQuery such cross-filtering and cross-highlighting requires queries to be sent to the underlying source, so the interaction should be switched off if the time taken to respond to users' selections would be unreasonably long.

  • レポートのみを共有することを検討する: Power BI サービスへの発行後にコンテンツを共有するにはさまざまな方法があります。Consider sharing the report only: There are different ways of sharing content after publishing to the Power BI service. DirectQuery の場合は、新しいレポートの作成を他のユーザーに許可する (そして、作成される特定の視覚エフェクトでパフォーマンスの問題が発生する可能性を招く) のではなく、完成したレポートのみの共有を検討することをお勧めします。In the case of DirectQuery, it's advisable to only considering sharing the finished report, rather than allow other users to author new reports (and potentially encounter performance issues for the particular visuals that they build).

これまでに説明したガイダンスに加えて、次の各レポート機能がパフォーマンスの問題の原因になる可能性があることに注意してください。In addition to the above list of suggestions, note that each of the following reporting capabilities can cause performance issues:

  • メジャー フィルター: 視覚エフェクトのメジャー (または列の集計) にはフィルターを含めることができます。Measure filters: Visuals containing measures (or aggregates of columns) can contain filters in those measures. たとえば、次の視覚エフェクトではカテゴリ別の SalesAmount が表示されますが、売上が 2,000 万を超えるカテゴリのみが含まれます。For example, the visual below shows SalesAmount by Category, but only including those Categories with more than 20M of sales.

    これにより、基になるソースに 2 つのクエリが送信されます。This will result in two queries being sent to the underlying source:

    • 最初のクエリでは、条件 (売上が 2,000 万を超える) を満たすカテゴリが取得されます。The first query will retrieve the Categories meeting the condition (Sales > 20M)
    • 2 番目のクエリでは、WHERE 句の条件を満たすカテゴリなど、視覚エフェクトに必要なデータが取得されます。The second query will then retrieve the necessary data for the visual, including the Categories that met the condition in the WHJERE clause.

    一般に、この例のようにカテゴリの数が数百から数千の場合はパフォーマンスに問題はありません。This generally performs just fine if there are hundreds or thousands of categories, as in this example. カテゴリの数が非常に多い場合は、パフォーマンスが低下する可能性があります (実際、条件を満たすカテゴリが 100 万を超えると、前に説明した 100 万行の制限のため、クエリは失敗します)。Performance can degrade if the number of categories is much larger (and indeed, the query will fail if there were more than a million categories meeting the condition, due to the one million row limit discussed earlier).

  • TopN フィルター: メジャーによるランクで上位 (または下位) N 個の値だけを表示するように、高度なフィルターを定義できます。たとえば、上の視覚エフェクトでは上位 10 のカテゴリだけを含めることができます。TopN filters: Advanced filters can be defined to filter on only the Top (or Bottom) N values ranked by some measure, for example, to only include the Top 10 Categories in the visual above. これにより、基になるソースに 2 つのクエリが送信されます。This will again result in two queries being sent to the underlying source. ただし、最初のクエリは基になるソースからすべてのカテゴリを返し、返された結果に基づいて TopN が決定されます。However, the first query will return all categories from the underlying source, and then the TopN are determined based on the returned results. 関係する列の基数によっては、パフォーマンスの問題が発生します (または、100 万行の制限によりクエリが失敗します)。Depending on the cardinality of the column involved, this can lead to performance issues (or query failures due to the 1m row limit).
  • 中央値: 一般に、すべての集計 (Sum、Count Distinct など) は基になるソースにプッシュされます。Median: Generally, any aggregation (Sum, Count Distinct, so on) is pushed to the underlying source. ただし、中央値の場合、この集計は一般に基になるソースによってサポートされないので、プッシュされません。However, this is not true for Median, as this aggregate is generally not supported by the underlying source. このような場合は、詳細データが基になるソースから取得され、返された結果から中央値が計算されます。In such cases, the detail data is retrieved from the underlying source, and the Median calculated from the returned results. これは、比較的少数の結果について中央値を計算するときは問題ありませんが、基数が大きい場合はパフォーマンスの問題が発生します (または、100 万行の制限によりクエリが失敗します)。This is reasonable when the median is to be calculated over a relatively small number of results, but performance issues (or query failures due to the 1m row limit) will occur if the cardinality is large. たとえば、Median Country Population は問題がなくても、Median Sales Price は問題になることがあります。For example, Median Country Population might be reasonable, but Median Sales Price might not be.
  • 高度なテキスト フィルター ("contains" など): テキスト列をフィルター処理する場合、高度なフィルタリングでは "contains" や "begins with" などのフィルターを使用できます。Advanced text filters (‘contains’ and similar): When filtering on a text column, the advanced filtering allows filters like ‘contains’ and ‘begins with’ and so on. 一部のデータ ソースでは、これらのフィルターにより確実にパフォーマンスが低下します。These filters can certainly result in degraded performance for some data sources. 具体的には、実際に必要なのが完全な一致 ("is" や "is not") である場合は、既定の "contains" フィルターを使わないようにする必要があります。In particular, the default ‘contains’ filter should not be used if what is really required is an exact match (‘is’ or ‘is not’). 結果は同じかもしれませんが、実際のデータによっては、インデックスの使用のためにパフォーマンスが大きく異なる可能性があります。Although the results might be the same, depending on the actual data, the performance might be drastically different due to the use of indexes.
  • 複数選択スライサー: 既定では、スライサーで可能な選択は 1 つのみです。Multi select slicers: By default, slicers only allow a single selection to be made. フィルターで複数選択を許可した場合、ユーザーがスライサーで複数の項目を選択すると (たとえば、関心のある 10 製品)、新しい選択ごとにクエリがバックエンド ソースに送信されるため、パフォーマンスの問題が発生する可能性があります。Allowing multi selection in filters can cause some performance issues, because as the user selects a set of items in the slicer (for example, the ten products they are interested in), then each new selection will result in queries being sent to the backend source. ユーザーがクエリが完了する前に次の項目を選択できるので、基になるソースで余分な負荷が発生します。Whilst the user can select the next item prior to the query completing, this does result in extra load on the underlying source.

パフォーマンスの問題の診断Diagnosing performance issues

このセクションでは、パフォーマンスの問題を診断する方法、またはレポートを最適化できるより詳細な情報を取得する方法について説明します。This section describes how to diagnose performance issues, or how to get more detailed information to allow the reports to be optimized.

パフォーマンスの問題の診断は、Power BI サービスではなく Power BI Desktop で始めることを強くお勧めします。It's strongly recommended that any diagnosis of performance issues starts in Power BI Desktop, rather than in the Power BI service. 一般に、パフォーマンスの問題は単に基になるソースのパフォーマンス レベルによるものであり、Power BI Desktop の分離環境で最初に特定のコンポーネント (Power BI ゲートウェイなど) を除外する方が、より簡単に問題を識別して診断できます。It's commonly the case that performance issues are simply based on the level of performance of the underlying source, and these are more easily identified and diagnosed in the much more isolated environment of Power BI Desktop, and initially eliminates certain components (such as the Power BI gateway). Power BI Desktop にパフォーマンスの問題が存在しないことがわかった場合にのみ、Power BI サービスでレポートの詳細に焦点を当てて調査する必要があります。Only if the performance issues are found to not be present with Power BI Desktop should investigation focus on the specifics of the report in the Power BI service.

同様に、ページにある多くの視覚エフェクトではなく、最初に個々の視覚エフェクトに問題を分離することをお勧めします。Similarly, it is recommended to first try to isolate any issues to an individual visual, rather than many visuals on a page.

それでは、このセクションの前の段落の手順を実施して、Power BI Desktop のページにある 1 つの視覚エフェクトの動作が遅いことがわかったものとします。So, let's say those steps (in the previous paragraphs in this section) have been taken - we now have a single visual on a page in Power BI Desktop that is still sluggish. Power BI Desktop によって基になるソースに送信されるクエリを特定するには、そのソースから出力される可能性があるトレース/診断情報を見ることができます。To determine the queries that are sent to the underlying source by Power BI Desktop, it's possible to view traces/diagnostic information that might be emitted by that source. このようなトレースには、クエリの実行方法および改善方法の詳細に関する有用な情報も含まれることがあります。Such traces might also contain useful information about the details of how the query was executed, and how it can be improved.

さらに、ソースからのこのようなトレースがない場合であっても、次に示すように、実行時間に沿って Power BI によって送信されるクエリを表示することができます。Further, even in the absence of such traces from the source, it's possible to view the queries sent by Power BI, along with their execution times, as described next.

Power BI Desktop によって送信されたクエリの特定Determining the queries sent by Power BI Desktop

既定では、Power BI Desktop は特定のセッションの間のイベントを FlightRecorderCurrent.trc という名前のトレース ファイルに記録します。By default, Power BI Desktop logs events during a given session to a trace file called FlightRecorderCurrent.trc.

一部の DirectQuery ソースの場合、このログには基になるデータ ソースに送信されたすべてのクエリが含まれています (他の DirectQuery ソースは将来的に含まれる予定です)。For some DirectQuery sources, this log includes all queries sent to the underlying data source (the remaining DirectQuery sources will be included in the future). ログにクエリを送信するソースは次のとおりです。The sources that send queries to the log are the following:

  • SQL ServerSQL Server
  • Azure SQL DatabaseAzure SQL Database
  • Azure SQL Data WarehouseAzure SQL Data warehouse
  • OracleOracle
  • TeradataTeradata

トレース ファイルは、現在のユーザーの AppData フォルダーにあります。The trace file can be found in the AppData folder for the current user:

\<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

このフォルダーに簡単にアクセスするには、Power BI Desktop[ファイル] > [オプションと設定] > [オプション] の順に選択し、[診断] を選択します。Here's an easy way to get to this folder: In Power BI Desktop select File > Options and settings > Options, and then select Diagnostics. 次のダイアログ ウィンドウが表示されます。The following dialog window appears:

[診断オプション][トレース フォルダーを開く] リンクを選択すると、次のフォルダーが表示されます。When you select the Open traces folder link, under Diagnostic Options, the following folder opens:

\<User>\AppData\Local\Microsoft\Power BI Desktop\Traces

そのフォルダーの親フォルダーに移動すると、AnalysisServicesWorkspaces を含むフォルダーが表示され、これには Power BI Desktop の開いているインスタンスごとに 1 つのワークスペース フォルダーが含まれます。Navigating to that folder's parent folder displays the folder containing AnalysisServicesWorkspaces, which will contain one workspace subfolder for every open instance of Power BI Desktop. これらのサブフォルダーは整数のサフィックスが付いた名前になっています (例: AnalysisServicesWorkspace2058279583)。These subfolders are named with an integer suffix, such as AnalysisServicesWorkspace2058279583.

そのフォルダー内の \Data サブフォルダーには、現在の Power BI セッションのトレース ファイル FlightRecorderCurrent.trc が含まれます。Inside that folder is a \Data subfolder that contains the trace file FlightRecorderCurrent.trc for the current Power BI session. 関連する Power BI Desktop セッションが終了すると、対応するワークスペース フォルダーは削除されます。The corresponding workspace folder is deleted when the associated Power BI Desktop session ends.

トレース ファイルは、SQL Server Profiler ツールを使って読むことができます。このツールは、SQL Server Management Studio の一部として無料でダウンロードできます。The trace files can be read using the SQL Server Profiler tool, which is available as a free download as part of SQL Server Management Studio. この場所から入手できます。You can get that from this location.

SQL Server Management Studio をダウンロードしてインストールした後、SQL Server Profiler を実行します。Once you download and install SQL Server Management Studio, run SQL Server Profiler.

トレース ファイルを開くには、次の手順のようにします。To open the trace file, take the following steps:

  1. SQL Server Profiler で、[ファイル] > [開く] > [トレース ファイル] の順に選択します。In SQL Server Profiler, select File > Open > Trace file
  2. 現在開いている Power BI セッションのトレース ファイルへのパスを入力します。次はその例です。Enter the path to the trace file for the currently open Power BI session, such as:

      C:\Users\<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data
  3. FilghtRecorderCurrent.trc を開きます。Open FilghtRecorderCurrent.trc

現在のセッションのすべてのイベントが表示されます。All events from the current session are displayed. 注釈付きの例を以下に示します。イベントのグループが強調表示されています。An annotated example is shown below, which highlights groups of events. 各グループには次のものが含まれます。Each group has the following:

  • Query Begin イベントと Query End イベント。これらは、UI によって生成された DAX クエリの開始と終了を表します (たとえば、視覚エフェクトから、またはフィルター UI 内の値の一覧の作成から)。A Query Begin and Query End event, which represent the start and end of a DAX query generated by the UI (for example, from a visual, or from populating a list of values in the filter UI)
  • 1 つまたは複数の DirectQuery Begin イベントと DirectQuery End イベントのペア。これらは、DAX クエリの評価の一部として、基になるデータ ソースに送信されたクエリを表します。One or more pairs of DirectQuery Begin and DirectQuery End events, which represent a query sent to the underlying data source, as part of evaluating the DAX query.

複数の DAX クエリを並列して実行できるので、異なるグループからのイベントが混在している可能性があることに注意してください。Note that multiple DAX queries can be executed in parallel, so events from different groups can be interleaved. ActivityID の値を使って、同じグループに属しているイベントを特定できます。The value of the ActivityID can be used to determine which events belong to the same group.

必要なその他の列は次のとおりです。Other columns of interest are the following:

  • TextData: イベントのテキスト形式の詳細です。TextData: The textual detail of the event. "Query Begin/End" イベントの場合は、DAX クエリです。For “Query Begin/End” events this will be the DAX query. "DirectQuery Begin/End" イベントの場合は、基になるソースに送信された SQL クエリです。For “DirectQuery Begin/End” events this will be the SQL query sent to the underlying source. 現在選択されているイベントの TextData は、下部の領域にも表示されます。The TextData for the currently selected event is also displayed in the region at the bottom.
  • EndTime: イベントが完了した日時です。EndTime: When the event completed.
  • Duration: DAX クエリまたは SQL クエリの実行にかかった時間です (ミリ秒単位)。Duration: The duration, in milliseconds, taken to execute the DAX or SQL query.
  • Error: エラーが発生したかどうかを示します (発生した場合は、イベントも赤で表示されます)。Error: Indicates if an error occurred (in which case the event is also displayed in red).

上の図では、重要な列がわかりやすいように、重要ではない列の表示が狭くなっていることに注意してください。Note that in the image above, some of the less interesting columns have narrowed, to allow the interesting columns to be seen more easily.

潜在的なパフォーマンスの問題の診断に役立つトレースをキャプチャする推奨される方法は次のとおりです。The recommended approach to capturing a trace to help diagnose a potential performance issue is the following:

  • 1 つの Power BI Desktop セッションを開きます (複数のワークスペース フォルダーで混乱するのを避けるため)。Open a single Power BI Desktop session (to avoid the confusion of multiple workspace folders)
  • Power BI Desktop で関心のあるアクションのセットを実行します。Perform the set of actions of interest in Power BI Desktop. それ以外にいくつかの操作を実行し、目的のイベントがトレース ファイルにフラッシュされるようにします。Include a few additional actions beyond that, to ensure that the events of interest are flushed into the trace file.
  • SQL Server Profiler を開き、前述のようにトレースを確認します。Open SQL Server Profiler and examine the trace, as described earlier. Power BI Desktop を閉じるとトレース ファイルが削除されることに注意してください。Remember that the trace file will be deleted upon closing Power BI Desktop. また、Power BI Desktop でのその後の操作はすぐに表示されません。新しいイベントを表示するには、トレース ファイルいったん閉じてから再度開く必要があります。Also, further actions in Power BI Desktop will not immediately appear – the trace file should be closed and re-opened to see the new events.
  • トレース ファイルを容易に解釈できるよう (および、トレース ファイルのサイズには制限があり、非常に長いセッションでは前の方のイベントが破棄される可能性があるため)、個々のセッションを適度な小ささ (数百秒ではなく 10 秒くらいの操作) にします。Keep individual sessions reasonably small (ten seconds of actions, not hundreds) to make it easier to interpret the trace file (and because there is a limit on the size of the trace file, thus for very long sessions there is a chance of early events being dropped).

Power BI Desktop によって送信されるクエリの形式の概要Understanding the form of query sent by Power BI Desktop

Power BI Desktop によって作成および送信されるクエリの一般的な形式では、参照されるテーブルごとにサブセレクトが使われます。サブセレクトは、クエリ エディターで定義されるクエリによって定義されます。The general format of queries created and sent by Power BI Desktop use subselects for each of the tables referenced, where the subselect is as defined by the query defined in Query Editor. たとえば、SQL Server に次のような TPC-DS テーブルがあるものとします。For example, assume the following TPC-DS tables in SQL Server:

次のようなクエリについて考えます。Consider the following query:

このクエリは、次の視覚エフェクトになります。That query results in the following visual:

この視覚エフェクトを更新すると、次の段落の後で示す SQL クエリが生成されます。Refreshing that visual will result in the SQL query shown below the next paragraph. ご覧のように、Web Sales、Item、Date_dim に対する 3 つのサブセレクトがあり、それぞれが対応するテーブルのすべての列を返しますが、視覚エフェクトで実際に参照されているのは 4 つの列だけです。As you can tell, there are three subselects for Web Sales, Item, and Date_dim, that each return all the columns on the respective table, even though only four columns are actually referenced by the visual. サブセレクトでのこれらのクエリは (網掛けの部分)、クエリ エディターで定義されているクエリの結果です。These queries in the subselects (they're shaded) are exactly the result of the queries defined in Query editor. 現時点で DirectQuery についてサポートされているデータ ソースの場合、この方法でサブセレクトを使っても、パフォーマンスには影響ないことがわかっています。Use of subselects in this manner has not been found to impact performance, for the data sources so far supported for DirectQuery. SQL Server などのデータ ソースでは、他の列への参照は最適化により除外されます。Data sources like SQL Server simply optimize away the references to the other columns.

Power BI でこのパターンが使われる理由の 1 つは、使用される SQL クエリをアナリストが直接提供でき、書き換えられることなく "そのまま" 使用されるようにするためです。One reason Power BI employs this pattern is because the SQL query used can be provided directly by the analyst, so it's used "as provided", without an attempt to rewrite it.

次の手順Next steps

この記事では、すべてのデータ ソースに共通する DirectQuery の側面について説明しました。This article describes aspects of DirectQuery that are common across all data sources. 個々のソースに固有の特定の詳細があります。There are certain details that are specific to individual sources. 特定のソースについては、以下のトピックをご覧ください。See the following topics covering specific sources:

DirectQuery について詳しくは、次のリソースをご覧ください。For more information about DirectQuery, check out the following resources: