azure-recipe-user はじめに
2026年6月15日~18日サンフランシスコ・バーチャルにて、Databricks社主催の年間最大規模のカンファレンスイベント、「Databricks Data＋AI Summit 2026」（DAIS）が開催されました。
本記事はDAIS2026 Building Production-Grade SQL ETL on the Lakehouse で発表された、Databricks SQLだけで「本番運用に耐えるETL」をどう作るかを、初心者にもわかりやすく整理した内容になります。ETLは分析基盤の中でも最も壊れやすい部分とされてきましたが、本セッションではその常識を覆す「SQL-first」のアプローチが示されました。
本記事はDatabricks公式発表を元にした非公式の日本語要約であり、すべての著作権・知的財産権はDatabricksに帰属します。
忙しい方用
※セッション最後の「Three things to take home」スライドより
- ① AUTO CDC（GA）：約150行のSCD（緩やかに変化する次元）ロジックが、約10行のSQLに。MERGEの手書きが不要に。
- ② Incremental Replace Where（Beta）：変わった部分だけ再処理。従来のバッチ全件上書きより 3.4倍速く・2.5倍安い（TPC-DI）。
- ③ すべて既存のDeltaテーブルに書き込む：テーブル名・権限・下流の利用者はそのまま。ジョブを差し替えるだけで“その場で”モダナイズ。
いずれも「ETLを作り直す」のではなく「運用の負担をプラットフォームに任せる」という発想が共通しています。
このセッションのポイント
| 観点 | 内容 |
|---|---|
| 何が新しいか | ETLの「業務ロジック」ではなく「運用の配管（plumbing）」を自動化する宣言的な機能群 |
| 誰向けか | SQLでETLを書いている方／レガシーDWHから移行検討中の方／夜間バッチ運用に疲れている方 |
| 持ち帰れる示唆 | コードを減らすこと自体が信頼性・速度・コストに直結する。まず1レイヤーだけ置き換える移行も可能 |
| 従来との違い | 「命令型（手順を全部書く）」から「宣言型（結果だけ書く）」への転換 |
背景：ETLはなぜ壊れやすいのか
セッションでは、架空の旅行予約プラットフォーム「Wanderbricks」を題材に、メダリオンアーキテクチャ（Bronze -> Silver -> Gold -> Serving）の各レイヤーを「今日のやり方」と「モダナイズ後」で比較する形式で進行しました。
ポイントは一貫して 「業務ロジック自体はシンプル。複雑なのは運用の配管（plumbing）部分である」 という点です。処理済みファイルの追跡や、遅延・順不同で届くデータの扱い、夜間ロード失敗時のリカバリといった「本来やりたくない作業」こそが、ETLを壊れやすくしている真因だと指摘されました。
1. Silver層 ─ AUTO CDCでSCD Type2を150行から10行に
顧客プロフィールの変化を追跡する SCD Type2 は、データエンジニアにとって最も面倒なタスクの一つです。従来は複数のビュー・CTE・MERGEを組み合わせ、約150行の壊れやすいコードが必要でした。とくに MERGE は、順序が乱れて届いたレコードに対して正しく動かすための追加ロジックが必要になるケースが多いです。
これを宣言的な AUTO CDC に置き換えると、約10行で完結します。SCD Type1 と Type2 の切り替えも宣言一つで済むため、エンジニアは面倒な処理に時間を割くことなく、実現したいことに集中できます。
AUTO CDCはこれまで APPLY CHANGES として提供されていたAPIを置き換える新しい推奨APIです。CDCフィードからの変更を自動処理し、SCD Type1/Type2の計算の複雑さを自動化します。今回 GA（一般提供） となりました。
公式ドキュメント：The AUTO CDC APIs
2. Gold層 ─ Incremental Replace Whereで速く、安く
従来のREPLACE WHERE
Gold層で予約データをエンリッチする際、従来は「ステージングテーブル＋手動ウォーターマーク＋上書きジョブ」を手配線していました。問題は、変わっていない行まで含めて、対象ウィンドウ全体を書き直す点です。データ量が増えるほど、この「無駄な書き直し」がコストと処理時間を押し上げる枷となっていました。
|
1 2 3 4 5 6 7 8 9 10 11 |
-- 従来パターン：ウォーターマーク以降のスライス全体を再計算 CREATE OR REPLACE TABLE bookings_enriched AS SELECT b.booking_id, b.customer_id, b.booking_dt, b.amount, c.customer_tier FROM booking_tf_v b JOIN customers_dim c ON b.customer_id = c.customer_id WHERE b.booking_dt >= watermark_dt; -- 上書きジョブ INSERT INTO bookings_enriched REPLACE WHERE booking_dt >= watermark_dt SELECT * FROM bookings_enriched; |
新機能：変わった行だけを更新する
新機能 Incremental Replace Where（Beta） では、AI最適化エンジン Enzyme が実際に変わった行だけを特定して処理します。書き手は対象ウィンドウを指定するだけで、増分計算はエンジンが自動で担ってくれます。
|
1 2 3 4 5 6 |
CREATE OR REFRESH STREAMING TABLE bookings_enriched SCHEDULE EVERY 1 DAY FLOW REPLACE WHERE booking_dt >= date_sub(current_date(), 7) BY NAME SELECT b.booking_id, b.customer_id, b.booking_dt, b.amount, c.customer_tier FROM booking_tf_v b JOIN customers_dim c ON b.customer_id = c.customer_id; |
得られるもの（WHAT YOU GET)
- スケジュール更新：更新時・毎日・毎時・cronに対応
- 全件上書きを行わない：書き直しはウィンドウ内に限定
- 自動増分化：Enzymeが変わった行だけを修正
速いリフレッシュ以上の価値
Incremental Replace Whereは、時間的に速いだけではなく、運用上ありがちな「特定範囲だけ直したい」「過去分をまとめて入れ直したい」といったニーズにも、宣言的に応えられます。
| 特徴 | 内容 |
|---|---|
| Performance boost | Enzymeが変更分だけ処理するため、従来より安く・速い |
| Targeted corrections | 特定の行・列（例：ある1日分の予約）だけをウィンドウ全体を書き直さずに修正 |
| Arbitrary DML | フロー外部からのINSERT/UPDATE/DELETEも尊重 |
| Backfills | 述語オーバーライドで初期ロードや再処理の履歴リロードに対応 |
イメージ図とベンチマーク
従来は対象ウィンドウの全行（×OVERWRITE）を書き直すのに対し、Incremental版は実際に変わった行だけに触れます。この差は、データ規模が大きくなるほど影響が大きくなります。
そしてベンチマーク結果（TPC-DI）はこのようになっています。
- 3.4 倍速くなる
- 2.5 倍安くなる
3. Serving層 ─ マテリアライズドビューで配信を高速化
通常のビューの弱点
レポート用データセットを通常のビュー（またはメトリックビュー）で作ると、ダッシュボードを開くたびにクエリ全体を再計算します。つまり利用者が増えるほど、同じ計算が何度も繰り返される構造的な無駄が生まれてしまいます。
欠点（DOWNSIDES）
- ダッシュボード読み込みのたびに全クエリを再計算
- データ利用者が増えるほどコストが線形に増加
- 変わった部分だけ処理する手段がない
マテリアライズドビューで解決
これを MATERIALIZED VIEW にすると、事前計算された結果を返すため大幅に高速化されます。リフレッシュもEnzymeによる増分処理が効くため、最新性とコスト効率を同時に実現できます。
|
1 2 3 4 5 6 |
CREATE OR REFRESH MATERIALIZED VIEW top_customer TRIGGER ON UPDATE AS SELECT customer_id, customer_tier, sum(amount) AS total_spend, booking_dt FROM bookings_enriched GROUP BY customer_id, customer_tier, booking_dt; |
- BIクエリを高速化：ベーステーブル直接照会より劇的に高速
- Enzymeによる増分リフレッシュ：変更分だけを処理し、高コストな全再計算を回避
- 宣言的かつフルガバナンス：SELECTを書くだけ。リフレッシュはエンジン任せ、Unity Catalogのリネージ・アクセス制御も完備
スタンドアロンのマテリアライズドビューは、Databricks SQLウェアハウスやサーバーレスのNotebookから作成・リフレッシュでき、クエリ結果を物理的に保存（事前計算・キャッシュ）してETL処理の性能向上とコスト削減を実現します。
公式ドキュメント：Use standalone materialized views | Databricks on AWS
運用のモダナイズ ─ Flowという新しい単位（近日提供）
ここからセッションは 「Operational modernization（02）」 の内容になります。ここまで紹介した3機能を支える共通の土台が、このFlowという考え方です。
Flowとは何か
Flow は、Unity Catalogに保存される“名前付き・状態を持つクエリ”で、テーブルを最新に保つために繰り返し実行されるものです。これまで手書きしていた状態管理を、プラットフォーム側に委ねられるのが本質的な価値です。3種類が紹介されました。
- Append flow
- AUTO CDC flow
- Replace Where flow
| 特徴 | 内容 |
|---|---|
| デフォルトで増分 | マネージドなオフセットとクエリ状態で、Enzymeが変わった分だけ処理。手書きの増分ロジック不要 |
| チェックポイント管理 | テーブル全体の巻き戻しや堅牢な障害復旧。ストリーミングのチェックポイントを複製 |
| スケジュール/オンデマンド | 中断地点から常に再開 |
| Unity Catalogに専用ページ | 定義・スケジュール・最終実行を一箇所で確認 |
ポイントは 「Notebook・SQLエディタ・サーバーレスのどこでも同じ宣言的ETLプリミティブとして使える」 ことです。
既存テーブルにその場で書き込む
Flowの最大の魅力は、既存テーブルをそのまま使える点です。移行のためにテーブルや権限を作り直す必要がないため、現実の本番環境でも段階的に導入しやすくなっています。
- Flows target real tables：AUTO CDCもREPLACE WHEREも、既存のUnity Catalogテーブルに直接書き込む（別パイプラインではない）
- Modernize in place：テーブル名・権限・下流利用者はそのまま。ジョブを差し替えるだけでテーブル再作成は不要
- Streaming tables become tables：「ストリーミングテーブル」と「Deltaテーブル」の境界はなくなり、すべて単なるテーブルに
モダナイズはすべて、すでに持っているウェアハウスの中で完結します。
Wanderbricksのレイヤーを丸ごとモダナイズ
ここからデモンストレーションが始まり、Wanderbricksのレイヤーを丸ごとモダナイズする工程が実演されました。
デモを通じて、メダリオンの全レイヤーが宣言的な形に置き換わりました。注目すべきは、業務ロジックには一切手を加えず、運用の配管部分だけをプラットフォームに委ねたところです。
| レイヤー | 使う機能 | 対象テーブル | ポイント |
|---|---|---|---|
| Bronze | Auto Loader | bookings_stg |
手動状態管理なしの取り込み |
| Silver | AUTO CDC | customers_dim |
SCD2次元を宣言的に。MERGE不要 |
| Gold | Incremental REPLACE WHERE | bookings_enriched |
変わったウィンドウだけ再エンリッチ |
| Serving | Materialized View | top_customer |
ダッシュボード用に高速・最新 |
- 同じテーブル・同じUnity Catalogガバナンスを全レイヤーで維持したまま、コードは大幅に減り、コストは目に見えて安くなる
今年の特徴・従来との違い
| 従来（命令型） | 今年の提案（宣言型） | |
|---|---|---|
| 書き方 | 処理手順を1行ずつ書く | 欲しい結果だけ書く |
| 状態管理 | 手動（ウォーターマーク等） | Flowが自動管理 |
| SCD Type2 | 約150行 | 約10行（AUTO CDC） |
| バッチ上書き | ウィンドウ全件書き直し | 変更行のみ（Enzyme） |
| 配信 | ビューで毎回再計算 | マテリアライズドビューで事前計算 |
| 移行方法 | テーブル再作成が必要 | 既存テーブルのままジョブ差し替え |
DAISでは近年「消費（BI/AI）」や「エージェント」が注目されてきましたが、今年のこのセッションは最も壊れやすいETLの“運用配管”を、SQLだけで本番品質にするという、極めて実務的なテーマに踏み込んでいました。話題を集めやすい派手な新機能というより、現場視点での地道な負担を減らす質の部分に焦点が当たっていた点が印象的でした。
まとめ
- AUTO CDCがMERGEロジックを簡素化：約150行のSCDロジックが約10行のSQLに。（GA）
- Incremental REPLACE WHEREで高速なバッチ上書き：変わったスライスだけ再エンリッチ。（Beta）
- すべて既存のDeltaテーブルに書き込む：その場でモダナイズ。同じUnity Catalogテーブル・権限・利用者のまま、ジョブを差し替えるだけ。
本セッションは、「ETLを全部書き直す必要はなく、まず1レイヤーだけ宣言型に置き換えてみることから始める」というように、その第一歩のハードルを大きく下げてくれる内容でした。手元のレガシーETLのうち、どこから宣言型に寄せられるかを考えるきっかけにしてみてはいかがでしょうか。
お知らせ
ナレッジコミュニケーションでは、Databricks Data + AI Summit 2026 開催に伴い、日本語でのウェビナーや現地レポートを公開しております！
DAIS2026 Recap イベント
現地参加が難しかった方や、主要トピックスを短時間で振り返りたい方向けに、Recapイベントを開催します。
セッションの要点整理や、日本企業での実装観点も交えてご紹介予定です。
▼ 開催概要・お申し込みはこちら
ナレッジコミュニケーション DAIS2026 特設サイト
DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。
イベント情報の整理・社内共有にもご活用いただけます。
Databricks 導入支援サービスサイト
Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。
databricks.kc-cloud.jp参考文献
- Building Production-Grade SQL ETL on the Lakehouse | Databricks
- The AUTO CDC APIs: Simplify change data capture with pipelines | Databricks on AWS
- Use standalone materialized views | Databricks on AWS
- Optimizing Materialized Views Recomputes | Databricks Blog
- Use standalone materialized views – Azure Databricks | Microsoft Learn
- ETL in Databricks SQL | Databricks on AWS
