Automatisch rijen verwijderen met een automatische levensduur

Automatische bewaartermijn (Auto-TTL) verwijdert automatisch rijen uit door Unity Catalog beheerde tabellen na een configureerbare tijdsperiode op basis van de waarde in een tijdstempelkolom. U definieert een verloopperiode in dagen en geeft een tijdstempelkolom op voor vergelijking. Databricks voert DELETEen PURGEVACUUM bewerkingen op de achtergrond uit om verlopen rijen te verwijderen en ze uit de opslag te wissen.

Hier volgen twee voorbeelden van hoe u automatische time-to-live kunt gebruiken:

• Mogelijk wilt u gegevens verwijderen die ouder zijn dan 1 jaar om de opslagkosten laag te houden. Laat rijen 1 jaar na aanmaak verlopen door voor een created_at timestampkolom een vervalperiode van 365 dagen op te geven.
• Mogelijk wilt u gegevens verwijderen die zijn gemarkeerd voor verwijdering door een ander bedrijfsproces. Laat rijen 20 dagen nadat een verwijderingsaanvraag is verwerkt vervallen door een vervalperiode van 20 dagen op te geven voor een aangepaste del_request_approved-tijdstempelkolom.

Automatische time-to-live is beschikbaar voor door Unity Catalog beheerde Delta Lake-tabellen, Apache Iceberg-tabellen en streamingtabellen met Lakeflow-pijplijnen.

Requirements

• U moet voorspellende optimalisatie inschakelen. Zie Voorspellende optimalisatie voor beheerde tabellen in Unity Catalog.
  • Door voorspellende optimalisatie uit te schakelen voor een tabel met automatische time-to-live ingeschakeld, voorkomt u dat automatische time-to-live wordt uitgevoerd.
• U moet beschikken over MODIFY-machtigingen op een tabel om een automatisch time-to-live-beleid in te stellen of te verwijderen. Zie Basismachtigingen voor tabellen.
• Databricks Runtime 17.3 en hoger.
  • Databricks Runtime 17.2 en lager kan tabellen met een automatische levensduur lezen en ernaar schrijven.

Automatische time-to-live inschakelen

Schakel automatische time-to-live anders in, afhankelijk van de brontabel:

Door Delta Lake en Apache Iceberg beheerde tabellen

Als u een beleid voor automatische time-to-live wilt instellen voor een nieuwe tabel, geeft u een niet-negatief geheel getal voor <expiration_days> en een kolom met een type DATE, TIMESTAMPof TIMESTAMP_NTZ voor <time_column_name>:

CREATE TABLE table_name DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;

Een automatisch time-to-live-beleid instellen op een bestaande tabel:

ALTER TABLE table_name DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;

Als u bijvoorbeeld rijen 30 dagen na hun created_at tijdstempel wilt verwijderen:

ALTER TABLE my_catalog.my_schema.my_table DELETE ROWS 30 DAYS AFTER created_at;

Streamingtabellen met Lakeflow-pijplijnen

Als u een beleid voor automatische time-to-live wilt instellen voor een nieuwe streamingtabel in een pijplijn, geeft u twee waarden op. Geef een niet-negatief geheel getal op voor <expiration_days> en een kolom van het type DATE, TIMESTAMPof TIMESTAMP_NTZ voor <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)

Het wijzigen van een streamingtabel om automatische time-to-live te gebruiken met behulp van SQL, wordt niet ondersteund. Als u automatische time-to-live wilt wijzigen in een bestaande streamingtabel, werkt u de pijplijncode bij en publiceert u deze opnieuw.

Leesbewerkingen van tabellen streamen met automatische time-to-live

Als u Structured Streaming, Lakeflow-pijplijnen of streamingtabellen gebruikt om te lezen uit een tabel waarvoor automatische time-to-live is ingeschakeld, stelt u skipChangeCommits in voor de streamingleesbewerking. Automatische time-to-live-verwijderingsbewerkingen worden weergegeven als gegevenswijzigingen. Zonder deze instelling mislukt de streaming-leesactie wanneer rijen automatisch worden verwijderd door de time-to-live-instelling.

Zie de volgende voorbeelden:

Gestructureerd streamen

# 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-pijplijnen

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);

Controleer of automatische time-to-live is ingeschakeld

Gebruik DESCRIBE TABLE EXTENDED om te bevestigen dat automatische time-to-live is geconfigureerd. Als de eigenschappen autottl.expireInDays en autottl.timestampColumn zijn ingesteld, is automatische levensduur ingeschakeld.

De automatische time-to-live-instellingen worden weergegeven in de rij Tabeleigenschappen :

DESCRIBE TABLE EXTENDED table_name;

U kunt ook SHOW TBLPROPERTIES gebruiken om de eigenschappen voor automatische time-to-live te bekijken:

SHOW TBLPROPERTIES table_name;

Automatische time-to-live uitschakelen

Een automatisch time-to-live-beleid verwijderen uit een beheerde Delta Lake- of Apache Iceberg-tabel:

ALTER TABLE table_name DROP ROW DELETION;

Als u een automatisch time-to-live-beleid voor een streamingtabel wilt verwijderen, stelt u deze in auto_ttlNone de pijplijncode in en publiceert u het volgende opnieuw:

from pyspark import pipelines as dp

@dp.table(
  auto_ttl=None
)
def function_name():
  return (query)

