Uma prova que podia ter falhado

The €100 Lakehouse — 5/12

O check de equivalência passou: fingerprint 35324916267, idêntico nos dois caminhos. Depois apaguei a baseline e corri outra vez.

A decisão: reformar um atalho da Phase-0 em que o dlt escrevia direto no Databricks. Agora o dlt acaba num prefixo S3, e o bronze é escrito por uma coisa só — Auto Loader, incremental batch, trigger=availableNow.

A prova:

→ fingerprint = sum(crc32(concat_ws('~', 18 colunas))), igual nos dois caminhos
→ 17 = 17 linhas, diff bidirecional com EXCEPT: 0 linhas
→ re-run: batches=0 — idempotência medida, não assumida

Mas fazer MERGE de 17 linhas idênticas sobre 17 idênticas dá 17 quer o landing novo funcione quer não. O meu check era tautológico até eu remover o alvo. Recusei o verde, apaguei a tabela baseline e obriguei o pipeline a reconstruí-la do zero. Mesmo fingerprint. Agora é que conta.

O custo honesto está escrito na spec: um load passa a ter DOIS pontos de commit — o write no S3 e o commit do checkpoint do stream — e todas as falhas interessantes vivem no intervalo entre eles. Daí a regra: o checkpoint e a tabela bronze fazem reset JUNTOS. Sempre. Nunca um sem o outro. Um único ato composto no código, sem caminho que faça só metade.

Uma prova de equivalência só vale se pudesse ter falhado.

Quando foi a última vez que apagaram a baseline de um teste verde só para confirmar que ele ainda conseguia falhar?

Databricks · dbt · Airflow · Terraform · AWS

P.S. Novo post tech todas as quartas-feiras.

#100EuroLakehouse #Databricks #DataEngineering