Automatisk radering av rader med automatisk livslängd

Automatisk time-to-live (Auto-TTL) tar automatiskt bort rader från hanterade Unity Catalog-tabeller efter en konfigurerbar tidsperiod baserat på värdet i en tidsstämpelkolumn. Du definierar en förfalloperiod i dagar och anger en tidsstämpelkolumn för jämförelse. Databricks kör DELETE, PURGEoch VACUUM åtgärder i bakgrunden för att ta bort utgångna rader och rensa dem från lagring.

Följande är två exempel på hur du använder automatisk time-to-live:

• Du kanske vill ta bort data som är äldre än 1 år för att hålla lagringskostnaderna låga. Låt rader upphöra att gälla 1 år efter att de skapats genom att ange en förfalloperiod på 365 dagar för en created_at tidsstämpelkolumn.
• Du kanske vill ta bort data som har markerats för borttagning av en annan affärsprocess. Låt rader upphöra att gälla 20 dagar efter att en begäran om borttagning har bearbetats genom att ange en utgångsperiod på 20 dagar för en anpassad tidsstämpelkolumn av typen del_request_approved.

Automatisk livslängd är tillgänglig för Unity Catalog-hanterade Delta Lake-tabeller, Apache Iceberg-tabeller och streamingtabeller med Lakeflow-pipelines.

Requirements

• Du måste aktivera förutsägelseoptimering. Se Förutsägande optimering för hanterade Unity Catalog-tabeller.
  • Om du inaktiverar förutsägande optimering i en tabell med automatisk time-to-live-aktiverad förhindras automatisk time-to-live från att köras.
• Du måste ha MODIFY behörighet för en tabell för att kunna ange eller ta bort en automatisk time to live-princip. Se Grundläggande tabellbehörigheter.
• Databricks Runtime 17.3 och senare.
  • Databricks Runtime 17.2 och tidigare kan läsa och skriva till tabeller med automatisk livslängd.

Aktivera automatisk livslängd

Slå på automatisk livslängd på olika sätt beroende på källtabellen:

Delta Lake- och Apache Iceberg-hanterade tabeller

Om du vill ange en automatisk time-to-live-princip i en ny tabell anger du ett icke-negativt heltal för <expiration_days> och en kolumn med typen DATE, TIMESTAMPeller TIMESTAMP_NTZ för <time_column_name>:

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

Så här anger du en policy för automatisk livslängd för en befintlig tabell:

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

Om du till exempel vill ta bort rader 30 dagar efter tidsstämpeln created_at :

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

Strömningstabeller med Lakeflow-pipeliner

Ange två värden om du vill ange en automatisk time-to-live-princip för en ny direktuppspelningstabell i en pipeline. Ange ett icke-negativt heltal för <expiration_days> och en kolumn av typen DATE, TIMESTAMPeller 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)

Det går inte att ändra en streamingtabell så att den använder automatisk livslängd med SQL. Om du vill ändra automatisk time-to-live i en befintlig direktuppspelningstabell uppdaterar du pipelinekoden och publicerar om den.

Strömma läsningar från tabeller med automatisk time-to-live

Om du använder Structured Streaming, Lakeflow-pipelines eller strömmande tabeller för att läsa från en tabell med auto time-to-live aktiverat, anger du skipChangeCommits för den strömmande läsningen. Automatiska time to live-borttagningsåtgärder visas när data ändras. Utan den här inställningen misslyckas strömningsläsningen när automatisk time-to-live tar bort rader.

Se följande exempel:

Strukturerad direktuppspelning

# 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")

Strömmande tabeller

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

Kontrollera att automatisk time-to-live är aktiverat

Använd DESCRIBE TABLE EXTENDED för att bekräfta att automatisk time-to-live har konfigurerats. Om egenskaperna autottl.expireInDays och autottl.timestampColumn anges, aktiveras automatisk livslängd.

De automatiska time-to-live-inställningarna visas på raden Tabellegenskaper :

DESCRIBE TABLE EXTENDED table_name;

Du kan också använda SHOW TBLPROPERTIES för att se de automatiska time-to-live-egenskaperna:

SHOW TBLPROPERTIES table_name;

Stäng av automatisk livslängd

Så här tar du bort en automatisk time-to-live-princip från en hanterad Delta Lake- eller Apache Iceberg-tabell:

ALTER TABLE table_name DROP ROW DELETION;

Om du vill ta bort en automatisk time-to-live-princip i en direktuppspelningstabell anger du auto_ttl till None i pipelinekoden och publicerar om:

from pyspark import pipelines as dp

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

