メインコンテンツまでスキップ
に最終更新

Lakeflow Spark宣言型パイプラインとは

Lakeflow Spark宣言型パイプライン (SDP) とは何か、それを定義する中心的な概念 (パイプライン、ストリーミング テーブル、マテリアライズドビューなど)、それらの概念間の関係、データ処理ワークフローで SDP を使用する利点について学びます。

SDP とは何ですか？​

Lakeflow Spark宣言型パイプラインは、 SQLおよびPythonでバッチおよびストリーミング データ パイプラインを開発および実行するための宣言型フレームワークです。 Lakeflow SDP は、パフォーマンスが最適化されたDatabricks Runtime上で実行されながら、 Apache Spark 宣言型パイプラインを拡張し、相互運用可能です。また、 Lakeflow Spark 宣言型パイプラインflows API 、 Apache Sparkおよび構造化ストリーミングと同じDataFrame API使用します。

SDPの一般的なユースケースには次のようなものがあります。

宣言的なデータ処理の詳細については、「Databricksにおける手続き型と宣言型のデータ処理」を参照してください。

SDPのメリットは何ですか？​

SDP の宣言的な性質によりApache SparkおよびSpark構造化ストリーミングAPIs使用してデータ プロセスを開発し、 Lakeflowジョブを介した手動オーケストレーションを使用してDatabricks Runtimeでそれらを実行するのと比較して、次の利点が得られます。

  • 自動オーケストレーション ：SDP は、処理ステップ (「フロー」と呼ばれます) を自動的に調整し、正しい実行順序と並列処理の最大レベルを確保して最適なパフォーマンスを実現します。さらに、パイプラインは一時的なエラーを自動的かつ効率的に再試行します。再試行プロセスは、最も詳細でコスト効率の高い単位である Spark タスクから始まります。タスク レベルの再試行が失敗した場合、SDPはフローの再試行を続行し、必要に応じてパイプライン全体を再試行します。
  • 宣言型処理 ：SDPは宣言型関数を提供し、数百行、あるいは数千行にも及ぶ手動のSparkおよびStructured Streamingコードをわずか数行にまで削減できます。SDP AUTO CDC APIは、 SCDタイプ1とSCDタイプ2の両方をサポートすることで、変更データキャプチャ（CDC）イベントの処理を簡素化します。これにより、順不同イベントを処理するための手動コードが不要になり、ストリーミングセマンティクスやウォーターマークなどの概念を理解する必要もありません。
  • インクリメンタル処理: SDP は、マテリアライズドビューの インクリメンタル処理 エンジンを提供します。これを使用するには、バッチセマンティクスを使用して変換ロジックを記述し、エンジンは可能な限り新しいデータとデータソースの変更のみを処理します。インクリメンタル処理により、ソースで新しいデータや変更が発生した場合の非効率的な再処理が削減され、インクリメンタル処理を処理するための手動コードが不要になります。

主要な概念​

以下の図は、 Lakeflow Spark宣言型パイプラインの最も重要な概念を示しています。

SDPの主要な概念がどのように連携するかを示す概略図

データセット​

パイプラインは、それぞれ異なる処理セマンティクスを持つ3種類のデータセットを生成します：

データセットのタイプ

レコードの処理方法

ストリーミングテーブル

各レコードは一度だけ処理されます。これは、追加専用のソースを前提としています。ストリーミングテーブルは、継続的に増加するデータの取り込みと増分処理に適しています。

マテリアライズドビュー

必要に応じて結果が再計算され、データの現在の状態が反映されます。マテリアライズドビューは、複数のダウンストリームデータセットで利用される結果の変換、集計、または事前計算に適しています。

ビュー

オンデマンドで評価され、永続化されません。カタログに公開する必要がない中間変換とチェックには、ビューを使用します。

ストリーミングテーブル は、ストリーミングターゲットでもある Unity Catalog マネージドテーブルの形式です。ストリーミングテーブルには、1 つ以上のストリーミングフロー（ Append 、 AUTO CDC ）を書き込むことができます。ストリーミングフローを、ターゲットストリーミングテーブルとは別に明示的に定義することも、ストリーミングテーブル定義の一部として暗黙的に定義することもできます。

