Para ler dados do Bigtable para o Dataflow, use o conector de E/S do Bigtable do Apache Beam.
Paralelismo
O paralelismo é controlado pelo número de nós no cluster do Bigtable. Cada nó gerencia um ou mais intervalos de chaves, mas eles podem se mover entre os nós como parte do balanceamento de carga. Para mais informações, Confira Leituras e desempenhona documentação do Bigtable.
Você é cobrado pelo número de nós nos clusters da sua instância. Confira Preços do Bigtable.
Performance
A tabela a seguir mostra as métricas de desempenho das operações de leitura
do Bigtable. As cargas de trabalho foram executadas em um worker e2-standard2
usando
o SDK do Apache Beam 2.48.0 para Java. Eles não usaram o Runner v2.
100 milhões de registros | 1 KB | 1 coluna | Capacidade de processamento (bytes) | Capacidade de processamento (elementos) |
---|---|---|
Ler | 180 MBps | 170.000 elementos por segundo |
Essas métricas são baseadas em pipelines de lote simples. Elas servem para comparar o desempenho entre conectores de E/S e não representam necessariamente pipelines reais. O desempenho do pipeline do Dataflow é complexo e depende do tipo de VM, dos dados processados, do desempenho de origens e coletores externos e do código do usuário. As métricas se baseiam na execução do SDK do Java e não representam as características de desempenho de outros SDKs da linguagem. Para mais informações, confira Desempenho do E/S do Beam.
Práticas recomendadas
Para novos pipelines, use o conector
BigtableIO
, não oCloudBigtableIO
.Crie perfis de app separados para cada tipo de pipeline. Os perfis de app permitem melhores métricas para diferenciar o tráfego entre pipelines, para suporte e rastreamento de uso.
Monitore os nós do Bigtable. Se você tiver gargalos de desempenho, verifique se os recursos, como o uso da CPU, estão restritos no Bigtable. Para mais informações, consulte Monitoramento.
Em geral, os tempos limite padrão são bem ajustados na maioria dos pipelines. Se um pipeline de streaming travar ao ler no Bigtable, tente chamar
withAttemptTimeout
para ajustar o tempo limite da tentativa.Ative o escalonamento automático do Bigtable ou redimensione o cluster do Bigtable para ajustar ao tamanho dos jobs do Dataflow.
Considere definir
maxNumWorkers
no job do Dataflow para limitar a carga no cluster do Bigtable.Se um processamento significativo for feito em um elemento do Bigtable antes de um embaralhamento, as chamadas para o Bigtable podem expirar. Nesse caso, é possível chamar
withMaxBufferElementCount
para armazenar elementos em buffer. Esse método converte a operação de leitura de streaming para paginado, o que evita o problema.Se você usa um único cluster do Bigtable para pipelines de streaming e em lote, e o desempenho é reduzido no lado do Bigtable, considere configurar a replicação no cluster. Em seguida, separe os pipelines de lote e de streaming para que eles leiam de réplicas diferentes. Para mais informações, consulte Informações gerais da replicação.
A seguir
- Leia a documentação do conector de E/S do Bigtable.
- Confira a lista de modelos fornecidos pelo Google.