次の方法で共有

Direct Lake セマンティック モデルのストレージについて

  • [アーティクル]

この記事では、Direct Lake ストレージ 概念について説明します。 Delta テーブルと Parquet ファイルについて説明します。 また、Direct Lake セマンティック モデル用に Delta テーブルを最適化する方法と、それらを維持して信頼性の高い高速なクエリ パフォーマンスを実現する方法についても説明します。

Delta テーブル

デルタ テーブルは OneLake に存在します。 ファイル ベースのデータを行と列に整理し、ノートブック、Kusto、レイクハウス、ウェアハウスなどの Microsoft Fabric コンピューティング エンジンで使用できます。 デルタ テーブルのクエリは、データ分析式 (DAX)、多次元式 (MDX)、T-SQL (Transact-SQL)、Spark SQL、さらには Python を使用して実行できます。

Note

Delta または Delta Lake はオープン ソースのストレージ形式です。 つまり、Fabric は、他のツールやベンダーによって作成された Delta テーブルにもクエリを実行できます。

Delta テーブルは、データを Parquet ファイルに格納します。これは通常、Direct Lake セマンティック モデルがデータの読み込みに使用するレイクハウスに格納されます。 ただし、Parquet ファイルは外部に格納することもできます。 外部 Parquet ファイルは、OneLake ショートカットを使用して参照できます。これは、Azure Data Lake Storage (ADLS) Gen2、Amazon S3 ストレージ アカウント、dataverse など、特定のストレージの場所を指します。 ほとんどの場合、コンピューティング エンジンは Delta テーブルのクエリを実行して Parquet ファイルにアクセスします。 ただし、通常、Direct Lake セマンティック モデルは、コード変換と呼ばれるプロセスを使用して、OneLake の最適化された Parquet ファイルから列データを直接読み込みます。

データのバージョン管理:

Delta テーブルは、1 つ以上の Parquet ファイルで構成されます。 これらのファイルには、Delta テーブルに関連付けられている各 Parquet ファイルの順序と性質を追跡する JSON ベースのリンク ファイルのセットが付属しています。

基になる Parquet ファイルは本質的に増分的であることを理解することが重要です。 そのため、Delta という名前は、増分データ変更への参照として使用されます。 Delta テーブルへの挿入、更新、削除などの書き込み操作が行われるたびに、データはバージョンとしてデータ変更を表す新しい Parquet ファイルが作成されます。 したがって、Parquet ファイルは変更できないです。つまり、変更されることはありません。 そのため、Delta テーブルの Parquet ファイルのセット間でデータが何度も重複する可能性があります。 Delta フレームワークは、リンク ファイルに依存して、正しいクエリ結果を生成するために必要な物理 Parquet ファイルを決定します。

この記事でさまざまなデータ変更操作を説明するために使用する Delta テーブルの簡単な例を考えてみましょう。 テーブルには 2 つの列があり、3 つの行が格納されます。

ProductID StockOnHand
A 1
B 2
C 3

Delta テーブル データは、すべてのデータを含む単一の Parquet ファイルに格納され、データが挿入されたタイミング (追加) に関するメタデータを含む単一のリンク ファイルがあります。

  • Parquet ファイル 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • リンク ファイル 1:
    • Parquet file 1 が作成されたときのタイムスタンプと、データが追加されたことを記録します。

挿入操作

挿入操作が発生した場合に何が起こるかを検討します: 在庫の値 4 を持つ製品 C の新しい行が挿入されます。 この操作により、新しい Parquet ファイルとリンク ファイルが作成されるため、Parquet ファイルが 2 つ、リンク ファイルが 2 つになりました。

  • Parquet ファイル 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet ファイル 2:
    • ProductID: D
    • StockOnHand: 4
  • リンク ファイル 1:
    • Parquet file 1 が作成されたときのタイムスタンプと、データが追加されたことを記録します。
  • リンク ファイル 2:
    • Parquet file 2 が作成されたときのタイムスタンプと、データが追加されたことを記録します。

この時点で、Delta テーブルのクエリは次の結果を返します。 結果が複数の Parquet ファイルから取得される場合は関係ありません。

ProductID StockOnHand
A 1
B 2
C 3
D 4

以降のすべての挿入操作で、新しい Parquet ファイルとリンク ファイルが作成されます。 つまり、挿入操作のたびに Parquet ファイルとリンク ファイルの数が増えます。

更新操作

