Présentation de l'accès AlloyDB aux données en temps réel dans BigQuery

Pour exécuter des requêtes en temps réel sur des données analytiques en même temps que vos données opérationnelles sans créer de pipelines complexes, vous pouvez utiliser la fédération de lakehouse dans AlloyDB pour PostgreSQL. Grâce à l'extension bigquery_fdw, AlloyDB achemine vos requêtes vers BigQuery pour accéder aux données actives et aux formats ouverts tels qu'Apache Iceberg via des tables externes BigLake, ce qui élimine le besoin de migrations ETL (extraction, transformation, chargement) complexes.

Vous pouvez également interroger des tables Apache Iceberg stockées dans Cloud Storage ou enregistrées dans le catalogue d'environnements d'exécution Lakehouse sans acheminer l'exécution des requêtes via BigQuery, en utilisant le moteur de données en colonnes AlloyDB. Pour en savoir plus, consultez Accéder aux données Iceberg depuis AlloyDB.

Avantages de la fédération de lakehouse

L'approche de fédération de lakehouse offre les avantages suivants :

  • Zéro ETL : interrogez directement les données analytiques sans créer ni gérer de pipelines complexes.
  • Syntaxe familière : utilisez la syntaxe PostgreSQL standard pour interroger les données BigQuery.
  • Insights en temps réel : accédez à des données récentes en plus de vos tables opérationnelles.
  • Décharger le calcul : utilisez le moteur distribué de BigQuery pour les tâches lourdes grâce à l'optimisation du pushdown.
  • Accès autorisé : pour vous assurer que seuls les comptes de service autorisés peuvent interroger des données externes, utilisez Identity and Access Management (IAM) pour un contrôle des accès centralisé.

Cas d'utilisation

La fédération de lakehouses est compatible avec les cas d'utilisation métier et techniques suivants :

  • Charges de travail de traitement transactionnel et analytique hybride (HTAP) : vous pouvez interroger simultanément des données opérationnelles en temps réel dans AlloyDB et des données historiques ou analytiques dans BigQuery ou Cloud Storage sans affecter les performances transactionnelles.
  • Insights en temps réel sans pipelines fragiles : vous pouvez éviter la latence et les modes de défaillance des processus ETL traditionnels. Accédez instantanément à des données analytiques récentes pour prendre des décisions commerciales basées sur les informations les plus à jour.
  • Matérialisation des données pour les workflows agentiques : vous pouvez matérialiser des données analytiques externes dans AlloyDB pour utiliser le moteur de données en colonnes AlloyDB et les fonctionnalités d'AlloyDB AI. Cela permet d'effectuer des recherches vectorielles hautes performances, des embeddings de machine learning et des workflows agentiques avancés basés sur l'IA sur vos données fédérées.

Architecture et flux de données

Le schéma suivant illustre le flux de données et les interactions entre les composants lorsque vous utilisez la fédération de lakehouse :

Schéma montrant l'architecture de la fédération de lakehouse, illustrant le flux entre AlloyDB et BigQuery avec l'optimisation du pushdown.
Figure 1. Architecture et flux de données pour la fédération de lakehouse

