Présentation de BigQuery Omni

Avec BigQuery Omni, vous pouvez exécuter des analyses BigQuery sur les données stockées dans Amazon Simple Storage Service (Amazon S3) ou Azure Blob Storage à l'aide de tables BigLake.

De nombreuses organisations stockent des données dans plusieurs clouds publics. Ces données finissent souvent par être cloisonnées, car il est difficile d'obtenir des insights sur toutes les données. Vous souhaitez pouvoir analyser des données avec un outil de données multicloud qui est économique et rapide, et ne génère pas de frais généraux supplémentaire liée à la gouvernance des données décentralisée. En utilisant BigQuery Omni, nous atténuons ces frictions grâce à une interface unifiée.

Pour exécuter des analyses BigQuery sur vos données externes, vous devez d'abord vous connecter à Amazon S3 ou Blob Storage. Si vous souhaitez interroger des données externes, vous devez créer une table BigLake faisant référence aux données Amazon S3 ou Blob Storage.

Vous pouvez également combiner des données entre différents clouds à l'aide d'un transfert inter-cloud ou les interroger entre différents clouds à l'aide de jointures inter-cloud. BigQuery Omni offre une solution d'analyse multicloud qui permet d'analyser des données là où elles se trouvent et qui offre la flexibilité nécessaire pour répliquer des données si nécessaire. Pour en savoir plus, consultez les pages Charger des données avec un transfert inter-cloud et des jointures inter-cloud.

Architecture

L'architecture de BigQuery sépare le calcul du stockage, ce qui permet à BigQuery d'effectuer un scaling horizontal si nécessaire pour gérer des charges de travail très volumineuses. BigQuery Omni étend cette architecture en exécutant le moteur de requêtes BigQuery dans d'autres clouds. De ce fait, vous n'avez pas besoin de déplacer physiquement les données dans l'espace de stockage BigQuery. Le traitement des données se déroule là où ces données sont déjà stockées.

Architecture de BigQuery Omni

Les résultats de la requête peuvent être renvoyés à Google Cloud via une connexion sécurisée, par exemple pour s'afficher dans Google Cloud Console. Vous pouvez également écrire les résultats directement dans l'espace de stockage Amazon S3 ou Blob Storage. Dans ce cas, les résultats de la requête ne sont pas déplacés entre plusieurs clouds.

BigQuery Omni utilise les rôles AWS IAM standards ou les principes Azure Active Directory pour accéder aux données de votre abonnement. Vous déléguez l'accès en lecture ou en écriture à BigQuery Omni, et vous pouvez révoquer cet accès à tout moment.

Flux de données lors de l'interrogation de données

L'image suivante décrit la manière dont les données sont déplacées entre Google Cloud et AWS ou Azure pour les requêtes suivantes :

  • Instruction SELECT
  • Instruction CREATE EXTERNAL TABLE
Transfert de données entre Google Cloud et AWS ou Azure pour les requêtes.
Figure 1 :Transfert de données entre Google Cloud et AWS ou Azure pour les requêtes.
  1. Le plan de contrôle BigQuery reçoit des jobs de requête de votre part via la console Google Cloud, l'outil de ligne de commande bq, une méthode API ou une bibliothèque cliente.
  2. Le plan de contrôle BigQuery envoie des tâches de requête à traiter dans le plan de données BigQuery (sur AWS ou Azure).
  3. Le plan de données BigQuery reçoit une requête du plan de contrôle via une connexion VPN.
  4. Le plan de données BigQuery lit les données de table de votre bucket Amazon S3 ou Blob Storage.
  5. Le plan de données BigQuery exécute la tâche de requête sur les données de table. Le traitement des données de la table s'effectue dans la région AWS ou Azure sélectionnée.
  6. Le résultat de la requête est transmis du plan de données au plan de contrôle via la connexion VPN.
  7. Le plan de contrôle BigQuery reçoit les résultats du job de requête à afficher en réponse au job de requête. Ces données sont stockées pendant 24 heures au maximum.
  8. Le résultat de la requête vous est renvoyé.

Pour en savoir plus, consultez Interroger les données Amazon S3 et Données Blob Storage.

Flux de données lors de l'exportation de données

