Spulen Sie eine Pipeline zurück und spielen Sie sie erneut ab

Important

Dieses Feature befindet sich in der Betaversion. Um es zu aktivieren, setze deine Pipeline auf den Vorschaukanal und setze die Pipeline-Konfiguration pipelines.rewind.betaEnabled auf true. Siehe Anforderungen.

Eine fehlerhafte Transformation, ein fehlerhafter Batch von Quelldatensätzen oder eine unerwartete Änderung am Schema können dazu führen, dass die Tabellen einer Pipeline ab einem bestimmten bekannten Zeitpunkt fehlerhaft sind. Rewind bringt die Pipeline an einen Punkt vor dem Problem zurück, sodass Sie eine Lösung bereitstellen und nur die betroffenen Daten neu verarbeiten können.

Rewind stellt Tabellenversionen, Streaming-Quell-Offsets und den Operatorstatus gemeinsam wieder her, sodass Replay keine Datensätze überspringt oder Duplikate schreibt. Drei Operationen verarbeiten Daten neu und lösen verschiedene Probleme:

  • Zurückspulen ist für eine wiederherstellbare Pipeline gedacht, die ab einem bekannten Zeitpunkt fehlerhafte Daten geschrieben hat, etwa nach einer fehlerhaften Transformation, fehlerhaften Eingabedaten oder einer fehlerhaften Bereitstellung. Es stellt Tabellendaten, Quelloffsets und den Operatorstatus auf einen Punkt vor dem Problem wieder her und verarbeitet nur die betroffenen Daten erneut, wobei der Operatorstatus erhalten bleibt. Daten vor diesem Punkt sind unberührt.
  • Full Refresh stellt eine Tabelle aus allen verfügbaren Quelldaten neu zusammen und verwirft deren aktuellen Inhalt. Nutze es, um alles von Grund auf neu zu berechnen oder wenn eine Codeänderung nicht mit dem bestehenden Zustand kompatibel ist.
  • Der Checkpoint-Reset stellt eine Pipeline wieder her, deren Checkpoint ungültig oder beschädigt ist oder die durch eine Checkpoint-inkompatible Codeänderung blockiert wird. Er setzt den Kontrollpunkt zurück und setzt sich fort, während der aktuelle Inhalt der Tabelle erhalten bleibt. Rewind kann diese Fälle nicht wiederherstellen, da es die Kompatibilitätsregeln für strukturiertes Streaming nicht lockert.

Anforderungen

Anforderung Detail
Kanal Die Pipeline muss sich auf dem Vorschau-Kanal befinden. Siehe Konfigurieren von Pipelines.
Konfiguration Setze die Pipeline-Konfiguration pipelines.rewind.betaEnabled auf true, und führe die Pipeline einmal aus. Jeder Fluss wird erst nach Abschluss eines Updates mit aktivierter Zeitreise zurückspulbar.
Pipelinemodus Triggerbasierte und kontinuierliche Pipelines. Der Echtzeitmodus wird nicht unterstützt.
Quellen Delta-Tabellen, Streaming-Tabellen, Kafka und Auto Loader.
Ziele Streamtabellen und materialisierte Ansichten.
Flows Streaming-Flüsse und AUTO Change Data Capture (CDC)-Flüsse, einschließlich SCD Typ 1 und SCD Typ 2 Ziele. Zustandsbehaftete Abfragen wie Aggregationen, Joins und Deduplizierung werden unterstützt.

Jeder Fluss in der Pipeline muss diese Anforderungen erfüllen. Während pipelines.rewind.betaEnabledtrue ist, schlagen bei einer Pipeline, die einen Flow enthält, der die Voraussetzungen nicht erfüllt, die Aktualisierungen fehl. Überprüfen Sie, dass jeder Fluss die oben genannten Anforderungen erfüllt, bevor Sie ihn aktivieren.

Note

Eine Pipeline, bei der true auf pipelines.rewind.betaEnabled gesetzt ist, kann nicht zum aktuellen Kanal zurückkehren, bis der aktuelle Kanal auf eine Runtime aktualisiert wird, die das Zurückspulen unterstützt.

Wie Rückspulen und Wiederholen funktionieren