Voici comment se déroule le flux de données pour la fédération de lakehouse dans AlloyDB :

  1. Envoi de la requête : vous envoyez une requête PostgreSQL standard à votre instance AlloyDB.
  2. Planification et optimisation des requêtes : le planificateur de requêtes AlloyDB identifie les tables mappées à des ensembles de données BigQuery externes à l'aide du wrapper de données externes (FDW) BigQuery.
  3. Optimisation du pushdown : AlloyDB optimise la requête en envoyant des filtres et des agrégations spécifiques directement à BigQuery. Cela garantit que le réseau ne transfère que les lignes filtrées pertinentes ou les résumés pré-agrégés.
  4. Exécution et récupération : BigQuery exécute sa partie de la requête (en analysant directement l'espace de stockage intégré de BigQuery ou en lisant les tables Apache Iceberg stockées dans Cloud Storage) et renvoie l'ensemble de données obtenu à AlloyDB.
  5. Traitement final et réponse : AlloyDB combine les données externes avec les tables opérationnelles locales, termine le traitement des requêtes restantes et renvoie le résultat final à votre application.

Considérations sur les types de données pour les requêtes fédérées

Lorsque vous interrogez une table BigQuery externe à partir d'AlloyDB à l'aide de la fédération Lakehouse, le planificateur de requêtes AlloyDB interprète les types de données BigQuery comme des types de données PostgreSQL correspondants. Il est essentiel de comprendre ces mappages pour écrire des requêtes correctes et pour les définitions de tables externes utilisées par l'extension bigquery_fdw.

Si un type de données BigQuery n'a pas de mappage direct ou nécessite un traitement spécial, vous devrez peut-être utiliser des fonctions CAST explicites dans vos requêtes ou créer une vue dans BigQuery qui présente les données avec des types compatibles.

Pour obtenir la liste des types de données compatibles et de leurs types PostgreSQL correspondants, consultez Mappages des types de données.

Sécurité et contrôle des accès

L'accès aux données BigQuery depuis AlloyDB est géré via IAM. Vous devez attribuer des rôles IAM spécifiques au compte de service du cluster AlloyDB pour définir les ensembles de données et les tables pouvant être interrogés. Cela permet de s'assurer que les requêtes fédérées respectent les règles de gouvernance des données centralisées de votre organisation sans compromettre la sécurité. Pour en savoir plus, consultez la section Rôles requis.

Pushdown

Vous pouvez utiliser des techniques de pushdown de filtres et d'agrégats, qui accélèrent les requêtes et réduisent les coûts en filtrant ou en résumant les données dans BigQuery avant qu'elles ne soient déplacées ou traitées par AlloyDB. Cette approche minimise le trafic réseau et l'utilisation de la mémoire, ce qui vous permet d'analyser rapidement et efficacement des ensembles de données volumineux sans dépasser les limites de ressources.

Pushdown de filtre

Le pushdown de filtre, également appelé pushdown de prédicat, est une technique d'optimisation qui rapproche le filtrage des données de la couche de stockage en déplaçant vos filtres de requête (à l'aide de la clause WHERE) d'AlloyDB vers BigQuery.

Le pushdown de filtre vous permet d'utiliser des requêtes SQL avec une clause WHERE pour accéder à un sous-ensemble de données de la table distante. Ces données peuvent également être matérialisées dans une table locale ou associées en tant que partition locale à une table PostgreSQL.

Les opérations compatibles avec le pushdown de filtre sont les suivantes :

  • Opérateurs de comparaison standards : =, <, >, <=, >=, <>
  • Opérateurs logiques : AND, OR et NOT
  • Correspondance de modèles : LIKE et NOT LIKE
  • Contrôle des valeurs nulles : IS NULL et IS NOT NULL

Pushdown d'agrégats

Le pushdown d'agrégation est une optimisation de base de données avancée qui effectue des calculs (par exemple, SUM, COUNT, AVG ou GROUP BY) aussi près que possible de la couche de stockage. Ce pushdown évalue les fonctions récapitulatives directement dans BigQuery, ce qui peut réduire considérablement le nombre de lignes renvoyées à AlloyDB.

Les opérations compatibles avec le pushdown d'agrégation sont les suivantes :

  • SUM
  • COUNT
  • AVG
  • MIN
  • MAX

Pushdown de limite

Le pushdown de limite (qui inclut le pushdown OFFSET) est une technique d'optimisation qui déplace les clauses LIMIT et OFFSET de votre requête d'AlloyDB vers BigQuery.

Cela permet à BigQuery de ne renvoyer que le sous-ensemble spécifique de lignes demandé, ce qui réduit considérablement le trafic réseau et la latence des requêtes.

