Direct Lake

Direct Lake モードは、Power BI で非常に大きなデータ ボリュームを分析するためのセマンティック モデル機能です。 Direct Lake は、Lakehouse またはデータハウス エンドポイントのクエリを実行する必要も、Power BI モデルにデータをインポートまたは複製する必要もなしに、データ レイクから Parquet 形式のファイルを直接読み込むことに基づいています。 Direct Lake は、データをレイクから Power BI エンジンに直接読み込み、分析できる状態にする高速パスです。 次の図は、クラシック インポートおよび DirectQuery モードと、Direct Lake モードを比較したものです。

DirectQuery モードでは、Power BI エンジンはソースでデータのクエリを実行します。これは遅い場合がありますが、インポート モードのようにデータをコピーする必要はありません。 データ ソースでの変更は、すぐにクエリ結果に反映されます。

一方、インポート モードでは、データはキャッシュされて、DAX および MDX レポート クエリ用に最適化され、SQL やその他のタイプのクエリを変換してデータ ソースに渡す必要がないため、パフォーマンスが向上する可能性があります。 ただし、Power BI エンジンは、更新時に最初に新規データをモデルにコピーする必要があります。 ソースでの変更は、すべて "次の" モデル更新でのみ取得されます。

Direct Lake モードでは、データは OneLake から直接読み込まれるため、インポートする必要がなくなります。 DirectQuery とは異なり、DAX や MDX から他のデータベース システム上の他のクエリ言語やクエリ実行への変換は行われず、インポート モードと同程度のパフォーマンスが得られます。 明示的なインポート プロセスがないため、データ ソースでのすべての変更をその発生時に取得でき、DirectQuery モードとインポート モードの両方の利点が組み合わされ、欠点は回避されます。 Direct Lake モードは、とても大きいモデルや、データ ソースで頻繁に更新されるモデルを分析する場合に最適な選択となる可能性があります。

Direct Lake は Power BI の行レベルのセキュリティとオブジェクト レベルのセキュリティもサポートしているため、ユーザーは表示権限のあるデータのみを表示できます。

前提条件

Direct Lake は、Microsoft Premium (P) SKU と Microsoft Fabric (F) SKU でのみサポートされます。

Lakehouse

Direct Lake を使う前に、サポートされている Microsoft Fabric 容量でホストされているワークスペース内で、ひとつ以上の Delta テーブルを使って、Lakehouse (またはWarehouse) をプロビジョニングする必要があります。 Lakehouse は、OneLake で Parquet 形式のファイルの保存場所を提供するために必要です。

Lakehouse をプロビジョニングし、その Lakehouse に Delta テーブルを作成して、Lakehouse 用の基本モデルを作成する方法については、「Direct Lake 用の Lakehouse を作成する」を参照してください。

SQL 分析エンドポイントとデータ ウェアハウス

Lakehouse のプロビジョニングの一環として、SQL クエリ用の SQL 分析エンドポイントが作成され、Lakehouse に追加されたテーブルで更新されます。 Direct Lake モードでは、OneLake から直接データを読み込むときに SQL 分析エンドポイントをクエリしませんが、データ ソースが高度なセキュリティや、Direct Lake 経由では読み取れず SQL エンドポイントを利用する必要があるビューなどの特定の機能を使用する場合など、Direct Lake モデルをシームレスに DirectQuery モードにフォールバックする必要がある場合は、このモードが必要になります。 Direct Lake モードでは、スキーマおよびセキュリティ関連の情報についても、SQL エンドポイントを定期的に照会します。

SQL 分析エンドポイントを備えたLakehouse の代わりに、SQL ステートメントまたはデータ パイプラインを使用してウェアハウスをプロビジョニングし、テーブルを追加することもできます。 スタンドアロンのデータ ウェアハウスをプロビジョニングする手順は、Lakehouse の手順とほぼ同じです。

デフォルトの Power BI セマンティック モデル