Zurückspulen und wiederholen sind getrennte Schritte.

Rewind setzt jede Tabelle auf die Version zurück, die sie an einem Rewind-Punkt hatte, und setzt die Streaming-Checkpoints zurück, die protokollieren, wie weit jeder Flow gelesen hat. Deine Transformationen werden nicht ausgeführt, und keine Quelldaten werden neu verarbeitet.

Die Wiederholung erfolgt beim nächsten Start der Pipeline. Es verarbeitet ab dem Rückspulpunkt unter Verwendung der aktuellen Pipeline-Definition erneut, holt bis zum aktuellen Stand auf und setzt dann die normale inkrementelle Verarbeitung fort. Rewind startet die Pipeline nicht; starte sie daher selbst, wenn du bereit bist.

Die Pipeline erzeugt automatische Rückspulpunkte, etwa einmal pro Stunde, und speichert sie 7 Tage lang. Eine gerade erstellte Pipeline hat nichts, worauf man zurückspulen kann, bis sie die erste produziert.

Das Zurückspulen eines Datensatzes spult auch alle nachgelagerten Elemente in derselben Pipeline zurück. Rewind deckt eine Pipeline ab. Sie koordiniert sich nicht mit anderen Pipelines oder mit externen Readern derselben Tabellen, daher verwalten Sie diese separat.

Eine Pipeline über die Benutzeroberfläche zurücksetzen

Die Benutzeroberfläche und Genie sind die wichtigsten Möglichkeiten, rewind zu nutzen. Die Benutzeroberfläche zeigt die verfügbaren Wiederherstellungspunkte an und zeigt, welche Datensätze von ihnen jeweils betroffen sind, bevor du die Änderungen bestätigst.

  1. Klicken Sie auf Ihrer Pipeline-Seite auf das Chevron-Symbol nach unten neben Pipeline ausführen und klicken Sie dann auf Pipeline zurückspulen.
  2. Wählen Sie einen Rückspulpunkt oder verwenden Sie eine Abkürzung wie Rückspulen bis gestern oder Zurückspulen zum neuesten Punkt. Klicke auf Weiter.
  3. Wähle aus, welche Tabellen du einbeziehen möchtest. Verwenden Sie die Graph-Ansicht , um Datensätze im Pipeline-Graphen auszuwählen, oder die Listenansicht , um sie aus einer Tabelle auszuwählen. Lassen Sie Alle Prüfpunkte zurücksetzen ausgewählt (die Standardeinstellung), um Quell-Offsets und den Operatorstatus zusammen mit den Tabellendaten wiederherzustellen, sodass die Pipeline ab dem Rücksetzpunkt erneut verarbeitet wird. Lösche sie nur, um die Tabellendaten wiederherzustellen, ohne erneut zu verarbeiten, zum Beispiel wenn du den Inhalt einer Tabelle wiederherstellen möchtest, aber die betroffenen Daten nicht neu verarbeiten möchtest. Diese Einstellung muss für eine Tabelle und ihre Upstreams gleich sein und kann nicht für einen Fluss, der eine externe Quelle wie Kafka oder Auto Loader liest, gelöscht werden. Klicke auf Weiter.
  4. Überprüfen Sie den Wiederherstellungspunkt, die Checkpoint-Einstellungen und die betroffenen Datensätze und klicken Sie dann auf Zurückspulen.

Starte die Pipeline, um die Daten erneut abzuspielen.

Du kannst immer wieder zurückspulen. Jedes Zurückspulen ersetzt das letzte, sodass du dich nach einem fehlgeschlagenen Replay erholen kannst, indem du an eine andere Stelle zurückspulst.

Spulen Sie eine Pipeline mithilfe der API, CLI oder SDK zurück

Zusätzlich zur Benutzeroberfläche und Genie kann man programmatisch mit der Databricks-CLI, der REST-API oder dem Python SDK ein Rollback auslösen. Nutzen Sie den programmatischen Weg für die Automatisierung, wie zum Beispiel einen Korrekturauftrag, ein Test-Harness oder einen Orchestrator.

