Delta Live Tablesとは？

Delta Live Tablesは信頼性が高く、保守可能で、テスト可能なデータ処理パイプラインを構築するための宣言型フレームワークです。データに対して実行する変換を定義すると、Delta Live Tablesがタスクオーケストレーション、クラスター管理、監視、データ品質、エラー処理を管理します。

一連の個別のApache Sparkタスクを使用してデータパイプラインを定義する代わりに、あなたがストリーミングテーブルとマテリアライズドビューを定義することでシステムが作成し最新の状態に保ちます。Delta Live Tablesは、各処理ステップで定義したクエリーに基づいてデータがどのように変換されるかを管理します。Delta Live Tablesのエクスペクテーションを使用してデータ品質を強制することもできます。これにより、期待されるデータ品質を定義し、そのエクスペクテーションを満たさないレコードの処理方法を指定できます。

Delta Live TablesでETLパイプラインを構築し、実行する利点の詳細については、「Delta Live Tables製品ページ」をご覧ください。

Delta Live Tablesデータセットとは？

Delta Live Tablesデータセットは、ストリーミングテーブル、マテリアライズドビュー、および宣言クエリーの結果として維持されるビューです。次のテーブルは、各データセットがどのように処理されるかを示しています：

データセットのタイプ

定義されたクエリーによってレコードが処理される方法とは？

ストリーミングテーブル

各レコードは一度だけ処理されます。これは、追加専用のソースを前提としています。

マテリアライズドビュー

レコードは、現在のデータ状態の正確な結果を返すために、必要に応じて処理されます。 マテリアライズド ビューは、変換、集計、低速クエリや頻繁に使用される計算の事前計算などのデータ処理タスクに使用する必要があります。

VIEW

レコードは、ビューがクエリーされるたびに処理されます。パブリックデータセットに公開すべきではない中間変換やデータ品質チェックにはビューを使用します。

次のセクションでは、各データセットの種類について詳しく説明します。 データ処理要件を実装するためのデータセットタイプの選択の詳細については、「 ビュー、マテリアライズドビュー、ストリーミングテーブルを使用する場合」を参照してください。

ストリーミングテーブル

ストリーミングテーブルは、ストリーミングまたは増分データ処理の追加サポートを備えたDeltaテーブルです。ストリーミングテーブルを使用すると、各行を1回だけ処理して、増大するデータセットを処理できます。ほとんどのデータセットは時間の経過とともに継続的に増加するため、ストリーミングテーブルはほとんどの取り込みワークロードに適しています。ストリーミングテーブルは、データの鮮度と低遅延を必要とするパイプラインに最適です。ストリーミングテーブルは、新しいデータが到着するたびに結果を増分計算して、更新のたびにすべてのソースデータを完全に再計算する必要がなく、結果を最新の状態に保つことができるため、大規模な変換にも役立ちます。ストリーミングテーブルは、追加専用のデータソース用に設計されています。

注

デフォルトでは、ストリーミングテーブルには追加専用の データソースが必要ですが、ストリーミングソースが更新または削除を必要とする別のストリーミングテーブルである場合は、 skipChangeCommits フラグを使用してこの動作をオーバーライドできます。

マテリアライズドビュー

マテリアライズドビューは、結果が事前に計算されたビューです。マテリアライズド ビューは、それが含まれているパイプラインの更新スケジュールに従って更新されます。 マテリアライズドビューは、入力の変更を処理できるため、強力です。 パイプラインが更新されるたびに、コンプライアンス、修正、集計、または一般的な CDC によって発生した可能性のある上流データセットの変更を反映するためにクエリ結果が再計算されます。 Delta Live Tables はマテリアライズド ビューを Delta テーブルとして実装しますが、更新の効率的な適用に関連する複雑さを抽象化して、ユーザーがクエリの作成に集中できるようにします。

ビュー

Databricksのすべてのビューは、ソースデータセットからクエリーされた結果を計算します。Delta Live Tablesはビューをカタログに公開しないため、ビューは定義されたパイプライン内でのみ参照することができます。ビューは、エンドユーザーやシステムに公開されるべきでない中間クエリーとして有用です。Databricksは、データ品質制約を強制したり、複数のダウンストリームクエリーを駆動するデータセットを変換して充実させるためにビューを使用することを推奨しています。

Delta Live Tablesで最初のデータセットを宣言する

Delta Live Tables では、Python と SQL の新しい構文が導入されています。 パイプライン構文の基本については、「 Python を使用したパイプライン コードの開発 」および 「SQL を使用したパイプライン コードの開発」を参照してください。

注

Delta Live Tables はデータセット定義を更新処理から分離し、Delta Live Tables ノートブックは対話型実行を目的としていません。 「 Delta Live Tables パイプラインとは」を参照してください。

Delta Live Tablesパイプラインとは？

パイプラインは、Delta Live Tablesでデータ処理ワークフローを構成および実行するために使用されるメインユニットです。

パイプラインには、PythonまたはSQLソースファイルで宣言されたマテリアライズドビューとストリーミングテーブルが含まれています。Delta Live Tablesは、これらのテーブル間の依存関係を推測し、更新が正しい順序で行われることを保証します。Delta Live Tablesは、データセットごとに現在の状態と望ましい状態を比較し、効率的な処理方法を使用してデータセットの作成または更新を進めます。

Delta Live Tablesパイプラインの設定は、次の2つの大きなカテゴリに分類されます。

  1. Delta Live Tables 構文を使用してデータセットを宣言するノートブックまたはファイルのコレクション ( ソース コードと呼ばれます) を定義する構成。

  2. パイプライン インフラストラクチャ、依存関係の管理、更新の処理方法、ワークスペースでのテーブルの保存方法を制御する構成。

