Einführung in BigQuery Omni

Mit BigQuery Omni können Sie BigQuery-Analysen für Daten ausführen, die in Amazon Simple Storage Service (Amazon S3) oder Azure Blob Storage mithilfe von BigLake-Tabellen gespeichert sind.

Viele Organisationen speichern Daten in mehreren öffentlichen Clouds. Oft sind diese Daten isoliert gespeichert, da es schwierig ist, Erkenntnisse über alle Daten zu gewinnen. Sie möchten die Daten mit einem Multi-Cloud-Datentool analysieren können, das kostengünstig und schnell ist und keinen zusätzlichen Overhead für die dezentralisierte Data Governance verursacht. Durch die Verwendung von BigQuery Omni lassen sich diese Probleme mit einer einheitlichen Schnittstelle reduzieren.

Wenn Sie BigQuery-Analysen für Ihre externen Daten ausführen möchten, müssen Sie zuerst eine Verbindung zu Amazon S3 oder Blob Storage herstellen. Wenn Sie externe Daten abfragen möchten, müssen Sie eine BigLake-Tabelle erstellen, die auf Amazon S3- oder Blob Storage-Daten verweist.

Sie können Daten auch zwischen Clouds verschieben, um Daten aus mehreren Clouds mit cloudübergreifender Übertragung zu kombinieren, oder Daten über mehrere Clouds hinweg mit cloudübergreifenden Joins abfragen. BigQuery Omni bietet eine cloudübergreifende Analyselösung mit der Möglichkeit, Daten dort zu analysieren, wo sie sind, und die Daten bei Bedarf flexibel zu replizieren. Weitere Informationen finden Sie unter Daten mit cloudübergreifender Übertragung laden und Cloudübergreifende Joins.

Architektur

Bei der Architektur von BigQuery ist die Trennung von Computing und Speicher möglich. Somit kann BigQuery nach Bedarf für die Verarbeitung sehr großer Arbeitslasten horizontal skalieren. BigQuery Omni erweitert diese Architektur durch Ausführung der BigQuery-Abfrage-Engine in anderen Clouds. Daher müssen Sie Daten nicht physisch in den BigQuery-Speicher verschieben. Die Verarbeitung findet dann statt, wenn die Daten bereits vorhanden sind.

BigQuery Omni-Architektur

Abfrageergebnisse können über eine sichere Verbindung an Google Cloud zurückgegeben werden, z. B. um in der Google Cloud Console angezeigt zu werden. Alternativ können Sie die Ergebnisse direkt in Amazon S3-Buckets oder Blob Storage schreiben. In diesem Fall gibt es keine cloudübergreifende Verschiebung der Abfrageergebnisse.

BigQuery Omni verwendet die AWS IAM-Standardrollen oder Azure Active Directory-Hauptkonten, um auf die Daten in Ihrem Abo zuzugreifen. Sie delegieren den Lese- oder Schreibzugriff auf BigQuery Omni und können die Zugriffsrechte jederzeit widerrufen.

Datenfluss beim Abfragen von Daten

In der folgenden Abbildung wird gezeigt, wie die Daten für die folgenden Abfragen zwischen Google Cloud und AWS oder Azure verschoben werden:

  • SELECT-Anweisung
  • CREATE EXTERNAL TABLE-Anweisung
Datenverschiebung zwischen Google Cloud und AWS oder Azure für Abfragen.
Abbildung 1: Datenverschiebung zwischen Google Cloud und AWS oder Azure für Abfragen.
  1. Die BigQuery-Steuerungsebene empfängt Abfragejobs über die Google Cloud Console, das bq-Befehlszeilentool, eine API-Methode oder eine Clientbibliothek.
  2. BigQuery-Steuerungsebene sendet Abfragejobs zur Verarbeitung an die BigQuery-Datenebene in AWS oder Azure.
  3. Die BigQuery-Datenebene empfängt Abfragen über eine VPN-Verbindung von der Steuerungsebene.
  4. Die BigQuery-Datenebene liest Tabellendaten aus Ihrem Amazon S3-Bucket oder Blob-Speicher.
  5. Die BigQuery-Datenebene führt den Abfragejob für Tabellendaten aus. Die Tabellendaten werden in der angegebenen AWS- oder Azure-Region verarbeitet.
  6. Das Abfrageergebnis wird von der Datenebene über die VPN-Verbindung an die Steuerungsebene übertragen.
  7. Die BigQuery-Steuerungsebene empfängt die Abfrageergebnisse für die Anzeige in Form eines Abfragejobs. Diese Daten werden bis zu 24 Stunden gespeichert.
  8. Das Abfrageergebnis wird an Sie zurückgegeben.

