BigQuery pour les experts en entrepôts de données

Guide mis à jour le 29 juin 2016

Ce document explique comment utiliser BigQuery comme entrepôt de données. Il met en correspondance les concepts courants des entrepôts de données et ceux de BigQuery, et décrit comment effectuer des tâches d'entreposage standard. Ce document est destiné aux personnes qui gèrent des entrepôts de données et des systèmes de big data.

Comparaison des modèles de service

Le tableau suivant met en correspondance les concepts d'entrepôt de données standard et ceux de BigQuery :

Entrepôt de données BigQuery
Entrepôt de données Le service BigQuery remplace la configuration matérielle typique d'un entrepôt de données traditionnel. En d'autres termes, il sert de base collective pour toutes les données analytiques d'une organisation.
Magasin de données Les ensembles de données sont des collections de tables pouvant être divisées en fonction des secteurs d'activité ou d'un domaine analytique donné. Chaque ensemble de données est lié à un projet Google Cloud.
Lac de données Votre lac de données peut contenir des fichiers dans Cloud Storage ou Google Drive, ou des données transactionnelles dans Bigtable ou Cloud SQL. BigQuery peut définir un schéma et émettre des requêtes directement sur des données externes en tant que sources de données fédérées. L'API BigQuery Storage offre des lectures parallèles à haut débit et est compatible avec les frameworks de traitement courants tels que Spark et Pandas.

Ressources BigQuery

BigQuery possède une structure hiérarchique. Ses niveaux sont décrits dans le schéma suivant :

Projet A : ensemble de données, table englobante, vues, script/fonction Projet B : tâches comprenant les requêtes, les chargements, les copies et les exportations.

Projets

Toutes les ressources Google Cloud que vous allouez et utilisez doivent appartenir à un projet. Un projet est l'entité organisationnelle de ce que vous créez avec Google Cloud. Dans le contexte de BigQuery, un projet est un conteneur pour toutes les ressources BigQuery. Comme BigQuery dissocie le stockage et le calcul, les projets qui stockent et interrogent les données peuvent être différents.

Ensembles de données

Les ensembles de données sont les conteneurs de niveau supérieur que vous utilisez pour organiser vos tables et vos vues BigQuery. Ils sont fréquemment mappés à des schémas dans des entrepôts de données et des bases de données relationnelles standards.

Les ensembles de données sont limités à votre projet Cloud. Lorsque vous référencez une table depuis la ligne de commande, dans des requêtes SQL ou dans du code, vous y faites référence comme suit :

project.dataset.table

Un ensemble de données est lié à un emplacement. Les emplacements des ensembles de données sont les suivants :

  • Régional : emplacement géographique spécifique, par exemple Londres.
  • Multirégional : vaste zone géographique, telle que les États-Unis, qui comporte au moins deux lieux géographiques.

Vous ne pouvez définir l'emplacement d'un ensemble de données qu'au moment de sa création. Une requête peut contenir des tables ou des vues provenant de différents ensembles de données dans le même emplacement.

L'utilisation de ces multiples champs d'application (projet, ensemble de données, table et emplacement) peut vous aider à structurer vos informations de manière logique et géographique.

Tables

Les tables BigQuery sont des structures de colonnes à lignes qui contiennent vos données. Chaque table est définie par un schéma qui décrit les noms de colonne, les types de données et d'autres informations. Vous pouvez spécifier le schéma d'une table lors de sa création. Vous pouvez également créer une table sans schéma et spécifier le schéma dans la tâche de requête ou la tâche de chargement. Ces tâches permettent d'insérer des données préliminaires dans le schéma. BigQuery propose les types de tables suivants :

  • Tables natives : tables sauvegardées par le stockage BigQuery natif.
  • Tables externes : tables sauvegardées par un stockage externe à BigQuery.
  • Vues : tables virtuelles définies par une requête SQL.

Pour en savoir plus, consultez la section Gestion du stockage.

Tâches

Les tâches sont des actions que BigQuery exécute en votre nom pour charger, exporter, interroger ou copier des données. Les tâches ne sont pas associées au projet dans lequel vos données sont stockées. Cependant, l'emplacement d'exécution de la tâche est lié à l'emplacement de l'ensemble de données. Par exemple, si vous chargez des données à partir d'un bucket Cloud Storage dans un ensemble de données BigQuery situé à Singapour, le bucket Cloud Storage régional ou multirégional doit également être situé à Singapour. Si votre ensemble de données est situé dans une région européenne, vous ne pouvez pas l'interroger à partir d'autres régions, telles que les États-Unis. Cela garantit que vos exigences de localité des données sont remplies.

Provisionner et dimensionner le système

Il n'est pas nécessaire de provisionner des ressources avant d'utiliser BigQuery, contrairement à de nombreux systèmes de SGBDR. BigQuery alloue des ressources de stockage et de requête de manière dynamique en fonction de vos habitudes d'utilisation :

  • Les ressources de stockage sont allouées au fur et à mesure que vous les consommez et libérées lorsque vous supprimez des données ou des tables.
  • Les ressources de requête sont allouées en fonction du type de requête et de sa complexité. Chaque requête utilise un certain nombre d'emplacements, qui sont des unités de calcul comprenant une certaine quantité de processeurs et de mémoire RAM.

Pour exploiter BigQuery, vous n'avez pas besoin de vous engager pour une utilisation minimale. Le service alloue et facture les ressources en fonction de votre utilisation réelle. Par défaut, tous les clients BigQuery ont accès à 2 000 emplacements pour les opérations de requête. Vous pouvez également effectuer des réservations d'emplacements pour votre projet. Pour plus de détails sur l'approche à appliquer, consultez la section Coûts.

Gestion de l'espace de stockage

BigQuery stocke les données en interne dans un format de colonne propriétaire appelé Capacitor, qui présente de nombreux avantages pour les charges de travail de l'entrepôt de données. BigQuery s'appuie sur un format propriétaire, car il peut évoluer en même temps que le moteur de requête qui, lui, tire parti d'une connaissance approfondie de la structure des données pour optimiser l'exécution des requêtes. BigQuery détermine le nombre optimal de fragments physiques et leur encodage à l'aide de modèles d'accès aux requêtes.

Les données sont stockées sur le système de fichiers distribué de Google, appelé Colossus, qui garantit la durabilité en exploitant l'encodage d'effacement pour stocker des fragments redondants des données sur plusieurs disques physiques. De plus, les données sont dupliquées dans plusieurs centres de données.

Vous pouvez également exécuter des requêtes BigQuery sur des données extérieures à l'espace de stockage BigQuery, telles que des données stockées dans Cloud Storage, Google Drive ou Bigtable, à l'aide de sources de données fédérées. Cependant, ces sources n'étant pas optimisées pour les opérations BigQuery, elles risquent de ne pas fonctionner aussi bien que les données stockées dans l'emplacement de stockage BigQuery.

