Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die automatische Gültigkeitsdauer (Auto-TTL) löscht Zeilen aus von Unity Catalog verwalteten Tabellen nach Ablauf eines konfigurierbaren Zeitraums automatisch auf Grundlage des Werts in einer Zeitstempelspalte. Sie definieren einen Ablaufzeitraum in Tagen und geben eine Zeitstempelspalte für den Vergleich an. Databricks führt DELETE-, PURGE- und VACUUM-Vorgänge im Hintergrund aus, um abgelaufene Zeilen zu entfernen und sie aus dem Speicher zu löschen.
Im Folgenden finden Sie zwei Beispiele dafür, wie Sie die automatische Time-to-Live-Funktion verwenden können:
- Möglicherweise möchten Sie Daten entfernen, die älter als 1 Jahr sind, um die Speicherkosten niedrig zu halten. Ablaufen Sie zeilen 1 Jahr nach der Erstellung, indem Sie einen Ablaufzeitraum von 365 Tagen für eine
created_atZeitstempelspalte angeben. - Möglicherweise möchten Sie Daten entfernen, die für das Löschen durch einen anderen Geschäftsprozess markiert wurden. Ablaufen von Zeilen 20 Tage nach der Verarbeitung einer Löschanforderung durch Angabe eines Ablaufzeitraums von 20 Tagen in einer benutzerdefinierten
del_request_approvedZeitstempelspalte.
Important
Die genaue Löschdauer ist nicht garantiert und kann je nach Systemlast variieren. Um die Löschung zu überprüfen, fragen Sie die Systemtabelle für die prädiktive Optimierung ab oder führen Sie DESCRIBE HISTORY für die Tabelle aus. Siehe Systemtabellen.
Die Pufferzeit zwischen dem Ablauf einer Zeile und ihrer dauerhaften Löschung kann bis zu 6 Tage plus den Wert der Tabelleneigenschaft für die Datenaufbewahrung betragen, der standardmäßig auf 7 Tage festgelegt ist. Informationen zum Konfigurieren der automatischen Gültigkeitsdauer für das Löschen innerhalb eines bestimmten Zeitrahmens finden Sie unter Berechnen von Konfigurationswerten für einen Zielablaufzeitraum und Konfigurieren der Datenaufbewahrung für Zeitreiseabfragen.
Auto Time-to-Live ist für Unity Catalog verwaltete Delta Lake-Tabellen, Apache Iceberg-Tabellen und Streaming-Tabellen mit Lakeflow-Pipelines verfügbar.
Requirements
- Sie müssen die predictive Optimierung aktivieren. Siehe Prädiktive Optimierung für verwaltete Unity Catalog-Tabellen.
- Wenn Sie die prädiktive Optimierung für eine Tabelle deaktivieren, für die die automatische Gültigkeitsdauer aktiviert ist, kann die automatische Gültigkeitsdauer nicht ausgeführt werden.
- Sie müssen über
MODIFY-Berechtigungen für eine Tabelle verfügen, um eine Richtlinie für die automatische Gültigkeitsdauer festzulegen oder zu löschen. Siehe "Standardtabellenberechtigungen". - Databricks Runtime 17.3 und höher.
- Databricks Runtime 17.2 und niedriger kann Tabellen mit automatischer Gültigkeitsdauer lesen und in solche Tabellen schreiben.
Automatische Gültigkeitsdauer aktivieren
Die automatische Gültigkeitsdauer wird je nach Quelltabelle unterschiedlich aktiviert:
von Delta Lake und Apache Iceberg verwaltete Tabellen
Um für eine neue Tabelle eine automatische Time-to-Live-Richtlinie festzulegen, geben Sie für <expiration_days> eine nicht negative ganze Zahl und für DATE eine Spalte mit dem Typ TIMESTAMP, TIMESTAMP_NTZ oder <time_column_name> an:
CREATE TABLE table_name DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;
So legen Sie eine Richtlinie für die automatische Gültigkeitsdauer für eine vorhandene Tabelle fest:
ALTER TABLE table_name DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;
So löschen Sie beispielsweise Zeilen 30 Tage nach dem created_at Zeitstempel:
ALTER TABLE my_catalog.my_schema.my_table DELETE ROWS 30 DAYS AFTER created_at;
Streamingtabellen mit Lakeflow-Pipelines
Wenn Sie eine automatische Zeit-zu-Live-Richtlinie für eine neue Streamingtabelle in einer Pipeline festlegen möchten, geben Sie zwei Werte an. Geben Sie eine nicht negative ganze Zahl für <expiration_days> und eine Spalte vom Typ DATE, TIMESTAMPoder TIMESTAMP_NTZ für <time_column_name>:
SQL
CREATE STREAMING TABLE table_name
DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>
AS SELECT * FROM STREAM(source);
Python
from pyspark import pipelines as dp
@dp.table(
auto_ttl={"timestamp_column": <time_column_name>, "expire_in_days": <expiration_days>}
)
def function_name():
return (query)
Das Ändern einer Streamingtabelle zur Verwendung der automatischen Gültigkeitsdauer (TTL) per SQL wird nicht unterstützt. Um die automatische Gültigkeitsdauer einer vorhandenen Streaming-Tabelle zu ändern, aktualisieren Sie den Pipelinecode und veröffentlichen Sie ihn erneut.
Streamen von Lesevorgängen aus Tabellen mit automatischer Gültigkeitsdauer
Wenn Sie Structured Streaming, Lakeflow-Pipelines oder Streaming-Tabellen verwenden, um aus einer Tabelle mit aktivierter automatischer Gültigkeitsdauer zu lesen, setzen Sie skipChangeCommits für den Streaming-Lesevorgang. Löschvorgänge bei automatischer Gültigkeitsdauer werden als Datenänderungen angezeigt. Ohne diese Einstellung schlägt der Streaming-Lesevorgang fehl, wenn die automatische Gültigkeitsdauer (TTL) Zeilen löscht.
Sehen Sie sich die folgenden Beispiele an:
Strukturiertes Streaming
# Source table with auto time-to-live
spark.sql("ALTER TABLE source_table DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>")
# Structured Streaming read
spark.readStream.format("delta").option("skipChangeCommits", "true").table("source_table")
Lakeflow-Pipelines
from pyspark import pipelines as dp
# Source table with auto time-to-live
spark.sql("ALTER TABLE source_table DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>")
# Lakeflow pipelines streaming read
@dp.table
def my_table():
return spark.readStream.format("delta").option("skipChangeCommits", "true").table("source_table")
Streamingtabellen
-- Source table with auto time-to-live
ALTER TABLE source_table DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;
-- Lakeflow pipelines streaming read
CREATE OR REFRESH STREAMING TABLE my_table AS
SELECT * FROM STREAM(source_table) OPTIONS (skipChangeCommits);
Überprüfen, ob die automatische Zeit-zu-Live-Funktion aktiviert ist
Verwenden Sie DESCRIBE TABLE EXTENDED, um zu bestätigen, dass die automatische Gültigkeitsdauer konfiguriert ist. Wenn die Eigenschaften autottl.expireInDays und autottl.timestampColumn festgelegt sind, ist die automatische Time-to-Live aktiviert.
Die Einstellungen für die automatische Gültigkeitsdauer werden in der Zeile Tabelleneigenschaften angezeigt:
DESCRIBE TABLE EXTENDED table_name;
Alternativ verwenden Sie SHOW TBLPROPERTIES, um die automatischen Time-to-Live-Eigenschaften anzuzeigen:
SHOW TBLPROPERTIES table_name;
Ausschalten der automatischen Gültigkeitsdauer
So löschen Sie eine Richtlinie für die automatische Gültigkeitsdauer von einer verwalteten Delta Lake- oder Apache Iceberg-Tabelle:
ALTER TABLE table_name DROP ROW DELETION;
Um eine automatische Time-to-Live-Richtlinie für eine Streamingtabelle zu löschen, setzen Sie auto_ttl im Pipeline-Code auf None und veröffentlichen Sie sie erneut:
from pyspark import pipelines as dp
@dp.table(
auto_ttl=None
)
def function_name():
return (query)
Datenlebenszyklus
Automatisches Time-to-Live (TTL) hilft bei der Automatisierung der Verwaltung des Datenlebenszyklus für Tabellen mit zeitbasierten Aufbewahrungsanforderungen.
Auto Time-to-Live verfügt über einen mehrstufigen Datenlebenszyklus. Nachdem eine Datenzeile abgelaufen ist, führt die prädiktive Optimierung die Befehle DELETE und VACUUM asynchron aus. Wenn Löschvektoren für die Tabelle aktiviert sind, führt die prädiktive Optimierung auch PURGE vor VACUUM aus, um Datendateien neu zu schreiben und gelöschte Zeilen zu entfernen. Weitere Informationen finden Sie unter Bereinigen von Nur-Metadaten-Löschvorgängen, um das Neuschreiben von Daten zu erzwingen.
Die genaue Löschdauer ist nicht garantiert und kann je nach Systemlast variieren. Informationen zum Überprüfen, ob Daten gelöscht wurden, finden Sie in Den Systemtabellen.
Wenn Sie die automatische Zeit-zu-Live-Funktion für Ihre Datenaufbewahrungsanforderungen ordnungsgemäß konfigurieren möchten, lesen Sie die folgenden Phasen:
| Stage | Duration | Description |
|---|---|---|
| Ablaufzeitraum | Der Benutzer definiert, wann die automatische Gültigkeitsdauer aktiviert wird. | Die Anzahl der Tage nach dem Wert der Zeitspalte, ab dem eine Zeile zum Löschen freigegeben ist. Legen Sie dies fest, wenn Sie die automatische Time-to-Live aktivieren. |
| Pufferzeit | Bis zu 3 Tage pro Befehl (DELETE, VACUUM) |
Die Verzögerung zwischen dem Zeitpunkt, an dem Zeilen zum Löschen berechtigt sind und wenn die Vorhersageoptimierung sie löscht. Es kann zwischen dem Ablauf einer Zeile und jedem asynchronen Befehl, DELETE und VACUUM, zu Verzögerungen kommen. Jede Verzögerung beträgt in der Regel weniger als 3 Tage, bis zu insgesamt 6 Tage. |
| Datenaufbewahrungsdauer | Der Benutzer definiert mit einer Tabelleneigenschaft. | Die Zeitspanne, während der gelöschte Zeilen gespeichert bleiben und über Time Travel zugänglich sind. Konfigurieren Sie für Delta Lake-Tabellen mit delta.deletedFileRetentionDuration. Konfigurieren Sie für Apache Iceberg-Tabellen mit iceberg.deletedFileRetentionDuration. Wenn die Eigenschaft nicht festgelegt ist, beträgt die Standardeinstellung 7 Tage. Siehe Konfigurieren der Datenaufbewahrung für Zeitreiseabfragen. |
Nach der dauerhaften Löschung über VACUUM sind gelöschte Zeilen auch mittels Time Travel nicht mehr zugänglich. Siehe Entfernen nicht verwendeter Datendateien mit Vakuum.
Hier ist eine visuelle Zeitleiste des Datenlebenszyklus, in der eine Zeile mit einem Zeitspaltenwert von t vier Phasen durchläuft, bevor ihre Dateien von VACUUM physisch gelöscht werden:
Berechnen von Konfigurationswerten für einen Zielablaufzeitraum
Important
Die automatische Gültigkeitsdauer löscht Daten asynchron. Siehe Datenlebenszyklus.
Um eine predictive Optimierung einzurichten, um Zeilen innerhalb einer Zielanzahl von Tagen aus dem Speicher zu entfernen, subtrahieren Sie die maximale Pufferzeit (6 Tage) und die Aufbewahrungsdauer der gelöschten Dateien von Ihrem Ziel:
target_expiration_days = target_days - 6 - deletedFileRetentionDuration
Wenn Sie beispielsweise Zeilen innerhalb von 30 Tagen bei der standardmäßigen Aufbewahrungsdauer von 7 Tagen entfernen möchten, setzen Sie expiration_days auf 17 DAYS:
target_expiration_days = 30 - 6 - 7 = 17 days
Um Zeilen nach 90 Tagen bei einer Aufbewahrungsdauer von 30 Tagen zu entfernen, legen Sie expiration_days auf 54 DAYS fest:
target_expiration_days = 90 - 6 - 30 = 54 days
Automatische Gültigkeitsdauer überwachen
Mit Systemtabellen können Sie automatische Zeit-zu-Live-Ereignisse überprüfen, Kosten überwachen und Warnungen für Fehler festlegen.
Systemtabellen
Überprüfen Sie Ereignisse der automatischen Gültigkeitsdauer mit der Systemtabelle für die prädiktive Optimierung. Die prädiktive Optimierung führt DELETE aus, um abgelaufene Zeilen zu entfernen, VACUUM, um sie aus dem Speicher zu löschen, und optional PURGE für Tabellen mit aktivierten Löschvektoren, um neue Dateien ohne gelöschte Zeilen zu erstellen.
Führen Sie die folgende Abfrage aus, um Vorgänge der automatischen Gültigkeitsdauer in allen Tabellen in den letzten 7 Tagen zu überprüfen:
WITH tables_with_deletes AS (
SELECT DISTINCT catalog_name, schema_name, table_name
FROM system.storage.predictive_optimization_operations_history
WHERE
operation_type = 'DELETE'
AND timestampdiff(day, start_time, now()) < 7
)
SELECT hist.*
FROM system.storage.predictive_optimization_operations_history AS hist
INNER JOIN tables_with_deletes AS t
ON hist.catalog_name = t.catalog_name
AND hist.schema_name = t.schema_name
AND hist.table_name = t.table_name
WHERE
hist.operation_type IN ('DELETE', 'PURGE', 'VACUUM')
AND timestampdiff(day, hist.start_time, now()) < 7
ORDER BY hist.start_time DESC;
Festlegen einer Warnung für Fehler der automatischen Gültigkeitsdauer
Um Benachrichtigungen zu empfangen, wenn automatische Zeit-zu-Live-Vorgänge fehlschlagen, erstellen Sie eine SQL-Benachrichtigung mit databricks mit einer Abfrage, die auf fehlgeschlagene Vorgänge in der Tabelle des Vorhersageoptimierungssystems überprüft. Siehe Databricks SQL-Warnung für Anweisungen zum Erstellen von Warnungen und Dokumentation zu den Systemtabellen für Abfragebeispiele.
Schätzen der Kosten für die automatische Gültigkeitsdauer
Verwenden Sie die folgende Abfrage, um zu ermitteln, wie viele DBUs in den letzten 30 Tagen durch Vorgänge der automatischen Gültigkeitsdauer verbraucht wurden:
WITH tables_with_deletes AS (
SELECT DISTINCT table_name
FROM system.storage.predictive_optimization_operations_history
WHERE
operation_type = 'DELETE'
AND timestampdiff(day, start_time, now()) < 30
)
SELECT SUM(usage_quantity) AS total_estimated_dbu
FROM system.storage.predictive_optimization_operations_history AS hist
INNER JOIN tables_with_deletes AS t
ON hist.table_name = t.table_name
WHERE
hist.operation_type IN ('DELETE', 'PURGE', 'VACUUM')
AND hist.usage_unit = 'ESTIMATED_DBU'
AND timestampdiff(day, hist.start_time, now()) < 30;
Überprüfen von Vorgängen in einer bestimmten Tabelle
Verwenden Sie DESCRIBE HISTORY, um kürzlich für eine bestimmte Tabelle ausgeführte Vorgänge anzuzeigen:
DESCRIBE HISTORY table_name;
Begrenzungen
Die folgenden Einschränkungen gelten für die automatische Gültigkeitsdauer:
Important
Die genaue Löschdauer ist nicht garantiert und kann je nach Systemlast variieren. Informationen zum Überprüfen, ob Daten gelöscht wurden, finden Sie in Den Systemtabellen.
- Die automatische Gültigkeitsdauer wird für materialisierte Ansichten nicht unterstützt.
- Die Syntaxen
ALTER TABLEundALTER STREAMING TABLEwerden zum Ändern der automatischen Time-to-Live-Einstellung bei Streaming-Tabellen nicht unterstützt. Zum Hinzufügen oder Ändern einer automatischen Zeit-zu-Live-Richtlinie für eine vorhandene Streamingtabelle aktualisieren Sie denauto_ttlParameter im Pipelinecode, und veröffentlichen Sie die Pipeline erneut. - Spaltenumbenennung wird für Zeitspalten, die in einer Richtlinie für die automatische Gültigkeitsdauer definiert sind, nicht unterstützt. Wenn die Spaltenzuordnung aktiviert ist, gilt diese Einschränkung weiterhin. Siehe Umbenennen und Löschen von Spalten mit der Delta Lake-Spaltenzuordnung.
- In seltenen Fällen können Vorgänge der automatischen Gültigkeitsdauer zu Transaktionskonflikten führen. Um das Risiko von Transaktionskonflikten zu verringern, verwenden Sie Liquid Clustering, das Konflikte mit der Parallelität auf Zeilenebene reduziert. Siehe Verwenden von Flüssigclustering für Tabellen.
- Wenn serverloses Computing aufgrund von Private Link nicht auf ADLS zugreifen kann, können automatische Time-to-Live-Operationen fehlschlagen. Siehe _