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