次に、更新操作が発生した場合に何が起こるかを検討します。製品 D の行には、手持ち在庫の値が 10 に変更されています。 この操作により、新しい Parquet ファイルとリンク ファイルが作成されるため、Parquet ファイルが 3 つ、リンク ファイルが 3 つになりました。

  • Parquet ファイル 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet ファイル 2:
    • ProductID: D
    • StockOnHand: 4
  • Parquet ファイル 3:
    • ProductID: C
    • StockOnHand: 10
  • リンク ファイル 1:
    • Parquet file 1 が作成されたときのタイムスタンプと、データが追加されたことを記録します。
  • リンク ファイル 2:
    • Parquet file 2 が作成されたときのタイムスタンプと、データが追加されたことを記録します。
  • リンク ファイル 3:
    • Parquet file 3 が作成されたときのタイムスタンプと、データが更新されたことを記録します。

この時点で、Delta テーブルのクエリは次の結果を返します。

ProductID StockOnHand
A 1
B 2
C 10
D 4

製品 C のデータが複数の Parquet ファイルに存在するようになりました。 ただし、Delta テーブルに対するクエリでは、リンク ファイルを組み合わせて、正しい結果を得るために使用する必要があるデータを決定します。

操作を削除する

次に、削除操作が発生した場合の動作を検討します。製品 B の行が削除されます。 この操作により、新しい Parquet ファイルとリンク ファイルが作成されるため、Parquet ファイルが 4 つ、リンク ファイルが 4 つになりました。

  • Parquet ファイル 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet ファイル 2:
    • ProductID: D
    • StockOnHand: 4
  • Parquet ファイル 3:
    • ProductID: C
    • StockOnHand: 10
  • Parquet ファイル 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • リンク ファイル 1:
    • Parquet file 1 が作成されたときのタイムスタンプと、データが追加されたことを記録します。
  • リンク ファイル 2:
    • Parquet file 2 が作成されたときのタイムスタンプと、データが追加されたことを記録します。
  • リンク ファイル 3:
    • Parquet file 3 が作成されたときのタイムスタンプと、データが更新されたことを記録します。
  • リンク ファイル 4:
    • Parquet file 4 が作成されたときのタイムスタンプと、データが更新されたことを記録します。

Parquet file 4 には製品 B のデータは含まれませんが、テーブル内の他のすべての行のデータが含まれていることに注意してください。

この時点で、Delta テーブルのクエリは次の結果を返します。

ProductID StockOnHand
A 1
C 10
D 4

Note

この例は、小さなテーブル、少数の操作、およびわずかな変更のみが含まれるため、単純です。 多数の書き込み操作が発生し、多数のデータ行を含む大きなテーブルでは、バージョンごとに複数の Parquet ファイルが生成されます。

重要

Delta テーブルの定義方法とデータ変更操作の頻度によっては、多くの Parquet ファイルが生成される場合があります。 各 Fabric 容量ライセンスには、ガードレールがあることに注意してください。 Delta テーブルの Parquet ファイルの数が SKU の制限を超えた場合、クエリは DirectQuery にフォールバックするため、クエリのパフォーマンスが低下する可能性があります。

Parquet ファイルの数を管理するには、この記事で後述の「デルタ テーブルのメンテナンス」を参照してください。

Delta タイム トラベル

リンク ファイルを使用すると、以前の時点のデータに対してクエリを実行できます。 この機能は、デルタ タイム トラベルと呼ばれます。 以前の時点には、タイムスタンプまたはバージョンを指定できます。

次のクエリ例を考えてみましょう。

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

ヒント

@ 短縮構文を使用してテーブルにクエリを実行し、テーブル名の一部としてタイムスタンプまたはバージョンを指定することもできます。 タイムスタンプは yyyyMMddHHmmssSSS 形式である必要があります。 バージョンの前に v を付加することで、@ の後にバージョンを指定できます。

前のクエリ例を短縮構文で書き換えた例を次に示します。

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

重要

タイム トラベルでアクセスできるテーブル バージョンは、トランザクション ログ ファイルのリテンション期間のしきい値と VACUUM 操作の頻度と指定されたリテンション期間の組み合わせによって決まります (「Delta テーブルのメンテナンス」セクションで後述します)。 既定値を使用して VACUUM を毎日実行すると、タイム トラベルで 7 日間のデータを使用できるようになります。

フレーミング

