Présentation des transferts de données PostgreSQL

Vous pouvez charger des données de PostgreSQL vers BigQuery à l'aide du connecteur Service de transfert de données BigQuery pour PostgreSQL. Le connecteur est compatible avec les instances PostgreSQL hébergées dans votre environnement sur site, Cloud SQL et d'autres fournisseurs de services cloud public tels qu'Amazon Web Services (AWS) et Microsoft Azure. Ce document présente les options d'ingestion de données pour votre transfert PostgreSQL, ainsi que des informations sur le mappage des types de données et la tarification.

Pour savoir comment planifier un transfert PostgreSQL, consultez Charger des données PostgreSQL dans BigQuery.

Options d'ingestion de données

Les sections suivantes fournissent des informations sur les options d'ingestion de données lorsque vous configurez un transfert de données PostgreSQL.

Configuration TLS

Le connecteur PostgreSQL est compatible avec la configuration de la sécurité au niveau du transport (TLS) pour chiffrer vos transferts de données vers BigQuery. Le connecteur PostgreSQL accepte les configurations TLS suivantes :

  • Mode Chiffrer les données, et valider la CA et le nom d'hôte. Dans ce mode, une validation complète du serveur est effectuée à l'aide de TLS sur le protocole TCPS. Il chiffre toutes les données en transit et vérifie que le certificat du serveur de base de données est signé par une autorité de certification (CA) de confiance. Ce mode vérifie également que le nom d'hôte auquel vous vous connectez correspond exactement au nom commun (CN) ou à un autre nom de l'objet (SAN) sur le certificat du serveur. Ce mode empêche les pirates d'utiliser un certificat valide pour un autre domaine afin d'emprunter l'identité de votre serveur de base de données.

    Si votre nom d'hôte ne correspond pas au CN ou au SAN du certificat, la connexion échoue. Vous devez configurer une résolution DNS correspondant au certificat ou utiliser un autre mode de sécurité. Utilisez ce mode pour bénéficier de l'option la plus sécurisée afin d'éviter les attaques de type "person-in-the-middle" (PITM).

  • Mode Chiffrer les données et valider la CA uniquement. Ce mode chiffre toutes les données à l'aide de TLS sur le protocole TCPS et vérifie que le certificat du serveur est signé par une autorité de certification approuvée par le client. Toutefois, ce mode ne valide pas le nom d'hôte du serveur. Ce mode permet d'établir une connexion tant que le certificat est valide et émis par une autorité de certification de confiance, que le nom d'hôte du certificat corresponde ou non à celui auquel vous vous connectez.

    Utilisez ce mode si vous souhaitez vous assurer de vous connecter à un serveur dont le certificat est signé par une autorité de certification de confiance, mais dont le nom d'hôte n'est pas vérifiable ou dont vous ne contrôlez pas la configuration.

  • Le mode Chiffrement uniquement. Ce mode chiffre toutes les données transférées entre le client et le serveur. Il n'effectue aucune validation de certificat ou de nom d'hôte.

    Ce mode offre un certain niveau de sécurité en protégeant les données en transit, mais il peut être vulnérable aux attaques PITM.

    Utilisez ce mode si vous devez vous assurer que toutes les données sont chiffrées, mais que vous ne pouvez pas ou ne souhaitez pas valider l'identité du serveur. Nous vous recommandons d'utiliser ce mode lorsque vous travaillez avec des VPC privés.

  • Le mode Aucun chiffrement ni aucune vérification. Ce mode ne chiffre aucune donnée et n'effectue aucune vérification de certificat ou de nom d'hôte. Toutes les données sont envoyées en texte brut.

    Nous vous déconseillons d'utiliser ce mode dans un environnement où des données sensibles sont traitées. Nous vous recommandons de n'utiliser ce mode qu'à des fins de test sur un réseau isolé où la sécurité n'est pas un problème.

Certificat de serveur fiable (PEM)

