A regra de banco de dados de 40 anos que os agentes acabam de quebrar: como o LTAP unifica as cargas de trabalho OLTP e OLAP

Jonathan Katz passou sua carreira em ambos os lados de uma linha com a qual a maior parte do setor de dados simplesmente aprendeu a conviver. Como colaborador de longa data do Postgres e agora Senior Staff Product Manager na Databricks, ele viu os sistemas operacionais e analíticos funcionarem como dois mundos separados, conectados apenas por pipelines, cópias e concessões.

Nesta conversa, Jonathan explica por que essa separação existia em primeiro lugar, por que os agentes de AI são o fator que finalmente está quebrando essa barreira e como o LTAP reduz essa lacuna ao repensar onde os dois mundos se encontram: não em um único mecanismo, mas em uma camada de armazenamento unificada.

A premissa que os agentes de AI quebraram

O setor vive há décadas com uma separação rígida entre sistemas de banco de dados operacionais e analíticos. Por que o surgimento de agentes de AI autônomos está acabando com isso?

Jonathan Katz: Existem dois mundos de dados. Os dados operacionais são o que você acessa ao processar uma transação de cartão de crédito ou buscar fraudes: consultas muito curtas e rápidas, analisando os dados linha por linha. Os dados analíticos são o que você vem acumulando há semanas, meses ou anos e, quando faz uma consulta, analisa todo o conjunto de dados. Ambos tentam retornar uma resposta o mais rápido possível, mas fazem isso de maneiras totalmente diferentes.

Essa diferença não é arbitrária. É uma questão de física. Se você armazena seus dados em linhas, é assim que você retorna uma única resposta rápida o mais rápido possível. Se você os armazena em colunas, é assim que você varre e agrega tudo o mais rápido possível. Além disso, por design, uma consulta analítica pode consumir todos os recursos de um sistema massivamente paralelizado para obter uma resposta em um conjunto de dados muito grande, enquanto uma consulta operacional é projetada para consumir o mínimo de recursos possível, sem deixar de retornar uma resposta rapidamente. Isso leva a duas maneiras muito diferentes de pensar sobre como projetar e gerenciar seu sistema de dados, exigindo diferentes tipos de otimização.

O Postgres, um dos bancos de dados mais implantados no planeta, é construído em torno de linhas porque é otimizado para cargas de trabalho operacionais. Os mecanismos analíticos são construídos em torno de colunas pelo motivo oposto. Devido a essa diferença física fundamental, os dois sistemas sempre tiveram que ficar separados e, toda vez que você queria analisar dados operacionais, precisava enviá-los para outro lugar.

O surgimento de agentes de AI mudou o que precisamos dos bancos de dados. É parte do motivo pelo qual a arquitetura do Lakebase existe, para começar: bancos de dados criados para acompanhar o funcionamento real dos agentes. Por exemplo, os agentes têm a tarefa de procurar fraudes ou anomalias, e esses eventos ocorrem em centenas de milissegundos. Mas esse sistema também lida com um enorme volume de gravações e leituras curtas ao mesmo tempo. Um único agente pode ser inteligente o suficiente para saber qual consulta precisa executar. Um grupo de agentes pode facilmente sobrecarregar um sistema operacional se não houver limites de proteção estabelecidos.

O que é o LTAP na realidade

O que é o LTAP e como ele realmente funciona nos bastidores?

Jonathan Katz: O LTAP, Lake Transactional/Analytical Processing, permite executar consultas analíticas diretamente em dados operacionais em tempo real, sem mover esses dados para lugar nenhum e sem sobrecarregar o sistema que atende às suas transações. Ele faz isso unificando os dados transacionais e analíticos em uma única camada lógica de armazenamento, em vez de forçá-los a passar por sistemas separados conectados por um pipeline.