また、ウェアハウスと SQL 分析エンドポイントは、Direct Lake モードで デフォルトの Power BI セマンティック モデル を作成します。 このデフォルトのセマンティック モデルは、ウェアハウスまたは SQL エンドポイント内でのみ編集でき、追加の制限があります。 デフォルトの Power BI セマンティック モデルドキュメントを参照してください。 この Direct Lake のドキュメントは、Direct Lake モードのデフォルト以外の Power BI セマンティック モデルを対象としたものです。

Direct Lake モードで Power BI セマンティック モデルを作成する

Direct Lake モードの Power BI セマンティック モデルは、Lakehouse またはウェアハウスに作成されます。

Lakehouse で新規 Power BI セマンティック モデルをクリックして、Direct Lake モードで Power BI セマンティック モデルを作成します。

ウェアハウスまたは SQL 分析エンドポイントで、 Reporting リボンを選択し、 新規 Power BI セマンティック モデル を選択して、Direct Lake モードで Power BI セマンティック モデルを作成します。

その後、ブラウザーでセマンティック モデルを編集 することで、リレーションシップ、メジャー、計算グループ、書式指定文字列、行レベルのセキュリティなどを追加し、テーブルと列の名前を変更できます。 後でワークスペースのコンテキスト メニューを使用してセマンティック モデルを編集し、 データ モデル開きます。

XMLA エンドポイントを使用したモデル書き込みのサポート

Direct Lake モデルは、SQL Server Management Studio (19.1 以降) などのツールと、Tabular Editor や DAX Studio などの最新バージョンの外部 BI ツールを使用して、XMLA エンドポイントを介した書き込み操作をサポートします。 XMLA エンドポイントを使用したモデル書き込み操作では、次がサポートされます。

• Direct Lake モデルのメタデータのカスタマイズ、マージ、スクリプト作成、デバッグ、テスト。

• Azure DevOps と GitHub を使用したソースとバージョン管理、継続的インテグレーションと継続的デプロイ (CI/CD)。

• PowerShell と REST API を使用した Direct Lake モデルの更新や変更の適用などの自動化タスク。

XMLA アプリケーションを使って作成された Direct Lake テーブルは、最初、アプリケーションが更新コマンドを発行するまで、未処理の状態になります。 未処理のテーブルは DirectQuery モードにフォールバックします。 新規セマンティック モデルを作成するときは、セマンティック モデルを更新してテーブルを処理するようにしてください。

XMLA 読み取り/書き込みを有効にする

XMLA エンドポイントを介して Direct Lake モデルに対して書き込み操作を実行する前に、容量に対して XMLA の読み取りと書き込みを有効にする必要があります。

Fabric 試用版の容量の場合、試用版ユーザーは XMLA の読み取り/書き込みを有効にするために必要な管理者特権を持っています。

1. [管理ポータル] で [容量の設定] を選択します。

2. [試用版] タブを選択します。

3. 容量名に試用版とユーザー名を含む容量を選択します。

4. [Power BI ワークロード] を展開し、[XMLA エンドポイン���] 設定で [読み取り/書き込み] を選択します。

   

XMLA エンドポイントの設定は、容量に割り当てられたすべてのワークスペースとモデルに適用されることに注意してください。

Direct Lake モデルのメタデータ

XMLA エンドポイントを介してスタンドアロン Direct Lake モデルに接続する場合、そのメタデータは他のモデルと似ています。 ただし、Direct Lake モデルには次の違いがあります。

• データベース オブジェクトの compatibilityLevel プロパティは 1604 以上です。

• Direct Lake パーティションの Mode プロパティは directLake に設定されます。

• Direct Lake パーティションでは、共有式を使用してデータ ソースを定義します。 式はLakehouse またはウェアハウスの SQL エンドポイントを指します。 Direct Lake は SQL エンドポイントを使ってスキーマとセキュリティの情報を検出しますが、データを Delta テーブルから直接読み込みます (何らかの理由で Direct Lake が DirectQuery モードにフォールバックする必要がある場合を除きます)。

SSMS での XMLA クエリの例を次に示します。