フレーミング は、セマンティック モデル列にデータを読み込むのに使用する Delta テーブルのバージョンを設定する Direct Lake 操作です。 同様に重要なのは、データの読み込み時に除外する必要がある項目もバージョンによって決まります。

フレーミング操作では、各 Delta テーブルのタイムスタンプ/バージョンがセマンティック モデル テーブルにスタンプされます。 この時点から、セマンティック モデルが Delta テーブルからデータを読み込む必要がある場合、読み込むデータを決定するために、最新のフレーミング操作に関連付けられているタイムスタンプ/バージョンが使用されます。 最新のフレーミング操作以降に Delta テーブルに対して行われる後続のデータ変更は無視されます (次のフレーミング操作まで)。

重要

フレーム化されたセマンティック モデルは特定の Delta テーブル バージョンを参照するため、ソースでは、新しいバージョンのフレーミングが完了するまで Delta テーブルのバージョンが保持されていることを確認する必要があります。 そうしないと、モデルによって Delta テーブル ファイルにアクセスする必要があり、プロデューサー ワークロードによってバキュームまたは削除された場合に、エラーが発生します。

フレームの詳細については、「Direct Lake の概要」を参照してください。

テーブルのパーティション分割

行のサブセットが単一の Parquet ファイルセットにまとめて格納されるように、Delta テーブルをパーティション分割できます。 パーティションを使用すると、クエリと書き込み操作を高速化できます。

2 年間の売上データが 10 億行ある Delta テーブルについて考えてみましょう。 すべてのデータを 1 セットの Parquet ファイルに格納することは可能ですが、このデータ ボリュームでは、読み取りと書き込みの操作には最適ではありません。 代わりに、10 億行のデータを複数の Parquet ファイルに分散することで、パフォーマンスを向上させることができます。

テーブルのパーティション分割を設定するときは、パーティション キー を定義する必要があります。 パーティション キーは、どの行がどの系列に格納するかを決定します。 Delta テーブルの場合、パーティション キーは、日付テーブルの月/年列など、指定した列の個別の値に基づいて定義できます。 この場合、2 年間のデータが 24 個のパーティション (2 年 x 12 か月) に分散されます。

Fabric コンピューティング エンジンは、テーブル パーティションを認識しません。 新しいパーティション キー値を挿入すると、新しいパーティションが自動的に作成されます。 OneLake では、一意のパーティション キー値ごとに 1 つのサブフォルダーがあり、各サブフォルダーには独自の Parquet ファイルとリンク ファイルのセットが格納されます。 少なくとも 1 つの Parquet ファイルと 1 つのリンク ファイルが存在する必要がありますが、各サブフォルダー内の実際のファイル数は異なる場合があります。 データ変更操作が行われると、各パーティションは、特定のタイムスタンプまたはバージョンに対して返される内容を追跡するために、Parquet ファイルとリンク ファイルの独自のセットを保持します。

パーティション分割された Delta テーブルのクエリが最新の 3 か月間の売上データのみにフィルター処理された場合、アクセスする必要がある Parquet ファイルとリンク ファイルのサブセットをすばやく特定できます。 これにより、多くの Parquet ファイルを完全にスキップできるため、読み取りパフォーマンスが向上します。

ただし、パーティション キーでフィルター処理されないクエリのパフォーマンスが常に向上するとは限りません。 これは、Delta テーブルですべてのデータを 1 つの大きな Parquet ファイルセットに格納し、ファイルまたは行グループの断片化がある場合です。 複数のクラスター ノード間で複数の Parquet ファイルからのデータ取得を並列化できますが、多くの小さな Parquet ファイルがファイル入出力に悪影響を及ぼす可能性があるため、クエリのパフォーマンスが低下する可能性があります。 このため、ほとんどの場合、Delta テーブルのパーティション分割を回避することをお勧めします—無意味な書き込み操作や抽出、変換、読み込み (ETL) プロセスは、その恩恵を明確に受けます。

パーティション分割では、変更または削除された行のパーティション キーに一致するサブフォルダーでのみファイル アクティビティが実行されるため、挿入、更新、および削除操作も行われます。 たとえば、データのバッチがパーティション分割された Delta テーブルに挿入された場合、データは評価され、バッチ内に存在するパーティション キーの値が決定されます。 その後、データはパーティションの関連フォルダーにのみ送信されます。

