Onde os Dados Moram: O Guia Definitivo de Arquiteturas e Tecnologias de Armazenamento

Por alguém que acredita que dados são sobre pessoas, não apenas números

Como ler este guia. Ele foi escrito para dois públicos ao mesmo tempo. Se você é engenheiro, arquiteto ou cientista de dados, leia na ordem e use as fichas técnicas como referência. Se você é gestor, gestor sênior ou C-level, comece pela linha do tempo, pule para Qual tecnologia devo escolher?, leia Os erros mais caros e volte às seções técnicas conforme a necessidade. As tabelas comparativas e a matriz de decisão no final resolvem 80% das conversas de arquitetura que você terá com seu time.

1 Introdução: por que não existe “o banco de dados”

Toda vez que alguém entra na área de dados, faz a mesma pergunta — e é uma boa pergunta:

“Se um banco de dados guarda dados, por que existem trinta tipos diferentes?”

A resposta curta é que “guardar dados” não é uma tarefa única. É pelo menos seis tarefas diferentes, com exigências que se contradizem entre si:

• Registrar a compra de um cliente agora, sem perder nada, em milissegundos.
• Responder “qual foi a margem por categoria nos últimos 36 meses?” varrendo bilhões de linhas.
• Guardar 40 TB de fotos de sinistros que talvez ninguém abra nunca mais, pelo menor custo possível.
• Encontrar, entre 200 milhões de trechos de documentos, os cinco mais semanticamente parecidos com uma pergunta em linguagem natural.
• Descobrir que o titular da conta A é sócio da empresa B, que compartilha endereço com o beneficiário C — em três saltos e 50 milissegundos.
• Reagir a um evento de fraude antes que a transação seja aprovada.

Nenhuma tecnologia faz as seis coisas bem. Não porque os engenheiros sejam preguiçosos, mas porque as decisões de projeto são mutuamente excludentes. Um sistema otimizado para escrever uma linha por vez com garantia transacional (armazenamento por linha, índices B-tree, bloqueios) é estruturalmente ruim para varrer um bilhão de linhas somando uma coluna. Um sistema otimizado para varrer colunas comprimidas (armazenamento colunar, arquivos imutáveis) é estruturalmente ruim para atualizar um registro por vez, mil vezes por segundo.

É a velha lição da engenharia: não existe solução ótima, existe trade-off explícito. E a maturidade de uma organização de dados se mede menos pelas ferramentas que ela usa e mais pela clareza com que ela sabe por que usa cada uma.

1.1 O que Big Data, nuvem e IA mudaram

Três forças reescreveram esse cenário em vinte anos:

1. O volume e a variedade explodiram (2005–2015). Deixou de ser só “linhas de sistema transacional”. Passou a incluir logs de clique, sensores, JSON de APIs, áudio, imagem, vídeo. Esquemas rígidos definidos antes da ingestão viraram gargalo.

2. A nuvem separou computação de armazenamento (2012–2020). Esse é, de longe, o fato econômico mais importante da última década em dados. No mundo antigo (Teradata, Oracle Exadata, Hadoop on-premises), para guardar mais dados você comprava mais servidores — e pagava por CPU que não usava. Com armazenamento de objetos (S3, ADLS, GCS) você paga centavos por gigabyte-mês para guardar, e paga computação só quando consulta. Isso derrubou a barreira de entrada e permitiu que arquiteturas como Data Lake e Lakehouse existissem economicamente.

3. A IA mudou a natureza do dado útil (2020–2026). Modelos de linguagem transformaram texto não estruturado em ativo de primeira classe e criaram uma nova primitiva de armazenamento — o vetor de embedding — além de uma nova exigência: dados versionados, rastreáveis e reproduzíveis, porque agora não basta saber o resultado, é preciso saber com base em que o modelo respondeu.

Uma nota sobre a terceira força, e volto a ela ao longo do texto: quando o dado deixa de ser “linha de tabela” e vira “representação de uma pessoa” — o histórico de saúde, o padrão de consumo, o rosto em uma foto —, decisões de arquitetura viram decisões éticas. Onde você guarda define quem consegue ver, por quanto tempo, com qual rastreabilidade e com que possibilidade de correção. Governança não é um item de compliance que se resolve depois. Ela é uma propriedade da arquitetura, e arquitetura é difícil de mudar depois de pronta.

2 Uma linha do tempo em sete atos

Cada tecnologia desta lista nasceu resolvendo uma dor concreta da anterior. Entender a sequência é a forma mais rápida de entender o presente.

2.1 Por que cada onda aconteceu

O relacional (1970). Edgar Codd, na IBM, propôs que dados fossem representados como relações matemáticas, independentes de como são fisicamente armazenados.¹ Essa separação entre modelo lógico e físico é o motivo de o SQL ter sobrevivido a cinco décadas de moda tecnológica.

O Data Warehouse (1990). Bill Inmon definiu-o como uma coleção de dados “orientada por assunto, integrada, não volátil e variante no tempo, em apoio à decisão gerencial”.² Ralph Kimball propôs o caminho oposto — começar por processos de negócio e modelagem dimensional (fatos e dimensões) em vez de um modelo corporativo normalizado.³ A disputa Inmon × Kimball moldou vinte anos de projetos, e a prática moderna é quase sempre híbrida.

Hadoop (2004). O Google publicou dois artigos que mudaram a indústria: o Google File System, mostrando como armazenar petabytes em hardware barato e não confiável,⁴ e o MapReduce, mostrando como processá-los em paralelo.⁵ O Hadoop foi a implementação aberta dessas ideias — e a primeira vez que “guardar tudo primeiro, decidir o esquema depois” ficou viável.

NoSQL (2006–2009). O Bigtable⁶ e o Dynamo⁷ resolveram problemas que o relacional não escalava: escrita massivamente distribuída com disponibilidade acima de consistência forte. Vale notar o mal-entendido histórico: NoSQL nunca significou “sem SQL”, e sim “not only SQL”.

Data Lake (2010). O termo é atribuído a James Dixon, então CTO da Pentaho, em contraste com o data mart — o lago mantém a água em estado natural; o mart é a garrafa engarrafada para um consumo específico.⁸ A promessa era ótima. O problema foi o que veio depois: sem catálogo, sem qualidade e sem transações, muitos lagos viraram pântanos.

Lakehouse (2020). O artigo da CIDR de Armbrust, Ghodsi, Xin e Zaharia formalizou a proposta: usar armazenamento de objetos barato e aberto, mas colocar sobre ele uma camada de metadados transacional que entrega ACID, versionamento, schema enforcement e performance competitiva com data warehouses.⁹ O Delta Lake foi a primeira implementação amplamente adotada,¹⁰ seguida por Apache Iceberg e Apache Hudi.

3 O mapa mental: três eixos que explicam quase tudo

Antes de entrar tecnologia por tecnologia, um modelo simples. Praticamente todo repositório de dados pode ser posicionado em três eixos. Se você é gestor e quer levar uma única imagem desta leitura, leve esta.

Eixo 1 — Natureza da carga de trabalho (workload)

Eixo 2 — Estrutura do dado

• Estruturado: tabelas com esquema fixo (transações, cadastros, lançamentos contábeis).
• Semi-estruturado: tem estrutura, mas flexível (JSON, XML, Avro, logs, eventos).
• Não estruturado: imagens, áudio, vídeo, PDFs, texto livre, prontuários digitalizados.

Eixo 3 — Acoplamento entre computação e armazenamento

• Acoplado: banco relacional tradicional, Teradata, Hadoop clássico. Escalar um obriga a escalar o outro.
• Desacoplado: Snowflake, BigQuery, Databricks, qualquer coisa sobre S3/ADLS/GCS. Escala e custo independentes — a base econômica de toda arquitetura moderna.

Guarde este mapa. Quase todo erro de arquitetura que vejo é alguém usando uma tecnologia do quadrante errado em pelo menos um dos três eixos.

4 Parte I — A camada de fundação

4.1 Object Storage (armazenamento de objetos)

Definição. Sistema de armazenamento que guarda dados como objetos imutáveis (arquivo + metadados + identificador único) em um espaço de nomes plano, acessível por API HTTP — não como blocos de disco nem como uma árvore de diretórios POSIX.

Objetivo. Guardar volumes praticamente ilimitados de qualquer tipo de dado, com durabilidade extrema e o menor custo por gigabyte do mercado.

Características. Namespace plano (o “diretório” é convenção no nome da chave); objetos imutáveis (você substitui, não edita in loco); durabilidade projetada em torno de 99,999999999% (11 noves) nos principais provedores; classes de armazenamento por frequência de acesso; versionamento nativo; políticas de ciclo de vida; latência de dezenas a centenas de milissegundos por objeto.

Quando usar. Base de Data Lake e Lakehouse; arquivos brutos, mídia, backups, arquivamento regulatório de longo prazo; qualquer coisa grande e imutável.

Quando NÃO usar. Como banco de dados de aplicação; para leituras e escritas pontuais de baixa latência; para dados que mudam a cada segundo; para consultas transacionais.

Tecnologias. Amazon S3 (o padrão de facto, cuja API virou linguagem franca); Azure Data Lake Storage Gen2 (Blob Storage com namespace hierárquico, melhor para analytics); Google Cloud Storage; MinIO (compatível com S3, para nuvem privada); Cloudflare R2 (sem cobrança de egress); Ceph (on-premises).

No mundo real. A Netflix mantém seu data lake em S3 na casa das centenas de petabytes e criou o Apache Iceberg justamente para conseguir gerenciar tabelas nessa escala.¹¹

4.2 Distributed File Systems (sistemas de arquivos distribuídos)

Definição. Sistema de arquivos que distribui blocos entre muitos servidores, apresentando ao usuário uma árvore de diretórios única com semântica POSIX (ou próxima disso).

Objetivo. Dar throughput de leitura sequencial altíssimo para processamento distribuído, colocando a computação perto do dado.

Características. Arquivos divididos em blocos grandes (128 MB no HDFS) e replicados (fator 3 por padrão); um nó de metadados (NameNode) e nós de dados; princípio de data locality; write-once, read-many.

