Présentation du chargement des données

Cette page vous offre un aperçu du chargement des données dans BigQuery.

Présentation

Il existe plusieurs façons d'ingérer des données dans BigQuery :

  • Chargez un ensemble d'enregistrements de données par lots.
  • Diffuser des enregistrements individuels ou des lots d'enregistrements.
  • Utilisez des requêtes pour générer de nouvelles données et ajouter ou écraser les résultats dans une table.
  • Utiliser une application ou un service tiers

Chargement par lot

Avec le chargement par lot, vous chargez les données sources dans une table BigQuery en une seule opération par lot. Par exemple, la source de données peut être un fichier CSV, une base de données externe ou un ensemble de fichiers journaux. Les tâches traditionnelles d'extraction, de transformation et de chargement (ETL) entrent dans cette catégorie.

Les options de chargement par lots dans BigQuery sont les suivantes :

  • Chargez des données à partir de Cloud Storage ou d'un fichier local en créant une tâche de chargement. Les enregistrements peuvent être au format Avro, CSV, JSON, ORC ou Parquet.
  • Utiliser le service de transfert de données BigQuery pour automatiser le chargement de données depuis des applications SaaS (Software as a Service) de Google ou depuis des applications et services tiers.
  • Utilisez l'API BigQuery Storage Write (bêta) en mode attente.
  • Utilisez d'autres services gérés pour exporter les données d'un datastore externe et les importer dans BigQuery. Par exemple, vous pouvez charger des données à partir d'exportations Firestore.

Le chargement par lots peut être effectué une seule fois ou selon un calendrier récurrent. Par exemple, vous pouvez effectuer les opérations suivantes :

  • Vous pouvez exécuter des transferts du service de transfert de données BigQuery de manière planifiée.
  • Vous pouvez utiliser un service d'orchestration tel que Cloud Composer pour planifier des tâches de chargement.
  • Vous pouvez utiliser une tâche Cron pour charger des données de manière planifiée.

Streaming

Avec le streaming, vous envoyez continuellement de petits lots de données en temps réel afin que les données soient disponibles pour l'interrogation dès qu'elles arrivent. Les options de streaming dans BigQuery sont les suivantes :

  • Utilisez la méthode tabledata.insertAll. Cette méthode est l'API d'origine pour la diffusion de données en streaming dans BigQuery.
  • Utilisez l'API BigQuery Storage Write (bêta). L'API Storage Write est disponible à un tarif inférieur à celui de la méthode insertAll et comporte des fonctionnalités plus robustes, dont une sémantique de livraison "exactement une fois".
  • Utilisez Dataflow avec le SDK Apache Beam pour configurer un pipeline de streaming qui écrit dans BigQuery.

Données générées

Vous pouvez utiliser SQL pour générer des données et stocker les résultats dans BigQuery. Les options de génération de données sont les suivantes :

  • Utiliser des instructions LMD (langage de manipulation de données) pour effectuer des insertions groupées dans une table existante ou pour stocker les résultats de requête dans une nouvelle table.

  • Utiliser une instruction CREATE TABLE ... AS pour créer une table à partir d'un résultat de requête.

  • Exécuter une requête et enregistrer les résultats dans une table. Vous pouvez ajouter les résultats à une table existante ou écrire dans une nouvelle table. Pour en savoir plus, consultez la section Écrire des résultats de requête.

Applications tierces

Certains services et applications tiers fournissent des connecteurs permettant d'ingérer des données dans BigQuery. Les informations sur la configuration et la gestion du pipeline d'ingestion dépendent de l'application.

Choisir une méthode d'ingestion de données

Voici quelques éléments à prendre en compte lorsque vous choisissez une méthode d'ingestion de données.

Source des données La source des données ou le format de données peut déterminer si le chargement par lot ou en flux est plus simple à mettre en œuvre et à gérer. Tenez compte des points suivants :

  • Si le service de transfert de données BigQuery est compatible avec la source de données, le transfert de données directement dans BigQuery peut être la solution la plus simple à mettre en œuvre.

  • Si vos données proviennent de Spark ou de Hadoop, pensez à utiliser les connecteurs BigQuery pour simplifier l'ingestion de données.

  • Pour les fichiers locaux, envisagez le chargement par lot, en particulier si BigQuery est compatible avec le format de fichier sans nécessiter une étape de transformation ou de nettoyage des données.

  • Pour les données d'application, telles que les événements d'application ou un flux de journal, il peut être plus facile de diffuser les données en temps réel plutôt que d'implémenter le chargement par lots.

Données à évolution lente et à évolution rapide. Si vous devez ingérer et analyser des données quasiment en temps réel, envisagez de les diffuser en flux continu. Avec le streaming, les données peuvent être interrogées dès que chaque enregistrement est reçu. Évitez d'utiliser des instructions LMD pour envoyer un grand nombre de mises à jour ou d'insertions de lignes individuelles. Pour les données fréquemment mises à jour, il est souvent préférable de diffuser un journal des modifications et d'utiliser une vue pour obtenir les derniers résultats. Une autre option consiste à utiliser Cloud SQL comme base de données de traitement des transactions en ligne (OLTP), et à utiliser des requêtes fédérées pour joindre les données dans BigQuery.

