Arquitetura LTAP

Lake Transactional/Analytical Processing (LTAP) é uma arquitetura de dados que serve cargas de trabalho transacionais (OLTP) e analíticas (OLAP) a partir de uma camada unificada de armazenamento de dados no lago, sob um único modelo de governação, para que não seja necessário manter sistemas transacionais e analíticos separados sincronizados. Remove os pipelines de captura de dados de alteração (CDC), replicação e transformação que as equipas tradicionalmente mantêm para copiar dados operacionais para um sistema analítico separado. O Azure Databricks constrói LTAP sobre a arquitetura de armazenamento Lakebase. Para o anúncio, veja Databricks lança LTAP: a primeira arquitetura de Processamento Transacional/Analítico do Lago.

LTAP é uma arquitetura, não uma única funcionalidade. O Azure Databricks disponibiliza-o através de um conjunto de capacidades do Lakebase que estão a ser desenvolvidas e expandidas ativamente. As capacidades disponíveis para si dependem da sua nuvem. Esta página explica a arquitetura. Para as funcionalidades que pode usar hoje na sua cloud, consulte Capacidades que implementam LTAP.

Importante

Antes de ler esta página, leia a arquitetura Lakebase para compreender a arquitetura Lakebase e os seus componentes: computação Postgres sem estado, safekeepers, servidores de paginação e armazenamento de objetos na cloud. O LTAP baseia-se diretamente em como o Lakebase separa computação de armazenamento, e o resto desta página assume essa base.

O custo de manter dois stacks em sincronização

As aplicações dividem o seu trabalho de dados em dois tipos de carga de trabalho. As cargas de trabalho transacionais (OLTP) atuam em poucas linhas de cada vez e precisam de obter o conteúdo completo dessas linhas rapidamente, como ao processar um pagamento ou a devolver um resultado da API. As cargas de trabalho analíticas (OLAP) procuram insights em grandes conjuntos de dados, frequentemente agregando e juntando muitas linhas, como prever vendas ou detetar fraude. Estes padrões puxam em direções opostas: o OLTP precisa de leituras e escritas constantes de baixa latência em linhas individuais, enquanto o OLAP precisa de escanear e agregar grandes volumes de dados. Durante décadas, a resposta foram dois sistemas distintos: uma base de dados transacional para a aplicação e um data warehouse ou lakehouse para análise.

Fazer a ponte entre essas duas pilhas é a parte mais 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 a base de dados transacional principal. À medida que as aplicações e os agentes de IA necessitam cada vez mais de capacidade analítica sobre os dados transacionais mais recentes, esta lacuna abranda o trabalho das equipas. Copiar dados entre dois sistemas também cria risco de governação: a linhagem pode quebrar-se à medida que os dados avançam, o que torna obrigações como pedidos de remoção do RGPD mais difíceis de cumprir.

Como o LTAP unifica os dados na camada de armazenamento

Em vez de criar uma melhor pipeline entre duas pilhas, o LTAP elimina por completo a necessidade de um pipeline. Faz isto repensando a base de dados a partir do armazenamento para cima.

O Lakebase já separa o processamento sem estado do Postgres de uma camada de armazenamento persistente composta por safekeepers, pageservers e armazenamento de objetos na nuvem. Uma transação é confirmada assim que um quórum de safekeepers regista de forma durável o seu write-ahead log, e os pageservers materializam depois essas alterações de forma assíncrona em armazenamento de objetos na cloud, pelo que os dados deixam de ficar bloqueados dentro de um único motor de base de dados.

Note