Quando usar. Cargas on-premises consolidadas; requisitos de soberania de dados que impedem nuvem pública; clusters HPC; ambientes onde a latência para armazenamento de objetos é proibitiva.

Quando NÃO usar. Como fundação de arquitetura nova em nuvem — em 2026 essa decisão precisa de justificativa muito específica. Armazenamento de objetos é mais barato, mais elástico e mais simples de operar.

Tecnologias. Apache Hadoop HDFS; Ceph; GlusterFS; Lustre e IBM Spectrum Scale (GPFS) em HPC; Alluxio como camada de cache entre computação e armazenamento de objetos.

Nota de mercado. O HDFS não morreu, mas deixou de ser o padrão para arquiteturas novas. A migração de HDFS para armazenamento de objetos foi o movimento estrutural da década de 2015–2025 — e sua principal motivação foi econômica, não técnica.

5 Parte II — A camada operacional (onde o negócio acontece)

5.1 Banco de dados relacional / OLTP

Definição. Sistema que organiza dados em tabelas relacionadas por chaves, com esquema definido antes da escrita, linguagem declarativa (SQL) e garantias transacionais ACID.

Objetivo. Registrar e consultar o estado atual do negócio com integridade absoluta e latência de milissegundos, sob alta concorrência.

Características. Esquema rígido (schema-on-write); normalização para eliminar redundância; chaves primárias e estrangeiras; índices B-tree; controle de concorrência (MVCC ou bloqueios); armazenamento orientado a linha; write-ahead log para durabilidade.

Quando usar. Sistemas transacionais (ERP, e-commerce, core bancário, prontuário eletrônico); qualquer coisa que envolva dinheiro ou obrigação legal; qualquer domínio com relacionamentos complexos e necessidade de integridade referencial. Regra prática honesta: na dúvida, comece com PostgreSQL. Ele resolve mais casos do que a maioria das pessoas imagina, inclusive JSON, busca textual, geoespacial e vetores.

Quando NÃO usar. Analytics em grande volume sobre a base de produção (você derruba o sistema e o cliente sente); armazenamento de arquivos binários grandes; ingestão de séries temporais na casa de milhões de pontos por segundo; dados sem esquema estável em fase de exploração.

Tecnologias. PostgreSQL (o mais versátil e extensível; suporta JSONB, PostGIS, pgvector, TimescaleDB); MySQL / MariaDB (onipresente em aplicações web); Microsoft SQL Server (forte integração com o ecossistema Microsoft); Oracle Database (dominante em grandes corporações e core bancário); Amazon Aurora (compatível com PostgreSQL/MySQL, com armazenamento distribuído gerenciado); CockroachDB, YugabyteDB e Google Spanner (distributed SQL — ACID com escala horizontal e distribuição geográfica).

No mundo real. O Nubank construiu boa parte de seu core sobre PostgreSQL e Datomic. A Uber migrou de PostgreSQL para MySQL em 2016 por razões de arquitetura de replicação e amplificação de escrita — um caso clássico de que não existe escolha universalmente certa, só escolha adequada ao contexto.¹²

5.2 Bancos analíticos / OLAP

Definição. Bancos projetados para consultas de agregação sobre grandes volumes, usando armazenamento colunar, compressão agressiva e execução vetorizada e massivamente paralela (MPP).

Objetivo. Responder perguntas analíticas complexas sobre bilhões de linhas em segundos, com custo previsível.

Características. Armazenamento por coluna (você lê só as colunas da consulta); compressão específica por tipo de dado; predicate pushdown e pruning por partição; processamento vetorizado (SIMD); paralelismo entre nós.

Quando usar. BI, dashboards corporativos, análise ad hoc, modelagem dimensional, feature engineering em SQL, relatórios regulatórios.

Quando NÃO usar. Como banco de aplicação; para leituras pontuais de baixa latência com alta concorrência; para atualizações unitárias frequentes.

Tecnologias. Snowflake (separação total entre computação e armazenamento, com virtual warehouses independentes);¹³ Google BigQuery (serverless, herdeiro do Dremel);¹⁴ Amazon Redshift; Azure Synapse Analytics / Microsoft Fabric; Databricks SQL; ClickHouse (o mais rápido da categoria para analytics em tempo real); DuckDB (OLAP embarcado, “o SQLite do analytics”, que mudou o jogo para análises locais); Apache Druid e Apache Pinot (analytics de baixa latência para aplicações voltadas ao usuário final); Teradata e Vertica (a geração anterior, ainda presente em grandes bancos e telecomunicações).

5.3 Document Database (banco de documentos)

Definição. Banco NoSQL que armazena documentos auto-descritivos (tipicamente JSON/BSON) como unidade primária, sem exigir esquema uniforme entre eles.

Objetivo. Dar flexibilidade de modelo a aplicações cujos dados mudam de forma frequente ou são naturalmente aninhados.

Quando usar. Catálogos de produto com atributos heterogêneos; perfis de usuário; CMS; agregados de aplicação em que o dado é lido inteiro; prototipagem rápida com modelo instável.

Quando NÃO usar. Quando há relacionamentos complexos entre entidades (você vai reimplementar joins na aplicação, mal); quando integridade referencial é requisito; quando relatórios analíticos são o consumo principal.

Tecnologias. MongoDB (líder de mercado); Amazon DocumentDB; Couchbase; Azure Cosmos DB (multimodelo, com distribuição global e cinco níveis de consistência); Firestore (aplicações móveis e web); PostgreSQL com JSONB — vale repetir: para muitos casos, esta última opção entrega flexibilidade de documento sem abrir mão de transações e joins.

5.4 Key-Value Store (chave-valor)

Definição. O modelo mais simples possível: uma chave única mapeia para um valor opaco. Sem esquema, sem consultas por conteúdo, sem joins.

Objetivo. Latência mínima e throughput máximo em acesso por chave conhecida.

Quando usar. Sessões de usuário; carrinhos de compra; feature flags; contadores; filas simples; qualquer acesso “dado o ID, me devolva o objeto”.

Quando NÃO usar. Quando você precisa consultar por qualquer coisa que não seja a chave; quando precisa de relacionamentos; como fonte única da verdade sem persistência garantida.

Tecnologias. Redis / Valkey (o padrão em memória, com estruturas ricas); Amazon DynamoDB (gerenciado, escala virtualmente ilimitada, herdeiro do Dynamo);¹⁵ etcd (configuração distribuída, base do Kubernetes); RocksDB e LevelDB (embarcados, motor de armazenamento de muitos outros bancos); Aerospike (baixa latência em escala, comum em adtech).

5.5 Wide Column Store (família de colunas)

Definição. Modelo em que cada linha é identificada por uma chave e pode ter um conjunto diferente de colunas, organizadas em famílias. Não confundir com armazenamento colunar de OLAP — a semelhança está no nome, não no propósito.

Objetivo. Escrita massivamente distribuída, com disponibilidade alta e escala horizontal linear para petabytes.

Quando usar. Séries de eventos em altíssimo volume; histórico de mensagens; telemetria de larga escala; casos com múltiplas regiões ativas simultaneamente.

Quando NÃO usar. Quando os padrões de consulta ainda não estão claros — neste modelo, você modela a tabela a partir da consulta, e mudar depois é caro. Também não use quando precisa de joins ou agregações ad hoc.

Tecnologias. Apache Cassandra e ScyllaDB (reescrita em C++, mais eficiente); Google Bigtable;¹⁶ Apache HBase; Amazon Keyspaces.

No mundo real. O histórico de mensagens do Discord roda em Cassandra e depois ScyllaDB, na casa de trilhões de mensagens.¹⁷

5.6 Time Series Database (banco de séries temporais)

Definição. Banco especializado em dados indexados por tempo, em que o timestamp é a dimensão organizadora primária e os registros são majoritariamente apêndices imutáveis.

Objetivo. Ingerir milhões de pontos por segundo, comprimir com eficiência extrema e responder consultas por janelas temporais e agregações de forma barata.

Características. Compressão especializada (delta-of-delta, Gorilla, XOR) que reduz o armazenamento em uma ordem de magnitude; downsampling e políticas de retenção automáticas; funções nativas de janela móvel, interpolação e taxa de variação; continuous aggregates.

Quando usar. Observabilidade (métricas de infraestrutura e aplicação); IoT e sensores industriais; dados financeiros de mercado (tick data); telemetria veicular; medição de energia.

Quando NÃO usar. Para dados relacionais ou que sofram atualização frequente; quando o tempo não é a dimensão principal de consulta.

Tecnologias. InfluxDB; TimescaleDB (extensão do PostgreSQL — mantém SQL completo e o ecossistema Postgres); Prometheus (padrão de facto em observabilidade Kubernetes); VictoriaMetrics e Mimir (escala horizontal para Prometheus); QuestDB; Amazon Timestream; ClickHouse (frequentemente usado como TSDB de altíssimo volume).

5.7 Graph Database (banco de grafos)

Definição. Banco em que a unidade de modelagem é o par nó–relacionamento, e o relacionamento é armazenado fisicamente como um ponteiro, não computado por join em tempo de consulta.

Objetivo. Percorrer relacionamentos profundos e variáveis com performance constante, independentemente do tamanho total da base.

Características. Index-free adjacency — a partir de um nó você chega aos vizinhos em tempo constante; linguagens declarativas de travessia (Cypher, Gremlin, SPARQL, e o padrão ISO GQL, publicado em 2024); propriedades em nós e arestas.

Quando usar. Detecção de fraude e lavagem de dinheiro (anéis de relacionamento); grafos de conhecimento e GraphRAG; recomendação baseada em rede; análise de risco de contraparte; gestão de identidade e acesso; rastreamento de cadeia de suprimentos; análise de dependências em TI.

Quando NÃO usar. Quando os relacionamentos são poucos e rasos — um join de duas tabelas em SQL não justifica um banco novo. Também não use como repositório analítico geral.

Tecnologias. Neo4j (líder, linguagem Cypher); Amazon Neptune; TigerGraph (foco em escala e analytics de grafo); ArangoDB (multimodelo); Memgraph (em memória, tempo real); JanusGraph; Apache AGE (extensão de grafo para PostgreSQL).