Weitere Informationen finden Sie unter Amazon S3-Daten abfragen und Blob-Speicherdaten.

Datenfluss beim Exportieren von Daten

In der folgenden Abbildung wird beschrieben, wie Daten während einer EXPORT DATA-Anweisung zwischen Google Cloud und AWS oder Azure verschoben werden.

Datenverschiebung zwischen Google Cloud und AWS oder Azure für Exportabfragen.
Abbildung 2: Datenverschiebung zwischen Google Cloud und AWS oder Azure für Exportabfragen.
  1. Die BigQuery-Steuerungsebene empfängt Exportabfragejobs von Ihnen über die Google Cloud Console, das bq-Befehlszeilentool, eine API-Methode oder eine Clientbibliothek. Die Abfrage enthält den Zielpfad für das Abfrageergebnis in Ihrem Amazon S3-Bucket oder Blob Storage.
  2. BigQuery-Steuerungsebene sendet Exportabfragejobs zur Verarbeitung an die BigQuery-Datenebene in AWS oder Azure.
  3. Die BigQuery-Datenebene empfängt die Exportabfragen über eine VPN-Verbindung von der Steuerungsebene
  4. Die BigQuery-Datenebene liest Tabellendaten aus Ihrem Amazon S3-Bucket oder Blob-Speicher.
  5. Die BigQuery-Datenebene führt den Abfragejob für Tabellendaten aus. Die Tabellendaten werden in der festgelegten AWS- oder Azure-Region verarbeitet.
  6. BigQuery schreibt das Abfrageergebnis in den angegebenen Zielpfad in Ihrem Amazon S3-Bucket oder in Blob Storage.

Weitere Informationen finden Sie unter Abfrageergebnisse nach Amazon S3 und Blob Storage exportieren.

Vorteile

Leistung. Sie erhalten schneller Einblicke, da die Daten nicht in andere Clouds kopiert werden und die Abfragen in derselben Region ausgeführt werden, in der sich Ihre Daten befinden.

Kosten. Sie sparen Kosten für ausgehende Datenübertragungen, da die Daten nicht verschoben werden. Für Ihr AWS- oder Azure-Konto im Zusammenhang mit BigQuery Omni-Analysen fallen keine zusätzlichen Gebühren an, da die Abfragen auf von Google verwalteten Clustern ausgeführt werden. Sie bezahlen nur für das Abfragen des BigQuery-Preismodells.

Sicherheit und Data Governance: Sie verwalten die Daten in Ihrem eigenen AWS- oder Azure-Abo. Sie müssen die Rohdaten nicht aus Ihrer öffentlichen Cloud verschieben oder kopieren. Die gesamte Berechnung erfolgt im BigQuery-Dienst mit mehreren Mandanten, der in derselben Region wie Ihre Daten ausgeführt wird.

Serverlose Architektur. Wie der Rest von BigQuery ist auch BigQuery Omni ein serverloses Angebot. Google stellt die Cluster bereit, die BigQuery Omni ausführen, und verwaltet diese. Sie müssen keine Ressourcen bereitstellen oder Cluster verwalten.

Einfache Verwaltung. BigQuery Omni bietet über Google Cloud eine einheitliche Verwaltungsoberfläche. BigQuery Omni kann Ihr vorhandenes Google Cloud-Konto und Ihre BigQuery-Projekte verwenden. Sie können eine GoogleSQL-Abfrage in der Google Cloud Console schreiben, um Daten in AWS oder Azure abzufragen und die Ergebnisse in der Google Cloud Console anzeigen zu lassen.

Cloudübergreifende Übertragung. Sie können Daten aus S3-Buckets und Blob-Speicher in Standard-BigQuery-Tabellen laden. Weitere Informationen finden Sie unter Amazon S3-Daten und Blob-Speicherdaten an BigQuery übertragen.

Metadaten-Caching für bessere Leistung

Sie können im Cache gespeicherte Metadaten verwenden, um die Abfrageleistung für BigLake-Tabellen zu verbessern, die auf Amazon S3-Daten verweisen. Dies ist besonders hilfreich, wenn Sie mit einer großen Anzahl von Dateien arbeiten oder die Daten mit Hive partitioniert sind.

