次の方法で共有

Direct Lake セマンティック モデルの管理

  • [アーティクル]

この記事では、Direct Lake セマンティック モデルの管理に関連する設計トピックについて説明します。

パブリケーション後のタスク

レポートの準備ができた Direct Lake セマンティック モデルを最初に発行した後は、発行後のいくつかのタスクをすぐに完了する必要があります。 これらのタスクは、セマンティック モデルのライフサイクル中にいつでも調整することもできます。

必要に応じて、データ検出 を設定して、レポート作成者がメタデータを読み取ることができるようにすることもできます。これにより、OneLake データ ハブ内のデータを検出 し、そのデータへのアクセスを要求できます。 セマンティック モデルを承認 (認定または昇格) して、使用に適した品質データを表していることを伝えることもできます。

クラウド接続を設定する

Direct Lake セマンティック モデルでは、クラウド接続を使用して SQL 分析エンドポイントに接続します。 これにより、ソース データへのアクセスが可能になります。これは、OneLake の Parquet ファイル (列データのメモリへの読み込みを伴う Direct Lake ストレージ モード) または SQL 分析エンドポイント (クエリが DirectQuery モードにフォールバックする場合)。

既定のクラウド接続

Direct Lake セマンティック モデルを作成すると、既定のクラウド接続が使用されます。 シングル サインオン (SSO) が利用されます。つまり、セマンティック モデル (多くの場合、レポート ユーザー) にクエリを実行する ID を使用して、SQL 分析エンドポイント データのクエリを実行します。

共有可能なクラウド接続

必要に応じて、共有可能なクラウド接続 (SCC) を作成して、固定 ID を使用してデータ ソースへの接続を作成できます。 企業のお客様が組織のデータ ストアを保護するのに役立ちます。 IT 部門は、資格情報の管理、SCC の作成、および一元化されたアクセス管理のために目的の作成者と共有できます。

固定 ID を設定するには、「Direct Lake セマンティック モデルの固定 ID を指定する」を参照してください。

認証

固定 ID は、OAuth 2.0 またはサービス プリンシパル 使用して認証できます。

手記

Microsoft Entra 認証のみがサポートされています。 そのため、Direct Lake セマンティック モデルでは、基本 認証はサポートされていません。

OAuth 2.0

OAuth 2.0 を使用する場合は、Microsoft Entra ユーザー アカウントで認証できます。 ユーザー アカウントには、SQL 分析エンドポイントのテーブルとビュー、およびスキーマ メタデータのクエリを実行するアクセス許可が必要です。

特定のユーザー アカウントを使用することは、推奨される方法ではありません。 これは、パスワードの変更やユーザー アカウントの削除 (従業員が組織を離れた場合など) にセマンティック モデルのクエリが失敗するためです。

サービス プリンシパル

サービス プリンシパルを使用した認証は、特定のユーザー アカウントに依存しないため、推奨される方法です。 セキュリティ プリンシパルには、SQL 分析エンドポイントのテーブルとビュー、およびスキーマ メタデータに対してクエリを実行するアクセス許可が必要です。

継続性のために、サービス プリンシパルの資格情報はシークレット/証明書のローテーションによって管理できます。

手記

Fabric テナント設定ではサービス プリンシパルを許可する必要があり、サービス プリンシパルは宣言されたセキュリティ グループに属している必要があります。

シングル サインオン

共有可能なクラウド接続を作成すると、既定で [シングル サインオン] チェック ボックスがオフになります。 これは、固定 ID を使用する場合の正しいセットアップです。

セマンティック モデルにクエリを実行する ID で SQL 分析エンドポイントのクエリを実行する場合は、SSO を有効にすることができます。 この構成では、Direct Lake セマンティック モデルは固定 ID を使用してモデルを更新し、ユーザー ID を使用してデータを照会します。

固定 ID を使用する場合は、固定 ID が更新とクエリの両方に使用されるように SSO を無効にするのが一般的ですが、これを行う技術的な要件はありません。

