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

Aperçu

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour exécuter des requêtes en temps réel sur des données analytiques en parallèle de 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 (extract, transform, load) complexes.

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 aux données actualisées en parallèle de vos tables opérationnelles.
• Déchargez le calcul : utilisez le moteur distribué BigQuery pour les tâches lourdes grâce à l'optimisation 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 contrôle des accès centralisé.

Cas d'utilisation

La fédération de lakehouse est compatible avec les cas d'utilisation professionnels 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 aux données analytiques actualisées pour prendre des décisions métier basées sur les informations les plus récentes.
• Matérialisation des données pour les workflows d'agent : 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'IA AlloyDB. Cela permet d'effectuer des recherches vectorielles hautes performances, des embeddings de machine learning et des workflows d'agent 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 :

Figure 1. Architecture et flux de données pour la fédération de lakehouse

La section suivante décrit le processus de 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 pushdown : AlloyDB optimise la requête en transférant des filtres et des agrégations spécifiques directement vers 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 le stockage intégré BigQuery ou en lisant les tables Apache Iceberg stockées dans Cloud Storage) et renvoie l'ensemble de données résultant à AlloyDB.
5. Traitement final et réponse : AlloyDB combine les données externes avec toutes 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 de 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 la section Mappages des types de données.

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

L'accès aux données BigQuery à partir d'AlloyDB est géré via IAM. Vous devez accorder des rôles IAM spécifiques au compte de service du cluster AlloyDB pour définir les ensembles de données et les tables qui peuvent ê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 filtre et d'agrégation, 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 déplace le filtrage des données aussi près que possible de la couche de stockage en déplaçant vos filtres de requête (à l'aide de la clause WHERE) d'AlloyDB vers BigQuery.

Avec le pushdown de filtre, vous pouvez 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 sur une table locale ou jointes en tant que partition locale à une table PostgreSQL.

Les opérations compatibles avec le pushdown de filtre incluent 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 NULL : IS NULL et IS NOT NULL
• Évaluation dans la liste : IN et NOT IN

Remarque : Le filtrage est également compatible avec l'API BigQuery Storage Read.

Pushdown d'agrégation

Le pushdown d'agrégation est une optimisation avancée de la base de données 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 de résumé 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 incluent 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 de base ou des expressions qui peuvent être évaluées à distance.

Coûts et facturation BigQuery

Le wrapper de données externes BigQuery dépend des éléments suivants :

• Tarifs de 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 accumule les coûts de calcul est appelé projet d'exécution (ou projet de facturation).

La séparation de votre projet d'exécution de votre projet de stockage de données vous permet d'isoler les coûts de calcul dans des centres de coûts spécifiques, de gérer les quotas indépendamment et de contrôler les dépenses sur 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 (en l'appliquant à toutes les tables externes associées) ou au niveau de la table individuelle. 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 règles de tri par défaut différentes, ce qui peut entraîner des résultats de tri de 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, les règles de tri suivent les paramètres de BigQuery. Pour réduire les conflits de règles de tri, envisagez d'utiliser les règles de tri C.UTF-8 sans ICU dans AlloyDB et les règles de tri par défaut (vides) dans BigQuery.

• Les requêtes qui renvoient une grande quantité de données 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 filtre ne peuvent pas être appliqués), la requête 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 la page Quotas et limites.

• PostgreSQL accepte une plus grande précision pour les calculs intermédiaires, tandis que BigQuery contrôle strictement la précision décimale. Cette différence peut entraîner une perte de précision ou des erreurs de dépassement de capacité lors de calculs complexes. Pour en savoir plus, consultez la section Types décimaux.

• Database Migration Service n'est pas compatible avec la migration 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 tâche de migration ou les supprimer avant de démarrer 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 la section Accorder l'accès AlloyDB à l'ensemble de données BigQuery.

Étape suivante

• Choisissez comment accéder aux données BigQuery.
• Configurez l'accès aux données en temps réel.