Von Bigtable nach Dataflow lesen

In Bigtable gespeicherte Betriebsdaten müssen häufig verarbeitet, aggregiert oder für nachgelagerte Analysen exportiert werden, ohne dass die Leistung von Live-Anwendungen beeinträchtigt wird. Wenn Sie Bigtable-Daten in Dataflow aufnehmen, können Sie skalierbare, parallele Pipelines verwenden, um große Mengen an Betriebsdatensätzen für ETL-Workflows, analytische Aggregationen und Data Lake-Exporte zu verarbeiten.

Zum Erstellen benutzerdefinierter Datenpipelines können Sie den Bigtable-E/A-Connector von Apache Beam verwenden. Für gängige Aufgaben wie das Exportieren von Tabellen nach Cloud Storage können Sie auch von Google bereitgestellte Dataflow-Vorlagen verwenden, um vordefinierte Pipelines bereitzustellen, ohne benutzerdefinierten Code schreiben zu müssen.

Parallelität

Die Parallelität wird durch die Anzahl der Knoten im Bigtable-Cluster gesteuert. Jeder Knoten verwaltet einen oder mehrere Schlüsselbereiche. Schlüsselbereiche können jedoch im Rahmen des Load-Balancings zwischen Knoten verschoben werden. Weitere Informationen finden Sie in der Bigtable-Dokumentation unter Lesevorgänge und Leistung.

Ihnen wird die Anzahl der Knoten in den Clustern Ihrer Instanz in Rechnung gestellt. Siehe Bigtable-Preise.

Leistung

In der folgenden Tabelle sind Leistungsmesswerte für Bigtable-Lesevorgänge aufgeführt. Die Arbeitslasten wurden mit einem Apache Beam SDK 2.48.0 für Java auf einem e2-standard2-Worker ausgeführt. Der Portable Runner wurde nicht verwendet.

100 Mio. Datensätze | 1 KB | 1 Spalte Durchsatz (Byte) Durchsatz (Elemente)
Lesen 180 Mbit/s 170.000 Elemente pro Sekunde

Diese Messwerte basieren auf einfachen Batchpipelines. Sie dienen zum Vergleich der Leistung zwischen E/A-Anschlüssen und sind nicht unbedingt repräsentativ für reale Pipelines. Die Leistung der Dataflow-Pipeline ist komplex und eine Funktion des VM-Typs, der verarbeiteten Daten, der Leistung externer Quellen und Senken sowie des Nutzercodes. Die Messwerte basieren auf der Ausführung des Java SDK und sind nicht repräsentativ für die Leistungsmerkmale anderer Sprach-SDKs. Weitere Informationen finden Sie unter Beam E/A-Leistung.

Best Practices

  • Verwenden Sie für neue Pipelines den Connector BigtableIO und nicht CloudBigtableIO.

  • Erstellen Sie für jeden Pipelinetyp separate Anwendungsprofile. Anwendungsprofile ermöglichen bessere Messwerte zur Unterscheidung des Traffics zwischen Pipelines, sowohl für den Support als auch für das Tracking der Nutzung.

  • Bigtable-Knoten überwachen Wenn Leistungsengpässe auftreten, prüfen Sie, ob Ressourcen wie die CPU-Auslastung in Bigtable eingeschränkt sind. Weitere Informationen finden Sie unter Monitoring.

  • Im Allgemeinen sind die Standard-Zeitlimits für die meisten Pipelines gut abgestimmt. Wenn eine Streamingpipeline aus Bigtable zu lesen scheint, versuchen Sie, withAttemptTimeout aufzurufen, um die Zeitüberschreitung für Versuche anzupassen.

  • Sie können das Bigtable-Autoscaling aktivieren oder die Größe des Bigtable-Clusters an die Größe Ihrer Dataflow-Jobs anpassen.

  • Sie können maxNumWorkers für den Dataflow-Job festlegen, um die Last auf dem Bigtable-Cluster zu begrenzen.

  • Wenn vor einem Shuffle eine erhebliche Verarbeitung für ein Bigtable-Element erfolgt, kann es bei Aufrufen an Bigtable zu Zeitüberschreitungen kommen. In diesem Fall können Sie withMaxBufferElementCount aufrufen, um Elemente zu puffern. Mit dieser Methode wird der Lesevorgang von Streaming in Seiten umgewandelt, wodurch das Problem vermieden wird.

  • Wenn Sie einen einzelnen Bigtable-Cluster sowohl für Streaming- als auch für Batchpipelines verwenden und die Leistung auf der Bigtable-Seite abnimmt, sollten Sie die Replikation auf dem Cluster einrichten. Trennen Sie dann die Batch- und Streamingpipelines, sodass sie aus verschiedenen Replikaten lesen. Weitere Informationen finden Sie unter Replikation – Übersicht.

Wie geht es weiter?