As zonas de um Data Lake

Em uma frase

Zonear um Data Lake é dividir o armazenamento em camadas com contrato, retenção, dono e permissão próprios, para que quem lê saiba exatamente em que pode confiar.

O problema: o pântano de dados

Object storage é barato e aceita qualquer coisa. Essas duas virtudes, juntas e sem disciplina, produzem o pântano de dados: milhares de arquivos que ninguém sabe de onde vieram, quem mantém, se estão corretos ou se podem ser apagados. O custo de armazenamento continua chegando todo mês; o valor não.

O sintoma clássico no banco é a reunião em que duas áreas trazem números diferentes para a mesma pergunta, e a discussão vira sobre qual planilha está certa em vez de sobre a decisão.

As quatro zonas

O erro comum é tratar isso como quatro pastas. Uma zona só existe quando tem contrato de schema, política de retenção, política de acesso, dono e regra de qualidade na entrada. Sem isso, você tem um diretório com nome bonito.

O mapeamento para a arquitetura medalhão

Os dois vocabulários descrevem o mesmo escalonamento de confiança. Traduzir um no outro em voz alta é a parte que a banca costuma cobrar quando troca de termo no meio da pergunta.

A diferença de ênfase é real e vale citar: o vocabulário de zonas nasceu falando de governança (retenção, acesso, dono), enquanto o medalhão nasceu falando de qualidade progressiva em tabelas de um lakehouse. Na prática você implementa os dois ao mesmo tempo, com Delta Lake por cima do S3.

Retenção: o custo e o risco andam juntos

Retenção não é só conta de armazenamento. Guardar dado pessoal além da finalidade é exposição de LGPD, não precaução. E apagar cedo demais quebra a capacidade de reprocessar e pode violar prazo regulatório.

1. 1Descubra o prazo regulatório do dado antes de definir a política, porque ele é o piso.
2. 2Defina expurgo automático em cada zona; política que depende de alguém lembrar não existe.
3. 3Use classe de armazenamento fria na raw antiga em vez de apagar, quando o prazo ainda corre.
4. 4Registre a finalidade de cada conjunto: é ela que justifica a existência do dado pessoal.

Controle de acesso: a raw é a mais fechada

A intuição de muita gente é o contrário, porque a raw "não tem nada de pronto". É justo o oposto: a raw concentra dado pessoal sem mascaramento nenhum, exatamente como a origem enviou. O mascaramento e a tokenização— Substituição do valor sensível por um substituto sem significado, reversível apenas por quem tem acesso ao cofre de tokens. entram na porta da trusted, que é onde ciência de dados trabalha.

Quanto mais a jusante, mais aberta a camada e menos sensível o conteúdo. Se um analista precisa do dado da raw para fechar um número, o problema quase sempre é de qualidade na trusted, e é lá que ele deve ser resolvido.