Para saber 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 do Lakebase materializa os dados em armazenamento de objetos, transcodifica os dados do Postgres em formato orientado por linhas para o esquema colunar do Parquet, à medida que os dados chegam ao lago, onde ficam acessíveis por meio de formatos de tabelas abertos, como Delta e Iceberg. Esta transcodificação é o que permite que uma única cópia de dados sirva tanto cargas de trabalho OLTP como OLAP. Foi desenhado 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 a sua forma colunar, mantendo a representação original do Postgres, pelo que qualquer motor compatível com Postgres pode reinterpretar os dados sem perder informação. Tipos que não correspondem de forma limpa ao Parquet, como NaN, NUMERIC overflow, ou tipos de extensão como vector, array, geography e JSON, são preservados num campo de overflow que contém a representação canónica do Postgres.
  • As versões em linha são preservadas. A transcodificação mantém versões intermédias das linhas, pelo que a cópia colunar contém a mesma informação de versão que os dados em linha.
  • Os dados colunares comprimem bem. A estrutura colunar é altamente comprimida, o que reduz o volume de armazenamento necessário e a quantidade de dados movidos de e para o armazenamento de objetos.

A transcodificação corre inteiramente na camada de armazenamento, isolada da instância principal do Postgres, por isso não afeta a carga de trabalho do serviço transacional. Baseia-se em algo que o Lakebase já faz: limpar dados comprometidos para armazenamento de objetos na cloud. O LTAP simplesmente adiciona o formato colunar a esse mesmo flush. Não existe nenhum pipeline para criar, nem qualquer processo externo a consultar a sua base de dados.

O Lakebase compute transmite o WAL para a camada de armazenamento, onde os safekeepers o confirmam e a camada de armazenamento do Lakebase transcodifica dados do Postgres em formato de linhas para o formato colunar Parquet, legível através de formatos de tabela abertos como Delta e Iceberg.

Nem tudo é transcodificado. Os índices Postgres mantêm-se na sua representação original na camada de armazenamento duradoura, em vez de serem convertidos em colunas, pelo que as leituras e consultas transacionais por pontos são rápidas enquanto a cópia colunar serve a análise.

Como os dados vivem em armazenamento externalizado e versionado, criar uma ramificação ou restaurar para um determinado momento é uma operação de metadados e não uma cópia física. Pode ramificar uma grande base de dados de produção em segundos, executar um experimento ou uma migração arriscada contra o ramo e descartá-lo, sem duplicar os dados subjacentes.

Note

Um ramo do Lakebase é um clone com cópia por escrita do armazenamento da sua base de dados: partilha os dados existentes do ramo progenitor e armazena apenas o que é alterado, pelo que não duplica quaisquer dados à partida. A restauração em ponto no tempo utiliza o mesmo armazenamento versionado para devolver uma base de dados a um momento anterior dentro da sua janela de restauro. Para saber mais, consulte Ramificações da base de dados e Restauro para um ponto anterior no tempo.

Esta abordagem ao nível de armazenamento é o que distingue o LTAP da captura de dados de alteração (CDC). O CDC replica dados do seu armazenamento OLTP para uma camada de análise separada, usando um processo externo que sonda continuamente a base de dados principal e um pipeline que transforma alterações de linhas em dados colunares. Esse fluxo consome recursos na sua base de dados transacional principal, obriga-o a gerir alterações ao esquema e casos extremos, e impõe um compromisso entre a atualidade dos dados e o custo do fluxo, ao mesmo tempo que acrescenta pontos de falha. O LTAP adota, em vez disso, uma abordagem ao nível do armazenamento: o armazenamento do Lakebase transcodifica os dados para o data lake como parte da operação normal de armazenamento, sem qualquer processo externo a competir com a sua carga de trabalho e sem qualquer cadeia de processamento que tenha de criar ou manter.

Os três pilares do LTAP

Unificar dados na camada de armazenamento confere ao LTAP três propriedades definidoras.

  • Governação 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 feitos de propósito. A Postgres serve transações e o Lakehouse serve análises, e nenhum compromete o outro.
  • Uma única cópia lógica em armazenamento aberto. Ambos os motores leem uma cópia dos seus dados em formatos abertos, sem réplicas ou pipelines para manter sincronizados.

O Unity Catalog gere uma única cópia lógica dos dados, uma vez que o Lakebase serve OLTP a partir de páginas do Postgres e o Lakehouse serve OLAP a partir de ficheiros Parquet colunares, assente numa única cópia num armazenamento aberto, sem replicação.

Governação universal

O Unity Catalog regula o acesso analítico aos seus dados em ambas as cargas de trabalho. Depois de registar uma base de dados Lakebase, o Unity Catalog aplica permissões, linhagem e auditoria ao computador externo que a lê.

