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 .

  • 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 gerenciamento de pipelines de ingestão não é compatível com espaços de trabalho em regiões AWS GovCloud (FedRAMP High).

  • O pipeline de ingestão gerencia não é compatível com o espaço de trabalho FedRAMP Moderate nas regiões us-east-2 ou us-west-1 .

  • Com o SCD tipo 1 ativado, as exclusões não produzem um evento delete explícito no feed de dados de alteração. Para exclusões auditáveis, use o tipo SCD 2 se o conector o suportar. Para obter detalhes, consulte o exemplo: Processamento de SCD tipo 1 e SCD tipo 2 com dados de origem CDF.

  • 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.
  • 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.
  • Qualquer tipo de dado integrado PostgreSQL que não esteja listado na tabela de transformações automáticas de dados é ingerido como string.
  • Para tipos de dados numéricos: NaN é convertido para nulo.
  • Para data e hora: Não oferecemos suporte a datas a.C. ou datas posteriores a 9999 d.C.
  • O parâmetro "infinito" não é suportado para data, carimbo de data/hora ou intervalo.

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 max_wal_slot_keep_size parameter é 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 o parâmetro max_wal_slot_keep_size; por default ele é fixo em -1 (infinito).