Diese Seite wurde von der Cloud Translation API übersetzt.

Bigtable-Daten mit BigQuery abfragen und analysieren

BigQuery ist ein verwaltetes Data Warehouse, mit dem Sie Ihre Bigtable-Daten mithilfe von SQL-Abfragen abfragen und analysieren können. BigQuery ist nützlich für Datenanalysten, Data Engineers, Data Scientists oder alle, die Bigtable-Daten verwenden möchten, um geschäftliche Fragen zu beantworten.

Mit BigQuery können Sie Ihre Bigtable-Daten in BigQuery abfragen. Dieses Feature ist hilfreich, wenn Sie Ihre Bigtable-Daten mit BigQuery-Tabellen verknüpfen möchten.

Dieses Dokument bietet einen Überblick über das Abfragen von Bigtable-Daten mit BigQuery. Bevor Sie diese Seite lesen, sollten Sie sich mit der Bigtable-Übersicht und der BigQuery-Übersicht vertraut machen.

Die Verwendung von BigQuery zum Abfragen einer Bigtable-Tabelle ist ideal für Tabellen, die in jeder Zeile dieselben Spaltenfamilien und Spaltenqualifizierer haben.

Externe Tabelle erstellen

Bevor Sie Ihre Bigtable-Daten abfragen können, müssen Sie oder ein Administrator in Ihrer Organisation eine externe Tabelle erstellen. Das ist eine BigQuery-Tabelle, die Metadatenverweise auf Ihre Bigtable-Tabelle enthält, an die Sie Ihre Abfragen senden. Weitere Informationen zu externen Tabellen finden Sie unter Einführung in externe Datenquellen.

Sie müssen die externe Tabelle in derselben Region wie die Bigtable-Tabelle erstellen. Wenn sich die Tabelle beispielsweise in einer Instanz mit Clustern in europe-central2-a (Warschau), europe-west1-c (Belgien) und asia-east1-a (Tokio) befindet, müssen Sie die externe Tabelle in Warschau, Belgien oder Tokio erstellen.

Empfohlene Konfigurationen

Wir empfehlen die folgenden Best Practices beim Erstellen der externen Tabelle:

Um den Traffic Ihrer Anwendung nicht zu beeinträchtigen, sollten Sie Data Boost-Serverless Compute verwenden, wenn Sie Bigtable-Daten mit externen BigQuery-Tabellen lesen. Data Boost ist besonders kostengünstig für Ad‑hoc-Abfragen. Wenn Sie Data Boost verwenden möchten, geben Sie beim Erstellen der Definition der externen Tabelle das Data Boost-Anwendungsprofil an. Weitere Informationen zu Data Boost finden Sie unter Bigtable Data Boost-Übersicht.
In den meisten Fällen sollten Sie beim Erstellen einer externen Tabelle readRowkeyAsString und ignoreUnspecifiedColumnFamilies auf true setzen.
Wenn ignoreUnspecifiedColumnFamilies auf „true“ gesetzt ist und Sie eine Tabellendefinition erstellen, die nur einige Spalten in einer Spaltenfamilie enthält, werden nur die ausgewählten Spalten als Spalten in der externen Tabelle hochgestuft. Daten in den nicht ausgewählten Spalten werden in einer allgemeinen Spalte column gruppiert.

Folgen Sie der Anleitung unter Externe Bigtable-Tabelle erstellen, um eine externe Tabelle zu erstellen.

Daten in der externen Tabelle abfragen

Nachdem Sie eine externe Tabelle für Ihre Bigtable-Tabelle erstellt haben, können Sie SQL-Abfragen mit einer der folgenden Methoden an sie senden:

Über die Befehlszeile mit bq, der BigQuery-Befehlszeile
Aufrufe der BigQuery API
Eine der BigQuery-Clientbibliotheken