Note

A governação do Unity Catalog aplica-se atualmente ao acesso analítico: à computação externa, como o Lakehouse//RT e o Change Data Feed, que lê os seus dados registados no Lakebase. Ainda não governa diretamente as tabelas individuais do Postgres. O acesso através do caminho transacional , ou seja, aplicações e clientes que se ligam ao Postgres, continua a ser controlado pelos privilégios padrão do Postgres (GRANT e REVOKE), e não pelo Catálogo Unity. Na prática, o Unity Catalog controla o acesso analítico e ao lakehouse, enquanto os papéis e privilégios do Postgres controlam o acesso transacional.

Motores concebidos especificamente

A Postgres serve a sua carga de trabalho transacional e a Lakehouse serve análises, cada uma com as forças para as quais foi criada. Um equívoco comum é pensar que unificar ambos significa que os seus dados operacionais se tornam dados frios armazenados no Iceberg. Não é esse o caso. Lakebase mantém-se no Postgres padrão. Indexação, ramificação, recuperação para um ponto no tempo, extensões e leituras e escritas pontuais de baixa latência continuam todas a funcionar exatamente como funcionam hoje.

As leituras analíticas não competem com a tua carga de trabalho transacional porque estão isoladas da instância principal do Postgres. Quando um motor analítico como o Lakehouse//RT consulta dados Lakebase em tempo real, devolve um resultado fresco e transacionalmente consistente sem copiar dados:

  • O mecanismo lê a maior parte dos dados da cópia em colunas no armazenamento por objetos, não do Postgres.
  • Para obter uma vista transacionalmente consistente, solicita ao Postgres apenas o número de sequência atual do registo (LSN), um único valor que assinala uma posição no registo de escrita antecipada. Isto é uma consulta barata de metadados.
  • Para o pequeno conjunto de alterações muito recentes que ainda não se materializaram no lago, ele lê-las do servidor de páginas e funde-as no topo.

O Postgres não serve nenhum tráfego analítico de leitura para além de devolver aquele único LSN, e a transcodificação corre na camada de armazenamento, não na instância Postgres que serve a sua aplicação. A sua carga de trabalho operacional continua a funcionar como esperado.

Uma única cópia lógica em armazenamento aberto

Como os dados residem no lago em formato colunar Parquet, acessível através de formatos de tabela abertos como Delta e Iceberg, o Lakebase (OLTP) e o Lakehouse (OLAP) partilham a mesma base de armazenamento. Mantém uma cópia lógica dos dados em ambas as cargas de trabalho, em vez de reconciliar uma base de dados transacional com uma cópia analítica separada.

Cada motor pode armazenar ou representar esses dados num formato físico diferente para o desempenho. O Lakebase utiliza páginas do Postgres para leituras pontuais OLTP rápidas, e os motores de análise leem ficheiros Parquet colunares. Continuas a trabalhar 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, por isso os mesmos dados estão disponíveis para as suas aplicações e para a análise sem uma segunda cópia.

Precisas de mudar a forma como usas o Lakebase

No. Adotar capacidades LTAP não requer uma migração de dados nem uma alteração na forma como as suas aplicações se ligam ao Lakebase. O Lakebase mantém-se no Postgres padrão: as suas extensões, índices, consultas e código de aplicação existentes continuam a funcionar inalterados. Cada uma das capacidades LTAP é independente, por isso podes adotar qualquer uma delas sempre que a carga de trabalho precisar.

Funcionalidades que implementam LTAP

Aplica-se a arquitetura LTAP através de um conjunto de capacidades do Lakebase. Cada um constrói-se sobre a base de armazenamento partilhado descrito acima e, juntos, cobrem os caminhos que os dados percorrem através do LTAP:

  • Gerir e registar: traga os dados do Lakebase para o Unity Catalog.
  • Disponibilize dados do lakehouse no Lakebase: tabelas sincronizadas, otimizadas com LTAP Direct Writes.
  • Consultar dados ao vivo do Lakebase: Lakehouse//RT para análise, Lakebase Change Data Feed para fluxos de alteração.

