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

ストリーミングテーブルの完全更新

ストリーミングテーブルの完全更新を行うと、既存のデータとメタデータがすべて破棄され、ストリームが最初から再開されます。具体的には、ストリーミングテーブルを切り捨て、すべてのチェックポイントデータを削除し、テーブルに書き込むすべてのフローに対して新しいチェックポイントを使用してストリーミングプロセスを再開します。このページでは、完全アップデートを実行する必要が生じる場合と、完全アップデートを実行した場合の影響について説明します。 また、完全なアップデートに関するベストプラクティスも含まれています。

完全な更新をトリガーする方法については、 「パイプラインの更新を実行する」を参照してください。

データソースへの影響​

完全更新を実行すると、ストリーミングテーブルから既存のデータがすべて削除されます。データ ソースに保持期間の制限がある場合 (保持期間が短いKafkaトピックなど)、一部の履歴データは完全に更新した後に回復できなくなる可能性があります。

たとえば、ソースが 24 時間の保存期間を持つKafkaであり、その期間後に完全な更新を実行した場合、古いメッセージは利用できなくなり、再処理できなくなります。

注記

完全更新は、大容量のストリーミング ワークロードの場合、またはアップストリームの保持により履歴データの再生が妨げられる場合には推奨されません。

ストリーミングテーブルに依存する下流テーブルがある場合、ストリーミングテーブルでskipChangeCommits が有効になっていない限り、それらのテーブルも完全に更新されるまでパイプラインは失敗します。下流のマテリアライズドビューも完全に更新する必要があります。

完全な更新をいつ実行するか​

LakeFlow Spark宣言型パイプラインの完全な更新は、明示的にトリガーする必要があります。 完全更新を実行するには、パイプライン UI で [完全更新] をクリックするか、 LakeFlow Connectで自動完全更新を有効にします。

変更によってストリーミングクエリが既存のチェックポイントから安全に再開できない場合、または以前に処理されたデータが更新されたロジック、スキーマ、またはソース構成と矛盾する場合は、完全な更新が推奨されます。以下のセクションでは、よくあるシナリオについて説明します。

スキーマの変更​

対象テーブルにおける以下のスキーマ変更は下位互換性がなく、完全な更新が必要です。

  • 列マッピングモードが有効になっていない状態で列名を変更する。

  • 重複排除列を変更します。

  • 列のデータ型を変更する（以下を含む）：

    • 型の絞り込み（例： BIGINT → INTまたはDOUBLE → FLOAT ）。
    • 互換性のない型変更（例： STRING → INT ）。

  • テーブルスキーマから列を完全に削除する。

このようなスキーマ変更の場合、Databricksは、目的のスキーマまたは名前で新しい列を作成し、ストリーミングテーブルの上にビューを作成して、古い値と新しい値を結合することを推奨しています。

物理データレイアウトの変更​

以下の物理データレイアウトの変更には、完全な更新が必要です。

  • 従来のパーティショニング方式から新しいクラスタリング方式への移行。

上流ソースの変更​

以下のアップストリームソースの変更には、完全な更新が必要です。

  • ストリーミングクエリによって読み取られるソーステーブルを変更します。
  • ソースタイプの切り替え（例えば、KafkaからDelta、またはAuto LoaderからKafkaへの切り替え）。
  • テーブルパスやKafkaトピックの購読など、ソースの場所を変更する。
  • スキーマが変更されていない場合でも、 Deltaテーブルを削除して再作成します。

ステートフル処理の変更​

以下のステートフル処理の変更には、完全な更新が必要です。

  • 集計グループ化キーまたは集計関数の変更。
  • 集計の追加または削除。
  • 結合キーまたは結合タイプを変更します。
  • 結合の追加または削除。
  • 重複排除列または重複排除ロジックの変更。

データ継続性の問題​

データの一貫性が損なわれた場合は、完全な更新が必要になる場合があります。

  • CDCのログは、保存期間の満了により利用できなくなりました。
  • ストリーミングチェックポイントディレクトリの破損または削除。
  • スキーマ追跡ファイルまたはスキーマロケーションファイルの破損または消失。

チェックポイント障害からのパイプラインの回復の詳細については、 「ストリーミング チェックポイント障害からのパイプラインの回復」を参照してください。

制限事項​

完全更新には以下の制限事項が適用されます。これらの制約内で作業を進めるための情報については、 「ベストプラクティス」を参照してください。

  • 完全な更新では、ソースが完全な履歴データセットを保持していない限り、データは再処理されません。
  • 大規模なデータセットでは、完全な更新にコストと時間がかかる場合があります。
  • テーブルに依存する下流のコンシューマーは、更新が完了するまで、処理に失敗したり、不完全な結果を返したりする可能性があります。

ベストプラクティス​

状況

ベストプラクティス

安定性を考慮した設計

スキーマを計画する際には、全面的な更新が必要となるような変更を避けるようにしてください。列を追加することは一般的に安全ですが、既存の列やパーティショニング方式を変更する場合は、通常、テーブルの再計算が必要になります。

保存期間が短いソースからのストリーム

Kafkaトピックなどの保持期間が長くないソースからのストリーミングは、完全に更新すると、ソースに残っていないデータが失われることを意味します。

ヒストリカルデータの損失を避けるために、生データをストリーミング テーブル (メダリオン アーキテクチャ内のブロンズ テーブル) にストリームします。 上流データが変更された場合でもこのテーブル全体を更新する必要がないように、柔軟な列型（例えば、バリアント型や文字列型）を使用してください。このテーブルには履歴データを保存でき、ダウンストリーム ストリーミング テーブル (より厳密なタイプやその他の構造変更がある場合があります) で使用できます。 ダウンストリーム テーブルが完全な更新を必要とする場合、このテーブルには履歴データが含まれますが、それ自体は完全な更新を必要としません。

全面的な更新を実行する前に、代替案を検討してください。

代替案としては以下が挙げられます。

  1. フローのソースを変更する場合は、ストリーミングテーブルの既存のフローを更新するのではなく、新しいフローを作成することを検討してください。これによりテーブル内の既存データは保持されますが、新しいフローには新しいチェックポイントがあるため、重複データが書き込まれる可能性があります。
  2. あるいは、チェックポイントをリセットすることもできますが、その場合、ターゲットテーブルに重複データが書き込まれる可能性があります。
  3. どちらのオプションも受け入れられない場合は、新しいストリーミング テーブルを作成し、ビューを使用して新旧のストリーミング テーブルを結合することを検討してください。

完全な更新が必要な場合

全面的な更新 が 必要な場合は、以下のベストプラクティスに従ってください。

  • 開発環境またはステージング環境で動作をテストしてください。
  • 影響を受ける下流の依存関係を文書化してください。
  • 本番運用のワークロードへの影響を最小限に抑えるために、メンテナンス期間中に更新をスケジュールしてください。
  • ストリームを再生するのに十分な履歴データがソース システムに保持されていることを確認してください。

完全更新後にデータをバックフィルするには、 append onceフローを作成できます。これは、最初の埋め戻し処理後も継続して実行することなく、一度限りの埋め戻し処理を実行します。コードはパイプライン内に残り、パイプラインが完全に更新された場合、バックフィル処理が再実行されます。