AlloyDB-Zugriff auf Echtzeitdaten in BigQuery – Übersicht

Wenn Sie Echtzeitabfragen von Analysedaten zusammen mit Ihren Betriebsdaten ausführen möchten, ohne komplexe Pipelines erstellen zu müssen, können Sie die Lakehouse-Föderation in AlloyDB for PostgreSQL verwenden. Mit der Erweiterung bigquery_fdw leitet AlloyDB Ihre Abfragen an BigQuery weiter, um über externe BigLake-Tabellen auf Live-Daten und offene Formate wie Apache Iceberg zuzugreifen. So sind keine komplexen ETL-Migrationen (Extrahieren, Transformieren, Laden) erforderlich.

Vorteile der Lakehouse-Föderation

Der Ansatz der Lakehouse-Föderation bietet die folgenden Vorteile:

  • Zero-ETL: Sie können Analysedaten direkt abfragen, ohne komplexe Pipelines erstellen oder verwalten zu müssen.
  • Vertraute Syntax: Sie können BigQuery-Daten mit der Standard-PostgreSQL-Syntax abfragen.
  • Echtzeit-Einblicke: Sie können auf aktuelle Daten neben Ihren Betriebstabellen zugreifen.
  • Auslagerung von Rechenleistung: Sie können die verteilte BigQuery-Engine für rechenintensive Aufgaben durch Push-down-Optimierung verwenden.
  • Autorisierter Zugriff: Um sicherzustellen, dass nur autorisierte Dienstkonten externe Daten abfragen können, verwenden Sie Identity and Access Management (IAM) für die zentrale Zugriffssteuerung.

Anwendungsfälle

Die Lakehouse-Föderation unterstützt die folgenden geschäftlichen und technischen Anwendungsfälle:

  • Hybride transaktionsorientierte und analytische Verarbeitung (HTAP): Sie können gleichzeitig Echtzeit-Betriebsdaten in AlloyDB und Verlaufs- oder Analysedaten in BigQuery oder Cloud Storage abfragen, ohne die transaktionsorientierte Leistung zu beeinträchtigen.
  • Echtzeit-Einblicke ohne anfällige Pipelines: Sie können die Latenz und die Fehlerarten herkömmlicher ETL-Prozesse vermeiden. Sie können sofort auf aktuelle Analysedaten zugreifen, um Geschäftsentscheidungen auf Grundlage der neuesten Informationen zu treffen.
  • Datenmaterialisierung für agentenbasierte Workflows: Sie können externe Analysedaten in AlloyDB materialisieren, um die spaltenbasierte Engine von AlloyDB und die KI-Funktionen von AlloyDB zu nutzen. So lassen sich leistungsstarke Vektorsuchen, Machine-Learning-Einbettungen und erweiterte KI-gestützte agentenbasierte Workflows für Ihre föderierten Daten ermöglichen.

Architektur und Datenfluss

Das folgende Diagramm zeigt den Datenfluss und die Komponenteninteraktionen bei Verwendung der Lakehouse-Föderation:

Diagramm mit der Architektur der Lakehouse-Föderation, das den Fluss zwischen AlloyDB und BigQuery mit Pushdown-Optimierung darstellt.
Abbildung 1. Architektur und Datenfluss für die Lakehouse-Föderation

Im Folgenden wird der Datenflussprozess für die Lakehouse-Föderation in AlloyDB beschrieben:

  1. Abfrageeinreichung: Sie senden eine Standard-PostgreSQL-Abfrage an Ihre AlloyDB-Instanz.
  2. Abfrageplanung und -optimierung: Der AlloyDB-Abfrageplaner identifiziert Tabellen, die mit dem BigQuery Foreign Data Wrapper (FDW) externen BigQuery-Datasets zugeordnet sind.
  3. Push-down-Optimierung: AlloyDB optimiert die Abfrage, indem bestimmte Filter und Aggregationen direkt an BigQuery weitergeleitet werden. So werden nur die relevanten, gefilterten Zeilen oder vorab aggregierten Zusammenfassungen über das Netzwerk übertragen.
  4. Ausführung und Abruf: BigQuery führt seinen Teil der Abfrage aus. Dabei werden entweder der integrierte BigQuery-Speicher direkt gescannt oder in Cloud Storage gespeicherte Apache Iceberg-Tabellen gelesen. Das resultierende Dataset wird dann an AlloyDB zurückgestreamt.
  5. Endgültige Verarbeitung und Antwort: AlloyDB kombiniert die externen Daten mit allen lokalen Betriebstabellen, führt die verbleibende Abfrageverarbeitung aus und gibt das Endergebnis an Ihre Anwendung zurück.

