Sistemas operacionais vs analíticos (DDIA, Cap. 1)
Introdução
Começo a resenha do Designing Data-Intensive Applications pelo capítulo 1, e o livro abre exatamente onde eu também começaria: separando dois trabalhos que parecem o mesmo e não são. Pega o dado de pedidos de uma loja. Quando o cliente finaliza a compra, o sistema grava aquele pedido e lê o estoque para confirmar: poucos registros, por chave, em tempo real. No fim do mês, alguém abre um dashboard e pergunta qual foi o faturamento por loja: isso varre milhões de pedidos e devolve um número. É o mesmo dado, mas as duas perguntas estressam o banco de formas opostas.
Kleppmann e Riccomini chamam esses dois mundos de sistemas operacionais e sistemas analíticos, e tratam essa divisão como o eixo que organiza boa parte do livro. Confundir os dois é a raiz de muito design ruim: bancos modelados para um caso que sofrem no outro, consultas analíticas pesadas derrubando a operação, times que não se entendem porque vivem em lados diferentes dessa linha.
Meu objetivo neste artigo é deixar essa fronteira nítida. Vou mostrar quem usa cada lado, qual é o padrão de acesso de cada um, por que a indústria passou a manter os dois fisicamente separados (o data warehouse e, depois, o data lake) e fechar com uma segunda distinção que o capítulo introduz e que ajuda a pensar o fluxo de dados: system of record contra dado derivado.
Dois tipos de sistema, dois tipos de gente
O livro parte de uma observação prática: numa empresa, gente diferente mexe com o dado de jeito diferente. De um lado estão os engenheiros de backend, que constroem serviços para ler e atualizar dados a pedido dos usuários. Do outro estão os analistas de negócio, que geram relatórios para a gestão decidir (business intelligence), e os cientistas de dados, que procuram padrões novos e criam recursos baseados em análise e machine learning, como a recomendação de "quem comprou X também comprou Y".
Analistas e cientistas de dados usam ferramentas distintas, mas têm duas práticas em comum. Os dois fazem análise, ou seja, olham para o dado que os usuários e os serviços já geraram. E os dois, em geral, não modificam esse dado, embora possam criar conjuntos derivados a partir dele. Isso leva à divisão central do capítulo:
- Sistemas operacionais são os serviços de backend e a infraestrutura onde o dado nasce, por exemplo ao atender um usuário. Aqui o código lê e modifica o dado conforme as ações das pessoas.
- Sistemas analíticos servem analistas e cientistas de dados. Contêm uma cópia somente-leitura do dado vindo dos sistemas operacionais e são otimizados para o tipo de processamento que a análise exige.
Os autores notam que, conforme esses sistemas amadureceram, surgiram dois papéis novos: o engenheiro de dados, que integra o lado operacional ao analítico e cuida da infraestrutura de dados como um todo, e o analytics engineer, que modela e transforma o dado para deixá-lo útil aos analistas. Vale guardar isso, porque o resto do livro cobre os dois lados de propósito, e entender essa estrutura de papéis ajuda a saber de quem é cada problema.
OLTP: o padrão de acesso da operação
No começo do processamento de dados de negócio, uma escrita no banco quase sempre correspondia a uma transação comercial: uma venda, um pedido a um fornecedor, o pagamento de um salário. Mesmo quando os bancos passaram a guardar coisas sem dinheiro envolvido (posts, jogadas de um jogo, contatos), o termo transação ficou, agora no sentido de um grupo de leituras e escritas que forma uma unidade lógica. O capítulo usa "transação" de forma solta para se referir a leituras e escritas de baixa latência, e deixa o aprofundamento para o capítulo 8.
O padrão de acesso desse mundo se manteve parecido com o de processar transações comerciais. Um sistema operacional costuma buscar um número pequeno de registros por uma chave, o que o livro chama de point query, e insere, atualiza ou remove registros conforme a entrada do usuário. Como essas aplicações são interativas, esse padrão ficou conhecido como online transaction processing, o OLTP.
Um detalhe importante de design: em sistemas operacionais, normalmente não se deixa o usuário escrever SQL arbitrário. Primeiro por segurança, já que ele poderia ler ou alterar dado fora da sua permissão. Segundo por performance, porque uma consulta mal feita pode pesar e afetar os outros usuários. Por isso o OLTP roda um conjunto fixo de consultas, embutidas no código da aplicação, e consultas avulsas só aparecem de vez em quando para manutenção. A escolha do banco aqui caminha junto com a modelagem, assunto que retomo em Banco SQL vs NoSQL.
Analytics: varrer muito e agregar
A consulta analítica é o oposto. Em vez de pegar poucos registros por chave, ela varre um número enorme de registros e calcula estatísticas agregadas, como contagem, soma ou média, sem devolver os registros individuais. O livro dá exemplos de um analista de uma rede de supermercados: qual foi o faturamento total de cada loja em janeiro, quantas bananas a mais que o normal foram vendidas na última promoção, qual marca de comida de bebê é mais comprada junto com a fralda da marca X. Esse padrão ganhou o nome de online analytical processing, o OLAP.
Aqui a liberdade é a regra. O analista escreve SQL arbitrário à mão ou gera consultas por uma ferramenta de visualização como Tableau, Looker ou Power BI. A diferença entre OLTP e analytics nem sempre é nítida, mas dá para resumir as características típicas que o livro organiza:
| Propriedade | Operacional (OLTP) | Analítico (OLAP) |
|---|---|---|
| Leitura | Point query, busca por chave | Agregação sobre muitos registros |
| Escrita | Cria/atualiza/remove registros individuais | Carga em lote (ETL) ou stream de eventos |
| Tipo de consulta | Fixa, definida pela aplicação | Arbitrária, exploração ad-hoc |
| Volume | Muitas consultas pequenas | Poucas consultas, cada uma complexa |
| O dado representa | Estado mais recente (agora) | Histórico de eventos ao longo do tempo |
| Tamanho | Gigabytes a terabytes | Terabytes a petabytes |
Em SQL, a diferença salta aos olhos. A consulta operacional pega uma linha:
-- OLTP: point query, busca um pedido pela chave
SELECT * FROM pedidos WHERE id = 84213;
A consulta analítica varre o histórico inteiro para condensar num número:
-- OLAP: varre milhões de linhas e agrega
SELECT loja_id, SUM(valor) AS faturamento
FROM pedidos
WHERE data >= '2025-01-01' AND data < '2025-02-01'
GROUP BY loja_id;
Vale notar uma terceira categoria que o livro cita: sistemas pensados para carga analítica, mas embutidos em produtos voltados ao usuário, chamados de product analytics ou real-time analytics, como Pinot, Druid e ClickHouse. Eles ingerem dados em tempo real e otimizam para resposta de baixa latência, enquanto o OLAP tradicional ingere em lotes e otimiza para vazão.
Por que separar: o data warehouse
No início, o mesmo banco servia transação e análise, e o SQL se mostrou flexível o bastante para os dois. Mas no fim dos anos 80 e começo dos 90 surgiu a prática de parar de rodar análise no sistema OLTP e mover isso para um banco separado, o data warehouse. O livro lista os motivos de não deixar analistas consultando os bancos operacionais direto, e cada um é um problema real de produção:
- O dado de interesse costuma estar espalhado por vários sistemas operacionais, o que dificulta combiná-los numa consulta só. É o problema dos data silos.
- O esquema bom para OLTP é ruim para análise, assunto que volta no capítulo 4 e nos esquemas estrela e floco de neve.
- Consultas analíticas são caras e, rodando no banco operacional, prejudicam a performance dos outros usuários.
- Os sistemas OLTP podem estar numa rede separada, sem acesso direto, por segurança ou compliance.
O data warehouse, por contraste, é um banco separado que o analista consulta à vontade sem afetar a operação. Ele guarda uma cópia somente-leitura do dado de todos os sistemas OLTP da empresa. O dado é extraído dos bancos operacionais, transformado num esquema amigável à análise, limpo e carregado no warehouse. Esse processo é o extract-transform-load, o ETL. Às vezes a ordem se inverte, transformando depois de carregar, e vira ELT. O warehouse, como mostro em Armazenamento para analytics: colunar, guarda o dado de um jeito bem diferente do OLTP justamente para otimizar essas varreduras.
O livro também observa que existem sistemas híbridos, o HTAP (hybrid transactional/analytical processing), que tentam fazer os dois num só sem ETL. Mas, na prática, muitos HTAP por dentro são um sistema OLTP acoplado a um analítico atrás de uma interface comum, então a distinção continua valendo para entender como funcionam. E mesmo onde HTAP existe, a separação costuma se manter, porque a boa prática de cada serviço operacional ter seu próprio banco leva a centenas de bancos operacionais, enquanto a empresa costuma ter um único warehouse onde dá para cruzar tudo.
Do warehouse ao data lake
O warehouse costuma usar modelo relacional e SQL, o que serve bem ao analista de BI, mas atende mal o cientista de dados. Tarefas como transformar linhas e colunas num vetor de features para treinar um modelo, ou extrair informação estruturada de texto e imagem com NLP e visão computacional, pedem código que é difícil de expressar em SQL. Por isso muitos cientistas de dados preferem trabalhar fora do banco relacional, com Pandas, scikit-learn, R e Spark.
A resposta a essa necessidade é o data lake: um repositório centralizado que guarda uma cópia de qualquer dado que possa ser útil para análise, vindo dos sistemas operacionais via ETL. A diferença para o warehouse é que o lake só contém arquivos, sem impor formato, modelo ou esquema. Os arquivos podem ser registros codificados em Avro ou Parquet, mas também texto, imagens, vídeo, leituras de sensor. Além de mais flexível, o lake costuma ser mais barato, por usar armazenamento de objetos comoditizado. O livro resume a filosofia com o que chama de princípio do sushi: dado cru é melhor, porque cada consumidor transforma o dado bruto na forma que melhor lhe serve.
Os autores ainda apontam dois movimentos recentes. O dado para análise passou a estar disponível também como streams de eventos, o que permite reagir em segundos em vez de reprocessar tudo todo dia, útil por exemplo para barrar fraude. E, em alguns casos, a saída do sistema analítico volta para o operacional, num processo apelidado de reverse ETL, como um modelo de ML treinado no analítico que é colocado em produção para gerar recomendações ao usuário final.
System of record e dado derivado
Ligada à divisão operacional contra analítico, o capítulo introduz uma segunda distinção que eu acho ainda mais útil no dia a dia, porque ela esclarece o fluxo do dado pelo sistema: system of record contra dado derivado.
O system of record, também chamado de fonte da verdade, guarda a versão autoritativa do dado. Quando um dado novo chega, por exemplo via input do usuário, ele é escrito aqui primeiro. Cada fato é representado exatamente uma vez, em geral de forma normalizada. Se houver divergência entre outro sistema e o system of record, por definição quem está certo é o system of record.
O dado derivado é o resultado de pegar um dado de outro sistema e transformá-lo de alguma forma. Se você perde o dado derivado, dá para recriá-lo a partir da fonte. O exemplo clássico é o cache: você serve do cache quando ele tem o que precisa e, quando não tem, cai de volta no banco original. Valores desnormalizados, índices, materialized views e modelos treinados sobre um conjunto também entram nessa categoria.
Tecnicamente, dado derivado é redundante, já que duplica informação que existe na fonte. Mas essa redundância costuma ser essencial para ter boa performance de leitura, e de uma única fonte dá para derivar vários conjuntos, cada um servindo a uma forma de olhar o dado. Os sistemas analíticos, em geral, são sistemas de dado derivado, porque consomem dado criado em outro lugar. Um serviço operacional costuma misturar os dois: o banco primário onde o dado é escrito primeiro é o system of record, e os índices e caches que aceleram a leitura são derivados.
O ponto que eu mais carrego desta seção é que isso não é propriedade da ferramenta. Um banco é só um banco; ser system of record ou derivado depende de como você o usa na aplicação. Deixar claro qual dado deriva de qual traz ordem a uma arquitetura que, sem isso, vira um emaranhado confuso. E há uma consequência operacional: quando um dado é derivado de outro, você precisa de um processo para atualizar o derivado sempre que a fonte muda. Muitos bancos assumem que você vai usar só aquele banco e não facilitam integrar vários sistemas para propagar essas mudanças, problema que o livro retoma no capítulo 11 com pipelines de dados.
Conclusão
O capítulo 1 entrega duas réguas que valem para o livro inteiro e para quase todo projeto. A primeira separa onde o dado nasce e é modificado (operacional, OLTP) de onde ele é lido em massa para decidir (analítico, OLAP), e explica por que a indústria os mantém em sistemas separados, do data warehouse ao data lake. A segunda separa a fonte da verdade (system of record) do que pode ser reconstruído a partir dela (dado derivado).
O gatilho que eu uso, antes de escolher banco ou modelar qualquer coisa, são duas perguntas. Primeira: esse caminho cria dado novo ou consome dado já criado em outro lugar? Segunda: esse dado é a fonte da verdade ou dá para reconstruí-lo se sumir? A resposta da primeira já diz se eu estou no lado operacional ou analítico, e me impede de jogar carga de varredura em cima de um banco de point query. A resposta da segunda diz o que eu posso tratar como cache ou índice descartável, e o que eu nunca posso perder. Quando essas duas ficam claras desde o começo, metade das decisões de arquitetura de dados para de ser chute.
Referências
- Kleppmann, M.; Riccomini, C. Designing Data-Intensive Applications, 2ª edição. O'Reilly Media, 2025. Capítulo 1 ("Trade-Offs in Data Systems Architecture"), seções "Operational Versus Analytical Systems" e "Systems of Record and Derived Data" (págs. 3–11).