Microsoft Fabricの「Lakehouse and Delta Tables – Microsoft Fabric」を確認する読者が最初に押さえるべき結論は、Fabric LakehouseではDelta Lakeテーブルが標準であり、今回の公式情報では特にV-OrderとOptimize Writeの既定値の扱いが整理されたという点です。新規ワークスペースと既存ワークスペースで挙動が異なる可能性があるため、管理者はSpark設定、ランタイム、テーブル最適化方針を確認し、開発者はNotebookやパイプライン内で暗黙の既定値に依存していないかを点検する必要があります。公式ページは2026年5月20日に更新され、GitHub上の変更履歴でも既定値の不整合を修正するコミットが確認できます。 (Microsoft Learn)
2026年5月20日の更新で確認すべきポイント
今回の更新は、「Delta Lakeを使うべきか」という選定の話ではなく、Fabric LakehouseでDeltaテーブルをどう扱い、どの最適化設定を前提に運用するかを見直す内容として読むべきです。
特に重要なのは、Azure Synapse Analyticsからの移行や、2025年4月以前に作成したFabricワークスペースを運用している組織です。公式ドキュメントの差分では、spark.sql.parquet.vorder.default が従来の true 表記から false* に、spark.databricks.delta.optimizeWrite.enabled が true から unset (false)* に修正されました。注記では、2025年4月より前に作成されたFabricワークスペースではV-OrderとOptimize Writeが既定で有効だった一方、新しいワークスペースではFabric Spark Runtime 1.3でこれらの機能が無効、Runtime 2.0ではOptimize Writeが UNSET であると説明されています。 (GitHub)
| 確認項目 | 公式情報の要点 | 実務での影響 |
|---|---|---|
| Delta Lake形式 | Fabric LakehouseではDelta Lakeが既定のテーブル形式 | CSVやParquetを扱っていても、テーブルとして管理する場合はDelta前提で設計する |
| V-Orderの既定値 | 新規ワークスペースではV-Orderが既定で無効 | ダッシュボードや反復クエリで読み取り性能を重視する場合は明示的な有効化を検討する |
| Optimize Write | ワークスペース作成時期とランタイムで既定値が異なる | 既存環境と新規環境でファイルサイズや書き込み性能が変わる可能性がある |
| Azure Synapseからの移行 | Synapseの既定テーブル形式はParquet、FabricはDelta | 移行時にテーブル形式、Spark設定、ライブラリ、Notebookの前提を点検する |
| ショートカット | Deltaテーブルとファイル/フォルダーで配置先の推奨が異なる | SQL分析エンドポイントで使いたいDeltaテーブルはTables側に配置する |
| テーブル最適化 | 自動最適化に任せるだけでなく、必要に応じてOPTIMIZEやVACUUMを使う | 大規模テーブル、頻繁な書き込み、Direct Lake用途では保守設計が必要 |
Fabric LakehouseではDelta Lakeテーブルが標準になる
Microsoft Fabric Lakehouseでは、データをテーブルとして保存する場合、Delta Lakeが既定の形式です。Delta Lakeは、トランザクション整合性、整合性チェック、クエリ性能の改善を支える形式で、Power BI、Notebook、パイプラインなどFabric内の複数サービスとの連携を前提に設計されています。 (Microsoft Learn)
初心者が混乱しやすいのは、「CSVやParquetもサポートされているなら、Deltaでなくてもよいのでは」という点です。実務では次のように考えると判断しやすくなります。
| データの状態 | 推奨される扱い | 理由 |
|---|---|---|
| 分析やPower BIで継続利用するデータ | DeltaテーブルとしてLakehouseのTablesに置く | SQL分析エンドポイントやFabric内の各機能と連携しやすい |
| 一時的に取り込んだCSVやJSON | Filesに置いてSparkで処理し、必要に応じてDelta化する | 生データと分析用テーブルを分けられる |
| 既存のParquetファイル | そのまま読むか、性能要件がある場合はDeltaテーブルへ変換する | Deltaのトランザクション管理や最適化を活用できる |
| 外部ストレージ上のDeltaテーブル | Tables側にショートカットを作成する | Lakehouse上でテーブルとして認識され、SQLクエリ対象にしやすい |
つまり、Fabric Lakehouseの運用では「ファイルを置く場所」と「テーブルとして管理する場所」を分けて考えることが重要です。探索や前処理はFiles、本番分析や共有はTables、という分離が基本になります。
V-OrderとOptimize Writeの既定値は必ず確認する
今回の更新で最も注意すべきなのは、V-OrderとOptimize Writeを「Fabricでは常に既定で有効」と思い込まないことです。
V-OrderはParquetファイルの書き込み時最適化で、ダッシュボード、対話型分析、反復的なスキャンのような読み取り中心のワークロードで効果を期待できます。一方で、書き込みに時間がかかる可能性があり、公式情報では平均的に約15%の書き込み時間増加が起こり得ると説明されています。新規Fabricワークスペースでは、書き込み中心のデータエンジニアリングワークロードを考慮して、V-Orderは既定で無効です。 (Microsoft Learn)
管理者が最初に見るべき設定
Fabric管理者やワークスペース管理者は、次の3点を確認してください。
| 確認対象 | 確認理由 | 具体的な見方 |
|---|---|---|
| ワークスペース作成時期 | 2025年4月以前とそれ以降で既定挙動が異なる可能性がある | 既存環境と新規環境のSpark設定を比較する |
| Fabric Spark Runtime | Runtime 1.3と2.0でOptimize Writeの扱いが変わる | Environmentまたはワークスペース設定でランタイムを確認する |
| Spark設定 | NotebookやSpark Job Definitionが暗黙の既定値に依存していないか確認する | spark.sql.parquet.vorder.default などを明示的に確認する |
V-Orderのセッション設定は、Notebookで次のように確認できます。 (Microsoft Learn)
spark.conf.get("spark.sql.parquet.vorder.default")読み取り中心のテーブルでV-Orderを有効にしたい場合は、セッション単位で次のように設定できます。
spark.conf.set("spark.sql.parquet.vorder.default", "true")逆に、取り込みや変換の書き込み速度を優先する処理では、明示的に無効化しておくと、環境差による挙動のブレを抑えられます。
spark.conf.set("spark.sql.parquet.vorder.default", "false")旧設定を使っているコードは修正する
Fabric Runtime 1.3以降では、spark.sql.parquet.vorder.enable は削除されています。以前のNotebookや移行元コードにこの設定が残っている場合は、spark.sql.parquet.vorder.default、テーブルプロパティ、または書き込みオプションで制御する形に見直します。 (Microsoft Learn)
特にAzure Synapse Analyticsから移行したコードでは、Spark設定の名前、テーブル形式、ライブラリ管理、ジョブ定義の違いをまとめて確認する必要があります。FabricではSpark構成がEnvironmentやNotebook/Spark Job Definition単位で扱われるため、Synapseのプール単位設定をそのまま移すだけでは期待どおりにならない場合があります。 (Microsoft Learn)
V-Orderは「全部有効」ではなく用途で使い分ける
V-Orderは便利ですが、すべてのDeltaテーブルで有効化すればよいわけではありません。判断基準はシンプルです。
| ワークロード | V-Orderの考え方 | 理由 |
|---|---|---|
| Power BIレポート、Direct Lake、定期的な集計参照 | 有効化を検討する | 同じテーブルを繰り返し読むため、読み取り効率の改善が効きやすい |
| 大量データの初回取り込み | 無効のまま始めることを検討する | 書き込み時間を優先した方がよい場合がある |
| ストリーミングやマイクロバッチ | 慎重に検証する | 書き込み遅延がSLAに影響する可能性がある |
| 一時テーブル、検証用テーブル | 原則として不要 | 最適化コストに見合わないことが多い |
| 大規模な本番分析テーブル | テーブル単位またはOPTIMIZE時に制御する | 読み取り性能と保守コストのバランスを取りやすい |
テーブル単位でV-Orderの既定値を持たせたい場合は、Deltaテーブルのプロパティを使います。ただし、テーブルプロパティの変更は将来の書き込みに影響するもので、既存ファイルの物理レイアウトを自動的に書き換えるわけではありません。既存データに適用したい場合は、OPTIMIZEなどで再編成する必要があります。 (Microsoft Learn)
ALTER TABLE sales.orders
SET TBLPROPERTIES ("delta.parquet.vorder.enabled" = "true");一時的に特定の書き込みだけV-Orderを使いたい場合は、DataFrame writerのオプションで制御します。
df.write \
.format("delta") \
.mode("append") \
.option("parquet.vorder.enabled", "true") \
.saveAsTable("sales.orders")Load to tablesを使う場合の注意点
FabricポータルのLakehouseでは、CSVやParquetファイルをDeltaテーブルへ変換する「Load to tables」を使えます。単一ファイルまたはフォルダーを起点に、新規テーブルまたは既存テーブルへ読み込めるため、GUIで手早くLakehouseテーブルを作りたい場合に便利です。 (Microsoft Learn)
ただし、現行のLoad to tablesでは、Lakehouseホームページからカスタム列スキーマを明示的に定義できません。列名やデータ型を厳密に制御したい場合は、Notebookを使って読み込み処理を書く方が安全です。 (Microsoft Learn)
| ケース | Load to tablesでよいか | 補足 |
|---|---|---|
| 小規模なCSVを試しにテーブル化する | 向いている | GUIで素早くDeltaテーブル化できる |
| 列名・データ型を厳密に指定したい | Notebook推奨 | スキーマ推論に任せると意図しない型になることがある |
| フォルダー内の複数CSVをまとめて読み込む | 条件付きで可 | 同じファイル形式でそろえる必要がある |
| 本番パイプラインに組み込む | Notebookまたはパイプライン推奨 | 再現性、ログ、エラー処理を管理しやすい |
失敗しやすいポイントは、CSVのヘッダーや区切り文字です。ヘッダーを使わない場合、列名が _c0、_c1 のような既定名になるため、後続のPower BIレポートやSQLクエリで扱いにくくなります。最初から本番利用を想定するテーブルでは、Notebookでスキーマを明示する運用をおすすめします。
ショートカットはTablesとFilesを使い分ける
OneLakeショートカットは、外部データや別ワークスペースのデータをコピーせずに参照できる仕組みです。ただし、Lakehouse内でどこにショートカットを作るかによって、テーブルとしての扱いが変わります。
公式情報では、Deltaテーブルをテーブルとして認識させたい場合はTablesセクションにショートカットを作ることが推奨されています。一方、ファイルやフォルダー、レガシーHiveテーブルなどはFilesセクションに置き、Sparkで読み込んだうえで必要に応じてLakehouseネイティブのDeltaテーブルに変換するのが実務的です。 (Microsoft Learn)
| ショートカット先のデータ | 作成場所 | 実務上の使い方 |
|---|---|---|
| 単一のDelta Lakeテーブル | Tables | SparkとSQL分析エンドポイントからテーブルとして使う |
| 複数のDeltaテーブルを含むフォルダー | Tables側のスキーマショートカット | スキーマ配下のテーブル群として扱う |
| CSV、JSON、Parquetなどのファイル群 | Files | Sparkで読み込み、必要ならDeltaテーブル化する |
| 外部ストレージ上のレガシーHiveテーブル | Files | Sparkまたは外部テーブル参照で扱い、必要ならDeltaへ移行する |
注意したいのは、外部DeltaテーブルをSparkコードで作成しただけでは、SQL分析エンドポイントに自動表示されない場合がある点です。SQLクエリやPower BIから使いたい外部Deltaテーブルは、Tablesセクションにショートカットを作成して認識させる流れを確認してください。 (Microsoft Learn)
Deltaテーブルの性能を保つにはOPTIMIZEとVACUUMを設計する
Deltaテーブルは作ったら終わりではありません。取り込み、更新、削除、MERGE、上書きが続くと、小さなファイルが増えたり、参照されなくなった古いファイルが残ったりします。そのまま放置すると、クエリのスキャン効率が下がり、ストレージコストも増えやすくなります。
FabricのDeltaテーブル保守では、主に次の操作を使い分けます。公式情報では、OPTIMIZE、VACUUM、REORG、統計情報、Auto compactionなどがDeltaテーブル保守の主要な要素として整理されています。 (Microsoft Learn)
| 操作 | 目的 | 実行タイミングの例 |
|---|---|---|
OPTIMIZE | 小さなファイルをまとめ、読み取り効率を改善する | 大量取り込み後、ファイル数が増えたとき、定期メンテナンス時 |
OPTIMIZE ... ZORDER BY | よく一緒に絞り込む列でデータ配置を最適化する | 日付と顧客IDなど、選択性の高い複数列で頻繁にフィルターする場合 |
OPTIMIZE ... VORDER | 対象ファイルにV-Orderを適用する | 読み取り中心の分析テーブルを再編成したい場合 |
VACUUM | 参照されなくなった古いデータファイルを削除する | 更新・削除・MERGE・OPTIMIZE後のストレージ回収 |
REORG TABLE ... APPLY (PURGE) | 削除ベクトルで論理削除された行を物理的に整理する | コンプライアンス要件など、明示的な物理削除が必要な場合 |
基本的なOPTIMIZEは次のように実行します。
OPTIMIZE sales.orders;V-Orderを明示的に適用したい場合は、次のように指定します。
OPTIMIZE sales.orders VORDER;Z-OrderとV-Orderは組み合わせることもできます。この場合、Fabric Sparkではbin compaction、Z-Order、V-Orderの順で処理されます。 (Microsoft Learn)
OPTIMIZE sales.orders
ZORDER BY (order_date, customer_id)
VORDER;運用では、DESCRIBE DETAIL と DESCRIBE HISTORY を使って、ファイル数、サイズ、最適化履歴を確認してからメンテナンスするのが安全です。 (Microsoft Learn)
DESCRIBE DETAIL sales.orders;
DESCRIBE HISTORY sales.orders;Auto compactionは便利だが万能ではない
Auto compactionは、書き込み後にファイルの断片化を評価し、小さなファイルが多すぎる場合に同期的なOPTIMIZEを実行する仕組みです。頻繁な小規模書き込みやマイクロバッチでは有効ですが、書き込み直後に追加処理が走るため、書き込み遅延が許容できるかを確認する必要があります。 (Microsoft Learn)
セッション単位で有効化する例は次のとおりです。
spark.conf.set("spark.databricks.delta.autoCompact.enabled", True)既存テーブルで有効化する場合は、テーブルプロパティを使います。
ALTER TABLE sales.orders
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true');Auto compactionを有効にする判断基準は、次のように考えると実務で迷いにくくなります。
| 状況 | 判断 |
|---|---|
| 数分おきに小さなデータを書き込む | 有効化を検討する |
| 夜間バッチで大きなファイルをまとめて書き込む | 手動OPTIMIZEで十分な場合が多い |
| 書き込み遅延を極力避けたい | まず無効で運用し、定期OPTIMIZEを検討する |
| Power BI向けの共有テーブル | Auto compactionと定期OPTIMIZEを組み合わせる |
| 検証用・一時テーブル | 原則不要 |
管理者が確認すべき設定
管理者は、個別のNotebookだけでなく、ワークスペース全体のSpark設定とEnvironmentを確認する必要があります。Fabricでは、ワークスペース作成時にスタータープールが自動作成され、管理者は必要に応じてカスタムSparkプール、Environment、ランタイム、ジョブ設定などを調整できます。Spark設定を変更するには、ワークスペースの管理者ロールが必要です。 (Microsoft Learn)
確認すべき項目は次のとおりです。
| 対象 | 確認内容 | 影響 |
|---|---|---|
| Workspace settings | Data Engineering/Science配下のSpark設定 | ワークスペース内のNotebookやSpark Job Definitionの既定動作 |
| Environment | 使用するFabric Runtime、ライブラリ、Sparkプロパティ | ランタイム差分や依存関係の不整合 |
| Starter Pool / Custom Spark Pool | ノード、オートスケール、動的割り当て | 処理性能、起動時間、コスト |
| Job settings | ジョブ受付、セッションタイムアウト | 同時実行や長時間ジョブの安定性 |
| High concurrency | 複数NotebookでのSparkセッション共有 | チーム開発や同時利用時の効率 |
特にRuntime変更時は、Spark、Python、Scala、Java、Delta Lakeのバージョンが変わります。公式情報では、2026年4月24日時点で本番ワークロードには最新の一般提供版Runtimeを使うことが推奨され、Runtime 1.3がGA、Runtime 2.0はPublic Previewとして掲載されています。 (Microsoft Learn)
開発者がコードで確認すべきポイント
開発者は、次のような「暗黙の既定値に依存したコード」を優先的に確認してください。
| 確認対象 | 問題になりやすい例 | 修正方針 |
|---|---|---|
| V-Order設定 | 以前は有効だった前提で読み取り性能を見積もっている | セッション、テーブル、書き込み単位で明示する |
| 旧設定名 | spark.sql.parquet.vorder.enable を使っている | Runtime 1.3以降では削除済みのため置き換える |
| Optimize Write | 既定で有効と想定している | 現環境の設定を確認し、必要なら明示する |
| スキーマ推論 | CSV読み込みで型や列名を自動判定している | 本番テーブルではスキーマを明示する |
| ショートカット | Files側の外部DeltaをSQLで使えると思っている | Tables側にショートカットを作る |
| メンテナンス | 取り込み後のOPTIMIZEやVACUUMがない | バッチ後または定期実行に組み込む |
実務では、Notebookの先頭に環境確認セルを置くと、トラブルシュートが楽になります。
print("Runtime V-Order default:", spark.conf.get("spark.sql.parquet.vorder.default", "UNSET"))
print("Optimize Write:", spark.conf.get("spark.databricks.delta.optimizeWrite.enabled", "UNSET"))設定が環境によって異なることを前提に、処理の目的に応じて明示するのが安全です。
# 読み取り中心の分析テーブル向け
spark.conf.set("spark.sql.parquet.vorder.default", "true")
# 書き込み中心の取り込み処理向け
spark.conf.set("spark.sql.parquet.vorder.default", "false")移行時のチェックリスト
Azure Synapse Analyticsや既存のFabric環境から移行・再構築する場合は、次の順で確認すると抜け漏れを減らせます。
| 順番 | 確認内容 | 完了条件 |
|---|---|---|
| 1 | 既存テーブルの形式を確認する | Delta、Parquet、CSV、Hiveテーブルの扱いを分類する |
| 2 | ワークスペース作成時期を確認する | 2025年4月以前か、それ以降かを把握する |
| 3 | Runtimeを確認する | Runtime 1.3、2.0などの違いを記録する |
| 4 | V-OrderとOptimize Writeを確認する | 既定値に依存せず、必要な処理では明示する |
| 5 | Load to tablesの利用範囲を決める | GUIでよい処理とNotebook化すべき処理を分ける |
| 6 | ショートカット配置を見直す | SQL利用するDeltaテーブルはTables側に置く |
| 7 | OPTIMIZE/VACUUMの運用を決める | 実行タイミング、対象テーブル、監視項目を決める |
| 8 | Power BIやSQL分析エンドポイントで確認する | クエリ性能とテーブル認識を検証する |
移行でよくある失敗は、「開発環境では速かったのに本番環境で遅い」「旧ワークスペースと新規ワークスペースでファイル数が違う」「SQL分析エンドポイントに外部Deltaテーブルが出てこない」といったものです。多くは、テーブル形式、ショートカットの配置、V-OrderやOptimize Writeの既定値、メンテナンス不足が原因になります。
次に取るべき行動
Microsoft FabricのLakehouse and Delta Tablesに関する今回の更新では、Fabric LakehouseでDelta Lakeテーブルを標準として扱う方針が改めて整理され、V-OrderやOptimize Writeの既定値について実務上重要な注意点が明確になりました。
まず管理者は、ワークスペース作成時期、Fabric Spark Runtime、Environment、Spark設定を確認してください。開発者は、NotebookやパイプラインがV-Order、Optimize Write、スキーマ推論、ショートカット配置に暗黙依存していないかを見直します。そのうえで、読み取り中心の分析テーブルにはV-OrderやOPTIMIZE、頻繁な小規模書き込みにはAuto compaction、ストレージ回収にはVACUUMを組み合わせるのが現実的です。
Deltaテーブル運用で重要なのは、機能をすべて有効にすることではありません。読み取り性能、書き込み速度、保守コスト、Power BIでの利用形態を見て、テーブルごとに最適化方針を決めることです。
コメント