Si vos données sources changent lentement ou si vous n'avez pas besoin de résultats mis à jour en continu, envisagez d'utiliser une tâche de chargement. Par exemple, si vous utilisez les données pour générer un rapport quotidien ou horaire, les tâches de chargement peuvent être moins coûteuses et utiliser moins de ressources système.

Un autre scénario est celui de données qui arrivent de manière peu fréquente ou en réponse à un événement. Dans ce cas, envisagez d'utiliser Dataflow pour diffuser les données ou d'utiliser Cloud Functions pour appeler l'API de streaming en réponse à un déclencheur.

Fiabilité de la solution. BigQuery est associé à un contrat de niveau de service. Cependant, vous devez également prendre en compte la fiabilité de la solution que vous mettez en œuvre. Tenez compte des points suivants :

  • Avec des formats moins rigoureux tels que JSON ou CSV, les données incorrectes peuvent faire échouer l'ensemble de la tâche de chargement. Déterminez si vous avez besoin d'une étape de nettoyage des données avant le chargement, et réfléchissez à la résolution des erreurs. Utilisez également un type de format plus rigoureux , tel que Avro, ORC ou Parquet.
  • Les tâches de chargement périodiques nécessitent une planification, à l'aide de Cloud Composer, de Cron ou d'un autre outil. Le composant de planification peut constituer un point de défaillance dans la solution.
  • Avec le streaming, vous pouvez vérifier la réussite de chaque enregistrement et signaler rapidement une erreur. Envisagez d'écrire des messages en échec dans une file d'attente de messages non traités pour une analyse et un traitement ultérieurs. Pour en savoir plus sur les erreurs de streaming BigQuery, consultez la section Dépannage pour les insertions en flux continu.
  • Les tâches de streaming et de chargement sont soumises à des quotas. Pour en savoir plus sur la gestion des erreurs de quota, consultez la page Dépannage des erreurs de quota BigQuery.
  • Les solutions tierces peuvent différer en matière de configurabilité, de fiabilité, de garantie de classement et d'autres facteurs. Nous vous recommandons donc de les prendre en compte avant d'adopter une solution.

Latence. Réfléchissez à la quantité de données que vous chargez et à la date à laquelle elles doivent être disponibles. Le streaming offre la plus faible latence des données disponibles pour l'analyse. Les tâches de chargement périodiques ont une latence plus élevée, car les nouvelles données ne sont disponibles qu'à la fin de chaque tâche de chargement.

Les tâches de chargement utilisent un pool d'emplacements partagé par défaut. Une tâche de chargement peut attendre un état en attente jusqu'à ce que des emplacements soient disponibles, en particulier si vous chargez une très grande quantité de données. Si cela crée des temps d'attente inacceptables, vous pouvez acheter des emplacements dédiés au lieu d'utiliser le pool d'emplacements partagé. Pour plus d'informations, consultez la page Présentation des réservations.

Les performances des requêtes pour des sources de données externes peuvent être inférieures aux performances des requêtes sur les données stockées dans BigQuery. Si la réduction de la latence des requêtes est importante, nous vous recommandons de charger les données dans BigQuery.

Format de l'ingestion de données. Choisissez un format d'ingestion de données en fonction des facteurs suivants :

  • Compatibilité du schéma Les exportations Avro, ORC, Parquet et Firestore sont des formats autodescriptifs. BigQuery crée automatiquement le schéma de la table en fonction des données sources. Pour les données JSON et CSV, vous pouvez fournir un schéma explicite ou utiliser la détection automatique de schéma.

  • Données plates ou champs imbriqués et répétés Les formats Avro, CSV, JSON, ORC et Parquet sont tous compatibles avec les données plates. Les exportations aux formats Avro, JSON, ORC, Parquet et Firestore sont également compatibles avec les données comprenant des champs imbriqués et répétés. Les données imbriquées et répétées sont utiles pour exprimer des données hiérarchiques. Les champs imbriqués et répétés permettent également de réduire la duplication lors de la dénormalisation des données.

  • Les nouvelles lignes intégrées Lorsque vous chargez des données à partir de fichiers JSON, les lignes doivent être délimitées par un retour à la ligne. BigQuery s'attend à ce que les fichiers JSON délimités par un retour à ligne ne contiennent qu'un seul enregistrement par ligne.

  • Encodage BigQuery est compatible avec l'encodage UTF-8 pour les données imbriquées ou répétées, ainsi que pour les données plates. BigQuery est compatible avec l'encodage ISO-8859-1 pour les données plates de fichiers CSV exclusivement.