XMLA エンドポイントを介したツールのサポートについて詳しくは、「XMLA エンドポイントを使用したセマンティック モデル接続」を参照してください。

フォールバック

Direct Lake モードの Power BI セマンティック モデルでは、OneLake から Delta テーブルを直接読み取ります。 ただし、Direct Lake モデルに対する DAX クエリが SKU の制限を超えたり、Direct Lake モードをサポートしていない機能 (ウェアハウスの SQL ビューなど) を使用したりした場合、そのクエリは DirectQuery モードにフォールバックすることがあります。 DirectQuery モードでは、クエリは SQL を使用してLakehouse またはウェアハウスの SQL エンドポイントから結果を取得するため、クエリのパフォーマンスに影響を与える可能性があります。 純粋な Direct Lake モードのみで DAX クエリを処理したい場合は、DirectQuery モードへのフォールバックを無効にできます。 DirectQuery にフォールバックする必要がない場合は、フォールバックを無効にすることをお勧めします。 これは、Direct Lake モデルのクエリ処理を分析して、フォールバックが発生するかどうか、またその頻度を特定する場合にも役立ちます。 DirectQuery モードの詳細については、Power BI のセマンティック モデル モードに関する記事を参照してください。

"ガードレール" は、Direct Lake モードのリソース制限を定義します。この制限を超えると、DAX クエリを処理するために DirectQuery モードへのフォールバックが必要になります。 Delta テーブルの Parquet ファイルと行グループの数を確認する方法について詳しくは、「Delta テーブルのプロパティ リファレンス」を参照してください。

Direct Lake セマンティック モデルの場合、最大メモリは、ページインできるデータの量に対するメモリ リソースの上限を表します。 これは、実際にはガードレールとはいえません。それを超えても DirectQuery へのフォールバックが発生しないためです。しかし、OneLake データからのモデル データのページインとページアウトを引き起こすほどデータ量が大きい場合は、パフォーマンスに影響を与えるおそれがあります。

次の表は、リソースのガードレールと最大メモリの両方を示しています。

1 - これを超えた場合、ディスク/Onelake の最大モデル サイズにより、クエリごとに評価される他のガードレールとは異なり、モデルに対するすべてのクエリが DirectQuery にフォールバックします。

Fabric の SKU に応じて、追加の容量ユニットとクエリあたりの最大メモリの制限も Direct Lake モデルに適用されます。 詳しくは、「容量と SKU」を参照してください。

フォールバック動作

Direct Lake モデルには、DirectLakeBehavior プロパティが含まれており、これには以下の 三つのオプションがあります。

自動 - (デフォルト値) データを効率的にメモリに読み込めない場合に、クエリが DirectQuery モードにフォールバックすることを指定します。

DirectLakeOnly - すべてのクエリが Direct Lake モードのみを使用することを指定します。 DirectQuery モードへのフォールバックは無効になります。 データをメモリに読み込めない場合は、エラーが返されます。 この設定を使用して、エラーが返されることを強制し、DAX クエリがデータをメモリに読み込むのに失敗するかを判断します。

DirectQueryOnly - すべてのクエリが DirectQuery モードのみを使用することを指定します。 この設定を使用してフォールバック パフォーマンスをテストします。

DirectLakeBehavior プロパティは、表形式オブジェクト モデル (TOM) または表形式モデル スクリプト言語 (TMSL) を使用して構成できます。

次の例は、すべてのクエリが Direct Lake モードのみを使用することを指定しています。

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

これは、セマンティック モデルのプロパティでブラウザーでセマンティック モデルを編集するときにも設定できます。 データ ペインのモデル タブでセマンティック モデルを選択します。

クエリ処理を分析する

データ ソースに対するレポートの視覚化の DAX クエリが、Direct Lake モードを使って最良のパフォーマンスを提供しているか、DirectQuery モードにフォールバックするかを判断するには、Power BI Desktop、SQL Server Profiler、または他のサードパーテ�� ツールでパフォーマンス アナライザーを使ってクエリを分析できます。 詳しくは、Direct Lake モデルのクエリ処理の分析に関する記事を参照してください。

