Delta Live Tables パイプラインで更新を実行する
この記事では、Delta Live Tables パイプラインの更新の概要と、その実行方法について説明します。
パイプラインを作成して実行する準備ができたら、 更新を開始します。 パイプラインの更新では、次の処理が行われます。
正しい構成でクラスターを起動します。
定義されたすべてのテーブルとビューを検出し、無効な列名、依存関係の欠落、構文エラーなどの分析エラーをチェックします。
使用可能な最新のデータでテーブルとビューを作成または更新します。
validate update を使用すると、テーブルが作成または更新されるのを待たずに、パイプラインのソースコードに問題がないか確認できます。この機能は、パイプラインの開発またはテスト時に、テーブル名や列名の誤りなど、パイプラインのエラーをすばやく見つけて修正できるので便利です。
パイプラインを作成する方法については、「 Delta Live Tables パイプラインの構成」を参照してください。
パイプラインの更新は、Databricks ジョブやその他のツールを使用して調整できます。 「ワークフローで Delta Live Tables パイプラインを実行する」を参照してください。
パイプラインの更新を開始する
Databricks には、パイプラインの更新を開始するためのオプションがいくつかあり、次のようなものがあります。
Delta Live Tables UI には、次のオプションがあります。
パイプラインの詳細ページの ボタンをクリックします。
パイプラインの一覧から、[ アクション ] 列をクリックします 。
ノートブックで更新を開始するには、構成されたパイプラインにノートブックをアタッチし、[ 開始] をクリックします。 「ノートブックでの Delta Live Tables パイプラインの開発とデバッグ」を参照してください。
パイプラインは、API または CLI を使用してプログラムでトリガーできます。 パイプライン API を参照してください。
パイプラインは、 Delta Live Tables UI またはジョブ UI を使用してジョブとしてスケジュールできます。 「 パイプラインのスケジュール」を参照してください。
注
これらの方法のいずれかを使用して手動でトリガーされたパイプライン更新のデフォルト動作は、すべて更新することです。
Delta Live Tables がテーブルとビューを更新する方法
重要
ストリーミングテーブルまたはマテリアライズドビューを完全に更新すると、テーブルまたはビューは切り捨てられ、入力データソースの現在の状態を反映するように再計算されます。 ストリーミングテーブルの場合、チェックポイントもリセットされます。 データ保持ポリシー、手動削除、 Kafkaなどの短い保持期間のソース などにより、レコードがデータソースから削除された場合、完全更新後のテーブルまたはビューの状態は以前の状態と異なる可能性があります。 さらに、フル更新を完了するための時間とリソースは、ソース データのサイズと相関しています。
Databricks は、必要な場合にのみ完全更新を実行することを推奨し、入力データソースにテーブルまたはビューの状態を再作成するデータが含まれている場合にのみ実行することをお勧めします。 テーブルまたはビューで完全更新が実行されないようにするには、テーブル・プロパティの pipelines.reset.allowed
を false
に設定します。 Delta Live Tables テーブルのプロパティを参照してください。また、追加フローを使用して、完全な更新を必要とせずに既存のストリーミング テーブルにデータを追加することもできます。
更新されるテーブルとビュー、およびそれらのテーブルとビューの更新方法は、更新の種類によって異なります。
すべて更新: すべてのテーブルが更新され、入力データソースの現在の状態が反映されます。 ストリーミング テーブルの場合、新しい行がテーブルに追加されます。
すべて完全更新: すべてのテーブルが更新され、入力データソースの現在の状態が反映されます。 ストリーミング テーブルの場合、Delta Live Tables は各テーブルからすべてのデータをクリアしてから、ストリーミング ソースからすべてのデータを読み込もうとします。
選択の更新:
refresh selection
の動作はrefresh all
と同じですが、選択したテーブルのみを更新できます。 選択したテーブルは、入力データソースの現在の状態を反映するように更新されます。 ストリーミング テーブルの場合、新しい行がテーブルに追加されます。完全更新選択:
full refresh selection
の動作はfull refresh all
と同じですが、選択したテーブルのみの完全更新を実行できます。 選択したテーブルは、入力データソースの現在の状態を反映するように更新されます。 ストリーミングテーブルの場合、 Delta Live Tables は各テーブルからすべてのデータをクリアし、ストリーミングソースからすべてのデータをロードしようとします。
既存のマテリアライズド ビューの場合、更新はマテリアライズド ビューでの SQL REFRESH
と同じ動作になります。 新しいマテリアライズド ビューの場合、動作は SQL CREATE
操作と同じです。
選択したテーブルのパイプライン更新を開始する
必要に応じて、パイプライン内の選択したテーブルのデータのみを再処理できます。 たとえば、開発中に 1 つのテーブルのみを変更してテスト時間を短縮したい場合や、パイプラインの更新が失敗し、 失敗したテーブルのみを更新する場合などです。
注
トリガーされたパイプラインでのみ選択的更新を使用できます。
選択したテーブルのみを更新する更新を開始するには、 [パイプラインの詳細 ] ページで:
[ 更新するテーブルの選択] をクリックします。 [ 更新するテーブルの選択 ] ダイアログが表示されます。
[ 更新するテーブルを選択 ] ボタンが表示されない場合は、[ パイプラインの詳細 ] ページに最新の更新が表示され、更新が完了していることを確認します。 更新が失敗したなどの理由で、最新の更新の DAG が表示されない場合、[ 更新用のテーブルの選択 ] ボタンは表示されません。
更新するテーブルを選択するには、各テーブルをクリックします。 選択したテーブルが強調表示され、ラベルが付けられます。 更新からテーブルを削除するには、テーブルをもう一度クリックします。
[ 選択範囲の更新] をクリックします。
注
[ 選択範囲の更新] ボタンには、選択したテーブルの数が括弧内に表示されます。
選択したテーブルに既に取り込まれたデータを再処理するには、[ 選択内容を更新] ボタンの横にある をクリックし 、[ 選択内容の完全更新] をクリックします。
失敗したテーブルのパイプライン更新を開始する
パイプライン グラフ内の 1 つ以上のテーブルのエラーが原因でパイプラインの更新が失敗した場合は、失敗したテーブルとダウンストリームの依存関係のみの更新を開始できます。
注
除外されたテーブルは、失敗したテーブルに依存している場合でも更新されません。
失敗したテーブルを更新するには、「 パイプラインの詳細 」ページで、「 失敗したテーブルの更新」をクリックします。
選択した失敗したテーブルのみを更新するには:
[ 失敗したテーブルの更新 ] ボタンの横をクリックし 、[ 更新するテーブルの選択 ] をクリックします。[ 更新するテーブルの選択 ] ダイアログが表示されます。
更新するテーブルを選択するには、各テーブルをクリックします。 選択したテーブルが強調表示され、ラベルが付けられます。 更新からテーブルを削除するには、テーブルをもう一度クリックします。
[ 選択範囲の更新] をクリックします。
注
[ 選択範囲の更新] ボタンには、選択したテーブルの数が括弧内に表示されます。
選択したテーブルに既に取り込まれたデータを再処理するには、[ 選択内容を更新] ボタンの横にある をクリックし 、[ 選択内容の完全更新] をクリックします。
テーブルが更新されるのを待たずにパイプラインでエラーをチェックする
プレビュー
Delta Live Tables Validate
の更新機能は パブリック プレビュー段階です。
完全な更新を実行せずにパイプラインのソース コードが有効かどうかを確認するには、 [検証] を使用します。 Validate
更新では、パイプラインで定義されているデータセットとフローの定義が解決されますが、データセットの具体化や発行は行われません。検証中に見つかったエラー (テーブル名や列名が正しくないなど) は、UI で報告されます。
Validate
更新を実行するには、[ 開始] の横にあるパイプラインの詳細ページをクリックし 、[ 検証] をクリックします。
Validate
の更新が完了すると、イベント ログにはValidate
の更新に関連するイベントのみが表示され、DAG にメトリクスは表示されません。エラーが見つかった場合は、イベント ログに詳細が表示されます。
最新の Validate
更新の結果のみが表示されます。 Validate
更新が最後に実行された更新であった場合は、更新履歴でそれを選択して結果を確認できます。Validate
更新後に別の更新が実行されると、結果は UI で使用できなくなります。
パイプライン境界の選び方
Delta Live Tables パイプラインでは、1 つのテーブル、依存リレーションシップを持つ多数のテーブル、リレーションシップのない多数のテーブル、または依存リレーションシップを持つテーブルの複数の独立したフローに対する更新を処理できます。 このセクションには、パイプラインを分割する方法を決定するのに役立つ考慮事項が含まれています。
大規模な Delta Live Tables パイプラインには、いくつかの利点があります。 これには、次のものが含まれます。
クラスター リソースをより効率的に使用します。
ワークスペース内のパイプラインの数を減らします。
ワークフローオーケストレーションの複雑さを軽減します。
処理パイプラインの分割方法に関する一般的な推奨事項には、次のようなものがあります。
チームの境界で機能を分割します。 たとえば、データ チームはデータを変換するためのパイプラインを維持し、データアナリストは変換されたデータを分析するパイプラインを維持する場合があります。
アプリケーション固有の境界で機能を分割して、結合を減らし、共通の機能の再利用を容易にします。
開発モードと本番モード
パイプラインの実行を最適化するには、開発モードと本番モードを切り替えます。 パイプライン UI のボタンを使用して、これら 2 つのモードを切り替えます。デフォルトにより、パイプラインは開発モードで実行されます。
パイプラインを開発モードで実行すると、 Delta Live Tables システムは次の処理を行います。
クラスターを再利用して、再起動のオーバーヘッドを回避します。 デフォルトでは、開発モードが有効になっている場合、クラスターは 2 時間実行されます。 これは、Delta Live Tables パイプラインのコンピュートの構成の
pipelines.clusterShutdown.delay
設定で変更できます。パイプラインの再試行を無効にして、エラーをすぐに検出して修正できるようにします。
本番モードでは、 Delta Live Tables システムは以下を実行します。
メモリリークや古い認証情報など、特定の回復可能なエラーに対してクラスターを再起動します。
クラスターの開始の失敗など、特定のエラーが発生した場合に実行を再試行します。
注
開発モードと本番モードの切り替えは、クラスターとパイプラインの実行動作のみを制御します。 テーブルを発行するためのカタログ内のストレージの場所とターゲット スキーマは、パイプライン設定の一部として構成する必要があり、モードを切り替えても影響を受けません。
パイプラインをスケジュールする
トリガーされたパイプラインを手動で開始することも、Databricks ジョブを使用してスケジュールに従ってパイプラインを実行することもできます。 Delta Live Tables UI で直接 1 つのパイプラインタスクを使用してジョブを作成およびスケジュールするか、ジョブ UI でパイプラインタスクをマルチタスクワークフローに追加できます。ジョブの Delta Live Tables パイプライン タスクを参照してください。
Delta Live Tables UI で単一タスクのジョブとそのジョブのスケジュールを作成するには:
[ スケジュール] をクリックして>スケジュールを追加します。 パイプラインが 1 つ以上のスケジュールされたジョブに含まれている場合、[ スケジュール ] ボタンが更新され、既存のスケジュールの数が表示されます ( 例: スケジュール (5))。
[ ジョブ名 ] フィールドにジョブの名前を入力します。
[スケジュール] を [スケジュール済み] に設定します。
期間、開始時刻、およびタイム ゾーンを指定します。
パイプラインの開始、成功、または失敗に関するアラートを受信するように 1 つ以上の Eメール アドレスを構成します。
[作成]をクリックします。