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

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

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

データ ソースへの影響

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

たとえば、ソースが 24 時間リテンション期間の Kafka で、そのウィンドウの後に完全な更新を実行した場合、古いメッセージは使用できなくなり、再処理できません。

注

高トラフィックのストリーミングワークロードや、アップストリームリテンションによって履歴データの再生が妨げられる場合、フルリフレッシュは推奨されません。

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

完全更新を実行するタイミング

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

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

スキーマの変更

ターゲット テーブルの次のスキーマ変更は下位互換性を持たず、完全な更新が必要です。

  • 列マッピング モードが有効になっていない列の名前変更。
  • 重複除去列の変更。
  • 次のような列データ型の変更を行う:
    • 絞り込み ( BIGINT → INT や DOUBLE → FLOATなど) を入力します。
    • 互換性のない型の変更 (たとえば、 STRING → INT)。
  • テーブル スキーマからの列のハード削除。

このような種類のスキーマ変更の場合、Databricks では、目的のスキーマまたは名前を持つ新しい列を作成し、ストリーミング テーブルの上部にあるビューを使用して古い値と新しい値を結合することをお勧めします。

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

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

  • 従来のパーティション分割から新しいクラスタリング スキームへの移行。

アップストリーム ソースの変更

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

  • ストリーミング クエリによって読み取られたソース テーブルを変更する。
  • ソースの種類の切り替え (Kafka から Delta への切り替え、Kafka への自動ローダーなど)。
  • テーブル パスや Kafka トピック サブスクリプションなどのソースの場所を変更する。
  • スキーマが変更されていない場合でも、ソース Delta テーブルを削除して再作成します。

ステートフル処理の変更

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

  • 集計グループ化キーまたは集計関数の変更。
  • 集計を追加または削除すること。
  • 結合キーまたは結合の種類を変更する。
  • 結合の追加または削除。
  • 重複除去列または重複除去ロジックの変更。

データ継続性の問題

データの継続性が損なわれると、完全な更新が必要になる場合があります。

  • 保持期限が切れ、CDC ログが使用できなくなった。
  • ストリーミング チェックポイント ディレクトリの破損または削除。
  • スキーマ追跡またはスキーマの場所ファイルの破損または損失。

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

制限事項

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

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

ベスト プラクティス

状況 ベスト プラクティス
安定性のための設計 完全な更新が必要な変更を避けるためにスキーマを計画します。 通常、列の追加は安全ですが、既存の列またはパーティション分割スキームを変更するには、通常、テーブルを再計算する必要があります。
保有期間が短いソースからのストリーム Kafka トピックなど、保持期間が長くないソースからのストリーミングは、完全な更新によってソースにまだデータが残っていないデータが失われることを意味します。
履歴データの損失を回避するには、生データをストリーミング テーブル ( medallion アーキテクチャのブロンズ テーブル) にストリーミングします。 柔軟な列型 (バリアント型や文字列型など) を使用して、アップストリーム データが変更された場合に完全な更新が必要なこのテーブルを回避します。 このテーブルは履歴データを格納でき、ダウンストリーム ストリーミング テーブルで使用できます (厳密な型やその他の構造変更が発生する可能性があります)。 ダウンストリーム テーブルで完全更新が必要な場合、このテーブルには履歴データが含まれますが、完全更新自体は必要ありません。
完全更新を実行する前に代替手段を検討する 代替手段は次のとおりです。
  • フローのソースを変更する場合は、ストリーミング テーブルの既存のフローを更新するのではなく、新しいフローを作成することを検討してください。 これにより、テーブル内の既存のデータが保持されますが、新しいフローに新しいチェックポイントがあるため、重複するデータが書き込まれる可能性があります。
  • または、チェックポイントをリセットすることもできますが、これにより、重複するデータがターゲット テーブルに書き込まれる可能性があります。
  • どちらのオプションも許容できない場合は、新しいストリーミング テーブルを作成し、ビューを使用して古いストリーミング テーブルと新しいストリーミング テーブルを結合することを検討してください。
完全な更新が必要な場合 完全な更新が必要な場合は、次のベスト プラクティス に 従います。
  • 開発環境またはステージング環境で操作をテストします。
  • 影響を受けるダウンストリームの依存関係を文書化します。
  • 運用ワークロードへの影響を最小限に抑えるために、メンテナンス期間中に更新をスケジュールします。
  • ストリームを再生するのに十分な履歴データがソース システムに保持されていることを確認します。

完全更新後にデータをバックフィルするには、 append onceフローを作成します。 これにより、1 回限りのバックフィルが実行され、最初のバックフィルの後は実行が続行されません。 コードはパイプラインに残り、パイプラインが再び完全に更新されると、バックフィルが再実行されます。

  • Last updated on