Wiki Delta Lake

Time travel e histórico

Cada commit é uma versão. Dá para ler a tabela como ela estava, comparar versões e restaurar, enquanto os arquivos antigos existirem.

Como o log guarda cada commit, a tabela tem versões numeradas a partir de 0. Ler uma versão antiga é reaplicar o log só até ela.

Databricks SQLDatabricks SQL / Delta: roda num workspace, não aqui.

DESCRIBE HISTORY silver.pedidos;

SELECT COUNT(*) FROM silver.pedidos VERSION AS OF 12;
SELECT COUNT(*) FROM silver.pedidos TIMESTAMP AS OF '2024-06-01 00:00:00';

-- o que entrou entre duas versões
SELECT * FROM silver.pedidos VERSION AS OF 13
EXCEPT
SELECT * FROM silver.pedidos VERSION AS OF 12;

-- desfazer um carregamento ruim
RESTORE TABLE silver.pedidos TO VERSION AS OF 12;

PySparkPrecisa de um cluster Spark: não roda aqui.

v12 = spark.read.option("versionAsOf", 12).table("silver.pedidos")

Para que serve

Auditoria e depuração: "o número mudou desde ontem; o que entrou?".
Reprodutibilidade: treinar ou recalcular sobre a versão exata usada antes.
Recuperação: RESTORE volta a tabela para uma versão (o próprio RESTORE vira um commit novo, e dá para desfazê-lo).

O limite: VACUUM

Time travel precisa dos arquivos de dados antigos. O VACUUM apaga os arquivos que não fazem parte da versão atual e são mais velhos que a retenção (padrão de 7 dias, delta.deletedFileRetentionDuration). Depois dele, as versões que dependiam desses arquivos não podem mais ser lidas. O histórico do log em si é guardado por delta.logRetentionDuration (padrão de 30 dias).

Time travel não é backup: apagar a tabela ou o armazenamento leva junto o histórico.
DESCRIBE HISTORY mostra quem fez cada operação, quando e quantas linhas mudou (operationMetrics).

Fontes

Conhecimento compartilhado pela Genesis Innovation.

AnteriorDelta Lake: transações ACID sobre arquivos PróximoMERGE (upsert)