Ein Zurückspulen-Vorgang ist ein einzelnes Pipeline-Update, dessen Anfragekörper einen rewind_spec enthält. Die Felder in rewind_spec setzen die gleichen Optionen wie in der Benutzeroberfläche: Der Punkt zum Zurückspulen, die Datensätze, die aufgenommen werden sollen und ob Checkpoints zurückgesetzt werden sollen. Replay ist das nächste Update, das du ohne rewind_specsendest, was dem API-Äquivalent zum Pipeline-Start entspricht. Rewind startet die Pipeline nicht für dich.

Du kannst eines der folgenden auswählen:

  • Ein Wiederherstellungspunkt (empfohlen). Setzen Sie rewind_point_id auf einen der Zurückspulpunkte, die die Pipeline generiert hat. Das ist dieselbe Entscheidung, die die UI und Genie treffen. Der Wiederherstellungspunkt zeichnet bereits die Tabellenversion und den Kontrollpunkt für jeden Datensatz auf, sodass die Wiederherstellung genau diesen Zustand wiederherstellt. Siehe Rücksetzpunkt finden.
  • Ein Zeitstempel. Setze rewind_timestamp auf einen beliebigen Zeitpunkt, an dem kein generierter Rückspulpunkt dem gewünschten Zustand entspricht. Du wählst den Zeitstempel selbst aus. Siehe Zurückspulen zu einem Zeitstempel.

Punkt zum Zurückspulen finden

Die Pipeline verzeichnet jeden Rückspulpunkt als rewind_summary-Ereignis in ihrem Ereignisprotokoll. Das id der Veranstaltung ist das rewind_point_id. Jeder periodische Rückspulpunkt zeichnet die aktuelle Version jeder Tabelle in der Pipeline auf. Ein Trockenlauf zeichnet auch einen Wiederherstellungspunkt für den von ihm validierten Zustand auf. Um die Rückspulpunkte der letzten 7 Tage aufzulisten, führe eine Abfrage wie folgt aus:

SELECT id AS rewind_point_id, timestamp, message
FROM event_log('<pipeline-id>')
WHERE event_type = 'rewind_summary'
  AND details:rewind_summary.dry_run = true
  AND timestamp > current_timestamp() - INTERVAL 7 DAYS
ORDER BY timestamp DESC;

Periodische Wiederherstellungspunkte haben den Zeitstempel Periodic rewind summary capturing current table versions.. Um fehlerhafte Daten rückgängig zu machen, wähle den aktuellsten Wiederherstellungspunkt, dessen timestamp vor dem Schreiben der fehlerhaften Daten liegt.

Wenn die ID nicht mit einem rewind_summary-Ereignis im Ereignisprotokoll der Pipeline übereinstimmt, scheitert das Rückspulen mit INVALID_REWIND_SPECIFICATION.REWIND_POINT_NOT_FOUND.

Request-Body zurücksetzen

Um eine Pipeline zurückzusetzen, senden Sie ein Update mit einem rewind_spec Body wie folgt:

Rückspulpunkt

{
  "cause": "USER_ACTION",
  "rewind_spec": {
    "rewind_point_id": "<rewind-point-id>",
    "datasets": [
      {
        "identifier": "catalog.schema.table",
        "cascade": true,
        "reset_checkpoints": true
      }
    ],
    "dry_run": false
  }
}

Timestamp

{
  "cause": "USER_ACTION",
  "rewind_spec": {
    "rewind_timestamp": "2026-09-29 08:36:55",
    "datasets": [
      {
        "identifier": "catalog.schema.table",
        "cascade": true,
        "reset_checkpoints": true
      }
    ],
    "dry_run": false
  }
}

Zurückspulen mit der CLI

Die Databricks-CLI gibt den Request-Body über --json weiter. Um eine Pipeline zurückzusetzen, führen Sie Folgendes aus:

Rückspulpunkt

Der databricks pipelines start-update Befehl entfernt rewind_point_id aus dem Request-Body. Senden Sie die Anfrage stattdessen mit databricks api post, wodurch der Body unverändert durchgereicht wird:

databricks api post /api/2.0/pipelines/<pipeline-id>/updates --json @rewind.json --profile <profile>

Timestamp

databricks pipelines start-update <pipeline-id> --json @rewind.json --profile <profile>