更新

デフォルトでは、OneLake のデータに対する変更は、Direct Lake モデルに自動的に反映されます。 この動作を変更するには、モデルの設定で [Keep your Direct Lake data up to date] (Direct Lake データを最新の状態に保つ) を無効にします。

たとえば、モデルのコンシューマーに新規データを公開する前に、データ準備ジョブの完了を許可する必要がある場合は無効にしてください。 無効にすると、更新を手動で呼び出すか、更新 API を使用して呼び出すことができます。 Direct Lake モデルの更新の呼び出しは、モデルで最新バージョンの Delta Lake テーブルのメタデータが分析され、OneLake の最新ファイルを参照するように更新される、低コストの操作です。

更新中に、回復不可能なエラーが発生したときは、Power BI が、Direct Lake テーブルの自動更新を一時停止する場合があるため、セマンティック モデルを正常に更新できることを確認してください。 後続のユーザー呼び出し更新がエラーなしで完了すると、Power BI は自動更新を自動的に再開します。

シングルサインオン（SSO）がデフォルトで有効になっています。

デフォルトでは、Direct Lake モデルは Microsoft Entra シングル サインオン (SSO) に依存して Fabric Lakehouse と Warehouse のデータ ソースにアクセスし、現在モデルと対話しているユーザーの ID を使用します。 次のスクリーンショットに示すように、[ゲートウェイとクラウド接続] セクションを展開して、Direct Lake モデルの設定で構成をチェックできます。 Direct Lake モデルでは、Lakehouse または Warehouse に直接アクセスできるため、明示的なデータ接続は必要ありません。SSO は、保存されている接続資格情報が不要になります。

また、保存されている資格情報を使用する場合には、Lakehouse または Warehouse データ ソースを共有可能なクラウド接続 (SCC) に明示的にバインドし、そのデータ ソース接続の SSO を無効にすることもできます。 データ ソースを明示的にバインドするには、[ゲートウェイとクラウド接続] セクションの マップから SCC を選択します。 [接続の作成] を選択して新規接続を作成し、手順に従って接続名を指定することもできます。 次に、新規接続の認証方法として OAuth 2.0 を選択し、目的の資格情報を入力し、 シングル サインオンチェック ボックスをオフにして、作成した新規 SCC 接続に Lakehouse または Warehouse データ ソースをバインドします。

デフォルト値: シングル サインオン (Entra ID) 接続構成では Direct Lake モデルの構成が簡略化されますが、既に Lakehouse または Warehouse データ ソースへの個人用クラウド接続 (PCC) がある場合は、Direct Lake モデルは一致する PCC に自動的にバインドされ、データ ソースに対して既に定義した接続設定がすぐに適用されます。 Direct Lake モデルの接続構成を確認して、モデルが正しい設定で Fabric データ ソースにアクセスすることを確認することが必要です。

セマンティック モデルでは、Direct Lake、Import、DirectQuery モードの Fabric Lakehouses および Warehouse に対して デフォルト: シングル サインオン (Entra ID) 接続構成を使用できます。 他のすべてのデータ ソースには、明示的に定義されたデータ接続が必要となります。

階層型データ アクセスのセキュリティ

Lakehouse とウェアハウスの上に作成された Direct Lake モデルは、T-SQL エンドポイントを通してアクセス許可チェックを実行して、データにアクセスしようとしている ID が必要なデータ アクセス許可を持っているかを判断することで、Lakehouse とウェアハウスがサポートする階層型セキュリティ モデルに従います。 デフォルトでは、Direct Lake モデルはシングル サインオン (SSO) を使用するため、対話ユーザーの有効なアクセス許可によって、そのユーザーがデータへのアクセスを許可されるか拒否されるかが決まります。 固定 ID を使用するように Direct Lake モデルが構成されている場合、固定 ID の有効なアクセス許可によって、セマンティック モデルとやり取りしているユーザーがデータにアクセスできるかが決まります。 T-SQL エンドポイントは、OneLake セキュリティと SQL のアクセス許可の組み合わせに基づいて、Direct Lake モデルに対して許可または拒否を返します。