クラウド接続に関連する推奨プラクティスを次に示します。

  • すべてのユーザーがデータにアクセスできる (アクセス許可がある) 場合、共有クラウド接続を作成する必要はありません。 代わりに、既定のクラウド接続設定を使用できます。 この場合、モデルにクエリを実行するユーザーの ID が使用されます。クエリが DirectQuery モードにフォールバックする必要があります。
  • 固定 ID を使用してソース データのクエリを実行する場合は、共有クラウド接続を作成します。 これは、セマンティック モデルに対してクエリを実行するユーザーに、レイクハウスまたはウェアハウスを読み取るアクセス許可が付与されていないことが原因である可能性があります。 このアプローチは、セマンティック モデルが RLS を適用する場合に特に関連します。
  • 固定 ID を使用する場合は、サービス プリンシパルの オプションを使用します。これは、より安全で信頼性が高いためです。 これは、単一のユーザー アカウントまたはそのアクセス許可に依存せず、パスワードを変更したり、組織を離れたりしてもメンテナンス (および中断) は必要ないためです。
  • 異なるユーザーがデータのサブセットのみにアクセスするように制限する必要がある場合は、実行可能な場合は、セマンティック モデル レイヤーでのみ RLS を適用します。 そうすることで、ユーザーは高パフォーマンスのメモリ内クエリの恩恵を受けることができます。
  • 可能であれば、レポート ビジュアルでエラーが発生するため、OLS と CLS は避けてください。 エラーが発生すると、ユーザーの混乱や懸念が生じます。 集計可能な列の場合は、CLS ではなく特定の条件で BLANK を返すメジャーを作成することを検討してください (可能な場合)。

セキュリティ ロールのメンバーシップを管理する

Direct Lake セマンティック モデル 行レベル セキュリティ (RLS)を適用する場合は、セキュリティ ロールに割り当てられているメンバーの管理が必要になる場合があります。 詳細については、「モデルのセキュリティを管理する」を参照してください。

Fabric 項目のアクセス許可を設定する

Direct Lake セマンティック モデルは、階層型セキュリティ モデルに準拠します。 SQL 分析エンドポイントを介してアクセス許可チェックを実行し、データへのアクセスを試みる ID に必要なデータ アクセス許可があるかどうかを判断します。

Direct Lake セマンティック モデルを使用または管理できるように、ユーザーにアクセス許可を付与する必要があります。 レポートコンシューマーには読み取り アクセス許可が必要であり、レポート作成者にはビルド アクセス許可が必要です。 セマンティック モデルのアクセス許可 直接 割り当てることも、ワークスペース ロール を介して暗黙的に取得することもできます。 セマンティック モデルの設定 (更新やその他の構成) を管理するには、セマンティック モデルの所有者 である必要があります。

クラウド接続の設定、およびユーザーが lakehouse またはウェアハウス SQL 分析エンドポイントに対してクエリを実行する必要があるかどうかに応じて、他のアクセス許可を付与する必要がある場合があります (このセクションの表で説明します)。

手記

特に、ユーザーは OneLake でデータを読み取るアクセス許可を必要としません。 これは、Fabric では Delta テーブルと関連する Parquet ファイルを読み取るために必要なアクセス許可をセマンティック モデルに付与するためです (メモリに列データを読み込むため)。 セマンティック モデルには、SQL 分析エンドポイントを定期的に読み取り、クエリを実行するユーザー (または固定 ID) がアクセスできるデータを決定するためのアクセス許可チェックを実行するために必要なアクセス許可もあります。

次のシナリオとアクセス許可の要件を検討してください。

