Delta Live Tables パイプラインで更新を実行する

この記事では、パイプラインの更新について説明し、更新をトリガーする方法について詳しく説明します。

パイプライン更新とは？

パイプラインを作成して実行する準備ができたら、 更新を開始します。 パイプラインの更新では、次の処理が行われます。

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

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

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

validate update を使用すると、テーブルが作成または更新されるのを待たずに、パイプラインのソースコードに問題がないか確認できます。この機能は、パイプラインの開発またはテスト時に、テーブル名や列名の誤りなど、パイプラインのエラーをすばやく見つけて修正できるので便利です。

パイプラインの更新はどのようにトリガーされますか?

次のいずれかのオプションを使用して、パイプラインの更新を開始します。

更新トリガー

詳細

手動

パイプラインの更新は、パイプライン UI、パイプライン リスト、またはパイプラインにアタッチされたノートブックから手動でトリガーできます。 「パイプライン更新を手動でトリガーする」および「ノートブックでDelta Live Tablesパイプラインを開発およびデバッグする」を参照してください。

スケジュール

パイプラインの更新は、ジョブを使用してスケジュールできます。 ジョブの Delta Live Tables パイプライン タスクを参照してください。

プログラム

サードパーティのツール、 APIs、および CLI を使用して、プログラムで更新をトリガーできます。 「Delta Live Tables パイプラインの実行」および「パイプライン パイプライン API」を参照してください。

パイプラインの更新を手動でトリガーする

次のいずれかのオプションを使用して、パイプラインの更新を手動でトリガーします。

  • パイプラインの詳細ページのDelta Live Tables スタートアイコン ボタンをクリックします。

  • パイプラインの一覧から、[右矢印アイコン アクション ] 列をクリックします 。

注

手動でトリガーされたパイプライン更新のデフォルトの動作は、パイプラインで定義されているすべてのデータセットを更新することです。

パイプライン更新セマンティクス

次の表では、デフォルトの更新と完全更新のマテリアライズドビューとストリーミングテーブルの動作について説明します。

アップデートのタイプ

具体化されたビューのセマンティクス

ストリーミング テーブルのセマンティクス

更新 (デフォルト)

結果を更新して、定義クエリの現在の結果を反映します。

ストリーミング テーブルとフローで定義されたロジックを通じて新しいレコードを処理します。

フルリフレッシュ

結果を更新して、定義クエリの現在の結果を反映します。

ストリーミングテーブルからデータをクリアし、フローから状態情報 (チェックポイント) をクリアし、データソースからすべてのレコードを再処理します。

デフォルトでは、パイプライン内のすべての具体化されたビューとストリーミングテーブルは、更新のたびに更新されます。 オプションで、次の機能を使用して更新からテーブルを省略できます。

これらの機能はどちらも、デフォルトの更新セマンティクスまたは完全更新をサポートしています。 オプションで、[ Select tables for update ] ダイアログを使用して、失敗したテーブルの更新を実行するときに追加のテーブルを除外できます。

フルアップデートを使うべきですか?

Databricks では、必要な場合にのみフル更新を実行することをお勧めします。 完全更新では、データセットを定義するロジックを通じて、指定されたデータソースのすべてのレコードが常に再処理されます。 完全更新を完了するための時間とリソースは、ソース データのサイズと相関しています。

マテリアライズドビューは、デフォルト更新と完全更新のどちらが使用されていても同じ結果を返します。 ストリーミングテーブルで完全更新を使用すると、すべての状態処理とチェックポイント情報がリセットされ、入力データが使用できなくなった場合にレコードがドロップされる可能性があります。

Databricks は、入力データソースにテーブルまたはビューの目的の状態を再作成するために必要なデータが含まれている場合にのみ、完全な更新を推奨します。 入力ソース データが使用できなくなった次のシナリオと、完全更新を実行した結果について考えてみます。

データソース

入力データが存在しない理由

全更新の結果

Kafka

短い保持しきい値

Kafka ソースに存在しなくなったレコードは、ターゲットテーブルから削除されます。

オブジェクトストレージ内のファイル

ライフサイクルポリシー

ソース・ディレクトリーに存在しなくなったデータ・ファイルは、ターゲット・テーブルからドロップされます。

テーブル内のレコード

コンプライアンスのために削除されました

ソース テーブルに存在するレコードのみが処理されます。

テーブルまたはビューで完全更新が実行されないようにするには、テーブル・プロパティの pipelines.reset.allowed を falseに設定します。 Delta Live Tables テーブルのプロパティを参照してください。また、追加フローを使用して、完全な更新を必要とせずに既存のストリーミング テーブルにデータを追加することもできます。

選択したテーブルのパイプライン更新を開始する

必要に応じて、パイプライン内の選択したテーブルのデータのみを再処理できます。 たとえば、開発中に 1 つのテーブルのみを変更してテスト時間を短縮したい場合や、パイプラインの更新が失敗し、 失敗したテーブルのみを更新する場合などです。