Delta テーブルでパーティションを使用する方法を理解すると、大規模な Delta テーブルを更新するときに実行する必要がある書き込み操作を減らす最適な ETL シナリオを設計できます。 作成する必要がある新しい Parquet ファイルの数とサイズを減らすことで、書き込みパフォーマンスが向上します。 前の例で説明したように、月/年でパーティション分割された大きな Delta テーブルでは、新しいデータによって最新のパーティションに新しい Parquet ファイルのみが追加されます。 過去のカレンダー月のサブフォルダーは変更されません。 過去のカレンダー月のデータを変更する必要がある場合は、関連するパーティション フォルダーのみが新しいパーティション ファイルとリンク ファイルを受け取ります。

重要

Delta テーブルの主な目的がセマンティック モデル (およびセカンダリに他のクエリ ワークロード) のデータ ソースとして機能する場合は、通常、メモリへの列の負荷を最適化するために優先してパーティション分割を回避することをお勧めします。

Direct Lake セマンティック モデルまたは SQL 分析エンドポイントの場合、Delta テーブル パーティションを最適化する最善の方法は、Delta テーブルの各バージョンの Parquet ファイルを Fabric が自動的に管理できるようにすることです。 Fabric に管理を任せておくと、並列化によってクエリのパフォーマンスが高くなりますが、必ずしも最適な書き込みパフォーマンスが得られない場合があります。

書き込み操作用に最適化する必要がある場合は、パーティションを使用して、パーティション キーに基づいて Delta テーブルへの書き込み操作を最適化することを検討してください。 ただし、Delta テーブルをパーティション分割すると、読み取りパフォーマンスに悪影響を及ぼす可能性があることに注意してください。 このため、読み取りと書き込みのパフォーマンスを慎重にテストすることをお勧めします。たとえば、タイミングを比較する構成が異なる同じ Delta テーブルの複数のコピーを作成します。

警告

カーディナリティの高い列にパーティション分割すると、Parquet ファイルの数が多くなる可能性があります。 すべての Fabric 容量ライセンスには、ガードレールがあることに注意してください。 Delta テーブルの Parquet ファイルの数が SKU の制限を超えた場合、クエリは DirectQuery にフォールバックするため、クエリのパフォーマンスが低下する可能性があります。

Parquet ファイル

Delta テーブルの基になるストレージは、1 つ以上の Parquet ファイルです。 Parquet ファイル形式は、一般に、書き込み 1 回、読み取り多く アプリケーションに使用されます。 新しい Parquet ファイルは、挿入、更新、または削除の操作によって、Delta テーブル内のデータが変更されるたびに作成されます。

Note

OneLake エクスプローラーなどのツールを使用して、Delta テーブルに関連付けられている Parquet ファイルアクセスできます。 ファイルは、他のファイルを移動するのと同じくらい簡単に、ダウンロード、コピー、または他の宛先に移動できます。 ただし、Parquet ファイルと JSON ベースのリンク ファイルの組み合わせにより、コンピューティング エンジンは Delta テーブルとしてファイルに対してクエリを発行できます。

Parquet ファイル形式

Parquet ファイルの内部形式は、CSV、TSV、XMLA、JSON などの他の一般的なデータ ストレージ形式とは異なります。 これらの形式では、データが行別に整理され、Parquet では列別にデータが整理されます。 また、Parquet ファイル形式は、データ行を 1 つ以上の行グループに整理するため、これらの形式とは異なります。

Power BI セマンティック モデルの内部データ構造は列ベースであるため、Parquet ファイルは Power BI と多くの共通点を共有します。 この類似性は、Direct Lake セマンティック モデルが Parquet ファイルからメモリに直接データを効率的に読み込むことができることを意味します。 実際、非常に大量のデータを数秒で読み込むことができます。 この機能と、ブロックまたはソース データを取得し、処理、エンコード、格納、メモリへの読み込みを行う必要があるインポート セマンティック モデルの更新と対照的です。 インポート セマンティック モデルの更新操作では、大量のコンピューティング (メモリと CPU) が消費され、完了するまでにかなりの時間がかかる場合もあります。 ただし、Delta テーブルでは、セマンティック モデルへの直接読み込みに適したデータを準備する作業のほとんどは、Parquet ファイルが生成されるときに行われます。

Parquet ファイルによるデータの格納方法

次の一連のデータの例を考えてみましょう。

日 ProductID StockOnHand
2024-09-16 A 10
2024-09-16 B 11
2024-09-17 A 13
...