Um die Daten erneut abzuspielen, starten Sie ein einfaches Update ohne rewind_spec:

databricks pipelines start-update <pipeline-id> --profile <profile>

Um ein Update so lange abzufragen, bis es einen Terminalzustand erreicht, führen Sie Folgendes aus:

databricks pipelines get-update <pipeline-id> <update-id> --profile <profile>

Zurückspulen mit der REST-API

Um eine Pipeline zurückzusetzen, senden Sie eine POST Anfrage an den Start-an-Update-Endpunkt mit dem rewind_spec Body. Beispiele:

Rückspulpunkt

curl -sS -X POST \
  "https://<workspace-host>/api/2.0/pipelines/<pipeline-id>/updates" \
  -H "Authorization: Bearer $DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "cause": "USER_ACTION",
    "rewind_spec": {
      "rewind_point_id": "<rewind-point-id>",
      "datasets": [{"identifier": "catalog.schema.table", "cascade": true, "reset_checkpoints": true}],
      "dry_run": false
    }
  }'

Timestamp

curl -sS -X POST \
  "https://<workspace-host>/api/2.0/pipelines/<pipeline-id>/updates" \
  -H "Authorization: Bearer $DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "cause": "USER_ACTION",
    "rewind_spec": {
      "rewind_timestamp": "2026-09-29 08:36:55",
      "datasets": [{"identifier": "catalog.schema.table", "cascade": true, "reset_checkpoints": true}],
      "dry_run": false
    }
  }'

Zurückspulen mit dem Python SDK

Rücksetzpunkt

Der typisierte RewindSpec Helfer enthält rewind_point_id nicht. Senden Sie die Anfrage stattdessen mit dem authentifizierten REST-Client des SDK. Dies funktioniert in jeder SDK-Version, einschließlich der databricks-sdk in Databricks Runtime enthaltenen SDK-Version und serverlosem Compute. Um eine Pipeline zurückzusetzen, führen Sie Folgendes aus:

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()  # In a notebook, authenticates as the notebook identity.
resp = w.api_client.do("POST", f"/api/2.0/pipelines/{pipeline_id}/updates", body={
    "cause": "USER_ACTION",
    "rewind_spec": {
        "rewind_point_id": rewind_point_id,
        "datasets": [{"identifier": root_table, "cascade": True, "reset_checkpoints": True}],
        "dry_run": False,
    },
})
print(resp["update_id"])

Timestamp

Der getippte RewindSpec Helfer wird direkt auf den Request-Body abgebildet. Es benötigt databricks-sdk 0,40 und höher. Um eine Pipeline zurückzuspulen, führen Sie Folgendes aus:

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.pipelines import StartUpdateCause, RewindSpec, RewindDatasetSpec

w = WorkspaceClient(profile="<profile>")
resp = w.pipelines.start_update(
    "<pipeline-id>",
    cause=StartUpdateCause.USER_ACTION,
    rewind_spec=RewindSpec(
        rewind_timestamp="2026-09-29 08:36:55",
        datasets=[RewindDatasetSpec(
            identifier="catalog.schema.table",
            cascade=True,
            reset_checkpoints=True,
        )],
        dry_run=False,
    ),
)
print(resp.update_id)

Das mit Databricks Runtime gebündelte databricks-sdk, einschließlich serverloser Rechenleistung, könnte älter sein als das typisierte RewindSpec. In einem Notizbuch verwenden Sie den authentifizierten REST-Client, der in jeder SDK-Version verfügbar ist, sodass Sie kein neueres SDK installieren müssen:

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()  # Authenticates as the notebook identity.
w.api_client.do("POST", f"/api/2.0/pipelines/{pipeline_id}/updates", body={
    "cause": "USER_ACTION",
    "rewind_spec": {
        "rewind_timestamp": rewind_timestamp,
        "datasets": [{"identifier": root_table, "cascade": True, "reset_checkpoints": True}],
        "dry_run": False,
    },
})

Referenz zur Rückspul-Spezifikation

Die folgende Tabelle beschreibt die Felder im rewind_spec Body.