Maintenance

BigQuery étant un service entièrement géré, l'équipe d'ingénieurs de BigQuery s'occupe des mises à jour et de la maintenance. Les mises à niveau ne nécessitent généralement pas de temps d'arrêt et ne nuisent pas aux performances du système.

De nombreux systèmes traditionnels requièrent des processus de vide consommant beaucoup de ressources afin de s'exécuter à différents intervalles pour remanier et trier les blocs de données et récupérer de l'espace. BigQuery n'intègre aucun équivalent à la gestion de vide ou d'index, car le moteur de stockage gère et optimise en permanence la manière dont les données sont stockées et dupliquées. De plus, étant donné que BigQuery n'utilise pas d'index sur les tables, vous n'avez pas besoin de reconstruire les index.

Sauvegarde et récupération

La gestion de la sauvegarde et de la disponibilité a toujours été une tâche complexe et coûteuse pour les administrateurs de base de données. Le besoin de licences et de matériel supplémentaires peut augmenter considérablement les coûts. BigQuery se charge de la sauvegarde et de la reprise après sinistre au niveau du service. En conservant un historique complet des modifications des tables sur sept jours, BigQuery vous permet d'interroger un instantané de vos données à un moment précis à l'aide de l'une des méthodes suivantes : décorateurs de table ou de SYSTEM_TIME AS OF dans laclause FROM. Vous pouvez facilement annuler les modifications sans avoir à demander une récupération à partir des sauvegardes. (Lorsqu'une table est explicitement supprimée, son historique est vidé après sept jours.) De plus, la commande cp offre des instantanés de table dans la région.

Les ensembles de données BigQuery peuvent être régionaux ou multirégionaux. Pour les ensembles de données régionaux, par exemple un ensemble de données situé dans la région us-central1, aucune copie de l'ensemble de données n'est conservée en dehors de la région. Si vous considérez que l'absence de sauvegardes en dehors d'une région est risquée pour votre entreprise, vous pouvez créer et planifier des copies interrégionales à l'aide du service de transfert de données BigQuery. Pour les ensembles de données multirégionaux situés dans de grandes zones géographiques telles que l'Europe (UE), une copie est automatiquement stockée dans une autre région Google Cloud.

Si une région échoue, certaines données récentes risquent d'être perdues. Pour en savoir plus, consultez la documentation BigQuery sur la disponibilité et la durabilité.

Gérer les workflows

Cette section traite des tâches d'administration, telles que l'organisation des ensembles de données, l'octroi d'autorisations et l'intégration du travail dans BigQuery. Elle aborde également la gestion des charges de travail simultanées, la surveillance de l'état de votre entrepôt de données et l'audit de l'accès des utilisateurs.

Organiser les ensembles de données

Vous pouvez segmenter des ensembles de données en projets distincts en fonction de la classe de données ou de l'unité commerciale, ou les regrouper en projets communs pour des raisons de simplicité.

Vous pouvez inviter un analyste de données à collaborer sur un ensemble de données existant dans n'importe quel rôle limité que vous définissez. Ainsi, lorsqu'un analyste de données se connecte à la console Web BigQuery, il ne voit que les ressources BigQuery qui ont été partagées avec lui entre projets. Les activités que les analystes de données peuvent exécuter sur des ensembles de données varient suivant leur rôle dans chaque ensemble de données.

Accord d'autorisations...

Dans un système SGBDR classique, vous accordez des autorisations pour afficher ou modifier des tables en créant des autorisations SQL et en les appliquant à un utilisateur donné dans le système de base de données. En outre, certains systèmes SGBDR vous permettent d'accorder des autorisations aux utilisateurs d'un annuaire externe, tel que LDAP. Le modèle BigQuery pour la gestion des utilisateurs et des autorisations ressemble à ce dernier modèle.

Cloud Identity est le fournisseur d'identité central intégré de Google Cloud qui permet l'authentification des utilisateurs. Il fait partie de Identity and Access Management (IAM). Outre l'authentification, IAM vous offre un contrôle centralisé pour accorder aux identités des autorisations spécifiques à BigQuery et ses ensembles de données. Vous pouvez utiliser les rôles prédéfinis ou créer des rôles personnalisés pour contrôler les accès. Pour un accès non humain aux ressources BigQuery, vous pouvez créer un compte de service et lui attribuer le rôle requis. Un exemple de cas d'utilisation pour cette approche est l'accès à des scripts de chargement de données planifiés.

Un aspect important de l'exploitation d'un entrepôt de données consiste à permettre à différents groupes d'utilisateurs un accès partagé mais contrôlé aux mêmes données. Par exemple, les services des finances, des ressources humaines et du marketing accèdent aux mêmes tables, mais leurs niveaux d'accès diffèrent. Les outils d'entreposage de données traditionnels rendent cela possible en appliquant une sécurité au niveau des lignes. Vous pouvez obtenir les mêmes résultats dans BigQuery en définissant des vues autorisées et des autorisations au niveau de la ligne. Pour les tables contenant des données sensibles dans certaines colonnes, vous pouvez utiliser des tags avec stratégie de données ainsi que des rôles IAM pour appliquer la sécurité au niveau des colonnes. Pour plus d'informations sur la gouvernance des données, consultez la page Migrer des entrepôts de données vers BigQuery : gouvernance de données.

Intégration

Avec les entrepôts de données conventionnels, l'intégration de nouveaux analystes de données impliquait un délai d'exécution important. Pour permettre aux analystes d'exécuter des requêtes simples, il fallait leur indiquer l'emplacement des sources de données et configurer des connexions, des outils ODBC et des droits d'accès. Grâce à Google Cloud, vous pouvez accélérer considérablement la productivité d'un analyste.

Pour intégrer un analyste dans Google Cloud, vous accordez l'accès aux projets pertinents, vous lui présentez Google Cloud Console et la console Web BigQuery, et vous partagez certaines requêtes pour l'aider à se familiariser avec les données :

  • Cloud Console fournit une vue centralisée de tous les éléments de votre environnement Google Cloud. Les ressources les plus pertinentes pour les analystes de données sont certainement les buckets Cloud Storage, dans lesquels ils peuvent collaborer sur des fichiers.
  • La console Web de BigQuery présente la liste des ensembles de données auxquels l'analyste a accès. Suivant le rôle que vous leur avez attribué, les analystes peuvent effectuer des tâches dans Cloud Console, telles que l'affichage des métadonnées, la prévisualisation des données, l'exécution, la sauvegarde et le partage de requêtes.