シナリオ 必要なアクセス許可 コメント
ユーザーはレポートを表示できます • レポートの 読み取り アクセス許可を付与し、セマンティック モデルの 読み取り アクセス許可を付与します。
• クラウド接続で SSO が使用されている場合は、少なくともレイクハウスまたはウェアハウスの Read アクセス許可を付与します。		 レポートは、セマンティック モデルと同じワークスペースに属している必要はありません。 詳細については、「読み取り専用コンシューマーに関する戦略」をご覧ください。
ユーザーはレポートを作成できます • セマンティック モデル ビルド アクセス許可を付与します。
• クラウド接続で SSO が使用されている場合は、少なくともレイクハウスまたはウェアハウスの Read アクセス許可を付与します。		 詳細については、「コンテンツ作成者向けの 戦略」を参照してください。
ユーザーはセマンティック モデルにクエリを実行できますが、lakehouse または SQL 分析エンドポイントのクエリは拒否されます • レイクハウスや倉庫に対する許可を与えないでください。 クラウド接続で固定 ID が使用されている場合にのみ適しています。
ユーザーはセマンティック モデルと SQL 分析エンドポイントに対してクエリを実行できますが、lakehouse のクエリは拒否されます • Read および ReadData アクセス許可をレイクハウスまたはウェアハウスに付与します。 重要な: SQL 分析エンドポイントに送信されたクエリは、セマンティック モデルによって適用されるデータ アクセス許可をバイパスします。
更新設定を含むセマンティック モデルを管理する • セマンティック モデルの所有権が必要です。 詳細については、「セマンティック モデルの所有権 参照してください。

重要

セマンティック モデルとレポートを運用環境にリリースする前に、常にアクセス許可を十分にテストする必要があります。

詳しくは、セマンティックモデルのアクセス許可を参照してください。

Direct Lake セマンティック モデルを更新する

Direct Lake セマンティック モデルを更新すると、フレーミング 操作が行われます。 更新操作をトリガーできます。

  • 手動で、ファブリック ポータルで オンデマンド更新 を実行するか、テーブル モデル スクリプト言語 (TMSL) 更新コマンド を SQL Server Management Studio (SSMS) のスクリプトから実行するか、XMLA エンドポイント経由で接続するサード パーティ製ツールを使用して実行します。
  • 自動的に、Fabric ポータルで 更新スケジュール を設定することで実行されます。
  • 基になるDeltaテーブルで変更が検出されると、自動的に更新が行われます。詳細については、「自動更新 」（次に説明する）を参照してください。
  • プログラムで Power BI REST API または TOM を使用して更新をトリガーします。 抽出、変換、読み込み (ETL) プロセスの最後の手順として、プログラムによる更新をトリガーできます。

自動更新

Direct Lake テーブルの自動更新を実行する Direct Lake データを最新の状態に保つ という名前のセマンティック モデル レベルの設定があります。 既定では有効になっています。 これにより、OneLake のデータ変更が Direct Lake セマンティック モデルに自動的に反映されます。 この設定は、ファブリック ポータルのセマンティック モデル設定の 更新 セクションで使用できます。

この設定を有効にすると、基になる Delta テーブルのデータ変更が検出されるたびに、セマンティック モデルによってフレーミング操作が実行されます。 フレーミング操作は常に、データ変更が検出されるテーブルのみに固有です。

特に、小規模または中規模のセマンティック モデルがある場合は、この設定をオンのままにすることをお勧めします。 これは、待機時間の短いレポート要件があり、差分テーブルが定期的に変更される場合に特に便利です。

状況によっては、自動更新を無効にすることが必要な場合があります。 たとえば、セマンティック モデルのコンシューマーに新しいデータを公開する前に、データ準備ジョブまたは ETL プロセスの完了を許可する必要がある場合があります。 無効にすると、プログラムによる方法 (前述) を使用して更新をトリガーできます。

手記

更新中に 回復不可能なエラー が発生すると、Power BI は自動更新を中断します。 回復不可能なエラーは、たとえば、複数回試行した後に更新が失敗した場合に発生する可能性があります。 そのため、セマンティック モデルを正常に更新できることを確認します。 後続のオンデマンド更新がエラーなしで完了すると、Power BI は自動更新を自動的に再開します。

キャッシュをウォームアップする

Direct Lake セマンティック モデルの更新操作では、すべての常駐列がメモリから削除される可能性があります。 つまり、Direct Lake セマンティック モデルの更新後の最初のクエリでは、列がメモリに読み込まれるので、多少の遅延が発生する可能性があります。 遅延は、大量のデータがある場合にのみ顕著になる可能性があります。

