Nota: Este é o segundo post da série de estudos sobre o livro Fundamentos da Qualidade de Dados, de Barr Moses, Lior Gavish e Molly Vorwerck (original em inglês pela O’Reilly; esta leitura é da edição brasileira da Alta Books). No post anterior vimos os componentes de um sistema confiável e a diferença entre dados operacionais e analíticos — além de um primeiro panorama de data warehouses e data lakes. Agora vou continuar a leitura do Capítulo 2, aprofundando o data lake, entrando nos data lakehouses e entendendo como esses dois mundos conversam entre si.

Retomando de onde paramos

No primeiro post, ficou claro que o data warehouse prioriza ordem e confiabilidade, enquanto o data lake prioriza flexibilidade e volume. Mas essa separação, vista de longe, esconde um detalhe importante: por trás de um data lake “que aceita tudo” existe uma série de decisões de arquitetura e, principalmente, desafios de qualidade que só aparecem depois.

Neste post, o foco é entender como o data lake realmente funciona por dentro, por que ele pode se tornar um problema e como o mercado vem respondendo a isso com o lakehouse.

O que é, de fato, um data lake

O termo não é novo. Ele foi cunhado por James Dixon, cofundador e ex-CTO da Pentaho, que descreveu o data lake como um repositório onde os dados chegam no seu formato bruto, sem a curadoria prévia exigida pelos warehouses tradicionais.

A ideia central é simples: em vez de decidir o esquema antes de armazenar (como no warehouse), você guarda o dado como ele veio e decide como interpretá-lo na hora de usar. Isso dá muita liberdade — e é justamente por isso que o data lake se tornou tão popular entre equipes que precisam de customização nos produtos de dados.

Costuma ser o ambiente preferido de quem quer mais liberdade para explorar:

  • Cientistas de dados, que precisam de uma variedade maior de dados para experimentar modelos.
  • Engenheiros de machine learning, que trabalham com features e formatos que mudam com frequência.
  • Times de dados em geral, que querem um único lugar para reunir fontes heterogêneas.

Características comuns de um data lake

Ainda que cada implementação seja única, data lakes bem construídos compartilham um conjunto de características:

  • Armazenamento e processamento desacoplados: o dado pode ficar guardado num lugar barato (ex.: object storage) e ser processado por outro serviço, de forma independente. Isso permite escalar cada parte conforme a necessidade.
  • Suporte a processamento distribuído: é comum que os motores de processamento rodem em cluster, dividindo o trabalho entre vários nós.
  • Customização e interoperabilidade: as equipes conseguem adaptar o ambiente ao seu caso de uso e integrá-lo com diferentes ferramentas.
  • Baseado majoritariamente em tecnologias open source: a flexibilidade do lake vem, em grande parte, de um ecossistema aberto.
  • Capacidade de lidar com dados não estruturados ou fracamente estruturados: texto, logs e imagens convivem com formatos semiestruturados e estruturados (JSON, Parquet) — tudo cabe.
  • Suporte a modelos NoSQL: a modelagem não precisa seguir o formato rígido de tabelas relacionais.

Os desafios da equipe de dados

Aqui está o ponto em que “aceitar tudo” cobra o preço. O mesmo data lake que dá liberdade também concentra boa parte dos problemas de qualidade. Três deles aparecem com frequência:

1. Integridade dos dados

Quanto mais fontes entram no lake, maior o risco de dados incompletos, duplicados ou inconsistentes. Como não há curadoria na entrada, é a equipe que precisa garantir que aquele dado bruto seja confiável — e isso vira um trabalho contínuo, não um passo único.

2. Swampification

Esse é o apelido dado ao processo em que um data lake, aos poucos, deixa de ser um lago organizado e se transforma num pântano (swamp): dados demais, contexto de menos. Sem catálogo, sem documentação e sem dono claro, ninguém mais sabe o que é confiável ou o que pode ser descartado. É o famoso “data lake virou data swamp”.

3. Mais endpoints

Multiplicar fontes significa multiplicar endpoints — as portas de entrada pelas quais os dados chegam. Cada endpoint novo é mais um lugar que pode falhar, mudar de formato ou travar no meio do caminho. Quanto mais endpoints, maior a superfície de risco para a qualidade.

Em uma frase: o data lake resolve o problema de onde guardar o dado, mas cria um problema novo — o de confiar no que está guardado.

Data Lakehouse: o melhor dos dois mundos

Se o warehouse é confiável, mas rígido, e o lake é flexível, mas bagunçado, o data lakehouse surge para juntar o que cada um tem de melhor: a flexibilidade e o baixo custo do lake com a confiabilidade e o desempenho do warehouse — tudo sobre a mesma base de armazenamento.

