In diesem Artikel wird eine Architektur zur Optimierung der Aufnahme umfangreicher Analyseereignisse in Google Cloud beschrieben. In diesem Artikel bedeutet umfangreich mehr als 100.000 Ereignisse pro Sekunde oder eine kumulierte Ereignisnutzlastgröße von über 100 MB pro Sekunde.
Sie können die flexiblen und skalierbaren verwalteten Dienste von Google Cloud verwenden, um große Mengen eingehender Log- und Analyseereignisse zu erfassen und anschließend für die Eingabe in ein Data Warehouse wie BigQuery aufzubereiten.
Jede Architektur zur Aufnahme von großen Datenmengen muss berücksichtigen, auf welche Daten nahezu in Echtzeit zugegriffen werden muss und welche Daten mit einer kurzen Verzögerung verarbeitet werden können. Diese müssen dann entsprechend aufgeteilt werden. Vorteile einer segmentierten Lösung:
- Log-Integrität. Sie können vollständige Logs anzeigen. Es gehen keine Logs wegen Grenzwerten der Streaming-Quoten oder wegen Samplings verloren.
- Kostenreduzierung. Streaming-Insert-Anweisungen von Ereignissen und Logs werden mit einer höheren Rate abgerechnet als Ereignisse und Logs, die mit Batchjobs aus Cloud Storage eingefügt werden.
- Reservierte Abfrageressourcen. Wenn Logs mit niedrigerer Priorität in das Batch-Ladeverfahren verschoben werden, haben diese keine Auswirkung auf reservierte Abfrageressourcen.
Im folgenden Architekturdiagramm ist ein derartiges System dargestellt. Außerdem werden darin die Konzepte von Hot Path und Cold Path für die Aufnahme vorgestellt:
Architekturübersicht
In dieser Architektur stammen Daten aus zwei möglichen Quellen:
- Logs werden mit Cloud Logging erfasst.
- Analyseereignisse werden in einem Pub/Sub-Thema veröffentlicht.
Nach Aufnahme aus einer der Quellen werden die Daten je nach den Latenzanforderungen der Nachricht in den Hot Path oder Cold Path gestellt. Der Hot Path verwendet die Streaming-Eingabe, die einen kontinuierlichen Datenfluss verarbeiten kann, während der Cold Path die Batch-Verarbeitung ermöglicht und Daten nach einem von Ihnen bestimmten Plan geladen werden.
Logging-Ereignisse
Mit Cloud Logging können Sie Logging-Ereignisse aufnehmen, die von Standard-Logging-Funktionen des Betriebssystems generiert werden. Cloud Logging ist standardmäßig in einer Reihe von Compute Engine-Umgebungen enthalten, einschließlich der Standard-Images, und kann mit dem Cloud Logging-Agent unter vielen Betriebssystemen installiert werden. Der Logging-Agent ist die Standard-Logging-Senke für App Engine und Google Kubernetes Engine.
Hot Path
Im Hot Path werden kritische Logs, die für das Monitoring und die Analyse Ihrer Dienste erforderlich sind, durch die Angabe eines Filters in der Cloud Logging-Senke ausgewählt und dann in mehrere BigQuery-Tabellen gestreamt. Wenn höhere Volumen erwartet werden, verwenden Sie separate Tabellen für die Logging-Ebenen ERROR und WARN und teilen diese dann weiter je nach Dienst auf. Diese bewährte Vorgehensweise hält die Anzahl von Aufnahmen pro Sekunde pro Tabelle unter dem Grenzwert von 100.000 und sorgt dafür, dass Abfragen für diese Daten ordnungsgemäß verarbeitet werden.
Cold Path
Für den Cold Path werden Logs, die keine Analyse nahezu in Echtzeit erfordern, mit einer Cloud Logging-Senke ausgewählt, die auf einen Cloud Storage-Bucket verweist. Logs werden in Batches zusammengefasst und in stündlichen Batches von Cloud Storage in Logdateien geschrieben. Mit dem Standardprozess zum Dateiimport von Cloud Storage, der sich über die Google Cloud Console, die Befehlszeile oder ein einfaches Skript initiieren lässt, können diese Logs dann im Batchverfahren in BigQuery geladen werden. Das Batchladeverfahren wirkt sich weder auf die Streaming-Aufnahme des Hot Path noch auf die Abfrageleistung aus. In den meisten Fällen wird empfohlen, die Cold-Path-Logs direkt in dieselben Tabellen einzufügen, die die Hot-Path-Logs verwenden, um Problembehebung und Berichtsgenerierung zu vereinfachen.
Analyseereignisse
Analyseereignisse können von den Diensten Ihrer App in Google Cloud generiert oder von Remote-Clients gesendet werden. Die Aufnahme dieser Analyseereignisse über Pub/Sub und deren anschließende Verarbeitung in Dataflow führt zu einem System mit hohem Durchsatz und niedriger Latenz. Auch wenn die Hot- und Cold-Analyseereignisse an zwei separate Pub/Sub-Themen gesendet werden können, sollten Sie alle Ereignisse an ein einziges Thema senden und sie dann mit separaten Dataflow-Jobs über Hot Path und Cold Path verarbeiten. Auf diese Weise können Sie den Pfad eines Analyseereignisses ändern, indem Sie die Dataflow-Jobs aktualisieren. Dies ist einfacher als die Bereitstellung einer neuen App- oder Clientversion.
Hot Path
Einige Ereignisse erfordern eine sofortige Analyse. Beispielsweise kann ein Ereignis auf ein unerwünschtes Clientverhalten oder falsche Nutzer hinweisen. Sie sollten solche Ereignisse mit einem Dataflow-Autoscaling-Job einzeln in Pub/Sub auswählen und dann direkt an BigQuery senden. Diese Daten können von dem Dataflow-Job partitioniert werden, um sicherzustellen, dass der Grenzwert von 100.000 Zeilen pro Sekunde pro Tabelle nicht erreicht wird. Dadurch bleibt auch die einwandfreie Ausführung von Abfragen gewährleistet.
Cold Path
Ereignisse, die nicht sofort, sondern stündlich oder täglich verfolgt oder analysiert werden müssen, können von Dataflow an Objekte in Cloud Storage übertragen werden. Ladevorgänge können von Cloud Storage in BigQuery mit der Cloud Console, der Google Cloud CLI oder einem einfachen Script initiiert werden. Sie können sie in dieselben Tabellen einfügen wie die Hot-Path-Ereignisse. Wie beim Cold-Path-Logging haben die im Batchverfahren geladenen Analyseereignisse keine Auswirkung auf reservierte Abfrageressourcen, sodass die Belastung des Streaming-Aufnahmepfads in einem angemessenen Rahmen bleibt.
Unter Einführung in das Laden von Daten finden Sie weitere Informationen dazu.
Nächste Schritte
- Erfahren Sie mehr über die Einrichtung eines sicheren BigQuery-Data-Warehouses.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center