Arquitetura LTAP
Beta
A partir de 15 de junho, o Lakebase está disponível em Beta no GCP. Consulte Disponibilidade regional para regiões compatíveis.
O LTAP (Lake Transactional/Analytical Processing) é uma arquitetura de dados que atende a cargas de trabalho transacionais (OLTP) e analíticas (OLAP) a partir de uma camada de armazenamento de dados unificada no lake, sob um único modelo de governança, para que você não precise manter sistemas transacionais e analíticos separados em sincronia. Ele remove os pipelines de captura de dados de alterações (CDC), replicação e transformações que as equipes tradicionalmente mantêm para copiar dados operacionais para um sistema analítico separado. O Databricks constrói o LTAP sobre a arquitetura de armazenamento Lakebase. Para o anúncio, consulte Databricks lança LTAP: a primeira arquitetura de Processamento Analítico/Transacional de Lake.
LTAP é uma arquitetura, não um único recurso. A Databricks a entrega por meio de um conjunto de recursos do Lakebase que estão sendo desenvolvidos e expandidos ativamente. Os recursos disponíveis para você dependem da sua cloud. Esta página explica a arquitetura. Para os recursos que você pode usar hoje em sua cloud, consulte Recursos que implementam LTAP.
Antes de ler esta página, leia a arquitetura do Lakebase para entender a arquitetura do Lakebase e seus componentes: computação Postgres sem estado, servidores de segurança (safekeepers), servidores de páginas (pageservers) e armazenamento de objetos na nuvem. O LTAP se baseia diretamente em como o Lakebase separa compute de armazenamento, e o restante desta página pressupõe essa base.
O custo de manter duas pilhas em sincronia
As aplicações dividem seu trabalho de dados em dois tipos de carga de trabalho. Cargas de trabalho transacionais (OLTP) atuam em algumas linhas por vez e precisam do conteúdo completo dessas linhas rapidamente, como no processamento de um pagamento ou no retorno de um resultado de API. Cargas de trabalho analíticas (OLAP) buscam percepções em grandes datasets, frequentemente agregando e unindo muitas linhas, como na previsão de vendas ou detecção de fraudes. Esses padrões seguem direções opostas: o OLTP precisa de leituras e gravações constantes de baixa latência em linhas individuais, enquanto o OLAP precisa verificar e agregar grandes volumes de dados. Por décadas, a resposta foi dois sistemas separados: um banco de dados transacional para a aplicação e um data warehouse ou lakehouse para analítica.
Fazer a ponte entre essas duas stacks é a parte dispendiosa. Mantê-los sincronizados significa executar a captura de dados de alterações (CDC), pipelines de transmissão e réplicas de leitura cujo único job é copiar dados de um sistema para o outro. Essa infraestrutura é frágil, adiciona latência entre o momento em que os dados são gravados e o momento em que podem ser analisados, e compete por recursos com o banco de dados transacional primário. À medida que aplicações e agentes de IA precisam cada vez mais de analítica sobre os dados transacionais mais recentes, essa lacuna torna as equipes mais lentas. Copiar dados entre dois sistemas também cria riscos de governança: a linhagem pode ser interrompida à medida que os dados se movem, o que torna obrigações como solicitações de remoção da GDPR mais difíceis de cumprir.
Como o LTAP unifica dados na camada de armazenamento
Em vez de construir um pipeline melhor entre duas pilhas, o LTAP elimina completamente a necessidade de um pipeline. Isso é feito repensando o banco de dados desde o armazenamento.
O Lakebase já separa o compute stateless do Postgres de uma camada de armazenamento durável de safekeepers, pageservers e armazenamento de objetos em cloud. Uma transação realiza o commit assim que um quórum de safekeepers registra de forma durável seu write-ahead log, e os pageservers então materializam essas alterações de forma assíncrona no armazenamento de objetos em cloud, para que os dados não fiquem mais bloqueados dentro de um único mecanismo de banco de dados.
Para saber como o Lakebase separa compute e armazenamento, consulte Arquitetura Lakebase.
O LTAP adiciona o passo de uma camada a esse armazenamento. À medida que o armazenamento do Lakebase materializa dados no armazenamento de objetos, ele transcodifica os dados do Postgres orientados a linhas para a disposição colunar do Parquet conforme os dados chegam ao lake, onde podem ser lidos por meio de formatos de tabela abertos como Delta e Iceberg. Essa transcodificação é o que permite que uma única cópia de dados atenda a cargas de trabalho OLTP e OLAP. Ele foi projetado para que a cópia colunar permaneça uma representação fiel e eficiente do original do Postgres:
- A semântica é preservada. O armazenamento do Lakebase transcodifica cada valor para sua forma colunar enquanto mantém a representação original do Postgres, para que qualquer mecanismo compatível com Postgres possa reinterpretar os dados sem perder informações. Tipos que não são mapeados claramente para Parquet, como
NaN, estouro deNUMERICou tipos de extensão como vetor, matriz, geografia e JSON, são preservados em um campo de estouro que mantém a representação canônica do Postgres. - As versões de linha são preservadas. A transcodificação retém versões intermediárias de linha, portanto, a cópia colunar carrega as mesmas informações de versão que os dados de linha.
- Dados colunares são bem compactados. A disposição colunar é altamente compactada, o que reduz a ocupação de armazenamento e a quantidade de dados movidos de e para o armazenamento de objetos.
A transcodificação é executada inteiramente na camada de armazenamento, isolada da instância principal do Postgres, portanto, não afeta sua carga de trabalho de serviço transacional. Ele se baseia em algo que o Lakebase já faz: liberar dados confirmados para o armazenamento de objetos em cloud. O LTAP simplesmente adiciona o formato colunar a esse mesmo flush. Não há pipeline para você criar e nenhum processo externo consultando seu banco de dados.
Nem tudo é transcodificado. Os índices do Postgres permanecem em sua representação original na camada de armazenamento durável, em vez de serem convertidos em colunas, de modo que as leituras e pesquisas pontuais transacionais permanecem rápidas, enquanto a cópia em colunas serve para analítica.
Como os dados residem em armazenamento externalizado e com controle de versão, criar uma branch ou restaurar para um ponto específico no tempo é uma operação de metadados, e não uma cópia física. Você pode criar uma branch de um banco de dados de produção grande em segundos, realizar um experimento ou uma migração arriscada na branch e descartá-la, sem duplicar os dados subjacentes.
Um branch do Lakebase é um clone copy-on-write do armazenamento do seu banco de dados: ele compartilha os dados existentes do pai e armazena apenas o que muda, portanto, não duplica dados antecipadamente. A restauração pontual usa o mesmo armazenamento com versão para retornar um banco de dados a um momento anterior dentro de sua janela de restauração. Para saber mais, consulte Branch de banco de dados e Restauração pontual.
Essa abordagem em nível de armazenamento é o que diferencia o LTAP da captura de dados de alterações (CDC). O CDC replica dados do seu armazenamento OLTP para uma camada de analítica separada usando um processo externo que pesquisa continuamente o banco de dados primário e um pipeline que transforma alterações de linha em dados colunares. Esse pipeline consome recursos em seu banco de dados transacional primário, obriga você a lidar com alterações de esquema e casos extremos por conta própria, e troca a atualização dos dados pelo custo do pipeline, tudo isso enquanto adiciona pontos de falha. O LTAP adota uma abordagem em nível de armazenamento: o armazenamento do Lakebase transcodifica dados para o lake como parte da operação normal de armazenamento, sem nenhum processo externo competindo com sua carga de trabalho e sem nenhum pipeline para você criar ou manter.
Os três pilares do LTAP
A unificação de dados na camada de armazenamento confere ao LTAP três propriedades definidoras.
- Governança universal. O Unity Catalog rege o acesso analítico a uma cópia lógica dos seus dados em ambos os workloads.
- Mecanismos desenvolvidos especificamente. O Postgres atende transações e o Lakehouse atende a analítica, e nenhum compromete o outro.
- Uma única cópia lógica em armazenamento aberto. Ambos os mecanismos leem uma única cópia dos seus dados em formatos abertos, sem réplicas ou pipelines para manter sincronizados.
Governança universal
O Unity Catalog governa o acesso analítico aos seus dados em ambas as cargas de trabalho. Após registrar um banco de dados Lakebase, o Unity Catalog aplica permissões, linhagem e auditoria ao compute externo que o lê.
A governança do Unity Catalog aplica-se hoje ao acesso analítico : o compute externo, como o Lakehouse//RT e o Change Data Feed, que lê seus dados registrados no Lakebase. Ele ainda não rege tabelas individuais do Postgres diretamente. O acesso pelo caminho transacional , ou seja, aplicações e clientes que se conectam ao Postgres, ainda é controlado pelos privilégios padrão do Postgres (GRANT e REVOKE), não pelo Unity Catalog. Na prática, o Unity Catalog rege o acesso analítico e ao lakehouse, enquanto as funções e privilégios do Postgres regem o acesso transacional.
Motores desenvolvidos especificamente
O Postgres atende à sua carga de trabalho transacional e o Lakehouse atende à analítica, cada um com os pontos fortes para os quais foi desenvolvido. Um equívoco comum é que unificar os dois significa que seus dados operacionais se tornam dados frios armazenados no Iceberg. Esse não é o caso. O Lakebase permanece como Postgres padrão. Indexação, ramificação, recuperação pontual, extensões e leituras e gravações pontuais de baixa latência continuam funcionando exatamente como hoje.
As leituras analíticas não competem com sua carga de trabalho transacional porque são isoladas da instância primária do Postgres. Quando um mecanismo de analítica como o Lakehouse//RT faz queries em dados ativos do Lakebase, ele retorna um resultado atualizado e transacionalmente consistente sem copiar dados:
- O mecanismo lê a maior parte dos dados da cópia colunar no armazenamento de objetos, não do Postgres.
- Para obter uma view transacionalmente consistente, ele solicita ao Postgres apenas o número de sequência de log (LSN) atual, um valor único que marca uma posição no log de write-ahead. Esta é uma pesquisa de metadados de baixo custo.
- Para o pequeno conjunto de alterações muito recentes que ainda não foram materializadas no lake, ele as lê do pageserver e faz o merge delas por cima.
O Postgres não atende a nenhum tráfego de leitura analítica além de retornar esse LSN único, e a transcodificação é executada na camada de armazenamento, não na instância do Postgres que atende ao seu aplicativo. Seu workload operacional continua sendo executado conforme o esperado.
Uma única cópia lógica em armazenamento aberto.
Como os dados residem no lake como Parquet colunar, legível por meio de formatos de tabela abertos como Delta e Iceberg, o Lakebase (OLTP) e o Lakehouse (OLAP) compartilham a mesma base de armazenamento. Mantém-se uma cópia lógica de dados em ambas as cargas de trabalho, em vez de reconciliar uma base de dados transacional com uma cópia analítica separada.
Cada mecanismo pode armazenar em cache ou representar esses dados em um formato físico diferente para desempenho. O Lakebase usa páginas Postgres para leituras pontuais OLTP rápidas, e mecanismos analíticos leem Parquet colunar. Você ainda trabalha com um único dataset lógico , em vez de manter cópias transacionais e analíticas separadas e mantê-las sincronizadas.
Cada tabela tem um único gravador, seja o Lakebase ou o lakehouse. Ambos os mecanismos leem essa única cópia lógica, portanto, os mesmos dados ficam disponíveis para suas aplicações e para a analítica sem a necessidade de uma segunda cópia.
Você precisa alterar a forma como usa o Lakebase
Não. A adoção das capacidades LTAP não requer uma migração de dados ou uma alteração na forma como suas aplicações se conectam ao Lakebase. O Lakebase permanece como Postgres padrão: suas extensões, índices, queries e código de aplicação existentes continuam funcionando sem alterações. Cada uma das capacidades LTAP é independente, portanto, você pode adotar qualquer uma delas sempre que uma carga de trabalho precisar.
Capacidades que implementam LTAP
Você coloca a arquitetura LTAP em prática por meio de um conjunto de recursos do Lakebase. Cada um deles se baseia na base de armazenamento compartilhada descrita acima e, juntos, eles cobrem os caminhos que os dados percorrem através do LTAP:
- Governar e registrar : traga os dados do Lakebase para o Unity Catalog.
- Disponibilize dados de lakehouse no Lakebase : tabelas sincronizadas, aceleradas por LTAP Direct Writes.
- Fazer query de dados do Lakebase em tempo real : Lakehouse//RT para analítica, Lakebase Change Data Feed para fluxos de alteração.
O diagrama a seguir mostra como esses recursos gravam e leem de uma cópia dos seus dados, governados pelo Unity Catalog.
O Lakehouse//RT e o Change Data Feed do Lakebase leem os mesmos dados subjacentes, mas os representam de forma diferente. O Lakehouse//RT lê o estado atual dos dados ativos do Postgres para analítica. O Change Data Feed entrega uma transmissão de alterações em nível de linha para pipelines downstream e auditoria. Nenhum deles é o CDC externo que o LTAP remove: ambos operam na cópia única de dados.
A tabela a seguir lista cada capacidade do LTAP e o que ela faz, juntamente com seu status de lançamento na sua cloud. A disponibilidade varia de acordo com a cloud, portanto, uma capacidade que não é oferecida na sua cloud é marcada como não disponível.
Capacidade | Status | Descrição |
|---|---|---|
GA | Governe o acesso analítico aos dados do Lakebase e execute queries de várias fontes a partir do lakehouse. | |
GA | Disponibilize dados de tabelas do Unity Catalog no Lakebase para leituras OLTP de baixa latência. | |
Lakehouse//RT consultando o Lakebase | Não disponível no GCP | Execute consultas OLAP transacionalmente consistentes em dados Postgres em tempo real, sem afetar o desempenho do Lakebase OLTP. |
Change Data Feed do Lakebase | Não disponível no GCP | Armazene as alterações em nível de linha das tabelas do Lakebase Postgres como tabelas Delta do Unity Catalog para pipelines subsequentes e auditoria. |
Como abordar a implementação
Agora que você conhece os recursos, a questão é quais deles sua carga de trabalho precisa. Você implementa o LTAP combinando os recursos que correspondem à forma como os dados fluem pela sua arquitetura.
A decisão crucial é a direção: para cada dataset, qual sistema detém a permissão de escrita? Cada tabela possui um único gravador, e isso determina quais recursos você utiliza.
- O Lakebase detém a gravação. Sua aplicação grava no Postgres, e você deseja que esses dados operacionais estejam disponíveis para analítica sem precisar copiá-los. Por exemplo, uma aplicação de vendas grava pedidos e pagamentos no Lakebase à medida que ocorrem. Use o Lakehouse//RT para executar um dashboard de receita em tempo real sobre esses pedidos, ou o Lakebase Change Data Feed para stream cada alteração de pedido para um pipeline downstream ou log de auditoria.
- O lakehouse detém a gravação. Seus dados são produzidos ou mantidos no lakehouse, e você deseja leituras OLTP de baixa latência neles a partir de sua aplicação. Por exemplo, um job noturno de lakehouse calcula recomendações de produto ou uma tabela de preços. Use tabelas sincronizadas para disponibilizar esses dados no Lakebase para que sua aplicação possa lê-los com baixa latência, e habilite o LTAP Direct Writes para acelerar o carregamento inicial de uma tabela grande.
Mapeie cada dataset para uma dessas direções, registre o banco de dados no Unity Catalog para governança e, em seguida, siga a documentação de recursos para implementar cada caminho. Uma única aplicação geralmente utiliza ambas as direções: fornecendo dados de referência do lakehouse para o Postgres, enquanto expõe suas próprias gravações transacionais de volta para a analítica. A disponibilidade varia conforme a nuvem, portanto, verifique a tabela de recursos acima para confirmar o que é oferecido na sua nuvem.
Passos seguintes
- Arquitetura Lakebase : entenda como o Lakebase separa o compute sem estado do armazenamento durável. Consulte Arquitetura Lakebase.
- Registrar um banco de dados no Unity Catalog : gerencie dados do Lakebase e faça query deles a partir do lakehouse. Consulte Registrar um banco de dados Lakebase no Unity Catalog.
- Disponibilize dados com tabelas sincronizadas : sincronize dados de tabelas do Unity Catalog no Lakebase para leituras de baixa latência e acelere grandes cargas com LTAP Direct Writes. Consulte Disponibilize dados lakehouse com tabelas sincronizadas.
Saiba mais
- Anúncio : Databricks lança a LTAP: a primeira arquitetura de Processamento Transacional/Analítico em Lake
- Blog de engenharia : Do monolito ao Lakebase ao LTAP: repensando o banco de dados a partir do armazenamento
- Demonstração : LTAP: A primeira arquitetura de Processamento Analítico/Transacional de Lake