Les flux de données streaming échouent avec des erreurs de quota dépassé après une augmentation de volume

Manon Garcia 0 Points de réputation
2026-10-13T14:28:40.45+00:00

Bonjour, j'utilise notre pipeline de télémétrie déployé sur l'ensemble de nos postes de travail d'entreprise avec une ingestion en continu vers BigQuery (sur Google Cloud).

Suite à une montée en charge du volume de données remontées par nos applications métier, les flux streaming récents ne s'intègrent plus du tout et renvoient des erreurs "Quota exceeded" en écriture. Pourtant, les flux par lots plus légers passent sans encombre, ce qui prouve que la connexion et les accès à la table fonctionnent.

J'ai déjà tenté d'espacer les envois et d'augmenter les délais d'attente, mais rien n'y fait.

Quelqu'un aurait-il une solution pour migrer correctement l'ingestion vers la BigQuery Storage Write API afin de contourner ces limites de quota de l'ancienne API streaming ?

Merci d'avance pour votre aide !

Windows pour les entreprises | Windows 365 Business
0 commentaires Aucun commentaire

1 réponse

  1. Daphne Huynh (WICLOUD CORPORATION) 1,980 Points de réputation Personnel externe Microsoft Modérateur
    2026-10-14T05:32:06.2466667+00:00

    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 :

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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.
    7. 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.

    Cette réponse a-t-elle été utile ?

    0 commentaires Aucun commentaire

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur.