What are LakeFlow Pipelines?
LakeFlow Pipelinesは、SQLとPythonでバッチおよびストリーミングのデータパイプラインを構築するための宣言型フレームワークを提供します。その主要な概念は、パイプライン、フロー、ストリーミングテーブル、マテリアライズドビュー、およびシンクであり、これらは連携して自動オーケストレーションと増分更新によりデータを処理します。
LakeFlow Pipelines は、Apache Spark™ 宣言型パイプライン (SDP) を拡張したものです。SDP と LakeFlow Pipelines との比較について詳しくは、Apache Spark 宣言型パイプラインを参照してください。
パイプラインの利点は何ですか？
Apache Spark と Spark Structured Streaming APIs を Databricks Runtime 上で Lakeflow Jobs による手動のオーケストレーションを使用してデータエンジニアリングプロセスを開発する場合と比べると、パイプラインの宣言的な特性には次の利点があります。
- 自動オーケストレーション ：パイプラインは、処理ステップ（「フロー」と呼ばれます）を正しい順序で最大限の並列度で実行し、一時的な障害を段階的に再試行します。Spark タスクからフローへ、さらにパイプライン全体へと順に再試行します。
- 宣言型処理 : 宣言型関数は、数百行の手動SparkおよびStructured Streamingコードを数行に削減します。AUTO CDC APIは、SCD Type 1とType 2を含むチェンジデータキャプチャ(CDC)イベントを、順不同イベントの手動コードや、ウォーターマークのようなストリーミングの概念なしに処理します。
- インクリメンタル処理: インクリメンタル処理 エンジンは、マテリアライズドビューを最新の状態に保ちます。バッチセマンティクスで変換ロジックを記述すると、エンジンは可能な場合にのみ新規または変更されたソースデータを再処理します。
主要な概念
以下の図は、パイプラインの最も重要な概念を示しています。
データセット
パイプラインは、それぞれ異なる処理セマンティクスを持つ3種類のデータセットを生成します：
データセットのタイプ | レコードの処理方法 |
|---|---|
ストリーミングテーブル | 各レコードは一度だけ処理されます。これは、追加専用のソースを前提としています。ストリーミングテーブルは、継続的に増加するデータの取り込みと増分処理に適しています。 |
マテリアライズドビュー | 必要に応じて結果が再計算され、データの現在の状態が反映されます。マテリアライズドビューは、複数のダウンストリームデータセットで利用される結果の変換、集計、または事前計算に適しています。 |
ビュー | オンデマンドで評価され、永続化されません。カタログに公開する必要がない中間変換とチェックには、ビューを使用します。 |
ストリーミングテーブル は、ストリーミングターゲットでもある Unity Catalog マネージドテーブルの形式です。ストリーミングテーブルには、1 つ以上のストリーミングフロー（ Append 、 AUTO CDC ）を書き込むことができます。ストリーミングフローを、ターゲットストリーミングテーブルとは別に明示的に定義することも、ストリーミングテーブル定義の一部として暗黙的に定義することもできます。
マテリアライズドビュー は、Unity Catalog マネージドテーブルの形式であり、バッチ ターゲットでもあります。マテリアライズドビューには、1 つ以上のマテリアライズドビューフローを書き込むことができます。マテリアライズドビューがストリーミングテーブルと異なるのは、常にマテリアライズドビューの定義の一部としてフローを暗黙的に定義する点です。
詳細については、ストリーミングテーブルおよびマテリアライズドビューを参照してください。
ビュー、マテリアライズドビュー、ストリーミングテーブルをどのような場合に使用するのか
パイプライン クエリを実装する際は、ユースケースに最適なデータセットの種類を選択してください。
ビューの使用を検討してください：
- 大規模または複雑なクエリを、より管理しやすいクエリに分割してください。
- エクスペクテーションを使用して中間結果を検証します。
- 永続化が不要な結果のストレージとコンピュート・コストを削減します。テーブルが具体化されるため、追加のコンピューティングおよびストレージリソースが必要となります。
マテリアライズドビューは、次の場合に使用を検討してください。
- 複数のダウンストリームクエリがテーブルを使用します。マテリアライズドビューはその結果をキャッシュするため、ダウンストリームクエリは、アクセスごとにクエリを再計算する代わりに、事前に計算された結果を読み込みます。
- 他のパイプライン、ジョブ、またはクエリがそのテーブルを利用します。マテリアライズドビューは Unity Catalog テーブルとしてマテリアライズされるため、それを定義するパイプラインの外部にあるコンシューマはそれをクエリできます。ビューはマテリアライズされないため、同じパイプライン内でのみ使用できます。
- 開発中にクエリの結果を検査したい場合があります。マテリアライズドビューは具体化されており、パイプラインの外部からクエリを実行できるため、開発中に計算の正確性を検証できます。検証後、具体化を必要としないクエリをビューに変換します。
- クエリが集計または結合を実行する場合、あるいはソースデータが追加されるだけでなく、更新や削除によって変更される可能性があります。マテリアライズドビューは、その結果をソースデータの現在の状態と一貫させます。一方、ストリーミングテーブルは追記専用のソース向けに設計されており、各レコードを1回処理します。
次のような場合は、ストリーミングテーブルの使用を検討してください。
- クエリーは、継続的または段階的に増加するデータソースに対して定義されます。
- クエリー結果は増分的にコンピュートされるべきです。
- パイプラインは高スループットと低レイテンシを必要とします。
ストリーミングテーブルは、常にストリーミング ソースに対して定義されます。 また、 AUTO CDC ... INTO でストリーミング ソースを使用して、CDC フィードからの更新を適用することもできます。「AUTO CDC APIs : パイプラインによる変更データ キャプチャの簡素化」を参照してください。
フロー
フローは、パイプラインにおける基本的なデータ処理の概念であり、ストリーミングおよびバッチセマンティクスの両方をサポートしています。フローは、ソースからデータを読み取り、ユーザー定義の処理ロジックを適用して、結果をターゲットに書き込みます。パイプラインは、Spark Structured Streaming と同じストリーミングフローのタイプ（ 追加 、 更新 、 完了 ）を共有します。（現在、 追加 フローと 更新 フローのみが公開されています。）詳細については、Structured Streaming の出力モードを参照してください。
パイプラインは、追加のフロータイプも提供します。
- AUTO CDC は、順序外れのCDCイベントを処理し、SCD Type 1 とSCD Type 2 の両方をサポートするLakeFlow Pipelines独自のストリーミングフローです。Auto CDC はSDPでは利用できません。
- マテリアライズドビュー は、パイプラインにおけるバッチフローであり、可能な限り新しいデータとソーステーブルの変更のみを処理します。
詳細については、LakeFlow Pipelines を使用してデータを増分的にロードおよび処理するを参照してください。
シンク
シンク はパイプラインのストリーミング ターゲットであり、Delta テーブル、Apache Kafka トピック、Azure EventHubs トピック、およびカスタム Python データソースをサポートしています。シンクには、1つ以上のストリーミングフロー ( Append , Update ) を書き込むことができます。
詳細については、Lakeflow pipelinesを参照してください。
パイプライン
「パイプライン」とは、開発と実行の単位であり、定義するフロー、ストリーミングテーブル、マテリアライズドビュー、シンクを格納するコンテナです。パイプラインソースコードでこれらのオブジェクトを定義し、パイプラインを実行することで、パイプラインを構築します。パイプラインの実行中に、定義されたオブジェクトの依存関係を分析し、実行順序と並列化を自動的にオーケストレーションします。
詳細については、「パイプラインとは？」を参照してください。
You can also define standalone マテリアライズドビュー and ストリーミングテーブル outside a Lakeflow pipeline, where Databricks manages the パイプライン for you.2つのアプローチを比較するには、スタンドアロンパイプラインとLakeflow pipelinesの比較を参照してください。
データ取り込み
パイプラインは、Databricksで利用可能なすべてのデータソースをサポートしています。Databricksでは、ほとんどのインジェストのユースケースでストリーミングテーブルを使用することをお勧めします。クラウドオブジェクトストレージ内のファイルについては、Auto Loader は段階的かつべき等な読み込みを提供します。ストリーミングデータの場合、パイプラインは Apache Kafka、Azure Event Hubs、Amazon Kinesis、Google Pub/Sub などのメッセージバスから直接取り込むことができます。「パイプラインでデータをロードする」を参照してください。
データ品質
期待値とは、データセットに付加されるオプションの条項であり、データがパイプラインを通過する際にその妥当性を検証するものです。期待値はSQLのBoolean制約として定義し、レコードが失敗した場合に何が起こるかを指定します。警告を表示する、レコードを削除する、または更新を失敗させる、といった具合です。パイプラインの期待値に基づいてデータ品質を管理する方法については、「パイプラインの期待値に基づいてデータ品質を管理する」を参照してください。
Delta 統合
パイプラインによって作成および管理されるすべてのテーブルはDeltaテーブルとなります。Delta Lake と同様に、ACIDトランザクション、タイムトラベル、スキーマ強制といった保証を備えています。パイプラインは追加のテーブルプロパティを追加し、予測的最適化を使用して自動メンテナンスを実行します。これには、OPTIMIZEおよびVACUUMの操作が含まれます。「Databricks の Delta Lake とは」を参照してください。