Power BI Desktop の DirectQuery
Power BI Desktop を使用してデータ ソースに接続すると、データのコピーをインポートできます。 一部のデータ ソースでは、DirectQuery を使用してデータをインポートせずにデータ ソースに直接接続することもできます。 この記事では、インポートと DirectQuery の接続モードの違いについて説明し、DirectQuery を使用してデータ ソースに接続する方法について説明します。 また、DirectQuery の使用に関する考慮事項と制限事項 (パフォーマンスやセキュリティなど) についても説明します。
データ ソースが DirectQuery をサポートしているかどうかを判断するには、Power Query の接続の記事「Power Query におけるコネクタ」にある利用可能なデータ ソースの完全な一覧を表示します。これは Power BI にも適用されます。 サポートされているコネクタの一覧から、関心のあるデータ ソースについて説明する記事を選択し、そのコネクタの記事の「サポートされている機能」というタイトルのセクションを参照してください。 データ ソースの記事のそのセクションに DirectQuery が一覧表示されていない場合、そのデータ コネクタでは DirectQuery はサポートされていません。
インポートと DirectQuery 接続モードの使用の違いを次に示します:
インポート: 選択したテーブルと列のデータのコピーが Power BI Desktop にインポートされます。 視覚エフェクトを作成するか、操作する場合、Power BI Desktop ではインポートされたデータが使用されます。 初回インポート後または最新の更新後に基になるデータの変更を確認するには、セマンティック モデル全体をもう一度インポートしてデータを更新する必要があります。
DirectQuery: データは Power BI Desktop にインポートされません。 リレーショナル ソースの場合、Power BI Desktop の [データ] ペインに表示されるテーブルと列を選択できます。 SAP Business Warehouse (SAP BW) などの多次元ソースの場合、選択されたキューブのディメンションとメジャーは [データ] ペインに表示されます。 視覚エフェクトを作成または操作するときに、Power BI Desktop で基になるデータ ソースに対してクエリが実行されるため、常に現在のデータが表示されます。
DirectQuery では、視覚エフェクトを作成または操作する場合、基になるソースに対してクエリを実行する必要があります。 視覚エフェクトの更新に必要な時間は、基になるデータ ソースのパフォーマンスによって異なります。 要求の処理に必要なデータが最近要求されていた場合、Power BI Desktop では最近のデータが使用され、視覚エフェクトの表示に必要な時間が短縮されます。 [ホーム] リボンから [更新] を選択すると、すべての視覚エフェクトが現在のデータで更新されます。
DirectQuery を使用する場合、多くのデータ モデリングとデータ変換を使用できますが、パフォーマンスに基づいたいくつかの制限があります。 DirectQuery の利点、制限、推奨事項の詳細については、Power BI での DirectQuery に関するページを参照してください。
DirectQuery の利点
DirectQuery を使用する利点としては、次のようなものがあります。
DirectQuery を使用すると、事前集計を使用してすべてのデータをインポートすることが不可能な非常に大きなセマンティック モデルに対して視覚化を構築できます。
DirectQuery レポートでは、常に現在のデータが使用されます。 基になるデータの変更を確認するにはデータを更新する必要がありますが、データを更新するために大きなセマンティック モデルを再インポートすることは不可能な場合があります。
1 GB のセマンティック モデル制限は、DirectQuery には適用されません。
DirectQuery を使用して接続する
DirectQuery を使用してデータ ソースに接続するには、次の手順を行います。
Power BI Desktop のリボンの [ホーム] グループで、[データの取得] を選択し、DirectQuery でサポートされているデータ ソース (SQL Server など) を選択します。
接続のダイアログ ボックスにある [データ接続モード] で、[DirectQuery] を選択します。
Power BI サービスに公開する
DirectQuery レポートを Power BI サービスに発行できますが、Power BI サービスでレポートを開くには追加の手順を行う必要があります。
Azure SQL Database、Azure Synapse Analytics (旧称 SQL Data Warehouse)、Amazon Redshift、Snowflake Data Warehouse 以外の DirectQuery データ ソースに Power BI サービスを接続するには、オンプレミス データ ゲートウェイをインストールし、データ ソースを登録します。
Azure SQL Database、Azure Synapse、Amazon Redshift、Snowflake Data Warehouse などのクラウド ソースで DirectQuery を使用した場合、オンプレミス データ ゲートウェイは必要ありません。 その場合でも、発行されたレポートを Power BI サービスで開くには、資格情報を提供する必要があります。 資格情報を提供しないと、発行されたレポートを開こうとしたとき、または DirectQuery に接続して作成されたセマンティック モデルを探求しようとしたときにエラーが発生します。
レポートを開いてデータを更新するために資格情報を提供するには、次の手順を行います。
Power BI サービスで、ワークスペースに移動し、ワークスペースコンテンツリストで DirectQuery を使用するセマンティック モデルを見つけます。
セマンティック モデルの名前の横にある 3 つの水平ドット アイコンの [詳細オプション] を選択し、[設定] を選択します。
[データ ソースの資格証明] で、データ ソースに接続するための資格情報を入力します。
Note
プライベート IP アドレスを持つ Azure SQL Database で DirectQuery を使用した場合は、オンプレミスのゲートウェイを使用する必要があります。
考慮事項と制限事項
Power BI Desktop の一部の機能は DirectQuery モードでサポートされていないか、制限があります。 また、Power BI サービスの一部の機能 (クイック分析情報など) は、DirectQuery を使用するセマンティック モデルでは使用できません。 DirectQuery を使用するかどうかを決定する際には、機能に関するこれらの制限事項を考慮してください。 また、次の要因についても検討してください。
パフォーマンスと負荷に関する考慮事項
DirectQuery ではすべての要求がソース データベースに送信されるため、ビジュアルの更新に必要な時間は、基になるソースが結果を返すのに要する時間によって異なります。 要求されたビジュアル データを受け取るまでの応答時間としては、5 秒以下が推奨されます。 更新時間が 30 秒を超えると、ユーザーがレポートを使用するためのエクスペリエンスが著しく低下します。 Power BI サービスでは、実行時間が 4 分を超えるとクエリはタイムアウトし、ユーザーはエラーを受け取ります。
ソース データベースに対する負荷は、特にレポートで行レベルのセキュリティ (RLS) が使用されている場合、発行されたレポートを使用する Power BI ユーザーの数によっても異なります。 複数のユーザーによって共有される RLS 以外のダッシュボード タイルを更新すると、1 つのクエリがデータベースに送信されます。一方、RLS を使用するダッシュボード タイルを更新するには、ユーザーごとに 1 つのクエリが必要になります。 クエリの数が増えると、負荷が大幅に増加し、パフォーマンスに影響を及ぼす可能性があります。
100 万行の制限
DirectQuery では、クラウド データ ソース (オンプレミスではないすべてのデータ ソース) から返されるデータについて 100 万行の制限が規定されています。 オンプレミスのソースは、1 行あたり約 4 MB (専用の圧縮アルゴリズムによって異なる)、またはビジュアル全体で 16 MB の定義されたペイロードに制限されます。 Power BI Premium 容量の新しい設定に関するブログ記事で説明されているように、Premium 容量では、最大行についてさまざまな制限を設定できます。
Power BI では、可能な限り効率的なクエリが作成されますが、生成される一部のクエリでは、基になるデータ ソースから取得する行数が多すぎる場合があります。 たとえば、高いカーディナリティ列を含む単純なグラフで、集計オプションを [計算しない] に設定した場合に、このような状況が発生する可能性があります。 ビジュアルの場合、列のカーディナリティは 100 万未満にするか、適切なフィルターを適用する必要があります。
行の制限は、DirectQuery が返すセマンティック モデルの選択に使用される集計および計算には適用されず、返される行に対してのみ適用されます。 たとえば、データ ソースに対して実行されるクエリは、1,000 万行を集計できます。 Power BI に返されるデータが 100 万行未満である限り、クエリは結果を正確に返します。 管理者によって異なる制限が設定されている Premium 容量を除いて、データが 100 万行を超える場合、Power BI には、 外部データ ソースに対するクエリの結果セットが、許可されている最大サイズの '1000000' 行を超えていますというエラーが表示されます。
セキュリティに関する考慮事項
既定では、発行されたレポートを Power BI サービスで利用するすべてのユーザーは、発行後に入力された資格情報を使用して、基になるデータ ソースに接続します。 これは、インポートされたデータの場合と同じです。 基になるソースで定義されているセキュリティ規則に関係なく、すべてのユーザーに同じデータが表示されます。
DirectQuery ソースで実装されたユーザーごとのセキュリティが必要な場合は、RLS を使用するか、ソースに対する Kerberos 制約付き認証を構成します。 Kerberos はすべてのソースで使用できるわけではありません。 詳細については、「Power BI での行レベルのセキュリティ (RLS)」および「Power BI サービスからオンプレミス データ ソースへの Kerberos ベースの SSO を構成する」を参照してください。
DirectQuery に関するその他の制限
DirectQuery の使用に関するその他の制限としては、次のようなものがあります。
Power Query エディターのクエリが複雑すぎると、エラーが発生します。 エラーを修正するには、Power Query エディターで問題のある手順を削除するか、インポート モードに切り替える必要があります。 SAP BW などの多次元ソースでは、Power Query エディターを使用できません。
自動の日付/時刻の階層は、DirectQuery では使用できません。 DirectQuery モードでは、年、四半期、月、または日による日付列のドリルダウンはサポートされていません。
テーブルまたはマトリックスの視覚化では、DirectQuery ソースから 500 を超える行が返される場合、列は 125 に制限されます。 このような結果が返される場合、テーブルまたはマトリックスにスクロール バーが表示され、それを使用してより多くのデータを取り込むことができます。 その場合、テーブルまたはマトリックス内の列の最大数は 125 です。 1 つのテーブルまたはマトリックスに 125 を超える列を含める必要がある場合は、
MIN、MAX、FIRST、またはLASTを使用するメジャーの作成を検討します。これらは、この最大値にはカウントされません。インポートから DirectQuery モードに変更できません。 必要なすべてのデータをインポートする場合は、DirectQuery モードをインポート モードに切り替えることができます。 DirectQuery がサポートしていない機能セットが主な原因で、元に戻すことはできません。 SAP BW などの多次元ソースに対する DirectQuery モデルは、外部メジャーの処理が異なるため、DirectQuery からインポート モードに切り替えることもできません。
シングル サインオン (SSO) 認証を使用してデータ ソースから DirectQuery テーブルを参照する計算テーブルおよび計算列は、共有可能なクラウド接続 や 詳細なアクセス コントロール が割り当てられた Power BI サービス内でサポートされています。