La découverte de données est une préoccupation majeure pour les entreprises, tant pour l'intégration de nouveaux utilisateurs que pour les utilisateurs expérimentés. Il est très important de pouvoir trouver les données requises. Il est tout aussi important de protéger les données sensibles et d'autoriser l'accès à ces données. Vous pouvez utiliser Data Catalog pour fournir automatiquement des fonctionnalités telles que la recherche de métadonnées et la prévention de la perte de données. Pour en savoir plus sur la découverte de données, consultez la page Découverte de données.

Gérer des charges de travail et la simultanéité

Cette section décrit les contrôles disponibles permettant de gérer les charges de travail, le nombre de requêtes simultanées que vous pouvez effectuer et la planification des tâches.

Quotas de service

Les quotas de service permettent de maintenir une qualité de service cohérente lorsque vous utilisez BigQuery et sont décrits dans les Règles relatives aux quotas de BigQuery. Chaque limite de quota a une valeur par défaut pour tous les clients. Par exemple, vous pouvez définir par défaut le nombre maximal de requêtes simultanées sur 100. Si vous devez augmenter ou diminuer ce nombre, vous pouvez effectuer cette opération à l'aide d'un quota de remplacement.

Quotas personnalisés

Si vous avez plusieurs projets et utilisateurs BigQuery, vous pouvez maîtriser vos coûts en demandant un quota personnalisé qui limite le volume des données de requêtes traitées chaque jour. Les quotas quotidiens sont réinitialisés à minuit (heure du Pacifique).

Hiérarchisation et planification des requêtes

BigQuery propose deux types de priorités pour les requêtes : les requêtes interactives et les requêtes par lot. Par défaut, BigQuery exécute des requêtes interactives, ce qui signifie qu'elles sont exécutées dès que possible. Les requêtes interactives sont comptabilisées dans les quotas de limite du débit simultanés. Les requêtes par lot sont mises en file d'attente et exécutées lorsque des ressources inactives sont disponibles, généralement en quelques minutes. Si BigQuery n'a pas lancé la requête dans les 24 heures, il redéfinit la priorité de la tâche sur interactive. Les requêtes par lot ne sont pas comptabilisées dans le quota de limite du débit simultané.

BigQuery met en œuvre un algorithme de planification équitable lorsque les requêtes simultanées peuvent utiliser plus d'emplacements que ceux disponibles dans un projet ou une réservation. Étant donné la vitesse et l'échelle auxquelles BigQuery fonctionne, de nombreux problèmes de charge de travail classiques, tels que la gestion de files d'attente distinctes pour différentes charges de travail, ne s'appliquent pas. Si vous avez besoin d'une hiérarchisation explicite des requêtes, vous pouvez séparer vos charges de travail sensibles dans un projet avec une réservation distincte.

Surveiller et auditer

Vous pouvez surveiller BigQuery à l'aide de Monitoring, dans lequel divers graphiques et alertes sont définis en fonction de métriques BigQuery. Par exemple, vous pouvez surveiller le débit du système à l'aide de la métrique Durée de la requête, ou visualiser les tendances de la demande de requête en fonction de la métrique Emplacements alloués. Lorsque vous devez planifier à l'avance une requête exigeante, vous pouvez utiliser la métrique Emplacements disponibles. Pour effectuer une surveillance proactive de l'état du système, vous pouvez créer des alertes en fonction de seuils que vous définissez. Monitoring fournit un portail Web en libre-service.

BigQuery crée automatiquement des journaux d'audit sur les actions de l'utilisateur. Vous pouvez exporter les journaux d'audit vers un autre ensemble de données BigQuery, par lot ou sous forme de flux de données, puis visualiser les journaux à l'aide de votre outil d'analyse préféré. Pour plus d'informations, consultez la page Analyser des journaux d'audit à l'aide de BigQuery.

BigQuery fournit également des vues en lecture seule INFORMATION_SCHEMA que vous pouvez utiliser pour accéder aux métadonnées de vos ressources BigQuery, telles que des ensembles de données, des tables et des tâches. Ces vues peuvent être utilisées à diverses fins, telles que le suivi de la date d'expiration de votre table ou la compréhension de l'utilisation des emplacements de vos requêtes.

Gérer des données

Cette section aborde les considérations liées à la conception d'un schéma, le fonctionnement du partitionnement et du clustering, ainsi que les méthodes de chargement de données dans BigQuery. Pour finir, elle décrit comment gérer les modifications dans l'entrepôt tout en conservant des temps d'arrêt nuls sur les opérations d'analyse.

Concevoir un schéma

BigQuery vous permet de spécifier le schéma d'une table lorsque vous y chargez des données ou lorsque vous créez une table vide. BigQuery accepte les types de données SQL standards, y compris les types simples tels que les entiers et les types plus complexes tels que ARRAY et STRUCT.

BigQuery accepte les modèles de données traditionnels basés sur les schémas en étoile et les schémas en flocon. Dans ces modèles, les tables de faits sont jointes aux tables de dimension. BigQuery accepte également les opérations INNER, [FULL|RIGHT|LEFT] OUTER et CROSS JOIN.

Dans certains cas, vous pouvez utiliser des champs imbriqués et répétés pour dénormaliser vos données. Pour ce faire, vous pouvez utiliser une combinaison des types de données ARRAY et STRUCT afin de définir votre schéma.

Partitionner les tables

Les tables partitionnées sont divisées en segments basés sur la valeur d'une colonne de partition. Lorsqu'une requête spécifie des filtres sur la colonne de partition, seuls les segments correspondants sont analysés. Cet agencement accélère l'exécution de la requête et réduit son coût d'exécution. Une table BigQuery peut être partitionnée de différentes manières :

  • Date d'ingestion : BigQuery charge automatiquement les données dans des partitions quotidiennes basées sur la date, qui reflètent la date d'ingestion ou d'arrivée des données.
  • Partitionnement basé sur une colonne : la table est partitionnée en fonction de la valeur d'une colonne spécifiée. Vous pouvez utiliser les types suivants sur les colonnes :
    • Partitions de colonne temporelle : les tables peuvent être partitionnées en fonction des colonnes DATE, DATETIME et TIMESTAMP.
      • DATE : autorise les partitions avec une précision quotidienne, mensuelle ou annuelle.
      • TIMESTAMP DATETIME : autorise les partitions avec n'importe quel type de précision d'unité de temps, y compris HOUR.
    • Plage d'entiers : les tables sont partitionnées en fonction d'une colonne de nombres entiers.

Vous activez le partitionnement pendant le processus de création de table. De plus, vous pouvez spécifier un délai d'expiration pour les données des partitions. Les nouvelles données insérées dans une table partitionnée sont écrites sur la partition brute au moment de l'insertion. Pour contrôler la partition sur laquelle les données sont chargées, vous pouvez spécifier une partition particulière dans votre tâche de chargement.

