Direct Lake

  • [アーティクル]

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

Direct Lake の機能ダイアグラム。

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

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

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

Direct Lake では、行レベルのセキュリティとオブジェクト レベルのセキュリティもサポート されているため、ユーザーには表示するアクセス許可があるデータのみが表示されます。

前提条件

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

重要

新機能については、Direct Lake は、Microsoft Fabric (F) SKU でのみサポートされます。 既存のお客様は、引き続き Premium (P) SKU で Direct Lake を使用できますが、Fabric 容量 SKU に移行することをお勧めします。 Power BI Premium ライセンスの詳細については、ライセンスに関するお知らせを参照してください。

Lakehouse

Direct Lake を使う前に、サポートされている Microsoft Fabric 容量でホストされているワークスペース内で、1 つ以上の Delta テーブルを使って、lakehouse (またはWarehouse) をプロビジョニングする必要があります。 レイクハウスは、OneLake で Parquet 形式のファイルの格納場所を提供するために必要です。 レイクハウスは、Direct Lake モデルを作成するために Web モデリング機能を起動するためのアクセス ポイントも提供します。

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

SQL エンドポイント

レイクハウスのプロビジョニングの一環として、SQL クエリ用の SQL エンドポイントとレポート用の既定のモデルが作成され、レイクハウスに追加されるすべてのテーブルで更新されます。 Direct Lake モードでは、SQL エンドポイントのクエリは、OneLake からデータを直接読み込むときは実行されませんが、Direct Lake モデルが DirectQuery モードにシームレスにフォールバックする必要があるときは必要です (高度なセキュリティや、Direct Lake で読み取ることができないビューのような、特定の機能がデータ ソースで使われている場合など)。 Direct Lake モードでは、スキーマ関連とセキュリティ関連の情報を得るための SQL エンドポイントに対するクエリも実行されます。

データ ウェアハウス (data warehouse)

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

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 エンドポイント] 設定で [読み取り/書き込み] を選択します。

    Fabric 試用版容量に関する XMLA エンドポイントの読み取り/書き込み設定でのスクリーンショット。

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

Direct Lake モデルのメタデータ

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

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

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

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

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

SSMS の XMLA クエリのスクリーンショット。

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

フォールバック

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

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

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

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

Fabric SKU テーブルあたりの Parquet ファイル数 テーブルあたりの行グループ数 テーブルあたりの行数 (百万) ディスク/OneLake の最大モデル サイズ1 (GB) 最大メモリ (GB)
F2 1.000 1.000 300 10 3
F4 1.000 1.000 300 10 3
F8 1.000 1.000 300 10 3
F16 1.000 1.000 300 20 5
F32 1.000 1.000 300 40 10
F64/FT1/P1 5,000 5,000 1,500 無制限 25
F128/P2 5,000 5,000 3,000 無制限 50
F256/P3 5,000 5,000 6,000 無制限 100
F512/P4 10,000 10,000 12,000 無制限 200
F1024/P5 10,000 10,000 24,000 無制限 400
F2048 10,000 10,000 24,000 無制限 400

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

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

フォールバック動作

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

自動 - (既定値) データを効率的にメモリに読み込めない場合に、クエリが 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 データを最新の状態に保つ) を無効にします。

モデルの設定での Direct Lake 更新オプションのスクリーンショット。

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

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

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

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

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

OneLake セキュリティ アクセス許可 SQL アクセス許可 有効なアクセス許可
Allow なし Allow
なし Allow Allow
許可 拒否 拒否
なし 拒否 拒否

既知の問題と制限事項

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

  • Direct Lake セマンティック モデル テーブルは、1 つのレイクハウスまたはウェアハウスのテーブルとビューからのみ派生することができます。

  • 現在、Direct Lake テーブルは、同じモデル内の Import、DirectQuery、Dual などの他のテーブル型と混合することはできません。 複合モデルは、現在、サポートされていません。

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

  • 計算列と計算テーブルは、サポートされていません。

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

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

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

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

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

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

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

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

作業の開始

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

関連するコンテンツ