Data lakes e data warehouses

1. Fundamentos e Definições Arquiteturais

A arquitetura de dados moderna frequentemente confronta o arquiteto com duas abordagens complementares: o Data Warehouse e o Data Lake. O Data Warehouse surgiu na década de 1990 com o trabalho de Bill Inmon e Ralph Kimball, estabelecendo-se como um repositório centralizado de dados estruturados, modelados para consultas analíticas. Sua estrutura típica utiliza o modelo dimensional (star schema), onde tabelas de fatos armazenam métricas mensuráveis e tabelas de dimensões contêm atributos descritivos.

-- Exemplo de star schema para vendas
CREATE TABLE fato_vendas (
    id_venda INT,
    id_cliente INT,
    id_produto INT,
    id_data INT,
    valor DECIMAL(10,2),
    quantidade INT
);

CREATE TABLE dim_cliente (
    id_cliente INT,
    nome VARCHAR(100),
    regiao VARCHAR(50)
);

CREATE TABLE dim_produto (
    id_produto INT,
    nome VARCHAR(100),
    categoria VARCHAR(50)
);

O processamento no warehouse segue o padrão ETL (Extract, Transform, Load), onde os dados são transformados antes da carga, garantindo qualidade e consistência. Já o Data Lake, popularizado por Hadoop no início dos anos 2010, adota o conceito de armazenamento bruto em formatos variados (Parquet, Avro, JSON, CSV) com schema-on-read — a estrutura é interpretada no momento da consulta.

-- Exemplo de schema-on-read com Spark SQL
CREATE TEMPORARY VIEW vendas_view
USING parquet
OPTIONS (path "s3://data-lake/raw/vendas/2024/01/");

SELECT cliente, SUM(valor) as total
FROM vendas_view
GROUP BY cliente;

As diferenças essenciais residem na governança: o warehouse oferece controle rígido sobre qualidade e linhagem, enquanto o lake prioriza flexibilidade e agilidade na ingestão de dados heterogêneos.

2. Padrões de Ingestão e Processamento

No Data Warehouse, pipelines ETL são projetados com transformações predefinidas que garantem integridade referencial e consistência dimensional. Esses pipelines executam em janelas de processamento batch, tipicamente noturnas.

-- Pipeline ETL típico
1. Extract: SELECT * FROM source_vendas WHERE data = CURRENT_DATE - 1
2. Transform: Aplicar regras de negócio, deduplicar, validar chaves
3. Load: INSERT INTO fato_vendas (SELECT ... FROM staging)

No Data Lake, o padrão ELT (Extract, Load, Transform) inverte a ordem: os dados são carregados em estado bruto e transformados sob demanda. Motores como Apache Spark permitem processamento distribuído e flexível.

-- ELT com PySpark
df = spark.read.json("s3://lake/raw/sensores/")
df_clean = df.filter(col("temperatura").isNotNull())
df_clean.write.mode("overwrite").parquet("s3://lake/curated/sensores/")

A escolha entre streaming e batch impacta diretamente a latência. Streaming (Kafka, Kinesis) entrega dados em tempo real com consistência eventual, enquanto batch garante consistência forte em intervalos definidos.

3. Modelagem de Dados e Schema Management

A modelagem dimensional no warehouse exige planejamento cuidadoso de fatos, dimensões e tabelas de agregação. Tabelas de agregação pré-computadas aceleram consultas frequentes.

-- Tabela de agregação mensal
CREATE TABLE agg_vendas_mensal (
    ano INT,
    mes INT,
    id_produto INT,
    total_vendas DECIMAL(12,2)
);

INSERT INTO agg_vendas_mensal
SELECT YEAR(data), MONTH(data), id_produto, SUM(valor)
FROM fato_vendas
GROUP BY YEAR(data), MONTH(data), id_produto;

No data lake, o schema-on-read permite evolução contínua. Catálogos como Apache Hive Metastore ou AWS Glue atuam como camada de abstração, registrando metadados e versões de esquema.

-- Versionamento de schema no Apache Hive
ALTER TABLE vendas_parquet ADD COLUMNS (desconto DECIMAL(5,2));
-- Dados antigos retornam NULL para a nova coluna

4. Camadas de Armazenamento e Organização no Data Lake

A organização em zonas de dados é fundamental para governança e performance:

  • Raw: dados brutos, imutáveis, formato original
  • Curated: dados limpos e validados, formato colunar
  • Refined: dados agregados e otimizados para consumo
  • Sandbox: área exploratória para experimentação
