Lakeflow 宣言型パイプラインとは何か、それを定義する主要な概念 (パイプライン、ストリーミング テーブル、具体化されたビューなど)、それらの概念間のリレーションシップ、およびデータ処理ワークフローで使用する利点について説明します。
注
Lakeflow 宣言型パイプラインには、 Premium プランが必要です。 詳細については、Databricks アカウント チームにお問い合わせください。
Lakeflow 宣言型パイプラインとは何ですか
Lakeflow 宣言型パイプラインは、SQL および Python でバッチ およびストリーミング データ パイプラインを開発および実行するための宣言型フレームワークです。 Lakeflow 宣言型パイプラインはパフォーマンス最適化 Databricks ランタイム (DBR) で実行され、Lakeflow 宣言パイプライン flows API では、Apache Spark および構造化ストリーミングと同じ DataFrame API が使用されます。 Lakeflow 宣言型パイプラインの一般的なユース ケースには、クラウド ストレージ (Amazon S3、Azure ADLS Gen2、Google Cloud Storage を含む) やメッセージ バス (Apache Kafka、Amazon Kinesis、Google Pub/Sub、Azure EventHub、Apache Pulsar など) からの増分データ インジェスト、ステートレス演算子とステートフル 演算子を使用した増分バッチ変換とストリーミング変換、メッセージ バスやデータベースなどのトランザクション ストア間のリアルタイム ストリーム処理などがあります。
宣言型データ処理の詳細については、「 Databricks での手続き型データ処理と宣言型データ処理」を参照してください。
Lakeflow デクラレーティブ パイプラインの利点は何ですか?
Lakeflow 宣言型パイプラインの宣言型の性質は、 Apache Spark および Spark Structured Streaming API を使用してデータ パイプラインを開発し、 Lakeflow ジョブを介して手動オーケストレーションを使用して Databricks ランタイムで実行する場合と比較して、次の利点を提供します。
- 自動オーケストレーション: Lakeflow 宣言パイプラインでは、処理手順 ("フロー" と呼ばれます) が自動的に調整され、最適なパフォーマンスを得るために、正しい実行順序と並列処理の最大レベルが確保されます。 さらに、Lakeflow 宣言パイプラインは、一時的なエラーを自動的かつ効率的に再試行します。 再試行プロセスは、最も細かくコスト効率の高い単位である Spark タスクから始まります。 タスク レベルの再試行が失敗した場合、Lakeflow 宣言パイプラインはフローの再試行に進み、必要に応じて最後にパイプライン全体を再試行します。
- 宣言型処理: Lakeflow 宣言型パイプラインは、数百行または数千行の手動 Spark および構造化ストリーミング コードを数行のみに減らすことができる宣言型関数を提供します。 Lakeflow 宣言パイプライン AUTO CDC API は、SCD タイプ 1 と SCD タイプ 2 の両方をサポートすることで、変更データ キャプチャ (CDC) イベントの処理を簡略化します。 これにより、順序が誤ったイベントを処理するための手動コードの必要がなくなります。また、ストリーミング セマンティクスやウォーターマークなどの概念を理解する必要はありません。
- 増分処理: Lakeflow 宣言パイプラインは、具体化されたビュー用の 増分処理 エンジンを提供します。 これを使用するには、バッチ セマンティクスを使用して変換ロジックを記述します。エンジンは、可能な限り新しいデータと変更のみをデータ ソースで処理します。 増分処理により、ソースで新しいデータや変更が発生した場合の非効率的な再処理が減り、増分処理を処理する手動コードが不要になります。
主要概念
次の図は、Lakeflow 宣言パイプラインの最も重要な概念を示しています。
フロー
フローは、ストリーミングセマンティクスとバッチ セマンティクスの両方をサポートする Lakeflow 宣言パイプラインの基本的なデータ処理の概念です。 フローは、ソースからデータを読み取り、ユーザー定義の処理ロジックを適用して、結果をターゲットに書き込みます。 Lakeflow 宣言型パイプラインは、Spark 構造化ストリーミングと同じストリーミング フローの種類 (追加、 更新、 完了) を共有します。 (現時点では、 追加 フローのみが公開されています)。詳細については、 構造化ストリーミングの出力モードを参照してください。
Lakeflow 宣言パイプラインには、追加のフローの種類も用意されています。
- AUTO CDC は、順序の異なった CDC イベントを処理し、SCD タイプ 1 と SCD タイプ 2 の両方をサポートする、Lakeflow 宣言型パイプラインの一意のストリーミング フローです。
- 具体化されたビュー は、可能な限りソース テーブルの新しいデータと変更のみを処理する、Lakeflow 宣言パイプラインの一意のバッチ フローです。
詳細については、以下を参照してください。
ストリーミング テーブル
ストリーミング テーブルは、Lakeflow 宣言型パイプラインのストリーミング ターゲットでもある Unity カタログマネージド テーブルの形式です。 ストリーミング テーブルには、1 つ以上のストリーミング フロー (Append、 AUTO CDC) を書き込むことができます。 AUTO CDC は、ストリーミング テーブルでのみ使用できる一意のストリーミング フローです。 ストリーミング フローは、ターゲット ストリーミング テーブルとは別に明示的に定義できます。 ストリーミング フローは、ストリーミング テーブル定義の一部として暗黙的に定義することもできます。
詳細については、以下を参照してください。
マテリアライズド・ビュー
具体化されたビューは、Unity カタログのマネージド テーブルの形式でもあり、バッチ ターゲットです。 具体化されたビューには、1 つ以上の具体化されたビュー フローを書き込むことができます。 具体化されたビューは、具体化されたビュー定義の一部としてフローを常に暗黙的に定義するという点で、ストリーミング テーブルとは異なります。
詳細については、以下を参照してください。
シンク
シンクは、Lakeflow 宣言型パイプラインのストリーミング ターゲットであり、現在、Delta テーブル、Apache Kafka トピック、および Azure EventHubs トピックをサポートしています。 シンクには、1 つ以上のストリーミング フロー (追加) を書き込むことができます。
詳細については、以下を参照してください。
パイプライン
パイプラインは、Lakeflow 宣言パイプラインでの開発と実行の単位です。 パイプラインには、1 つ以上のフロー、ストリーミング テーブル、具体化されたビュー、シンクを含めることができます。 Lakeflow 宣言型パイプラインを使用するには、パイプラインのソース コードでフロー、ストリーミング テーブル、具体化されたビュー、シンクを定義し、パイプラインを実行します。 パイプラインの実行中に、定義されたフロー、ストリーミング テーブル、具体化されたビュー、シンクの依存関係を分析し、実行と並列化の順序を自動的に調整します。
詳細については、以下を参照してください。
Lakeflow 向けの Databricks SQL 宣言型パイプライン
Lakeflow 宣言型パイプラインは、Databricks SQL の 2 つの基本的な ETL 機能としてストリーミング テーブルと具体化されたビューを提供します。 Databricks SQL で標準 SQL を使用して、ストリーミング テーブルと具体化されたビューを作成および更新できます。 Databricks SQL のストリーミング テーブルと具体化されたビューは、同じ Databricks インフラストラクチャ上で実行され、Lakeflow 宣言型パイプラインと同じ処理セマンティクスを持ちます。 Databricks SQL でストリーミング テーブルと具体化されたビューを使用する場合、フローはストリーミング テーブルと具体化されたビュー定義の一部として暗黙的に定義されます。
詳細については、以下を参照してください。