Überlegungen zu Datentypen für föderierte Abfragen

Wenn Sie eine externe BigQuery-Tabelle aus AlloyDB mit der Lakehouse-Föderation abfragen, interpretiert der AlloyDB-Abfrageplaner die BigQuery-Datentypen als entsprechende PostgreSQL-Datentypen. Diese Zuordnungen sind wichtig, um korrekte Abfragen zu schreiben und für die Definitionen externer Tabellen, die von der Erweiterung bigquery_fdw verwendet werden.

Wenn ein BigQuery-Datentyp keine direkte Zuordnung hat oder eine spezielle Verarbeitung erfordert, müssen Sie möglicherweise explizite CAST-Funktionen in Ihren Abfragen verwenden oder eine Ansicht in BigQuery erstellen, die die Daten mit kompatiblen Typen präsentiert.

Eine Liste der unterstützten Datentypen und der entsprechenden PostgreSQL-Typen finden Sie unter Zuordnungen von Datentypen.

Sicherheit und Zugriffssteuerung

Der Zugriff auf BigQuery-Daten aus AlloyDB wird über IAM verwaltet. Sie müssen dem AlloyDB-Clusterdienstkonto bestimmte IAM-Rollen zuweisen, um festzulegen, welche Datasets und Tabellen abgefragt werden können. So wird sichergestellt, dass föderierte Abfragen den zentralen Richtlinien zur Data Governance Ihrer Organisation entsprechen, ohne die Sicherheit zu beeinträchtigen. Weitere Informationen finden Sie unter Erforderliche Rollen.

Push-down

Sie können Filter- und Aggregations-Push-down-Techniken verwenden, um Abfragen zu beschleunigen und Kosten zu senken, indem Sie Daten in BigQuery filtern oder zusammenfassen, bevor sie von AlloyDB verschoben oder verarbeitet werden. Dieser Ansatz minimiert den Netzwerkverkehr und die Arbeitsspeichernutzung. So können Sie große Datasets schnell und effizient analysieren, ohne die Ressourcengrenzwerte zu überschreiten.

Filter-Push-down

Filter-Push-down, auch Prädikat-Push-down genannt, ist eine Optimierungstechnik , bei der das Filtern von Daten so nah wie möglich an die Speicherebene verlagert wird. Dazu werden Ihre Abfragefilter (mit der WHERE Klausel) von AlloyDB an BigQuery weitergeleitet.

Mit dem Filter-Push-down können Sie SQL-Abfragen mit einer WHERE-Klausel verwenden, um auf eine Teilmenge von Daten aus der Remotetabelle zuzugreifen. Diese Daten können auch in einer lokalen Tabelle materialisiert oder als lokale Partition an eine PostgreSQL-Tabelle angehängt werden.

Unterstützte Vorgänge für den Filter-Push-down sind:

  • Standardvergleichsoperatoren: =, <, >, <=, >=, <>
  • Logische Operatoren: AND, OR und NOT
  • Musterabgleich: LIKE und NOT LIKE
  • Null-Prüfungen: IS NULL und IS NOT NULL
  • In-List-Auswertung: IN und NOT IN

Aggregations-Push-down

Aggregations-Push-down ist eine erweiterte Datenbankoptimierung, bei der Berechnungen wie SUM, COUNT, AVG oder GROUP BY so nah wie möglich an der Speicherebene ausgeführt werden. Bei diesem Push-down werden Zusammenfassungsfunktionen direkt in BigQuery ausgewertet, wodurch die Anzahl der an AlloyDB zurückgegebenen Zeilen erheblich reduziert werden kann.

Unterstützte Vorgänge für den Aggregations-Push-down sind:

  • SUM
  • COUNT
  • AVG
  • MIN
  • MAX

Limit-Push-down

Limit-Push-down (einschließlich OFFSET-Push-down) ist eine Optimierungstechnik, bei der die Klauseln LIMIT und OFFSET Ihrer Abfrage von AlloyDB an BigQuery weitergeleitet werden.

So kann BigQuery nur die angeforderte Teilmenge von Zeilen zurückgeben, was den Netzwerkverkehr und die Abfragelatenz erheblich reduziert.

Der Limit-Push-down wird nach Möglichkeit automatisch angewendet. Achten Sie darauf, dass die folgenden Bedingungen erfüllt sind:

  • Die Abfrage verwendet nicht die Option WITH TIES in der Anweisung FETCH FIRST.
  • Die Ausdrücke LIMIT und OFFSET sind einfache Konstanten oder Ausdrücke, die remote ausgewertet werden können.

