Databricks LTAP Elimina Pipelines CDC para Analytics com Dados Atualizados

Databricks publicou uma análise arquitetônica detalhada do Lakebase, sua oferta serverless Postgres, e do LTAP—Lake Transaction & Metadata Protocol. O post lê-se mais como uma autópsia de três décadas de design de banco de dados do que um anúncio de produto. Cada grande dor de cabeça operacional rastreia até a mesma causa raiz: o WAL e os arquivos de dados vivendo na mesma máquina.

O problema do monólito não é novo, mas Databricks o nomeia com precisão. Cada instância tradicional de Postgres, MySQL ou Oracle mantém duas coisas em disco local: o write-ahead log (WAL), que torna commits rápidos via appends sequenciais, e os arquivos de dados, que tornam leituras rápidas armazenando o estado atual. Essa co-localização cria custos operacionais em cascata. A durabilidade do commit depende de configurações sutis de disk-flush—o SO pode mentir silenciosamente sobre flushing. Se o disco da máquina morre, os dados morrem. Escalar leituras requer provisionar um clone físico completo, que desestabiliza o primário. Alta disponibilidade significa executar pelo menos duas cópias completas em sincronização, pagando 2x+ infraestrutura. Queries analíticas competem diretamente com latência OLTP.

Lakebase quebra esse acoplamento tornando a camada de compute Postgres sem estado. O WAL move para SafeKeeper, um serviço de nuvem distribuído aceitando escritas de quórum. Uma transação é durável no momento em que o quórum de SafeKeeper a reconhece, sem disco local no caminho. Arquivos de dados movem para PageServer, que armazena páginas em object storage em nuvem e as serve sob demanda para nós de compute. Qualquer instância de compute Postgres pode se anexar ao mesmo SafeKeeper e PageServer, então failover é uma troca de ponteiro em vez de um clone completo de banco de dados. Branching torna-se instantâneo—apenas um fork de ponteiro de metadados, não uma cópia de byte.

LTAP é a segunda camada. Onde Lakebase desagrega armazenamento de formatos Postgres tradicionais, LTAP muda o formato em si. Dados operacionais são armazenados uma vez em formato colunar aberto—Delta Lake / Parquet—que tanto Postgres quanto os engines Lakehouse do Databricks leem diretamente. Queries de analytics rodam contra a mesma camada de armazenamento que transações acabaram de escrever: sem pipeline CDC, sem segunda cópia, sem lag de replicação. Isso aborda diretamente a arquitetura que a maioria dos times de dados rodando Postgres + Databricks operam hoje: escritas transacionais para Postgres, um pipeline CDC (Debezium, Fivetran, ou similar) empurrando mudanças para o lakehouse, e queries analíticas rodando em dados que estão minutos a horas desatualizados.

HTAP—hybrid transactional/analytical processing—tenta lidar com ambas as cargas de trabalho em um único engine. Um único engine otimizado para nenhum acaba medíocre em ambos. LTAP mantém engines especializados em seu lugar. Postgres lida com OLTP, Spark e o runtime Databricks lidam com OLAP, e compartilham uma camada de armazenamento comum sem interferência. Por design, LTAP roteia analytics através da camada de armazenamento compartilhada em vez do caminho de compute transacional, mantendo as duas cargas de trabalho de competirem pelos mesmos recursos.

Para cargas de trabalho de ML e IA, a implicação é dados de features mais frescos com menos partes móveis. Feature pipelines que hoje leem de uma réplica OLAP com lag de replicação podem ler diretamente do armazenamento LTAP em frescor de transação-committed. Isso remove tanto o lag quanto o pipeline como superfícies de falha. A capacidade de branching importa para times fazendo iteração rápida de schema—spinning up uma branch para um teste de migração ou retreinamento de modelo custa nada em overhead de cópia de dados.

Databricks não publicou números de latência de benchmark para o caminho de quórum-write SafeKeeper ou penalidades de cache miss PageServer. Times avaliando Lakebase para cargas de trabalho sensíveis a latência devem tratar esses como questões abertas até que case studies de produção apareçam. O argumento arquitetônico é sólido; o envelope operacional em escala permanece a ser mostrado externamente.

Se você está rodando um pipeline CDC de Postgres para Databricks hoje, LTAP é a substituição arquitetônica direta—uma cópia, sem pipeline, analytics com dados atualizados.