BigLake- und Objekttabellen unterstützen das Caching von Metadaten zu Dateien aus externen Datenquellen wie Cloud Storage und Amazon Simple Storage Service (Amazon S3). Die Metadaten enthalten Dateinamen, Partitionierungsinformationen und physische Metadaten aus Dateien wie der Zeilenanzahl. Sie können auswählen, ob das Caching von Metadaten für eine Tabelle aktiviert werden soll. Abfragen mit einer großen Anzahl von Dateien und mit Hive-Partitionsfiltern profitieren am meisten vom Metadaten-Caching.

Wenn Sie das Metadaten-Caching nicht aktivieren, müssen Abfragen in der Tabelle die externe Datenquelle lesen, um Objektmetadaten abzurufen, wodurch die Abfragelatenz erhöht wird. Das Auflisten von Millionen von Dateien aus der externen Datenquelle kann einige Minuten dauern. Wenn Sie das Metadaten-Caching aktivieren, können Abfragen die Auflistung von Dateien aus der externen Datenquelle vermeiden und eine schnellere Partitionierung und Dateibereinigung erreichen.

Es gibt zwei Attribute, die diese Funktion steuern:

  • Maximale Veralterung, die steuert, wann Abfragen im Cache gespeicherte Metadaten verwenden.
  • Metadaten-Cache-Modus, der steuert, wie die Metadaten erfasst werden.

Wenn Sie das Caching von Metadaten aktiviert haben, geben Sie auch das maximale Intervall der Metadatenveralterung an, das für Vorgänge in Bezug auf die Tabelle akzeptabel ist. Wenn Sie beispielsweise ein Intervall von 1 Stunde angeben, verwenden die Vorgänge für die Tabelle im Cache gespeicherte Metadaten, wenn sie innerhalb der letzten Stunde aktualisiert wurden. Sind die im Cache gespeicherten Metadaten älter, werden für den Vorgang stattdessen Metadaten aus Cloud Storage abgerufen. Sie können ein Veralterungsintervall auf einen Wert zwischen 30 Minuten und 7 Tagen festlegen.

Sie können den Cache entweder automatisch oder manuell aktualisieren:

  • Bei automatischen Aktualisierungen wird der Cache in einem systemdefinierten Intervall aktualisiert, in der Regel zwischen 30 und 60 Minuten. Das automatische Aktualisieren des Caches ist ein guter Ansatz, wenn die Dateien in der externen Datenquelle in zufälligen Intervallen hinzugefügt, gelöscht oder geändert werden. Wenn Sie den Zeitpunkt der Aktualisierung steuern müssen, z. B. um die Aktualisierung am Ende eines Extract-Transform-Ladejobs auszulösen, verwenden Sie die manuelle Aktualisierung.

  • Bei manuellen Aktualisierungen führen Sie das Systemverfahren BQ.REFRESH_EXTERNAL_METADATA_CACHE aus, um den Metadaten-Cache nach einem Zeitplan zu aktualisieren, der Ihren Anforderungen entspricht. Das manuelle Aktualisieren des Caches ist ein guter Ansatz, wenn die Objekte in Cloud Storage in bekannten Intervallen hinzugefügt, gelöscht oder geändert werden, z. B. als Ausgabe einer Pipeline.

    Wenn Sie mehrere manuelle Aktualisierungen gleichzeitig ausführen, ist nur eine erfolgreich.

Der Metadaten-Cache läuft nach 7 Tagen ab, wenn er nicht aktualisiert wird.

Sie sollten berücksichtigen, wie die Werte für Veralterung und Metadaten-Caching-Modus interagieren, bevor Sie sie festlegen. Betrachten Sie hierzu folgende Beispiele:

  • Wenn Sie den Metadaten-Cache für eine Tabelle manuell aktualisieren und das Veralterungsintervall auf 2 Tage festlegen, müssen Sie das Systemverfahren BQ.REFRESH_EXTERNAL_METADATA_CACHE alle 2 Tage oder weniger ausführen, wenn Sie Vorgänge wünschen. um die im Cache gespeicherten Metadaten zu verwenden.
  • Wenn Sie den Metadaten-Cache für eine Tabelle automatisch aktualisieren und das Veralterungsintervall auf 30 Minuten festlegen, ist es möglich, dass einige Vorgänge für die Tabelle aus Cloud Storage gelesen werden, wenn die Metadaten-Cache-Aktualisierung länger als die üblichen 30 bis 60 Minuten dauert.

Fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS ab, um Informationen zu Aktualisierungsjobs für Metadaten zu erhalten, wie im folgenden Beispiel gezeigt:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Weitere Informationen finden Sie unter Caching von Metadaten.

Cache-fähige Tabellen mit materialisierten Ansichten