BigQuery-Kosten und -Abrechnung

Der BigQuery Foreign Data Wrapper hängt von Folgendem ab:

  • BigQuery-Preise für Computing
  • BigQuery Storage API – Preise

Weitere Informationen finden Sie unter BigQuery-Preise.

Laufzeitprojekte

In BigQuery können Sie Ihre Daten in einem Projekt speichern und Ihre Abfragen in einem anderen Projekt ausführen. Das Projekt, in dem die Abfragen ausgeführt werden und die Rechenkosten anfallen, wird als Laufzeitprojekt (oder Abrechnungsprojekt) bezeichnet.

Wenn Sie Ihr Laufzeitprojekt von Ihrem Datenspeicherprojekt trennen, können Sie die Rechenkosten bestimmten Kostenstellen zuordnen, Kontingente unabhängig verwalten und Ausgaben für verschiedene Arbeitslasten steuern, ohne die zugrunde liegenden Daten zu verschieben.

Wenn Sie AlloyDB für den Zugriff auf BigQuery-Daten konfigurieren, können Sie ein Laufzeitprojekt auf Serverebene (für alle zugehörigen externen Tabellen) oder auf der Ebene der einzelnen Tabellen angeben. Wenn Sie kein Laufzeitprojekt angeben, verwendet AlloyDB standardmäßig das Projekt, in dem sich die Daten befinden.

Beschränkungen

  • AlloyDB und BigQuery verwenden möglicherweise unterschiedliche Standardsortierungen, was zu unterschiedlichen Ergebnissen bei der Datensortierung oder beim Stringvergleich zwischen den beiden Systemen führen kann. Beispielsweise kann die Standard-PostgreSQL-Sortierung in den Versionen 15, 16 und 17 die Groß- und Kleinschreibung bei der Sortierung anders behandeln als die Standard-Sortierung von BigQuery, bei der Strings streng nach ihren Unicode-Codepoints ausgewertet werden.

    Für jeden Teil einer Abfrage, der remote in BigQuery ausgeführt wird, gelten die Sortierungseinstellungen von BigQuery. Um Sortierungskonflikte zu reduzieren, sollten Sie in AlloyDB die Sortierung C.UTF-8 ohne ICU und in BigQuery die Standardsortierung (leer) verwenden.

  • Abfragen, die nach dem Push-downeine große Datenmenge aus BigQuery zurückgeben, werden nicht optimiert.

  • Wenn Sie eine externe Tabelle erstellen, prüft AlloyDB nicht aktiv, ob die externe BigQuery-Tabelle vorhanden ist oder welches Schema sie hat.

  • Wenn für eine föderierte Abfrage eine große Datenmenge gelesen werden muss, z. B. wenn Filter-Push-downs nicht angewendet werden können, kann die Abfrage aufgrund der Größenbeschränkungen für BigQuery API-Antworten fehlschlagen. Die maximalen Größenbeschränkungen für BigQuery-Antworten gelten weiterhin. Weitere Informationen zu diesen Beschränkungen finden Sie unter Kontingente und Limits.

  • PostgreSQL unterstützt eine höhere Genauigkeit für Zwischenberechnungen, während BigQuery die Dezimalgenauigkeit streng kontrolliert. Dieser Unterschied kann bei komplexen Berechnungen zu Genauigkeitsverlusten oder Überlauffehlern führen. Weitere Informationen finden Sie unter Dezimaltypen.

  • Database Migration Service unterstützt die Migration externer Tabellen, die mit der Erweiterung bigquery_fdw erstellt wurden, nicht. Als Problemumgehung können Sie die externen Tabellen entweder aus Ihrem Migrationsjob ausschließen oder sie vor Beginn der Migration löschen und dann nach Abschluss der Migration im Ziel-AlloyDB-Cluster neu erstellen.

  • Wenn Sie externe Tabellen mit der Erweiterung bigquery_fdw abfragen, wertet BigQuery die Berechtigungen für den Datenzugriff anhand des AlloyDB-Cluster-Dienstkontos aus. Auch wenn sich Datenbanknutzer mit der IAM-Datenbankauthentifizierung anmelden, werden ihre individuellen IAM-Nutzerberechtigungen nicht für die externen BigQuery-Tabellen geprüft. Weitere Informationen finden Sie unter AlloyDB-Zugriff auf das BigQuery-Dataset gewähren.

Nächste Schritte