O diagrama seguinte mostra como estas capacidades escrevem e leem a partir de uma cópia dos seus dados, governada pelo Unity Catalog.

Como os dados se movem através do LTAP: tabelas sincronizadas e escritas diretas LTAP carregam os dados do lakehouse no Lakebase, a aplicação escreve e lê o Lakebase transacionalmente, o Lakebase materializa-se numa cópia dos dados em armazenamento aberto governado pelo Unity Catalog, e o Lakehouse//RT lê essa cópia em tempo real enquanto o Change Data Feed transmite alterações ao nível das linhas para as tabelas e pipelines Delta.

O Lakehouse//RT e o Lakebase Change Data Feed leem ambos os mesmos dados subjacentes, mas representam-nos de forma diferente. O Lakehouse//RT lê o estado atual dos dados Postgres em tempo real para análise. O Change Data Feed disponibiliza um fluxo de alterações ao nível da linha para pipelines subsequentes e fins de auditoria. Também não o é o CDC externo que o LTAP remove: ambos operam com a única cópia dos dados.

A tabela seguinte lista todas as capacidades LTAP e o que fazem, juntamente com o seu estado de lançamento na cloud. A disponibilidade varia consoante a cloud, por isso uma funcionalidade que não é oferecida na sua cloud é marcada como não disponível.

Capability Situação Description
Registe o Lakebase no Catálogo Unity disponibilidade geral Gerir o acesso analítico aos dados do Lakebase e executar consultas entre várias origens a partir do lakehouse.
Forneça dados com tabelas sincronizadas disponibilidade geral Servir os dados da tabela do Unity Catalog no Lakebase para leituras OLTP de baixa latência. O LTAP Direct Writes (Beta) acelera a carga inicial em todos os modos de sincronização, além de atualizações completas.
Lakehouse//RT a consultar a Lakebase Beta Execute consultas OLAP transacionalmente consistentes em dados Postgres ao vivo, sem afetar o desempenho do OLTP do Lakebase.
Fluxo de dados de alterações do Lakebase Pré-visualização Pública Armazene as alterações ao nível da linha das tabelas Postgres do Lakebase como tabelas Delta do Unity Catalog para pipelines downstream e auditoria.

Como abordar a implementação

Agora que conhece as capacidades, a questão é quais são as que a sua carga de trabalho precisa. Implementa o LTAP combinando as capacidades que correspondem à forma como os dados fluem na 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 escritor, e isso determina quais as capacidades que utiliza.

  • Lakebase tem a propriedade de escrita. A tua aplicação escreve para o Postgres, e queres que esses dados operacionais estejam disponíveis para análise sem os copiar. Por exemplo, uma aplicação de vendas escreve encomendas e pagamentos para a Lakebase à medida que acontecem. Utilize o Lakehouse//RT para executar um painel de receitas em tempo real com base nessas encomendas, ou o Lakebase Change Data Feed para transmitir em fluxo cada alteração de encomenda para um pipeline a jusante ou para um registo de auditoria.
  • A casa do lago detém a escrita. Os seus dados são produzidos ou mantidos no lakehouse, e pretende leituras OLTP com baixa latência a partir da sua aplicação. Por exemplo, um trabalho noturno na casa do lago calcula recomendações de produtos ou uma tabela de preços. Use tabelas sincronizadas para servir esses dados no Lakebase para que a sua aplicação possa lê-los com baixa latência, e ative as Escritas Diretas LTAP para acelerar a carga inicial de uma tabela grande.

Mapeie cada conjunto de dados para uma destas direções, registe-a na base de dados no Unity Catalog para governação e depois siga a documentação de capacidades para implementar cada caminho. Uma única aplicação usa frequentemente ambas as direções: alimentando o PostgreSQL com dados de referência do lakehouse, enquanto expõe as suas próprias operações transacionais de escrita de volta para a camada analítica. A disponibilidade varia consoante a cloud, por isso consulte a tabela de capacidades acima para confirmar o que está disponível na sua cloud.

Passos seguintes

Mais informações

  • Last updated on