Levenscyclus van gegevens

Een automatische time-to-live-instelling kan helpen het beheer van de levenscyclus van gegevens te automatiseren voor tabellen met tijdgebonden bewaartermijnen.

Automatische time-to-live heeft een gegevenslevenscyclus met meerdere fasen. Nadat een rij is verlopen, voert voorspellende optimalisatie asynchroon de opdrachten DELETE en VACUUM uit. Als verwijderingsvectoren zijn ingeschakeld in de tabel, wordt voorspellende optimalisatie ook uitgevoerd PURGE voordat VACUUM u gegevensbestanden herschrijft en verwijderde rijen verwijdert. Zie Alleen verwijderen van metagegevens opschonen om het herschrijven van gegevens af te dwingen.

Exacte verwijderingstijd is niet gegarandeerd en kan variëren op basis van systeembelasting. Zie Systeemtabellen voor meer informatie over het controleren of de gegevens zijn verwijderd.

Als u automatische time-to-live correct wilt configureren voor uw vereisten voor gegevensretentie, raadpleegt u de onderstaande fasen:

Na definitieve verwijdering via VACUUM zijn verwijderde rijen niet langer toegankelijk via time travel. Zie Ongebruikte gegevensbestanden verwijderen met vacuüm.

Hier volgt een visuele tijdlijn van de gegevenslevenscyclus, waarbij een rij met een tijdkolomwaarde van t vier fasen wordt verplaatst voordat de bestanden fysiek worden verwijderd door VACUUM:

Configuratiewaarden berekenen voor een doelverloopperiode

Als u voorspellende optimalisatie wilt instellen voor het verwijderen van rijen uit de opslag binnen een doelaantal dagen, trekt u de maximale buffertijd (6 dagen) en de duur van de verwijderde bestandsretentie af van uw doel:

target_expiration_days = target_days - 6 - deletedFileRetentionDuration

Als u bijvoorbeeld rijen binnen 30 dagen wilt verwijderen met de standaardretentieperiode van 7 dagen, stelt u expiration_days17 DAYSin op:

target_expiration_days = 30 - 6 - 7 = 17 days

Als u rijen binnen 90 dagen met een bewaarperiode van 30 dagen wilt verwijderen, stelt u het volgende in expiration_days54 DAYS:

target_expiration_days = 90 - 6 - 30 = 54 days

Automatische levensduur controleren

Met systeemtabellen kunt u automatische time-to-live-gebeurtenissen controleren, kosten bewaken en waarschuwingen instellen voor fouten.

Systeemtabellen

Controleer automatische time-to-live-gebeurtenissen met de systeemtabel voor voorspellende optimalisatie. Voorspellende optimalisatie wordt uitgevoerd DELETE om verlopen rijen te verwijderen, VACUUM om ze uit de opslag te verwijderen en optioneel PURGE voor tabellen met verwijderingsvectoren die zijn ingeschakeld om nieuwe bestanden zonder verwijderde rijen te maken.

Voer de volgende query uit om automatische time-to-live-bewerkingen in alle tabellen in de afgelopen 7 dagen te bekijken:

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;

Een waarschuwing instellen voor automatische time-to-live-fouten

Als u meldingen wilt ontvangen wanneer automatische time-to-live-bewerkingen mislukken, maakt u een Databricks SQL-waarschuwing met een query die controleert op mislukte bewerkingen in de tabel met voorspellend optimalisatiesysteem. Zie de Databricks SQL-waarschuwing voor instructies over het maken van waarschuwingen en documentatie voor systeemtabellen voor queryvoorbeelden.

Automatische time-to-live-kosten schatten

Gebruik de volgende query om te zien hoeveel DBU's in de afgelopen 30 dagen zijn verbruikt door automatische time-to-live-bewerkingen:

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;

Bewerkingen voor een specifieke tabel controleren

Gebruik DESCRIBE HISTORY dit om recente bewerkingen uit te voeren in een specifieke tabel:

DESCRIBE HISTORY table_name;

Limitations

De volgende beperkingen gelden voor automatische levensduur:

• Automatische levensduur wordt niet ondersteund voor gematerialiseerde weergaven.
• ALTER TABLE en ALTER STREAMING TABLE-syntaxis worden niet ondersteund voor het wijzigen van de automatische time-to-live van streamingtabellen. Als u een beleid voor automatische time-to-live wilt toevoegen aan of wijzigen in een bestaande streamingtabel, werkt u de auto_ttl parameter in de pijplijncode bij en publiceert u de pijplijn opnieuw.
• Het wijzigen van kolomnamen wordt niet ondersteund voor tijdkolommen die zijn gedefinieerd in een automatisch time-to-live-beleid. Als kolomtoewijzing is ingeschakeld, is deze beperking nog steeds van toepassing. Zie Kolommen hernoemen en verwijderen met kolomtoewijzing van Delta Lake.
• In zeldzame gevallen kunnen automatische time-to-live-bewerkingen transactieconflicten veroorzaken. Als u het risico op transactieconflicten wilt verminderen, gebruikt u liquid clustering, waarmee conflicten door concurrency op rijniveau worden verminderd. Zie Liquid Clustering gebruiken voor tabellen.

• Als serverloze compute geen toegang heeft tot ADLS vanwege een privékoppeling, kunnen automatische time-to-live-bewerkingen mislukken. Foutbericht van Private Link weergeven