Interroger et analyser des données Bigtable avec BigQuery

BigQuery est un entrepôt de données géré qui peut vous aider à interroger et à analyser vos données Bigtable à l'aide de requêtes SQL. BigQuery est utile aux analystes de données, aux ingénieurs de données, aux data scientists ou à toute personne souhaitant utiliser les données Bigtable pour répondre à des questions commerciales.

BigQuery vous permet d'interroger vos données Bigtable depuis BigQuery. Cette fonctionnalité est utile lorsque vous souhaitez joindre vos données Bigtable à des tables BigQuery.

Ce document présente l'interrogation des données Bigtable avec BigQuery. Avant de lire cette page, vous devez avoir pris connaissance de la présentation de Bigtable et de la présentation de BigQuery.

L'utilisation de BigQuery pour interroger une table Bigtable est idéale pour les tables qui comportent les mêmes familles de colonnes et les mêmes qualificatifs de colonne dans chaque ligne.

Création de tables externes

Avant de pouvoir interroger vos données Bigtable, vous ou un administrateur de votre organisation devez créer une table externe. Il s'agit d'une table BigQuery contenant des pointeurs de métadonnées vers votre table Bigtable, vers laquelle vous envoyez vos requêtes. Pour en savoir plus sur les tables externes, consultez Présentation des sources de données externes.

Vous devez créer la table externe dans la même région que la table Bigtable. Cela signifie, par exemple, que si la table se trouve dans une instance comportant des clusters à europe-central2-a (Varsovie), europe-west1-c (Belgique) et asia-east1-a (Tokyo), vous devez créer la table externe à Varsovie, en Belgique ou à Tokyo.

Nous vous recommandons de suivre les bonnes pratiques suivantes lorsque vous créez votre table externe :

  • Pour éviter d'impacter le trafic de diffusion de votre application, utilisez le service de calcul sans serveur Data Boost lorsque vous lisez des données Bigtable avec des tables externes BigQuery. L'utilisation de Data Boost est particulièrement rentable pour les requêtes ad hoc. Pour utiliser Data Boost, spécifiez le profil d'application Data Boost lorsque vous créez la définition de table externe. Pour en savoir plus sur Data Boost, consultez la présentation de Bigtable Data Boost.

  • Dans la plupart des cas, lorsque vous créez une table externe, définissez readRowkeyAsString et ignoreUnspecifiedColumnFamilies sur true.

  • Lorsque ignoreUnspecifiedColumnFamilies est défini sur "true", lorsque vous créez une définition de table qui n'inclut que certaines colonnes d'une famille de colonnes, seules les colonnes sélectionnées sont promues en tant que colonnes dans la table externe. Les données des colonnes non sélectionnées sont regroupées dans une colonne column générale.

Pour créer votre table externe, suivez les instructions de la section Créer une table externe Bigtable.

Interroger les données de la table externe

Une fois que vous disposez d'une table externe pour votre table Bigtable, vous pouvez lui envoyer des requêtes SQL à l'aide de l'une des méthodes suivantes :

Pour savoir comment composer et exécuter une requête, consultez Exécuter une requête. Pour obtenir des instructions spécifiques à Bigtable, y compris les autorisations requises et des exemples de code, consultez Interroger des données Bigtable.

Requêtes programmées

Les requêtes programmées sont utiles lorsque vous souhaitez importer des données Bigtable dans BigQuery de manière récurrente. Ils sont également utiles pour les cas d'utilisation qui pourraient autrement vous obliger à créer un pipeline de données et à diffuser les données dans BigQuery. Pour savoir comment gérer les requêtes programmées, consultez Planifier des requêtes.

Analyses complètes des tables

Si vous utilisez Data Boost pour lire vos données, vous n'avez pas besoin d'éviter d'analyser l'intégralité de la table. En revanche, si vous utilisez des nœuds provisionnés pour le calcul, vous devez le faire. De même que lorsque vous envoyez des requêtes de lecture directement à votre table Bigtable, lorsque vous interrogez la table externe pour la table et que vous n'utilisez pas Data Boost, vous devez généralement éviter les analyses complètes de la table. Les analyses complètes de tables augmentent l'utilisation du processeur et prennent beaucoup plus de temps que les requêtes sélectives. Ils nécessitent également un débit BigQuery plus élevé.

Si votre requête implique toutes les lignes, elle déclenche une analyse complète de la table. En revanche, si vous limitez la requête et demandez une plage de lignes ou des lignes non contiguës spécifiques, l'intégralité de la table n'est pas analysée. Voici quelques exemples de limitation de la requête en syntaxe GoogleSQL :

  • WHERE rowkey = "abc123"
  • WHERE rowkey BETWEEN "abc123" PRECEDING AND "abc999" FOLLOWING
  • WHERE rowkey > 999999 (si vous lisez la clé de ligne en tant que chaîne)

Jointures

Si vous prévoyez d'utiliser une jointure pour analyser les données de votre table Bigtable conjointement à celles d'une autre source, vous devez créer une sous-requête qui extrait les champs pertinents de Bigtable pour la jointure prévue. Pour découvrir d'autres bonnes pratiques concernant l'association de tables, consultez Optimiser le calcul des requêtes.

Coûts

Lorsque vous créez une table externe et que vous l'interrogez, vous êtes facturé pour les coûts BigQuery et pour l'augmentation du nombre de nœuds Bigtable nécessaires pour gérer le trafic. Comme votre table externe se trouve dans la même région que votre table Bigtable, aucun frais de réseau n'est facturé.

Si vous avez tendance à exécuter vos requêtes pendant les heures d'ouverture habituelles, envisagez d'activer l'autoscaling Bigtable afin que le nombre de nœuds augmente si nécessaire, puis diminue une fois les jobs terminés. L'autoscaling est également une tactique efficace si vous exécutez des requêtes planifiées sans date limite précise.

Une autre façon de limiter les coûts consiste à éviter une analyse complète de la table.

Pour en savoir plus sur l'optimisation des coûts pour BigQuery, consultez Estimer et contrôler les coûts.

Limites

La limite suivante s'applique :

  • Les résultats de requête contenant des données sérialisées avec des types imbriqués, tels que les formats Protocol Buffer (protobufs) et Avro, peuvent s'afficher de manière incorrecte ou être difficiles à lire dans la console Google Cloud .

Étapes suivantes