Bei ML-bezogenen Operationen und Analysen werden die Daten in BigQuery häufig direkt lokal heruntergeladen und verarbeitet. In letzter Zeit verwende ich häufig Laboratorien zur Analyse und Visualisierung, daher lade ich häufig Daten mit magischen Befehlen herunter, die schnell verwendet werden können. Wenn die Zieldaten jedoch größer werden, wird die zum Herunterladen erforderliche Zeit erheblich länger. Ich werde.
Also, Einführung der neuen Funktionen, die bei Google Cloud Next '19 angekündigt wurden! (Cloud Run, BigQuery Storage API, Cloud Data Fusion) Wie schnell wird die ** BigQuery Storage API ** eingeführt? Ich werde versuchen zu sehen, ob es wird.
BigQuery Storage API Weitere Informationen finden Sie im folgenden Artikel.
Um die BigQuery Storage API zu nutzen, installieren Sie die BigQuery Client Library Version 1.9.0 oder höher und die BigQuery Storage API Client Library.
pip install --upgrade google-cloud-bigquery[bqstorage,pandas]
Der Geschwindigkeitsvergleich vergleicht **, bis Sie die BQ-Daten aus der Abfrage erhalten und als pandas.DataFrame herunterladen.
Datenanalyseaufgaben verwenden häufig Abfragen, um Daten aus BQ-Tabellen abzurufen, und rufen selten die BQ-Tabelle selbst ab. Mit der BigQuery-Speicher-API können Sie einfache Zeilenfilter anwenden. Wenn Sie jedoch komplexe Filter anwenden möchten, müssen Sie diese mithilfe einer Abfrage abrufen. Daher wird die Datenerfassung mit der BigQuery Storage API-Clientbibliothek hier direkt vom Vergleich ausgeschlossen.
Die zu erfassenden Daten sind die Daten aus den öffentlichen Daten von BigQuery zu den Protokolldaten des Seitenaufrufs von Wikipedia am 1. Januar 2019 um 0:00 Uhr.
bigquery-public-data.wikipedia.pageviews_2019
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
WHERE datehour = '2019-01-01'
Die Anzahl der Spalten beträgt 4, aber diese allein hat 5.287.235 Zeilen, was ziemlich robuste Daten sind.
(Daten mit einer Reihenfolge von 1 Million Zeilen sind ein Volumen, das sich in der Analyseaufgabe in Zara befindet, daher kann es ein gutes Überprüfungsziel sein.)
Die Ausführungsumgebung befindet sich in Zusammenarbeit.
Die Erfassung mit dem magischen Befehl ist wie folgt.
%%bigquery --project <project_id> df_temp
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
Durch Ausführen des obigen Befehls in der Zelle des Labors wird das Erfassungsergebnis als pandas.DataFrame in df_temp
erhalten.
Im Labor ist die Clientbibliothek bereits installiert, sodass Sie sie so importieren können, wie sie ist.
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 Dies entspricht der zweiten Methode, die in der BigQuery Storage API-Übersicht (https://cloud.google.com/bigquery/docs/reference/storage/#background) beschrieben ist.
Die Methode besteht darin, die Abfrageergebnisse mithilfe der BQ-Clientbibliothek als temporäre Tabelle zu speichern, als AVRO-Datei in GCS zu exportieren und als pandas.DataFrame in die Ausführungsumgebung zu laden.
In dem Experiment haben wir eine interne Bibliothek entwickelt, die Daten mit dieser Methode erfasst, daher werden wir diese verwenden.
Um die BigQuery-Speicher-API mit magischen Befehlen zu verwenden, setzen Sie die Eigenschaft context.use_bqstorage_api
wie folgt auf True:
import google.cloud.bigquery.magics
google.cloud.bigquery.magics.context.use_bqstorage_api = True
Verwenden Sie danach den obigen magischen Befehl.
%%bigquery --project <project_id> df_temp
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
Um die BigQuery Storage-API in der Clientbibliothek zu verwenden, übergeben Sie einfach das BigQuery Storage API-Clientobjekt als Argument an die Methode "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)
Wie oben erwähnt, Zeit ** von der Abfrage bis pandas.DataFrame **. Die Zeitmessung erfolgt durch Anhängen des magischen Befehls "% time" an die entsprechende Zeile. Bei Verwendung der Clientbibliothek sieht es wie folgt aus:
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() # <--Hier messen
Fügen Sie in [Magic Command](#Magic Command) und [Magic Command + BigQuery Storage API](#Magic Command --bigquery-storage-api) der ersten Zeile der Zelle "%% time" hinzu, um der gesamten Zelle "%% time" hinzuzufügen. Messen Sie die Zeit.
%%time
%%bigquery --project <project_id> df_temp
SELECT * FROM `bigquery-public-data.wikipedia.pageviews_2019`
where datehour = '2019-01-01'
Bei beiden handelt es sich um One-Shot-Messungen. Beachten Sie daher, dass es Abweichungen gibt.
Methode | CPU time | Wall time |
---|---|---|
Magischer Befehl | 2min 9s | 4min 48s |
Magischer Befehl+ BigQuery Storage API | 19.6 s | 21.2 s |
BQ-Client-Bibliothek | 2min 9s | 5min 1s |
BQ -> (AVRO) -> GCS | 57.1 s | 1min 42s |
BQ-Client-Bibliothek+ BigQuery Storage API | 19.7 s | 36.8 s |
Aus dem Ergebnis geht hervor, dass die Methode mit der BigQuery-Speicher-API ** überwältigend schnell ** ist. .. .. Eine Größenordnung schneller. ..
([BQ-> (AVRO) -> GCS](# bigquery - avro - gcs) hat eine Bibliothek erstellt.)
Die Schlussfolgerung ist, dass die BigQuery-Speicher-API die erste Wahl für Speed-First-Methoden zum Abrufen von BQ-Tabellendaten aus Abfragen als pandas.DataFrame ist.
Eine letzte Anmerkung.
Zum 17. Dezember 2019 befindet es sich noch in der Beta-Phase, sodass es anscheinend nur in Multi-Regionen der USA und der EU verwendet werden kann.
Übersicht hat mehrere Regionen in den USA / der EU + einige Standorte (asia-east1
,` Beinhaltet Asien-Nordosten1 "," Asien-Süd1 "," Asien-Südosten1 "," Europa-Westen2 "," Nordamerika-Nordosten1 ", jedoch auf der Preisseite (https://cloud.google.com). / bigquery / price # storage-api) zeigt Nicht verfügbar an, außer für US / EU-Multiregionen.
(Kann es tatsächlich verwendet werden, nur weil das Dokument nicht aufholt?)
Bitte achten Sie bei der Verwendung auf den Speicherort des Datensatzes. ..
Übrigens wird die Gebühr basierend auf der Anzahl der Bytes berechnet, die aus dem BigQuery-Speicher durch Aufrufen von "ReadRows" gelesen werden, und im Grunde wird sie gemäß der Datenmenge berechnet, die von "ReadRows" der BigQuery-Speicher-API gelesen wird. Es scheint ein Mechanismus zu sein (es tut mir leid, wenn die Erkennung falsch ist).
Beim Ausführen einer Abfrage
Für die aus der temporären Tabelle gelesenen Daten wird keine Gebühr erhoben. Da es
gibt, gibt es keine Gebühr für die Speicher-API selbst, nur die Gebühr für die Ausführung der Abfrage.
Beim Erwerb der gesamten Tabelle 1,10 USD pro TB in mehreren Regionen der USA
(@ na0 Danke m (_ _) m)
Recommended Posts