No mundo real. Consórcios bancários e reguladores usam grafos para investigar redes de lavagem de dinheiro; os Panama Papers foram investigados pelo ICIJ com Neo4j, e a análise em grafo foi decisiva para revelar as cadeias de propriedade oculta.¹⁸ É um bom lembrete de que a escolha da tecnologia certa às vezes é o que torna a justiça possível.

5.8 Cache distribuído

Definição. Camada de armazenamento volátil e compartilhada entre instâncias de aplicação, que guarda cópias de dados caros de obter, com tempo de expiração.

Objetivo. Reduzir latência percebida pelo usuário e proteger o banco de origem de carga repetitiva.

Quando usar. Sempre que a mesma leitura cara se repete; sessões; rate limiting; resultados de APIs externas; camada de leitura para picos de tráfego (Black Friday, bilheteria, matrícula escolar).

Quando NÃO usar. Como fonte da verdade; para dados que precisam ser duráveis; quando a invalidação é mais complexa que o benefício — cache mal invalidado é uma das principais causas de bug difícil de reproduzir em produção.

Ponto de atenção que raramente aparece em documentação técnica. Caches guardam dados pessoais em memória, frequentemente sem criptografia, sem controle de acesso granular, sem log de auditoria e fora do inventário de dados da empresa. Já vi mapeamentos de LGPD completos que simplesmente não listavam o Redis. Se o dado do titular está lá, ele está sujeito às mesmas obrigações — inclusive à de exclusão.

Tecnologias. Redis / Valkey; Memcached; Hazelcast e Apache Ignite (grades de dados em memória); Amazon ElastiCache; Caffeine (cache local em JVM, quando distribuído não é necessário).

5.9 Streaming Storage (armazenamento de fluxo)

Definição. Log distribuído, ordenado, particionado e durável, em que produtores anexam registros ao fim e múltiplos consumidores leem de forma independente, cada um controlando sua própria posição.

Objetivo. Ser a espinha dorsal de integração em tempo real entre sistemas, desacoplando quem produz de quem consome.

Características. Log apenas de apêndice, imutável; partições que dão ordenação e paralelismo; retenção configurável por tempo ou tamanho (e compaction por chave); replicação entre nós; offset controlado pelo consumidor — o que permite reprocessar o passado.

Quando usar. Integração entre microsserviços; CDC de bancos operacionais; ingestão de IoT e cliques; detecção de fraude em tempo real; alimentação simultânea de sistemas operacionais e analíticos a partir de uma única fonte.

Quando NÃO usar. Como banco de dados consultável (não há consulta por conteúdo); para armazenamento de longo prazo (embora o tiered storage moderno esteja mudando isso); quando um job em lote diário resolveria o problema — e resolve, em mais casos do que se admite.

Tecnologias. Apache Kafka (o padrão de facto);¹⁹ Apache Pulsar (separa computação de armazenamento via BookKeeper, com multi-tenancy nativo); Amazon Kinesis Data Streams; Azure Event Hubs; Google Pub/Sub; Redpanda (compatível com a API do Kafka, em C++, sem JVM nem ZooKeeper); Apache Flink para processamento com estado sobre esses fluxos.

5.10 Event Store (armazenamento de eventos)

Definição. Banco especializado em event sourcing: o estado da aplicação não é armazenado diretamente, mas derivado da sequência completa e imutável de eventos de negócio que aconteceram.

Objetivo. Preservar a intenção e a história completa do que ocorreu, permitindo reconstruir qualquer estado passado e derivar novas visões a partir do mesmo histórico.

Diferença fundamental em relação ao streaming. Kafka é infraestrutura de transporte com retenção; um Event Store é o sistema de registro do domínio, com fluxos por agregado, garantias de concorrência otimista por versão e leitura ordenada de um fluxo específico. Muita gente usa Kafka como Event Store e depois descobre, tarde, que faltam essas garantias.

Quando usar. Domínios em que o histórico é o requisito: contabilidade, sistemas regulados, saúde, seguros, controle de acesso. Também quando auditabilidade completa é exigência legal.

Quando NÃO usar. CRUD comum — é complexidade sem retorno. E atenção a um conflito real: um log imutável colide com o direito de eliminação previsto na LGPD e no GDPR. A solução usual é crypto-shredding (guardar dados pessoais cifrados e destruir a chave), e isso precisa ser projetado no início, não remendado depois.

Tecnologias. EventStoreDB (KurrentDB); Axon Server; Marten (sobre PostgreSQL); Apache Kafka com compactação (com as ressalvas acima); AWS DynamoDB Streams para padrões mais simples.

6 Parte III — A camada analítica

6.1 Data Warehouse (armazém de dados)

Definição. Repositório central que integra dados de múltiplas fontes operacionais, tratados, modelados, historizados e organizados para apoiar decisão. Na definição clássica de Inmon: orientado por assunto, integrado, não volátil e variante no tempo.²⁰

Objetivo. Dar à organização uma base analítica consistente, confiável e histórica — a tal “versão única da verdade”.

Características. Schema-on-write (a estrutura é definida antes da carga); modelagem dimensional (fatos, dimensões, esquema estrela) ou normalizada (Data Vault, 3NF); histórico preservado com dimensões de mudança lenta (SCD); dados curados, com regras de qualidade aplicadas na entrada.

Quando usar. BI corporativo; relatórios financeiros e regulatórios; KPIs que precisam ser idênticos em todas as áreas; qualquer número que vá para o conselho de administração ou para o regulador.

Quando NÃO usar. Para guardar dados brutos não estruturados (imagens, áudio, vídeo); como área de exploração de dados ainda sem modelo definido; para cargas de ML sobre dados brutos em larga escala; quando o custo por TB inviabiliza reter cinco anos de log bruto.

Tecnologias. Snowflake; Google BigQuery; Amazon Redshift; Azure Synapse / Microsoft Fabric; Databricks SQL Warehouse; Teradata, Oracle Exadata, IBM Db2 Warehouse, SAP BW (a geração anterior, ainda muito viva em grandes corporações); Firebolt e ClickHouse Cloud entre as alternativas de alto desempenho.

6.1.1 Enterprise Data Warehouse (EDW)

Definição. O Data Warehouse em escopo corporativo — um único repositório que atende toda a organização, com modelo integrado entre domínios, em vez de vários armazéns departamentais.

Objetivo. Eliminar divergência de números entre áreas e criar um vocabulário de negócio comum.

Vantagens. Consistência corporativa real; economia de escala em infraestrutura e licenças; governança centralizada; uma definição só de “cliente ativo”.

Desvantagens. É onde a tensão organizacional aparece. Times centrais viram gargalo; o backlog cresce; áreas de negócio criam soluções paralelas em planilhas e bases próprias; projetos de EDW ficaram famosos por prazos longos e entregas tardias. Foi exatamente essa frustração que motivou o Data Mesh.

Quando faz sentido em 2026. Em organizações com forte necessidade regulatória e domínios estáveis (bancos, seguradoras, utilities), o EDW continua sendo a resposta certa. A crítica ao modelo é organizacional, não técnica.

6.2 Data Mart

Definição. Subconjunto do Data Warehouse voltado a um domínio ou área específica — vendas, finanças, marketing, logística.

Objetivo. Entregar valor rápido a uma área, com modelo simples, performance previsível e escopo controlado.

Características. Escopo departamental; modelagem dimensional focada; pode ser dependente (derivado do DW corporativo), independente (construído direto das fontes) ou híbrido.

Quando usar. Entrega incremental de valor; áreas com necessidade urgente e escopo claro; camada de consumo final sobre um Lakehouse.

Quando NÃO usar. Como estratégia corporativa de dados. Marts independentes que se multiplicam são a receita histórica para reuniões em que cada diretoria chega com um número diferente de receita — e o tempo da liderança é gasto reconciliando planilhas em vez de decidindo.

Tecnologias. Qualquer DW moderno com schemas separados; dbt para gerenciar as transformações com versionamento, testes e documentação — hoje o padrão de facto da camada de transformação; Power BI Datasets, Looker e Cube como camadas semânticas.

6.3 Operational Data Store (ODS)

Definição. Repositório integrado de dados operacionais atuais (não históricos), atualizado com latência baixa, que consolida informações de vários sistemas para consumo operacional.

Objetivo. Responder perguntas operacionais que atravessam sistemas — “qual a situação completa deste cliente agora?” — sem consultar cada sistema de origem nem esperar a carga noturna do DW.

Diferença essencial em relação ao DW. O ODS guarda o estado atual e é volátil (sofre atualização); o DW guarda o histórico e é não volátil. O ODS serve o atendente no telefone; o DW serve o analista e o diretor.

Quando usar. Visão 360º do cliente para atendimento; consultas operacionais entre sistemas; camada de desacoplamento entre sistemas legados; alimentação de portais e aplicativos com dado consolidado.

Quando NÃO usar. Para análise histórica e tendências; como substituto do DW; quando um CDC direto para o Lakehouse já resolve — em arquiteturas modernas, o ODS clássico está sendo substituído por camadas silver de Lakehouse com atualização contínua.

Tecnologias. PostgreSQL ou SQL Server com CDC; Debezium para captura de mudanças; MongoDB para visões 360º; Kafka Streams com estado materializado; tabelas streaming de Lakehouse.

6.4 Data Lake

Definição. Repositório que armazena grandes volumes de dados em formato bruto, em armazenamento de objetos, com a estrutura sendo aplicada apenas no momento da leitura (schema-on-read).

Objetivo. Guardar tudo, barato, sem decidir antecipadamente qual será o uso — preservando a opção de responder perguntas que ainda não foram formuladas.

Características. Baixo custo por TB; aceita qualquer formato; organização por zonas (bruta, tratada, curada); desacoplamento total entre armazenamento e as engines de processamento; sem esquema imposto na escrita.

Quando usar. Ingestão de dados brutos de origens heterogêneas; retenção de longo prazo a baixo custo; treinamento de modelos sobre dados brutos; dados não estruturados (imagem, áudio, texto); exploração de dados novos.

Quando NÃO usar. Como camada de consumo direto para BI corporativo; para cargas transacionais; como substituto de banco de dados — este é o erro conceitual mais comum da área; e sem catálogo, sem qualidade e sem dono definido, porque o resultado tem nome próprio: data swamp.

