Pular para o conteúdo principal
Última atualização em

limitações do conector PostgreSQL

info

Visualização

O conector PostgreSQL para LakeFlow Connect está em versão prévia pública. Entre em contato com a equipe da sua account Databricks para se inscrever na Prévia Pública.

Esta página lista as limitações e considerações para a ingestão de PostgreSQL usando Databricks LakeFlow Connect.

Limitações gerais do conector de banco de dados​

As limitações desta seção aplicam-se a todos os conectores de banco de dados no LakeFlow Connect. Continue lendo para conhecer as limitações específicas de cada conector.

  • Ao executar um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, elas são acionadas na próxima execução da atualização.

  • Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do pipeline declarativo LakeFlow Spark .

  • O catálogo de encenação não pode ser um catálogo estrangeiro.

  • Durante períodos de manutenção da fonte de dados, o Databricks poderá não conseguir acessar seus dados.

  • Se o nome de uma tabela de origem entrar em conflito com o nome de uma tabela de destino existente, a atualização do pipeline falhará.

  • O suporte pipeline com múltiplos destinos é feito exclusivamente via API.

  • Opcionalmente, você pode renomear uma tabela que você importa. Se você renomear uma tabela em seu pipeline, ele se tornará um pipeline somente para API e você não poderá mais editá- pipeline na interface do usuário.

  • Se você selecionar uma coluna depois que um pipeline já tiver sido iniciado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, execute manualmente uma refresh completa na tabela.

  • O Databricks não consegue ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas provenham de esquemas de origem diferentes.

  • O sistema de origem pressupõe que as colunas do cursor estejam em ordem crescente monotônica.

  • O pipeline de ingestão gerencia não é compatível com espaços de trabalho FedRAMP High ou FedRAMP Moderate .

  • O conector ingere dados brutos sem transformações. Use o pipeline declarativo LakeFlow Spark downstream para transformações.

  • O conector suporta apenas replicação de instâncias primárias do PostgreSQL.

Autenticação​

  • O conector suporta apenas autenticação por nome de usuário e senha.

Variações do banco de dados​

  • O conector é compatível com PostgreSQL 13 ou superior.
  • O conector é compatível com AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Banco de Dados Azure para PostgreSQL, máquinas virtuais Azure e Cloud SQL GCP para PostgreSQL. O conector também oferece suporte ao PostgreSQL on-premises usando Azure ExpressRoute, AWS Direct Connect e redes VPN.

oleoduto​

  • Cada pipeline de ingestão deve estar associado a exatamente um gateway de ingestão. Os gateways não podem ser compartilhados entre diferentes pipelines.
  • Embora o pipeline de ingestão seja executado em compute serverless , o gateway de ingestão deve ser executado em compute clássica.
  • O gateway de ingestão deve ser executado em modo contínuo para evitar o inchaço do Write-Ahead Log (WAL) e o acúmulo de slots de replicação.

Replicação​

  • Para AWS RDS e Aurora, defina o parâmetro rds.logical_replication como 1.

  • Cada tabela que você replica deve ter sua identidade de réplica definida como FULL ou DEFAULT. Databricks recomenda o uso de identidade de réplica FULL para tabelas sem chave primária ou com colunas TOASTable.

  • Os slots de replicação não são removidos automaticamente quando você exclui um pipeline. Você deve limpar manualmente os slots de replicação para evitar o acúmulo de WALs. Consulte Limpar slots de replicação.

evolução do esquema​

O conector lida automaticamente com colunas novas e excluídas.

  • Quando uma nova coluna aparece na fonte de dados, o Databricks a incorpora automaticamente na próxima execução do pipeline.
  • Quando uma coluna é excluída da fonte de dados, o Databricks não a exclui automaticamente. Em vez disso, o conector usa uma propriedade da tabela para definir a coluna excluída como inactive no destino. Se outra coluna aparecer posteriormente com um nome conflitante com a coluna inactive , o pipeline falhará. Nesse caso, execute uma refresh completa da tabela ou remova manualmente a coluna inativa.

O conector consegue lidar com os DDLs mencionados abaixo (por exemplo, renomeação de colunas), mas requer uma refresh completa das tabelas de destino.

DDLs que exigem refreshcompleta​

  • Alterar o tipo de dados de uma coluna
  • Renomear uma coluna
  • Alterar a key primária de uma tabela
  • Converter uma tabela de não registrada para registrada ou vice-versa.
  • Adicionar ou remover partições (para tabelas particionadas)

Encenação​

O catálogo de encenação não pode ser um catálogo estrangeiro.

