Power BI でのデータの更新
Power BI を利用すると、データから分析情報へ、さらにはアクションへと迅速に移動することが可能です。ただし、Power BI レポートとダッシュボード内のデータは、確実に最新化しておく必要があります。 データの更新方法を把握することは、多くの場合、正確な結果を得るうえで重要になります。
この記事では、Power BI のデータ更新機能とその依存関係について概念レベルで説明します。 また、一般的な更新の問題を回避するためのベスト プラクティスとヒントも提示します。 データ更新の仕組みを理解するための基礎を築く内容になっています。 データ更新を構成する際に対象となる詳しい手順については、この記事の末尾にある「関連するコンテンツ」セクションに示されたチュートリアルと攻略ガイドをご覧ください。
データ更新について
Power BI では、データが更新されるたびに、基になるデータ ソースを照会し、必要に応じてソース データをセマンティック モデルに読み込んで、更新後のセマンティック モデルに依存するレポートまたはダッシュボード内のビジュアルをすべて更新する必要があります。 プロセス全体は、以降のセクションで説明するように、セマンティック モデルのストレージ モードに応じて複数のフェーズで構成されます。
Power BI によるセマンティック モデル、レポート、およびダッシュボードの更新方法を理解するためには、次の概念について認識しておく必要があります:
- ストレージ モードとセマンティック モデルの種類: Power BI でサポートされるストレージ モードとセマンティック モデルの種類には、さまざまな更新要件があります。 Power BI にデータを再インポートして、行われた変更をすべて確認するか、またはソースにあるデータを直接照会するかを選ぶことができます。
- Power BI 更新の種類: セマンティック モデルの特性に関わらず、さまざまな更新の種類を把握しておくと、Power BI では更新処理中にどこに時間を費やす可能性があるのかを理解しやすくなります。 そして、これらの詳細とストレージ モードの特性を合わせて考えることは、セマンティック モデルに対して [今すぐ更新] を選択したときに Power BI が何を実行するかを正確に理解するのに役立ちます。
ストレージ モードとセマンティック モデルの種類
さまざまなデータ ソースからデータにアクセスするために、Power BI セマンティック モデルは次のいずれかのモードで操作できます。 詳細については、「Power BI Desktop のストレージ モード」をご覧ください。
- Import モード
- DirectQuery モード
- Direct Lake モード
- LiveConnect モード
- Push モード
次の図では、ストレージ モードに基づいて、さまざまなデータ フローを示しています。 最も重要な点は、Import モードのセマンティック モデルだけがソース データの更新を必要とすることです。 データ ソースからデータをインポートするのはこの種類のセマンティック モデルだけなので、更新が必要になります。また、インポートされたデータは、定期またはアドホック ベースで更新される可能があります。 DirectQuery、Direct Lake、または Analysis Services での LiveConnect モードのセマンティック モデルでは、データをインポートしません。ユーザー操作ごとに、基になるデータ ソースを照会します。 Push モードのセマンティック モデルは、データ ソースに直接アクセスはしませんが、ユーザーが Power BI にデータをプッシュすることを想定します。 セマンティック モデルの更新要件は、ストレージ モード/セマンティック モデルの種類によって異なります。
Import モードのセマンティック モデル
Power BI では、元のデータ ソースからセマンティック モデルへデータをインポートします。 セマンティック モデルに送信された Power BI レポートとダッシュボードのクエリでは、インポートされたテーブルと列から結果が返されます。 このようなセマンティック モデルは、ポイントインタイム コピーと考える場合があります。 Power BI ではデータをコピーするので、セマンティック モデルを更新して、基になるデータ ソースから変更をフェッチする必要があります。
セマンティック モデルが更新される場合、完全に更新されるか、部分的に更新されます。 部分更新は、増分更新ポリシーが設定されているテーブルを持つセマンティック モデルで行われます。 これらのセマンティック モデルでは、テーブル パーティションのサブセットのみが更新されます。 さらに、上級ユーザーは XMLA エンドポイントを使用して、任意のセマンティック モデル内の特定のパーティションを更新できます。
セマンティック モデルの更新に必要なメモリの量は、完全と部分のどちらの更新を実行しているかによって異なります。 更新中は、セマンティック モデルへのクエリを処理するためにセマンティック モデルのコピーが保持されます。 つまり、完全更新を実行する場合は、セマンティック モデルに必要なメモリの量が 2 倍になります。
セマンティック モデルの更新に必要な追加のメモリが確保されるように、容量使用量を計画することをお勧めします。 十分なメモリを用意することで、更新操作中にセマンティック モデルで利用可能なメモリよりも多くのメモリが必要になった場合に発生する可能性のある更新の問題を回避できます。 Premium 容量の各セマンティック モデルで使用可能なメモリの量については、容量と SKU の表を参照してください。
Premium 容量の大規模なセマンティック モデルの詳細については、「大規模なセマンティック モデル 」を参照してください。
DirectQuery モードのセマンティック モデル
Power BI では、DirectQuery モードで動作する接続を介してデータをインポートすることはありません。 代わりに、レポートまたはダッシュボードがセマンティック モデルに対してクエリを実行するたびに、セマンティック モデルは基になるデータ ソースから結果を返します。 Power BI ではクエリを変換して、データ ソースに転送します。
Note
ライブ接続レポートでは、セマンティック モデルまたはモデルをホストする容量または Analysis Services インスタンスにクエリを送信します。 SQL Server Analysis Services (SSAS) や Azure Analysis Services (AAS) などの外部分析サービスを使用する場合、Power BI の外部でリソースが消費されます。
Power BI ではデータをインポートしないため、データ更新を実行する必要はありません。 ただし、更新の種類に関する次のセクションで説明するように、Power BI では、タイルの更新と、可能であればレポートの更新を実行します。 タイルは、ダッシュボードにピン留めされたレポート ビジュアルであり、タイルに最新の結果が表示されるように、ダッシュボード タイルの更新は約 1 時間ごとに行われます。 次のスクリーンショットに示すように、セマンティック モデルの設定では、スケジュールを変更できます。または、[今すぐ更新] オプションを使用して、手動でダッシュボードの更新を強制実行します。
Note
- Import モードのセマンティック モデルと、Import モードと DirectQuery モードを組み合わせた複合セマンティック モデルでは、スケジュールされたデータ更新またはオンデマンドのデータ更新のたびにタイルが Power BI により自動的に更新されるため、個別にタイルを更新する必要はありません。 XMLA エンドポイントに基づいて更新されたセマンティック モデルでは、キャッシュされたタイル データのみがクリアされます (キャッシュを無効にします)。 各ユーザーがダッシュボードにアクセスするまで、タイル キャッシュは更新されません。 インポート モデルの場合は、[セマンティック モデル] タブの [スケジュールされた更新] セクションで更新スケジュールを確認できます。複合セマンティック モデルの場合、[スケジュールされた更新] セクションは [パフォーマンスの最適化] セクションにあります。
- Power BI は、ソブリン クラウドでの Azure Analysis Services (AAS) へのクロスボーダー ライブ接続をサポートしていません。
プッシュ セマンティック モデル
プッシュ セマンティック モデルには、データ ソースの正式な定義は含まれません。そのため、Power BI 上でデータ更新を実行する必要はありません。 Azure Stream Analytics などの外部サービスやプロセスを経由して、セマンティック モデルにデータをプッシュすることで、更新を行います。 これは、Power BI を利用したリアルタイム分析では、一般的な手法です。 Power BI では、プッシュ セマンティック モデルの最上部に使用されるタイルに対しては、引き続きキャッシュの更新を実行します。 詳細なチュートリアルについては、「Stream Analytics を使用した不正な通話データの分析と Power BI ダッシュボード内での結果の視覚化」を参照してください。
Power BI の更新の種類
Power BI の更新操作は、データ更新、OneDrive の更新、クエリ キャッシュの更新、タイルの更新、およびレポート ビジュアルの更新を含む、複数の更新の種類で構成できます。 指定したセマンティック モデルに対して必要な更新手順は、Power BI によって自動的に判断されますが、それらが更新操作の複雑さや期間にどのように影響するのかは、ご自身で把握しておく必要があります。 簡単な参考情報については、次の表で確認してください。
ストレージ モード | データ更新 | OneDrive の更新 | クエリのキャッシュ | タイルの更新 | レポート ビジュアル |
---|---|---|---|---|---|
インポート | スケジュール設定およびオンデマンド | はい (接続されたセマンティック モデルの場合) | Premium 容量で有効になっている場合 | 自動およびオンデマンド | いいえ |
DirectQuery | 適用なし | はい (接続されたセマンティック モデルの場合) | 適用なし | 自動およびオンデマンド | いいえ |
LiveConnect | 適用なし | はい (接続されたセマンティック モデルの場合) | 適用なし | 自動およびオンデマンド | はい |
プッシュ | 該当なし | 該当なし | 実効性なし | 自動およびオンデマンド | いいえ |
更新の種類が異なる際にもう 1 つ考慮すべきなのが、それが何に影響するかと、それをどこに適用できるかです。 列の新規作成、名前変更、削除などのデータ ソース テーブル構造またはスキーマの変更は、Power BI Desktop でのみ適用でき、Power BI サービスでは更新が失敗する可能性があります。 何に影響するかの簡単な参考情報については、次の表で確認してください。
レポート ビジュアルの更新 | データ更新 | スキーマの更新 | |
---|---|---|---|
それぞれの更新の種類は何を行いますか? | ビジュアルの設定に使用されるクエリが更新されます。 DirectQuery テーブルを使用するビジュアルの場合、ビジュアルはクエリを実行してデータ ソースから最新のデータを取得します。 インポートされたテーブルを使用するビジュアルの場合、ビジュアルは前回のデータ更新時にセマンティック モデルにインポート済みのデータのクエリしか実行しません。 |
データはデータ ソースから更新されます。 ビジュアル レベルであり、レポート ビジュアルの更新に依存する DirectQuery テーブルには適用されません。 インポートされたテーブルの場合、データはソースから更新されます。 |
前回の更新以降の、データ ソース テーブル構造の変更がすべて表示されます。 たとえば、Power BI データフローまたは SQL Database ビューに追加された新しい列を表示します。 インポート済みの DirectQuery および Direct Lake テーブルに適用されます。 |
Power BI Desktop では、レポート ビジュアルの更新、データの更新、スキーマの更新は以下を使用して同時に行われます
[ホーム] リボン >[更新] ボタン。
[ホーム] リボン >[データの変換]>[閉じて適用] ボタン。
[データ] ペイン内の任意のテーブル上のショートカット メニュー (右クリックまたは省略記号の選択): [データの更新] を選択します。
これらの更新の種類は、常に個別に適用できるわけではありません。また、これらを適用できる場所は、Power BI Desktop と Power BI サービスで異なります。 簡単な参考情報については、次の表で確認してください。
レポート ビジュアルの更新 | データ更新 | スキーマの更新 | |
---|---|---|---|
Power BI Desktop の場合 |
|
他の更新の種類とは別に使用できない | 他の更新の種類とは別に使用できない |
Power BI サービスの場合 |
|
|
Power BI サービスでデータ モデルを編集する際に、[テーブルの編集] を使用する場合、Direct Lake モードのセマンティック モデルでのみ使用できます。 |
次の点に留意してください | たとえば、ブラウザーでレポートを開くと、スケジュールされた更新によってインポートされたテーブルのデータ更新が実行され、開いているブラウザーのレポート ビジュアルは、レポート ビジュアルの更新が開始されるまで更新されません。 | ソース列またはテーブルの名前が変更されたり削除されたりしていると、Power BI サービス内のデータ更新は失敗します。 Power BI サービスにはスキーマ更新が含まれていないため、失敗します。 このエラーを修正するには、Power BI Desktop でスキーマの更新を実行し、セマンティック モデルをサービスに対して再発行する必要があります。 | データ ソースで名前が変更または削除された列またはテーブルはスキーマ更新で削除されますが、これによってビジュアルと DAX 式 (メジャー、計算列、行レベル セキュリティなど) が壊れたり、それらの列またはテーブルに依存しているリレーションシップが削除されたりする可能性があります。 |
データ更新
Power BI ユーザーにとって、データの更新とは通常、更新スケジュールに基づくか、オンデマンドでの元のデータ ソースからセマンティック モデルへのデータのインポートを意味します。 セマンティック モデルの更新は 1 日に複数回実行でき、基になるソース データが頻繁に変更される場合には、その必要が生じる可能性があります。 Power BI では、共有容量のセマンティック モデルは、スケジュールされた 1 日 8 回のセマンティック モデルの更新に制限されます。 この 8 回という値はバックエンド データベースに保存され、セマンティック モデルの設定ページで選択された "ローカル時間" ゾーンを基準にします。 更新するモデルと更新のタイミングがスケジューラによって確認されます。 8 回の更新というクォータは、毎日ローカル時間の午前 12 時 1 分にリセットされます。
セマンティック モデルが Premium 容量に存在する場合は、セマンティック モデルの設定で 1 日あたり最大 48 回の更新をスケジュールできます。 詳しくは、この記事で後述する「スケジュールされた更新の構成」をご覧ください。 XMLA エンドポイントで読み取り/書き込みが有効になっている Premium 容量のセマンティック モデルでは、TMSL または PowerShell を使用してプログラムによって構成した場合、無制限の更新操作がサポートされます。
1 日あたりの更新に関する共有容量の制限は、スケジュールされた更新と API による更新の両方に適用されることを周知することも重要です。 次のスクリーンショットに示すように、セマンティック モデルの設定ページ上のリボン内の [今すぐ更新] を選択することで、オンデマンドの更新をトリガーすることもできます。 オンデマンドの更新は、更新の制限の対象外です。 また、Premium 容量上のセマンティック モデルには、API による更新の制限は課されません。 Power BI REST API を使用して独自の更新ソリューションを構築する場合は、「セマンティック モデル - 更新セマンティック モデル」を参照してください。
Note
共有容量でのデータ更新は 2 時間未満で完了する必要があります。 セマンティック モデルでより長い更新操作が必要な場合は、セマンティック モデルを Premium 容量に移動することを検討してください。 Premium では、最大更新時間は 5 時間ですが、XMLA エンドポイントを使用するデータの更新では 5 時間の制限を回避できます。
OneDrive の更新
OneDrive または SharePoint Online 上の Power BI Desktop ファイル、Excel ワークブック、またはコンマ区切りの値 (.csv) ファイルに基づいてセマンティック モデルとレポートを作成した場合、Power BI では、OneDrive の更新と呼ばれる別の種類の更新を実行します。 詳しくは、「ファイルから Power BI 用のデータを取得する」をご覧ください。
Power BI がデータ ソースからセマンティック モデルにデータをインポートするセマンティック モデルの更新とは異なり、OneDrive の更新ではセマンティック モデルとレポートがソース ファイルと同期されます。 Power BI では既定で、OneDrive または SharePoint Online 上のファイルに接続されているセマンティック モデルを同期する必要があるかどうかを、約 1 時間ごとにチェックします。
Power BI では OneDrive の項目 ID に基づいて更新が実行されるため、更新と置き換えを検討する際は慎重になる必要があります。 OneDrive ファイルをデータ ソースとして設定すると、Power BI では、更新を実行するときにファイルの項目 ID が参照されます。 次のシナリオを考えてみます。マスター ファイルの A とそのファイルの運用コピー B があるとき、ファイル B に対して OneDrive の更新を構成するとします。ファイル B の上にファイル A をコピーすると、コピー操作によって古いファイル B が削除され、新しいファイル B が異なる項目 ID で作成され、これにより OneDrive の更新が中断されます。 このような状況を回避するには、代わりにファイル B をアップロードして置き換えることができます。これによってその同じ項目 ID が保持されます。
(たとえば、ドラッグ アンド ドロップなどを使用して) ファイルを別の場所に移動しても、Power BI はそのファイルのアイテム ID を把握し続けているため、更新は動作し続けます。 ただし、そのファイルを別の場所にコピーすると、ファイルの新しいインスタンスと新しいアイテム ID が作成されます。 そのため、Power BI ファイル参照は無効になり、更新は失敗します。
Note
ローカル コンピューターで同期が完了していて、Power BI サービスで [今すぐ更新] を使用した後でも、Power BI でセマンティック モデルを更新するまでに最大 60 分かかることがあります。
過去の同期サイクルを確認するには、更新履歴にある [OneDrive] タブをチェックします。 次のスクリーンショットは、サンプル セマンティック モデルに対する完了済みの同期サイクルを示しています。
上記のスクリーンショットに示すように、Power BI ではこの OneDrive の更新をスケジュールされた更新として識別しますが、更新間隔を構成することはできません。 OneDrive の更新は、セマンティック モデルの設定でのみ非アクティブ化できます。 更新の非アクティブ化は、Power BI のセマンティック モデルとレポートにより、ソース ファイルから自動的に変更が取得されないようにしたい場合に便利です。
次のスクリーンショットに示すように、セマンティック モデルが OneDrive または SharePoint Online 上のファイルに接続されている場合、セマンティック モデルの設定ページには [OneDrive の資格情報] と [OneDrive の更新] セクションのみが表示されることに注意してください。 OneDrive または SharePoint Online 内のソース ファイルに接続されていないセマンティック モデルでは、これらのセクションは表示されません。
セマンティック モデルの OneDrive 更新を無効にした場合でも、セマンティック モデル メニューで [今すぐ更新] を選択することで、セマンティック モデルをオンデマンドで同期することはできます。 Power BI は、オンデマンド更新の一環として、OneDrive または SharePoint Online 上のソース ファイルが Power BI 内のセマンティック モデルよりも新しいかどうかをチェックし、新しい場合はセマンティック モデルを同期します。 [更新履歴] では、 [OneDrive] タブ上にオンデマンド更新としてこれらのアクティビティが一覧表示されます。
OneDrive の更新では、元のデータ ソースからデータがプルされないことに留意してください。 OneDrive の更新では、次の図に示すように、.pbix、.xlsx、または .csv ファイルからのメタデータおよびデータを利用して、単純に Power BI 上のリソースを更新します。 セマンティック モデルがデータ ソースからの最新のデータを保持することを保証するために、Power BI では、オンデマンド更新の中でデータ更新もトリガーします。 [スケジュール] タブに切り替えると、 [更新履歴] 上でこれを確認できます。
OneDrive または SharePoint Online に接続されたセマンティック モデルに対して OneDrive の更新を有効にした状態で、スケジュール ベースでのデータ更新を実行したい場合は、Power BI によるデータ更新が OneDrive の更新の後に実行されるように、確実にスケジュールを構成してください。 たとえば、毎夜午前 1 時に OneDrive または SharePoint Online 内のソース ファイルを更新するために独自のサービスまたはプロセスを作成した場合、Power BI がデータ更新の開始前に OneDrive の更新を完了できるだけの十分な時間を取れるように、スケジュールされた更新を午前 2 時 30 分に構成できます。
クエリ キャッシュの更新
セマンティック モデルが Premium 容量にあるなら、次のスクリーンショットに示すように、クエリ キャッシュを有効にすることで、関連するレポートとダッシュボードのパフォーマンスを向上させることができる場合があります。 クエリ キャッシュにより、Premium 容量はそのローカル キャッシュ サービスを使用してクエリ結果を維持するよう指示され、基になるデータ ソースによってそれらの結果が計算されることが回避されます。 詳しくは、「Power BI Premium でのクエリのキャッシュ」をご覧ください。
しかし、データ更新の後は、以前にキャッシュされたクエリ結果は無効になってしまいます。 Power BI では、キャッシュされたこれらの結果を破棄して、再構築する必要があります。 このため、1 日に 48 回など、頻繁に更新されるセマンティック モデルに関連付けられたレポートおよびダッシュボードでは、クエリ キャッシュによるメリットはあまり得られない可能性があります。
レポート ビジュアルの更新
この更新プロセスは、Analysis Services へのライブ接続にしか該当しないため、重要度は低くなります。 これらの接続の場合、レポートを再度表示するときに Power BI が Analysis Services の表形式モデルを照会する必要がないように、Power BI ではレポート ビジュアルの最新状態をキャッシュします。 レポート フィルターを変更するなど、レポートを操作した場合、Power BI では表形式モデルを照会して、レポート ビジュアルを自動的に更新します。 レポートに古いデータが表示されていると思われる場合は、次のスクリーンショットに示されるように、レポートの [更新] ボタンを選択してすべてのレポート ビジュアルの更新をトリガーすることもできます。
ピン留めされたビジュアルのみが更新され、ピン留めされたライブ ページは更新されません。 ピン留めされたライブ ページを更新するには、ブラウザーの [更新] ボタンを使用します。
データ インフラストラクチャの依存関係を確認する
ストレージ モードに関係なく、基になるデータ ソースがアクセス可能でない限り、データ更新を成功させることはできません。 主なデータ アクセスのシナリオとして、次の 3 つがあります。
- セマンティック モデルがオンプレミスに存在するデータ ソースを使用する。
- セマンティック モデルがクラウド内のデータ ソースを使用する。
- セマンティック モデルがオンプレミスおよびクラウド ソースの両方からのデータを使用する。
オンプレミス データソースへの接続
セマンティック モデルが、直接ネットワーク接続では Power BI からアクセスできないデータ ソースを使用している場合は、更新スケジュールを有効にしたり、オンデマンドによるデータ更新を実行したりできるように、事前にこのセマンティック モデルに対してゲートウェイ接続を構成しておく必要があります。 データ ゲートウェイとその仕組みの詳細については、「オンプレミス データ ゲートウェイとは?」を参照してください
次のようなオプションがあります。
- エンタープライズ データ ゲートウェイと必要なデータ ソース定義を選択する。
- 個人用データ ゲートウェイをデプロイする。
エンタープライズ データ ゲートウェイの使用
Microsoft では、個人用ゲートウェイではなくエンタープライズ データ ゲートウェイを使用して、オンプレミス データ ソースにセマンティック モデルを接続することを推奨しています。 確実にゲートウェイが正しく構成されるようにしてください。つまり、ゲートウェイでは、最新の更新情報と必要なすべてのデータ ソース定義を保持している必要があります。 データ ソース定義は、接続エンドポイント、認証モード、資格情報など、指定されたソースへの接続情報を Power BI に提供します。 ゲートウェイ上のデータ ソースの管理の詳細については、「データ ソースの管理 - インポートとスケジュールされた更新」を参照してください。
ゲートウェイ管理者になっている場合、セマンティック モデルをエンタープライズ ゲートウェイに接続することは、比較的簡単です。 管理者権限があれば、速やかにゲートウェイを更新し、必要に応じて不足するデータ ソースを追加できます。 実際に、セマンティック モデルの設定ページから直接、不足しているデータ ソースをゲートウェイに追加できます。 次のスクリーンショットに示すように、トグル ボタンを展開してデータ ソースを表示し、 [ゲートウェイに追加] リンクを選択します。 一方、ゲートウェイ管理者でない場合は、ゲートウェイ管理者に問い合わせて、必要なデータ ソース定義を追加する必要があります。
Note
ゲートウェイ管理者だけがデータ ソースをゲートウェイに追加できます。 また、データ ソースを使用するアクセス許可を持つユーザーの一覧に、ゲートウェイ管理者があなたのユーザー アカウントを追加していることを確認します。 [セマンティック モデルの設定] ページでは、使用するアクセス許可を与えられているデータ ソースに一致するものを持つエンタープライズ ゲートウェイのみを選択できます。
データ ソースに適切なデータ ソースの定義をマップすることを確認します。 上記のスクリーン ショットに示すように、ゲートウェイの管理者は、それぞれ別の資格情報を持つ同じデータ ソースに接続する単一のゲートウェイで複数の定義を作成できます。 例で示したとおり、販売部署のセマンティック モデルの所有者は AdventureWorksProducts 販売データ ソースの定義を選択し、サポート部門のセマンティック モデルの所有者は、セマンティック モデルを AdventureWorksProducts サポートのデータ ソースの定義にマップします。 データ ソースの定義の名前が直感的でない場合は、ゲートウェイの管理者に、どの定義を選択するべきかお問い合わせください。
Note
セマンティック モデルでは、1 つのゲートウェイ接続のみを使用できます。 言い換えると、複数のゲートウェイ接続にわたってオンプレミス データ ソースにアクセスすることはできません。 したがって、必要なすべてのデータ ソース定義を必ず同じゲートウェイに追加してください。
個人用データ ゲートウェイを展開する
エンタープライズ データ ゲートウェイにアクセスできず、またセマンティック モデルを管理する唯一のユーザーであるために他のユーザーとデータ ソースを共有する必要がない場合は、個人用モードでデータ ゲートウェイを展開できます。 [ゲートウェイ接続] セクション内で、 [個人用ゲートウェイがインストールされていません] の下にある [今すぐインストール] を選択します。 個人用データ ゲートウェイには、「Power BI での個人用ゲートウェイの使用」に記載されているように、いくつかの制限があります。
エンタープライズ データ ゲートウェイとは異なり、個人用ゲートウェイにはデータ ソース定義を追加する必要はありません。 代わりに、次のスクリーンショットに示すように、セマンティック モデルの設定にある [データ ソースの資格情報] セクションを使用して、データ ソースの構成を管理します。
クラウド データ ソースへのアクセス
Azure SQL DB などのクラウド データ ソースを使用するセマンティック モデルでは、Power BI がソースへの直接ネットワーク接続を確立できる場合、データ ゲートウェイを必要としません。 したがって、セマンティック モデルの設定にある [データ ソースの資格情報] セクションを使用して、これらのデータ ソースの構成を管理できます。 次のスクリーンショットに示すように、ゲートウェイ接続を構成する必要はありません。
Note
セマンティック モデルが存在するワークスペースに関係なく、各ユーザーは、所有するすべてのセマンティック モデルについて、資格情報のセットをデータソースごとに 1 つだけ持つことができます。 また、各セマンティック モデルの所有者は 1 人だけです。 自分がセマンティック モデルの所有者ではないセマンティック モデルの資格情報を更新したい場合は、まずセマンティック モデルの設定ページ上の [引き継ぎ] ボタンをクリックして、セマンティック モデルを引き継ぐ必要があります。
同一ソース クエリでのオンプレミスとクラウド ソースへのアクセス
1 つのセマンティック モデルでは複数のソースからデータを取得でき、これらのソースをオンプレミスまたはクラウド内に配置しておくことが可能です。 しかし、前述したように、1 つのセマンティック モデルでは単一のゲートウェイ接続しか使用できません。 クラウド データ ソースでは必ずしもゲートウェイを必要としないものの、単一のマッシュアップ クエリ内で 1 つのセマンティック モデルからオンプレミスとクラウド ソースの両方に接続する場合には、ゲートウェイが必要になります。 このシナリオでは、クラウド データ ソースの場合でも、Power BI においてゲートウェイを使用する必要があります。 次の図は、このようなセマンティック モデルがデータ ソースにアクセスする仕組みを示しています。
Note
セマンティック モデルが別個のマッシュアップ クエリを使用してオンプレミスとクラウド ソースに接続している場合、Power BI は、オンプレミス ソースにアクセスするにはゲートウェイ接続を使用し、クラウド ソースにアクセスするには直接ネットワーク接続を使用します。 1 つのマッシュアップ クエリにおいて、オンプレミスとクラウドのソースからデータをマージまたはアペンドする場合は、Power BI では、クラウド ソースに対してもゲートウェイ接続に切り替えます。
Power BI のセマンティック モデルは Power Query に依存して、ソース データにアクセスして取得します。 次のマッシュアップは、オンプレミス ソースとクラウド ソースからデータをマージする基本例を示しています。
Let
OnPremSource = Sql.Database("on-premises-db", "AdventureWorks"),
CloudSource = Sql.Databases("cloudsql.database.windows.net", "AdventureWorks"),
TableData1 = OnPremSource{[Schema="Sales",Item="Customer"]}[Data],
TableData2 = CloudSource {[Schema="Sales",Item="Customer"]}[Data],
MergedData = Table.NestedJoin(TableData1, {"BusinessEntityID"}, TableData2, {"BusinessEntityID"}, "MergedData", JoinKind.Inner)
in
MergedData
オンプレミスおよびクラウド ソースからのデータのマージまたはアペンドをサポートするようにデータ ゲートウェイを構成するには、2 つのオプションがあります。
- オンプレミス データ ソースだけでなく、クラウド ソース用のデータ ソース定義をデータ ゲートウェイに追加します。
- [Allow user's cloud data sources to refresh through this gateway cluster](このゲートウェイ クラスターを利用してユーザーのクラウド データ ソースを更新することを許可します) のチェックボックスをオンにします。
上記のスクリーンショットに示すように、[ゲートウェイ構成のこのゲートウェイ クラスターを利用してユーザーのクラウド データ ソースを更新することを許可する] のチェックボックスをオンにした場合、Power BI ではセマンティック モデルの設定にある [データソースの資格情報] 下でユーザーがクラウド ソース用に定義した構成を使用できます。 これにより、ゲートウェイ構成のオーバーヘッドを低減できます。 一方で、お使いのゲートウェイによって確立された接続を介して、より詳細な制御を行いたい場合は、このチェックボックスをオンにしてはいけません。 この場合、サポート対象にするすべてのクラウド ソース用の明示的なデータ ソース定義を、お使いのゲートウェイに追加する必要があります。 また、チェックボックスを有効にした状態で、クラウド ソース用の明示的なデータ ソース定義をゲートウェイに追加することも可能です。 この場合、ゲートウェイでは、一致するすべてのソースに対してデータ ソース定義を使用します。
クエリ パラメーターの構成
Power Query を使用して作成したマッシュアップまたは M クエリでは、簡単な手順からパラメーター化されたコンストラクトまで、複雑さに違いが生じる場合があります。 データベース内の指定されたテーブルにアクセスするために SchemaName および TableName という 2 つのパラメーターを使用する小規模なサンプル マッシュアップ クエリを、次に示します。
let
Source = Sql.Database("SqlServer01", "AdventureWorks"),
TableData = Source{[Schema=SchemaName,Item=TableName]}[Data]
in
TableData
Note
クエリ パラメータは、Import モードのセマンティック モデルに対してのみ、サポートされています。 DirectQuery/LiveConnect モードでは、クエリ パラメーターの定義をサポートしていません。
パラメーター化されたセマンティック モデルが正しいデータに確実にアクセスできるようにするには、セマンティック モデルの設定でマッシュアップ クエリ パラメーターを構成する必要があります。 また、Power BI REST API を使用して、プログラムによってパラメータ―を更新することもできます。 次のスクリーンショットは、上記のマッシュアップ クエリを使用するセマンティック モデルに対してクエリ パラメータを構成するためのユーザー インターフェイスを示しています。
更新と動的データ ソース
"動的データ ソース" は、Power Query でクエリが実行されるまで、接続に必要な情報の一部またはすべてを決定できないデータ ソースです。これは、データがコードで生成されるか別のデータ ソースから返されるためです。 この例としては、SQL Server データベースのインスタンス名とデータベース、CSV ファイルのパス、Web サービスの URL などがあります。
ほとんどの場合、動的データ ソースを使用する Power BI セマンティック モデルを Power BI サービスで更新することはできません。 ただし、Power BI サービスで動的データ ソースを最新の情報に更新できる例外がいくつかあります。たとえば、Web. Contents M 関数で RelativePath およびクエリ オプションを使用する場合などです。 Power Query パラメーターを参照するクエリを更新することもできます。
動的データ ソースを更新できるかどうかを判断するには、Power Query エディター内の [データ ソース設定] ダイアログを開いた後、[現在のファイル内のデータ ソース] を選択します。 表示されたウィンドウで、次の画像に示された警告メッセージを探します。
Note
手動で作成したクエリのため、一部のデータ ソースが一覧に表示されない可能性があります。
この警告が [データ ソース設定] ダイアログ内に表示されている場合は、Power BI サービス内で更新できない動的データ ソースが存在します。
重要
動的 M クエリ パラメーターを使用したデータ ソースの切り替えも、Power BI サービスではサポートされていません。
スケジュールされた更新の構成
Power BI とデータ ソース間での接続の確立は、データ更新の構成の中でも圧倒的に困難な作業です。 それ以外の手順は比較的簡単であり、更新スケジュールの設定や更新失敗の通知の有効化などがあります。 ステップバイステップの手順については、攻略ガイドの「スケジュールされた更新の構成」を参照してください。
更新スケジュールの設定
[更新] セクションでは、セマンティック モデルを更新する頻度と時間帯を定義します。 前述のように、セマンティック モデルが共有された容量上にある場合は 1 日に最大 8 時間の枠を、Power BI Premium 上では 48 時間の枠を構成できます。 次のスクリーンショットは、12 時間間隔の更新スケジュールを示したものです。
更新スケジュールを構成すると、上記のスクリーンショットに示すように、セマンティック モデルの設定ページ上で次回の更新時刻が通知されます。 ゲートウェイとデータ ソースの構成をテストする場合など、データの更新をより早く行いたい場合は、セマンティック モデルの設定ページ上の [今すぐ更新] オプションを使用することで、オンデマンド更新を実行します。 オンデマンド更新は、次にスケジュールされている更新時間には影響しません。
ヒント
Power BI には、月次更新間隔オプションはありません。 ただし、次の Power BI ブログ記事で説明されているように、Power Automate を使用して、毎月発生するカスタム更新間隔を作成できます。
また、構成された更新時刻は、スケジュールされた次のプロセスが Power BI によって開始される正確な時刻になるとは限らない点に注意してください。 Power BI は、スケジュールされた更新をベスト エフォート ベースで開始します。 スケジュールされた時間枠の 15 分以内に更新を開始することを目標としますが、サービスが必要なリソースを迅速に割り当てることができない場合、最大で 1 時間の遅延が生じる可能性があります。
Note
連続で 4 回失敗した後、あるいは、資格情報が無効または期限切れの場合など、構成の更新が必要になる回復不能なエラーをサービスが検出した場合に、Power BI では更新スケジュールを非アクティブ化します。 連続エラーのしきい値を変更することはできません。
更新失敗の通知の取得
Power BI では既定で、更新の問題が発生した場合に、セマンティック モデルの所有者がすみやかに対応できるように、メール経由で所有者に更新エラー通知を送信します。 所有者がモバイル デバイス上に Power BI アプリを持っている場合は、そこにも失敗通知が送信されます。 また、Power BI では、連続するエラーが原因でサービスによってスケジュールされた更新が無効にされた場合にも、メール通知を送信します。 Microsoft では、[更新失敗に関する通知を電子メールでセマンティック モデル所有者に送信する] を有効のままにしておくことをおすすめします。
また、[更新に失敗したときにこれらの連絡先に電子メールを送信する] ボックスを使用し、スケジュールされた更新の失敗の通知を受け取る追加の受信者を指定することもお勧めします。 セマンティック モデルの所有者と同様に、指定された受信者には、メールとモバイル アプリへのプッシュ通知で更新エラー通知が送信されます。 指定される受信者として、あなたの休暇中にセマンティック モデルを担当する同僚や、あなたの部署や組織の更新の問題を処理するサポート チームのメール エイリアスなどが該当する可能性があります。 セマンティック モデルの所有者に加えて更新エラー通知を他のユーザーに送信することで、問題が確実に把握されてすみやかに対処されるようになります。
Note
モバイル アプリへのプッシュ通知では、グループ エイリアスはサポートされていません。
Power BI では、更新失敗時だけでなく、非アクティブ状態が原因でサービスがスケジュールされた更新を一時停止した場合にも、通知を送信することに注意してください。 2 か月後、セマンティック モデルに基づいて構築されたダッシュボードまたはレポートにユーザーがアクセスしなかった場合、Power BI はセマンティック モデルを非アクティブと見なします。 このような場合、Power BI では、サービスによってセマンティック モデルに対する更新スケジュールが一時停止にされたことを示すメール メッセージをセマンティック モデル所有者に送信します。 次のスクリーンショットに、このような通知の例を示します。
スケジュールされた更新を再開するには、このセマンティック モデルを使用して構築されたレポートまたはダッシュボードにアクセスするか、[今すぐ更新] オプションを使用して手動でセマンティック モデルを更新します。
Note
外部ユーザーへの更新通知の送信はサポートされていません。 [更新に失敗したときにこれらのユーザーに電子メールを送信する] ボックスに指定した受信者は、Microsoft Entra テナントにアカウントを持っている必要があります。 この制限は、セマンティック モデルの更新とデータフローの更新の両方に適用されます。
更新の状態と履歴のチェック
失敗の通知以外にも、更新エラーについて定期的にセマンティック モデルをチェックすることをお勧めします。 簡単な方法は、ワークスペース内のセマンティック モデルの一覧を表示することです。 エラーのあるセマンティック モデルには、小さな警告アイコンが表示されます。 次のスクリーンショットに示すように、警告アイコンを選択して追加情報を取得します。 特定の更新エラーのトラブルシューティングの詳細については、「更新のトラブルシューティング シナリオ」を参照してください。
警告アイコンによって現在のセマンティック モデルの問題が示されますが、時には更新履歴をチェックすることもお勧めします。 名前からもわかるように、更新履歴では、過去の同期サイクルの成功や失敗の状態を確認できます。 たとえば、ゲートウェイ管理者が、有効期限が切れた一連のデータベース資格情報を更新したかもしれません。 次のスクリーンショットに示すように、更新履歴には、影響を受けた更新が再稼働を開始した時刻が示されます。
Note
セマンティック モデルの設定には、更新履歴を表示するためのリンクがあります。 また、Power BI REST API を使用して、プログラムによって更新履歴を取得することも可能です。 カスタム ソリューションを使用して、複数のセマンティック モデルの更新履歴を一元的な方法で監視することができます。
ページの自動更新
自動ページ更新はレポート ページ レベルで機能し、レポート作成者は、ページが使用されているときにのみアクティブなページ上のビジュアルの更新間隔を設定できます。 ページの自動更新は、DirectQuery データ ソースでのみ使用できます。 最小更新間隔は、レポートが発行されているワークスペースの種類と、Premium ワークスペースの容量の管理者設定と埋め込まれたワークスペースによって変わります。
ページの自動更新の詳細については、ページの自動更新に関する記事を参照してください。
セマンティック モデルの更新履歴
Power BI セマンティック モデルの更新の試行は、常にスムーズに実行されるとは限らず、想定以上に時間がかかる場合もあります。 [更新履歴] ページを使用すると、想定通りに更新が行われなかった理由を診断できます。
Power BI では、更新エラーが発生した場合、セマンティック モデルの更新が複数回自動的に試行されます。 更新履歴アクティビティに関する分析情報がないと、更新に想定以上の時間がかかっているだけのように見える場合があります。 [更新履歴] ページでは、失敗した試行を確認し、失敗の理由に関する分析情報を得ることができます。
次のスクリーンショットは、更新の失敗を示しています。Power BI が自動的に正常に完了しようとするたびに詳細が示されています。
先行する試行が失敗した後のどのタイミングで Power BI が成功したかを確認することもできます。次の画像では、3 回の失敗の後にやっと Power BIが成功したことがわかります。 成功したデータ更新と、クエリ キャッシュが同じインデックス番号を共有していることに注目してください。これは、4 回目の試行で両方が成功したことを示しています。
失敗の横にある [表示] リンクを選択すると、失敗した更新の試行に関する詳細情報を取得できます。これは、問題のトラブルシューティングに役立ちます。
さらに、Power BI 更新の試行はそれぞれ 2 つの操作に分けられます。
- データ – データをセマンティック モデルに読み込みます。
- クエリ キャッシュ – Premium クエリ キャッシュやダッシュボード タイルの更新。
次の画像は [更新履歴] がどのようにこれらの操作を分離し、それぞれに関する情報を提供するかを示しています。
ダッシュボード タイルやプレミアム キャッシュを使いすぎると、更新の実行時間が長くなる可能性があります。いずれも更新のたびに多数のクエリをキューに入れる可能性があるためです。 ダッシュボードの数を減らすか、キャッシュの自動更新設定を無効にして、クエリの数を減らすことができます。
データ フェーズとクエリ キャッシュのフェーズは互いに独立していますが、順番に実行されます。 最初にデータ更新が実行され、それが成功すると、クエリ キャッシュの更新が実行されます。 データ更新が失敗した場合、クエリの更新は開始されません。 データ更新は正常に実行できますが、クエリ キャッシュの更新は失敗する可能性があります。
XMLA エンドポイントを使用して行われた更新では、[更新履歴] ウィンドウに試行の詳細は表示されません。
更新の取り消し
セマンティック モデルの更新の停止は、ピーク時に大規模なセマンティック モデルの更新を停止する場合に便利です。 更新の取り消し機能を使用して、Premium、Premium Per User (PPU) または Power BI Embedded 容量に存在するセマンティック モデルの更新を停止します。
セマンティック モデルの更新をキャンセルするには、セマンティック モデルのワークスペースの共同作成者、メンバー、管理者のいずれかである必要があります。 セマンティック モデルの更新のキャンセルが機能するのは、Import モードまたは Composite モードを使用するセマンティック モデルでだけです。
Note
データマートの一部として作成されたセマンティック モデルはサポートされていません。
更新を開始するには、更新したいセマンティック モデルに移動した後、[今すぐ更新] を選択します。
更新を停止するには、以下の手順に従います。
更新中のセマンティック モデルに移動し、[更新のキャンセル] を選択します。
[更新の取り消し] ポップアップ ウィンドウで、[はい] を選択します。
ベスト プラクティス
セマンティック モデルの更新履歴を定期的にチェックすることは、レポートとダッシュボードにおいて最新のデータが利用されることを保証するために取り入れることができる、最も重要なベスト プラクティスの 1 つです。 問題を発見した場合には速やかに対応し、データ ソースの所有者とゲートウェイ管理者と共に対処します。
さらに、セマンティック モデルに対して信頼できるデータ更新プロセスを確立して維持するために、次の推奨事項について検討します:
- 特にセマンティック モデルが Power BI Premium 上にある場合には、ビジー状態の時間を減らすように更新をスケジュールします。 セマンティック モデルの更新サイクルをより広範な時間枠にわたって分散させると、利用可能なリソースに高い負荷を強いる可能性があるピークを回避できます。 更新サイクルの開始の遅延は、リソース オーバーヘッドの指標になります。 Premium 容量が使い果たされると、Power BI では更新サイクルをスキップする可能性もあります。
- 更新に関する制限事項に常に留意してください。 ソース データが頻繁に変更される場合や、データ ボリュームがかなり大きい場合には、ソースでの負荷の上昇やクエリ パフォーマンスへの影響を許容できるのであれば、Import モードではなく DirectQuery/LiveConnect モードを使用することを検討してください。 Import モードのセマンティック モデルを絶えず更新することは避けてください。 「Power BI Desktop での DirectQuery の使用」で記述されているとおり、DirectQuery/LiveConnect モードには、応答データに対する 100 万行の上限やクエリ実行に対する 225 秒の応答時間の上限など、いくつかの制限事項があることにも注意する必要があります。 これらの制限事項によって、やはり Import モードを使用することが必要になる場合もあります。 データ ボリュームが大きい場合は、Power BI での集計を利用することを検討してください。
- セマンティック モデルの更新時間が、更新期間の上限を超過していないことを確認します。 Power BI Desktop を使用して更新期間をチェックしてください。 2 時間以上を要する場合は、セマンティック モデルを Power BI Premium に移行することを検討してください。 セマンティック モデルは、共有容量では更新できない可能性があります。 また、1 GB を超えたり、更新に数時間かかるセマンティック モデルには、増分更新を使用することも検討してください。
- レポートおよびダッシュボードで使用されるテーブルと列だけを含むように、セマンティック モデルを最適化します。 マッシュアップ クエリを最適化し、必要に応じて、動的データ ソース定義や高コストの DAX 計算を回避してください。 特に、メモリ消費量が高くオーバーヘッド処理があることから、テーブル内のすべての行をテストする DAX 関数は回避してください。
- Power BI において効率的なソース クエリを確実に生成できるように、Power BI Desktop と同じプライバシー設定を適用します。 Power BI Desktop ではプライバシー設定は公開されないことに留意してください。 セマンティック モデルの公開後、手動でデータ ソース定義の設定を再適用する必要があります。
- 特に行レベルのセキュリティ (RLS) を使用する場合には、ダッシュボード上のビジュアル数を制限します。 この記事で前述したように、ダッシュボード タイルの数が多くなり過ぎると、更新期間が大幅に増大する可能性があります。
- 信頼できるエンタープライズ データ ゲートウェイのデプロイを利用して、オンプレミス データ ソースにセマンティック モデルを接続します。 ゲートウェイが利用不可能や過負荷になるなどで、ゲートウェイ関連の更新失敗に気付いたら、ゲートウェイ管理者と共に、既存のクラスターにさらにゲートウェイを追加するか、新しいクラスターを展開して、対応を行います (スケールアップとスケールアウト)。
- ユーザー操作のたびにデータ ソースに対してクエリを実行する、スケジュールされた更新の間のデータ インポートが DirectQuery/LiveConnect セマンティック モデルを基にするレポートやダッシュボードのパフォーマンスに影響しないように、Import モードのセマンティック モデルと DirectQuery/LiveConnect セマンティック モデルに対しては別個のデータ ゲートウェイを使用します。
- Power BI からご自身の電子メール ボックスに更新失敗の通知を送信できることを確認します。 スパム フィルターによって、電子メール メッセージがブロックされたり、気付かないような別のフォルダーへ直ちに移動されたりする可能性があります。
関連するコンテンツ
その他の質問 Power BI コミュニティで質問してみてください。