Tecnologias. Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage, HDFS, MinIO como armazenamento; Apache Parquet e ORC como formatos; AWS Glue Data Catalog, Apache Hive Metastore, Unity Catalog como catálogos; Apache Spark, Trino, Presto, Athena, DuckDB como engines.

Uma lição que aprendi observando muitos projetos. A promessa “guarde tudo agora, decida depois” é tecnicamente verdadeira e organizacionalmente perigosa. Ela transfere para o futuro um custo que cresce: dado sem contexto, sem dono e sem documentação vira passivo — de armazenamento, de risco regulatório e de confiança. Quando alguém pergunta “esse número é confiável?” e ninguém sabe responder, o problema já deixou de ser técnico.

6.5 Delta Lake

Definição. Camada de armazenamento open source que adiciona transações ACID, versionamento, evolução de esquema e otimizações de performance sobre arquivos Parquet em armazenamento de objetos. Não é um banco de dados nem um serviço: é um formato de tabela definido por um log de transações.²¹

Como funciona, em uma frase. Cada tabela tem um diretório _delta_log com arquivos JSON numerados sequencialmente, que registram quais arquivos Parquet compõem a versão atual da tabela. Uma transação é a criação atômica do próximo arquivo de log — e é isso que dá ACID sobre um armazenamento que, sozinho, não tem transação alguma.

Objetivo. Eliminar o compromisso entre o custo do Data Lake e a confiabilidade do Data Warehouse.

Características. ACID com isolamento de snapshot; time travel por versão ou por timestamp; MERGE, UPDATE e DELETE (essenciais para CDC e para atender pedidos de exclusão de dados pessoais); schema enforcement e schema evolution; deletion vectors; liquid clustering; OPTIMIZE e Z-ORDER para compactar arquivos pequenos.

Quando usar. Como formato padrão de tabelas em Lakehouse no ecossistema Databricks ou Spark; sempre que houver necessidade de atualização, deleção ou CDC sobre o lago; quando reprodutibilidade de experimentos de ML importa.

Quando NÃO usar. Para dados que só serão lidos uma vez em varredura completa (Parquet puro basta e é mais simples); para cargas OLTP; quando não há capacidade de manter as rotinas de otimização — Delta sem compactação acumula arquivos pequenos e a performance despenca.

Tecnologias. Delta Lake (projeto Linux Foundation); Apache Spark; Databricks; delta-rs (implementação em Rust, sem Spark); Delta Sharing (compartilhamento aberto entre organizações); leitura nativa em Trino, Flink, DuckDB, Snowflake e BigQuery.

6.6 Lakehouse

Definição. Arquitetura que combina o armazenamento aberto e barato do Data Lake com as garantias transacionais, o desempenho e a governança do Data Warehouse, por meio de uma camada de metadados baseada em formatos de tabela abertos.²²

Não confunda os três — este é o mal-entendido mais comum da área:

Em outras palavras: o Delta Lake é um dos componentes que tornam o Lakehouse possível; o Lakehouse é a arquitetura completa; o Data Lake é a fundação sobre a qual tudo isso é construído.

Objetivo. Ter uma única cópia dos dados, em formato aberto, servindo BI, analytics, streaming e machine learning — eliminando a duplicação e o custo de manter lago e armazém em paralelo.

Características. Armazenamento de objetos como base; formato de tabela aberto (Delta, Iceberg, Hudi); catálogo com governança unificada (Unity Catalog, Polaris, Glue); múltiplas engines lendo os mesmos dados; arquitetura em camadas medallion (bronze → prata → ouro).

Quando usar. Plataformas novas em nuvem; quando BI e ML precisam da mesma base sem cópias divergentes; quando o custo do DW puro em escala de petabytes se tornou insustentável; quando a organização quer evitar dependência de um único fornecedor.

Quando NÃO usar. Cargas transacionais; consultas com latência de milissegundos e milhares de usuários simultâneos (um Druid, Pinot ou ClickHouse serve melhor); organizações pequenas com poucos terabytes, onde um Postgres com DuckDB ou um DW simples resolve com uma fração da complexidade. Vale dizer com todas as letras: grande parte das empresas não tem Big Data, tem dado médio com ansiedade de escala.

Tecnologias. Databricks (a plataforma que criou o termo); Microsoft Fabric / OneLake; Snowflake com tabelas Iceberg; Amazon S3 Tables e Athena; Google BigLake; Dremio; Starburst / Trino; Apache Doris e StarRocks.

No mundo real. A Netflix criou o Iceberg para resolver problemas de escala e consistência de tabelas Hive; a Uber criou o Hudi para tornar viável a ingestão incremental de CDC em escala; a Databricks criou o Delta Lake para dar confiabilidade ao lago. Três empresas, o mesmo problema, três soluções que hoje convergem.

6.7 Formatos de tabela abertos: Delta × Iceberg × Hudi

Os três resolvem a mesma dor essencial — transações sobre arquivos em armazenamento de objetos — com filosofias diferentes.

Onde essa disputa chegou em 2026. O mercado convergiu para o Iceberg como formato de interoperabilidade: Snowflake, Databricks, AWS, Google e Microsoft leem e escrevem Iceberg, e a especificação v3 — ratificada em 2025, com deletion vectors, tipo variant, linhagem de linha e tipos geoespaciais — chegou a disponibilidade geral nas principais plataformas ao longo de 2026, embora a maioria das tabelas em produção ainda esteja em v2.²³ A Databricks passou a tratar Delta e Iceberg como formatos de primeira classe dentro do Unity Catalog e propôs convergência de metadados entre Iceberg v4 e Delta 5.0.²⁴

A consequência estratégica é a que mais importa para quem decide: a disputa migrou do formato para o catálogo. O formato virou commodity aberta; o ponto de aprisionamento agora é o serviço que gerencia metadados, permissões e linhagem — Unity Catalog, Snowflake Horizon/Open Catalog, Apache Polaris, AWS Glue.²⁵ Se você está negociando contrato de plataforma de dados, é sobre o catálogo e a portabilidade dos metadados que sua equipe precisa perguntar.

Vale registrar dois nomes que ganharam espaço recentemente: Apache Paimon, desenhado para streaming com estrutura LSM (forte no ecossistema Flink), e DuckLake, que propõe guardar todos os metadados de tabela em um banco relacional em vez de arquivos — uma simplificação com adoção ainda inicial, mas com ideias que já estão influenciando os formatos consolidados.²⁶

7 Parte IV — A camada de inteligência artificial

7.1 Feature Store

Definição. Repositório centralizado de features (variáveis de entrada de modelos) que garante que a mesma definição de cálculo seja usada no treinamento e na inferência, com versionamento e reuso entre equipes.

Objetivo. Resolver dois problemas que custam caro e são difíceis de detectar: o training-serving skew (a feature calculada de um jeito no treino e de outro em produção, degradando o modelo silenciosamente) e o vazamento temporal (usar, no treino, informação que não estaria disponível no momento da predição).

Características. Arquitetura dupla — offline store (histórico, sobre Lakehouse ou DW, para treino) e online store (chave-valor de baixa latência, para inferência); point-in-time correctness nas junções, que é a funcionalidade que realmente justifica a categoria; catálogo de features com dono, descrição e linhagem; monitoramento de drift.

Quando usar. A partir de mais ou menos uma dezena de modelos em produção, ou quando múltiplos times reusam as mesmas features; sempre que houver requisito de inferência em tempo real; em domínios regulados, onde é preciso provar quais dados alimentaram uma decisão automatizada.

Quando NÃO usar. Com dois ou três modelos batch — uma tabela bem documentada no Lakehouse resolve com muito menos complexidade. Feature Store adotado cedo demais é um dos casos mais frequentes de investimento em plataforma sem retorno.

Tecnologias. Feast (open source, leve, agnóstico); Tecton (gerenciado, forte em tempo real); Databricks Feature Store (integrado ao Unity Catalog, com linhagem automática); Hopsworks; Vertex AI Feature Store; Amazon SageMaker Feature Store; Chronon (criado pelo Airbnb).

Onde isso encontra a ética. Uma Feature Store é, na prática, o melhor instrumento de auditoria de justiça algorítmica que uma empresa pode ter. Se você consegue responder “quais features alimentaram a decisão de negar este crédito, com quais valores, naquele instante?”, você consegue auditar viés. Se não consegue, sua explicação para o cliente — e para o regulador — é uma reconstrução aproximada. A diferença entre as duas situações é uma decisão de arquitetura tomada anos antes.

7.2 Vector Database (banco vetorial)

Definição. Banco especializado em armazenar embeddings — vetores de centenas a milhares de dimensões que representam o significado de um texto, imagem, áudio ou vídeo — e em buscar os mais similares a um vetor de consulta, por proximidade geométrica.

Objetivo. Viabilizar busca semântica (“encontre o que significa algo parecido”) em vez de busca léxica (“encontre quem contém esta palavra”), que é a base do padrão RAG (Retrieval-Augmented Generation) e da memória de agentes de IA.

Características. Índices de vizinhos mais próximos aproximados — HNSW (grafo hierárquico navegável, o mais comum)²⁷ e IVF-PQ (partição com quantização de produto); métricas de distância (cosseno, produto interno, euclidiana); filtragem por metadados combinada à busca vetorial; busca híbrida (vetorial + BM25 léxico), que na prática entrega resultado melhor do que qualquer uma isolada.

Quando usar. RAG sobre base de conhecimento corporativa; busca semântica em documentos, jurisprudência, prontuários ou catálogos; recomendação por similaridade; deduplicação de registros; busca multimodal (texto que encontra imagem); memória de longo prazo de agentes.

Quando NÃO usar. Quando busca por palavra-chave resolve (frequentemente resolve, e sai muito mais barato); como fonte da verdade (o vetor é uma representação derivada, não o dado); para dados estruturados com filtros exatos; abaixo de alguns milhões de vetores, quando pgvector no Postgres que você já opera costuma ser a escolha economicamente mais sensata.