Feld Description
rewind_point_id Das id eines rewind_summary Ereignisses, zu dem wiederhergestellt werden soll. Siehe Einen Rückspulpunkt finden. Setze genau eines von rewind_point_id oder rewind_timestamp.
rewind_timestamp Der Zeitpunkt, auf den wiederhergestellt werden soll, im UTC-Format yyyy-MM-dd HH:mm:ss. Siehe Zu einer Zeitmarke zurückspulen. Setze genau eins von rewind_point_id oder rewind_timestamp.
datasets Die Liste der zurückzusetzenden Datensätze. Lass die Liste weg, um alle Datasets in der Pipeline zurückzuspulen, jeweils mit cascade und reset_checkpoints auf true gesetzt.
datasets[].identifier Der vollständig qualifizierte Name des Datensatzes zum Zurückspulen in Form catalog.schema.table .
datasets[].cascade Ob man auch jeden Datensatz stromabwärts von diesem in der Pipeline zurückspulen sollte. Geben Sie dieses Feld für jeden Datensatz an. Für eine lineare Pipeline setzen Sie sie auf true auf dem Root-Datensatz, um die gesamte Pipeline zurückzuspulen.
datasets[].reset_checkpoints Ob Streaming-Quell-Offsets und Operator-Status zurückgesetzt werden sollen, damit ab dem Rücksetzpunkt erneut verarbeitet wird. Dies ist die Einstellung der Benutzeroberfläche Alle Checkpoints zurücksetzen. Wird standardmäßig auf true festgelegt. Stelle es so ein, dass false Tabellendaten nur wiederhergestellt werden, ohne erneute Verarbeitung.
dry_run Rewind überprüfen, ohne eine Tabelle zu ändern. Wird standardmäßig auf false festgelegt. Siehe Testen Sie das Zurückspulen in einem Probelauf.

Warning

Wenn ein Root-Datensatz eine externe Quelle wie Kafka oder Auto Loader liest, lassen Sie reset_checkpoints auf true gesetzt. Die Benutzeroberfläche verhindert, dass Reset all checkpoints für diese Quellen gelöscht werden, aber die API akzeptiert eine Anfrage, die reset_checkpoints auf false setzt. Die Anfrage wurde akzeptiert und der Rewind kann gestartet werden, aber die Pipeline fällt danach aus. Begrenze reset_checkpoints: false auf Datensätze, die ein Streaming-Fluss nicht liest.

Spulen Sie zu einem Zeitstempel zurück

Verwenden Sie rewind_timestamp , wenn kein generierter Rückspulpunkt mit dem gewünschten Zustand übereinstimmt, zum Beispiel um auf einen Punkt zwischen zwei Rückspulpunkten zurückzuspulen. Du gibst den Zeitstempel selbst an. Befolgen Sie zwei Regeln:

  • Wähle einen Punkt strikt zwischen zwei Commits, nicht einen, der auf einen Commit fällt. Ein Zeitstempel, der auf einem Commit landet, kann beim Replay fehlschlagen. Nutze den Mittelpunkt zwischen dem letzten guten Commit und dem ersten schlechten Comit.
  • Bei einer Pipeline, die weder zurückgespult noch aktualisiert wurde, scannen Sie den Änderungsdatenfeed von Version 1. Version 0 zeichnet keine Änderungsdaten auf. Wenn Version 1 älter ist als die Dateiaufbewahrungszeit der Tabelle (standardmäßig 7 Tage), schlägt der Scan fehl, also beginnen Sie stattdessen mit der ältesten Version, die innerhalb dieses Zeitraums festgeschrieben wurde.

Die untenstehende Abfrage, die die Commit-Zeiten findet, liest den Change Data Feed (CDF) der Pipeline-Tabelle, die Sie zurückspulen möchten, daher muss CDF in dieser Tabelle aktiviert sein. Das Rückspulen selbst erfordert keine CDF. Lakeflow-Pipelines aktivieren standardmäßig CDF für ihre Tabellen, sodass die Abfrage ohne zusätzliche Einrichtung funktioniert. Wenn CDF auf der Tabelle deaktiviert wurde, verwenden Sie einen Wiederherstellungspunkt oder verwenden Sie DESCRIBE HISTORY, um stattdessen einen Punkt auszuwählen.