Parquet ファイル形式で格納されている場合、概念的には、この一連のデータは次のテキストのようになります。

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

データは、共通値のディクショナリ キーを置き換え、実行長エンコード (RLE) を適用することによって圧縮されます。 RLE は、同じ値の系列をより小さな表現に圧縮するよう努めています。 次の例では、数値キーと値のディクショナリ マッピングがヘッダーに作成され、データ値の代わりに小さいキー値が使用されます。

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Direct Lake セマンティック モデルで、ProductID でグループ化された StockOnHand 列の合計を計算するデータが必要な場合は、2 つの列に関連付けられているディクショナリとデータのみが必要です。 多数の列を含む大きなファイルでは、Parquet ファイルのかなりの部分をスキップして、読み取りプロセスを高速化できます。

Note

Parquet ファイルの内容は人間が判読できないため、テキスト エディターで開くには適していません。 ただし、Parquet ファイルの内容を開いて表示できる多くのオープン ソース ツールがあります。 これらのツールを使用すると、ファイルに含まれる行数や行グループなどのメタデータを検査することもできます。

V-Order

Fabric では、V オーダーと呼ばれる追加の最適化がサポートされています。 V オーダーは、Parquet ファイル形式への書き込み時の最適化です。 V オーダーを適用すると、ファイルが小さくなり、読み取り速度が向上します。 この最適化は、メモリへの高速読み込みに備えてデータを準備するため、Direct Lake セマンティック モデルに特に関連するため、容量リソースに対する要求が少なくなります。 また、スキャンする必要があるメモリが少ないため、クエリのパフォーマンスも向上します。

データ パイプライン、データフロー、ノートブックなどの Fabric 項目によって作成および読み込まれた Delta テーブルには、V オーダーが自動的に適用されます。 ただし、Fabric Lakehouse にアップロードされた Parquet ファイルや、ショートカットによって参照されている Parquet ファイルでは、この最適化が適用されていない可能性があります。 最適化されていない Parquet ファイルは引き続き読み取ることができますが、読み取りパフォーマンスは、V オーダーが適用された同等の Parquet ファイルほど高速ではなくなる可能性があります。

Note

V オーダーが適用されている Parquet ファイルは、引き続きオープンソースの Parquet ファイル形式に準拠しています。 そのため、非 Fabric ツールで読み取ることができます。

詳細については、「Delta Lake テーブルの最適化と V オーダー」を参照してください。

Delta テーブルの最適化

このセクションでは、セマンティック モデル用に Delta テーブルを最適化するためのさまざまなトピックについて説明します。

データ量

Delta テーブルは非常に大量のデータを格納するように拡張できますが、Fabric 容量ガードレール、クエリを実行するセマンティック モデルに制限が課せられます。 これらの制限を超えると、クエリは DirectQuery にフォールバックするため、クエリのパフォーマンスが低下する可能性があります。

そのため、粒度を上げる (集計データを格納する)、次元を減らす、または履歴を少なくして、大きな ファクト テーブル の行数を制限することを検討してください。

また、読み取るファイルが小さくなり、読み取り速度が向上するため、V オーダー が適用されていることを確認します。

列のデータ型

各 Delta テーブルのすべての列のカーディナリティ (一意の値の数) を減らすように努めます。 これは、すべての列が圧縮され、ハッシュ エンコードを使用して格納されるためです。 ハッシュ エンコードでは、列に含まれる各一意の値に数値識別子を割り当てるために V オーダー最適化が必要です。 これは数値識別子であり、格納され、ストレージとクエリ中にハッシュ検索が必要になります。

近似数値データ型 (浮動、real など) を使用する場合は、値を丸め、精度を低くすることを検討してください。

不要な列

他のデータ テーブルと同様に、Delta テーブルには必要な列のみを格納する必要があります。 この記事のコンテキストでは、セマンティック モデルで必要であることを意味しますが、Delta テーブルにクエリを実行する他の分析ワークロードが存在する可能性があります。

Delta テーブルには、モデル リレーションシップをサポートする列に加えて、フィルター処理、グループ化、並べ替え、集計のためにセマンティック モデルに必要な列を含める必要があります。 不要な列はセマンティック モデルのクエリ パフォーマンスに影響しませんが (メモリに読み込まれないため)、OneLake のストレージ サイズが大きくなり、読み込みと保守に必要なコンピューティング リソースが増えます。

