Lakeflow パイプラインは、SQL および Python でバッチおよびストリーミング データ パイプラインを構築するための宣言型フレームワークを提供します。 これらの主要な概念は、パイプライン、フロー、ストリーミング テーブル、具体化されたビュー、シンクです。これらは連携して、自動オーケストレーションと増分更新を使用してデータを処理します。
Lakeflow パイプラインは、Apache Spark™ 宣言パイプライン (SDP) を拡張します。 SDP と Lakeflow パイプラインの比較の詳細については、「 Apache Spark 宣言型パイプライン」を参照してください。
Tip
パイプライン初心者ですか? まずは Lakeflowパイプラインの使い方 から始めて、パイプラインのライフサイクル全体をどのように使い、なぜ使うのかを理解し、各段階のタスクへのリンクを添えましょう。
Note
Lakeflow パイプラインには Premium プランが必要です。 詳細については、Databricks アカウント チームにお問い合わせください。
パイプラインの利点は何ですか?
Lakeflow ジョブを介した手動オーケストレーションを使用して Databricks ランタイムで Apache Spark および Spark Structured Streaming API を使用してデータ エンジニアリング プロセスを開発するのとは対照的に、パイプラインの宣言型の性質には次の利点があります。
- 自動オーケストレーション: パイプラインは、並列処理を最大にして正しい順序で処理ステップ ("フロー" と呼ばれます) を実行し、Spark タスクからフローまで、パイプライン全体に段階的に一時的なエラーを再試行します。
- 宣言型処理: 宣言型関数は、数百行の手動 Spark および構造化ストリーミング コードを少数に減らします。 AUTO CDC API は、SCD Type 1 や Type 2 を含む Change Data Capture (CDC) イベントを処理します。順序が正しく設定されていないイベントや、透かしなどのストリーミングの概念を手動でコード化する必要はありません。
- 増分処理: 増分処理 エンジンは具体化されたビューを最新の状態に保ちます。バッチ セマンティクスを使用して変換ロジックを記述し、可能な場合は新しいソース データまたは変更されたソース データのみを再処理します。
主な概念
次の図は、パイプラインの最も重要な概念を示しています。
データセット
パイプラインは、それぞれ異なる処理セマンティクスを持つ 3 種類のデータセットを生成します。
| データセットの型 | レコードの処理方法 |
|---|---|
| ストリーミング テーブル | 各レコードは、追加のみのソースを想定して、1 回だけ処理されます。 ストリーミング テーブルは、継続的に増加するデータのインジェストと増分処理に適しています。 |
| マテリアライズド・ビュー | 結果は、データの現在の状態を反映するために必要に応じて再計算されます。 具体化されたビューは、複数のダウンストリーム データセットで使用される変換、集計、または事前計算の結果に適しています。 |
| View | 必要に応じて評価され、永続化されません。 カタログに発行する必要のない中間変換とチェックにビューを使用します。 |
ストリーミング テーブルは、ストリーミング ターゲットでもある Unity カタログマネージド テーブルの形式です。 ストリーミング テーブルには、1 つ以上のストリーミング フロー (Append、 AUTO CDC) を書き込むことができます。 ストリーミング フローは、ターゲット ストリーミング テーブルとは明示的に個別に定義することも、ストリーミング テーブル定義の一部として暗黙的に定義することもできます。
具体化されたビューは、Unity カタログのマネージド テーブルの形式でもあり、バッチ ターゲットです。 具体化されたビューには、1 つ以上の具体化されたビュー フローを書き込むことができます。 具体化されたビューは、具体化されたビュー定義の一部としてフローを常に暗黙的に定義するという点で、ストリーミング テーブルとは異なります。
詳細については、 ストリーミング テーブル と 具体化されたビューを参照してください。
ビュー、具体化されたビュー、ストリーミング テーブルを使用する場合
パイプライン クエリを実装する場合は、ユース ケースに最適なデータセットの種類を選択します。
次の目的でビューの使用を検討してください:
- 大規模または複雑なクエリを、管理しやすいクエリに分割します。
- 期待値を使用して中間結果を検証します。
- 永続化する必要のない結果のストレージコストとコンピューティング コストを削減します。 テーブルは具体化されているため、追加の計算とストレージ リソースが必要です。
次の場合は、具体化されたビューの使用を検討してください。
- 複数のダウンストリーム クエリがテーブルを消費する。 具体化されたビューでは結果がキャッシュされるため、ダウンストリーム クエリは、各アクセスでクエリを再計算するのではなく、事前計算された結果を読み取ります。
- その他のパイプライン、ジョブ、クエリでテーブルを使用する。 具体化されたビューは Unity カタログ テーブルに具体化されるため、定義するパイプラインの外部のコンシューマーはクエリを実行できます。 ビューは具体化されないため、同じパイプライン内でのみ使用できます。
- 開発中にクエリの結果を検査する必要があります。 具体化されたビューは具体化され、パイプラインの外部で照会できるため、開発中に計算の正確性を検証できます。 検証後、具体化を必要としないクエリをビューに変換します。
- クエリが集計や結合を実行する場合、またはソース データが単に増え続けるだけでなく、更新や削除によって変更される可能性がある場合。 具体化されたビューでは、結果がソース データの現在の状態と一貫性を保ちますが、ストリーミング テーブルは追加専用のソース用に設計され、各レコードを 1 回処理します。
次の場合は、ストリーミング テーブルの使用を検討してください。
- クエリが、継続的またはインクリメンタルに増加しているデータ ソースに対して定義されている。
- クエリ結果はインクリメンタルに計算する必要がある。
- パイプラインは、スループットが高く待機時間が少ない必要があります。
Note
ストリーミング テーブルは、常にストリーミング ソースに対して定義されます。
AUTO CDC ... INTO でストリーミング ソースを使用して、CDC フィードから更新を適用することもできます。
「AUTO CDC API: パイプラインを使用して変更データ キャプチャを簡略化する」を参照してください。
Flows
フローはパイプラインの基本的なデータ処理の概念であり、ストリーミングセマンティクスとバッチ セマンティクスの両方をサポートします。 フローは、ソースからデータを読み取り、ユーザー定義の処理ロジックを適用して、結果をターゲットに書き込みます。 パイプラインは、Spark 構造化ストリーミングと同じストリーミング フローの種類 (追加、 更新、 完了) を共有します。 (現時点では、 追加 フローと 更新 フローのみが公開されています)。詳細については、 構造化ストリーミングの出力モードを参照してください。
パイプラインには、追加のフローの種類も用意されています。
- AUTO CDC は、順序が正しく処理されていない CDC イベントを処理する Lakeflow パイプライン内の一意のストリーミング フローであり、SCD タイプ 1 と SCD タイプ 2 の両方をサポートします。 自動 CDC は SDP では使用できません。
- 具体化されたビュー は、可能な限りソース テーブルの新しいデータと変更のみを処理するパイプラインのバッチ フローです。
詳細については、 Lakeflow パイプライン フローを使用したデータの増分読み込みと処理に関するページを参照してください。
Sinks
シンクはパイプラインのストリーミング ターゲットであり、Delta テーブル、Apache Kafka トピック、Azure EventHubs トピック、およびカスタム Python データ ソースをサポートします。 シンクには、1 つ以上のストリーミング フロー (追加、 更新) を書き込むことができます。
詳細については、「 Lakeflow パイプラインのシンク」を参照してください。
Pipelines
パイプラインは、開発と実行の単位であり、定義するフロー、ストリーミング テーブル、具体化されたビュー、シンクのコンテナーです。 パイプラインを構築するには、パイプラインのソース コードでこれらのオブジェクトを定義し、パイプラインを実行します。 パイプラインの実行中に、定義されたオブジェクトの依存関係が分析され、実行と並列化の順序が自動的に調整されます。
詳細については、「 パイプラインとは」を参照してください。
また、Lakeflow パイプラインの外部でスタンドアロンの具体化されたビューとストリーミング テーブルを定義することもできます。ここで、Azure Databricksはパイプラインを管理します。 2 つの方法を比較するには、「 スタンドアロン パイプラインと Lakeflow パイプライン」を参照してください。
パイプラインはトリガーモードか連続モードで動作し、新しいデータが届いた際に利用可能なデータの更新やテーブルの停止または新規のままにするかを制御します。 2つのモードを比較するには、 トリガーモードと連続パイプラインモードを参照してください。
データ インジェスト
パイプラインでは、Azure Databricks で使用できるすべてのデータ ソースがサポートされます。 Databricks では、大半のユース ケースにストリーミング テーブルを使用することを推奨しています。 クラウドオブジェクトストレージ内のファイルに対して、Auto Loader は増分かつべき等な読み込みを実現します。 ストリーミング データの場合、パイプラインは Apache Kafka、Azure Event Hubs、Amazon Kinesis、Google Pub/Sub などのメッセージ バスから直接取り込むことができます。 「パイプラインにデータを読み込む」を参照してください。
データ品質
Expectation は、パイプラインを流れるデータを検証するためにデータセットに対して定義する任意のルールです。 SQL ブール制約として期待値を定義し、レコードが失敗したときの動作 (警告、レコードの削除、更新の失敗) を指定します。 「パイプラインの期待値を使用してデータ品質を管理する」を参照してください。
差分統合
パイプラインによって作成および管理されるすべてのテーブルは Delta テーブルです。 ACID トランザクション、タイム トラベル、スキーマの適用など、Delta Lake と同じ保証があります。 パイプラインは、操作やOPTIMIZE操作など、VACUUMを使用してテーブル プロパティを追加し、自動メンテナンスを実行します。
Azure Databricks の Delta Lake とは何ですか？を参照してください。