注

トリガーされたパイプラインでのみ選択的更新を使用できます。

選択したテーブルのみを更新する更新を開始するには、 [パイプラインの詳細 ] ページで:

  1. [ 更新するテーブルの選択] をクリックします。 [ 更新するテーブルの選択 ] ダイアログが表示されます。

    [ 更新するテーブルを選択 ] ボタンが表示されない場合は、[ パイプラインの詳細 ] ページに最新の更新が表示され、更新が完了していることを確認します。 更新が失敗したなどの理由で、最新の更新の DAG が表示されない場合、[ 更新用のテーブルの選択 ] ボタンは表示されません。

  2. 更新するテーブルを選択するには、各テーブルをクリックします。 選択したテーブルが強調表示され、ラベルが付けられます。 更新からテーブルを削除するには、テーブルをもう一度クリックします。

  3. [ 選択範囲の更新] をクリックします。

    注

    [ 選択範囲の更新] ボタンには、選択したテーブルの数が括弧内に表示されます。

選択したテーブルに既に取り込まれたデータを再処理するには、[ブルーダウンキャレット 選択内容を更新] ボタンの横にある をクリックし 、[ 選択内容の完全更新] をクリックします。

失敗したテーブルのパイプライン更新を開始する

パイプライン グラフ内の 1 つ以上のテーブルのエラーが原因でパイプラインの更新が失敗した場合は、失敗したテーブルとダウンストリームの依存関係のみの更新を開始できます。

注

除外されたテーブルは、失敗したテーブルに依存している場合でも更新されません。

失敗したテーブルを更新するには、「 パイプラインの詳細 」ページで、「 失敗したテーブルの更新」をクリックします。

選択した失敗したテーブルのみを更新するには:

  1. ボタンダウン [ 失敗したテーブルの更新 ] ボタンの横をクリックし 、[ 更新するテーブルの選択 ] をクリックします。[ 更新するテーブルの選択 ] ダイアログが表示されます。

  2. 更新するテーブルを選択するには、各テーブルをクリックします。 選択したテーブルが強調表示され、ラベルが付けられます。 更新からテーブルを削除するには、テーブルをもう一度クリックします。

  3. [ 選択範囲の更新] をクリックします。

    注

    [ 選択範囲の更新] ボタンには、選択したテーブルの数が括弧内に表示されます。

選択したテーブルに既に取り込まれたデータを再処理するには、[ブルーダウンキャレット 選択内容を更新] ボタンの横にある をクリックし 、[ 選択内容の完全更新] をクリックします。

テーブルが更新されるのを待たずにパイプラインでエラーをチェックする

プレビュー

Delta Live Tables Validate の更新機能は パブリック プレビュー段階です。

完全な更新を実行せずにパイプラインのソース コードが有効かどうかを確認するには、 [検証] を使用します。 Validate更新では、パイプラインで定義されているデータセットとフローの定義が解決されますが、データセットの具体化や発行は行われません。検証中に見つかったエラー (テーブル名や列名が正しくないなど) は、UI で報告されます。

Validate更新を実行するには、[ブルーダウンキャレット 開始] の横にあるパイプラインの詳細ページをクリックし 、[ 検証] をクリックします。

Validateの更新が完了すると、イベント ログにはValidateの更新に関連するイベントのみが表示され、DAG にメトリクスは表示されません。エラーが見つかった場合は、イベント ログに詳細が表示されます。

最新の Validate 更新の結果のみが表示されます。 Validate更新が最後に実行された更新であった場合は、更新履歴でそれを選択して結果を確認できます。Validate更新後に別の更新が実行されると、結果は UI で使用できなくなります。

開発モードと本番モード

パイプラインの実行を最適化するには、開発モードと本番モードを切り替えます。 Delta Live Tables 環境切り替えアイコン パイプライン UI のボタンを使用して、これら 2 つのモードを切り替えます。デフォルトにより、パイプラインは開発モードで実行されます。

パイプラインを開発モードで実行すると、 Delta Live Tables システムは次の処理を行います。

  • クラスターを再利用して、再起動のオーバーヘッドを回避します。 デフォルトでは、開発モードが有効になっている場合、クラスターは 2 時間実行されます。 これは、Delta Live Tables パイプラインのコンピュートの構成の pipelines.clusterShutdown.delay 設定で変更できます。

  • パイプラインの再試行を無効にして、エラーをすぐに検出して修正できるようにします。

本番モードでは、 Delta Live Tables システムは以下を実行します。

  • メモリリークや古い認証情報など、特定の回復可能なエラーに対してクラスターを再起動します。

  • クラスターの開始の失敗など、特定のエラーが発生した場合に実行を再試行します。

注

開発モードと本番モードの切り替えは、クラスターとパイプラインの実行動作のみを制御します。 テーブルを発行するためのカタログ内のストレージの場所とターゲット スキーマは、パイプライン設定の一部として構成する必要があり、モードを切り替えても影響を受けません。