Um Erro de €2,3 Milhões Que Poderia Ter Sido Evitado

Uma empresa de retalho gastou €2,3 milhões a construir um data lake no AWS S3. Dezoito meses depois, os seus cientistas de dados ainda não conseguiam consultá-lo eficazmente. O lake tinha-se tornado um pântano—terabytes de ficheiros JSON com schemas inconsistentes, sem catálogo de dados, e tempos de consulta medidos em horas em vez de segundos.

O erro deles? Escolher a arquitetura antes de compreender as suas cargas de trabalho reais. Este artigo vai ajudar-te a evitar o mesmo destino.

Compreender os Quatro Paradigmas

A arquitetura de dados moderna não é sobre escolher a "melhor" opção—é sobre fazer corresponder a arquitetura às características da carga de trabalho.

Data Warehouses: Analítica Estruturada em Escala

Um data warehouse armazena dados processados e estruturados otimizados para consultas analíticas. Pensa em Snowflake, Google BigQuery ou Amazon Redshift.

Quando os warehouses se destacam:

• Os teus dados encaixam em modelos relacionais (clientes, encomendas, produtos)

• Precisas de performance de consulta sub-segundo para dashboards

• Utilizadores de negócio executam consultas SQL ad-hoc regularmente

• Governança de dados e audit trails são críticos

Exemplo real: Uma empresa de serviços financeiros com quem trabalhei processa 50 milhões de transações diariamente através do Snowflake. A equipa de BI executa 12.000 consultas por dia com tempo de resposta mediano inferior a 800 milissegundos. Custo mensal total: aproximadamente €18.000 para 2 petabytes de armazenamento e computação consistente.

O insight chave: warehouses cloud modernos escalam computação independentemente do armazenamento. Pagas pelas consultas quando as executas, não por capacidade ociosa.

Data Lakes: Armazenamento Bruto para Dados Diversos

Um data lake armazena dados brutos em formatos nativos—ficheiros Parquet, JSON, imagens, logs—sem exigir definição de schema prévia.

Quando os lakes fazem sentido:

• Estás a recolher dados antes de saber exatamente como os vais usar

• Os dados chegam em formatos diversos (sensores IoT, logs, ficheiros de media)

• Equipas de ciência de dados precisam de acesso a dados brutos e não processados

• Otimização de custos é crítica (armazenamento de objetos é 10x mais barato que armazenamento de warehouse)

O problema do pântano: Sem governança, os lakes tornam-se inutilizáveis. Já migrámos clientes de lakes que continham 40TB de dados onde ninguém sabia o que 60% deles representavam. Os dados existiam; os metadados não.

Fazer os lakes funcionar: Implementa um catálogo de dados desde o primeiro dia. AWS Glue Data Catalog, Azure Purview ou o open-source Apache Atlas devem ser inegociáveis. Cada ficheiro precisa de metadados: sistema de origem, timestamp de ingestão, versão do schema, proprietário dos dados.

Data Lakehouses: A Convergência

A Databricks cunhou "lakehouse" para descrever arquiteturas que adicionam funcionalidades tipo warehouse ao armazenamento de lake. Delta Lake, Apache Iceberg e Apache Hudi permitem transações ACID, imposição de schema e viagem no tempo em armazenamento de objetos.

O avanço técnico: Estes formatos de tabela armazenam dados como ficheiros Parquet (baratos, colunares, comprimidos) enquanto mantêm logs de transação que permitem comportamento tipo warehouse. Obtens o custo dos lakes com a fiabilidade dos warehouses.

Verificação de performance: Fizemos benchmark do Delta Lake no S3 contra o Snowflake em consultas TPC-DS idênticas. O Snowflake foi 3-4x mais rápido em joins complexos. Mas o Delta Lake custou 70% menos para a mesma carga de trabalho. A escolha certa depende de estares a otimizar para latência de consulta ou custo total.

Onde os lakehouses brilham:

• Workflows de machine learning que precisam de acesso SQL e acesso a ficheiros brutos

• Dados de streaming que requerem garantias de processamento exactly-once

• Organizações que querem evitar vendor lock-in mantendo performance

Data Mesh: Uma Mudança Organizacional

Data Mesh não é uma tecnologia—é um modelo operacional. Em vez de uma equipa de dados central ser proprietária de toda a infraestrutura de dados, equipas de domínio são proprietárias dos seus dados como produtos.

Os quatro princípios:

• Propriedade orientada ao domínio (marketing é dono dos dados de marketing)

• Dados como produto (com SLAs, documentação, descobribilidade)

• Plataforma de dados self-serve (domínios não precisam de engenheiros de plataforma para cada mudança)

• Governança computacional federada (padrões centrais, execução distribuída)

Avaliação honesta: Data Mesh funciona para organizações com cultura de engenharia madura em múltiplos domínios. Já vi falhar em empresas onde apenas a equipa de dados central tem capacidades de engenharia fortes. Não podes descentralizar propriedade sem primeiro descentralizar expertise.

Implementação prática: Começa com dois domínios que têm equipas de engenharia fortes. Constrói a plataforma self-serve. Prova que o modelo funciona. Depois expande. Tentar adoção de Data Mesh em toda a empresa simultaneamente é receita para o caos.

Framework de Decisão: Escolher a Tua Arquitetura

Após 15+ migrações, eis o framework que uso:

Escolhe um warehouse quando:

• >80% dos teus dados encaixam em modelos relacionais

• Business intelligence é o teu caso de uso principal

• A tua equipa tem fortes competências SQL mas capacidade de engenharia limitada

Escolhe um lakehouse quando:

• Tens cargas de trabalho significativas de machine learning

• Os dados chegam em formatos variados (estruturados + não estruturados)

• Precisas de processamento streaming e batch nos mesmos dados

• Otimização de custos em escala é crítica

Escolhe um mesh quando:

• Tens 5+ domínios de dados distintos

• Cada domínio tem capacidades de engenharia

• Equipas de dados centralizadas tornaram-se bottlenecks

• Diferentes domínios têm diferentes requisitos de freshness de dados

A realidade híbrida: A maioria das organizações acaba com arquiteturas híbridas. Um warehouse Snowflake para finanças e BI, um lakehouse Databricks para ciência de dados, bases de dados especializadas para cargas de trabalho operacionais. A chave são fronteiras claras entre sistemas e contratos de dados bem definidos nas interfaces.

Lições Aprendidas em Migrações

Três padrões de migrações bem-sucedidas:

1. Execução paralela é inegociável. Executa sistemas antigo e novo simultaneamente durante pelo menos 3 meses. Compara outputs diariamente. Vais encontrar discrepâncias—melhor encontrá-las em paralelo do que após o cutover.

2. Começa com o caso de uso mais doloroso. Não migres cargas de trabalho fáceis primeiro. Ataca a consulta que demora 4 horas, o pipeline que quebra semanalmente. Vitórias iniciais em problemas difíceis constroem momentum organizacional.

3. Orçamenta para problemas de qualidade de dados. Cada migração descobre problemas de qualidade de dados escondidos em sistemas legados. Planeia 20-30% de tempo de engenharia adicional para limpeza.

A arquitetura que escolhes importa menos do que quão bem a implementas. Um data lake bem governado supera um warehouse mal gerido. Foca-te nos fundamentos: propriedade clara, metadados abrangentes, contratos de dados testados e monitorização contínua.