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