Mettre en cluster des tables

Les tables en cluster sont organisées en fonction d'une ou de plusieurs colonnes spécifiées. BigQuery accepte le clustering pour les tables partitionnées et non partitionnées. Le clustering divise les segments de table en blocs triés sur les champs de clustering. Pour les requêtes qui filtrent les données sur les colonnes en cluster, la quantité de données analysées est réduite et les performances des requêtes sont améliorées. Étant donné que la quantité de données analysées ne peut être déterminée qu'au moment de l'exécution, le coût exact de l'exécution d'une requête ne peut pas être connu à l'avance.

BigQuery procède automatiquement à la remise en cluster des données nouvellement insérées en arrière-plan. La remise en cluster automatique n'a aucun impact sur la capacité ou la tarification des requêtes.

L'organigramme ci-dessous décrit les meilleurs cas d'utilisation du partitionnement, du clustering et du partitionnement avec clustering dans les tables.

Organigramme avec des options répétées dans le tableau suivant

L'organigramme ci-dessus décrit les options suivantes :

Cas d'utilisation Recommandation
Vous utilisez le tarif à la demande et exigez des garanties de coûts strictes avant d'exécuter des requêtes. Tables partitionnées
La taille de votre segment est inférieure à 1 Go après le partitionnement de la table. Tables en cluster
Vous avez besoin d'un grand nombre de partitions au-delà des limites de BigQuery. Tables en cluster
Les mutations fréquentes dans vos données modifient un grand nombre de partitions. Tables en cluster
Vous exécutez fréquemment des requêtes pour filtrer les données sur certaines colonnes fixes. Partitions plus clustering

Vues matérialisées

Les vues matérialisées sont des vues précalculées qui mettent régulièrement en cache les résultats d'une requête pour optimiser les performances et l'efficacité. Dans BigQuery, une vue matérialisée est toujours cohérente avec la table de base, y compris les tables de streaming BigQuery. Les vues matérialisées sont utiles pour créer des tables agrégées dans votre entrepôt de données.

Données géospatiales

Les entrepôts de données contiennent souvent des données de localisation. Ce type de données peut être utilisé de différentes manières, par exemple pour rendre un système logistique de chaîne d'approvisionnement plus efficace ou pour se préparer à un ouragan dans une ferme éolienne. Analyse géospatiale (Systèmes d'informations géographiques) vous permet d'analyser et de visualiser des données géospatiales dans BigQuery à l'aide des fonctions de géographie du langage SQL standard. BigQuery fournit le type de données GEOGRAPHY qui permet de charger des données spatiales aux formats GeoJSON, Well-known Binary (WKB) et Well-known Text (WKT). BigQuery fournit également plusieurs fonctions géographiques qui permettent d'analyser, de transformer et d'exploiter des données SIG. Pour en savoir plus sur l'utilisation des données géospatiales, consultez la page Utiliser des analyses géospatiales.

Chargement de données

BigQuery propose des modes de traitement par lot et par flux pour le chargement des données. Il permet également d'importer des données directement depuis certaines applications SaaS à l'aide du service de transfert de données BigQuery. Les chargements par lot vous permettent de charger de grandes quantités de données sans affecter les performances de la requête et sans frais supplémentaires. Pour les cas d'utilisation tels que le chargement de données modifiées pour la détection des fraudes, qui nécessitent que ces données soient disponibles en temps réel, vous pouvez diffuser des données dans BigQuery.

Chargements par lot

Pour les chargements par lot, les fichiers de données sont stockés dans un bucket Cloud Storage, puis importés dans vos tables BigQuery à l'aide d'une tâche de chargement. BigQuery est compatible avec de nombreuxformats tels que CSV, JSON, Avro ,ORC et Parquet. BigQuery est également compatible avec Datastore et Firestore.

BigQuery définit des limites quotidiennes sur le nombre et la taille des tâches de chargement que vous pouvez effectuer par projet et par table. De plus, il limite la taille des fichiers de chargement et des enregistrements. Pour en savoir plus, consultez la page Quotas et limites.

Vous pouvez lancer des tâches de chargement via la console BigQuery. Pour automatiser le processus, vous pouvez configurer une fonction Cloud Functions afin d'écouter un événement Cloud Storage associé à l'arrivée de nouveaux fichiers dans un bucket donné et lancer la tâche de chargement BigQuery. Les pipelines de données sont souvent utilisés pour exécuter une procédure d'extraction, de transformation et de chargement (ETL), qui s'exécute en dehors de l'entrepôt de données. Le schéma suivant illustre le flux d'événements dans le pipeline.

Procédure ETL BigQuery

Une alternative à une procédure ETL est une procédure d'extraction, de chargement et de transformation (ELT). Comme le montre le schéma suivant, dans une procédure ELT, les données sont d'abord chargées dans l'entrepôt de données, puis transformées en schéma à l'aide des opérations SQL.

Pipelines ELT BigQuery

Vous pouvez utiliser des pipelines ETL exécutés sur Dataflow pour charger automatiquement des données dans BigQuery à l'aide du connecteur d'E/S BigQuery fourni dans le SDK Apache Beam ; Vous pouvez également utiliser des pipelines créés avec Apache Spark pour charger automatiquement des données dans BigQuery à l'aide du connecteur Spark BigQuery.

Insertions en flux continu

Lorsque vous transmettez des données en continu aux tables BigQuery, vous envoyez vos enregistrements directement à BigQuery à l'aide de l'API BigQuery. Si vous utilisez Cloud Logging, vous pouvez également transférer en continu les journaux de votre projet sur le cloud directement dans BigQuery, y compris les journaux de requêtes d'App Engine et les informations des journaux personnalisés envoyées à Cloud Logging.

Il est également possible de diffuser des données d'événements à partir de systèmes de messagerie avec des pipelines exécutés sur Dataflow tels que Pub/Sub et Apache Kafka en utilisant la méthode STREAMING_INSERTS du connecteur E/S BigQuery fourni dans le SDK Apache Beam.

Comme les entreprises commencent à utiliser d'autres services Google Cloud, elles choisissent souvent de capturer des données sources directement dans Bigtable, Cloud SQL ou Cloud Spanner et d'utiliser Dataflow pour extraire, transformer et charger les données dans BigQuery par lots ou par flux. Le schéma suivant montre comment configurer des pipelines ETL par lots et par flux à l'aide de Dataflow.

Pipelines ETL par lots et par flux configurés avec Dataflow.

Importation depuis des applications SaaS

