Data Lake

Data warehouses resolvem bem um problema específico: análise estruturada de dados que chegam de fontes conhecidas em formato previsível. O ERP tem tabela de pedidos com schema fixo; o CRM tem registro de clientes com campos definidos. Define-se o schema antes de carregar, transforma-se no ETL, e os dados chegam ao warehouse prontos para análise.

Esse modelo tem um limite: o que fazer com dados que não cabem nesse paradigma? Logs de servidor com formato semi-estruturado. Imagens de produtos. Gravações de calls de atendimento. Textos de avaliações de clientes. Posts de redes sociais. Dados de sensores com frequência e formato variáveis. Definir schema antes de saber como os dados vão ser usados — e forçar a transformação antes do armazenamento — descarta informação potencialmente valiosa e atrasa a disponibilidade dos dados para análise exploratória.

Data Lake é um repositório centralizado que armazena dados em qualquer formato e qualquer escala — estruturados, semi-estruturados e não estruturados — em seu estado bruto, sem transformação ou schema predefinido. A premissa: armazene tudo agora, processe e estruture quando souber para quê. O custo de armazenamento é baixo o suficiente para que essa estratégia seja economicamente viável.

A ideia é atraente: centralizar todos os dados da organização, disponíveis para qualquer análise futura, sem o gargalo de definir schema antecipadamente. Na prática, sem governança deliberada, o data lake rapidamente se torna um data swamp — repositório de dados que ninguém sabe o que tem, não consegue encontrar o que procura, não confia na qualidade do que encontra.

Os problemas típicos sem governança:

• Arquivos chegam sem metadata de contexto (quem gerou? quando? de qual sistema?)
• Múltiplas versões do mesmo dado com nomes diferentes e sem versionamento
• Dados pessoais misturados com dados não sensíveis sem controle de acesso
• Ninguém sabe quais tabelas estão corretas — há quatro versões da "tabela de clientes"
• Time de analytics passa mais tempo encontrando e validando dados do que analisando

O data swamp não é falha de tecnologia — é falha de governança e processo. A tecnologia não resolve o problema de disciplina organizacional.

Camada de armazenamento: a fundação. AWS S3, Google Cloud Storage, Azure Data Lake Storage Gen2 — armazenamento de objetos distribuído com custo por GB muito menor que armazenamento de bloco ou banco de dados. Praticamente ilimitado, alta durabilidade (11 noves de durabilidade no S3), performance adequada para processamento em lote.

Formatos de arquivo: a escolha de formato afeta performance de leitura significativamente.

• Parquet: colunar, comprimido, altamente eficiente para análise. O padrão de facto para dados analíticos em data lakes.
• ORC: similar ao Parquet, mais eficiente em algumas workloads Hive.
• Avro: orientado a linha, eficiente para escrita e evolução de schema. Comum em streaming com Kafka.
• JSON/CSV: flexíveis mas ineficientes para análise em grande escala — sem compressão colunar, sem schema embutido.
• Delta Lake / Iceberg / Hudi: formatos de tabela que adicionam transações ACID e versionamento sobre Parquet — a evolução para lakehouse.

Camadas lógicas:

• Raw/Bronze: dados brutos como chegaram da origem. Imutável — arquivo histórico fiel.
• Curated/Silver: dados limpos, validados, padronizados. Schema consistente, deduplicados.
• Aggregated/Gold: dados modelados para consumo analítico. Data marts, tabelas prontas para BI e ML.

Essa arquitetura em camadas (chamada de Medallion Architecture pela Databricks) estrutura o data lake em progressão de qualidade — evita que dados brutos sejam consumidos diretamente por ferramentas de BI sem tratamento.

A distinção frequentemente levantada como "data lake vs data warehouse" é falsa dicotomia. As duas tecnologias têm propósitos diferentes e complementares.

Data Warehouse: dados estruturados e transformados, prontos para análise de BI. Performance de query otimizada. Schema definido e confiável. Custo de storage maior. Ideal para análises repetitivas e dashboards operacionais.

Data Lake: dados brutos de qualquer tipo, disponíveis para exploração, ML e processamento ad hoc. Schema flexível. Storage barato. Ideal para exploração exploratória, treinamento de modelos de ML em grandes volumes, dados não estruturados.

A maioria das organizações maduras opera os dois em paralelo: o data lake como repositório de armazenamento barato e flexível, o data warehouse como camada analítica curada para consumo de BI. O fluxo típico: sistemas operacionais → data lake (raw) → transformações (dbt, Spark) → data warehouse → BI.

A evolução mais recente é o lakehouse: arquitetura que combina a flexibilidade e custo do data lake com as garantias de confiabilidade e performance analítica do data warehouse.

Formatos de tabela como Delta Lake (Databricks), Apache Iceberg (Netflix, adotado por AWS, Apple, Netflix) e Apache Hudi (Uber) adicionam sobre o armazenamento de objetos:

• Transações ACID: escritas atômicas, sem dados corrompidos em falhas parciais
• Versionamento e time travel: capacidade de consultar o estado dos dados em qualquer momento do passado
• Upserts e deletes: capacidade de atualizar registros específicos — essencial para conformidade com LGPD (direito ao esquecimento)
• Schema enforcement e evolution: validação de schema na escrita, evolução controlada
• Performance de query: otimizações como Z-ordering, compaction, bloom filters

O lakehouse está se tornando o padrão de referência para novas arquiteturas de dados, substituindo a arquitetura separada de lake + warehouse em muitas organizações.

Data lakes concentram dados de múltiplos sistemas — incluindo dados pessoais sujeitos à LGPD. Sem controles de acesso granulares, qualquer pessoa com acesso ao lake tem acesso a tudo.

Controle de acesso: IAM policies por bucket, pasta e arquivo. Colunas sensíveis mascaradas para usuários sem permissão. Ferramentas como AWS Lake Formation e Unity Catalog (Databricks) gerenciam permissões no nível de tabela e coluna com política centralizada.

Catalog e descoberta: sem catalog, ninguém sabe o que existe no lake. AWS Glue Data Catalog, Apache Atlas, DataHub, Alation — indexam tabelas, schemas, linhagem e metadata de negócio. Fundamental para que analistas consigam encontrar e confiar nos dados sem depender de quem os gerou.

Data lineage: rastrear de onde cada dado veio e como foi transformado. Auditoria, debugging e conformidade regulatória dependem disso.

O data lake resolve o problema de armazenamento barato e flexível de grandes volumes de dados heterogêneos — mas não resolve o problema de governança, que é organizacional. Organizações que implementam data lake sem investir em catalog, lineage, controle de acesso e processos de curadoria quase invariavelmente acabam com um data swamp caro.

Para a maioria das PMEs, o data warehouse é o investimento certo antes do data lake. O caso de uso do data lake — exploração de dados não estruturados em grande volume, treinamento de modelos de ML, dados de streaming — raramente é o problema inicial de uma empresa que está construindo capacidade analítica. O problema inicial é ter dados confiáveis e acessíveis de fontes estruturadas. Isso o warehouse resolve melhor.

Quando o data lake faz sentido: há volume real de dados não estruturados (logs, imagens, áudio, texto) que precisam ser armazenados e eventualmente processados; há necessidade de armazenar histórico bruto de sistemas antes de definir como serão usados; há equipe técnica para gerenciar a complexidade de governança. Nesses casos, a arquitetura lakehouse moderna (S3/GCS + Delta Lake/Iceberg + Spark ou query engines como Athena/DuckDB) é a abordagem recomendada.