宣言型パターンを使用したレイクハウスにおけるSQL ETLのモダン化

Databricks は、Lakehouse でのデータウェアハウジングのワークフローに宣言的 ETL を導入し、SQL 実務担当者がすでに使い慣れている作業環境で複雑な変換ロジックを簡単に簡素化できるようにします。

これは、Apache Spark™ Declarative Pipelinesの背後にある宣言的実行モデルを、Databricks 全体のより多くの作成エクスペリエンスに導入するという、より広範な戦略の一部です。専用のパイプライン指向の環境で作業する必要はなく、SQL ユーザーは Databricks Lakehouse 内の SQL クエリで一般的な ETL パターンを直接定義できるようになります。

Lakehouse における繰り返しの ETL パターンの簡素化

Databricks における宣言的 SQL ETL は新しいものではありません。現在、何千人もの SQL ファーストのユーザーが、マテリアライズドビューやストリーミングテーブルなどの宣言的プリミティブをすでに利用して、繰り返しの変換を簡素化し、ダウンストリームテーブルを最新の状態に保ち、BI ワークロードを高速化しています。

多くの繰り返しの ETL パターンは、記述するのは簡単ですが、運用するのは困難であり、カスタム SQL ロジック、手動のスケジューリング、オーケストレーションの連携が必要になります。これらのパターンには、新しいレコードの追加、CDC 変更の適用、変更されたデータのみのリフレッシュなどが含まれます。

宣言的プリミティブが効果的なのは、テーブルを最新の状態に保つために必要なすべてのステップを手動でコーディングする代わりに、ユーザーが目的のテーブルやビューを記述できるからです。Databricks がスケジューリング、リフレッシュ、および該当する場合はインクリメンタル処理を処理するため、ユーザーはテーブルを最新の状態に保つために必要なロジックを手動でコーディングする必要はありません。

現在、この同じ宣言的アプローチを Lakeflow Pipelines エディターを超えて、データウェアハウスや SQL の実務担当者向けのより多くの繰り返しの ETL パターンへと拡張しています。これにより、Lakehouse ユーザーは（たとえば SQL エディター内で直接）目的の ETL パターンを定義できるようになり、Databricks がそれを確実に実行するために必要なインクリメンタル処理、更新ロジック、スケジューリング、オーケストレーションを処理します。

Lakehouse で利用可能な最初の宣言的プリミティブ

Lakehouse SQL エディターで利用可能な最初の宣言的オペレーションは、アペンド専用アップデート、変更データキャプチャ、バッチ上書きという 3 つの一般的な繰り返しの ETL パターンに対応しています。

これらのパターンの多くは、すでに Lakeflow の AUTO CDC などの宣言的 API を介して利用可能ですが、ここでの変化は、SQL アナリストが Lakehouse で直接これらにアクセスできるようにすることです。

これらのフローは、スケジュールに従ってリフレッシュしたり、アップストリームの更新によってトリガーしたり、オンデマンドで実行したり、Jobs の SQL タスクを通じてオーケストレーションしたりできます。

アペンド専用アップデート

アペンド専用アップデートは、今日の多くのストリーミングテーブルの背後にある標準的なパターンであり、ソースからターゲットテーブルに新しいレコードをインクリメンタルに追加するために使用されます。これらは、Auto Loader を使用してクラウドオブジェクトストレージから新しいレコードをロードするなどのインジェストワークロードで一般的に使用されます。

繰り返しのインサートロジックを記述してスケジュールする代わりに、SQL ユーザーは、ソース内の新しいデータと以前に処理されたデータを自動的に追跡するシンプルな APPEND フローを定義できます。Databricks が状態の追跡を処理し、新しいレコードが到着するとインクリメンタルに追加し、基盤となるサーバーレスパイプラインを自動的に管理します。

これにより、SQL ユーザーは、個別のパイプラインを手動で作成、スケジュール、または管理することなく、アペンド型のインジェストを簡単に運用できるようになります。

Lakehouse で APPEND フローを定義する方法を見る。

変更データキャプチャ

CDC パイプラインは、SQL ETL において最も一般的であり、かつ最も複雑なパターンの 1 つです。チームはインサート、アップデート、デリートを処理するために MERGE INTO をよく使用しますが、CDC データは順不同で到着する可能性があり、誤った結果を避けるために追加のロジックが必要になります。

AUTO CDC を使用すると、SQL ユーザーは Lakehouse で数行の宣言的コードを使用して CDC ロジックを定義できます。AUTO CDC を使用すると、複雑なマージパイプラインを手動で記述することなく、キー、シーケンス、削除処理、および結果を SCD タイプ 1 または SCD タイプ 2 として保存するかどうかを簡単に指定できます。

「bsport では、SQL AUTO CDC により、Databricks でのデータインジェストを管理するための、よりシンプルでモジュール化された方法が提供されました。テーブルのロードを単一のパイプラインから分離することで、プラットフォーム全体の可用性とデータの鮮度が向上しました。サードパーティからのデータを独立して処理できるため、障害管理が向上し、オーケストレーションの複雑さが軽減され、セットアップ全体の運用とスケーリングが容易になります。私たちのチームにとって、これにより、本番環境での信頼性が高く、よりクリーンで柔軟な SQL ベースのワークフローが構築されました。」—Adrien Marteau 氏（bsport、Head of Data）