Le service de transfert de données BigQuery vous permet d'importer des données à partir de sources d'applications Google telles que Google Ads, Campaign Manager, Google Ad Manager et YouTube. Il est également compatible avec les sources de données externes, comme Amazon S3, et les entrepôts de données, tels que Teradata et Amazon Redshift. Vous pouvez également utiliser les connecteurs vers d'autres systèmes fournis par nos partenaires issus de Google Cloud Marketplace.

Gérer le changement

De nombreux entrepôts de données fonctionnent dans le cadre de contrats de niveau de service (SLA), exigeant peu ou pas de temps d'arrêt. Bien que le service BigQuery bénéficie d'un contrat de niveau de service de 99,99 %, vous contrôlez la disponibilité et la réactivité de vos ensembles de données afin de refléter l'évolution des données.

Toutes les modifications de table dans BigQuery, y compris les opérations LMD, les requêtes avec des tables de destination et les tâches de chargement, sont conformes à la norme ACID. Par conséquent, la modification d'une table ne nécessite pas de temps d'arrêt. En revanche, le processus interne peut nécessiter une phase de test et de validation avant de mettre à disposition les données actualisées à des fins d'analyse. De plus, étant donné que les opérations LMD sont moins efficaces dans les bases de données analytiques, il peut être préférable de les regrouper. Vous pouvez utiliser la plupart des techniques couramment employées pour gérer les modifications de données. Cette section explore de plus près certains des défis et remèdes connus.

Fenêtre à durée flexible

Contrairement à un lac de données, un entrepôt de données traditionnel ne conserve les données que pendant une durée déterminée, par exemple les 5 dernières années. Lors de chaque cycle de mise à jour, de nouvelles données sont ajoutées à l'entrepôt, et les données les plus anciennes sont supprimées, en maintenant la durée fixe. Ce concept a été essentiellement utilisé pour contourner les limites des technologies plus anciennes.

BigQuery est conçu pour évoluer et peut s'adapter à mesure que la taille de l'entrepôt augmente. Il n'est donc pas nécessaire de supprimer les données plus anciennes. En conservant l'intégralité de l'historique, vous pouvez fournir plus d'informations sur votre entreprise. Si les coûts de stockage posent problème, vous avez la possibilité de tirer parti des tarifs de stockage à long terme de BigQuery en archivant les données les plus anciennes, afin de ne les utiliser qu'en cas de besoin, dans le cadre d'une analyse particulière. Si vous avez toujours de bonnes raisons de supprimer les données plus anciennes, vous pouvez utiliser la compatibilité intégrée dans BigQuery pour les tables partitionnées par date et l'expiration des partitions. En d'autres termes, BigQuery peut supprimer automatiquement les anciennes données.

Modifier les schémas

Si un entrepôt de données est conçu et développé, il est courant de modifier les schémas de table en ajoutant, en mettant à jour ou en supprimant des colonnes, voire en ajoutant ou supprimant des tables entières. À moins que ces modifications ne se présentent sous la forme d'une colonne ou d'une table ajoutée, elles risquent de briser les requêtes et les rapports enregistrés qui font référence à une table supprimée, à une colonne renommée et à d'autres éléments associés.

Une fois l'entrepôt de données en production, ces modifications sont soumises à un contrôle strict. Dans la plupart des cas, les modifications de schéma sont planifiées en tant que mises à niveau de version. Vous concevez, développez et testez la mise à niveau en parallèle pendant que la version précédente de l'entrepôt de données diffuse les charges de travail d'analyse. La même approche s'applique pour modifier les schémas d'un entrepôt de données BigQuery.

Dimensions à évolution lente

Un schéma de données normalisé minimise l'impact sur les dimensions à évolution lente (SCD, Slowly Changing Dimensions) en isolant la modification dans les tables de dimension. Il est généralement préférable à un schéma dénormalisé, où les SCD peuvent provoquer de nombreuses mises à jour de la table de faits plate.

Il n'existe pas de solution commune pour tous les cas de dimensions à évolution lente. Il est important de comprendre la nature de la modification et d'appliquer la solution ou les combinaisons de solutions les plus pertinentes à votre problème. Le reste de cette section présente quelques solutions et décrit comment les appliquer aux types de SCD.

SCD de type 1 : écraser

Les SCD de type 1 écrasent la valeur d'un attribut en la remplaçant par de nouvelles données sans conserver l'historique. Cette approche est particulièrement utile lorsque les tables de dimensions reflètent les tables principales opérationnelles. Par exemple, si le produit "crème hydratante géniale" faisait partie de la catégorie "santé et beauté" et qu'il est désormais classé dans la catégorie "cosmétiques", la modification se présente comme suit :

Avant :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC crème hydratante géniale - 2,95 L santé et beauté

Après :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC crème hydratante géniale - 2,95 L santé et beauté
cosmétiques

Si l'attribut se trouve dans une table de dimension normalisée, la modification est isolée. Vous mettez simplement à jour la ligne affectée dans la table de dimension.

Pour les modifications peu fréquentes de lignes spécifiques, vous pouvez utiliser l'instruction UPDATE DML.

update mydataset.dimension_table set PRD_CATEGORY="cosmetics" where PRD_SK="123"

Il peut arriver que vous souhaitiez synchroniser périodiquement la dimension avec la table principale opérationnelle. Un modèle courant consiste à fusionner périodiquement les vidages de votre base de données opérationnelle vers la table de dimensions BigQuery. Vous pouvez charger les nouvelles données dans une table temporaire ou créer une table externe pointant vers les données.

Tableau des dimensions :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC crème hydratante géniale - 2,95 L santé et beauté
124 PQR lotion géniale - 50 oz santé et beauté

Table temporaire :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC crème hydratante géniale - 2,95 L cosmétiques
124 PQR lotion géniale - 50 oz cosmétiques
125 XYZ t-shirt acme - xl vêtement

Vous pouvez maintenant exécuter une requête de fusion pour mettre à jour la table de dimension, puis supprimer la table temporaire.

MERGE my-dataset.dimension_table as MAIN using
my-dataset.temporary_table as TEMP
on MAIN.PRD_SK = TEMP.PRD_SK
when matched then
UPDATE SET
MAIN.PRD_CATEGORY = TEMP.PRD_CATEGORY
when not matched then
INSERT VALUES(TEMP.PRD_SK, TEMP. PRD_ID, TEMP. PRD_SK, TEMP.
PRD_CATEGORY)

Table des dimensions de résultat :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC crème hydratante géniale - 2,95 L santé et beauté
cosmétiques
124 PQR lotion géniale - 50 oz santé et beauté
cosmétiques
125 XYZ t-shirt acme - xl vêtement

SCD de type 2 : conserver l'historique des lignes

Cette méthode permet de suivre des données d'historique illimitées en créant plusieurs enregistrements pour une clé naturelle donnée, à l'aide de clés de substitution distinctes. Par exemple, la même modification illustrée dans l'exemple de SCD de type 1 sera traitée comme suit :