Três pilares sustentam essa proposta:

  • SQL de alta performance: motores otimizados consultam os dados diretamente no lake com a velocidade que se espera de um warehouse.
  • Esquema (schema): o lakehouse reintroduz a ideia de esquema e governança, trazendo ordem para os dados brutos sem perder a flexibilidade.
  • ACID (atomicidade, consistência, isolamento e durabilidade): transações confiáveis passam a valer também no lake, evitando leituras de dados “pela metade” ou corrompidos.

Na prática, o lakehouse permite que a mesma equipe explore dados novos com liberdade e entregue tabelas curadas e confiáveis para BI e decisões — sem manter dois sistemas paralelos com cópias divergentes.

Sincronizando dados entre data warehouses e data lakes

Mesmo com o avanço dos lakehouses, muitas empresas ainda mantêm os dois ambientes: o data lake como landing zone (a origem imutável, onde tudo chega) e o data warehouse com as versões limpas e modeladas para análise. O elo entre eles é uma camada de integração de dados.

É ela que cuida de mover e transformar os dados do lake para o warehouse (e, às vezes, no sentido inverso). O fluxo típico é:

flowchart TB
    A[Fontes: bancos, APIs, logs, arquivos] --> B[(Data Lake - dados brutos)]
    B --> C[Camada de integração de dados]
    C -->|Limpeza, modelagem, validação| D[(Data Warehouse - dados curados)]
    D --> E[BI, dashboards, decisões]
    B --> F[Cientistas e engenheiros de ML]

Guardar a fonte bruta e sincronizar apenas versões curadas traz duas vantagens claras: você nunca perde o dado original (dá para reprocessar se algo der errado) e o warehouse continua entregando só o que já foi validado.

Um exemplo simples: imagine que uma tabela de vendas chega ao lake em JSON, sem garantia de formato. A camada de integração valida, remove duplicatas e grava no warehouse já modelada — se descobrirmos um erro na regra de negócio, basta reprocessar a partir do lake.

 1-- Exemplo em Snowflake. A coluna _ingested_at é um metadado de auditoria
 2-- adicionado na ingestão (não é campo de negócio).
 3-- Idempotência depende de: deduplicar a origem + chave única + MERGE.
 4MERGE INTO dw.fato_vendas AS d
 5USING (
 6    SELECT
 7        order_id,
 8        CAST(valor AS DECIMAL(12,2)) AS valor,
 9        CAST(data_pedido AS TIMESTAMP) AS data_pedido
10    FROM lake.vendas_raw
11    WHERE order_id IS NOT NULL  -- descarta registros inválidos
12    QUALIFY ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY _ingested_at DESC) = 1
13) AS s
14ON d.order_id = s.order_id
15WHEN MATCHED THEN UPDATE SET valor = s.valor, data_pedido = s.data_pedido
16WHEN NOT MATCHED THEN INSERT (order_id, valor, data_pedido) VALUES (s.order_id, s.valor, s.data_pedido);

O MERGE (ou upsert) é o coração da carga, mas a idempotência não vem só dele: ela só é garantida quando a origem é deduplicada (aqui, o QUALIFY ... = 1 mantém apenas o registro mais recente por order_id) e a chave de match é única. Com essas premissas, mesmo que o job rode duas vezes, o resultado no warehouse é o mesmo. Isso é qualidade de dados na prática — não basta mover o dado; é preciso garantir que ele chegue certo, uma única vez e sempre no mesmo formato.

O que fica deste capítulo

A leitura reforça uma ideia central da qualidade de dados: flexibilidade sem governança vira caos. O data lake é uma peça poderosa, mas precisa de catálogo, dono e processos para não virar um pântano. O lakehouse é a resposta natural a esse problema, e a sincronização entre lake e warehouse é o que garante que a curiosidade dos cientistas e a confiabilidade das decisões caminhem juntas.

No próximo post da série, sigo avançando pelos capítulos do livro — sempre conectando a teoria com o que a prática de um pipeline real exige.

Quer se aprofundar?

Este post é um resumo do Capítulo 2 do livro Fundamentos da Qualidade de Dados, de Barr Moses, Lior Gavish e Molly Vorwerck (original em inglês pela O’Reilly; edição brasileira da Alta Books). Se você quer entender na prática como construir pipelines de dados confiáveis e evitar o famoso data downtime, vale muito a pena ler o livro completo.

Capa do livro Fundamentos da Qualidade de Dados

Fundamentos da Qualidade de Dados

Guia prático para criar pipelines de dados confiáveis — Barr Moses, Lior Gavish e Molly Vorwerck.

Comprar na Alta Books →