Tecnologias e o estado do mercado em 2026. A categoria se organizou em quatro grupos: SaaS gerenciado (Pinecone, Weaviate Cloud, Zilliz Cloud), open source auto-hospedado (Qdrant, Milvus, Weaviate), bibliotecas embarcadas (Chroma, LanceDB) e extensões de bancos que a empresa já tem (pgvector, Redis, MongoDB Atlas Vector Search, Elasticsearch, OpenSearch). O mercado foi estimado em torno de US$ 3,7 bilhões em 2026, com crescimento anual acima de 20%, impulsionado pela industrialização de RAG e pelo volume de consultas gerado por agentes autônomos.²⁸ A orientação prática mais repetida por quem opera essas cargas: pgvector para a maioria dos casos abaixo de alguns milhões de vetores; Qdrant quando há filtragem pesada com baixa latência; Milvus ou Zilliz na casa dos bilhões.²⁹

7.2.1 Relacional × Vetorial: uma comparação que evita erro caro

8 Parte V — A camada de metadados, governança e arquitetura

8.1 Metadata Repository e Data Catalog

Definição. O repositório de metadados é a base que armazena informação sobre os dados: esquemas, tipos, estatísticas, proprietários, linhagem, políticas de acesso, glossário de negócio. O Data Catalog é a camada de descoberta e colaboração sobre esse repositório — a interface pela qual as pessoas encontram, entendem e confiam nos dados.

Tipos de metadados.

• Técnicos: esquema, tipos, tamanho, partições, formato, estatísticas.
• De negócio: definição de “cliente ativo”, regras de cálculo, criticidade, dono.
• Operacionais: quando a tabela foi atualizada, se o job falhou, qual a taxa de completude.
• Sociais: quem usa, quem certificou, quais consultas são mais frequentes, notas e avaliações.

Objetivo. Tornar os dados encontráveis, compreensíveis e confiáveis — e tornar auditável quem acessou o quê.

Quando usar. Sempre que houver mais de um time consumindo dados. A pergunta “onde eu acho o dado de X e posso confiar nele?” é o principal ladrão de produtividade em organizações de dados.

Quando NÃO usar (ou usar com cautela). Comprar uma ferramenta de catálogo esperando que ela resolva governança por conta própria é uma frustração previsível. Catálogo sem donos designados e sem incentivos vira um cemitério de metadados desatualizados — que é pior que não ter catálogo, porque cria falsa confiança.

Tecnologias. Databricks Unity Catalog; Snowflake Horizon; AWS Glue Data Catalog; Apache Polaris e Project Nessie (catálogos abertos para Iceberg, o segundo com semântica de branches ao estilo Git); DataHub (criado no LinkedIn); OpenMetadata; Apache Atlas; Amundsen (Lyft); Collibra, Alation e Informatica no segmento corporativo; dbt docs para linhagem no nível de transformação.

8.2 Data Hub

Definição. Arquitetura de integração em que um ponto central medeia o intercâmbio de dados entre sistemas, com modelo canônico, sem necessariamente armazenar cópias permanentes de tudo.

Objetivo. Reduzir a explosão combinatória de integrações ponto a ponto — o clássico problema de N sistemas exigindo N×(N−1)/2 conexões.

Diferença em relação a lago e armazém. O foco do Data Hub é movimento e mediação, não análise. Ele resolve o problema de sincronização entre sistemas operacionais, não o de análise histórica.

Quando usar. Muitos sistemas legados que precisam trocar dados; fusões e aquisições, quando dois parques tecnológicos precisam conversar; MDM (gestão de dados mestres) de cliente e produto.

Quando NÃO usar. Como plataforma analítica. E cuidado com o hub que vira gargalo organizacional — se toda integração depende de um time central, você trocou complexidade técnica por fila de espera.

Tecnologias. MarkLogic; Informatica MDM; Talend; Kafka como espinha dorsal de um hub baseado em eventos; Reltio; Semarchy.

8.3 Data Fabric

Definição. Abordagem arquitetural que cria uma camada unificada de acesso, integração e governança sobre fontes de dados distribuídas e heterogêneas, usando metadados ativos e automação para conectar em vez de centralizar.

Objetivo. Permitir acesso governado a dados onde quer que eles estejam, sem exigir a consolidação física de tudo em um repositório único.

Características. Virtualização e federação de consultas; catálogo de metadados ativos que alimenta automação; políticas de segurança aplicadas centralmente e executadas nas fontes; descoberta assistida por aprendizado de máquina.

Quando usar. Ambientes genuinamente híbridos e multinuvem; restrições regulatórias ou de soberania que impedem mover dados de país ou de sistema; organizações com forte legado e baixa tolerância a migração.

Quando NÃO usar. Como atalho para evitar arrumar a casa. Federação sobre fontes ruins entrega dado ruim mais rápido. E performance de consulta federada sobre sistemas transacionais é uma limitação real, não um detalhe de implementação.

Tecnologias. Denodo (referência em virtualização); Starburst / Trino; IBM Cloud Pak for Data; Microsoft Fabric; Dremio; Informatica IDMC.

Fabric × Mesh — a confusão que atrapalha discussões de estratégia. Data Fabric é uma resposta tecnológica (uma camada que conecta e automatiza). Data Mesh é uma resposta organizacional (times de domínio como donos de produtos de dados). Não são concorrentes e não se excluem: dá perfeitamente para ter um mesh organizacional apoiado por uma fabric tecnológica. Quando um fornecedor apresenta os dois como alternativas concorrentes, vale perguntar por quê.

8.4 Data Mesh

Definição. Abordagem sociotécnica, proposta por Zhamak Dehghani em 2019, que descentraliza a propriedade dos dados analíticos para os times de domínio, sustentada por quatro princípios: propriedade por domínio, dados como produto, plataforma de autosserviço e governança federada computacional.³⁰

O problema que ela ataca. Não é técnico. É o gargalo do time central de dados que não conhece o negócio de nenhum domínio em profundidade, e que por isso vira ao mesmo tempo gargalo de entrega e ponto de perda de contexto.

Os quatro princípios, na prática:

1. Propriedade por domínio. Quem gera o dado é responsável por ele analiticamente. O time de logística é dono dos dados de entrega, e não uma equipe central que nunca visitou um centro de distribuição.
2. Dados como produto. Cada conjunto tem dono, SLA, documentação, contrato de esquema, versionamento e — o critério que separa retórica de prática — consumidores satisfeitos como medida de sucesso.
3. Plataforma de autosserviço. Sem uma plataforma que torne barato publicar um produto de dados com qualidade, descentralizar apenas espalha o caos.
4. Governança federada computacional. Padrões globais (identificadores, privacidade, qualidade mínima) definidos em conjunto e aplicados como código, automaticamente, não como comitê que aprova por e-mail.

Quando usar. Organizações grandes, com domínios de negócio realmente distintos, maturidade de engenharia alta e um time central já saturado. Vale a pena quando o gargalo comprovadamente é organizacional.

Quando NÃO usar. Empresas pequenas ou médias — para dez pessoas de dados, um time central bem organizado é mais eficiente. Também não use quando a maturidade de engenharia dos domínios é baixa: mesh sem plataforma madura produz dezenas de silos com nomes bonitos. E, sendo direto: uma parcela relevante das iniciativas que se apresentam como Data Mesh são, na prática, o antigo modelo descentralizado com terminologia nova.

Tecnologias. Não existe “ferramenta de Data Mesh” — é arquitetura organizacional. O que existe são habilitadores: Databricks Unity Catalog e Delta Sharing; Snowflake com data sharing entre contas; dbt para produtos de dados versionados; DataHub e OpenMetadata como marketplaces internos; Great Expectations e Soda para qualidade como código; Open Data Contract Standard para contratos formais entre produtor e consumidor.

Uma observação sobre governança federada que vale para qualquer modelo. Descentralizar propriedade não descentraliza responsabilidade legal. A empresa continua sendo a controladora dos dados pessoais perante a LGPD, independentemente de qual time publicou o produto de dados. Por isso, no Data Mesh, as políticas de privacidade e de retenção precisam ser executadas pela plataforma, automaticamente — não confiadas à boa vontade de cada domínio. É a diferença entre governança que funciona e governança que aparece bonita no slide.

9 Parte VI — Os conceitos que atravessam todas as tecnologias

Esta seção é a “gramática” da área. Sem ela, as decisões de arquitetura viram escolha de marca.

9.1 Schema-on-Write × Schema-on-Read

O Lakehouse é interessante justamente porque permite as duas coisas em camadas diferentes: schema-on-read na camada bronze (guarde tudo como veio) e schema-on-write nas camadas prata e ouro (só entra o que passa nas regras).

9.2 ACID × BASE

ACID — o contrato dos bancos transacionais:

• Atomicidade: ou a transação inteira acontece, ou nada acontece. Sem débito sem o crédito correspondente.
• Consistência: a transação leva o banco de um estado válido a outro estado válido, respeitando todas as regras.
• Isolamento: transações simultâneas não enxergam estados intermediários umas das outras.
• Durabilidade: uma vez confirmada, sobrevive a queda de energia.

BASE — o contrato de muitos sistemas distribuídos:

• Basically Available: o sistema responde, mesmo que com dado possivelmente desatualizado.
• Soft state: o estado pode mudar sem escrita, por propagação entre réplicas.
• Eventual consistency: dado tempo suficiente sem novas escritas, todas as réplicas convergem.

A raiz teórica é o teorema CAP, formulado por Eric Brewer e formalizado por Gilbert e Lynch: diante de uma partição de rede, um sistema distribuído precisa escolher entre consistência e disponibilidade.³¹ Uma formulação mais útil no dia a dia é o PACELC: em caso de partição (P), escolha entre disponibilidade (A) e consistência (C); else (E), na operação normal, escolha entre latência (L) e consistência (C).

Como decidir na prática. A pergunta não é técnica, é de negócio: qual o custo de mostrar um dado desatualizado por alguns segundos? Se a resposta for “um cliente vê 3 curtidas em vez de 4”, use BASE. Se for “um cliente saca duas vezes o mesmo saldo” ou “um paciente recebe a dose errada”, use ACID. Consistência eventual é uma decisão de negócio disfarçada de decisão técnica.