Avant :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY START_DATE END_DATE
123 ABC crème hydratante géniale - 2,95 L santé et beauté 31-Jan-2009 NULL

Après :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY START_DATE END_DATE
123 ABC crème hydratante géniale - 2,95 L santé et beauté 31-Jan-2009 18-JUL-2017
124 ABC crème hydratante géniale - 2,95 L cosmétiques 19-JUL-2017 NULL

Vous pouvez créer une vue ou une vue matérialisée au-dessus de cette table, puis l'utiliser dans vos requêtes d'analyse.

create view products_current as
select PRD_SK, PRD_ID, PRD_DESC, PRD_CATEGORY, PRD_START_DATE
from my-dataset.dimension_table
where END_DATE IS NULL

Si l'attribut est intégré à la table de faits d'une manière dénormalisée, la situation peut s'avérer plus favorable, tant que vous ne conservez pas les dates de début et de fin explicites de la valeur, mais que vous vous fiez aux dates de transaction. Comme la valeur précédente reste vraie pour la date et l'heure auxquelles les transactions précédentes ont eu lieu, il n'est pas nécessaire de modifier les lignes précédentes de la table de faits. La table de faits ressemblerait à ceci :

TRANSACTION_DATE PRD_SK PRD_ID PRD_DESC PRD_CATEGORY UNITS AMOUNT
18-JUL-2017 123 ABC crème hydratante géniale - 2,95 L santé et beauté 2 25.16
19-JUL-2017 124 ABC crème hydratante géniale - 2,95 L cosmétiques 1 13.50

SCD de type 3 : gérer l'historique en ajoutant des colonnes

Cette méthode permet de suivre les données de l'historique limité à l'aide de colonnes distinctes afin de préserver l'historique limité. Étant donné que BigQuery accepte les champs imbriqués et répétés, il est possible de conserver l'historique dans la même colonne, en utilisant un type de tableau dans l'ordre croissant par la valeur START_DATE. Comme pour le type SCD 2, vous pouvez créer une vue ou une vue matérialisée au-dessus de la table pour faciliter la création d'une requête.

Table de base :

PRD_SK PRD_ID PRD_DESC PRD_CATEGORY
123 ABC crème hydratante géniale - 2,95 L CATEGORY_NAME START_DATE END_DATE
santé et beauté 31-Jan-2009 18-Jul-2017
cosmétiques 18-Jul-2017 NULL

Créez la vue pour sélectionner le nom de la dernière catégorie de produits dans le tableau PRD_CATEGORY :

create view my-dataset.products_current as
select PRD_SK, PRD_ID, PRD_DESC,
PRD_CATEGORY.ordinal[array_length(PRD_CATEGORY)] as PRD_CAT
from my-dataset.dimension_table;

Afficher :

PRD_SK PRD_ID PRD_DESC PRD_CAT
123 ABC crème hydratante géniale - 2,95 L cosmétiques

Réplication en quasi-temps réel

Si vous souhaitez que les données mises à jour de votre base de données opérationnelle soient disponibles pour l'analyse en temps quasi réel, vous pouvez utiliser la réplication de base de données vers BigQuery à l'aide de la capture de données modifiées (CDC).

Interroger les données

BigQuery est compatible avec les requêtes SQL standards et la révision SQL:2011 du langage SQL définie par l'ANSI. La documentation de référence SQL sur BigQuery fournit une description complète de la totalité des fonctions, opérateurs et fonctionnalités regex compatibles.

Étant donné que BigQuery est compatible avec les champs imbriqués et répétés dans le cadre du modèle de données, sa compatibilité avec SQL a été spécifiquement étendue à ces types de champs. Par exemple, en utilisant l'ensemble de données public GitHub, vous pouvez émettre la commande UNNEST, permettant l'itération sur un champ répété :

SELECT
  name, count(1) as num_repos
FROM
  `bigquery-public-data.github_repos.languages`, UNNEST(language)
GROUP BY name
ORDER BY num_repos
DESC limit 10

Requêtes interactives

La console Web de BigQuery permet l'interrogation interactive des ensembles de données et fournit une vue consolidée des ensembles de données de tous les projets auxquels vous avez accès. La console fournit également plusieurs fonctionnalités utiles, telles que la sauvegarde et le partage de requêtes ad-hoc, le réglage et la modification de requêtes d'historique, l'exploration de tables et de schémas ainsi que la collecte de métadonnées de table. Pour en savoir plus, consultez la page Console Web de BigQuery.

Fonctionnalités de la console Web BigQuery

Fonctions définies par l'utilisateur

BigQuery accepte également les fonctions définies par l'utilisateur pour les requêtes dont la complexité dépasse les capacités d'une instruction SQL. Ces fonctions permettent d'étendre les fonctions SQL intégrées. Elles prennent une liste de valeurs, qui peuvent être de type ARRAY ou STRUCT, et renvoient une valeur unique qui peut également être de type ARRAY ou STRUCT. Les fonctions définies par l'utilisateur peuvent être écrites en SQL standard et en JavaScript. Dans les fonctions JavaScript définies par l'utilisateur, vous pouvez inclure des ressources externes, telles que le chiffrement ou d'autres bibliothèques. Nous vous recommandons d'utiliser les fonctions SQL définies par l'utilisateur, car elles sont plus performantes que les fonctions JavaScript définies par l'utilisateur. Pour obtenir des exemples de fonctions définies par l'utilisateur couramment utilisées et créées par l'équipe des services professionnels Google Cloud, consultez la page GitHub bigquery-utils.

Développement de scripts et procédures stockées

Les utilisateurs de la version Enterprise exécutent souvent une logique complexe dans des entrepôts de données. La fonctionnalité de scripts de BigQuery permet d'écrire des scripts SQL standards, qui permettent d'utiliser des variables et des instructions de contrôle, et de les exécuter dans votre entrepôt de données BigQuery. Les procédures stockées permettent d'enregistrer ces scripts pour qu'ils s'exécutent dans BigQuery dans les cas d'utilisation futurs. Comme pour les vues, vous pouvez également partager une procédure stockée avec les autres membres de votre organisation, tout en conservant une version canonique de la procédure. Vous trouverez des exemples de scripts et de procédures stockées sur la page GitHub bigquery-utils.

Requêtes automatisées

Il est courant d'automatiser l'exécution de requêtes en fonction d'une planification ou d'un événement, et de mettre en cache les résultats en vue d'une utilisation ultérieure. Vous pouvez utiliser les requêtes programmées de BigQuery pour exécuter régulièrement les instructions de langage de définition de données (LDD) et de langage de manipulation de données (LMD).