L'image suivante décrit la façon dont les données sont déplacées entre Google Cloud et AWS ou Azure lorsqu'une instruction EXPORT DATAest utilisée.

Transfert de données entre Google Cloud et AWS ou Azure pour les requêtes d'exportation.
Figure 2 : Transfert de données entre Google Cloud et AWS ou Azure pour les requêtes d'exportation.
  1. Le plan de contrôle BigQuery reçoit des tâches de requête d'exportation de votre part via la console Google Cloud, l'outil de ligne de commande bq, une méthode API ou une bibliothèque cliente. La requête contient le chemin de destination du résultat de la requête dans votre bucket Amazon S3 ou Blob Storage.
  2. Le plan de contrôle BigQuery envoie des tâches de requête d'exportation pour traitement au plan de données BigQuery (sur AWS ou Azure).
  3. Le plan de données BigQuery reçoit la requête d'exportation provenant du plan de contrôle via la connexion VPN.
  4. Le plan de données BigQuery lit les données de table de votre bucket Amazon S3 ou Blob Storage.
  5. Le plan de données BigQuery exécute la tâche de requête sur les données de table. Le traitement des données de la table s'effectue dans la région AWS ou Azure sélectionnée.
  6. BigQuery écrit le résultat de la requête dans le chemin de destination spécifié dans votre bucket Amazon S3 ou Blob Storage.

Pour en savoir plus, consultez Exporter des résultats de requête vers Amazon S3 et Blob Storage.

Avantages

Performances Vous pouvez obtenir des insights plus rapidement, car les données ne sont pas copiées entre les différents clouds, et les requêtes s'exécutent dans la même région que celle où sont stockées vos données.

Coût Vous réduisez les coûts associés aux transferts de données sortantes, car les données ne sont pas déplacées. Aucuns frais supplémentaires ne sont facturés pour votre compte AWS ou Azure lié à l'analyse BigQuery Omni, car les requêtes s'exécutent sur des clusters gérés par Google. Vous n'êtes facturé que pour l'exécution des requêtes, selon le modèle de tarification BigQuery.

Sécurité et gouvernance des données. Vous devez gérer les données dans votre propre abonnement AWS ou Azure. Vous n'avez pas besoin de transférer ni de copier les données brutes depuis votre cloud public. Tous les calculs sont effectués dans le service mutualisé BigQuery qui s'exécute dans la même région que vos données.

Architecture sans serveur Comme le reste de BigQuery, BigQuery Omni est une offre sans serveur. Google déploie et gère les clusters qui exécutent BigQuery Omni. Vous n'avez pas besoin de provisionner de ressources ni de gérer de clusters.

Gestion simplifiée BigQuery Omni fournit une interface de gestion unifiée via Google Cloud. BigQuery Omni peut utiliser votre compte Google Cloud et vos projets BigQuery existants. Vous pouvez écrire une requête GoogleSQL dans la console Google Cloud pour interroger des données dans AWS ou Azure, et voir les résultats affichés dans la console Google Cloud.

Transfert de cloud à cloud Vous pouvez charger des données dans des tables BigQuery standards à partir de buckets S3 et de Blob Storage. Pour en savoir plus, consultez Transférer des données Amazon S3 et Données Blob Storage vers BigQuery.

Mise en cache des métadonnées pour améliorer les performances

Vous pouvez utiliser les métadonnées mises en cache pour améliorer les performances des requêtes sur les tables BigLake faisant référence à des données Amazon S3. Ceci est particulièrement utile lorsque vous travaillez avec un grand nombre de fichiers ou lorsque les données sont partitionnées avec Hive.

Les métadonnées incluent les noms de fichiers, les informations de partitionnement et les métadonnées physiques des fichiers, telles que le nombre de lignes. Vous pouvez choisir d'activer ou non la mise en cache des métadonnées sur une table. Les requêtes comportant un grand nombre de fichiers et des filtres de partitionnement Hive tirent le meilleur parti de la mise en cache des métadonnées.

Si vous n'activez pas la mise en cache des métadonnées, les requêtes effectuées sur la table doivent lire la source de données externe pour obtenir les métadonnées d'objet. La lecture de ces données augmente la latence des requêtes. Répertorier des millions de fichiers depuis la source de données externe peut prendre plusieurs minutes. Si vous activez la mise en cache des métadonnées, les requêtes peuvent éviter de répertorier les fichiers de la source de données externe et ainsi partitionner et supprimer les fichiers plus rapidement.