9.3 ETL × ELT

O ELT venceu na maioria dos cenários em nuvem, e o dbt consolidou a prática de tratar transformação como código versionado, testado e documentado. Uma ressalva importante: em contextos com dados pessoais sensíveis, o ETL clássico ainda tem um mérito real — mascarar ou pseudonimizar antes que o dado chegue ao repositório analítico reduz a superfície de exposição de forma que nenhuma política aplicada depois consegue igualar.

9.4 CDC (Change Data Capture)

Definição. Técnica que captura, em tempo quase real, as alterações (inserções, atualizações, exclusões) ocorridas em um banco de origem, geralmente lendo o log de transações do próprio banco.

Por que importa. Substitui as cargas completas noturnas por fluxos incrementais, reduzindo latência de horas para segundos e a carga sobre o sistema de origem para quase nada.

Métodos, do pior ao melhor. Comparação completa entre origem e destino (caro e lento); coluna de timestamp updated_at (simples, mas não captura exclusões e falha se a aplicação esquecer de atualizar o campo); triggers (impacto na produção); leitura do log de transações — WAL no PostgreSQL, binlog no MySQL, redo log no Oracle — que é a abordagem correta na maioria dos casos.

Tecnologias. Debezium (open source, o padrão de mercado); Fivetran e Airbyte; AWS DMS; Qlik Replicate; Databricks Lakeflow Connect; Oracle GoldenGate.

Atenção que evita um incidente. CDC propaga também as exclusões. Se um titular exerce o direito de eliminação no sistema de origem, sua pipeline precisa propagar isso até a última cópia analítica. Foi para viabilizar exatamente esse tipo de operação que o DELETE em formatos de tabela abertos deixou de ser luxo e virou requisito.

9.5 Formatos de arquivo: quando cada um faz sentido

A regra que resolve 90% das dúvidas: Avro para dados em movimento, Parquet para dados em repouso. Avro é orientado a linha e ótimo para escrever registros completos rapidamente com evolução de esquema controlada; Parquet é colunar e ótimo para ler poucas colunas de muitos registros.

Um exemplo do impacto econômico: um conjunto de dados de 1 TB em CSV costuma ocupar entre 100 e 200 GB em Parquet com compressão Snappy ou Zstandard, e uma consulta que lê 3 de 50 colunas varre só a fração correspondente. A diferença de custo entre varrer 1 TB e varrer 6 GB, repetida milhares de vezes por mês, é a diferença entre uma fatura de nuvem saudável e uma reunião difícil com o CFO.

9.6 Particionamento, clustering e compressão

Particionamento é dividir fisicamente a tabela por valores de uma coluna (tipicamente data), de modo que consultas filtradas leiam apenas as partições relevantes — o partition pruning. É a otimização de maior impacto e menor esforço em analytics.

O erro clássico: particionar por uma coluna de alta cardinalidade (por exemplo, id_cliente) gera milhões de diretórios com arquivos minúsculos e piora tudo. O alvo prático é partição com arquivos entre 128 MB e 1 GB.

Clustering / Z-Ordering / Liquid Clustering ordena os dados dentro dos arquivos por colunas frequentemente filtradas, permitindo pular blocos inteiros com base em estatísticas de mínimo e máximo. Complementa o particionamento e resolve o caso de colunas de alta cardinalidade que não podem virar partição.

Compressão — na prática: Snappy é o padrão equilibrado (rápido, compressão média); Zstandard (zstd) virou a melhor escolha geral, com compressão melhor e velocidade competitiva; gzip comprime mais mas é lento; LZ4 é o mais rápido, para dados quentes.

9.7 Transações, versionamento, Time Travel e linhagem

Transação é um conjunto de operações tratado como unidade indivisível. Em armazenamento de objetos, isso é simulado pelo log de transações do formato de tabela — o que explica por que Delta, Iceberg e Hudi existem.

Versionamento é manter o histórico de estados de uma tabela. Em formatos de tabela, cada operação de escrita cria uma nova versão, sem apagar a anterior imediatamente.

Time Travel é a capacidade de consultar a tabela como ela estava em uma versão ou instante anteriores:

-- Delta Lake
SELECT * FROM vendas VERSION AS OF 42;
SELECT * FROM vendas TIMESTAMP AS OF '2026-07-01 00:00:00';

-- Iceberg
SELECT * FROM vendas FOR SYSTEM_TIME AS OF '2026-07-01 00:00:00';

-- Snowflake
SELECT * FROM vendas AT(OFFSET => -3600);

Para que serve, concretamente: recuperar de um UPDATE sem WHERE (acontece); reproduzir exatamente o conjunto de treino de um modelo que precisa ser auditado; comparar o antes e o depois de uma carga; provar a um regulador qual era o dado no momento de uma decisão. Uma advertência operacional: time travel tem custo de armazenamento e prazo de retenção. Depois do VACUUM, os arquivos antigos somem. Retenção é decisão de negócio, não configuração padrão.

Data Lineage (linhagem) é o mapa de origem e destino de cada dado: de qual sistema veio, por quais transformações passou, quais tabelas alimenta, quais dashboards e modelos dependem dele. Serve para análise de impacto (“se eu mudar esta coluna, o que quebra?”), diagnóstico de erro (“por que este número está errado?”) e conformidade (“onde estão todos os dados deste titular?”).

Sem linhagem, atender a um pedido de eliminação de dados pessoais vira uma investigação artesanal por dezenas de sistemas. Com linhagem automatizada, vira uma consulta. Isso é governança gerando eficiência operacional — não apenas evitando multa.

Tecnologias. Unity Catalog, OpenLineage (padrão aberto), Marquez, DataHub, dbt (linhagem no nível de modelo), Apache Atlas, Collibra.

10 Parte VII — Comparações lado a lado

10.1 OLTP × OLAP

10.2 SQL × NoSQL

Duas observações que evitam decisões ruins. Primeira: os bancos distributed SQL (Spanner, CockroachDB, YugabyteDB) tornaram falsa a dicotomia “ou ACID ou escala horizontal”. Segunda: PostgreSQL com JSONB cobre boa parte dos casos que motivam a adoção de um banco de documentos, sem abrir mão de transações e joins. A escolha por NoSQL deve ser justificada por um requisito concreto, não pela expectativa de uma escala que talvez nunca chegue.

10.3 Data Warehouse × Data Lake

10.4 Data Lake × Delta Lake × Lakehouse

10.5 Object Storage × HDFS

10.6 Relacional × Grafo

11 Parte VIII — Como isso se encaixa: um fluxo de referência

Nenhuma dessas tecnologias vive isolada. O desenho abaixo é a arquitetura que mais encontro em organizações de porte médio e grande em 2026.

┌──────────────────────────────────────────────────────────────┐
│ 1. ORIGENS                                                   │
│    Aplicações (OLTP) · SaaS/APIs · IoT e sensores ·          │
│    Logs e cliques · Arquivos e planilhas                     │
└───────────────┬──────────────────────────────────────────────┘
                │  CDC (Debezium) · eventos · batch · APIs
                ▼
┌──────────────────────────────────────────────────────────────┐
│ 2. TRANSPORTE E BUFFER                                       │
│    Apache Kafka / Pulsar / Kinesis  (+ Schema Registry)      │
│    Desacopla produtor e consumidor; permite reprocessar      │
└───────────────┬──────────────────────────────────────────────┘
                │  Spark Structured Streaming · Flink
                ▼
┌──────────────────────────────────────────────────────────────┐
│ 3. LAKEHOUSE sobre OBJECT STORAGE (S3 / ADLS / GCS)          │
│    Formato de tabela aberto: Delta · Iceberg · Hudi          │
│                                                              │
│    🥉 BRONZE  dado bruto, imutável, fiel à origem            │
│    🥈 PRATA   limpo, deduplicado, conformado, com qualidade  │
│    🥇 OURO    agregado por domínio de negócio, pronto p/ uso  │
└──────┬────────────────────┬──────────────────┬───────────────┘
       │                    │                  │
       ▼                    ▼                  ▼
┌─────────────┐   ┌──────────────────┐   ┌──────────────────────┐
│ 4. BI e DW  │   │ 5. IA e ML       │   │ 6. APLICAÇÕES        │
│ Power BI    │   │ Feature Store    │   │ APIs e produtos      │
│ Tableau     │   │ Vector DB (RAG)  │   │ Cache (Redis)        │
│ Looker      │   │ Model Registry   │   │ OLTP de volta ao app │
│ Camada      │   │ Notebooks        │   │ (reverse ETL)        │
│ semântica   │   │                  │   │                      │
└─────────────┘   └──────────────────┘   └──────────────────────┘

        ═══════ CAMADAS TRANSVERSAIS (não opcionais) ═══════
        Catálogo e governança · Linhagem · Qualidade como código
        Orquestração (Airflow/Dagster) · Observabilidade · FinOps

O papel de cada componente, em uma linha:

Uma nota de honestidade sobre este desenho. Ele é uma referência, não uma prescrição. Uma empresa com 5 TB e 20 fontes não precisa de Kafka, Flink, Feature Store e banco vetorial. Precisa de um Postgres bem cuidado, um DW simples, dbt e um catálogo leve. Já vi mais valor destruído por arquitetura ambiciosa demais do que por arquitetura simples demais — a segunda dói e se corrige; a primeira consome anos e orçamento antes de alguém admitir.

12 Qual tecnologia devo escolher?

12.1 Árvore de decisão

COMECE AQUI: qual é a natureza da sua carga?