Pour les orchestrations simples, telles que l'automatisation des tâches de chargement à partir d'un bucket Cloud Storage, vous pouvez utiliser un déclencheur Cloud Storage pour exécuter une fonction Cloud qui exécute une tâche BigQuery. Pour les tâches planifiées, vous pouvez déclencher la fonction Cloud à partir de Cloud Scheduler. Pour les workflows plus complexes, vous pouvez orchestrer d'autres activités automatisées à l'aide de Cloud Composer en utilisant des opérateurs BigQuery Airflow.

API BigQuery Storage

Il est courant que les entreprises disposent de pipelines devant lire une grande quantité de données depuis BigQuery. L'API BigQuery Storage permet de lire des flux parallèles de données structurées sérialisées. Cette approche permet de surmonter les limites de performances de la lecture de lignes paginées et de l'exportation de données vers Cloud Storage.

Les pipelines existants créés à l'aide d'Apache Beam ou d'Apache Spark peuvent utiliser l'API BigQuery Storage avec une configuration supplémentaire minimale ou nulle.

Optimisation des requêtes

Pour comprendre les caractéristiques de performance après l'exécution d'une requête, consultez l'explication détaillée du plan de requête. Elle décrit les étapes franchies par la requête, le nombre de lignes d'entrée/sortie traitées à chaque étape ainsi que le profil de minutage de chaque étape. Les résultats fournis dans l'explication peuvent vous aider à comprendre et à optimiser vos requêtes.

Entrée et sortie de la requête

Réduire l'analyse des données

BigQuery n'est pas compatible avec les index, et ne les utilise donc pas. Chaque fois qu'il exécute une requête, il analyse la colonne complète. Les coûts liés aux requêtes et aux performances de BigQuery étant basés sur la quantité de données analysées au cours d'une requête, nous vous recommandons de concevoir vos requêtes de sorte qu'elles ne référencent que les colonnes pertinentes. Lorsque vous utilisez des tables partitionnées, seules les partitions pertinentes doivent être analysées. Vous pouvez éviter les analyses indésirables en utilisant des filtres de partition basés sur la colonne de partition. Si vous avez des requêtes qui filtrent fréquemment sur des colonnes particulières, envisagez de mettre en cluster la table. Si vous devez fréquemment exécuter une requête d'agrégation pour un traitement ultérieur, envisagez de matérialiser la requête. Cette approche réduit les exigences de calcul ainsi que la quantité de données à analyser.

Réduire les besoins en calcul

Nous vous recommandons d'éviter d'utiliser des fonctions JavaScript définies par l'utilisateur. Lorsque cela est possible, utilisez plutôt des fonctions SQL définies par l'utilisateur. Une autre façon d'accélérer les requêtes consiste à utiliser des agrégations approximatives, telles que APPROX_COUNT_DISTINCT au lieu de COUNT(DISTINCT).

Améliorer les performances des jointures

Les entreprises doivent souvent joindre plusieurs tables, en particulier lorsque les entrepôts de données possèdent un schéma en étoile ou en flocon. Une table de faits est généralement plus grande qu'une table de dimension. Dans le schéma en flocon, comme les dimensions sont normalisées, vous pouvez avoir des tables de dimension encore plus petites. Il est recommandé de commencer par la table de faits sur la gauche et de la joindre aux tables de dimension plus petites sur la droite, par taille décroissante. Lorsqu'une grande table constitue le côté gauche de la jointure JOIN et une petite le côté droit de la jointure JOIN, une jointure de diffusion est créée. Celle-ci envoie toutes les données de la plus petite table à chaque emplacement qui traite la plus grande table.

Pour en savoir plus, consultez l'article Migrer des entrepôts de données vers BigQuery : optimisation des performances.

Sources externes

Pour les cas d'utilisation où vous souhaitez joindre une petite table opérationnelle fréquemment modifiée à vos tables BigQuery, BigQuery accepte les sources de données externes telles queCloud Bigtable et Cloud SQL. Cette approche garantit que les données n'ont pas besoin d'être rechargées à chaque mise à jour.

Comme BigQuery est compatible avec l'interrogation de données dans de nombreux formats comme Avro, Parquet et ORC, vous pouvez l'utiliser pour transformer des données et les charger dans BigQuery à partir de Google Drive ou Cloud Storage en un seul passage. Il est également possible d'interroger les données de votre lac de données existant dans Cloud Storage à partir de BigQuery, en suivant la configuration partitionnée par défaut Hive. Par exemple, une table d'un lac de données d'entreprise est stockée dans un bucket Cloud Storage au format Parquet avec le modèle de partitionnement Hive suivant :

gs://my_bucket/my_table/{dt:DATE}/{val:STRING}

Pour effectuer la requête, l'utilisateur peut créer une table externe dans BigQuery avec le modèle de partitionnement Hive. Lorsque l'utilisateur exécute des requêtes sur cette table, BigQuery respecte le schéma de partition Hive et réduit les données analysées.

Ceci est particulièrement utile lorsque vous migrez votre entrepôt de données vers BigQuery de manière progressive, car vous pouvez migrer toutes les requêtes vers BigQuery sans déplacer vos données.

Pour plus d'informations sur les sources de données externes dans BigQuery, consultez la page Présentation des sources de données externes.

Partage des requêtes

BigQuery permet aux collaborateurs de sauvegarder et de partager des requêtes entre membres d'équipe. Cette fonctionnalité peut s'avérer particulièrement utile dans les exercices d'exploration de données ou pour se familiariser rapidement avec un nouvel ensemble de données ou un nouveau modèle de requête. Pour plus d'informations, consultez la page Enregistrer et partager des requêtes.

Analyser des données

Cette section présente diverses manières de vous connecter à BigQuery et d'analyser les données. Pour tirer pleinement parti de BigQuery en tant que moteur d'analyse, vous devez stocker les données dans l'espace de stockage BigQuery. Toutefois, selon votre cas d'utilisation spécifique, il peut être bénéfique d'analyser des sources externes, soit seules, soit jointes à des données stockées dans BigQuery.

Outils du commerce

Google Data Studio, Looker, ainsi que de nombreux outils partenaires déjà intégrés à BigQuery permettent d'effectuer des analyses à partir de BigQuery et de créer des visualisations de données sophistiquées et interactives. Si vous connaissez les interfaces de feuille de calcul, vous pouvez accéder aux données, les analyser, les visualiser et les partager dans BigQuery à partir de Sheets à l'aide de feuilles connectées.

Si vous êtes dans une situation où vous devez choisir un outil, vous trouverez une comparaison complète des fournisseurs dans le rapport Magic Quadrant de Gartner et le rapport de score G2 de G2 Crowd. Le rapport Gartner est disponible sur de nombreux sites partenaires, tels que Tableau.