Le pushdown de limite est appliqué automatiquement chaque fois que cela est possible. Assurez-vous que les conditions suivantes sont remplies :

  • La requête n'utilise pas l'option WITH TIES dans la clause FETCH FIRST.
  • Les expressions LIMIT et OFFSET sont des constantes ou des expressions de base qui peuvent être évaluées à distance.

Coûts et facturation BigQuery

Le wrapper de données étrangères BigQuery dépend des éléments suivants :

  • Tarifs du calcul BigQuery
  • Tarifs de l'API BigQuery Storage

Pour en savoir plus, consultez la page Tarifs de BigQuery.

Projets d'exécution

Dans BigQuery, vous pouvez stocker vos données dans un projet et exécuter vos requêtes dans un autre projet. Le projet qui exécute les requêtes et génère les coûts de calcul est appelé projet d'exécution (ou projet de facturation).

En séparant votre projet d'environnement d'exécution de votre projet de datastore, vous pouvez isoler les coûts de puissance de calcul dans des centres de coûts spécifiques, gérer les quotas de manière indépendante et contrôler les dépenses pour différentes charges de travail sans déplacer les données sous-jacentes.

Lorsque vous configurez AlloyDB pour accéder aux données BigQuery, vous pouvez spécifier un projet d'exécution au niveau du serveur (qui s'applique à toutes les tables externes associées) ou au niveau de chaque table. Si vous ne spécifiez pas de projet d'exécution, AlloyDB utilise par défaut le projet propriétaire des données.

Limites

  • AlloyDB et BigQuery peuvent utiliser des classements par défaut différents, ce qui peut entraîner des résultats de classement des données ou de comparaison de chaînes différents entre les deux systèmes. Par exemple, le classement PostgreSQL par défaut dans les versions 15, 16 et 17 peut gérer la sensibilité à la casse différemment lors du tri par rapport au classement par défaut de BigQuery, qui évalue strictement les chaînes en fonction de leurs points de code Unicode.

    Pour toute partie d'une requête exécutée à distance sur BigQuery, le classement suit les paramètres de BigQuery. Pour réduire les conflits de classement, envisagez d'utiliser le classement C.UTF-8 sans ICU dans AlloyDB et le classement par défaut (vide) dans BigQuery.

  • Les requêtes qui renvoient une grande quantité de données à partir de BigQuery, après le pushdown, ne sont pas optimisées.

  • Lorsque vous créez une table externe, AlloyDB ne valide pas activement l'existence ni le schéma de la table BigQuery distante.

  • Si une requête fédérée nécessite la lecture d'une grande quantité de données (par exemple, si les pushdowns de filtres ne peuvent pas être appliqués), elle peut échouer en raison des limites de taille de réponse de l'API BigQuery. Les limites de taille de réponse maximale de BigQuery s'appliquent toujours. Pour en savoir plus sur ces limites, consultez Quotas et limites.

  • PostgreSQL et BigQuery gèrent différemment la précision décimale, la division et les calculs intermédiaires. Ces différences peuvent entraîner des variations d'arrondi, une perte de précision ou des erreurs de dépassement lors de calculs complexes. Pour en savoir plus, consultez Types décimaux et Opérateurs arithmétiques.

  • Database Migration Service ne permet pas de migrer des tables externes créées à l'aide de l'extension bigquery_fdw. Pour contourner ce problème, vous pouvez exclure les tables externes de votre job de migration ou les supprimer avant de lancer la migration, puis les recréer sur le cluster AlloyDB de destination une fois la migration terminée.

  • Lorsque vous interrogez des tables externes à l'aide de l'extension bigquery_fdw, BigQuery évalue les autorisations d'accès aux données en fonction du compte de service du cluster AlloyDB. Même si les utilisateurs de la base de données se connectent à l'aide de l'authentification IAM pour les bases de données, leurs autorisations utilisateur IAM individuelles ne sont pas vérifiées par rapport aux tables BigQuery distantes. Pour en savoir plus, consultez Accorder à AlloyDB l'accès à l'ensemble de données BigQuery.

Étapes suivantes