Limitations du connecteur PostgreSQL

Cette page répertorie les limitations et considérations relatives à l’ingestion PostgreSQL à l’aide de Databricks Lakeflow Connect.

Limitations générales du connecteur de base de données

Les limitations de cette section s’appliquent à tous les connecteurs de base de données dans Lakeflow Connect. Continuez à lire les limitations spécifiques au connecteur.

• Lorsque vous exécutez un pipeline planifié, les alertes ne se déclenchent pas immédiatement. Au lieu de cela, elles se déclenchent lorsque la prochaine mise à jour s’exécute.
• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer manuellement la table de destination. Ce comportement n’est pas cohérent avec le comportement des pipelines déclaratifs Spark Lakeflow.
• Pendant les périodes de maintenance source, Databricks peut ne pas être en mesure d’accéder à vos données.
• Si un nom de table source est en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• Le support du pipeline multi-destination est disponible uniquement via l'API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, elle devient un pipeline API uniquement et vous ne pouvez plus modifier le pipeline dans l’interface utilisateur.
• Si vous sélectionnez une colonne après le démarrage d’un pipeline, le connecteur ne reremplit pas automatiquement les données de la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement une actualisation complète sur la table.
• Databricks ne peut pas ingérer deux tables ou plus portant le même nom dans le même pipeline, même si elles proviennent de schémas sources différents.
• Le système source suppose que les colonnes de curseur augmentent de façon monotonique.

• Les pipelines d’ingestion gérés ne sont pas pris en charge pour les espaces de travail dans les régions Azure GovCloud.

• Avec le type SCD 1 activé, les suppressions ne produisent pas d’événement explicite delete dans le flux de données de modification. Pour les suppressions auditables, utilisez le type SCD 2 si le connecteur le prend en charge. Pour plus d’informations, consultez l’exemple : traitement de type SCD 1 et de type SCD 2 avec des données sources CDF.
• Le connecteur ingère des données brutes sans transformations. Utilisez les pipelines déclaratifs de Lakeflow Spark en aval pour les transformations.

• Le connecteur prend uniquement en charge la réplication à partir d’instances PostgreSQL principales.

Authentication

• Le connecteur prend uniquement en charge l’authentification par nom d’utilisateur et mot de passe.

Variations de base de données

• Le connecteur prend en charge PostgreSQL 13 ou version ultérieure.
• Le connecteur prend en charge AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database pour PostgreSQL, les machines virtuelles Azure et GCP Cloud SQL pour PostgreSQL. Le connecteur prend également en charge PostgreSQL local à l’aide d’Azure ExpressRoute, AWS Direct Connect et de la mise en réseau VPN.

Pipelines

• Chaque pipeline d’ingestion doit être associé à une seule passerelle d’ingestion.
• Bien que le pipeline d’ingestion s’exécute sur une infrastructure sans serveur, la passerelle d’ingestion doit s’exécuter sur une infrastructure traditionnelle.
• La passerelle d’ingestion doit fonctionner en mode continu pour prévenir l'encombrement du Write-Ahead Log (WAL) et l'accumulation des slots de réplication.

Réplication

• La réplication logique nécessite PostgreSQL 13 ou version ultérieure avec le wal_level paramètre défini sur logical.

• Chaque table que vous répliquez doit avoir son identité de réplica définie sur FULL ou DEFAULT. Databricks recommande d’utiliser l'identité de réplica FULL pour les tables sans clés primaires ou avec des colonnes TOASTables.
• Les emplacements de réplication ne sont pas automatiquement supprimés lorsque vous supprimez des pipelines. Vous devez nettoyer manuellement les emplacements de réplication pour empêcher l'accumulation de WAL. Consultez Nettoyer les emplacements de réplication.

Évolution du schéma

Le connecteur gère automatiquement les colonnes nouvelles et supprimées.

