Bienvenue sur Microsoft Q&A !
Merci d’avoir pris le temps de fournir des informations aussi détaillées.
Oui, la migration du chemin d’ingestion à volume élevé vers la BigQuery Storage Write API est une approche raisonnable. Toutefois, avant d’effectuer cette modification, je vous recommande de confirmer le quota exact qui est dépassé.
Étant donné que votre ingestion à faible volume et votre ingestion par lots continuent de fonctionner, il est moins probable que le problème soit dû à la connectivité de base ou aux autorisations d’accès aux tables. L’augmentation du volume de télémétrie peut plutôt amener la charge de travail de streaming à dépasser l’un des quotas BigQuery applicables.
Avant de procéder à la migration, vérifiez l’erreur complète quotaExceeded ou RESOURCE_EXHAUSTED et identifiez le quota correspondant dans Google Cloud. Cela est important, car la Storage Write API possède également ses propres quotas et limites. La migration doit donc être considérée comme une amélioration architecturale pour le streaming à volume élevé plutôt que comme un moyen de supprimer complètement les restrictions de quota.
Pour une télémétrie continue à volume élevé, je vous suggère l’approche de migration suivante :
- Activez la BigQuery Storage Write API pour le projet et confirmez que l’identité utilisée par votre pipeline d’ingestion dispose des autorisations BigQuery requises.
- Remplacez le composant d’écriture d’insertion en streaming hérité par un client Storage Write API. La Storage Write API prend en charge l’ingestion en streaming via son interface AppendRows.
- Pour la plupart des scénarios de télémétrie, envisagez de commencer par le flux par défaut, en particulier si une livraison au moins une fois est acceptable. Les données écrites avec succès peuvent être interrogées immédiatement.
- Si votre application nécessite une sémantique exactement une fois, utilisez des flux COMMITTED créés par l’application avec des offsets. Les offsets peuvent être utilisés pour aider à détecter les opérations d’ajout en double.
- Maintenez les connexions d’écriture ouvertes sur une longue durée plutôt que de créer de façon répétée des connexions pour de petits lots. Lorsque cela est approprié, regroupez les enregistrements de télémétrie dans des requêtes d’ajout et utilisez le contrôle de flux pour éviter que les producteurs ne surchargent le service.
- Implémentez une gestion des nouvelles tentatives pour les défaillances transitoires. Pour les conditions RESOURCE_EXHAUSTED ou de limitation, utilisez une temporisation exponentielle plutôt que d’appliquer simplement un délai fixe entre les requêtes.
- Pendant la migration, envisagez de ne déplacer initialement qu’une partie de la charge de travail d’ingestion. Surveillez le débit, la latence d’ingestion, le nombre de lignes et les erreurs liées aux quotas avant d’augmenter progressivement le trafic et de retirer l’ancien chemin de streaming.
Un point important est que l’augmentation du délai entre les requêtes de streaming héritées peut ne pas résoudre le problème si le taux d’ingestion soutenu lui-même dépasse le quota applicable. La temporisation peut aider en cas de limitation temporaire, mais elle ne fournit pas de capacité d’ingestion soutenue supplémentaire.
Par conséquent, je commencerais par identifier le quota exact indiqué dans l’erreur, puis je migrerais la charge de travail d’ingestion continue à volume élevé vers la Storage Write API. Le flux par défaut constitue généralement le point de départ le plus simple, sauf si votre application nécessite spécifiquement une livraison exactement une fois.
Si le problème persiste après la migration, ou si vous avez besoin d’une augmentation de quota au-delà des limites documentées, je vous recommande de contacter l’assistance Google Cloud, car BigQuery et la Storage Write API sont des services Google Cloud. L’assistance pourra examiner l’utilisation des quotas du projet concerné et déterminer si une augmentation est disponible.
J’espère que cela vous aidera à mieux comprendre ce comportement et vous fournira une marche à suivre claire.
Si vous trouvez cette réponse utile, veuillez cliquer sur Accepter la réponse.
Merci d’avoir choisi Microsoft Q&A.
Remarque : Cette réponse a été traduite à l’aide d’un outil de traduction. Veuillez noter qu’elle peut contenir des erreurs grammaticales ou sémantiques. Merci de votre compréhension.