Delta Lakeスキーマエボリューション完全ガイド｜mergeSchema・overwriteSchema

Delta Lakeはデフォルトでスキーマエンフォースメント（スキーマ検証）を行い、テーブル定義に合わないデータの書き込みを拒否します。 しかし実運用では、ソースシステムの変更に伴ってカラムが追加されたり、型が変わったりすることがあります。 スキーマエボリューションは、こうした変更にテーブルを柔軟に追従させるための仕組みです。

この記事では、スキーマエンフォースメントのデフォルト挙動、mergeSchemaとoverwriteSchemaの違い、 Auto Loaderのスキーマエボリューションモード、MERGE INTOでのスキーマエボリューション、 Column Mapping、パーティション列の制約を整理します。

スキーマエンフォースメント（デフォルト挙動）

Delta Lakeのテーブルに書き込む際、書き込みデータのスキーマがテーブルのスキーマと一致しない場合、 デフォルトではエラーが発生して書き込みが拒否されます。これがスキーマエンフォースメントです。

• テーブルにないカラムが書き込みデータにある → エラー
• カラムの型が異なる（例: STRING vs INT） → エラー
• 書き込みデータにテーブルのカラムが欠けている → NULLで埋まる（エラーにはならない）

-- テーブル定義
CREATE TABLE events (event_id BIGINT, event_type STRING, amount DECIMAL(10,2));

-- 新しいカラム "region" を含むデータを書き込もうとするとエラー
INSERT INTO events
SELECT 1 AS event_id, 'purchase' AS event_type, 99.99 AS amount, 'APAC' AS region;
-- AnalysisException: cannot resolve 'region' given input columns

mergeSchema vs overwriteSchema 比較表

mergeSchema: カラム追加を許可する

# DataFrameの書き込み時にmergeSchemaを有効化
(df.write
  .format("delta")
  .mode("append")
  .option("mergeSchema", "true")
  .saveAsTable("events")
)

# SQLでセッション単位で有効化
SET spark.databricks.delta.schema.autoMerge.enabled = true;

# テーブルプロパティで永続的に有効化
ALTER TABLE events
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true');

mergeSchemaが許可する操作と許可しない操作の境界を理解することが試験で重要です。

overwriteSchema: スキーマの完全置換

# mode("overwrite") + overwriteSchema でスキーマを完全置換
(df.write
  .format("delta")
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .saveAsTable("events")
)

overwriteSchemaは破壊的な操作です。テーブルの既存データと互換性がなくなる可能性があるため、 本番環境では慎重に使うべきです。Time Travelで元のスキーマに戻すことは可能ですが、 新スキーマで書き込まれたデータは旧スキーマでは読めません。

Auto Loaderでのスキーマエボリューション

Auto Loaderは独自のスキーマ推論・エボリューション機能を持っています。cloudFiles.schemaEvolutionMode で挙動を制御します。

# Auto Loader + スキーマエボリューション
(spark.readStream
  .format("cloudFiles")
  .option("cloudFiles.format", "json")
  .option("cloudFiles.schemaEvolutionMode", "addNewColumns")
  .option("cloudFiles.schemaLocation", "/schema/events")
  .load("/landing/events/")
  .writeStream
  .option("checkpointLocation", "/checkpoint/events")
  .option("mergeSchema", "true")
  .table("bronze.events")
)

MERGE INTOでのスキーマエボリューション

MERGE INTO でもスキーマエボリューションが可能です。 ソースデータに新しいカラムがある場合、Spark設定を有効にするとターゲットテーブルにカラムが自動追加されます。

-- セッションレベルで有効化
SET spark.databricks.delta.schema.autoMerge.enabled = true;

-- ソースに "loyalty_tier" という新カラムがある場合
-- ターゲットに自動的に loyalty_tier カラムが追加される
MERGE INTO silver.customers t
USING staging.updates s
ON t.customer_id = s.customer_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

UPDATE SET *とINSERT *を使う場合のみスキーマエボリューションが動作します。 カラムを個別に指定するUPDATE SET t.col = s.col形式では、新カラムは追加されません。

Column Mapping（カラム名変更・削除）

Delta Lake 2.0以降では、Column Mapping機能によりカラム名の変更やカラムの削除がALTER TABLEで可能になりました。

-- Column Mappingの有効化
ALTER TABLE events SET TBLPROPERTIES (
  'delta.columnMapping.mode' = 'name',
  'delta.minReaderVersion' = '2',
  'delta.minWriterVersion' = '5'
);

-- カラム名の変更
ALTER TABLE events RENAME COLUMN event_type TO event_category;

-- カラムの削除
ALTER TABLE events DROP COLUMN temp_column;

パーティション列の変更制約

スキーマエボリューションにおいて、パーティション列には特別な制約があります。

• パーティション列の追加: 既存テーブルに新しいパーティション列を追加することはできない
• パーティション列の削除: Column Mappingが有効でも、パーティション列の削除は不可
• パーティション列の型変更: overwriteSchemaでも、パーティション列の型は変更できない
• パーティション列のリネーム: Column Mappingが有効であれば可能

パーティション構造を根本的に変更する場合は、テーブルの再作成（CTAS）が必要です。 これはLiquid Clusteringへの移行動機の一つでもあります。

試験で問われるポイント

• スキーマエンフォースメント: デフォルトで有効、スキーマ不一致は書き込み拒否
• mergeSchema: 新カラム追加と安全な型拡張のみ許可、カラム削除は不可
• overwriteSchema: スキーマの完全置換、破壊的操作
• Auto Loaderのスキーマエボリューションモードの違い（addNewColumns / failOnNewColumns / rescue / none）
• MERGE INTOでのスキーマエボリューション有効化方法（autoMerge設定 + SET *構文）
• Column Mapping: カラム名変更・削除に必要（delta.columnMapping.mode = 'name'）
• パーティション列の変更制約

問題で確認

よくある質問