次の方法で共有

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

  • [アーティクル]

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

Delta テーブル

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

Note

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

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

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

デルタ テーブルは、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 と、データが追加されたレコードを格納します。

挿入操作

挿入操作が発生した場合に何が起こるかを検討します。在庫の値が指定された製品 C の 4 新しい行が挿入されます。 この操作により、新しい Parquet ファイルとリンク ファイルが作成されるため、2 つの Parquet ファイルと 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 ファイルとリンク ファイルが作成されるため、3 つの Parquet ファイルと 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 と、データが削除されたことを記録します。

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

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

ProductID StockOnHand
A 1
C 10
D 4

Note

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

重要

Delta テーブルの定義方法とデータ変更操作の頻度によっては、多くの Parquet ファイルが生成される場合があります。 各ファブリック容量ライセンスにはガードレールがあることに注意してください。 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 操作の頻度と指定されたリテンション期間の組み合わせによって決まります (デルタ テーブルのメンテナンス セクションで後述)。 既定値を使用して VACUUM を毎日実行すると、タイム トラベルで 7 日間のデータを使用できるようになります。

フレーミング

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

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

重要

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

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

警告

カーディナリティの高い列にパーティション分割すると、Parquet ファイルの数が多くなる可能性があります。 すべてのファブリック容量ライセンスにガードレールがあることに注意してください。 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 項目によって作成および読み込まれたデルタ テーブルは、V オーダーを自動的に適用します。 ただし、Fabric Lakehouse にアップロードされた Parquet ファイル、またはショートカットによって参照されている Parquet ファイルでは、この最適化が適用されていない可能性があります。 最適化されていない Parquet ファイルは引き続き読み取ることができますが、読み取りパフォーマンスは、V オーダーが適用された同等の Parquet ファイルほど高速ではなくなる可能性があります。

Note

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

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

差分テーブルの最適化

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

データ ボリューム

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

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

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

列のデータ型

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

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

不要な列

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

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

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

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

行グループのサイズ

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

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

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

重要

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

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

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

OPTIMIZE

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

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

VACUUM

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

重要

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

REORG TABLE

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

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

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

ヒント

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

関連するコンテンツ