たとえば、ウェアハウス管理��は、ユーザーが OneLake セキュリティ アクセス許可を持っていない場合でも、ユーザーがテーブルからの読み取りを行えるように、テーブルに対する SELECT アクセス許可をユーザーに付与できます。 ユーザーがLakehouse /ウェアハウス レベルで承認されました。 逆に、ウェアハウス管理者は、テーブルへのユーザーの読み取りアクセスを "拒否" することもできます。 その場合、ユーザーが OneLake セキュリティの読み取りアクセス許可を持っている場合でも、ユーザーはそのテーブルからの読み取りを行うことはできません。 "拒否" ステートメントは、付与されたすべての OneLake セキュリティまたは SQL のアクセス許可より優先されます。 ユーザーが OneLake セキュリティと SQL のアクセス許可の組み合わせによって持つことができる有効なアクセス許可については、次の表を参照してください。

既知の問題と制限事項

• 設計上、Lakehouse またはウェアハウスのテーブルから派生したセマンティック モデル内のテーブルのみが Direct Lake モードをサポートします。 モデル内のテーブルは、Lakehouse /ウェアハウスの SQL ビューから派生することができますが、これらのテーブルを使用するクエリは DirectQuery モードにフォールバックします。

• Direct Lake セマンティック モデル テーブルは、ひとつのLakehouse またはウェアハウスのテーブルとビューからのみ派生することができます。 1 つの Lakehouse に、他の Lakehouse から追加されたショートカットを含めることができます。

• レベルのセキュリティを使用して、ウェアハウス (Lakehouse SQL 分析エンドポイントを含む) 内のテーブルに対するクエリは、DirectQuery モードにフォールバックします。

• 現在、Direct Lake テーブルは、同じモデル内の Import、DirectQuery、Dual などの他のテーブル型と混合することはできません。 Power BI セマンティック モデルの複合モデル は、ソースとして Direct Lake ストレージ モードで Power BI セマンティック モデルを使用できます。

• DateTime リレーションシップは Direct Lake モデルでサポートされていません。 日付リレーションシップがサポートされています。

• 計算列と計算テーブルは、サポートされていません。 計算グループとフィールド パラメーターがサポートされています。

• 高精度の 十進数や money 型などの一部のデータ型は、サポートされていない場合があります。

• Direct Lake テーブルでは、複合 Delta テーブルの列型はサポートされていません。 バイナリおよび Guid のセマンティック型もサポートされていません。 これらのデータ型は、文字列またはその他のサポートされているデータ型に変換する必要があります。

• テーブル リレーションシップでは、キー列のデータ型が一致している必要があります。 主キー列には一意の値が含まれている必要があります。 重複する主キー値が検出された場合、DAX クエリは失敗します。

• 文字列の列値の長さは、32,764 Unicode 文字に制限されています。

• 浮動小数点値 "NaN" (非数値) は、Direct Lake モデルでサポートされていません。

• 埋め込みエンティティに依存する Power BI Embedded シナリオはまだサポートされていません。

• 検証は Direct Lake モデルに対して限定されます。 ユーザーの選択は正しいと見なされ、クエリではリレーションシップに対するカーディナリティとクロス フィルターの選択 (つまり、日付テーブルで選択された日付列) は検証されません。

• [更新履歴] の [Direct Lake] タブには、Direct Lake 関連の更新エラーのみが表示されます。 正常な更新は現在省略されています。

作業の開始

組織内で Direct Lake ソリューションの使用を開始する最善の方法は、Lakehouse を作成し、その中に Delta テーブルを作成してから、Microsoft Fabric ワークスペースでそのLakehouse の基本的なセマンティック モデルを作成することです。 詳しくは、「Direct Lake 用のLakehouse を作成する」を参照してください。

関連するコンテンツ

• Direct Lake 用のLakehouse を作成する
• Direct Lake セマンティック モデルのクエリ処理を分析する