Nos bastidores, o LTAP só é possível devido à forma como o próprio Lakebase é arquitetado: computação stateless e efêmera totalmente desacoplada do armazenamento no lake. Essa separação, herdada do Neon, significa que a camada de armazenamento durável pode lidar com gravações de alta taxa de transferência e enviá-las periodicamente para o armazenamento de objetos para permanência, independentemente de qual computação esteja sendo executada nele em um determinado momento. Como esses dados já estavam sendo otimizados para o armazenamento em nuvem, por que não representá-los no mesmo formato colunar que o Lakehouse já usa, para que mecanismos como o Apache Spark e o SQL possam lê-los diretamente e obter leituras analíticas de alto desempenho sem uma segunda cópia?

A parte mais difícil foi garantir que nada se perdesse no caminho. O Postgres tem seus próprios tipos de dados e codificações, e formatos abertos como o Iceberg e o Delta têm os seus. Tivemos que gravar os dados de uma forma que preservasse a representação física exata dos dados originais do Postgres, sem alterar um único bit, e colocá-los em um arquivo Parquet. Essa é a parte que nos permitiu mesclar as representações operacionais e analíticas dos mesmos dados em uma só. Na prática, a camada de armazenamento funciona em duas camadas: uma camada mais quente que mantém os dados em formato de linha para acesso operacional rápido, e uma camada mais fria que os mantém em formato colunar para leituras analíticas, para que ambos os lados possam obter o que precisam de forma eficiente.

Por que o LTAP tem sucesso onde o HTAP estagnou

O HTAP tentou resolver a análise em tempo real anos atrás e estagnou. Por que fazer isso na camada de armazenamento do lakehouse funciona onde o HTAP tradicional falhou?

Jonathan Katz: É possível fazer os sistemas HTAP funcionarem, mas eles são caros. São complexos, difíceis de operar e, geralmente, não são abertos. O diferencial do modelo LTAP é que você tem computação operacional serverless e computação analítica serverless como duas coisas separadas. Você pode ajustar exatamente a quantidade de computação que está usando para cada carga de trabalho de forma independente, em vez de pagar por um único sistema que tenta fazer as duas tarefas ao mesmo tempo. O armazenamento é a parte barata de qualquer sistema de dados. A computação é a parte cara.

Esse é todo o argumento para unificar a camada de armazenamento em vez do mecanismo: você mantém o mecanismo especializado e eficiente para cada tarefa e só paga pela computação onde realmente precisa dela, em vez de executar um sistema caro que tenta ser bom em tudo ao mesmo tempo.

O que falha quando os agentes agem com base em dados desatualizados

Explique um fluxo de trabalho de agente específico que falha ou perde desempenho hoje porque está lendo e agindo com base em dados desatualizados. O que realmente dá errado?

Jonathan Katz: A detecção de fraudes é o exemplo mais claro. As transações de cartão de crédito são compensadas em centenas de milissegundos ou menos. Se o agente responsável por detectar fraudes estiver trabalhando com uma cópia em lote (batch) dos dados que tem minutos ou horas de atraso, ele será simplesmente lento demais para detectar qualquer coisa antes que a transação já tenha sido concluída. Portanto, você quer que esse agente trabalhe diretamente no sistema operacional.

Mas o sistema operacional está lidando com um fluxo constante de gravações e leituras curtas, e não foi criado para absorver também consultas analíticas pesadas. Se o agente executar uma consulta que varre todo o histórico de compras de um cliente para verificar anomalias, essa será uma consulta cara para ser executada em um sistema otimizado para o tipo oposto de carga de trabalho. Isso pode prejudicar o desempenho de todas as outras transações que tentam ser processadas ao mesmo tempo. E uma arquitetura moderna geralmente precisa de dados tanto do lado operacional quanto do analítico para tomar uma boa decisão, de modo que o agente precisa extrair dados de ambos. Um único agente pode lidar com isso de forma responsável. Uma frota de agentes executando consultas semelhantes ao mesmo tempo pode sobrecarregar o sistema operacional rapidamente se não houver nada que controle a carga que eles podem aplicar a ele.

Governança, abertura e o caso de uso corporativo