Deux propriétés contrôlent cette fonctionnalité :

  • L'obsolescence maximale spécifie le moment auquel les requêtes utilisent des métadonnées mises en cache..
  • Le mode de cache des métadonnées spécifie la manière dont les métadonnées sont collectées.

Lorsque la mise en cache des métadonnées est activée, vous spécifiez l'intervalle maximal d'obsolescence des métadonnées acceptable pour les opérations sur la table. Par exemple, si vous spécifiez un intervalle d'une heure, les opérations sur la table utilisent les métadonnées mises en cache si celles-ci ont été actualisées au cours de la dernière heure. Si les métadonnées mises en cache sont plus anciennes, l'opération extrait les métadonnées depuis Amazon S3. Vous pouvez spécifier un intervalle d'obsolescence compris entre 30 minutes et sept jours.

Vous pouvez choisir d'actualiser le cache automatiquement ou manuellement :

  • Pour les actualisations automatiques, le cache est actualisé à un intervalle défini par le système, généralement compris entre 30 et 60 minutes. L'actualisation automatique du cache est une bonne approche si les fichiers dans Amazon S3 sont ajoutés, supprimés ou modifiés à intervalles irréguliers. Si vous devez contrôler le moment de l'actualisation, par exemple pour déclencher l'actualisation à la fin d'un job d'extraction, de transformation et de chargement, utilisez l'actualisation manuelle.

  • Pour les actualisations manuelles, exécutez la procédure système BQ.REFRESH_EXTERNAL_METADATA_CACHE afin d'actualiser le cache de métadonnées selon une programmation répondant à vos besoins. L'actualisation manuelle du cache est une bonne approche si les fichiers dans Amazon S3 sont ajoutés, supprimés ou modifiés à des intervalles connus, par exemple en tant que sortie d'un pipeline.

    Si vous émettez plusieurs actualisations manuelles simultanées, une seule réussira.

Le cache des métadonnées expire au bout de sept jours s'il n'est pas actualisé.

Les actualisations manuelles et automatiques du cache sont exécutées avec la priorité de requête INTERACTIVE.

Si vous choisissez d'utiliser les actualisations automatiques, nous vous recommandons de créer une réservation, puis de créer une attribution avec un type de job BACKGROUND pour le projet qui exécute les jobs d'actualisation du cache de métadonnées. Cela empêche les jobs d'actualisation d'être en concurrence avec les requêtes utilisateur pour les ressources et d'échouer potentiellement si les ressources sont insuffisantes.

Réfléchissez à la manière dont l'intervalle d'obsolescence et les valeurs du mode de mise en cache des métadonnées interagissent avant de les définir. Prenons les exemples suivants :

  • Si vous actualisez manuellement le cache de métadonnées d'une table et que vous définissez l'intervalle d'obsolescence sur deux jours, vous devez exécuter la procédure système BQ.REFRESH_EXTERNAL_METADATA_CACHE tous les deux jours ou moins si vous souhaitez effectuer des opérations sur la table pour utiliser les métadonnées mises en cache.
  • Si vous actualisez automatiquement le cache de métadonnées d'une table et que vous définissez l'intervalle d'obsolescence sur 30 minutes, il est possible que certaines de vos opérations sur la table lisent les données d'Amazon S3 si l'actualisation du cache de métadonnées s'approche de la durée maximum de la fenêtre habituelle de 30 à 60 minutes.

Pour trouver des informations sur les jobs d'actualisation des métadonnées, interrogez la vue INFORMATION_SCHEMA.JOBS, comme illustré dans l'exemple suivant :

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Pour en savoir plus, consultez la section Mise en cache des métadonnées.

Tables compatibles avec le cache avec vues matérialisées

Vous pouvez utiliser des vues matérialisées sur des tables compatibles avec le cache des métadonnées Amazon Simple Storage Service (Amazon S3) pour améliorer les performances et l'efficacité lors de l'interrogation de données structurées stockées dans Amazon S3. Ces vues matérialisées fonctionnent comme les vues matérialisées sur des tables de stockage gérées par BigQuery, ce qui inclut les avantages de l'actualisation automatique et du réglage intelligent.

