Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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.
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 en flux continu 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 en flux continu 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 section Présentation de la réplication.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eUse the Apache Beam Bigtable I/O connector to read data from Bigtable to Dataflow, considering Google-provided Dataflow templates as an alternative depending on your specific use case.\u003c/p\u003e\n"],["\u003cp\u003eParallelism in reading Bigtable data is governed by the number of nodes in the Bigtable cluster, with each node managing key ranges.\u003c/p\u003e\n"],["\u003cp\u003ePerformance metrics for Bigtable read operations on one \u003ccode\u003ee2-standard2\u003c/code\u003e worker using Apache Beam SDK 2.48.0 for Java, show a throughput of 180 MBps or 170,000 elements per second for 100M records, 1 kB, and 1 column, noting that real-world pipeline performance may vary.\u003c/p\u003e\n"],["\u003cp\u003eFor new pipelines, use the \u003ccode\u003eBigtableIO\u003c/code\u003e connector instead of \u003ccode\u003eCloudBigtableIO\u003c/code\u003e, and create separate app profiles for each pipeline type for better traffic differentiation and tracking.\u003c/p\u003e\n"],["\u003cp\u003eBest practices for pipeline optimization include monitoring Bigtable node resources, adjusting timeouts as needed, considering Bigtable autoscaling or resizing, and potentially using replication to separate batch and streaming pipelines for improved performance.\u003c/p\u003e\n"]]],[],null,["# Read from Bigtable to Dataflow\n\nTo read data from Bigtable to Dataflow, use the\nApache Beam [Bigtable I/O connector](https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/io/gcp/bigtable/package-summary.html).\n| **Note:** Depending on your scenario, consider using one of the [Google-provided Dataflow templates](/dataflow/docs/guides/templates/provided-templates). Several of these read from Bigtable.\n\nParallelism\n-----------\n\nParallelism is controlled by the number of\n[nodes](/bigtable/docs/instances-clusters-nodes#nodes) in the\nBigtable cluster. Each node manages one or more key ranges,\nalthough key ranges can move between nodes as part of\n[load balancing](/bigtable/docs/overview#load-balancing). For more information,\nsee [Reads and performance](/bigtable/docs/reads#performance) in the\nBigtable documentation.\n\nYou are charged for the number of nodes in your instance's clusters. See\n[Bigtable pricing](/bigtable/pricing).\n\nPerformance\n-----------\n\nThe following table shows performance metrics for Bigtable read\noperations. The workloads were run on one `e2-standard2` worker, using the\nApache Beam SDK 2.48.0 for Java. They did not use Runner v2.\n\n\nThese metrics are based on simple batch pipelines. They are intended to compare performance\nbetween I/O connectors, and are not necessarily representative of real-world pipelines.\nDataflow pipeline performance is complex, and is a function of VM type, the data\nbeing processed, the performance of external sources and sinks, and user code. Metrics are based\non running the Java SDK, and aren't representative of the performance characteristics of other\nlanguage SDKs. For more information, see [Beam IO\nPerformance](https://beam.apache.org/performance/).\n\n\u003cbr /\u003e\n\nBest practices\n--------------\n\n- For new pipelines, use the [`BigtableIO`](https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/io/gcp/bigtable/BigtableIO.html) connector, not\n `CloudBigtableIO`.\n\n- Create separate [app profiles](/bigtable/docs/app-profiles) for each type of\n pipeline. App profiles enable better metrics for differentiating traffic\n between pipelines, both for support and for tracking usage.\n\n- Monitor the Bigtable nodes. If you experience performance\n bottlenecks, check whether resources such as CPU utilization are constrained\n within Bigtable. For more information, see\n [Monitoring](/bigtable/docs/monitoring-instance).\n\n- In general, the default timeouts are well tuned for most pipelines. If a\n streaming pipeline appears to get stuck reading from Bigtable,\n try calling [`withAttemptTimeout`](https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/io/gcp/bigtable/BigtableIO.Read.html#withAttemptTimeout-org.joda.time.Duration-) to adjust the attempt\n timeout.\n\n- Consider enabling\n [Bigtable autoscaling](/bigtable/docs/autoscaling), or resize\n the Bigtable cluster to scale with the size of your\n Dataflow jobs.\n\n- Consider setting\n [`maxNumWorkers`](/dataflow/docs/reference/pipeline-options#resource_utilization)\n on the Dataflow job to limit load on the\n Bigtable cluster.\n\n- If significant processing is done on a Bigtable element before\n a shuffle, calls to Bigtable might time out. In that case, you\n can call [`withMaxBufferElementCount`](https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/io/gcp/bigtable/BigtableIO.Read.html#withMaxBufferElementCount-java.lang.Integer-) to buffer\n elements. This method converts the read operation from streaming to paginated,\n which avoids the issue.\n\n- If you use a single Bigtable cluster for both streaming and\n batch pipelines, and the performance degrades on the Bigtable\n side, consider setting up replication on the cluster. Then separate the batch\n and streaming pipelines, so that they read from different replicas. For more\n information, see [Replication overview](/bigtable/docs/replication-overview).\n\nWhat's next\n-----------\n\n- Read the [Bigtable I/O connector](https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/io/gcp/bigtable/package-summary.html) documentation.\n- See the list of [Google-provided templates](/dataflow/docs/guides/templates/provided-templates)."]]