Développement personnalisé

Pour créer des applications et des plates-formes personnalisées sur BigQuery, vous pouvez recourir aux bibliothèques clientes disponibles pour les langages de programmation les plus courants, ou utiliser directement l'API REST de BigQuery. Pour obtenir un exemple, consultez la section Créer des tableaux de bord interactifs personnalisés avec Bokeh et BigQuery, qui utilise des bibliothèques Python pour se connecter à BigQuery et générer des tableaux de bord interactifs personnalisés.

Connecteurs tiers

Pour vous connecter à BigQuery depuis une application qui n'est pas intégrée de manière native à BigQuery au niveau de l'API, vous pouvez utiliser les pilotes JDBC et ODBC pour BigQuery. Ces pilotes fournissent un pont permettant aux applications héritées ou difficilement modifiables, telles que Microsoft Excel, d'interagir avec BigQuery. Si les outils ODBC et JDBC peuvent interagir avec BigQuery à l'aide de SQL, ils ne sont pas aussi expressifs que le traitement direct avec l'API.

Coûts

La plupart des entrepôts de données desservent plusieurs entités commerciales au sein de l'organisation. L'analyse du coût de fonctionnement par entité commerciale constitue un défi courant. Pour obtenir des conseils sur la ventilation de votre facture et l'attribution d'un coût à une consommation, consultez l'article Visualiser la facturation Google Cloud à l'aide de BigQuery et Data Studio.

BigQuery comporte trois principales catégories de coûts : les coûts de chargement, de stockage et de requête. Le projet qui détient l'ensemble de données BigQuery est facturé aux tarifs de stockage mensuels standards. Le projet qui lance la requête ou la charge est facturé pour le coût de calcul. Cette section présente chaque catégorie en détail.

Stocker des données

Le tarif de stockage est calculé au prorata par Mbit/s.

Si une table n'a pas été modifiée pendant 90 jours consécutifs, elle est classée dans la catégorie de stockage à long terme et le tarif du stockage de cette table chute automatiquement de 50 % à 0,01 $ par Go et par mois. Lorsqu'une table est considérée comme un espace de stockage à long terme, cela n'a aucune incidence sur les performances, la durabilité, la disponibilité ou toute autre fonctionnalité.

Lorsque les données d'une table sont modifiées, BigQuery réinitialise le chronomètre de la table. Toutes les données de la table reviennent alors au tarif de stockage normal. Les actions qui ne manipulent pas directement des données, telles que l'interrogation et la création de vues, ne réinitialisent pas le chronomètre. Pour les tables partitionnées, le même modèle s'applique aux segments de partition individuels.

Pour en savoir plus, consultez les tarifs de stockage BigQuery.

Chargement de données

Vous pouvez charger des données dans BigQuery à l'aide d'une tâche de chargement classique, sans aucuns frais. Une fois les données chargées, vous payez le stockage, comme indiqué dans la section précédente.

Les insertions en flux continu sont facturées en fonction de la quantité de données transférées en continu. Pour plus d'informations, consultez les coûts des insertions en flux continu répertoriés dans la section Tarifs du stockage BigQuery.

Interroger les données

Pour les requêtes, BigQuery propose deux modèles de tarification: à la demande et au forfait avec des réservations.

Tarifs à la demande

Dans le modèle à la demande, BigQuery facture la quantité de données ayant fait l'objet d'un accès lors de l'exécution de la requête. Étant donné que BigQuery utilise un format de stockage en colonnes, seules les colonnes pertinentes à la requête font l'objet d'un accès. Si vous n'exécutez des rapports que sur une base hebdomadaire ou mensuelle, et que vous avez interrogé moins de 1 To de données, vous constaterez peut-être que le coût des requêtes sur votre facture est très bas.

Pour en savoir plus sur la facturation des requêtes, consultez les tarifs des requêtes BigQuery.

Pour vous aider à déterminer au préalable la quantité de données qu'une requête va analyser, vous pouvez utiliser l'outil de validation des requêtes dans l'interface utilisateur Web. Dans le cas d'un développement personnalisé, vous pouvez définir l'option dryRun dans la requête d'API et empêcher BigQuery d'exécuter la tâche, pour renvoyer plutôt des statistiques sur la tâche, telles que le nombre d'octets à traiter. Pour en savoir plus reportez-vous à l'API Query.

Coût des requêtes

Réservations BigQuery

Pour des dépenses mensuelles plus cohérentes, vous pouvez choisir d'activer les tarifs forfaitaires via les réservations BigQuery. Cette option vous permet de souscrire des engagements de capacité pour un nombre spécifique d'emplacements BigQuery pour votre organisation et de les attribuer à des projets spécifiques.

Vous pouvez prendre des engagements mensuels ou annuels. Vous pouvez également souscrire des engagements d'emplacements Flex, ce qui vous permet d'acheter des emplacements supplémentaires pour au moins 60 secondes. Une fois que vous avez acheté des emplacements, vous pouvez les attribuer à des buckets différents, appelés réservations. Les réservations créent une allocation d'emplacements nommée. Pour utiliser les emplacements que vous avez achetés, vous devez attribuer des projets, des dossiers ou des organisations aux réservations. Chaque niveau de la hiérarchie des ressources hérite de l'attribution du niveau supérieur, à moins que vous n'ignoriez ce paramètre.

Pour isoler votre capacité engagée répartie entre les charges de travail, les équipes ou les services, vous pouvez créer des réservations supplémentaires et attribuer des projets à ces réservations à l'aide de BigQuery Reservations.

Dans le premier exemple de scénario illustré ci-dessous, 1 000 emplacements sont requis pour deux types de charges de travail : data science (DS) et informatique décisionnelle (BI). Dans le deuxième exemple de scénario, 1 000 emplacements sont nécessaires pour exécuter des tâches ELT toutes les heures pendant 15 minutes.

Exemple de réservation d'emplacements

Dans le premier scénario pour les tâches DS et les tâches d'informatique décisionnelle, vous utiliserez les engagements et les réservations comme suit :

  • Créez un engagement mensuel ou annuel de 1 000 emplacements.
  • Créez une réservation d'emplacement DS 500 et attribuez tous les projets Google Cloud pertinents à la réservation DS.
  • Créez une réservation BI de 500 emplacements et attribuez les projets associés à vos outils BI à la réservation BI.

Dans un second scénario pour les tâches ELT, vous utiliseriez les engagements et les réservations comme suit :

  • Créez une réservation d'emplacements Flex de 1 000 emplacements.
  • Créez une réservation ELT avec 1 000 emplacements, puis attribuez le projet concerné à la réservation ELT.
  • Une fois les tâches ELT terminées, vous supprimez l'attribution, la réservation ELT et l'engagement.

Étape suivante