Leggere da Bigtable a Dataflow

I dati operativi archiviati in Bigtable spesso devono essere elaborati, aggregati o esportati per l'analisi a valle senza compromettere le prestazioni delle applicazioni attive. L'importazione dei dati di Bigtable in Dataflow consente di utilizzare pipeline scalabili e parallele per gestire record operativi di volumi elevati per workflow ETL, aggregazioni analitiche ed esportazioni di data lake.

Per creare pipeline di dati personalizzate, puoi utilizzare il connettore Bigtable I/O di Apache Beam. Per attività comuni come l'esportazione di tabelle in Cloud Storage, puoi anche utilizzare i modelli Dataflow forniti da Google per eseguire il deployment di pipeline predefinite senza scrivere codice personalizzato.

Parallelismo

Il parallelismo è controllato dal numero di nodi nel cluster Bigtable. Ogni nodo gestisce uno o più intervalli di chiavi, anche se gli intervalli di chiavi possono spostarsi tra i nodi nell'ambito del bilanciamento del carico. Per saperne di più, consulta Letture e prestazioni nella documentazione di Bigtable.

Ti viene addebitato il costo per il numero di nodi nei cluster dell'istanza. Consulta i prezzi di Bigtable.

Prestazioni

La tabella seguente mostra le metriche sul rendimento per le operazioni di lettura di Bigtable. I workload sono stati eseguiti su un worker e2-standard2, utilizzando l'SDK Apache Beam 2.48.0 per Java. Non hanno utilizzato il runner portatile.

100 milioni di record | 1 kB | 1 colonna Throughput (byte) Throughput (elementi)
Leggi 180 MBps 170.000 elementi al secondo

Queste metriche si basano su semplici pipeline batch. Sono pensati per confrontare le prestazioni tra i connettori di I/O e non sono necessariamente rappresentativi delle pipeline reali. Le prestazioni della pipeline Dataflow sono complesse e dipendono dal tipo di VM, dai dati in fase di elaborazione, dalle prestazioni di origini e sink esterni e dal codice utente. Le metriche si basano sull'esecuzione dell'SDK Java e non sono rappresentative delle caratteristiche di rendimento degli SDK di altri linguaggi. Per saperne di più, consulta Prestazioni di Beam IO.

Best practice

  • Per le nuove pipeline, utilizza il connettore BigtableIO, non CloudBigtableIO.

  • Crea profili app separati per ogni tipo di pipeline. I profili app consentono di ottenere metriche migliori per differenziare il traffico tra le pipeline, sia per l'assistenza sia per il monitoraggio dell'utilizzo.

  • Monitora i nodi Bigtable. Se riscontri colli di bottiglia nelle prestazioni, controlla se le risorse, come l'utilizzo della CPU, sono limitate all'interno di Bigtable. Per saperne di più, consulta Monitoring.

  • In genere, i timeout predefiniti sono ottimizzati per la maggior parte delle pipeline. Se una pipeline di streaming sembra bloccarsi durante la lettura da Bigtable, prova a chiamare withAttemptTimeout per regolare il timeout del tentativo.

  • Valuta la possibilità di attivare la scalabilità automatica di Bigtable o di ridimensionare il cluster Bigtable per fare lo scale up in base alle dimensioni dei job Dataflow.

  • Valuta la possibilità di impostare maxNumWorkers sul job Dataflow per limitare il carico sul cluster Bigtable.

  • Se viene eseguita un'elaborazione significativa su un elemento Bigtable prima di uno shuffle, le chiamate a Bigtable potrebbero scadere. In questo caso, puoi chiamare withMaxBufferElementCount per memorizzare gli elementi nel buffer. Questo metodo converte l'operazione di lettura da streaming a impaginata, evitando il problema.

  • Se utilizzi un singolo cluster Bigtable per le pipeline di flussi di dati e batch e le prestazioni peggiorano sul lato Bigtable, valuta la possibilità di configurare la replica sul cluster. Poi, separa le pipeline batch e di streaming in modo che leggano da repliche diverse. Per saperne di più, consulta la Panoramica della replica.

Passaggi successivi