Data lake vs lakehouse vs warehouse

• Banco de dados
• Conceito de arquitetura
• Fora da AWS
• Analytics
• IA e machine learning

A conclusão a tirar do desenho é que as três camadas existem em qualquer das arquiteturas — o que muda é onde fica a fronteira do que é gerenciado. O formato de tabela é exatamente o que traz garantias de armazém para arquivos em bucket, e é ele, não a palavra, que define o lagohouse.

1. 1 · A camada crua guarda o que chegou. Sem transformação nenhuma, e com histórico. É o que permite reprocessar quando a regra de negócio muda ou quando se descobre um erro na limpeza — coisa impossível se a transformação foi destrutiva na entrada.
2. 2 · A intermediária resolve tipo e duplicata. Aqui o dado vira tabela confiável: tipos corretos, chaves reconciliadas, duplicatas removidas. É a camada que a maior parte do trabalho de ciência de dados realmente consome.
3. 3 · A camada final fala a língua do negócio. Métrica agregada, dimensão conformada, nome que o time de negócio reconhece. É a que aparece no painel — e a única que a maioria das pessoas vê.
4. 4 · O formato de tabela é o que separa lago de lagohouse. Um lago é um monte de arquivo num bucket: sem transação, uma escrita concorrente corrompe a leitura. O formato de tabela traz confirmação atômica, evolução de esquema e consulta a um instante anterior — sobre os mesmos arquivos, sem servidor de banco.
5. 5 · O catálogo é o que torna o dado achável. Sem ele, existe o arquivo mas ninguém sabe que ele existe, quem o produz nem quando foi atualizado pela última vez. Lago sem catálogo vira pântano.
6. 6 · Nem todo consumo passa pela camada final. Modelos costumam precisar de granularidade que o agregado já destruiu, e investigação de incidente quase sempre desce até o cru. Desenhar o acesso como "todo mundo consome o ouro" é o que empurra times a criar cópias paralelas por fora.