ほとんどの構成はオプションですが、特に運用パイプラインを構成する場合は、注意が必要です。これらには以下が含まれます：

  • パイプラインの外部でデータを利用できるようにするには、Hive metastoreに公開するターゲットスキーマ、またはUnity Catalogに公開するターゲットカタログとターゲットスキーマを宣言する必要があります。

  • データアクセス許可は、実行に使用されるクラスターを通じて構成されます。データソースとターゲットとなるストレージの場所（指定されている場合）に対して適切なアクセス許可がクラスターに構成されていることを確認してください。

PythonとSQLを使用してパイプラインのソースコードを記述する詳細については、Delta Live Tables SQL言語リファレンスとDelta Live Tables Python言語リファレンスを参照してください。

パイプラインの設定と構成の詳細については、「 Delta Live Tables パイプラインの構成」を参照してください。

最初のパイプラインをデプロイして更新をトリガーする

Delta Live Tablesでデータを処理する前に、パイプラインを構成する必要があります。パイプラインを構成したら、更新をトリガーして、パイプライン内の各データセットの結果を計算できます。Delta Live Tables パイプラインを使い始めるには、「チュートリアル：初めてのDelta Live Tablesパイプラインを実行する」を参照してください。

パイプライン更新とは？

パイプラインはインフラストラクチャをデプロイし、更新の開始時にデータの状態を再計算します。更新プログラムは、次の処理を行います：

  • 正しい構成でクラスターを開始します。

  • 定義されているすべてのテーブルとビューを検出し、無効な列名、欠落している依存関係、構文エラーなどの分析エラーがないかチェックします。

  • 使用可能な最新のデータでテーブルとビューを作成または更新します。

パイプラインは、ユースケースのコストとレイテンシの要件に応じて、継続的に実行することも、スケジュールに従って実行することもできます。「Delta Live Tablesパイプラインで更新を実行する」を参照してください。

Delta Live Tablesによるデータの取り込み

Delta Live Tablesは、Databricksで利用可能な全てのデータソースをサポートしています。

Databricksでは、ほとんどの取り込みユースケースでストリーミングテーブルを使用することをお勧めします。クラウドオブジェクトストレージに到着するファイルの場合、DatabricksはAuto Loaderを推奨します。Delta Live Tablesを使用して、ほとんどのメッセージバスからデータを直接取り込むことができます。

クラウド ストレージへのアクセスの構成の詳細については、「 クラウド ストレージの構成」を参照してください。

Auto Loaderでサポートされていない形式については、PythonまたはSQLを使用して、Apache Sparkでサポートされている形式をクエリーできます。「Delta Live Tablesを使用したデータのロード」を参照してください。

データ品質の監視と実施

エクスペクテーションを使って、データセットの内容に関するデータ品質管理を指定することができます。従来のデータベースにおけるCHECK制約が、制約に不合格となったレコードの追加を阻止するのとは異なり、エクスペクテーションはデータ品質要件に不合格となったデータを処理する際の柔軟性を提供します。この柔軟性により、乱雑であることが予想されるデータや、厳格な品質要件を満たさなければならないデータを処理し、保存することができます。Delta Live Tablesでデータ品質を管理するを参照してください。

Delta Live Tablesによるテーブルの作成および管理方法

Databricksは、Delta Live Tablesで作成されたテーブルを自動的に管理し、テーブルの現在の状態を正しく計算するために必要な更新の処理方法を決定し、多数のメンテナンスおよび最適化タスクを実行します。

ほとんどの操作では、ターゲットテーブルに対するすべての更新、挿入、および削除を Delta Live Tables 処理できるようにする必要があります。 詳細と制限事項については、「 手動による削除または更新を保持する」を参照してください。

Delta Live Tablesによって実行されるメンテナンスタスク

Delta Live Tables は、テーブルが更新されてから 24 時間以内にメンテナンスタスクを実行します。 メンテナンスにより、古いバージョンのテーブルを削除することで、クエリーのパフォーマンスを向上させ、コストを削減できます。 デフォルトでは、システムは完全な OPTIMIZE 操作を実行してから VACUUM を実行します。 テーブルの OPTIMIZE を無効にするには、テーブルの テーブル プロパティ で pipelines.autoOptimize.managed = false を設定します。メンテナンス タスクは、メンテナンス タスクがスケジュールされる前の 24 時間以内にパイプラインの更新が実行された場合にのみ実行されます。

制限事項

次の制限が適用されます：

  • Delta Live Tablesによって作成および更新されるテーブルはすべてDeltaテーブルである。

  • Delta Lake タイムトラベルクエリはストリーミングテーブルでのみサポートされ、マテリアライズドビュー ではサポートされていません 。 「Delta Lake テーブル履歴の操作」を参照してください。

  • Delta Live Tablesテーブルは1回だけ定義できます。つまり、すべてのDelta Live Tablesパイプラインで1つのオペレーションのターゲットにのみ設定できる。

  • ID カラムは、 APPLY CHANGES INTO のターゲットであり、マテリアライズドビューの更新中に再計算される可能性のあるテーブルではサポートされません。 このため、Databricks では、Delta Live Tables の ID 列をストリーミング テーブルでのみ使用することをお勧めします。 「Delta Lake での ID 列の使用」を参照してください。

  • Databricksワークスペースは、パイプラインの同時更新が100件に制限されている。

Unity Catalog で Delta Live Tables を使用する場合に固有の要件と制限事項の一覧については、「Delta Live Tables パイプラインで Unity Catalog を使用する」を参照してください

追加のリソース