Passen Sie den _change_type Filter dem Fehler an, den Sie untersuchen: Bei fehlerhaften Einfügungen oder Updates behalten Sie 'insert' und 'update_postimage' bei; bei fehlerhaften Löschungen filtern Sie stattdessen nach 'delete', da table_changes gelöschte Zeilen nur bei diesem Änderungstyp anzeigt. Um einen Zeitstempel des Mittelpunkts aus einem Prädikat zu berechnen, das die schlechten Daten auswählt, führen Sie eine Abfrage wie folgt aus:

WITH onset AS ( -- The first commit that introduced the bad data.
  SELECT min(_commit_version) AS first_bad_version,
         min(_commit_timestamp) AS first_bad_ts
  FROM table_changes('catalog.schema.table', 1) -- Start from version 1.
  WHERE _change_type IN ('insert', 'update_postimage') -- Use ('delete') instead to find an erroneous delete.
    AND (event_date >= '2026-09-29') -- Example predicate. Replace the condition in parentheses with one that selects the bad rows.
),
bounds AS (
  SELECT first_bad_ts,
         (SELECT max(h.timestamp)
          FROM (DESCRIBE HISTORY catalog.schema.table) h
          WHERE h.version < onset.first_bad_version) AS last_good_ts
  FROM onset
)
SELECT date_format(
         from_unixtime((unix_timestamp(last_good_ts) + unix_timestamp(first_bad_ts)) / 2),
         'yyyy-MM-dd HH:mm:ss') AS rewind_timestamp
FROM bounds;

Wenn die Pipeline bereits zurückgespult oder aktualisiert wurde, starten Sie den Scan ab dem neuesten RESTORE- oder Refresh-Commit, sodass sie nicht über die vorherige Operation hinausgeht.

Testen Sie den Rücklauf in einem Probelauf

Um eine Rückspulung zu validieren, ohne eine Tabelle zu ändern, setzen Sie dry_run auf true. Das Update läuft durch die Validierung in einen Endzustand COMPLETED, ohne die Daten zu verändern. Verwenden Sie einen Trockenlauf, um zu bestätigen, dass die Pipeline das Rückspulen akzeptiert, und senden Sie die Anfrage erneut mit dry_run gesetztem auf false.

Ein Trockenlauf zeichnet das Rückspulen als validiertes rewind_summary-Ereignis auf. Um genau dieses Rückspulen anzuwenden, zum Beispiel nach einem Trockenlauf mit rewind_timestamp, senden Sie das echte Rückspulen mit dem id des Ereignisses als rewind_point_id. Ein Trockenlauf, der fehlschlägt, blockiert spätere Updates nicht.

Wenn du in der Automatisierung aufeinanderfolgende Rückspul- und Wiedergabezyklen ausführst, führe eine vollständige Aktualisierung zwischen ihnen durch. Das Stapeln eines zweiten Rewinds und Replays auf einer Pipeline ohne vollständige Aktualisierung dazwischen kann die reprozessierten Zeilen in nachgelagerten Streaming-Tabellen duplizieren.

Nach dem Rückspulen

Ein Fehler bei der Wiederausführung versetzt die Pipeline in einen vorherigen Zustand zurück, sie bleibt jedoch angehalten. Repariere den Code oder die Quelldaten und starte die Pipeline, um es erneut zu versuchen, oder spule zu einem anderen Punkt zurück. Die Pipeline rollt nicht von selbst zurück, und Fehler treten durch Standard-Pipeline-Diagnosen und das Ereignisprotokoll auf.

Replay ist nur erfolgreich, wenn die aktuelle Pipeline-Definition mit dem wiederhergestellten Zustand kompatibel ist; Rewind lockert die Kompatibilitätsregeln für strukturiertes Streaming nicht. Für welche Änderungen kompatibel sind, siehe Arten von Änderungen in Structured Streaming-Abfragen. Materialisierte Views folgen der Batch-Semantik und tolerieren umfassendere Schemaänderungen, scheitern aber trotzdem, wenn eine Abhängigkeit inkompatibel ist.

