Eliminação automática de linhas com tempo de vida automática

O auto-time-to-live (Auto-TTL) apaga automaticamente as linhas das tabelas geridas pelo Catálogo Unity após um período de tempo configurável com base no valor numa coluna de carimbo temporal. Defines um período de expiração em dias e especificas uma coluna de carimbo temporal para comparação. O Databricks executa DELETE, PURGE, e VACUUM operações em segundo plano para remover linhas expiradas e limpá-las do armazenamento.

Seguem-se dois exemplos de como usar o auto-time-to-live:

• Pode querer remover dados com mais de 1 ano para manter os custos de armazenamento baixos. Faça com que as linhas expirem 1 ano após a criação, especificando um período de expiração de 365 dias numa coluna created_at de carimbo de data/hora.
• Pode querer remover dados que foram marcados para eliminação por outro processo de negócio. Faça expirar as linhas 20 dias depois de um pedido de eliminação ser processado, especificando um período de expiração de 20 dias numa coluna personalizada del_request_approved de carimbo de data/hora.

O tempo de vida automático está disponível para tabelas Delta Lake geridas pelo Unity Catalog, tabelas Apache Iceberg e tabelas de transmissão em fluxo com pipelines do Lakeflow.

Requirements

• Tens de ativar a otimização preditiva. Consulte Otimização preditiva para tabelas gerenciadas do Unity Catalog.
  • Desativar a otimização preditiva numa tabela com o TTL automático ativado impede que o TTL automático entre em execução.
• Tem de ter permissões MODIFY sobre uma tabela para definir ou apagar uma política automática de tempo de vida. Veja Permissões básicas de tabelas.
• Databricks Runtime 17.3 e versões superiores.
  • O Databricks Runtime 17.2 e anteriores podem ler e escrever em tabelas com tempo de vida automático.

Ativar o modo automático de tempo para viver

Ativa o tempo para viver automaticamente de forma diferente consoante a tabela de origem:

Tabelas geridas do Delta Lake e da Apache Iceberg

Para definir uma política de tempo para vida automática numa nova tabela, especifique um inteiro não negativo para <expiration_days> e uma coluna com um tipo de DATE, TIMESTAMP, ou TIMESTAMP_NTZ para <time_column_name>:

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

Para definir uma política automática de tempo para viver numa tabela existente:

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

Por exemplo, para eliminar as linhas 30 dias após a respetiva created_at data/hora:

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

Tabelas de fluxo em pipelines Lakeflow

Para definir uma política automática de tempo de vida para uma nova tabela de streaming num pipeline, especifique dois valores. Forneça um inteiro não negativo para <expiration_days> e uma coluna do tipo DATE, TIMESTAMP, ou TIMESTAMP_NTZ para <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)

Não é suportado alterar uma tabela de streaming para usar o auto-time-to-live usando SQL. Para modificar o tempo de vida automático numa tabela de fluxo existente, atualize o código do pipeline e republique.

Leituras em streaming a partir de tabelas com tempo automático de transmissão ao vivo

Se utilizar o Structured Streaming, pipelines do Lakeflow ou tabelas de streaming para ler de uma tabela com o time-to-live automático ativado, defina skipChangeCommits na leitura de streaming. As operações automáticas de eliminação em tempo de vida aparecem à medida que os dados mudam. Sem esta configuração, a leitura em streaming falha quando o TTL automático elimina as linhas.

Veja os seguintes exemplos:

Transmissão em Fluxo Estruturada

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

Condutas de fluxo de lago

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

Tabelas de streaming

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

Verifique se o tempo de vida automático está ativado

Usa DESCRIBE TABLE EXTENDED para confirmar que o tempo de vida automática está configurado. Se as propriedades autottl.expireInDays e autottl.timestampColumn estiverem definidas, o tempo de vida automático fica ativado.

As definições automáticas de tempo para viver aparecem na linha Propriedades da Tabela :

DESCRIBE TABLE EXTENDED table_name;

Alternativamente, use SHOW TBLPROPERTIES para ver as propriedades de tempo para viver automaticamente:

SHOW TBLPROPERTIES table_name;

Desligue o tempo de vida automática

Para eliminar uma política automática de time-to-live de uma tabela Delta Lake ou Apache Iceberg gerida:

ALTER TABLE table_name DROP ROW DELETION;

Para eliminar uma política automática de tempo de vida numa tabela de streaming, defina auto_ttl como None no código do pipeline e republique:

from pyspark import pipelines as dp

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

Ciclo de vida dos dados

