Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Processamento Transacional/Analítico de Lago (LTAP) é uma arquitetura de dados que atende tanto cargas de trabalho transacionais (OLTP) quanto analíticas (OLAP) a partir de uma camada unificada de armazenamento de dados no lago, sob um único modelo de governança, para que você não precise manter sistemas transacionais e analíticos separados sincronizados. Ela remove os pipelines de captura de dados de mudança (CDC), replicação e transformação que as equipes tradicionalmente mantêm para copiar dados operacionais em um sistema analítico separado. Azure Databricks constrói LTAP sobre a arquitetura de armazenamento Lakebase. Para saber mais, veja Databricks lança LTAP: a primeira arquitetura Lake Transactional/Analytical Processing.
LTAP é uma arquitetura, não um único recurso. O Azure Databricks o entrega por meio de um conjunto de capacidades do Lakebase que estão sendo ativamente desenvolvidas e expandidas. As capacidades disponíveis dependem da sua nuvem. Esta página explica a arquitetura. Para as capacidades que você pode usar hoje em sua nuvem, veja Capacidades que implementam LTAP.
Importante
Antes de ler esta página, leia a arquitetura Lakebase para entender a arquitetura Lakebase e seus componentes: computação Postgres sem estado, safekeepers, servidores de paginação e armazenamento de objetos em nuvem. O LTAP se baseia diretamente em como o Lakebase separa computação de armazenamento, e o restante desta página assume essa base.
O custo de manter duas stacks sincronizadas
As aplicações dividem seu trabalho de dados em dois tipos de carga de trabalho. Cargas de trabalho transacionais (OLTP) atuam em poucas linhas por vez e precisam do conteúdo completo dessas linhas rapidamente, como processar um pagamento ou devolver um resultado da API. Cargas de trabalho analíticas (OLAP) buscam insights em grandes conjuntos de dados, frequentemente agregando e juntando muitas linhas, como prever vendas ou detectar fraudes. Esses padrões puxam em direções opostas: o OLTP precisa de leituras e gravações constantes de baixa latência em linhas individuais, enquanto o OLAP precisa escanear e agregar em 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 análises.
Fazer a ponte entre essas duas pilhas é a parte cara. Mantê-los sincronizados significa executar captura de dados de alterações (CDC), pipelines de streaming e réplicas de leitura cuja única função é copiar dados de um sistema para o outro. Essa infraestrutura é frágil, adiciona latência entre o momento em que os dados são escritos e quando podem ser analisados, e compete por recursos com o banco de dados transacional principal. À medida que aplicações e agentes de IA precisam cada vez mais de análises sobre os dados transacionais mais recentes, essa lacuna desacelera as equipes. Copiar dados entre dois sistemas também cria risco de governança: a linhagem pode se romper à medida que os dados avançam, o que torna obrigações como pedidos de remoção do GDPR mais difíceis de cumprir.
Como o LTAP unifica dados na camada de armazenamento
Em vez de criar um pipeline melhor entre duas stacks, o LTAP elimina por completo a necessidade de qualquer pipeline. Ele faz isso repensando o banco de dados do armazenamento para cima.
O Lakebase já separa a computação Postgres sem estado de uma camada de armazenamento durável composta por safekeepers, servidores de paginação e armazenamento de objetos na nuvem. Uma transação é confirmada assim que um quórum de safekeepers registra de forma durável seu log de gravação antecipada (write-ahead log), e os pageservers então materializam essas alterações de forma assíncrona no armazenamento de objetos em nuvem, de modo que os dados deixam de ficar presos em um único mecanismo de banco de dados.
Note
Para entender como o Lakebase separa computação e armazenamento, veja Arquitetura Lakebase.
O LTAP adiciona um passo a essa camada de armazenamento. À medida que o armazenamento Lakebase materializa os dados em armazenamento de objetos, ele transcodifica os dados Postgres orientados a linhas para o layout colunar do Parquet, à medida que os dados caem no lago, onde podem ser legidos por formatos de tabela aberta como Delta e Iceberg. Essa transcodificação permite que uma única cópia de dados atenda tanto cargas de trabalho OLTP quanto 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 Lakebase transcodifica cada valor para sua forma colunar mantendo a representação original do Postgres, então qualquer motor compatível com Postgres pode reinterpretar os dados sem perder informações. Tipos que não correspondem corretamente ao Parquet, como
NaN,NUMERICoverflow ou tipos de extensão como vector, array, geography e JSON, são preservados em um campo de overflow que contém a representação canônica do Postgres. - Versões em fileira são preservadas. A transcodificação mantém versões intermediárias das linhas, então a cópia colunar carrega as mesmas informações de versão que os dados de linha.
- Dados colunares comprimem bem. O formato colunar é altamente comprimido, o que reduz o espaço de armazenamento e a quantidade de dados movidos de e para o armazenamento de objetos.
A transcodificação roda inteiramente na camada de armazenamento, isolada da instância primária do Postgres, então não afeta sua carga de trabalho de serviço transacional. Ele se baseia em algo que o Lakebase já faz: liberar dados comprometidos para armazenamento de objetos na nuvem. O LTAP simplesmente adiciona o formato colunar a esse mesmo flush. Não há pipeline para você montar, nem processo externo consultando continuamente seu banco de dados.
Nem tudo é transcodificado. Os índices Postgres permanecem em sua representação original na camada de armazenamento durável, em vez de serem convertidos em colunas, então as leituras e buscas transacionais por pontos permanecem rápidas enquanto a cópia colunar serve para análises.
Como os dados ficam em armazenamento externo e versionado, criar uma ramificação ou restaurar para um ponto no tempo é uma operação de metadados, e não uma cópia física. Você pode ramificar um grande banco de dados de produção em segundos, rodar um experimento ou uma migração arriscada contra o branch e descartá-lo, sem duplicar os dados subjacentes.
Note
Uma ramificação do Lakebase é um clone de cópia por gravação do armazenamento do seu banco de dados: ela compartilha os dados existentes da ramificação pai e armazena apenas as alterações, portanto não duplica nenhum dado de antemão. A restauração em ponto no tempo usa o mesmo armazenamento versionado para retornar um banco de dados a um momento anterior dentro de sua janela de restauração. Para saber mais, veja Branches de banco de dados e Restauração para um ponto no tempo.
Essa abordagem em nível de armazenamento é o que diferencia o LTAP da captura de dados por alteração (CDC). O CDC replica dados do seu armazenamento OLTP em uma camada de análise separada usando um processo externo que sonda continuamente o banco de dados primário e um pipeline que transforma mudanças de linha em dados colunares. Esse pipeline consome recursos no seu banco de dados transacional principal, exige que você lide com mudanças de esquema e casos extremos, e faz um trade-off entre a atualização dos dados e o custo do pipeline, tudo isso enquanto introduz pontos de falha. O LTAP adota, em vez disso, uma abordagem no nível de armazenamento: o armazenamento do Lakebase transcodifica os dados para o data lake como parte da operação normal de armazenamento, sem nenhum processo externo concorrendo com sua carga de trabalho e sem nenhum pipeline para você criar ou manter.
Os três pilares do LTAP
Unificar dados na camada de armazenamento concede ao LTAP três propriedades definidoras.
- Governança universal. O Unity Catalog regula o acesso analítico a uma cópia lógica dos seus dados em ambas as cargas de trabalho.
- Motores projetados especificamente para isso. A Postgres atende transações e o Lakehouse atende análises, e nenhum compromete o outro.
- Uma única cópia lógica em armazenamento aberto. Ambos os mecanismos leem uma cópia dos seus dados em formatos abertos, sem réplicas nem pipelines que precisem ser mantidos sincronizados.
Governança universal
O Unity Catalog regula o acesso analítico aos seus dados em ambas as cargas de trabalho. Depois que você registra um banco de dados Lakebase, o Unity Catalog aplica permissões, linhagem e auditoria ao computo externo que o lê.
Note
A governança do Unity Catalog se aplica hoje ao acesso analítico: a computação externa, como Lakehouse//RT e Change Data Feed, que lê seus dados registrados no Lakebase. Ainda não governa diretamente as tabelas individuais do Postgres. O acesso pelo caminho transacional , ou seja, aplicações e clientes conectando-se ao Postgres, ainda é controlado pelos privilégios padrão do Postgres (GRANT e REVOKE), e não pelo Unity Catalog. Na prática, o Unity Catalog controla o acesso analítico e ao lakehouse, enquanto as funções e os privilégios do Postgres controlam o acesso transacional.
Motores construídos especialmente
A Postgres atende sua carga de trabalho transacional e a Lakehouse atende análises, cada uma com os pontos fortes para os quais foi criada. Um equívoco comum é a ideia de que, ao unificar os dois, seus dados operacionais se tornam dados frios armazenados no Iceberg. Não é o caso. Lakebase continua sendo o padrão Postgres. Indexação, ramificação, recuperação pontual, extensões e leituras e gravações pontuais de baixa latência continuam funcionando exatamente como funcionam hoje.
As leituras analíticas não competem com sua carga de trabalho transacional porque elas estão isoladas da instância principal do Postgres. Quando um motor analítico como o Lakehouse//RT consulta dados ao vivo do Lakebase, ele retorna um resultado novo e transacionalmente consistente sem copiar os dados:
- O motor lê a maior parte dos dados da cópia colunar no armazenamento de objetos, não do Postgres.
- Para obter uma visão transacional consistente, ele solicita ao Postgres apenas o número de sequência do log (LSN) atual, um único valor que marca uma posição no log de gravação antecipada. Essa é uma busca barata de metadados.
- Para o pequeno conjunto de mudanças muito recentes que ainda não se materializaram no lago, ele as lê do servidor de páginas e as funde no topo.
O Postgres não atende nenhum tráfego analítico de leitura além de retornar aquele único LSN, e a transcodificação roda na camada de armazenamento, não na instância do Postgres que atende sua aplicação. Sua carga de trabalho operacional continua em execução conforme o esperado.
Uma única cópia lógica em armazenamento aberto
Como os dados ficam armazenados no data lake em formato colunar Parquet, legível por meio de formatos abertos de tabela, como Delta e Iceberg, o Lakebase (OLTP) e o Lakehouse (OLAP) compartilham a mesma base de armazenamento. Você mantém uma cópia lógica dos dados em ambas as cargas de trabalho, em vez de conciliar um banco de dados transacional com uma cópia analítica separada.
Cada motor pode armazenar ou representar esses dados em um formato físico diferente para desempenho. O Lakebase utiliza páginas do Postgres para leituras pontuais rápidas de OLTP, e os mecanismos analíticos leem Parquet em formato colunar. Você ainda trabalha com um único conjunto de dados lógico , em vez de manter cópias transacionais e analíticas separadas e mantê-las sincronizadas.
Cada mesa tem um único escritor, seja Lakebase ou a casa do lago. Ambos os motores leem essa cópia lógica, então os mesmos dados estão disponíveis para suas aplicações e para análises sem uma segunda cópia.
Você precisa mudar a forma como usa o Lakebase?
No. Adotar recursos LTAP não exige migração de dados nem mudança na forma como suas aplicações se conectam ao Lakebase. O Lakebase permanece o Postgres padrão: suas extensões, índices, consultas e código de aplicação existentes continuam funcionando inalterados. Cada uma das capacidades LTAP é independente, então você pode adotar qualquer uma delas sempre que a carga de trabalho precisar.
Capacidades que implementam LTAP
Você coloca a arquitetura LTAP em prática por meio de um conjunto de capacidades do Lakebase. Cada um se baseia na base de armazenamento compartilhado descrita acima e, juntos, cobrem os caminhos que os dados seguem via LTAP:
- Gerencie e registre: incorpore os dados do Lakebase ao Unity Catalog.
- Disponibilize dados do lakehouse no Lakebase: tabelas sincronizadas, aceleradas por LTAP Direct Writes.
- Consulte dados em tempo real do Lakebase: Lakehouse//RT para análise, feed de dados de alteração do Lakebase para fluxos de alterações.
O diagrama a seguir mostra como essas capacidades escrevem e leem a partir de uma cópia dos seus dados, governada pelo Unity Catalog.
Lakehouse//RT e Lakebase Change Data Feed leem os mesmos dados subjacentes, mas os representam de forma diferente. O Lakehouse//RT lê o estado atual dos dados em tempo real do Postgres para análises. O Feed de Dados de Alteração oferece uma sequência de alterações em nível de linha para pipelines e auditorias posteriores. O CDC externo que o LTAP elimina também não é diferente: ambos operam sobre uma única cópia dos dados.
A tabela a seguir lista todas as capacidades LTAP e o que ela faz, junto com seu status de lançamento na sua nuvem. A disponibilidade varia de nuvem para nuvem, então uma funcionalidade que não é oferecida na sua nuvem é marcada como não disponível.
| Capability | Status | Description |
|---|---|---|
| Registre o Lakebase no Catálogo Unity | GA | Gerencie o acesso analítico aos dados do Lakebase e execute consultas entre diferentes fontes a partir do lakehouse. |
| Servir dados com tabelas sincronizadas | GA | Sirva dados da tabela do Unity Catalog no Lakebase para leituras OLTP de baixa latência. LTAP Direct Writes (Beta) acelera a carga inicial em todos os modos de sincronização, além das atualizações completas. |
| Lakehouse//RT consultando Lakebase | Beta | Execute consultas OLAP transacionalmente consistentes em dados Postgres ao vivo, sem impactar o desempenho do OLTP do Lakebase. |
| Fluxo de dados de alterações do Lakebase | Visualização Pública | Armazene as alterações em nível de linha das tabelas Postgres do Lakebase como tabelas Delta do Catálogo Unity para pipelines downstream e auditoria. |
Como abordar a implementação
Agora que você conhece os recursos, a questão é de quais deles sua carga de trabalho precisa. Você implementa o LTAP combinando as capacidades que correspondem à forma como os dados fluem pela sua arquitetura.
A decisão chave é a direção: para cada conjunto de dados, qual sistema é o responsável pela escrita? Cada tabela tem um único redator, e isso determina quais capacidades você usa.
- Lakebase é responsável pela escrita. Sua aplicação escreve para o Postgres, e você quer que esses dados operacionais estejam disponíveis para análise sem precisar copiá-los. Por exemplo, um aplicativo de vendas emite pedidos e pagamentos para a Lakebase conforme eles acontecem. Use o Lakehouse//RT para executar um painel em tempo real da receita com base nesses pedidos, ou o Lakebase Change Data Feed para transmitir cada alteração nos pedidos para um pipeline de destino ou registro de auditoria.
- A casa do lago é dona da escrita. Seus dados são produzidos ou mantidos no lakehouse, e você quer leituras OLTP de baixa latência neles a partir da sua aplicação. Por exemplo, um trabalho noturno em uma casa no lago elabora recomendações de produtos ou uma tabela de preços. Use tabelas sincronizadas para servir esses dados no Lakebase, assim sua aplicação pode lê-los com baixa latência, e ative as gravações diretas LTAP para acelerar a carga inicial de uma tabela grande.
Mapeie cada conjunto de dados para uma dessas direções, registre o banco de dados no Unity Catalog para governança e siga a documentação de capacidade para implementar cada caminho. Uma única aplicação frequentemente usa ambas as direções: disponibilizando dados de referência do lakehouse para o Postgres, enquanto expõe suas próprias gravações transacionais de volta para a análise. A disponibilidade varia de nuvem para nuvem, então confira a tabela de capacidades acima para confirmar o que está disponível na sua nuvem.
Próximas Etapas
- Arquitetura Lakebase: Entenda como o Lakebase separa computação sem estado do armazenamento durável. Veja arquitetura Lakebase.
- Registre um banco de dados no Unity Catalog: Gerencie os dados do Lakebase e consulte-os no lakehouse. Consulte Registrar um banco de dados Lakebase no Unity Catalog.
- Disponibilize dados com tabelas sincronizadas: Sincronize os dados das tabelas do Unity Catalog para o Lakebase para leitura de baixa latência e acelere cargas em grande volume com o LTAP Direct Writes. Consulte os dados do Serve lakehouse com tabelas sincronizadas.
- Fluxo de Dados de Mudanças do Lakebase: Alterações em nível de linha no lago para oleodutos e auditoria. Consulte o Feed de Dados de Alterações do Lakebase.