Si vous utilisez le mode Chiffrer les données, et valider la CA et le nom d'hôte ou le mode Chiffrer les données, et valider la CA, vous pouvez également fournir un ou plusieurs certificats encodés au format PEM. Ces certificats sont requis dans certains scénarios où le service de transfert de données BigQuery doit vérifier l'identité de votre serveur de base de données lors de la connexion TLS :

  • Si vous utilisez un certificat signé par une autorité de certification privée au sein de votre organisation ou un certificat autosigné, vous devez fournir la chaîne de certificats complète ou le certificat autosigné unique. Cela est nécessaire pour les certificats émis par les autorités de certification internes des services de fournisseur de cloud gérés, tels qu'Amazon Relational Database Service (RDS).
  • Si le certificat de votre serveur de base de données est signé par une autorité de certification publique (par exemple, Let's Encrypt, DigiCert ou GlobalSign), vous n'avez pas besoin de fournir de certificat. Les certificats racine de ces autorités de certification publiques sont préinstallés et approuvés par le service de transfert de données BigQuery.

Vous pouvez spécifier des certificats encodés au format PEM dans le champ Certificat PEM de confiance de la configuration de transfert, en respectant les exigences suivantes :

  • Le certificat doit être une chaîne de certificats valide encodée au format PEM.
  • Le certificat doit être entièrement correct. Tout certificat manquant dans la chaîne ou tout contenu incorrect entraîne l'échec de la connexion TLS.
  • Pour un seul certificat, vous pouvez fournir un seul certificat autosigné provenant du serveur de base de données.
  • Pour une chaîne de certificats complète émise par une CA privée, vous devez fournir la chaîne de confiance complète. Cela inclut le certificat du serveur de base de données, ainsi que tous les certificats CA intermédiaires et racines.

Transferts complets ou incrémentiels

Vous pouvez spécifier la manière dont les données sont chargées dans BigQuery en sélectionnant la préférence d'écriture Complète ou Incrémentielle dans la configuration de transfert lorsque vous configurez un transfert PostgreSQL.

Vous pouvez configurer un transfert de données complet pour transférer toutes les données de vos ensembles de données PostgreSQL à chaque transfert de données.

Vous pouvez également configurer un transfert de données incrémentiel pour ne transférer que les données qui ont été modifiées depuis le dernier transfert de données, au lieu de charger l'ensemble de données complet à chaque transfert de données. Si vous sélectionnez Incrémentiel pour votre transfert de données, vous devez spécifier le mode d'écriture Ajouter ou Faire un upsert pour définir la manière dont les données sont écrites dans BigQuery lors d'un transfert de données incrémentiel. Les sections suivantes décrivent les modes d'écriture disponibles.

Mode d'écriture "Ajouter"

Le mode d'écriture "Ajouter" n'insère que de nouvelles lignes dans votre table de destination. Cette option ajoute strictement les données transférées sans vérifier l'existence d'enregistrements. Ce mode peut donc entraîner la duplication des données dans la table de destination.

Lorsque vous sélectionnez le mode d'ajout, vous devez sélectionner une colonne de filigrane. Une colonne de filigrane est requise pour que le connecteur PostgreSQL puisse suivre les modifications dans la table source.

Pour les transferts PostgreSQL, nous vous recommandons de sélectionner une colonne qui n'est mise à jour que lors de la création de l'enregistrement et qui ne changera pas lors des mises à jour ultérieures, par exemple la colonne CREATED_AT.

Mode d'écriture Upsert

Le mode d'écriture "upsert" met à jour une ligne ou en insère une nouvelle dans votre table de destination en vérifiant la présence d'une clé primaire. Vous pouvez spécifier une clé primaire pour permettre au connecteur PostgreSQL de déterminer les modifications nécessaires pour maintenir votre table de destination à jour avec votre table source. Si la clé primaire spécifiée est présente dans la table BigQuery de destination lors d'un transfert de données, le connecteur PostgreSQL met à jour cette ligne avec les nouvelles données de la table source. Si aucune clé primaire n'est présente lors d'un transfert de données, le connecteur PostgreSQL insère une nouvelle ligne.

Lorsque vous sélectionnez le mode "Upsert", vous devez sélectionner une colonne de filigrane et une clé primaire :

  • Une colonne de filigrane est requise pour que le connecteur PostgreSQL puisse suivre les modifications apportées à la table source.
    • Sélectionnez une colonne de filigrane qui est mise à jour chaque fois qu'une ligne est modifiée. Nous vous recommandons des colonnes semblables à la colonne UPDATED_AT ou LAST_MODIFIED.

  • La clé primaire peut être une ou plusieurs colonnes de votre table, nécessaires au connecteur PostgreSQL pour déterminer s'il doit insérer ou mettre à jour une ligne.

    Sélectionnez les colonnes qui contiennent des valeurs non nulles et uniques pour toutes les lignes du tableau. Nous vous recommandons d'utiliser des colonnes incluant des identifiants générés par le système, des codes de référence uniques (par exemple, des ID à incrémentation automatique) ou des ID de séquence temporels immuables.

    Pour éviter toute perte ou corruption de données, les colonnes de clé primaire que vous sélectionnez doivent contenir des valeurs uniques. Si vous avez des doutes sur l'unicité de la colonne de clé primaire choisie, nous vous recommandons d'utiliser plutôt le mode d'écriture "Ajouter".

Comportement d'ingestion incrémentielle

Lorsque vous modifiez le schéma de table dans votre source de données, les transferts de données incrémentiels à partir de ces tables sont reflétés dans BigQuery de la manière suivante :

Modifications apportées à la source de données Comportement d'ingestion incrémentielle
Ajouter une colonne Une colonne est ajoutée à la table BigQuery de destination. Tous les enregistrements précédents de cette colonne auront des valeurs nulles.
Supprimer une colonne La colonne supprimée reste dans la table BigQuery de destination. Les nouvelles entrées de cette colonne supprimée sont renseignées avec des valeurs nulles.
Modifier le type de données d'une colonne Le connecteur n'accepte que les conversions de types de données compatibles avec l'instruction LDD ALTER COLUMN. Toute autre conversion de type de données entraîne l'échec du transfert de données.

Si vous rencontrez des problèmes, nous vous recommandons de créer une configuration de transfert.
Renommer une colonne La colonne d'origine reste telle quelle dans la table BigQuery de destination, tandis qu'une nouvelle colonne est ajoutée à la table de destination avec le nom mis à jour.

Mappage des types de données

Le tableau suivant mappe les types de données PostgreSQL aux types de données BigQuery correspondants :

Type de données PostgreSQL Type de données BigQuery Type de données BigQuery mis à jour
array STRING
bigint INTEGER
bigserial INTEGER
bit(n) STRING
bit varying(n) STRING
boolean BOOLEAN
box STRING
bytea BYTES
character STRING
character varying STRING
cidr STRING
circle STRING
circularstring STRING
compoundcurve STRING
curvepolygon STRING
date DATE
double precision FLOAT
enum STRING
geometrycollection STRING
inet STRING
integer INTEGER
interval STRING
json STRING JSON
jsonb STRING JSON
line STRING
linestring STRING
lseg STRING
macaddr STRING
macaddr8 STRING
money STRING
multicurve STRING
multilinestring STRING
multipoint STRING
multipolygon STRING
multisurface STRING
numeric(precision, scale)/decimal(precision, scale) NUMERIC
path STRING
point STRING
polygon STRING
polyhedralsurface STRING
range STRING
real FLOAT
serial INTEGER
smallint INTEGER
smallserial INTEGER
text STRING
time [ (p) ] [ without timezone ] TIMESTAMP
time [ (p) ] with time zone TIMESTAMP
tin STRING
timestamp [ (p) ] [ without timezone ] TIMESTAMP DATETIME
timestamp [ (p) ] with time zone TIMESTAMP
triangle STRING
tsquery STRING
tsvector STRING
uuid STRING
xml STRING

Tarifs

Pour connaître les tarifs des transferts PostgreSQL, consultez la page Tarifs du service de transfert de données.

Étapes suivantes