Delta Live Tablesのコンセプト


Delta Live Tables concepts | Databricks on AWS [2022/3/2時点]の翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

プレビュー
この機能はパブリックプレビューです。アクセスする際にはDatabricks担当者にお問い合わせください。

本書では、Delta Live Tablesを効果的に使用するために理解すべき基本的なコンセプトを紹介します。

パイプライン

Delta Live Tablesにおける処理実行のメインユニットはパイプラインとなります。パイプラインは、データソースとターゲットデータセットを接続する有向非循回グラフ(DAG)です。SQLクエリーあるいはSpark SQLあるいはKoalasデータフレームを返却するPython関数を用いて、Delta Live Tablesのデータセットのコンテンツを定義することができます。パイプラインを実行するのに必要な設定をパイプラインに定義することができます。オプションとして、データセットを定義する際にデータ品質の制約を指定することができます。

DatabricksノートブックでDelta Live Tablesのパイプラインを実装します。1つのノートブックあるいは複数のノートブックでパイプラインを実装することができます。1つのノートブックでは、全てのクエリーはPythonあるいはSQLで実装される必要がありますが、Pythonのノートブック、SQLのノートブックを組み合わせた複数のノートブックでパイプラインを設定することが可能です。それぞれのノートブックは出力データの格納場所を共有し、パイプラインの他のノートブックからデータセットを参照することができます。

Delta Live Tablesのノートブックを格納、管理するためにDatabricks Reposを使用することができます。パイプラインを作成する際にDatabricks Reposで管理できるようにするには、以下の設定を行います。

  • SQLノートブックの先頭にコメント-- Databricks notebook sourceを追加します。
  • Pythonノートブックの先頭にコメント# Databricks notebook sourceを追加します。

パイプラインの作成、実行についてはCreate, run, and manage Delta Live Tables pipelinesをご覧ください。複数ノートブックによるパイプラインの設定例については、パイプラインの複数のノートブックの設定をご覧ください。

クエリー

クエリーでは、データソースとターゲットデータセットを定義することでデータ変換を定義します。Delta Live TablesのクエリーはPythonあるいはSQLで実装できます。

エクスペクテーション

データセットのコンテンツに対するデータ品質のコントロールを指定するためにエクスペクテーションを使用します。制約に違反するレコードの追加を防ぐ従来型のデータベースのCHECK制約とは異なり、エクスペクテーションはデータ品質要件に違反するデータの処理に対する柔軟性を提供します。この柔軟性によって、綺麗でないと予測されるデータ、厳密な品質要件に合致すべきデータを処理、格納することが可能となります。

検証に失敗したレコードを保持するか、レコードを削除するか、パイプラインを停止するようにエクスペクテーションを定義することができます。

パイプライン設定

パイプライン設定はJSONで定義され、以下のようにパイプラインの実行に必要なパラメーターを含めることができます。

  • Delta Lakeでターゲットデータセットを作成するためのテーブルとビューを定義するクエリーを含む(ノートブック形式の)ライブラリ
  • 処理に必要となるテーブルとビューが格納されるクラウドストレージ上の格納場所。この格納場所には、DBFSあるいは指定する場所を設定できます。
  • データの処理を行うSparkクラスターの追加設定

詳細はDelta Live Tablesの設定をご覧ください。

パイプラインのアップデート

パイプラインを作成したら実行することができます。アップデートを起動します。アップデートは以下の処理を実行します。

  • 適切な設定でクラスターを起動します。
  • 定義されたすべてのテーブルとビューを特定し、不正なカラム名、依存関係の欠如、構文エラーなどの解析エラーをチェックします。
  • 最新のデータを用いてすべてのテーブルとビューを作成、更新します。

パイプラインがトリガーモードの場合、パイプラインのすべてのテーブルの更新後にシステムは処理を停止します。

トリガーモードのアップデートが成功すると、それぞれのテーブルはアップデートがスタートした際のデータに基づいて更新されたことが保証されます。

低レーテンシーの要件があるユースケースでは、連続モードでパイプラインをアップデートするように設定できます。

お使いのパイプラインの実行モードの詳細については連続、トリガーパイプラインをご覧ください。

データセット