Informationen zum Erstellen und Ausführen einer Abfrage finden Sie unter Eine Abfrage ausführen. Bigtable-spezifische Anleitungen, einschließlich erforderlicher Berechtigungen und Codebeispiele, finden Sie unter Daten in Bigtable abfragen.

Geplante Abfragen

Geplante Abfragen sind nützlich, wenn Sie Bigtable-Daten regelmäßig in BigQuery importieren möchten. Sie sind auch für Anwendungsfälle nützlich, für die Sie sonst eine Datenpipeline erstellen und die Daten in BigQuery streamen müssten. Eine Anleitung zum Verwalten geplanter Abfragen finden Sie unter Abfragen planen.

Vollständige Tabellenscans

Wenn Sie Data Boost zum Lesen Ihrer Daten verwenden, müssen Sie nicht vermeiden, die gesamte Tabelle zu scannen. Wenn Sie jedoch bereitgestellte Knoten für das Computing verwenden, ist das der Fall. Ähnlich wie beim direkten Senden von Leseanfragen an Ihre Bigtable-Tabelle sollten Sie bei der Abfrage der externen Tabelle nach der Tabelle und wenn Sie Data Boost nicht verwenden, im Allgemeinen vollständige Tabellenscans vermeiden. Vollständige Tabellenscans erhöhen die CPU-Auslastung und dauern wesentlich länger als selektive Abfragen. Außerdem ist mehr BigQuery-Durchsatz erforderlich.

Wenn Ihre Abfrage alle Zeilen umfasst, wird ein vollständiger Tabellenscan ausgelöst. Wenn Sie die Abfrage jedoch einschränken und einen Bereich von Zeilen oder bestimmte nicht zusammenhängende Zeilen anfordern, wird nicht die gesamte Tabelle gescannt. Hier einige Beispiele in der GoogleSQL-Syntax, wie Sie die Abfrage einschränken können:

WHERE rowkey = "abc123"
WHERE rowkey BETWEEN "abc123" PRECEDING AND "abc999" FOLLOWING
WHERE rowkey > 999999 (wenn Sie den Zeilenschlüssel als String lesen)

Joins

Wenn Sie einen Join verwenden möchten, um Ihre Bigtable-Tabellendaten in Verbindung mit Daten aus einer anderen Quelle zu analysieren, sollten Sie eine Unterabfrage erstellen, mit der die relevanten Felder aus Bigtable für den geplanten Join extrahiert werden. Weitere Best Practices zum Verknüpfen von Tabellen finden Sie unter Abfrageberechnung optimieren.

Kosten

Wenn Sie eine externe Tabelle erstellen und abfragen, werden Ihnen BigQuery-Kosten und eine Erhöhung der Anzahl der Bigtable-Knoten in Rechnung gestellt, die zur Verarbeitung des Traffics erforderlich sind. Da sich Ihre externe Tabelle in derselben Region wie Ihre Bigtable-Tabelle befindet, fallen keine Netzwerkkosten an.

Wenn Sie Ihre Abfragen in der Regel während der regulären Geschäftszeiten ausführen, sollten Sie das Bigtable-Autoscaling aktivieren. So wird die Anzahl der Knoten bei Bedarf erhöht und nach Abschluss der Jobs wieder verringert. Autoscaling ist auch eine effektive Taktik, wenn Sie geplante Abfragen ohne feste Fristen ausführen.

Eine weitere Möglichkeit, die Kosten zu begrenzen, besteht darin, einen Scan der gesamten Tabelle zu vermeiden.

Weitere Informationen zur Kostenoptimierung für BigQuery finden Sie unter Kosten schätzen und kontrollieren.

Beschränkungen

Es gilt die folgende Einschränkung:

Abfrageergebnisse mit serialisierten Daten, die verschachtelte Typen wie Protokollpuffer (Protobufs) und Avro-Formate enthalten, werden in der Google Cloud -Konsole möglicherweise falsch gerendert oder sind schwer zu lesen.