Sie können materialisierte Ansichten über metadaten-cache-fähigen Amazon Simple Storage Service (Amazon S3)-Tabellen verwenden, um die Leistung und Effizienz beim Abfragen strukturierter Daten zu verbessern, die in Amazon S3 gespeichert sind. Diese materialisierten Ansichten funktionieren wie materialisierte Ansichten über von BigQuery verwalteten Speichertabellen, einschließlich der Vorteile einer automatischen Aktualisierung und intelligenten Abstimmung.

Wenn Sie Amazon S3-Daten in einer materialisierten Ansicht in einer unterstützten BigQuery-Region für Joins bereitstellen wollen, erstellen Sie ein Replikat der materialisierten Ansicht . Sie können Replikate der materialisierten Ansicht nur über autorisierte materialisierte Ansichten erstellen.

Beschränkungen

Zusätzlich zu den Einschränkungen für BigLake-Tabellen gelten für BigQuery Omni die folgenden Einschränkungen, die auf BigLake-Tabellen basieren, die auf Amazon S3- und Blob Storage-Daten basieren:

  • Die Arbeit mit Daten in einer der BigQuery Omni-Regionen wird von den Versionen Standard und Enterprise Plus nicht unterstützt. Weitere Informationen zu Editionen finden Sie unter Einführung in BigQuery-Editionen.
  • Die Ansichten OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, und PARTITIONS INFORMATION_SCHEMA sind für BigLake-Tabellen, die auf Amazon S3- und Blob Storage-Daten basieren, nicht verfügbar.
  • Materialisierte Ansichten werden für Blob Storage nicht unterstützt.
  • JavaScript-UDFs werden nicht unterstützt.

  • Die folgenden SQL-Anweisungen werden nicht unterstützt:

  • Für das Abfragen und Lesen von temporären Zieltabellen gelten folgende Einschränkungen (Vorschau):

    • Das Abfragen von temporären Tabellen mit der SELECT-Anweisung wird nicht unterstützt.
    • Die BigQuery Storage Read API zum Lesen von Daten aus temporären Zieltabellen wird nicht unterstützt.
    • Wenn Sie den ODBC-Treiber verwenden, werden Lesevorgänge mit hohem Durchsatz (Option EnableHTAPI) nicht unterstützt.

  • Geplante Abfragen werden nur über die API- oder die Befehlszeilenmethode unterstützt. Die Option Zieltabelle ist für Abfragen deaktiviert. Nur EXPORT DATA-Abfragen sind zulässig.

  • BigQuery Storage API ist in BigQuery Omni-Regionen nicht verfügbar.

  • Wenn die Abfrage die ORDER BY-Klausel verwendet und eine Ergebnisgröße von mehr als 256 MB hat, schlägt die Abfrage fehl. Zur Behebung dieses Problems reduzieren Sie entweder die Ergebnisgröße oder entfernen die ORDER BY-Klausel aus der Abfrage. Weitere Informationen zu BigQuery Omni-Kontingenten finden Sie unter Kontingente und Limits.

  • Die Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) mit Datasets und externen Tabellen wird nicht unterstützt.

Preise

Informationen zu Preisen und zeitlich begrenzten Angeboten in BigQuery Omni finden Sie unter BigQuery Omni-Preise.

Kontingente und Limits

Informationen zu BigQuery Omni-Kontingenten finden Sie unter Kontingente und Limits.

Wenn das Abfrageergebnis größer als 20 GiB ist, sollten Sie die Ergebnisse nach Amazon S3 oder Blob Storage exportieren. Weitere Informationen zu Kontingenten für die BigQuery Connection API finden Sie unter BigQuery Connection API.

Standorte

BigQuery Omni verarbeitet Abfragen am selben Standort wie das Dataset, das die Tabellen enthält, die Sie abfragen. Nachdem Sie das Dataset erstellt haben, kann der Standort nicht mehr geändert werden. Ihre Daten befinden sich in Ihrem AWS- oder Azure-Konto. BigQuery Omni-Regionen unterstützen Reservierungen in der Enterprise-Version und Preise für On-Demand-Computing (Analysen). Weitere Informationen zu Editionen finden Sie unter Einführung in BigQuery-Editionen.
Beschreibung der Region Name der Region Gemeinsame BigQuery-Region
AWS
AWS – US East (N. Virginia) aws-us-east-1 us-east4
AWS – US West (Oregon) aws-us-west-2 us-west1
AWS – Asiatisch-pazifischer Raum (Seoul) aws-ap-northeast-2 asia-northeast3
AWS - Europa (Irland) aws-eu-west-1 europe-west1
Azure
Azure – East US 2 azure-eastus2 us-east4

Nächste Schritte