O TTL automático pode ajudar a automatizar a gestão do ciclo de vida dos dados em tabelas com requisitos de retenção temporal.

O auto-time-to-live tem um ciclo de vida de dados em múltiplas fases. Após a expiração de uma linha, a otimização preditiva executa os comandos DELETE e VACUUM de forma assíncrona. Se os vetores de eliminação estiverem ativados na tabela, a otimização preditiva também é executada PURGE antes VACUUM para reescrever ficheiros de dados e remover linhas eliminadas. Consulte Purgar apenas exclusões de metadados para forçar a reescrita de dados.

O momento exato da eliminação não é garantido e pode variar consoante a carga do sistema. Para informações sobre como verificar que os dados foram eliminados, consulte as tabelas do sistema.

Para configurar corretamente o auto-time-to-live para os seus requisitos de retenção de dados, reveja as etapas abaixo:

Após a eliminação definitiva através de VACUUM, as linhas eliminadas deixam de estar acessíveis através da funcionalidade de viagem no tempo. Consulte Remover arquivos de dados não utilizados com vácuo.

Aqui está uma cronologia visual do ciclo de vida dos dados, em que uma linha com um valor da coluna temporal de t passa por quatro fases antes de os seus ficheiros serem fisicamente removidos por VACUUM:

Calcular valores de configuração para um período de expiração alvo

Para configurar uma otimização preditiva para remover linhas do armazenamento dentro de um número alvo de dias, subtraia o tempo máximo de buffer (6 dias) e a duração da retenção de ficheiros eliminados do seu alvo:

target_expiration_days = target_days - 6 - deletedFileRetentionDuration

Por exemplo, para remover linhas dentro de 30 dias com o período padrão de retenção de 7 dias, defina expiration_days para 17 DAYS:

target_expiration_days = 30 - 6 - 7 = 17 days

Para remover linhas dentro de 90 dias com um período de retenção de 30 dias, defina expiration_days para 54 DAYS:

target_expiration_days = 90 - 6 - 30 = 54 days

Monitorizar o time-to-live automático

Com as tabelas do sistema, pode verificar eventos automáticos de time-to-live, monitorizar custos e definir alertas para falhas.

Tabelas do sistema

Verifique os eventos automáticos de tempo de vida com a tabela do sistema de otimização preditiva. A otimização preditiva é executada DELETE para remover linhas expiradas, VACUUM eliminá-las do armazenamento e, opcionalmente PURGE , para tabelas com vetores de eliminação ativados para criar novos ficheiros sem linhas eliminadas.

Execute a seguinte consulta para analisar as operações automáticas de TTL em todas as tabelas nos últimos 7 dias:

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;

Defina um alerta para falhas do TTL automático

Para receber notificações quando as operações de TTL automático falharem, crie um alerta SQL do Databricks com uma consulta que verifique operações com falha na tabela de sistema da otimização preditiva. Consulte o alerta SQL do Databricks para instruções sobre como criar alertas e a documentação de tabelas do sistema para exemplos de consultas.

Estimar os custos do tempo de vida automóvel

Utilize a consulta seguinte para ver quantas DBUs foram consumidas por operações automáticas de tempo de vida nos últimos 30 dias:

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;

Rever operações numa tabela específica

Use DESCRIBE HISTORY para ver operações recentes executadas numa tabela específica:

DESCRIBE HISTORY table_name;

Limitations

As seguintes limitações aplicam-se ao tempo de vida automático:

• O tempo de vida (TTL) automático não é suportado em vistas materializadas.
• A sintaxe ALTER TABLE e ALTER STREAMING TABLE não é suportada para modificar o tempo de vida automático em tabelas de fluxo. Para adicionar ou alterar uma política automática de tempo de vida numa tabela de streaming existente, atualize o parâmetro auto_ttl no código do pipeline e republique o pipeline.
• Não é suportado mudar o nome de colunas temporais definidas numa política automática de time-to-live. Se o mapeamento de colunas estiver ativado, esta limitação ainda se aplica. ** Consulte Renomear e remover colunas utilizando o mapeamento de colunas no Delta Lake.
• Em casos raros, as operações automáticas de TTL podem causar conflitos de transações. Para reduzir o risco de conflitos de transação, utilize a clusterização líquida, o que reduz os conflitos associados à concorrência ao nível da linha. Veja Utilizar clustering líquido para tabelas.

• Se a capacidade de computação sem servidor não conseguir aceder ao ADLS devido à ligação privada, as operações automáticas de time-to-live poderão falhar. Ver mensagem de erro do link privado