• Lorsqu’une nouvelle colonne apparaît dans la source, Databricks l’intègre automatiquement lors de l’exécution suivante du pipeline.
• Lorsqu’une colonne est supprimée de la source, Databricks ne la supprime pas automatiquement. Au lieu de cela, le connecteur utilise une propriété de table pour attribuer à la colonne supprimée la valeur inactive dans la destination. Si une autre colonne apparaît ultérieurement avec un nom en conflit avec la inactive colonne, le pipeline échoue. Dans ce cas, exécutez une actualisation complète de la table ou supprimez manuellement la colonne inactive.

Le connecteur peut gérer les DLL mentionnées ci-dessous (par exemple, les renommages de colonnes), mais nécessite une actualisation complète des tables cibles.

DDL nécessite une actualisation complète

• Modification du type de données d’une colonne
• Renommage d’une colonne
• Modification de la clé primaire d’une table
• Conversion d’une table non journalisée en journalisation ou inversement
• Ajout ou suppression de partitions (pour les tables partitionnées)

Staging

Le catalogue de mise en scène ne peut pas être un catalogue étranger.

Tables

• Databricks recommande d’ingérer 250 tables au maximum par pipeline. Toutefois, il n’existe aucune limite quant au nombre de lignes ou de colonnes prises en charge dans ces tables.
• Databricks ne peut pas ingérer deux tables dont les noms diffèrent uniquement dans le cas (par exemple, mytable et MyTable) à l’aide d’un pipeline. Pour prendre en charge ces cas, créez deux paires de pipelines d’ingestion de gateway qui publient sur différents schémas cibles.
• Les noms source_catalog, source_schema, et source_table sont sensibles à la casse pour le nom de la base de données, mais insensibles à la casse pour les noms de schéma et de table (suivant le comportement par défaut de PostgreSQL). Par exemple, si la base de données source est nommée MyDatabase, vous devez la spécifier comme MyDatabase dans le ingestion_definition.
• Bien que vous puissiez ingérer à partir de plusieurs bases de données ou schémas sources dans un pipeline, vous ne pouvez pas ingérer deux tables du même nom. Par exemple, vous ne pouvez pas ingérer les deux schema1.orders et schema2.orders dans le même pipeline.
• Vous pouvez inclure plusieurs spécifications de table ou de schéma dans le objects champ du ingestion_definition. Toutefois, les noms de tables sources dans différents schémas sources ne peuvent pas se chevaucher. Les noms qui se chevauchent entraînent l’échec du pipeline d’ingestion.

Types de données

• Les types définis par l’utilisateur et les types d’extension tiers sont ingérés en tant que chaînes.
• Les types de données TIME et TIMETZ sont ingérés sous forme de chaînes.
• Tout type de données intégré PostgreSQL non répertorié dans la table transformations de données automatiques est ingéré en tant que chaîne.
• Pour le type de données numérique : NaN est converti en null.
• Pour la date et l’horodatage : nous ne prenons pas en charge les dates avant 9999 après J.-C. ni les dates av. J.-C.
• L’infini n’est pas pris en charge pour la date, l’horodatage ou l’intervalle.

tables partitionnées ;

• La prise en charge des tables PostgreSQL partitionnées est assurée.
• Chaque partition est traitée comme une table distincte à des fins de réplication.
• L’ajout ou la suppression de partitions nécessite une actualisation complète de la table.

Limitations pour les variantes PostgreSQL spécifiques

Amazon RDS et Aurora

• Le rds.logical_replication paramètre doit être défini sur 1.

Base de données Azure pour PostgreSQL

• La réplication logique doit être activée dans les paramètres du serveur.
• Pour les déploiements à serveur unique, la réplication logique n’est disponible que dans les niveaux Usage général et Mémoire optimisée.
• Pour les déploiements de serveur flexible, la réplication logique est prise en charge sur tous les niveaux.
• Le max_wal_slot_keep_size parameter est en lecture seule, fixe à -1 (infini) et ne peut pas être configuré.

Google Cloud SQL pour PostgreSQL

• L’indicateur cloudsql.logical_decoding doit être activé.
• Cloud SQL n’autorise pas la configuration de max_wal_slot_keep_size ; elle est fixe à -1 (infinie) par défaut.