Como a Databricks implementa especificamente o LTAP hoje e como você descreveria isso para alguém que já entende por que o HTAP deixa a desejar?

Jonathan Katz: Além da mecânica de armazenamento, a outra parte importante é o catálogo. Uma das grandes inovações do Lakehouse foi dar às organizações uma visão centralizada e unificada de todos os seus dados: quem tem acesso a quê, políticas consistentes em tudo, para que as pessoas não possam ler algo como um número de CPF, a menos que estejam em um grupo privilegiado. Isso nunca se aplicou realmente aos sistemas operacionais, porque eles foram construídos como silos de dados desde o início. A relação entre dados operacionais e analíticos costumava ser: você cria um pipeline, envia os dados e, depois disso, boa sorte. Ninguém era responsável pelo que acontecia com eles downstream. O LTAP muda isso. São todos os seus dados, em um modelo de armazenamento unificado, sob um único catálogo. Você não precisa se preocupar com a possibilidade de os dados operacionais saírem de um limite de governança só porque alguém precisou analisá-los.

Também há um argumento forte sobre o motivo pelo qual isso precisa ser construído sobre uma base aberta. O Postgres está prestes a se tornar o terceiro banco de dados mais bem avaliado em termos de preferência no ranking do DB-Engines. Isso não é necessariamente uma medida de adoção, mas é um forte sinal de para onde as coisas estão caminhando e mostra o valor da flexibilidade e da escolha. O código aberto vem impulsionando alguns dos sistemas mais importantes do mundo há décadas. O LTAP estende esse mesmo princípio. Mesmo dentro do Postgres, seus dados são portáveis entre sistemas Postgres, mas você ainda fica preso ao Postgres. Com a camada de armazenamento unificada do LTAP, você não precisa mais mover os dados para usar o mecanismo correto. Você leva o mecanismo até os dados.

A mudança fundamental: armazenamento unificado

Se você tivesse que descrever a mudança fundamental que o LTAP representa em uma única frase, independentemente de como a formulasse, como a definiria?

Jonathan Katz: A versão supersimplificada é o armazenamento unificado. Diga isso a alguém da área de analytics e a pessoa entenderá quase imediatamente. Diga isso a alguém do lado operacional e essa pessoa poderá perguntar o que você quer dizer. Mas, uma vez que você consegue unir as representações operacional e analítica dos mesmos dados sem mover nada, sem alterar nenhum bit, isso elimina uma série de problemas que antes pareciam inevitáveis. Não preciso mais executar pipelines apenas para colocar os dados em uma camada bronze ou silver. Posso começar a analisá-los no momento em que são gravados. Eu também inverteria a perspectiva: trata-se menos de inventar algo novo e mais de unir novamente dois mundos que nunca deveriam ter sido separados. Dados são apenas dados. Quanto mais pudermos tratá-los assim, mais fácil será para as pessoas, e agora para os agentes, trabalharem com eles sem que todos precisem negociar por meio de um pipeline primeiro.

Unindo os dois mundos novamente

Por quarenta anos, a linha entre dados operacionais e analíticos se manteve porque a física do armazenamento assim exigia. Os agentes são a primeira carga de trabalho que não pode tolerar o atraso que essa linha cria. O LTAP não tenta apagar a diferença entre uma transação e uma consulta analítica. Ele remove o custo que costumava existir ao executar ambas no mesmo conjunto de dados. Para um Arquiteto de Dados que avalia se uma carga de trabalho de agentes realmente precisa desse padrão, o teste que Jonathan descreve é muito útil: se a próxima decisão de um agente depender de dados que ainda estão se consolidando, em um sistema construído para manter esses dados próximos e protegidos, o antigo modelo de pipeline e cópia não será rápido o suficiente. Esse é o problema específico que o LTAP foi criado para resolver.

Para saber mais sobre o LTAP, leia Do monolito ao Lakebase e ao LTAP: repensando o banco de dados a partir do armazenamento.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original