Delta Constraintsで実現する品質制御｜NOT NULL・CHECK・DLT Expectations比較

データパイプラインで「NULLが入ってはいけないカラムにNULLが入った」「負の金額が紛れ込んだ」 といった品質問題は、下流のレポートやMLモデルに波及して大きな手戻りを引き起こします。 Delta Constraintsは、テーブルレベルでデータ品質のルールを定義し、違反する書き込みを 自動的に拒否する仕組みです。

この記事では、NOT NULL制約とCHECK制約のSQL構文、DLT Expectationsとの使い分け、 制約の確認・削除方法、ストリーミング書き込み時の挙動、そして試験対策ポイントを整理します。

NOT NULL 制約

最もシンプルな制約です。指定したカラムにNULL値の書き込みを禁止します。

-- テーブル作成時に NOT NULL を指定
CREATE TABLE prod.silver.orders (
  order_id BIGINT NOT NULL,
  customer_id BIGINT NOT NULL,
  amount DECIMAL(10,2) NOT NULL,
  status STRING,
  created_at TIMESTAMP NOT NULL
);

-- 既存テーブルにNOT NULL制約を追加
ALTER TABLE prod.silver.orders
ALTER COLUMN status SET NOT NULL;

-- NOT NULL制約の削除
ALTER TABLE prod.silver.orders
ALTER COLUMN status DROP NOT NULL;

既存テーブルにNOT NULLを追加する場合、既にNULL値が存在するとALTER TABLEが失敗します。 事前にNULL行をUPDATEまたはDELETEで処理してから制約を追加してください。

CHECK 制約

CHECK制約はSQL式による条件を定義し、条件に違反する行の書き込みを拒否します。 複数のCHECK制約を同一テーブルに定義でき、すべての制約を満たす行のみが書き込まれます。

-- CHECK制約の追加（名前付き）
ALTER TABLE prod.silver.orders
ADD CONSTRAINT chk_amount_positive CHECK (amount > 0);

ALTER TABLE prod.silver.orders
ADD CONSTRAINT chk_status_valid CHECK (status IN ('pending', 'shipped', 'delivered', 'cancelled'));

ALTER TABLE prod.silver.orders
ADD CONSTRAINT chk_created_after_2020 CHECK (created_at >= '2020-01-01');

-- 複合条件のCHECK制約
ALTER TABLE prod.silver.orders
ADD CONSTRAINT chk_cancelled_has_reason CHECK (
  status != 'cancelled' OR cancel_reason IS NOT NULL
);

-- CHECK制約の削除
ALTER TABLE prod.silver.orders
DROP CONSTRAINT chk_amount_positive;

制約違反が発生すると、トランザクション全体がロールバックされます。 バッチ書き込みで1行でも違反があると、バッチ全体の書き込みが拒否されます。

制約の確認方法

-- テーブルの制約一覧を確認
DESCRIBE DETAIL prod.silver.orders;
-- properties列のdelta.constraints.xxx に制約定義が格納される

-- テーブル情報からNOT NULLを確認
DESCRIBE TABLE prod.silver.orders;
-- nullable列にfalseと表示されるカラムがNOT NULL制約付き

-- テーブルプロパティとして確認
SHOW TBLPROPERTIES prod.silver.orders;
-- delta.constraints.chk_amount_positive = 'amount > 0'
-- delta.constraints.chk_status_valid = 'status IN ...'

DLT Expectations との比較

-- DLT Expectationsの例（参考）
CREATE OR REFRESH STREAMING LIVE TABLE silver_orders (
  CONSTRAINT valid_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT valid_status EXPECT (status IS NOT NULL) ON VIOLATION FAIL UPDATE
)
AS SELECT * FROM STREAM(LIVE.bronze_orders);

ストリーミング書き込み時の挙動

Structured Streamingでマイクロバッチ書き込みを行う際も、Delta Constraintsは有効です。 マイクロバッチ内に制約違反の行が含まれると、そのバッチ全体がロールバックされ、 ストリームはエラーで停止します。

• foreachBatch内でMERGEを実行する場合も制約チェックが適用される
• Auto Loaderからの書き込みでも制約チェックが動作する
• ストリーム停止後は、違反データの原因を修正してストリームを再起動する必要がある

ストリーミングパイプラインでは、Delta Constraintsの「fail only」挙動が厳しすぎる場合があります。 DLT ExpectationsのDROP ROWで不良レコードを除外し、Delta Constraintsは「最後の安全ネット」として 残すのが実務上のベストプラクティスです。

制約設計のベストプラクティス

• 主キー相当のカラム（order_id等）にはNOT NULLを必ず設定する
• 金額・数量にはCHECK制約で正の値を強制する（amount > 0）
• ステータス値にはIN句でENUM的な制約を定義する
• 制約名は分かりやすく命名する（chk_プレフィックスを推奨）
• 既存テーブルに制約を追加する前に、違反データの有無を事前チェックする
• DLT ExpectationsのDROP ROWと併用して多層防御を構成する

-- 既存データの違反チェック（制約追加前に実行）
SELECT COUNT(*) AS violation_count
FROM prod.silver.orders
WHERE amount <= 0;

SELECT COUNT(*) AS null_count
FROM prod.silver.orders
WHERE customer_id IS NULL;

試験で問われるポイント

• NOT NULLとCHECK制約の構文（ALTER TABLE ... ADD CONSTRAINT）
• 制約違反時の挙動: トランザクション全体がロールバックされる
• DLT Expectationsとの違い: 適用スコープと違反時動作の柔軟性
• CHECK制約で使えない式: サブクエリ、集約関数、UDF
• 制約の確認方法: DESCRIBE DETAIL / SHOW TBLPROPERTIES
• ストリーミング時にも制約が有効であること

問題で確認

よくある質問