このような遅延を回避するには、セマンティック モデルにクエリ を送信 プログラムによってキャッシュをウォーム化することを検討してください。 クエリを送信する便利な方法は、セマンティック リンク 使用することです。 この操作は、更新操作が完了した直後に行う必要があります。

重要

キャッシュのウォーム化は、遅延が許容できない場合にのみ意味があります。 他の容量ワークロードに負荷がかかり、制限されたり優先度が下げられたりする可能性があるメモリに不必要にデータを読み込まないように注意してください。

Direct Lake の動作プロパティを設定する

Direct Lake セマンティック モデルのフォールバックを制御するには、その DirectLakeBehavior プロパティを設定します。 次のように設定できます。

  • 自動: (既定) 必要なデータを効率的にメモリに読み込めない場合は、クエリで DirectQuery モードにフォールバックします。
  • DirectLakeOnly: すべてのクエリで Direct Lake ストレージ モードのみが使用されます。 DirectQuery モードへのフォールバックが無効になっています。 データをメモリに読み込めなかった場合は、エラーが返されます。
  • DirectQueryOnly: すべてのクエリで DirectQuery モードのみが使用されます。 この設定を使用してフォールバック パフォーマンスをテストします。たとえば、接続されたレポートでクエリのパフォーマンスを確認できます。

プロパティは、Web モデリング エクスペリエンスで設定するか、テーブル オブジェクト モデル (TOM) または テーブル モデル スクリプト言語 (TMSL)を使用して設定できます。

ヒント

Direct Lake ストレージ モードでのみクエリを処理する場合は、DirectQuery フォールバックを無効にすることを検討してください。 DirectQuery にフォールバックしない場合は、フォールバックを無効にすることをお勧めします。 また、Direct Lake セマンティック モデルのクエリ処理を分析して、フォールバックが発生したかどうかを特定する場合にも役立ちます。

Direct Lake セマンティック モデルの監視

Direct Lake セマンティック モデルを監視して、レポートビジュアル DAX クエリのパフォーマンスを判断したり、DirectQuery モードにフォールバックするタイミングを判断したりできます。

Performance Analyzer、SQL Server Profiler、Azure Log Analytics、または DAX Studio などのオープンソースのコミュニティ ツールを使用できます。

パフォーマンスアナライザー

Power BI Desktop Performance Analyzer を使用すると、クエリを実行するユーザー操作の結果として開始されたレポート要素の更新に必要な処理時間を記録できます。 監視結果に Direct クエリ メトリックが表示される場合は、DAX クエリが DirectQuery モードで処理されたことを意味します。 そのメトリックがない場合、DAX クエリは Direct Lake モードで処理されました。

詳細については、「Performance Analyzerを使用した分析」を参照してください。

SQL Server Profiler

SQL Server Profiler を使用して、クエリ イベントをトレースしてクエリのパフォーマンスに関する詳細を取得できます。 SQL Server Management Studio (SSMS)と共にインストールされます。 開始する前に、最新バージョンの SSMS がインストールされていることを確認してください。

詳細については、「SQL Server Profilerを使用した分析」を参照してください。

重要

一般に、Direct Lake ストレージ モードでは、DirectQuery モードへのフォールバックが必要でない限り、高速なクエリ パフォーマンスが提供されます。 DirectQuery モードへのフォールバックはクエリのパフォーマンスに影響を与える可能性があるため、Direct Lake セマンティック モデルのクエリ処理を分析して、フォールバックが発生したかどうか、頻度、および理由を特定することが重要です。

Azure Log Analytics

Azure Log Analytics を使用して、Direct Lake セマンティック モデルに関連付けられているテレメトリ データを収集、分析、および操作できます。 これは、アクティビティ ログを保存するために Power BI が使用する、Azure Monitor内のサービスです。

詳細については、「Power BI での Azure Log Analytics の使用の」を参照してください。

関連コンテンツ