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 またはサービス プリンシパルを使用して認証できます。
Note
Microsoft Entra 認証のみサポートしています。 そのため、Direct Lake セマンティック モデルでは、Basic 認証はサポートされていません。
OAuth 2.0
OAuth 2.0 を使用する場合は、Microsoft Entra ユーザー アカウントで認証できます。 ユーザー アカウントには、SQL 分析エンドポイントのテーブルとビュー、およびスキーマ メタデータのクエリを実行するアクセス許可が必要です。
特定のユーザー アカウントを使用することは、推奨される方法ではありません。 これは、パスワードの変更やユーザー アカウントの削除 (従業員が組織を離れた場合など) にセマンティック モデルのクエリが失敗するためです。
サービス プリンシパル
サービス プリンシパルを使用した認証は、特定のユーザー アカウントに依存しないので、おすすめの方法です。 セキュリティ プリンシパルには、SQL 分析エンドポイントのテーブルとビュー、およびスキーマ メタデータに対してクエリを実行するアクセス許可が必要です。
継続性のために、サービス プリンシパルの資格情報はシークレット/証明書のローテーションによって管理できます。
Note
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 セマンティック モデルを使用または管理できるように、ユーザーにアクセス許可を付与する必要があります。 つまり、レポート コンシューマーには読み取りアクセス許可が必要であり、レポート作成者にはビルド アクセス許可が必要です。 セマンティック モデルのアクセス許可は、直接割り当てたり、ワークスペース ロールを介して暗黙的に取得したりできます。 セマンティック モデルの設定 (更新やその他の構成) を管理するには、セマンティック モデルの所有者である必要があります。
クラウド接続の設定、およびユーザーがレイクハウスまたはウェアハウス SQL 分析エンドポイントに対してクエリを実行する必要があるかどうかに応じて、(このセクションの表で説明している) 他のアクセス許可を付与する必要がある場合があります。
Note
特に、ユーザーは OneLake でデータを読み取るアクセス許可を必要としません。 これは、差分テーブルと関連する Parquet ファイルを読み取るために必要なアクセス許可をセマンティック モデルに付与するためです (メモリに列データに読み込むため)。 セマンティック モデルには、SQL 分析エンドポイントを定期的に読み取り、クエリを実行するユーザー (または固定 ID) がアクセスできるデータを決定するためのアクセス許可チェックを実行するために必要なアクセス許可もあります。
次のシナリオとアクセス許可の要件を検討してください。
シナリオ | 必要なアクセス許可 | Comments |
---|---|---|
ユーザーはレポートを表示できます | • レポートの読み取りアクセス許可とセマンティック モデルの読み取りアクセス許可を付与します。 • クラウド接続が SSO を使用する場合は、少なくともレイクハウスまたはウェアハウスの読み取りアクセス許可を付与します。 |
レポートは、セマンティック モデルと同じワークスペースに属している必要はありません。 詳細については、「読み取りのみのコンシューマー向けの戦略」をご覧ください。 |
ユーザーはレポートを作成できます | • セマンティック モデルのビルド アクセス許可を付与します。 • クラウド接続で SSO が使用されている場合は、少なくともレイクハウスまたはウェアハウスの読み取りアクセス許可を付与します。 |
詳細については、「コンテンツ作成者向けの戦略」を参照してください。 |
ユーザーはセマンティック モデルにクエリを実行できますが、レイクハウスまたは SQL 分析エンドポイントのクエリは拒否されます | • レイクハウスや倉庫に対するアクセス許可を与えないでください。 | クラウド接続で固定 ID が使用されている場合にのみ適しています。 |
ユーザーはセマンティック モデルと SQL 分析エンドポイントに対してクエリを実行できますレイクハウスのクエリは拒否されます | • 読み取りアクセス許可と ReadData アクセス許可をレイクハウスまたはウェアハウスに付与します。 | 重要: SQL 分析エンドポイントに送信されたクエリは、セマンティック モデルによって適用されるデータ アクセス許可をバイパスします。 |
更新設定を含むセマンティック モデルを管理する | • セマンティック モデルの所有権が必要です。 | 詳細については、「セマンティック モデルの所有権」を参照してください。 |
重要
セマンティック モデルとレポートを運用環境にリリースする前に、常にアクセス許可を十分にテストする必要があります。
詳しくは、「セマンティック モデルのアクセス許可」をご覧ください。
Direct Lake セマンティック モデルを更新する
Direct Lake セマンティック モデルを更新すると、フレーミング操作が行われます。 更新操作をトリガーできます:
- 手動で、Fabric ポータルでオンデマンド更新を実行するか、SQL Server Management Studio (SSMS) のスクリプトから表形式モデル スクリプト言語 (TMSL) の更新コマンドを実行するか、XMLA エンドポイント経由で接続されるサード パーティ ツールを使用します。
- Fabric ポータルで更新スケジュールを設定して自動的に。
- 基になるデルタ テーブルで変更が検出されたときに自動的に—詳細については、(次に解説する) 「自動更新」を参照してください。
- プログラムで Power BI REST API または TOM を使用して更新をトリガー。 抽出、変換、読み込み (ETL) プロセスの最後の手順として、プログラムによる更新をトリガーできます。
自動更新
Direct Lake テーブルの自動更新を行う、Direct Lake データを最新の状態に維持する という名前のセマンティック モデル レベルの設定があります。 既定では有効になっています。 これにより、OneLake のデータ変更が Direct Lake セマンティック モデルに自動的に反映されます。 この設定は、Fabric ポータルのセマンティック モデル設定の「更新」セクションで使用できます。
この設定を有効にすると、基になる差分テーブルのデータ変更が検出されるたびに、セマンティック モデルによってフレーミング操作が実行されます。 フレーミング操作は常に、データ変更が検出されるテーブルのみに固有です。
特に、小規模または中規模のセマンティック モデルがある場合は、この設定をオンのままにすることをお勧めします。 これは、待機時間の短いレポート要件があり、差分テーブルが定期的に変更される場合に特に便利です。
状況によっては、自動更新を無効にすることが必要な場合があります。 たとえば、セマンティック モデルのコンシューマーに新しいデータを公開する前に、データ準備ジョブまたは ETL プロセスの完了を許可する必要がある場合があります。 無効にすると、プログラムによる方法 (前述) を使用して更新をトリガーできます。
Note
更新中に回復できないエラーが発生すると、Power BI は自動更新を中断します。 回復不可能なエラーは、たとえば、複数回試行した後に更新が失敗した場合に発生する可能性があります。 そのため、セマンティック モデルを正常に更新できることを確認します。 Power BI は、後続のオンデマンド更新がエラーなしで完了すると、自動更新を自動的に再開します。
キャッシュをウォームアップする
Direct Lake セマンティック モデルの更新操作では、すべての常駐列がメモリから削除される可能性があります。 つまり、Direct Lake セマンティック モデルの更新後の最初のクエリでは、列がメモリに読み込まれるので、多少の遅延が発生する可能性があります。 遅延は、大量のデータがある場合にのみ顕著になる可能性があります。
このような遅延を回避するには、プログラムでセマンティック モデルにクエリを送信してキャッシュをウォーム アップすることを検討してください。 クエリを送信する便利な方法は、セマンティック リンクを使用することです。 この操作は、更新操作が完了した直後に行う必要があります。
重要
キャッシュのウォーム アップは、遅延が許容できない場合にのみ意味があります。 他の容量ワークロードに負荷がかかる可能性があるメモリに不必要にデータを読み込んだり、調整したり、優先順位の低下を招いたりしないように注意してください。
Direct Lake の動作プロパティを設定する
DirectLakeBehavior
プロパティを設定することで、Direct Lake セマンティック モデルのフォールバックを制御できます。 以下に設定できます:
- Automatic: (既定) 必要なデータをメモリに効率的に読み込まれない場合は DirectQuery モードにフォールバックします。
- DirectLakeOnly: すべてのクエリで Direct Lake ストレージ モードのみが使用されます。 DirectQuery モードへのフォールバックが無効になっています。 データをメモリに読み込めない場合は、エラーが返されます。
- DirectQueryOnly: すべてのクエリで DirectQuery モードのみが使用されます。 この設定を使用してフォールバック パフォーマンスをテストします。たとえば、接続されたレポートでクエリのパフォーマンスを確認できます。
プロパティは、Web モデリング エクスペリエンスで設定するか、テーブル オブジェクト モデル (TOM) またはテーブル モデル スクリプト言語 (TMSL) を使用して設定できます。
ヒント
Direct Lake ストレージ モードでのみクエリを処理する場合は、DirectQuery フォールバックを無効にすることを検討してください。 DirectQuery にフォールバックしない場合は、フォールバックを無効にすることをお勧めします。 また、Direct Lake セマンティック モデルのクエリ処理を分析して、フォールバックが発生してるか、またどの程度発生しているかを特定したい場合にも役立ちます。
Direct Lake セマンティック モデルを監視する
Direct Lake セマンティック モデルを監視して、レポート ビジュアル DAX クエリのパフォーマンスを判断したり、DirectQuery モードにフォールバックするタイミングを判断したりできます。
パフォーマンス アナライザー、SQL Server Profiler、Azure Log Analytics、または DAX Studio などのオープンソースのコミュニティ ツールを使用できます。
パフォーマンス アナライザー
Power BI Desktop でパフォーマンス アナライザーを使用して、クエリの実行結果として開始されたレポート要素の更新に必要な処理時間を記録できます。 監視結果に Direct クエリ メトリックが表示される場合は、DAX クエリが DirectQuery モードで処理されたことを意味します。 そのメトリックがなかった場合、DAX クエリは Direct Lake モードで処理されていました。
詳細については、「パフォーマンス アナライザーを使用した分析」を参照してください。
SQL Server プロファイラー
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 セマンティック モデルに関連付けられているテレメトリ データを収集、分析、操作できます。 これは Azure Monitor 内のサービスであり、Power BI はアクティビティ ログを保存するために使用します。
詳細については、「Power BI での Azure Log Analytics の使用」を参照してください。