A arquitetura dos sistemas de dados modernos está passando por uma mudança fundamental.
Pergunte a um desenvolvedor como eles criam sistemas de dados hoje e a resposta se parece cada vez mais com o seguinte: Postgres para o aplicativo, um lago para a análise e ciência de dados.
O Postgres, favorecido há muito tempo para cargas de trabalho transacionais, evoluiu para um banco de dados operacional de uso geral. É confiável, flexível e profundamente extensível, alimentando tudo, desde transações de clientes e aplicativos CRUD, até painéis em tempo real e recursos de produto apoiados pela IA. Seu ecossistema cresceu para apoiar a análise em tempo real (timescaledb), dados geoespaciais (pós-gis), pesquisa de vetor e texto completo (PGVector e PGVectorScale) e muito mais.
Ao mesmo tempo, a ascensão das tecnologias abertas de Lakehouse redefiniu como as organizações gerenciam e analisam dados em escala. Armazenamento desagregado, formatos de tabela aberta como iceberg, catálogos de dados estruturados e mecanismos de consulta composíveis tornaram possível analisar dados em escala de petabytes com precisão e controle. Essa arquitetura pode oferecer governança, evitar o bloqueio do fornecedor e ainda fornecer flexibilidade às equipes de dados em sua escolha de ferramentas.
O que é impressionante não é apenas o sucesso dessas tecnologias individualmente, mas com que frequência eles estão sendo implantados juntos. As organizações precisam cada vez mais suportar cargas de trabalho operacionais (alimentadas por bancos de dados) e cargas de trabalho não operacionais (alimentadas por lakehouses), geralmente usando dados das mesmas fontes-pessoas, máquinas, sistemas digitais ou agentes. No entanto, esses sistemas ainda são tratados isoladamente, geralmente de propriedade de equipes diferentes, com muito atrito em fazê -los trabalhar juntos sem problemas.
Acreditamos que o atrito não deve existir. De fato, achamos que uma arquitetura nova e mais coerente está surgindo: uma que trata o Postgres e a Lakehouse não como mundos separados, mas como camadas distintas de um único sistema modular, projetado para atender a todo o espectro de necessidades operacionais e analíticas.
Os limites da dicotomia OLTP vs Olap
A maneira antiga de pensar sobre bancos de dados era simples: OLTP para transações, OLAP para análise. Você usou o PostGres para alimentar seu aplicativo e enviou trabalhos noturnos de ETL para um data warehouse para relatórios e painéis internos. Essa distinção tradicional nos serviu bem quando as aplicações eram mais simples, e os relatórios internos poderiam viver com uma cadência muito mais lenta. Mas esse não é mais o caso.
Os aplicativos modernos são pesados de dados, voltados para o cliente e em tempo real por design. Eles embaçam as linhas entre transações e analíticas.
- Um aplicativo financeiro pode administrar um mecanismo de negociação que precisa de acesso de milissegundos a portfólios de clientes, enquanto alimentava simultaneamente relatórios de risco em tempo real e painéis internos.
- Um aplicativo SaaS não está apenas armazenando cliques – ele está calculando métricas de uso, desencadeando alertas e atendendo a modelos personalizados.
- Um sistema de monitoramento industrial pode ingerir dezenas de milhões de leituras de sensores por hora, impulsionar a detecção de anomalias e alertar a lógica e arquivar anos de telemetria para análise de longo prazo e treinamento de modelos de IA.
Esses casos de uso não são outliers – eles estão se tornando rapidamente a norma.
Vemos cada vez mais uma divisão mais útil: bancos de dados operacionais que alimentam produtos e lakes que as organizações de energia.
No entanto, embora a propriedade desses tipos de sistemas seja dividida-as equipes de engenharia de produtos responsáveis pelos sistemas operacionais que alimentam seus produtos e as equipes de dados responsáveis pelo gerenciamento de sistemas Lakehouse como serviços organizacionais-os dois ainda precisam conversar. Eles precisam trabalhar com os mesmos dados e geralmente compartilhar esquemas subjacentes. Quanto melhor eles se integram e permanecem sincronizados, mais resiliente e capaz o sistema se torna.
Uma arquitetura de medalhão operacional
Um padrão que vemos ganhar tração é o que chamamos de Arquitetura de medalhão operacional. Inspirado nos modelos de medalhão popularizados no mundo da engenharia de dados, esse padrão também incorpora camadas de bronze, prata e ouro-não apenas para análises internas, mas também para alimentação de sistemas em tempo real e voltados para o usuário.
Aqui está o que parece:
- Camada de bronze: Os dados brutos vivem em arquivos parquet ou iceberg no AWS S3 ou em sistemas de armazenamento sem fundo de baixo custo. Esses dados são tipicamente imutáveis, somente de anexo e consultáveis por qualquer coisa: motores de consulta como AWS Athena, DuckDB, Trino, Clickhouse ou Polars, ou mesmo diretamente de um banco de dados operacional como o Postgres.
- Camada de prata operacional: Os dados limpos, filtrados, validados e deduplicados são gravados no PostGres para alimentar análises, painéis, painéis ou lógica de aplicativo de produtos voltados para o usuário.
- Camada de ouro operacional: Dados pré-agregados sobre dados de prata (como as vistas materializadas do Postgres ou os agregados contínuos do TimeScaledB) atendem experiências de produtos de baixa latência e alta concorrência. Eles geralmente são mantidos no banco de dados para garantir a consistência entre as camadas de prata e ouro.
Fundamentalmente, cada camada é consultável e esse movimento de dados é bidirecional. Você pode puxar dados brutos ou transformados do S3 diretamente para o Postgres (semelhante ao ETL reverso reverso fortemente integrado). Você pode enrolar agregados do iceberg para as tabelas do Postgres (por consultas únicas ou permanecendo contra arquivos iceberg do Postgres). Você pode sincronizar continuamente um esquema completo ou uma única tabela do banco de dados até a casa Lakehouse.
Assim como os dados de bronze (ou transformados) podem ser lidos da camada de armazenamento Lakehouse no S3 no banco de dados, prata e ouro no banco de dados podem ser gravados nesses formatos de armazenamento de Lakehouse. Isso evita a necessidade de reimplementar pipelines idênticos em ambos os sistemas, o que adiciona complexidade e corre o risco de consistência.
Um padrão comum que observamos em aplicativos que exigem novos dados é escrever de um sistema de streaming a montante como Kafka ou Kinesis em paralelo para os dados S3 (para linha, não modificado de bronze) e Postgres (confiando em esquemas de banco de dados e restrições para validação de dados). Em seguida, essas tabelas de prata e os agregados de ouro subsequentes no banco de dados são exportados para o S3 novamente, para que as equipes de dados agora tenham acesso aos “dados da verdade no fundamento” que foram atendidos aos clientes.
Agora, cada sistema mantém sua separação de preocupações. O banco de dados operacional pode ser travado – tanto para usuários quanto consultas hostis – enquanto os dados ainda são disponibilizados como parte da casa aberta, onde quer que seja necessário na organização.
Por que agora? Forças técnicas que dirigem a mudança
Vários desenvolvimentos estão alimentando essa mudança dos bancos de dados operacionais e Lakehouses de serem isolados para integrados.
Primeiro, o iceberg amadureceu em um formato de tabela estável e flexível que suporta a evolução do esquema, as transações ácidas e a compactação eficiente. Ele permite que vários mecanismos de computação leiam e escrevam para os mesmos conjuntos de dados – com camadas de catálogo que rastreiam metadados e reforçam a governança em toda a pilha. Assim como os bancos de dados tinham catálogos em sua essência, então agora os Lakehouses.
Segundo, o Postgres continuou a evoluir como uma plataforma. Com extensões para armazenamento colunar, dados de séries temporais e pesquisa vetorial e híbrida-o que estamos construindo em escala de tempo há anos-o Postgres agora serve diretamente muitos produtos que incorporam análises em tempo real e fluxos de trabalho agênticos. E com suporte emergente para consultar dados S3 e iceberg diretamente do Postgres, é cada vez mais possível incorporar diretamente dados hospedados em S3. Portanto, o Postgres não é mais apenas para dados transacionais-com ETL/CDC unidirecional para Lakehouse-mas Agora atua como a camada de porção de produtos que incorporam dados transacionais e analíticos. Esta não é apenas uma camada de cache de dados para dados pré-computados, mas um banco de dados SQL completo para agregações adicionais, enriquecimento ou se junta ao tempo de consulta.
Terceiro, os desenvolvedores esperam composibilidade. Algumas organizações podem ficar presas com suas plataformas de dados monolíticas herdadas, mas a maioria dos desenvolvedores e cientistas de dados deseja flexibilidade para compor suas próprias pilhas, integrando ferramentas familiares de maneiras que refletem as necessidades de seus aplicativos. A mudança em direção a formatos abertos e armazenamento desagregado se encaixa nessa mentalidade. O mesmo acontece com o desejo de controle, particularmente em indústrias regulamentadas ou onde a soberania de dados é importante.
Em outras palavras: o mercado está se movendo em direção a arquiteturas modulares, abertas e amigáveis aos desenvolvedores.
O que vem a seguir
Acreditamos que o futuro da infraestrutura de dados será moldado por sistemas que integram as camadas operacionais e analíticas mais profundamente – sistemas que tratam o Postgres e a Lakehouse como dois lados da mesma moeda.
Isso não acontecerá através de outro monólito. Ele virá de interfaces cuidadosas – sincronização incremental, catálogos compartilhados, superfícies unificadas de consultas – e de uma filosofia arquitetônica que abraça a heterogeneidade em vez de combatê -la.
Estamos trabalhando em algo novo neste espaço. Algo que se baseia nos pontos fortes de Postgres e Iceberg, integra-se firmemente aos sistemas de Lakehouse existentes e facilita drasticamente a criação de sistemas de dados de pilha completa com fidelidade operacional e analítica.
Não se trata de usar o ETL para mover dados de sistemas legados para novos sistemas-trata-se de criar uma arquitetura de dados moderna coerente que serve casos de uso operacional e não operacional, igualmente.
Fique atento.