Pour rendre les données Amazon S3 dans une vue matérialisée disponibles dans une région BigQuery compatible à des fins de jointure, créez une instance dupliquée de la vue matérialisée. Vous ne pouvez créer des instances répliquées de vues matérialisées que pour les vues matérialisées autorisées.

Limites

En plus des limitations pour les tables BigLake, les limitations suivantes s'appliquent à BigQuery Omni, qui inclut des tables BigLake basées sur des données Amazon S3 et Blob Storage :

  • L'utilisation de données dans l'une des régions BigQuery Omni n'est pas compatible avec les éditions Standard et Enterprise Plus. Pour en savoir plus sur les éditions, consultez la page Présentation des éditions BigQuery.
  • Les vues OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, TABLE_CONSTRAINTS, KEY_COLUMN_USAGE, CONSTRAINT_COLUMN_USAGE, PARTITIONS et INFORMATION_SCHEMA ne sont pas disponibles pour les tables BigLake basées sur Amazon S3 et Blob Storage.
  • Les vues matérialisées ne sont pas compatibles avec Blob Storage.
  • Les fonctions JavaScript définies par l'utilisateur ne sont pas acceptées.

  • Les instructions SQL suivantes ne sont pas acceptées :

  • Les limites suivantes s'appliquent à l'interrogation et à la lecture des tables temporaires de destination (preview) :

    • Il n'est pas possible d'interroger des tables temporaires de destination à l'aide de l'instruction SELECT.
    • Il n'est pas possible d'utiliser l'API BigQuery Storage Read pour lire les données des tables temporaires de destination.
    • Lorsque vous utilisez le pilote ODBC, les lectures à haut débit (option EnableHTAPI) ne sont pas acceptées.

  • Les requêtes programmées ne sont disponibles que via la méthode API ou CLI. L'option de table de destination est désactivée pour les requêtes. Seules les requêtes EXPORT DATA sont autorisées.

  • L'API BigQuery Storage n'est pas disponible dans les régions BigQuery Omni.

  • Si votre requête utilise la clause ORDER BY et que sa taille de résultat est supérieure à 256 Mo, votre requête échoue. Pour résoudre ce problème, réduisez la taille du résultat ou supprimez la clause ORDER BY de la requête. Pour en savoir plus sur les quotas BigQuery Omni, consultez la page Quotas et limites.

  • Utiliser des clés de chiffrement gérées par le client (CMEK) avec des ensembles de données et des tables externes n'est pas pris en charge.

Tarifs

Pour en savoir plus sur les tarifs et les offres à durée limitée dans BigQuery Omni, consultez la page Tarifs de BigQuery Omni.

Quotas et limites

Pour en savoir plus sur les quotas BigQuery Omni, consultez la page Quotas et limites.

Si le résultat de votre requête dépasse 20 Gio, envisagez d'exporter les résultats vers Amazon S3 ou Blob Storage. Pour en savoir plus sur les quotas de l'API BigQuery Connection, consultez la page API BigQuery Connection.

Emplacements

BigQuery Omni traite les requêtes dans le même emplacement que l'ensemble de données contenant les tables que vous interrogez. Après avoir créé l'ensemble de données, la zone ne peut plus être modifiée. Vos données résident dans votre propre compte AWS ou Azure. Les régions BigQuery Omni sont compatibles avec les réservations de l'édition Enterprise et la tarification du calcul à la demande (analyse). Pour en savoir plus sur les éditions, consultez la page Présentation des éditions BigQuery.
Description de la région Nom de la région Région BigQuery colocalisée
AWS
AWS Est des États-Unis (Virginie du Nord) aws-us-east-1 us-east4
AWS Est des États-Unis (Oregon) aws-us-west-2 us-west1
AWS – Asie-Pacifique (Séoul) aws-ap-northeast-2 asia-northeast3
AWS – Asie-Pacifique (Sydney) aws-ap-southeast-2 australia-southeast1
AWS – Europe (Irlande) aws-eu-west-1 europe-west1
AWS – Europe (Francfort) aws-eu-central-1 europe-west3
Azure
Azure – Est des États-Unis 2 azure-eastus2 us-east4

Étapes suivantes