Estrutura de diretórios no S3:
s3://data-lake/
  raw/vendas/2024/01/01/vendas.json
  curated/vendas/ano=2024/mes=01/dia=01/vendas.parquet
  refined/dashboards/vendas_mensais.parquet

Particionamento por data e uso de formatos colunares (Parquet, ORC) com compressão (Snappy, Zstd) reduzem custos de armazenamento e aceleram consultas.

5. Arquitetura Lambda vs. Kappa

A Arquitetura Lambda combina processamento batch (warehouse) e streaming (lake) com uma camada de reconciliação para unificar resultados. Essa dualidade garante precisão histórica e baixa latência, mas aumenta a complexidade operacional.

Arquitetura Lambda:
- Batch layer: Spark processa dados históricos → tabelas agregadas
- Speed layer: Kafka Streams processa dados em tempo real → visões parciais
- Serving layer: reconciliação dos resultados

A Arquitetura Kappa simplifica ao usar processamento único via streaming, eliminando a dualidade. Todo dado é tratado como um fluxo contínuo, e o reprocessamento ocorre pela repetição do stream.

Arquitetura Kappa:
- Kafka como fonte única de verdade
- Processamento contínuo com Flink ou Kafka Streams
- Estado mantido em bancos key-value

O trade-off principal: Lambda oferece consistência temporal superior, enquanto Kappa reduz custos operacionais e complexidade.

6. Governança, Segurança e Linhagem de Dados

Controle de acesso baseado em RBAC (Role-Based Access Control) deve ser implementado em nível de arquivo e coluna. Ferramentas como Apache Ranger ou AWS Lake Formation permitem políticas granulares.

-- Política no AWS Lake Formation
{
    "Effect": "Allow",
    "Principal": {"arn": "role/analytics"},
    "Action": ["lakeformation:Select"],
    "Resource": "arn:lakeformation:database/vendas/table/fato_vendas",
    "Condition": {
        "Column": ["valor", "quantidade"],
        "Operator": "IN"
    }
}

A linhagem de dados rastreia transformações entre lake e warehouse. Ferramentas como Apache Atlas ou Marquez registram metadados de cada pipeline, permitindo auditoria e diagnóstico.

-- Metadados de linhagem
Pipeline: raw_vendas → curated_vendas → agg_vendas_mensal
Transformação: json → parquet (limpeza) → parquet (agregação)

Qualidade de dados exige validação contínua: checagem de nulidade, unicidade, intervalos e consistência referencial.

7. Trade-offs e Decisões Arquiteturais

A escolha entre tecnologias envolve análise de custos: S3 para armazenamento barato versus Redshift ou Snowflake para processamento otimizado. BigQuery oferece escalabilidade serverless, mas com custos de consulta.

Comparação de custos (exemplo mensal para 10TB):
- S3 + Athena: ~$250 armazenamento + $50 consulta
- Redshift: ~$1.500 instância + $200 armazenamento
- Snowflake: $2.000 computação + $100 armazenamento

Consistência eventual (típica em data lakes) pode causar discrepâncias em relatórios analíticos. Consistência forte (warehouse) garante precisão, mas limita escalabilidade.

Governança centralizada no warehouse reduz riscos, mas aumenta tempo de entrega. Self-service no lake acelera time-to-insight, porém exige cultura de dados madura.

8. Tendências e Evolução (Data Lakehouse)

O Data Lakehouse emerge como convergência entre as duas abordagens. Tecnologias como Delta Lake, Apache Iceberg e Apache Hudi adicionam transações ACID sobre data lakes, combinando flexibilidade com confiabilidade.

-- Transação ACID no Delta Lake
df.write.format("delta")
  .mode("overwrite")
  .option("mergeSchema", "true")
  .save("s3://lakehouse/vendas/")

-- Time travel para versões anteriores
spark.read.format("delta")
  .option("versionAsOf", 5)
  .load("s3://lakehouse/vendas/")

A integração com machine learning é facilitada por feature stores que gerenciam features reutilizáveis e pipelines de treinamento diretamente sobre o lakehouse.

-- Feature store no Databricks
CREATE FEATURE TABLE customer_features
USING delta
AS SELECT cliente_id, avg_gasto, frequencia_compras
FROM vendas_agregadas;

O lakehouse representa a evolução natural, unificando analytics, BI e machine learning em uma única plataforma, eliminando a necessidade de mover dados entre sistemas.

Referências