Delta Lakeを操作するSQLコマンドは、Databricks認定試験で最も出題頻度が高いトピックです。Data Engineer Associate試験では出題の30〜40%がDelta Lake関連で、OPTIMIZE・VACUUM・MERGE INTO・DESCRIBE HISTORY・RESTORE・DESCRIBE DETAILの構文と動作原理を正確に理解しているかが合否を分けます。この記事では各コマンドの構文・動作・注意点・試験での出題パターンを完全に解説します。
| コマンド | 目的 | データ変更 | メタデータ変更 |
|---|---|---|---|
OPTIMIZE | 小さなファイルの統合(Compaction) | 物理配置のみ | 新バージョン作成 |
VACUUM | 不要ファイルの物理削除 | なし | なし(ログに記録されない) |
MERGE INTO | 条件付きUpsert / CDC | INSERT/UPDATE/DELETE | 新バージョン作成 |
DESCRIBE HISTORY | 変更履歴の参照 | なし | なし |
RESTORE TABLE | 過去バージョンへの復元 | 論理的に復元 | 新バージョン作成 |
DESCRIBE DETAIL | テーブル物理情報の参照 | なし | なし |
VACUUMはトランザクションログに記録されないため、DESCRIBE HISTORYの出力には表示されません。これは試験で頻出の引っかけポイントです。
OPTIMIZEは、Delta Tableに蓄積された小さなParquetファイル(Small Files)を統合して大きなファイルにまとめるCompactionコマンドです。Structured Streamingのマイクロバッチや頻繁なINSERT操作で大量の小さなファイルが生成されると、メタデータのオーバーヘッドが増大しクエリ性能が劣化するため、定期的なOPTIMIZEが推奨されます。
-- 基本構文:テーブル全体を最適化
OPTIMIZE my_catalog.my_schema.sales
-- WHERE句でパーティションを絞り込み
OPTIMIZE my_catalog.my_schema.sales
WHERE region = 'APAC' AND order_date >= '2026-01-01'
-- Z-ORDERと組み合わせ(最大4カラム、推奨2〜3カラム)
OPTIMIZE my_catalog.my_schema.sales
ZORDER BY (customer_id, product_id)
-- Liquid Clustering対応テーブルではZORDER不要
-- OPTIMIZE実行時にCLUSTER BY設定に基づき自動配置
OPTIMIZE my_catalog.my_schema.eventsZ-ORDERは指定カラムの値に基づきデータを空間充填曲線に沿って配置し、データスキッピングを最大化します。ただしZ-ORDERはOPTIMIZE実行時にしか適用されず、その後のINSERTで効果が薄れます。Liquid ClusteringはDatabricks Runtime 13.3以降で利用可能な新方式で、CLUSTER BY句で指定したカラムに基づき書き込み時に自動的にデータを配置します。
-- Liquid Clusteringテーブルの作成
CREATE TABLE events (
event_id BIGINT,
user_id BIGINT,
event_type STRING,
event_date DATE
)
CLUSTER BY (user_id, event_date)
-- 既存テーブルにLiquid Clusteringを設定
ALTER TABLE events CLUSTER BY (user_id, event_date)
-- Liquid Clusteringを解除
ALTER TABLE events CLUSTER BY NONEVACUUMは、現在のテーブルバージョンから参照されていない古いParquetファイルを物理的に削除するコマンドです。ストレージコストを削減しますが、削除されたファイルに対応するバージョンのTime TravelとRESTOREが不可能になる点に注意してください。
-- デフォルト保持期間(168時間 = 7日間)で実行
VACUUM my_catalog.my_schema.sales
-- 保持期間を30日に指定
VACUUM my_catalog.my_schema.sales RETAIN 720 HOURS
-- DRY RUN:削除対象のファイル一覧を確認(実際には削除しない)
VACUUM my_catalog.my_schema.sales DRY RUNデフォルトの保持期間は168時間(7日間)です。これより短い期間を指定すると、同時実行中のリーダーがファイルを参照している可能性があるため、Delta Lakeはエラーを返します。7日未満を強制する場合は以下の設定が必要ですが、本番環境では推奨されません。
-- 保持期間チェックの無効化(非推奨)
SET spark.databricks.delta.retentionDurationCheck.enabled = false;
VACUUM my_catalog.my_schema.sales RETAIN 0 HOURSMERGE INTOは、ソースデータとターゲットDelta Tableをマッチング条件で結合し、マッチ/非マッチの結果に応じてUPDATE・INSERT・DELETEを1つのアトミック操作で実行するコマンドです。CDCパイプラインやUpsertの中核として最も重要なコマンドです。
MERGE INTO gold.customers AS target
USING silver.customers_updates AS source
ON target.customer_id = source.customer_id
WHEN MATCHED AND source.is_deleted = true THEN
DELETE
WHEN MATCHED THEN
UPDATE SET
target.name = source.name,
target.email = source.email,
target.updated_at = source.updated_at
WHEN NOT MATCHED THEN
INSERT (customer_id, name, email, created_at, updated_at)
VALUES (source.customer_id, source.name, source.email,
source.created_at, source.updated_at)
WHEN NOT MATCHED BY SOURCE THEN
UPDATE SET target.is_active = false| 節 | 対象行 | 使用可能な操作 |
|---|---|---|
| WHEN MATCHED | ソース・ターゲット両方に存在 | UPDATE / DELETE |
| WHEN NOT MATCHED | ソースに存在、ターゲットに不在 | INSERT のみ |
| WHEN NOT MATCHED BY SOURCE | ターゲットに存在、ソースに不在 | UPDATE / DELETE |
DESCRIBE HISTORYは、Delta Tableのトランザクションログに記録された変更履歴を表示するコマンドです。各バージョンの操作内容・ユーザー・パラメータを確認でき、デバッグや監査に使用します。
-- 全履歴を表示
DESCRIBE HISTORY my_catalog.my_schema.sales
-- 直近10件の履歴を表示
DESCRIBE HISTORY my_catalog.my_schema.sales LIMIT 10| カラム | 型 | 説明 |
|---|---|---|
| version | BIGINT | バージョン番号(0始まり) |
| timestamp | TIMESTAMP | コミットのタイムスタンプ |
| operation | STRING | WRITE / MERGE / DELETE / OPTIMIZE / RESTORE等 |
| operationParameters | MAP | mode, predicate, partitionBy等の操作パラメータ |
| readVersion | BIGINT | 読み取ったスナップショットバージョン |
| isolationLevel | STRING | トランザクション分離レベル |
| operationMetrics | MAP | numOutputRows, numOutputBytes等の統計 |
| userIdentity | STRING | 操作を実行したユーザー |
RESTORE TABLEは、Delta Tableを過去のバージョンまたはタイムスタンプの状態に復元するコマンドです。誤ったDELETEやUPDATEの取り消しに使用します。RESTOREは新しいバージョンを作成する操作であり、履歴を書き換えるのではなく復元状態を新バージョンとして追加します。
-- バージョン番号で復元
RESTORE TABLE my_catalog.my_schema.sales TO VERSION AS OF 5
-- タイムスタンプで復元
RESTORE TABLE my_catalog.my_schema.sales
TO TIMESTAMP AS OF '2026-03-20 10:00:00'VACUUMで削除済みのParquetファイルが復元先バージョンに必要な場合、RESTOREはFileNotFoundExceptionで失敗します。重要なテーブルではVACUUMの保持期間を長めに設定してください。
DESCRIBE DETAILは、Delta Tableの物理的なメタデータ(ファイルの場所・サイズ・パーティション情報等)を表示するコマンドです。テーブルの状態を診断する際に使用します。
DESCRIBE DETAIL my_catalog.my_schema.sales| カラム | 説明 |
|---|---|
| format | テーブルフォーマット(常に"delta") |
| id | テーブルの一意識別子(UUID) |
| name | Unity Catalog上のテーブル名 |
| location | データファイルの保存先パス |
| numFiles | 現在のバージョンのファイル数 |
| sizeInBytes | 現在のバージョンの合計サイズ |
| partitionColumns | パーティションカラムのリスト |
| clusteringColumns | Liquid Clusteringカラムのリスト |
| minReaderVersion | 必要な最小リーダーバージョン |
| minWriterVersion | 必要な最小ライターバージョン |
numFilesが極端に多い場合はOPTIMIZEの実行を検討し、sizeInBytesが想定より大きい場合はVACUUMが未実行の可能性があります。DESCRIBE DETAILはテーブルの健全性チェックに有用なコマンドです。
Time Travelは、Delta Tableの過去バージョンのデータを読み取る機能です。RESTOREとは異なりテーブルの状態を変更しません。
-- VERSION AS OF 構文
SELECT * FROM my_catalog.my_schema.sales VERSION AS OF 3
-- TIMESTAMP AS OF 構文
SELECT * FROM my_catalog.my_schema.sales
TIMESTAMP AS OF '2026-03-20 10:00:00'
-- @ 構文(簡略表記)
SELECT * FROM my_catalog.my_schema.sales@v3Delta Lake - VACUUM / DESCRIBE HISTORY
問題 1
あるDelta TableにOPTIMIZEを実行した後、DESCRIBE HISTORYでバージョン履歴を確認しました。続いてVACUUM RETAIN 168 HOURSを実行しました。再度DESCRIBE HISTORYを実行した場合、VACUUM操作はどのように表示されますか?
正解: C
VACUUMはDelta Lakeのトランザクションログに記録されない操作です。VACUUMはテーブルのデータ内容を変更せず、不要な物理ファイルを削除するだけのため、新しいバージョンは作成されません。したがってDESCRIBE HISTORYの出力にVACUUM操作は表示されません。一方、OPTIMIZEやMERGE INTOはバージョンを進めるためDESCRIBE HISTORYに記録されます。
OPTIMIZEとVACUUMはどちらを先に実行すべきですか?
OPTIMIZEを先に実行してください。OPTIMIZEが小さなファイルを統合すると、統合前の古いファイルが不要になります。その後VACUUMを実行すれば、OPTIMIZEで不要になったファイルも含めて一括で削除できます。逆の順序では、OPTIMIZEが生成する新しい不要ファイルが残ったままになります。一般的にはOPTIMIZE→VACUUM→ANALYZE TABLE(統計情報更新)の順序がベストプラクティスです。
VACUUM実行後にTime Travelで過去バージョンを参照するとどうなりますか?
VACUUMで削除されたParquetファイルを参照するTime Travelクエリは FileNotFoundException で失敗します。たとえばVACUUM RETAIN 168 HOURS(デフォルト)を実行すると、7日より前のバージョンのデータファイルが削除されるため、そのバージョンへのSELECT ... VERSION AS OFやRESTORE TABLEが不可能になります。VACUUMの保持期間はTime Travelの必要期間に合わせて設定してください。
MERGE INTOでWHEN NOT MATCHED BY SOURCE節はどのような場面で使いますか?
WHEN NOT MATCHED BY SOURCE節はターゲットテーブルに存在するがソースに存在しない行に対してDELETEまたはUPDATEを実行する場合に使います。具体的には、ソースがフルスナップショットを提供する場合にターゲットからソースに存在しない行を論理削除(is_deleted = trueに更新)するSCD Type 2シナリオや、ソースに残っていないレコードを物理削除するフルリフレッシュのMERGEパターンで使用します。Spark 3.4 / Databricks Runtime 13.x以降で利用可能です。
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
Databricks資格一覧|全7試験・難易度・勉強法
Databricks認定資格全7試験の一覧・難易度・出題範囲・合格ラインを徹底解説。2026年最新版の公式試験ガイドに準...
Databricks試験の難易度ランキング|全7資格を徹底比較
Databricks認定全7試験の難易度をランキング形式で徹底比較。合格率・学習時間・出題傾向から難易度を分析。...
Databricks資格の勉強方法|最短合格ルートと学習時間の目安
Databricks認定資格に最短で合格するための勉強方法を完全ガイド。公式リソース・問題集・学習スケジュールを徹底解説...
Databricks Data Engineer Associate完全解説|出題範囲・問題例・合格戦略
Databricks Certified Data Engineer Associate試験を徹底解説。5つの出題ドメイ...
Databricks Data Engineer Professional完全解説|上級試験の攻略法
Databricks Certified Data Engineer Professional試験を徹底解説。10の出題...