マテリアライズドビュー は、Unity Catalog マネージドテーブルの形式であり、バッチ ターゲットでもあります。マテリアライズドビューには、1 つ以上のマテリアライズドビューフローを書き込むことができます。マテリアライズドビューがストリーミングテーブルと異なるのは、常にマテリアライズドビューの定義の一部としてフローを暗黙的に定義する点です。

詳細については、ストリーミングテーブルおよびマテリアライズドビューを参照してください。

ビュー、マテリアライズドビュー、ストリーミングテーブルをどのような場合に使用するのか​

パイプライン クエリを実装する際は、ユースケースに最適なデータセットの種類を選択してください。

ビューの使用を検討してください：

  • 大規模または複雑なクエリを、より管理しやすいクエリに分割してください。
  • エクスペクテーションを使用して中間結果を検証します。
  • 永続化が不要な結果のストレージとコンピュート・コストを削減します。テーブルが具体化されるため、追加のコンピューティングおよびストレージリソースが必要となります。

マテリアライズドビューは、次の場合に使用を検討してください。

  • 複数の下流クエリがテーブルを利用しています。ビューはオンデマンドでコンピュートされるため、クエリが実行されるたびに、ビューは再コンピュートされます。
  • 他のパイプライン、ジョブ、またはクエリがテーブルを利用します。ビューはマテリアライズされていないため、同じパイプライン内でのみ使用できます。
  • 開発中にクエリ結果を検査したい場合。テーブルはマテリアライズされ、パイプラインの外部からクエリできるため、開発中にテーブルを使用することで、計算の正確性を検証するのに役立ちます。検証後、マテリアライゼーションが不要なクエリをビューに変換します。

次のような場合は、ストリーミングテーブルの使用を検討してください。

  • クエリーは、継続的または段階的に増加するデータソースに対して定義されます。
  • クエリー結果は増分的にコンピュートされるべきです。
  • パイプラインは高スループットと低レイテンシを必要とします。
注記

ストリーミングテーブルは、常にストリーミング ソースに対して定義されます。 また、 AUTO CDC ... INTO でストリーミング ソースを使用して、CDC フィードからの更新を適用することもできます。「AUTO CDC APIs : パイプラインによる変更データ キャプチャの簡素化」を参照してください。

フロー​

フローは、SDP における基本的なデータ処理の概念であり、ストリーミングとバッチの両方のセマンティクスをサポートします。フローは、ソースからデータを読み取り、ユーザー定義の処理ロジックを適用して、結果をターゲットに書き込みます。SDP は Spark 構造化ストリーミングと同じストリーミング フローの種類 ( 追加 、 更新 、 完了 ) を共有します。（現在、 Append と Update フローのみが公開されています。）詳細については、 構造化ストリーミングの出力モードを参照してください。

Lakeflow Spark宣言型パイプラインは、追加のフロー タイプも提供します。

  • AUTO CDC 、順序外れのCDCイベントを処理し、 SCD Type 1 とSCD Type 2 の両方をサポートするLakeflow SDP の独自のストリーミング フローです。Auto CDC 、 Apache Spark 宣言型パイプラインでは使用できません。
  • マテリアライズドビュー は、可能な限り新しいデータとソース テーブルの変更のみを処理する SDP のバッチ フローです。

詳細については、「 Lakeflow Spark宣言型パイプライン フローを使用してデータを段階的にロードして処理する」を参照してください。

シンク​

シンク はパイプラインのストリーミング ターゲットであり、Delta テーブル、Apache Kafka トピック、Azure EventHubs トピック、およびカスタム Python データソースをサポートしています。シンクには、1つ以上のストリーミングフロー ( Append , Update ) を書き込むことができます。

詳細については、Lakeflow Spark宣言型パイプラインのシンクを参照してください。

パイプライン​

パイプライン は、Lakeflow Spark宣言型パイプラインにおける開発および実行の単位であり、定義するフロー、ストリーミングテーブル、マテリアライズドビュー、シンクを格納するコンテナです。SDP を使用するには、これらのオブジェクトをパイプライン ソース コードで定義し、パイプラインを実行します。パイプラインの実行中に、定義されたオブジェクトの依存関係が分析され、それらの実行順序と並列化が自動的に調整されます。

詳細については、「パイプラインとは？」を参照してください。

データ取り込み​

パイプラインは、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 とは」を参照してください。

その他のリソース​

このページの見出し