Lors d'opérations et d'analyses liées au ML, il arrive souvent que les données sur BigQuery soient directement téléchargées localement et traitées. Récemment, j'utilise souvent colaboratory pour l'analyse et la visualisation, donc je télécharge souvent des données avec des commandes magiques qui peuvent être utilisées rapidement, mais à mesure que les données cibles deviennent plus grandes, le temps requis pour le téléchargement devient considérablement plus long. Je vais.
Alors, Présentation des nouvelles fonctionnalités annoncées lors de Google Cloud Next '19! (Cloud Run, API BigQuery Storage, Cloud Data Fusion) À quelle vitesse la ** API BigQuery Storage ** est-elle introduite? Je vais essayer de voir si cela devient.
BigQuery Storage API Veuillez vous référer à l'article suivant pour plus de détails.
Pour tirer parti de l'API BigQuery Storage, installez la bibliothèque cliente BigQuery version 1.9.0 ou ultérieure et la bibliothèque cliente de l'API BigQuery Storage.
pip install --upgrade google-cloud-bigquery[bqstorage,pandas]
La comparaison de vitesse compare ** jusqu'à ce que vous obteniez les données BQ de la requête et que vous les téléchargiez en tant que pandas.DataFrame.
Les tâches d'analyse des données utilisent souvent des requêtes pour récupérer les données des tables BQ et récupèrent rarement la table BQ elle-même. L'API BigQuery Storage vous permet d'appliquer des filtres de lignes simples, mais si vous souhaitez appliquer un filtrage complexe, vous devez les récupérer à l'aide d'une requête. Par conséquent, l'acquisition de données à l'aide directe de la bibliothèque cliente de l'API BigQuery Storage est exclue de la comparaison ici.
Les données à acquérir seront les données des données publiques de BigQuery aux données du journal de la page vue de Wikipédia à 0:00 le 1er janvier 2019.
bigquery-public-data.wikipedia.pageviews_2019
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
WHERE datehour = '2019-01-01'
Le nombre de colonnes est de 4, mais cela seul a 5 287 235 lignes, ce qui est des données assez robustes.
(Les données de l'ordre d'un million de lignes sont un volume qui se trouve dans Zara dans la tâche d'analyse, donc cela peut être une bonne cible de vérification)
L'environnement d'exécution est en collaboration.
L'acquisition à l'aide de la commande magique est la suivante.
%%bigquery --project <project_id> df_temp
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
En exécutant la commande ci-dessus dans la cellule de colaboratory, le résultat de l'acquisition sera obtenu sous la forme pandas.DataFrame dans df_temp.
En colaboratory, la bibliothèque cliente est déjà installée, vous pouvez donc l'importer telle quelle.
from google.cloud import bigquery
query = """
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
"""
client = bigquery.Client(project=<project_id>)
df_temp = client.query(query).to_dataframe()
BigQuery → (AVRO) → GCS C'est l'équivalent de la deuxième méthode décrite dans la présentation de l'API BigQuery Storage (https://cloud.google.com/bigquery/docs/reference/storage/#background).
La méthode consiste à enregistrer les résultats de la requête en tant que table temporaire à l'aide de la bibliothèque cliente BQ, à les exporter en tant que fichier AVRO vers GCS et à les charger en tant que pandas.DataFrame dans l'environnement d'exécution.
Dans l'expérience, nous avons développé une bibliothèque interne qui acquiert des données par cette méthode, nous allons donc l'utiliser.
Pour utiliser l'API BigQuery Storage avec des commandes magiques, définissez la propriété context.use_bqstorage_api sur True comme suit:
import google.cloud.bigquery.magics
google.cloud.bigquery.magics.context.use_bqstorage_api = True
Après cela, utilisez la commande magique ci-dessus.
%%bigquery --project <project_id> df_temp
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
Pour utiliser l'API BigQuery Storage dans la bibliothèque cliente, transmettez simplement l'objet client de l'API BigQuery Storage en tant qu'argument à la méthode to_dataframe (). (Cantan!)
from google.cloud import bigquery
from google.cloud import bigquery_storage_v1beta1
query = """
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
"""
bq_client = bigquery.Client(project=<project_id>)
bqstorage_client = bigquery_storage_v1beta1.BigQueryStorageClient()
df_temp = bq_client.query(query).to_dataframe(bqstorage_client)
Comme indiqué ci-dessus, le temps ** entre la requête et pandas.DataFrame **. La mesure du temps est effectuée en attachant la commande magique «% time» à la ligne correspondante. Lors de l'utilisation de la bibliothèque cliente, cela ressemble à ce qui suit:
from google.cloud import bigquery
query = """
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
"""
client = bigquery.Client(project=<project_id>)
%time df_temp = client.query(query).to_dataframe() # <--Mesurer ici
Dans [Magic Command](#Magic Command) et [Magic Command + BigQuery Storage API](#Magic Command --bigquery-storage-api), ajoutez «%% time» à la première ligne de la cellule pour ajouter «%% time» à la cellule entière. Mesurez le temps.
%%time
%%bigquery --project <project_id> df_temp
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
Les deux sont des mesures uniques, alors sachez qu'il existe des variations.
| Méthode | CPU time | Wall time |
|---|---|---|
| Commande magique | 2min 9s | 4min 48s |
| Commande magique+ BigQuery Storage API | 19.6 s | 21.2 s |
| Bibliothèque cliente BQ | 2min 9s | 5min 1s |
| BQ -> (AVRO) -> GCS | 57.1 s | 1min 42s |
| Bibliothèque cliente BQ+ BigQuery Storage API | 19.7 s | 36.8 s |
D'après le résultat, la méthode utilisant l'API BigQuery Storage est ** extrêmement rapide **. .. .. Un ordre de grandeur plus rapide. ..
([BQ-> (AVRO) -> GCS](# bigquery - avro - gcs) a créé une bibliothèque.)
La conclusion est que l'API BigQuery Storage est le choix pour les méthodes rapides de récupération des données de table BQ à partir de requêtes en tant que pandas.DataFrame.
Une dernière note.
Au 17 décembre 2019, il était toujours en version bêta, il semble donc qu'il ne puisse être utilisé que dans les multi-régions des États-Unis et de l'UE.
vue d'ensemble a la multi-région US / EU + quelques emplacements (ʻasia-east1, , Asia-Nordest1, ʻasia-sud1, ʻasia-sud-est1, ʻeurope-west2, northamerica-nordest1`) est incluse, mais [Price Page](https://cloud.google.com / bigquery / pricing # storage-api) indique Indisponible sauf pour les multi-régions US / EU.
(En fait, peut-il être utilisé simplement parce que le document ne rattrape pas son retard?)
Veuillez faire attention à l'emplacement de l'ensemble de données lors de son utilisation. ..
À propos, les frais sont facturés en fonction du nombre d'octets lus à partir du stockage BigQuery en appelant ReadRows, et ils sont essentiellement facturés en fonction de la quantité de données lues par ReadRows de l'API BigQuery Storage. Cela semble être un mécanisme (je suis désolé si la reconnaissance est erronée).
Lors de l'exécution d'une requête
Il n'y a pas de frais pour les données lues à partir de la table temporaire. Puisqu'il y a , il n'y a pas de frais pour l'API de stockage elle-même, seulement les frais pour l'exécution de la requête.
Lors de l'acquisition de la table entière 1,10 USD par TB dans la multirégion américaine
(@ na0 Merci m (_ _) m)
Recommended Posts