├── (1) É TRANSACIONAL? (o sistema que roda o negócio, escreve e lê o estado atual)
│    │
│    ├── Preciso de integridade forte e relacionamentos?  ──▶ BANCO RELACIONAL
│    │                                                        PostgreSQL · Oracle · SQL Server
│    │    └── ...e também escala horizontal global?       ──▶ DISTRIBUTED SQL
│    │                                                        Spanner · CockroachDB · Yugabyte
│    ├── Acesso é sempre por chave, latência mínima?      ──▶ KEY-VALUE
│    │                                                        Redis · DynamoDB
│    ├── Documentos aninhados, esquema instável?          ──▶ DOCUMENT DB (ou Postgres JSONB)
│    │                                                        MongoDB · Cosmos DB
│    ├── Escrita massiva, multirregião, esquema esparso?  ──▶ WIDE COLUMN
│    │                                                        Cassandra · ScyllaDB · Bigtable
│    └── A pergunta é sobre RELACIONAMENTOS profundos?    ──▶ GRAPH DB
│                                                             Neo4j · Neptune · TigerGraph
│
├── (2) É ANALÍTICA? (entender o negócio, agregar, historiar)
│    │
│    ├── Só dados estruturados, foco em BI, < 50 TB?      ──▶ DATA WAREHOUSE
│    │                                                        Snowflake · BigQuery · Redshift
│    ├── Dados variados, BI + ML, escala grande?          ──▶ LAKEHOUSE
│    │                                                        Databricks · Fabric · Iceberg+Trino
│    ├── Latência de milissegundos p/ milhares de users?  ──▶ OLAP TEMPO REAL
│    │                                                        ClickHouse · Druid · Pinot · StarRocks
│    ├── Escopo de uma área, entrega rápida?              ──▶ DATA MART (sobre DW/Lakehouse)
│    └── Menos de alguns TB e time pequeno?               ──▶ POSTGRES + dbt, ou DuckDB
│                                                             (sim, isso resolve — e é barato)
│
├── (3) É ARMAZENAMENTO BRUTO? (arquivos, mídia, backup, retenção)
│    │
│    ├── Nuvem, elástico, qualquer volume?                ──▶ OBJECT STORAGE
│    │                                                        S3 · ADLS Gen2 · GCS · MinIO
│    └── On-premises, soberania ou HPC?                   ──▶ DFS
│                                                             HDFS · Ceph · Lustre
│
├── (4) É TEMPO REAL / EVENTOS?
│    │
│    ├── Integrar sistemas, reprocessar, alta vazão?      ──▶ STREAMING STORAGE
│    │                                                        Kafka · Pulsar · Kinesis · Redpanda
│    ├── O histórico de eventos É o sistema de registro?  ──▶ EVENT STORE
│    │                                                        EventStoreDB · Axon · Marten
│    └── Métricas indexadas por tempo, sensores, IoT?     ──▶ TIME SERIES DB
│                                                             TimescaleDB · InfluxDB · Prometheus
│
├── (5) É INTELIGÊNCIA ARTIFICIAL?
│    │
│    ├── Busca semântica, RAG, memória de agente?         ──▶ VECTOR DB
│    │    ├── < ~5 milhões de vetores?                    ──▶ pgvector (use o Postgres que já existe)
│    │    ├── Filtro pesado + baixa latência?             ──▶ Qdrant
│    │    └── Bilhões de vetores?                         ──▶ Milvus · Zilliz · Pinecone
│    ├── Muitos modelos e times compartilhando variáveis? ──▶ FEATURE STORE
│    │                                                        Feast · Tecton · Databricks FS
│    └── Poucos modelos batch?                            ──▶ Tabela no Lakehouse. Não complique.
│
└── (6) É ACELERAÇÃO DE LEITURA?                          ──▶ CACHE DISTRIBUÍDO
                                                              Redis · Valkey · Memcached

12.2 Cinco perguntas que valem mais que a árvore

Antes de escolher qualquer tecnologia, respondo (ou peço ao time que responda) a estas cinco perguntas. Elas eliminam a maior parte das más decisões:

1. Qual pergunta de negócio isso responde, e quem decide com base nela? Se não há resposta clara, o projeto é sobre tecnologia, não sobre valor.
2. Qual o volume real hoje e a projeção honesta para 24 meses? Não a projeção do slide de investimento — a honesta.
3. Qual latência é aceitável, e quem sofre se ela não for atingida? Tempo real custa caro; muita coisa que se pede em “tempo real” tolera 15 minutos.
4. Quem é o dono do dado, e quem responde quando ele estiver errado? Se a resposta é “o time de dados”, você não tem dono, tem depósito.
5. Há dados pessoais? Como eu apago, mascaro e explico o uso deles? Se a resposta só vier depois da implementação, ela virá com um incidente junto.

Repare que quatro das cinco perguntas não são técnicas.

13 Cenários reais por setor

13.1 E-commerce

13.2 Instituição financeira

Aqui a arquitetura não é neutra. Se um cliente tem crédito negado por um modelo, ele tem direito a explicação, e a empresa tem obrigação de auditar viés. Isso só é possível se a arquitetura preserva, com precisão temporal, quais dados alimentaram aquela decisão — o que significa Feature Store, versionamento e linhagem. Sem isso, a explicação ao cliente é uma reconstrução aproximada, e a resposta ao regulador também.

13.3 Hospital e saúde

Dado de saúde é dado sensível pela LGPD, e a Resolução CFM 2.454/2026 estabeleceu obrigações específicas de rastreabilidade e auditabilidade para IA em medicina. Arquitetura em saúde precisa nascer com criptografia, segregação por finalidade, log de acesso por registro e prazo de retenção definido. Não é excesso de zelo: é o mínimo diante do que está em jogo.

13.4 Indústria e IoT

13.5 Marketing e mídia

Um ponto que considero incontornável neste setor: personalização em escala é a área em que a fronteira entre conveniência e vigilância é mais tênue. A arquitetura registra a finalidade de coleta e o consentimento? Se o titular revoga, o efeito se propaga em quantos minutos e para quantos sistemas? Se essas respostas não existem no desenho, existe um problema — mesmo que ninguém tenha reclamado ainda.

13.6 Telecom

13.7 Streaming de vídeo

14 Os erros mais caros — e o que eles custam de verdade

Esta seção é escrita para quem aprova orçamento. Cada item abaixo eu já vi custar dinheiro, tempo ou credibilidade.

1. Achar que Data Lake substitui banco de dados. São coisas de naturezas diferentes. O lago não tem transações, não tem baixa latência, não tem integridade referencial. Custo típico: meses de retrabalho e um sistema em produção com comportamento imprevisível.

2. Usar Data Warehouse como repositório de arquivos. Guardar PDFs, imagens e blobs em DW custa entre 10 e 100 vezes mais do que em armazenamento de objetos, e o DW não faz nada de útil com eles. Custo típico: fatura mensal inflada de forma silenciosa e permanente.

3. Usar banco relacional convencional para busca por embeddings. Sem índice vetorial, a busca vira varredura completa com cálculo de distância linha a linha. Solução barata: CREATE EXTENSION vector; no Postgres que você já tem.

4. Armazenar imagens e vídeos em colunas BLOB de banco SQL. Infla backups, degrada replicação, encarece storage transacional. O padrão correto: arquivo no object storage, caminho e metadados no banco.

5. Tratar governança como fase final do projeto. Governança retroativa custa entre 5 e 10 vezes mais do que governança desde o início — e nem sempre é possível recuperar contexto de dado ingerido há dois anos sem documentação. Custo típico: risco regulatório e perda de confiança nos números.

6. Escolher a arquitetura pela escala que você gostaria de ter. Kafka, Spark, Flink, mesh e feature store para 200 GB de dados é overhead puro. A pergunta certa não é “o que o Google usa?”, é “o que o meu problema exige?”.

7. Não gerenciar o problema dos arquivos pequenos. Milhões de arquivos de poucos KB destroem a performance de qualquer engine analítica. Compactação (OPTIMIZE) precisa ser rotina agendada, não intervenção heroica quando alguém reclama.

8. Particionar por coluna de alta cardinalidade. Particionar por id_cliente ou por timestamp com precisão de segundo cria milhões de diretórios e degrada tudo. Particione por dia ou mês; use clustering para o resto.

9. Confundir Kafka com banco de dados. Kafka é log de transporte, não repositório consultável. Se você precisa responder “qual o estado atual do pedido 123”, precisa de uma projeção materializada.

10. Ignorar egress e custo de varredura. Em nuvem, mover dados entre regiões e provedores custa caro, e varredura repetida de tabelas não particionadas é a principal causa de surpresa na fatura. Recomendação de gestão: peça ao time o custo por consulta dos dez dashboards mais acessados. A resposta costuma ser reveladora.

11. Adotar Data Mesh como reorganização de organograma. Sem plataforma de autosserviço e sem governança computacional, mesh vira descentralização sem rede de proteção — e a qualidade cai antes que alguém perceba.

12. Esquecer o cache e as réplicas no inventário de dados pessoais. O mapeamento de LGPD cobre o banco principal e ignora Redis, réplicas, backups e o data lake. Se o dado do titular está lá, a obrigação também está.

13. Duplicar a mesma informação em cinco repositórios sem definir a fonte de verdade. É assim que se chega à reunião em que cada área tem um número diferente de receita. O problema não é técnico: é ausência de propriedade definida.

14. Comprar plataforma antes de definir o problema. A ferramenta é a parte fácil e a parte cara. A parte difícil — definição de domínios, donos, métricas e contratos — nenhum fornecedor entrega junto com a licença.

15 Tendências que importam em 2026

Formatos abertos venceram; a disputa migrou para o catálogo. O Iceberg se consolidou como padrão de interoperabilidade, e todos os grandes provedores leem e escrevem o formato. A consequência estratégica: o ponto de aprisionamento deixou de ser o formato e passou a ser o serviço que gerencia metadados, permissões e linhagem.³² Em negociação de contrato, a pergunta certa é sobre portabilidade de metadados, não sobre suporte a formato.

Convergência de metadados entre Delta e Iceberg. Com a proposta de estrutura de metadados compartilhada entre Iceberg v4 e Delta 5.0, o cenário caminha para que a escolha entre os dois deixe de ser estratégica e passe a ser detalhe de implementação.³³

Dados como produto saindo do discurso. Contratos de dados formais (esquema, SLA, qualidade, dono, versionamento) estão virando prática concreta, com padrões abertos como o Open Data Contract Standard. É a parte do Data Mesh que sobreviveu ao ciclo de hype — e, na minha leitura, a mais valiosa.

IA generativa como consumidora de primeira classe. RAG deixou de ser experimento e virou carga de produção. Isso trouxe exigências novas para a camada de dados: chunking e versionamento de documentos, controle de acesso propagado até o resultado da busca (um modelo não pode recuperar um documento que o usuário não poderia abrir), e custo de reindexação a cada troca de modelo de embedding.

