増分更新とリアルタイム データに関するトラブルシューティング
増分更新とリアルタイム データのソリューションの実装時には、2 つのフェーズがあります。1 つ目は Power BI Desktop でのパラメーターの構成、フィルター処理、およびポリシーの定義で、2 つ目はサービスでの最初のセマンティック モデル更新操作とその後の更新です。 この記事では、これらのフェーズごとのトラブルシューティングを個別に説明します。
Power BI サービスでテーブルをパーティション分割している場合、増分更新を行い、DirectQuery を使ったリアルタイム データの取得も行うテーブルは、ハイブリッド モードで動作するようになることに注意してください。つまり、インポート モードと DirectQuery モードの両方で動作します。 このような増分更新を行ったハイブリッド テーブルとのリレーションシップを持つすべてのテーブルでは、デュアル モードを使用する必要があります。これにより、パフォーマンスを低下させることなくインポート モードと DirectQuery モードで使用できるようになります。 さらに、データ ソースにクエリが再び送信されるのを避けるために、レポートの視覚化によって結果がキャッシュされ、テーブルで最新のデータ更新内容をリアル タイムで取得できなくなる場合があります。 最後のトラブルシューティング セクションでは、ハイブリッド モードに関するこれらの問題について説明します。
増分更新とリアルタイム データのトラブルシューティングを行う前に、モデルの増分更新とリアルタイム データに関するページと、「増分更新とリアルタイム データを構成する」の詳細な手順を確認してください。
Power BI Desktop での構成
増分更新とリアルタイム データを構成するときに発生する問題のほとんどは、クエリ フォールディングに関係があります。 モデルの増分更新の概要のサポートされているデータ ソースに関するページで説明されているように、データ ソースはクエリ フォールディングをサポートする必要があります。
問題: データの読み込みに時間がかかりすぎる
Power Query エディターで [適用] を選ぶと、データの読み込みに多大な時間とコンピューター リソースが必要になります。 可能性のあるいくつかの原因は、次のとおりです。
原因: データ型が一致しない
この問題はデータ型の不一致が原因の可能性があります。RangeStart と RangeEnd のパラメーターに必要なデータ型は Date/Time ですが、フィルターが適用されているテーブルの日付列が Date/Time データ型ではない場合、またはその逆の場合です。 パラメーターのデータ型とフィルター処理されたデータ列は両方とも Date/Time データ型である必要があり、形式は同じである必要があります。 そうでない場合、クエリを折りたたむことはできません。
解決方法: データ型を確認する
増分更新テーブルの日時列が Date/Time データ型であることを確認します。 テーブルに Date/Time データ型の列が含まれておらず、代わりに整数データ型を使用している場合は、RangeStart と RangeEnd のパラメーターの日時値を、データ ソース テーブルの整数の代理キーに一致するように変換する関数を作成できます。 詳細については、「増分更新を構成する」の「DateTime を整数型に変換する」を参照してください。
原因: データ ソースでクエリ フォールディングがサポートされていない
「モデルの増分更新とリアルタイム データ」の「必要条件」で説明されているように、増分更新は、クエリ フォールディングをサポートするデータ ソース用に設計されています。 サービスに発行する前に、Power BI Desktop でデータ ソースのクエリが折りたたまれることを確認してください。そうでないと、クエリ フォールディングの問題が大幅に悪化する可能性があります。 このアプローチは、増分更新ポリシーにリアルタイム データを含める場合に特に重要です。リアルタイム DirectQuery パーティションにはクエリ フォールディングが必要なためです。
解決方法: クエリを確認してテストする
ほとんどの場合は、[増分更新ポリシー] ダイアログに、データ ソースに対して実行するクエリがクエリ フォールディングをサポートしていないかどうかを示す警告が表示されます。 ただし、場合によっては、クエリ フォールディングが可能であることをさらに確認する必要があります。 可能な場合は、SQL Profiler などのツールを使用して、データ ソースに渡されるクエリを監視します。 RangeStart と RangeEnd に基づくフィルターを指定したクエリは、1 つのクエリで実行する必要があります。
RangeStart と RangeEnd のパラメーターで、数千を超える行が含まれない短い日時の期間を指定することもできます。 データ ソースからモデルへのフィルター処理されたデータの読み込みに時間がかかり、処理負荷が高い場合は、クエリが折りたたまれていない可能性があります。
クエリが折りたたまれていないと判断した場合は、「Power BI Desktop でのクエリ フォールディングのガイダンス」と Power Query のクエリ フォールディングに関するページを参照してください。何が、どのようにクエリ フォールディングを妨げている可能性があるのか、またはデータ ソースがクエリ フォールディングをサポートできるかどうかを特定するのにも役立ちます。
サービスでのセマンティック モデルの更新
サービスでの増分更新に関する問題のトラブルシューティングは、モデルが発行された容量の種類によって異なります。 Premium 容量のセマンティック モデルは、SQL Server Management Studio (SSMS) のようなツールを使用して、個々のパーティションを表示して選択的に更新することをサポートしています。 一方、Power BI Pro モデルでは、XMLA エンドポイントを使用したツールへのアクセスは提供していないため、増分更新の問題のトラブルシューティングには、もう少し試行錯誤が必要になる場合があります。
問題: 最初の更新がタイムアウトになった
共有容量の Power BI Pro モデルのスケジュールされた更新には、2 時間の時間制限があります。 Premium 容量のモデルの場合、この時間制限は 5 時間に延長されます。 データ ソース システムによって、クエリ結果のサイズ制限やクエリのタイムアウトが生じる場合もあります。
原因: データ ソースのクエリが折りたたまれていない
クエリ フォールディングに関する問題は、通常はサービスに発行する前に Power BI Desktop で特定できますが、モデル更新クエリが折りたたまれていないため、更新時間が長くなりすぎたり、クエリのマッシュアップ エンジンのリソースが使われたりする可能性があります。 この状況が発生するのは、クエリはモデル内のパーティションごとに作成されるためです。 クエリが折りたたまれておらず、データ ソースでデータがフィルター処理されていない場合、エンジンによりデータのフィルター処理が試みられます。
解決方法: クエリ フォールディングを確認する
データ ソースでトレース ツールを使用して、パーティションごとに渡されるクエリが、RangeStart および RangeEnd パラメーターに基づくフィルターが含まれている単一のクエリであることを確認します。 そうでない場合は、フィルター処理された少量のデータをモデルに読み込むときに、Power BI Desktop モデルでクエリ フォールディングが行われていることを確認します。 そうでない場合は、最初にモデルで修正し、(XMLA エンドポイントを使って) モデルに対してメタデータのみの更新を実行します。または、共有容量の Power BI Pro モデルの場合は、サービス内の不完全なモデルを削除して再発行してから、最初の更新操作を再試行します。
クエリが折りたたまれていないと判断した場合は、クエリ フォールディングを妨げている可能性のある原因を特定するために、「Power BI Desktop でのクエリ フォールディングのガイダンス」と Power Query のクエリ フォールディングに関するページを参照してください。
原因: パーティションに読み込まれたデータが大きすぎる
解決策: モデルのサイズを小さくする
多くの場合、タイムアウトは、モデルのパーティションに対してクエリを実行して読み込む必要があるデータの量が、容量によって課された時間制限を超えていることによって発生します。 モデルのサイズまたは複雑さを軽減するか、モデルをより細かく分けることを検討してください。
解決方法: 大規模なモデルのストレージ形式を有効にする
Premium 容量に発行されたモデルでは、モデルが 1 GB 以上に拡大する場合は、更新操作のパフォーマンスを向上させ、サービスでの最初の更新操作を実行する前に大規模なモデルのストレージ形式を有効にして、モデルが最大サイズの制限を超えないようにすることができます。 詳細については、「Power BI Premium の大規模なモデル (プレビュー)」を参照してください。
解決方法: ブートストラップの最初の更新
Premium 容量に発行されたモデルの場合は、最初の更新操作をブートストラップすることができます。 ブートストラップを使用すると、サービスでモデルのテーブルおよびパーティション オブジェクトを作成できますが、履歴データをパーティションに読み込んで処理することはできません。 詳細については、高度な増分更新に関するページの「最初の完全な更新でタイムアウトを回避する」を参照してください。
原因: データ ソースのクエリのタイムアウト
クエリは、データ ソースの既定の時間制限によって制限することができます。
解決方法: クエリ式の時間制限をオーバーライドする
多くのデータ ソースでは、クエリ式の時間制限のオーバーライドが許可されています。 詳細については、モデルの増分更新に関するページの「時間制限」を参照してください。
問題: 値が重複しているため更新が失敗する
原因: 投稿日が変更されている
更新操作では、モデルで更新されるのは、データ ソースで変更済みのデータのみです。 データは日付で分割されるため、投稿 (トランザクション) の日付は変更しないことをお勧めします。
日付が誤って変更された場合は、2 つの問題が発生する可能性があります。ユーザーが履歴データの一部の合計が変更されたこと (発生するはずのないこと) に気付くか、一意の値が実際には一意ではないことを示すエラーが更新中に返されます。
後者の場合は、増分更新が構成されたテーブルがもう 1 つのテーブル (1 の側) と 1:N の関係で使われ、一意の値を持つ必要がある場合に、これが発生する可能性があります。 特定の ID のデータが変更されると、その ID は別のパーティションに表示され、エンジンは値が一意でないことを検出します。
解決方法: 特定のパーティションを更新する
日付から過去のデータを変更するというビジネス ニーズがある場合、考えられる解決方法は、SSMS を使って、変更が行われた位置から現在の更新パーティションまでのすべてのパーティションを更新し、それによって関係の 1 の側を一意に保つことです。
問題: データが切り詰められている
原因: データ ソースのクエリ制限を超えている
Azure Data Explorer、Log Analytics、Application Insights などの一部のデータ ソースには、外部クエリに対して返すことができるデータに 64 MB (圧縮) の制限があります。 Azure Data Explorer では明示的なエラーが返されることがありますが、その他の Log Analytics や Application Insights などの場合、返されるデータは切り詰められています。
解決方法: より短い更新および保存期間を指定する
ポリシーにより短い更新および保存期間を指定します。 たとえば、1 年の更新期間を指定したときに、クエリ エラーが返されたり、返されたデータが切り詰められたりした場合は、更新期間を 12 "か月" にしてみてください。 現在の更新パーティションまたは更新と保存の期間に基づく履歴パーティションのクエリが、64 MB を超えるデータを返さないようにする必要があります。
問題: パーティション キーの競合が原因で更新が失敗する
原因: データ ソースの日付列の日付が更新されている
日付列のフィルターは、Power BI サービスで複数の期間の範囲にデータを動的にパーティション分割するために使用されます。 増分更新は、フィルター処理された日付列をソース システムでも更新するようには設計されていません。 更新は、実際の更新ではなく、挿入と削除として解釈されます。 削除が増分範囲ではなく履歴範囲で発生した場合は、ピックアップされません。これにより、パーティション キーの競合が原因でデータの更新に失敗する可能性があります。
サービスのハイブリッド モード (プレビュー)
Power BI でリアルタイム データを含む増分更新ポリシーが適用される場合、増分更新を行ったテーブルは、インポート モードと DirectQuery モードの両方で動作するハイブリッド テーブルに変更されます。 次のサンプル テーブルのパーティション一覧の末尾には、DirectQuery パーティションがあることがわかります。 DirectQuery パーティションの存在は、関連テーブルと、このテーブルに対するクエリを実行するレポートの視覚化に影響を与えます。
問題: クエリのパフォーマンスが低い
原因: 関連テーブルがデュアル モードではない
インポート モードと DirectQuery モードの両方で動作するハイブリッド テーブルでは、すべての関連テーブルをデュアル モードで動作させる必要があります。これにより、Power BI モデルに送信されたクエリのコンテキストに応じて、キャッシュあり、キャッシュなしのいずれかで機能できるようになります。 デュアル モードを使うと、Power BI ではモデル内の制限付きリレーションシップの数を減らし、効率的なデータ ソース クエリを生成してパフォーマンスを向上させることができます。 制限付きリレーションシップは、Power BI で必要以上のデータを取得する必要が生じるデータ ソースにはプッシュできません。 デュアル テーブルは DirectQuery テーブルとしてもインポート テーブルとしても機能するため、この状況は回避されます。
解決策: 関連テーブルをデュアル モードに変換する
増分更新ポリシーを構成する場合、Power BI Desktop では、[DirectQuery で最新データをリアルタイムで取得します (Premium のみ)] を選ぶと、関連テーブルをデュアル モードに切り替える通知が表示されます。 さらに、モデル ビューで既存のすべてのテーブル リレーションシップを確認してください。
現在 DirectQuery モードで動作しているテーブルは、デュアル モードに簡単に切り替わります。 テーブルのプロパティの [詳細設定] で、[ストレージ モード] リストボックスから [デュアル] を選択します。 ただし、現在インポート モードで動作しているテーブルには、手動の作業が必要です。 デュアル テーブルの機能的な制約は、DirectQuery テーブルのものと同じです。 そのため、Power BI Desktop ではインポート テーブルを変換できません。デュアル モードでは使用できないその他の機能に依存している可能性があるためです。 これらのテーブルは、DirectQuery モードで手動で再作成してから、デュアル モードに変換する必要があります。 詳細については、「Power BI Desktop でストレージ モードを管理する」を参照してください。
問題: レポートの視覚化に最新のデータが表示されない
原因: パフォーマンスの向上とバック エンドの負荷の軽減のため、Power BI でクエリ結果がキャッシュされる
Power BI では既定でクエリ結果がキャッシュされるため、レポートの視覚化のクエリを、それが DirectQuery に基づいても迅速に処理できます。 不要なデータ ソース クエリを回避することでパフォーマンスが向上し、データ ソースの負荷が軽減されますが、ソースでの最新のデータ変更内容が結果に含まれないことも意味する可能性があります。
解決策: ページの自動更新を構成する
ソースから最新のデータ変更内容をフェッチし続けるには、Power BI サービスでレポートに対してページの自動更新を構成します。 ページの自動更新は、5 秒や 10 分などの一定の間隔で実行できます。 その特定の間隔に達すると、そのページ内のすべてのビジュアルから更新クエリがデータ ソースに送信され、それに応じて更新されます。 または、データの変更の検出に基づいて、ページ上の視覚エフェクトを更新することもできます。 このアプローチには変更検出メジャーが必要です。これはその後、Power BI でデータ ソースの変更をポーリングするために使用します。 変更の検出は、Premium 容量に含まれるワークスペースでのみサポートされています。 詳細については、「Power BI でのページの自動更新」を参照してください。