Lire des données de Bigtable vers Dataflow

Pour lire des données de Bigtable vers Dataflow, utilisez le connecteur d'E/S Bigtable d'Apache Beam.

Parallélisme

Le parallélisme est contrôlé par le nombre de nœuds dans le cluster Bigtable. Chaque nœud gère une ou plusieurs plages de clés, bien que les plages de clés puissent être déplacées entre les nœuds dans le cadre de l'équilibrage de charge. Pour plus d'informations, consultez la section Lectures et performances dans la documentation de Bigtable.

Le nombre de nœuds dans les clusters de votre instance vous est facturé. Consultez la page sur les tarifs de Bigtable.

Performances

Le tableau suivant présente les métriques de performances des opérations de lecture de Bigtable. Les charges de travail ont été exécutées sur un nœud de calcul e2-standard2 à l'aide du SDK Apache Beam 2.48.0 pour Java. Elles n'ont pas utilisé l'exécuteur v2.

100 millions d'enregistrements | 1 Ko | 1 colonne Débit (octets) Débit (éléments)
Lecture 180 Mbit/s 170 000 éléments par seconde

Ces métriques sont basées sur des pipelines de traitement par lot simples. Elles ont pour but de comparer les performances entre les connecteurs d'E/S et ne sont pas nécessairement représentatives des pipelines réels. Les performances des pipelines Dataflow sont complexes et dépendent du type de machine virtuelle, des données traitées, des performances des sources et des récepteurs externes, ainsi que du code utilisateur. Les métriques sont basées sur l'exécution du SDK Java et ne sont pas représentatives des caractéristiques de performances des SDK d'autres langages. Pour en savoir plus, consultez la page Performances d'E/S Beam.

Bonnes pratiques

  • Pour les nouveaux pipelines, utilisez le connecteur BigtableIO et non CloudBigtableIO.

  • Créez des profils d'application distincts pour chaque type de pipeline. Les profils d'application permettent d'obtenir de meilleures métriques pour différencier le trafic entre les pipelines, à la fois pour l'assistance et pour le suivi de l'utilisation.

  • Surveillez les nœuds Bigtable. Si vous rencontrez des goulots d'étranglement qui affectent les performances, vérifiez si des ressources telles que l'utilisation du processeur sont limitées dans Bigtable. Pour en savoir plus, consultez la section Surveillance.

  • En général, les délais avant expiration par défaut sont parfaitement adaptés à la plupart des pipelines. Si un pipeline de traitement par flux semble bloqué depuis Bigtable en lecture, essayez d'appeler withAttemptTimeout pour ajuster le délai avant expiration de la tentative.

  • Envisagez d'activer l'autoscaling Bigtable ou de redimensionner le cluster Bigtable pour qu'il s'adapte à la taille de vos tâches Dataflow.

  • Envisagez de définir maxNumWorkers sur la tâche Dataflow pour limiter la charge sur le cluster Bigtable.

  • Si un traitement important est effectué sur un élément Bigtable avant un brassage, les appels à Bigtable peuvent expirer. Dans ce cas, vous pouvez appeler withMaxBufferElementCount pour mettre en mémoire tampon les éléments. Cette méthode convertit l'opération de lecture en streaming en lecture paginée, ce qui évite le problème.

  • Si vous utilisez un seul cluster Bigtable pour les pipelines de traitement par flux et par lot, et que les performances se dégradent côté Bigtable, envisagez de configurer la réplication sur le cluster. Séparez ensuite les pipelines de traitement par lot et par flux afin qu'ils puissent lire à partir de différentes instances répliquées. Pour en savoir plus, consultez la page Présentation de la réplication.

Étapes suivantes