Datalivscykel

Automatisk TTL kan hjälpa till att automatisera hanteringen av datalivscykeln för tabeller med tidsbaserade krav på lagringstid.

Automatisk time-to-live har en datalivscykel i flera steg. När en rad har löpt ut kör prediktiv optimering DELETE- och VACUUM-kommandon asynkront. Om borttagningsvektorer är aktiverade i tabellen körs PURGE också prediktiv optimering före VACUUM för att skriva om datafiler och ta bort rader som har tagits bort. Se Rensa endast metadata för att tvinga omskrivning av data.

Exakt borttagningstid är inte garanterad och kan variera beroende på systembelastning. Information om hur du verifierar att data har tagits bort finns i Systemtabeller.

För att konfigurera automatisk Time to Live (TTL) korrekt enligt dina krav för datalagring går du igenom stegen nedan:

Efter permanent borttagning via VACUUMär borttagna rader inte längre tillgängliga via tidsresor. Se Ta bort oanvända datafiler med åtgärden "vacuum".

Här är en visuell tidslinje för datalivscykeln, där en rad med ett tidskolumnvärde t flyttas genom fyra faser innan filerna tas bort fysiskt av VACUUM:

Beräkna konfigurationsvärden för en målperiod

Om du vill konfigurera förutsägelseoptimering för att ta bort rader från lagring inom ett målantal dagar subtraherar du den maximala bufferttiden (6 dagar) och den borttagna kvarhållningstiden från målet:

target_expiration_days = target_days - 6 - deletedFileRetentionDuration

Om du till exempel vill ta bort rader inom 30 dagar med standardperioden på 7 dagar anger du expiration_days till 17 DAYS:

target_expiration_days = 30 - 6 - 7 = 17 days

Om du vill ta bort rader inom 90 dagar med en kvarhållningsperiod på 30 dagar anger du expiration_days till 54 DAYS:

target_expiration_days = 90 - 6 - 30 = 54 days

Övervaka automatisk livslängd

Med systemtabeller kan du verifiera automatiska time-to-live-händelser, övervaka kostnader och ange aviseringar för fel.

Systemtabeller

Verifiera automatiska time-to-live-händelser med systemtabellen för prediktiv optimering. Förutsägande optimering körs DELETE för att ta bort utgångna rader, VACUUM ta bort dem från lagring och valfritt PURGE för tabeller med borttagningsvektorer aktiverade för att skapa nya filer utan borttagna rader.

Kör följande fråga för att granska automatiska time-to-live-åtgärder i alla tabeller under de senaste 7 dagarna:

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;

Ange en avisering för automatiska time-to-live-fel

Om du vill ta emot meddelanden när automatiska time-to-live-åtgärder misslyckas skapar du en Databricks SQL-avisering med en fråga som söker efter misslyckade åtgärder i systemtabellen för förutsägande optimering. Se Databricks SQL-avisering för anvisningar om hur du skapar aviseringar och dokumentation om systemtabeller för frågeexempel.

Beräkna automatiska time-to-live-kostnader

Använd följande fråga för att se hur många DBU:er som automatiska time-to-live-åtgärder har förbrukat under de senaste 30 dagarna:

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;

Granska åtgärder i en specifik tabell

Använd DESCRIBE HISTORY för att se de senaste åtgärderna som körs i en specifik tabell:

DESCRIBE HISTORY table_name;

Limitations

Följande begränsningar gäller för automatisk time-to-live:

• Automatisk livstid stöds inte för materialiserade vyer.
• ALTER TABLE och ALTER STREAMING TABLE-syntaxen stöds inte när du ändrar automatisk TTL för strömmande tabeller. Om du vill lägga till eller ändra en automatisk time-to-live-princip i en befintlig direktuppspelningstabell uppdaterar du parametern auto_ttl i pipelinekoden och publicerar om pipelinen.
• Det går inte att byta namn på tidskolumner som definieras i en automatisk time-to-live-princip. Om kolumnmappning är aktiverat gäller fortfarande den här begränsningen. Se Byt namn på och ta bort kolumner med kolumnmappning i Delta Lake.
• I sällsynta fall kan automatiska time-to-live-åtgärder orsaka transaktionskonflikter. För att minska risken för transaktionskonflikter använder du liquid clustering, vilket minskar konflikter vid samtidighet på radnivå. Se Använda flytande klustring för tabeller.

• Om serverlös beräkning inte kan komma åt ADLS på grund av en privat länk kan automatiska time-to-live-åtgärder misslyckas. Se Felmeddelande om privat länk