Agentes de IA multiplicando o volume de consultas. Agentes autônomos consultam bases com frequência muito superior à de usuários humanos, o que mudou os requisitos de latência, cota e custo. Também abriu uma questão de governança nova e ainda mal resolvida: quem responde pelo que um agente consultou, inferiu e decidiu? Log de acesso por agente, com identidade própria e propósito declarado, está deixando de ser refinamento e virando requisito.

Dados multimodais. Texto, imagem, áudio e vídeo no mesmo espaço vetorial ampliaram muito o que se pode fazer — e ampliaram na mesma medida o risco. Buscar pessoas por semelhança facial em um acervo é tecnicamente trivial hoje. Que essa capacidade exista não significa que qualquer uso dela seja legítimo, e essa distinção precisa estar na arquitetura (controles de finalidade, segregação, log), não apenas no código de conduta.

Postgres como plataforma. Uma tendência silenciosa e economicamente relevante: com extensões (pgvector, TimescaleDB, PostGIS, AGE, Citus), o PostgreSQL cobre casos que antes exigiam quatro bancos distintos. Para a maior parte das empresas, isso significa menos peças, menos equipe especializada e menos fatura.

FinOps de dados como disciplina. Com custo de computação atrelado a consumo, a eficiência da consulta virou item de orçamento. Times maduros hoje monitoram custo por dashboard, por pipeline e por produto de dados — e isso muda comportamento mais rápido do que qualquer política escrita.

16 Conclusão: escolher bem é uma decisão sobre pessoas

Se este guia inteiro precisasse caber em um parágrafo, seria este: não existe tecnologia melhor, existe tecnologia adequada ao problema, ao volume, à latência exigida, ao orçamento e à maturidade do time. Bancos relacionais para o que precisa de integridade. Armazenamento de objetos para o que precisa ser barato e volumoso. Lakehouse para unificar analytics e IA sem duplicar dados. NoSQL quando o padrão de acesso justifica. Vetorial quando a pergunta é sobre significado. Streaming quando o tempo importa de verdade. E, com muito mais frequência do que o mercado admite, um PostgreSQL bem cuidado e um dbt organizado.

Mas há uma camada que atravessa todas as decisões deste texto e que quero deixar por último, porque é a que mais me importa.

Cada uma dessas tecnologias guarda, no fim, informação sobre pessoas. O prontuário que decide um tratamento. O histórico que decide um crédito. O perfil que decide qual oportunidade alguém vê e qual não vê. Quando escolhemos onde e como armazenar, estamos decidindo quem consegue acessar, por quanto tempo, com qual rastreabilidade e com que possibilidade de correção. Estamos decidindo se será possível, daqui a dois anos, explicar a uma pessoa por que um sistema decidiu o que decidiu sobre a vida dela.

Isso não é retórica anexada ao final de um texto técnico. É a razão pela qual linhagem, versionamento, catálogo, controle de acesso e time travel aparecem em cada seção deste guia. Eles não são funcionalidades avançadas para times maduros. São o que torna possível a prestação de contas — e prestação de contas é, na prática, a forma técnica de respeito.

A boa notícia é que, na maioria dos casos, a arquitetura que respeita as pessoas coincide com a arquitetura que funciona melhor. Dado com dono, documentado, versionado e rastreável é mais barato de operar, mais confiável para decidir e mais fácil de auditar. Ética e engenharia, aqui, apontam para o mesmo lado.

E, se você chegou até aqui: qual dessas decisões de arquitetura você tomaria diferente hoje, sabendo o que sabe agora? Essa costuma ser a conversa mais produtiva que um time de dados pode ter.

17 Material complementar

17.1 Tabela-resumo de todos os tipos de armazenamento

17.2 Matriz de decisão: quando usar e quando não usar

17.3 Glossário

ACID — Atomicidade, Consistência, Isolamento e Durabilidade; conjunto de garantias transacionais. Analytics Engineer — profissional que transforma dado bruto em modelos analíticos confiáveis, tipicamente com SQL e dbt. Avro — formato binário orientado a linha, com esquema embutido e evolução controlada; padrão em streaming. BASE — Basically Available, Soft state, Eventual consistency; modelo de consistência de sistemas distribuídos. Bronze / Prata / Ouro — camadas da arquitetura medallion: bruto, tratado e agregado para consumo. CAP (teorema) — sob partição de rede, um sistema distribuído escolhe entre consistência e disponibilidade. CDC (Change Data Capture) — captura incremental de mudanças de um banco, geralmente via log de transações. Colunar — armazenamento por coluna, que permite ler apenas os campos usados na consulta. Contrato de dados — acordo formal entre produtor e consumidor sobre esquema, qualidade, SLA e versionamento. Data Catalog — camada de descoberta, documentação e confiança sobre os metadados. Data Fabric — camada tecnológica que unifica acesso e governança sobre fontes distribuídas. Data Hub — ponto central de mediação e troca de dados entre sistemas. Data Lake — repositório de dados brutos em armazenamento de objetos, com schema-on-read. Data Mart — recorte analítico de um domínio ou área. Data Mesh — abordagem sociotécnica de descentralização por domínios, com dados tratados como produto. Data Product — conjunto de dados com dono, SLA, documentação, qualidade e consumidores definidos. Data Swamp — data lake sem catálogo, qualidade ou propriedade; dado inutilizável na prática. Data Warehouse — repositório analítico integrado, histórico e curado. Deletion Vector — técnica que marca linhas excluídas sem reescrever o arquivo inteiro. Delta Lake — formato de tabela aberto com ACID e time travel sobre Parquet. dbt — ferramenta que trata transformações SQL como código versionado, testado e documentado. Embedding — vetor numérico que representa o significado de um conteúdo. ELT / ETL — extrair-carregar-transformar / extrair-transformar-carregar. Event Sourcing — padrão em que o estado é derivado da sequência completa de eventos. Feature Store — repositório de variáveis de modelos, com consistência entre treino e inferência. GraphRAG — RAG que usa grafo de conhecimento para recuperar contexto estruturado. HNSW — índice de grafo hierárquico para busca aproximada de vizinhos mais próximos. Iceberg (Apache) — formato de tabela aberto, padrão de interoperabilidade do mercado. Lakehouse — arquitetura que une o custo do lago às garantias do armazém. Linhagem (lineage) — rastreamento da origem, transformações e destinos de um dado. LSM-tree — estrutura otimizada para escrita, base de Cassandra, RocksDB e Paimon. Medallion — organização em camadas bronze, prata e ouro. Metadado — dado sobre o dado: esquema, dono, qualidade, linhagem, política. MPP — Massively Parallel Processing; execução distribuída entre muitos nós. MVCC — controle de concorrência multiversão, usado pelo PostgreSQL e outros. ODS — Operational Data Store; visão integrada e atual de dados operacionais. OLAP / OLTP — processamento analítico / processamento transacional. ORC — formato colunar do ecossistema Hive, com forte compressão. Parquet — formato colunar aberto, padrão de facto para analytics. Particionamento — divisão física da tabela por valores de coluna, permitindo pular dados na leitura. pgvector — extensão do PostgreSQL para armazenamento e busca de embeddings. Point-in-time correctness — junção que respeita o instante em que o dado estaria disponível, evitando vazamento temporal. Quantização — redução da precisão de vetores para economizar memória, com perda controlada de recall. RAG — Retrieval-Augmented Generation; recuperar contexto relevante antes de gerar a resposta. Schema-on-read / on-write — esquema aplicado na leitura / na escrita. Schema Registry — repositório central de esquemas de eventos, com regras de compatibilidade. SCD — Slowly Changing Dimension; técnica de historização em modelagem dimensional. Sharding — particionamento horizontal de dados entre servidores. Time Travel — consulta a uma versão anterior da tabela. Training-serving skew — divergência entre a feature usada no treino e a usada em produção. Vacuum / Optimize — rotinas de limpeza de versões antigas e compactação de arquivos pequenos. Z-Ordering / Liquid Clustering — ordenação multidimensional dos dados para melhorar o data skipping.

17.4 Documentação oficial e leitura recomendada

Formatos de tabela e Lakehouse

• Apache Iceberg — documentação oficial · especificação
• Delta Lake — documentação oficial · protocolo
• Apache Hudi — documentação oficial
• Apache Paimon
• Databricks — What is a Data Lakehouse?
• Microsoft Learn — Fabric e OneLake

Data Warehouse e analytics

• Snowflake — documentação
• Google Cloud — BigQuery
• AWS — Redshift · Well-Architected Data Analytics Lens
• Kimball Group — técnicas de modelagem dimensional
• Oracle — o que é um Data Warehouse
• IBM — Data Warehouse, Data Lake e Lakehouse

Bancos operacionais e NoSQL

• PostgreSQL — documentação · pgvector
• Apache Cassandra · MongoDB · Redis
• Neo4j — documentação · padrão ISO GQL
• Amazon DynamoDB — guia do desenvolvedor

Streaming e eventos

• Apache Kafka — documentação · Apache Pulsar · Apache Flink
• Debezium — documentação

IA, vetores e features

• Feast — documentação · Tecton
• Qdrant · Milvus · Weaviate · Pinecone

Governança e catálogos

• Databricks Unity Catalog · Apache Polaris · Project Nessie
• DataHub · OpenMetadata · OpenLineage
• DAMA-DMBOK — Data Management Body of Knowledge
• ANPD — Autoridade Nacional de Proteção de Dados · LGPD (Lei 13.709/2018)

Livros que continuam valendo a pena

• Martin Kleppmann. Designing Data-Intensive Applications. O’Reilly, 2017. (A referência mais completa sobre os trade-offs discutidos aqui.)
• Joe Reis e Matt Housley. Fundamentals of Data Engineering. O’Reilly, 2022.
• Zhamak Dehghani. Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly, 2022.
• Ralph Kimball e Margy Ross. The Data Warehouse Toolkit, 3ª ed. Wiley, 2013.
• W. H. Inmon. Building the Data Warehouse, 4ª ed. Wiley, 2005.

18 Referências