Ein fehlgeschlagener Rückspulvorgang kann die Pipeline teilweise zurückgespult hinterlassen. Sie haben zwei Möglichkeiten:

  1. Spult man erneut zum gleichen oder einem anderen Punkt zurück, konvergiert die Pipeline zu diesem Punkt.
  2. Um die Pipeline trotz des unvollständigen Rückspulvorgangs zu einem normalen Update zu zwingen, setzen Sie pipelines.allowUpdateAfterIncompleteRewind auf true und starten Sie die Pipeline neu.

Note

Wenn ein Rewind-Vorgang fehlschlägt oder du ihn mit einem ungültigen Rewind-Punkt sendest, blockiert die Pipeline jedes nachfolgende Nicht-Rewind-Update, einschließlich einer vollständigen Aktualisierung, bis du einen gültigen Rewind erneut auslöst. Wenn du programmatisch Rückspulungen auslöst, bestätige, dass rewind_point_id oder rewind_timestamp sich auf einen gültigen Punkt bezieht, bevor du die Anfrage sendest.

Wie weit man zurückspulen kann

Rückspulpunkte werden 7 Tage gehalten. Innerhalb dieses Zeitfensters schlägt das Zurückspulen fehl, wenn die dafür benötigten Daten bereits entfernt wurden. Achten Sie auf Folgendes, bevor Sie sich auf die Rückspulfunktion verlassen:

  • VACUUM oder ein kurzes delta.deletedFileRetentionDuration auf Ihren Tischen. Siehe „Den Tabellenverlauf nutzen“.
  • Die Quellenbindung ist kürzer als das Zeitfenster, über das man zurückspulen möchte, wie bei einem Kafka-Thema, das einen Tag hält.

Pipelines mit mehreren Quellen oder langen Abhängigkeitsketten benötigen eine längere Aufbewahrungsdauer, weil jede Tabelle und jeder Checkpoint bis zu einem konsistenten Punkt zurückreichen muss.

Einschränkungen

  • Rewind kann eine Pipeline nicht auf einen Punkt vor einer vollständigen Aktualisierung wiederherstellen.
  • Wiederherstellungspunkte werden 7 Tage lang aufbewahrt, und eine Wiederherstellung schlägt fehl, wenn die Tabellenhistorie oder die Quelldaten, die benötigt werden, um diesen Punkt zu erreichen, bereits entfernt wurden, zum Beispiel durch VACUUM oder eine kurze Aufbewahrungsdauer der Quelldaten. Sieh mal, wie weit du zurückspulen kannst.
  • Der Echtzeitmodus wird nicht unterstützt.
  • Kinesis, Pulsar, Google Pub/Sub und benutzerdefinierte Quellcodes, die mit den Datenquellen-APIs DSv2 oder Python erstellt wurden, werden nicht als Quellen unterstützt.
  • Externe und benutzerdefinierte Senken werden nicht unterstützt, einschließlich Senken, die mit definiert sind create_sink(). Siehe Verwenden von Senken in Pipelines.
  • Streaming-Tabellen, die einen Zeilenfilter oder eine Spaltenmaske verwenden, können nicht zurückgespult werden. Siehe Manuelles Anwenden von Zeilenfiltern und Spaltenmasken.
  • Zustandsbehaftetes Zurücksetzen erfordert den RocksDB-State-Store, den Pipelines standardmäßig nutzen. Ein Rückspulen fehlschlägt bei einem Flow, der mit einem anderen Zustandsspeicher konfiguriert ist.
  • Einige AUTO CDC-Streaming-Tabellen benötigen eine Aktualisierung, bevor sie zurückgespult werden können. Die Pipeline benachrichtigt Sie, wenn Sie die Rückspulung anfordern.
  • Materialisierte Ansichten könnten nach einem Zurücksetzen vollständig neu berechnet werden, anstatt inkrementell aktualisiert zu werden. Siehe inkrementelle Aktualisierung für materialisierte Ansichten.
  • Rewind deckt eine Pipeline ab und koordiniert nicht mit externen Readern oder anderen Pipelines, die dieselben Tabellen lesen.
  • Rewind stellt weder Pipeline-Code, Pipeline-Konfiguration noch Unity-Catalog-Objektmetadaten wie Tags und Grants wieder her.

Weitere Ressourcen

  • Zuletzt aktualisiert um