Tabelas​

  • A Databricks recomenda a ingestão de 250 tabelas ou menos por pipeline. No entanto, não há limite para o número de linhas ou colunas que podem ser suportadas nessas tabelas.
  • O Databricks não pode ingerir duas tabelas cujos nomes diferem apenas em maiúsculas e minúsculas (por exemplo, mytable e MyTable) usando um único pipeline. Para dar suporte a esses casos, crie dois pares pipeline de gateway-ingestão que publiquem em esquemas de destino diferentes.
  • Os nomes source_catalog, source_schema e source_table diferenciam maiúsculas de minúsculas para o nome do banco de dados, mas não diferenciam maiúsculas de minúsculas para os nomes do esquema e da tabela (seguindo o comportamento default PostgreSQL ). Por exemplo, se o banco de dados de origem for nomeado MyDatabase, você deve especificá-lo como MyDatabase no ingestion_definition.
  • Embora seja possível ingerir dados de vários bancos de dados ou esquemas de origem em um único pipeline, não é possível ingerir duas tabelas com o mesmo nome. Por exemplo, você não pode ingerir schema1.orders e schema2.orders no mesmo pipeline.
  • Você pode incluir várias especificações de tabela ou esquema no campo objects do ingestion_definition. No entanto, os nomes das tabelas de origem em diferentes esquemas de origem não podem se sobrepor. Nomes sobrepostos resultam em falha no pipeline de ingestão.

Tipos de dados​

  • Os tipos definidos pelo usuário e os tipos de extensão de terceiros são inseridos como strings.

  • Os tipos de dados TIME e TIMETZ são ingeridos como strings.

  • Para os tipos de dados NUMERIC e DECIMAL :

    • Se a precisão for 38 ou menos, NaN é mapeado para null.
    • Se a precisão for maior que 38, o valor é armazenado como uma string e NaN é preservado como uma string.
    • Inf e -Inf são suportados apenas para tipos numéricos ilimitados. Para precisões maiores que 38, o valor é armazenado como uma string e o valor infinito é preservado.

  • Para o tipo de dados DATE : Todo o intervalo de datas do PostgreSQL é suportado. Inf e -Inf são convertidos em null. As datas a.C. são armazenadas usando a numeração de anos astronômicos. Por exemplo, 1 a.C. corresponde ao ano 0 e 2 a.C. corresponde a -1.

  • Para o tipo de dados TIMESTAMP (sem fuso horário): os valores são inseridos como strings. Inf e -Inf são preservados como strings.

  • Para o tipo de dados TIMESTAMP WITH TIME ZONE : O intervalo suportado pelo PostgreSQL é de 4713-01-01 00:00:00.000000 BC a 294276-12-31 23:59:59.999999 AD, enquanto o intervalo suportado pelo Databricks é de -290308-12-21 BCE 19:59:06 GMT a +294247-01-10 CE 04:00:54 GMT. Os timestamps acima do timestamp máximo suportado pelo Databricks são convertidos para null. As datas a.C. são armazenadas usando a numeração de anos astronômicos. Por exemplo, 1 a.C. corresponde ao ano 0 e 2 a.C. corresponde a -1. Inf e -Inf são convertidos em null.

  • Para o tipo de dados INTERVAL : os valores infinitos são mapeados para 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs.

  • MONEY Os valores são recebidos como strings.

  • Qualquer tipo de dado integrado PostgreSQL que não esteja listado na tabela de transformações automáticas de dados é ingerido como string.

Tabelas particionadas​

  • O PostgreSQL suporta tabelas particionadas.
  • Para fins de replicação, cada partição é tratada como uma tabela separada.
  • Adicionar ou remover partições requer uma refresh completa da tabela.

Limitações para variações específicas do PostgreSQL​

Amazon RDS e Aurora​

  • O parâmetro rds.logical_replication deve ser definido como 1.

Banco de Dados do Azure para PostgreSQL​

  • A replicação lógica deve estar habilitada nos parâmetros do servidor.
  • Para implantações de servidor único, a replicação lógica está disponível apenas nos planos de uso geral e otimizado para memória.
  • Para implementações do Flexible Server, a replicação lógica é suportada em todos os níveis.
  • O parâmetro max_slot_wal_keep_size é somente leitura, fixo em -1 (infinito) e não pode ser configurado.

Google Cloud SQL para PostgreSQL​

  • O sinalizador cloudsql.logical_decoding deve estar ativado.
  • O Cloud SQL não permite configurar max_slot_wal_keep_size; por default, ele é fixo em -1 (infinito).