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

[アーティクル]
02/06/2025

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

デルタテーブル

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

手記

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

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

データのバージョン管理

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

基になる Parquet ファイルは本質的に増分的であることを理解することが重要です。そのため、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 ファイルとリンクファイルが作成されるため、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
- 在庫数量: 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

手記

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

重要

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

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

デルタタイムトラベル

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

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

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 ファイルセットにまとめて格納されるように、デルタテーブルをパーティション分割できます。パーティションを使用すると、クエリと書き込み操作を高速化できます。

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

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

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

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

ただし、パーティションキーでフィルター処理されないクエリのパフォーマンスが常に向上するとは限りません。これが起こるのは、Delta テーブルで、すべてのデータが一つの大きな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 テーブル内のデータが変更されるたびに作成されます。

手記

Delta テーブルに関連付けられた Parquet ファイルに、OneLake ファイルエクスプローラーなどのツールを使用してアクセスできます。ファイルは、他のファイルを移動するのと同じくらい簡単に、ダウンロード、コピー、または他の宛先に移動できます。ただし、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年9月16日	B	11
2024年9月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 ファイルのかなりの部分をスキップして、読み取りプロセスを高速化できます。

手記

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

V オーダー

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

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

手記

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

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

デルタテーブルの最適化

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

データボリューム

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

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

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

列データ型

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

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

不要な列

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

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

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

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

行グループのサイズ

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

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

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

重要

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

Delta テーブルのメンテナンス

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

最適化

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

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

真空

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

重要

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

REORG TABLE

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

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

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

ヒント

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

次の方法で共有

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

デルタテーブル

データのバージョン管理

挿入操作

更新操作

削除操作

デルタタイムトラベル

フレーミング

テーブルパーティション

Parquet ファイル

Parquet ファイル形式

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

V オーダー

デルタテーブルの最適化

データボリューム

列データ型

不要な列

行グループのサイズ

Delta テーブルのメンテナンス

最適化

真空

REORG TABLE

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

フィードバック

その他のリソース

次の方法で共有

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

デルタテーブル

データのバージョン管理

挿入操作

更新操作

削除操作

デルタタイムトラベル

フレーミング

テーブルパーティション

Parquet ファイル

Parquet ファイル形式

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

V オーダー

デルタテーブルの最適化

データ ボリューム

列データ型

不要な列

行グループのサイズ

Delta テーブルのメンテナンス

最適化

真空

REORG TABLE

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

関連コンテンツ

フィードバック

その他のリソース

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

データボリューム