Delta Live Tablesでは、ビューテーブルという二つのタイプのデータセットが存在します。

  • ビューはSQLにおける一時ビューと類似のものであり、何かしらの計算処理のエイリアスとなります。ビューを用いることで、複雑なクエリーをより小さく理解しやすいクエリーに分割することができます。また、1つ以上のテーブルに対するソースとして特定の変換処理を再利用することができます。パイプライン内でのみビューを利用することができ、インタラクティブにクエリーを実行することはできません。
  • テーブルは従来のマテリアライズドビューと似たようなものです。Delta Live Tablesランタイムは自動でテーブルをDelta形式で作成し、テーブルを作成するクエリーの最新の結果でこれらのテーブルが更新されることを保証します。

テーブルはインクリメンタルあるいはコンプリートテーブルとなります。インクリメンタルテーブルでは、テーブル全体を再計算することなしに、継続的に到着するデータに基づいたアップデートをサポートしています。コンプリートテーブルではアップデートごとにすべてが再計算されます。

後段のコンシューマーで検索、クエリーできるようにテーブルを公開することができます。

連続、トリガーパイプライン

Delta Live Tablesでは、2つの実行モードをサポートしています。

  • トリガー(triggered)パイプラインは、現時点で利用可能なデータを用いてそれぞれのテーブルをアップデートし、パイプラインを実行しているクラスターを停止します。Delta Live Tablesは自動でテーブル間の依存関係を解析し、外部ソースからの読み込みを行う計算処理を起動します。パイプライン内のテーブルは、依存しているデータソースが更新された後に更新されます。
  • 連続(continuous)パイプラインは入力データの変更に合わせて継続的にテーブルをアップデートします。アップデートが起動すると、手動で停止されるまで処理を継続します。連続パイプラインには常時稼働のクラスターが必要となりますが、後段のコンシューマーが最新のデータを利用できることを保証します。

トリガーパイプラインでは、クラスターはパイプラインを実行するのに必要な期間のみ稼働するのでリソース消費とコストを削減できます。しかし、パイプラインがトリガーされるまでは、新規データは処理されません。連続パイプラインでは常時稼働のクラスターが必要となり、追加のコストが発生しますが処理のレーテンシーを削減することができます。

パイプライン設定continuousフラグで実行モードを制御します。デフォルトではトリガー実行モードでパイプラインは実行されます。パイプラインのテーブルに対して低レーテンシーのアップデートが必要な場合には、continuoustrueに設定します。

{
  ...
  "continuous": true,
  ...
}

実行モードと計算するテーブルのタイプは独立しています。どちらの実行モードでもコンプリートテーブル、インクリメンタルテーブルの両方をアップデートすることができます。

お使いのパイプラインのいくつかのテーブルでレーテンシーの要件が強くない場合には、設定pipelines.trigger.intervalで更新頻度を独立に設定することができます。

Python
spark_conf={"pipelines.trigger.interval", "1 hour"}

このオプションはパイプラインのアップデートの合間にクラスターを停止させませんが、お使いのパイプラインの他のテーブルをアップデートに使用するリソースを解放することができます。

連続パイプラインにおけるコンプリートテーブル

連続的に実行されるパイプラインにコンプリートテーブルを含めることができます。不要な処理を避けるために、パイプラインは依存するDeltaテーブルを自動でモニタリングし、依存するテーブルのコンテンツが変化した時のみアップデートを実行します。

Delta Live Tablesランタイムは非Deltaのデータソースの変更を検知することはできません。テーブルは定期的に更新されますが、デフォルトトリガー周期に大きな値を設定することで、クラスターで生じるインクリメンタルな処理をスローダウンさせるような過度な再計算を回避することができます。

開発、プロダクションモード

開発(development)モードとプロダクション(production)モードを切り替えることで、パイプライン実行を最適化することができます。パイプラインを開発モードで実行すると、Delta Live Tablesシステムは以下の処理を行います。

  • 再起動のオーバーヘッドを回避するためにクラスターを再利用します。
  • エラーを即座に検知し修正できるように、パイプラインのリトライを無効化します。

プロダクションモードでは、Delta Live Tablesシステムは以下の処理を行います。

  • メモリーリークや古い認証情報のような回復可能な特定のエラーに対してクラスターを再起動します。
  • クラスターの起動失敗など特定のエラーイベントに対しては、処理の実行をリトライします。

開発モード、プロダクションモードを切り替えるにはパイプラインUIのボタンを使用します。デフォルトでは開発モードとなっています。

開発モード、プロダクションモードの切り替えは、クラスターとパイプライン実行の挙動のみを制御します。ストレージの場所はパイプライン設定の一部として設定されるものであり、このモードを切り替えても影響は受けません。

Databricks 無料トライアル

Databricks 無料トライアル