Charger des données dénormalisées, imbriquées et répétées

Beaucoup de développeurs sont habitués à travailler avec des bases de données relationnelles et des schémas de données normalisées. La normalisation élimine le stockage des données en double et assure la cohérence lors des mises à jour régulières des données.

La dénormalisation est une stratégie courante qui permet d'améliorer les performances de lecture sur des ensembles de données relationnels auparavant normalisés. La méthode recommandée pour dénormaliser des données dans BigQuery consiste à utiliser des champs imbriqués et répétés. Il est préférable d'employer cette stratégie lorsque vous avez affaire à des relations hiérarchiques souvent interrogées ensemble (par exemple, dans des relations parent-enfant).

Les économies de stockage rendues possibles par la normalisation des données ont moins d'impact sur les systèmes modernes. L'augmentation des coûts de stockage est justifiée par les gains de performance découlant de la dénormalisation des données. Les jointures nécessitent une coordination des données (synonyme de bande passante de communication). La dénormalisation localise les données dans des emplacements individuels, ce qui permet une exécution en parallèle.

Pour maintenir des relations tout en dénormalisant vos données, utilisez des champs imbriqués et répétés au lieu d'aplatir complètement vos données. Lorsque les données relationnelles sont complètement aplaties, la communication réseau (brassage) peut avoir un impact négatif sur les performances des requêtes.

Par exemple, dénormaliser un schéma de commandes sans utiliser de champs imbriqués et répétés peut nécessiter un regroupement par champ tel que order_id (lorsqu'il existe une relation de un à plusieurs). En raison du brassage qu'il implique, le regroupement des données est moins performant que la dénormalisation des données à l'aide de champs imbriqués et répétés.

Dans certaines circonstances, la dénormalisation des données et l'utilisation de champs imbriqués et répétés peuvent ne pas améliorer les performances. Évitez la dénormalisation dans les cas suivants :

  • Vous avez un schéma en étoile dont les dimensions changent fréquemment.
  • BigQuery complète un système de traitement des transactions en ligne (OLTP, Online Transaction Processing) avec une mutation au niveau de la ligne, mais ne peut pas le remplacer.

Les champs imbriqués et répétés sont compatibles avec les formats de données suivants :

  • Avro
  • JSON (délimité par un retour à la ligne)
  • ORC
  • Parquet
  • Exportations Cloud Datastore
  • Exportations Firestore

Pour savoir comment spécifier des champs imbriqués et répétés dans votre schéma lorsque vous chargez des données, consultez la section Spécifier des champs imbriqués et répétés.

Charger des données depuis d'autres services Google

Service de transfert de données BigQuery

Le service de transfert de données BigQuery automatise le chargement de données dans BigQuery à partir des services suivants :

Applications Google Software as a Service (SaaS) Fournisseurs de stockage cloud externes Entrepôts de donnéesEn outre, plusieurs transferts tiers sont disponibles dans Google Cloud Marketplace.

Après avoir configuré un transfert de données, le service de transfert de données BigQuery planifie et gère automatiquement les charges de données récurrentes de l'application source dans BigQuery.

Google Analytics 360

Pour découvrir comment exporter vos données de session et d'appel d'une vue de rapports Google Analytics 360 dans BigQuery, consultez la page BigQuery Export dans le centre d'aide Google Analytics.

Pour obtenir des exemples d'interrogation de données Analytics dans BigQuery, consultez la page BigQuery en pratique dans le centre d'aide Google Analytics.

Dataflow

Cloud Dataflow permet de charger des données directement dans BigQuery. Pour en savoir plus sur l'utilisation de Dataflow afin de lire et d'écrire dans BigQuery, consultez la page Connecteur d'E/S BigQuery dans la documentation Apache Beam.

Alternatives au chargement de données

Vous n'avez pas besoin de charger des données avant d'exécuter des requêtes dans les situations suivantes :

Ensembles de données publics
Les ensembles de données publics sont des ensembles de données stockés dans BigQuery et partagés avec le public. Pour plus d'informations, consultez Ensembles de données publics BigQuery.
Ensembles de données partagés
Vous pouvez partager des ensembles de données stockés dans BigQuery. Si quelqu'un a partagé un ensemble de données avec vous, vous pouvez exécuter des requêtes sur cet ensemble sans charger les données.
Sources de données externes
BigQuery peut exécuter des requêtes sur certaines formes de données externes, sans charger les données dans le stockage BigQuery. Cette approche vous permet de bénéficier des fonctionnalités analytiques de BigQuery sans déplacer les données stockées ailleurs. Pour en savoir plus sur les avantages et les limites de cette approche, consultez la section Sources de données externes.
Fichiers journaux Logging
Cloud Logging fournit une option pour exporter les fichiers journaux dans BigQuery. Consultez la page Exporter des entrées de journal avec la visionneuse de journaux pour en savoir plus.

Étapes suivantes