Direct Lake セマンティック モデルは計算列をサポートしていないため、Delta テーブルでこのような列を具体化する必要があります。 この設計アプローチは、インポートおよび DirectQuery セマンティック モデルのアンチパターンであることに注意してください。 たとえば、FirstName と LastName 列があり、FullName 列が必要な場合は、Delta テーブルに行を挿入するときにこの列の値を具体化します。

一部のセマンティック モデルの要約は、複数の列に依存する可能性があることを考慮してください。 たとえば、売上を計算するために、モデル内のメジャーは、Quantity と Price の 2 つの列の積を合計します。 どちらの列も個別に使用しない場合は、コンポーネント値を個別の列に格納するよりも、売上計算を 1 つの列として具体化する方が効率的です。

行グループのサイズ

内部的には、Parquet ファイルは、データの行を各ファイル内の複数の行グループに整理します。 たとえば、30,000 行を含む Parquet ファイルは、それぞれ 10,000 行の 3 つの行グループにチャンクされる場合があります。

行グループ内の行数は、Direct Lake がデータを読み取る速度に影響します。 行数が少ない行グループの数が多いほど、過剰な入出力が原因で、セマンティック モデルへの列データの読み込みに悪影響を及ぼす可能性があります。

一般に、既定の行グループ サイズを変更することはお勧めしません。 ただし、大きな Delta テーブルの行グループのサイズを変更することを検討してください。 読み取りと書き込みのパフォーマンスを慎重にテストしてください。たとえば、タイミングを比較する構成が異なる同じ Delta テーブルの複数のコピーを作成します。

重要

すべての Fabric 容量ライセンスには、ガードレールがあることに注意してください。 Delta テーブルの行 グループの数が SKU の制限を超えた場合、クエリは DirectQuery にフォールバックするため、クエリのパフォーマンスが低下する可能性があります。

デルタ テーブルのメンテナンス

時間の経過と同時に、書き込み操作が行われると、Delta テーブルのバージョンが蓄積されます。 最終的には、読み取りパフォーマンスに悪影響が出る可能性があります。 さらに悪いことに、テーブルあたりの Parquet ファイル数、またはテーブルあたりの行グループ数が容量ガードレールを超えた場合、クエリは DirectQuery にフォールバックし、クエリのパフォーマンスが低下する可能性があります。 そのため、Delta テーブルを定期的に管理することが重要です。

OPTIMIZE

OPTIMIZE を使用すると、Delta テーブルを最適化して、小さいファイルをより大きなファイルに結合できます。 WHERE 句を設定して、特定のパーティション述語に一致する行のフィルター処理されたサブセットのみを対象にすることもできます。 パーティション キーを含むフィルターのみがサポートされています。 OPTIMIZE コマンドでは、V-Order を適用して Parquet ファイルを圧縮および書き換えることもできます。

このコマンドは、頻繁に更新される大規模な Delta テーブル (ETL プロセスが完了した日など) に定期的に実行することをお勧めします。 クエリパフォーマンスの向上と、テーブルの最適化に必要なリソース使用量のコストとのトレードオフのバランスを取ります。

VACUUM

VACUUM を使用して、参照されなくなったファイルや、設定された保持しきい値より古いファイルを削除できます。 適切な保持期間を設定するように注意してください。そうしないと、セマンティック モデル テーブルにスタンプされたフレームより古いバージョンにタイム トラベルをできなくなる可能性があります。

重要

フレーム化されたセマンティック モデルは特定の Delta テーブル バージョンを参照するため、ソースでは、新しいバージョンのフレーミングが完了するまで Delta テーブルのバージョンが保持されていることを確認する必要があります。 そうしないと、モデルによって Delta テーブル ファイルにアクセスする必要があり、プロデューサー ワークロードによってバキュームまたは削除された場合に、エラーが発生します。

REORG TABLE

REORG TABLE を使用すると、ALTER TABLE DROP COLUMN を使用して列を削除する場合など、論理的に削除されたデータを消去するファイルを書き換えて差分テーブルを再構成できます。

テーブルのメンテナンスを自動化する

テーブルのメンテナンス操作を自動化するには、Lakehouse API を使用できます。 詳細については、「Microsoft Fabric REST API を使用した Lakehouse の管理」を参照してください。

ヒント

また、Fabric ポータルでレイクハウス テーブル メンテナンス機能を使用して、Delta テーブルの管理を簡略化することもできます。

関連するコンテンツ