SCD タイプ 1 およびタイプ 2 の AUTO CDC フローを作成する方法を見る。

バッチ上書き

一部のバッチ ETL ワークロードでは、日付範囲、パーティション、ビジネスセグメントなど、データの特定のサブセットのみをリフレッシュする必要があります。従来、チームはコストのかかる完全な再計算やカスタムの上書きロジックを使用してこれを処理することがよくありました。

REPLACE WHERE フローは、ターゲットを絞ったインクリメンタルなバッチ再計算のための宣言的パターンを Lakehouse にもたらします。ユーザーがターゲットテーブルに述語を定義すると、Databricks はその領域を自動的にリフレッシュします。Databricks の自動インクリメンタル化エンジンである Enzyme を使用すると、Databricks は、ターゲットテーブル全体を再計算したり、一致するスライス全体を書き換えたりする代わりに、可能な限り、指定された述語内で変更されたデータのみを特定して処理できます。

Lakehouse のベンチマークテストでは、Enzyme を搭載した REPLACE WHERE は、従来の REPLACE WHERE よりも 3.4 倍高速で、コストが 2.5 倍安くなりました。これは、選択的な再処理、スキーマの進化、バックフィル、およびより大きな履歴範囲を処理する前にデータの小さなウィンドウで反復処理を行う場合に便利です。

REPLACE WHERE フローを使用してテーブルのターゲットを絞ったサブセットをリフレッシュする方法を見る（コミュニティブログはこちら）。

要約：これが SQL 実務担当者にとって重要である理由

ETL の近代化には、完全な書き換えや、複雑なパイプラインフレームワークへの二者択一のコミットメントは必要ありません。既存の Lakehouse SQL オペレーションに宣言的セマンティクスを導入することで、最も合理的な場所で、既存のコードと近代化された宣言的 SQL を自由に組み合わせることができます。

カスタムタスク用に細かく調整された既存の手続き型 SQL クエリを維持しながら、アペンド専用インジェスト、AUTO CDC、ターゲットを絞ったバッチ上書きなどの宣言的オペレーションを、メンテナンスの手間がかかる繰り返しのパターンにシームレスに組み込むことができます。これにより、従来の SQL ロジックを完全に制御できると同時に、自動化された状態管理、依存関係の処理、必要に応じたスキーマの進化をすべて Lakehouse 内で直接実現するという、両方のメリットを享受できます。

宣言的プリミティブから完全な宣言的パイプラインへ

日常の SQL ワークフローに宣言的プリミティブを組み込むことは、個々のテーブルやインクリメンタルロジックを管理するための、実用的で摩擦の少ない出発点となります。プロジェクトの規模と複雑さが増すにつれて、開発ワークフローもそれに合わせて自然に進化させることができます。

複数の関連する変換、共有された依存関係、および本番ワークフローを管理するチーム向けに、Lakeflow Pipelines エディターは、複数ファイル開発、依存関係管理、パイプラインの可視化、統合された検証、および本番環境へのデプロイのサポートを備えた、宣言的 ETL のためのより豊かなプロジェクト指向の開発エクスペリエンスを提供します。

これは、ドメイン、データ製品、またはビジネスユニット全体で多くの関連する変換を管理するチームにとって特に便利です。バラバラのスクリプトを維持したり、すべてのロジックを 1 つの大規模なプロジェクトに集中させたりする代わりに、チームは Databricks 上で宣言的フローをガバナンスの効いたチーム所有のパイプラインに整理できます。Unity Catalog を使用すると、各チームは共有データアセットに基づいて構築し、一貫して権限を管理し、パイプラインやダウンストリームのコンシューマー全体の系統（リネージ）を把握できます。

SQL 実務担当者は、使い慣れた SQL エディターで宣言的フローから開始し、大規模なプロジェクト、より深いパイプライン管理、およびチームベースの開発のためにより構造化された環境が必要になったときに Pipelines エディターに移行できます。

Lakeflow Pipelines エディターを使用した宣言的 ETL ワークフローの構築について詳しくはこちらをご覧ください。

Genie Code を使用してより迅速に開始する

Genie Codeを使用すると、SQL実務担当者は、すでに使用しているワークフロー内でこれらの宣言型ETLパターンをより簡単に発見し、適用できるようになります。白紙の状態から始めたり、既存のSQLを手動で本番環境対応のパターンに変換したりする代わりに、ユーザーはGenie Codeに宣言型フローの生成、説明、調整の支援を求めることができます。

たとえば、CDCデータを扱うユーザーは、適切なキー、シーケンス列、削除処理、SCDタイプ1またはタイプ2の動作を含むAUTO CDCフローの作成をGenie Codeに支援してもらうことができます。定期的なバッチロジックを扱うユーザーは、既存の上書きロジックをインクリメンタルなREPLACE WHEREフローに変換するようGenie Codeに依頼できます。

宣言型ETLがより多くの作成エクスペリエンスで利用可能になるにつれて、Genie Codeは、ユーザーが目の前のタスクに適した宣言型パターンを選択できるようガイドします。

まずは、上記の各セクションにリンクされているドキュメントを確認してください。そして、SQL EditorでGenie Codeを使用して、APPENDフロー、AUTO CDCフロー、またはREPLACE WHEREフローによって既存のETLロジックを簡素化できる場所を特定しましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事