Présentation des requêtes continues

Ce document décrit les requêtes continues BigQuery.

Les requêtes continues BigQuery sont des instructions SQL qui s'exécutent en continu. Les requêtes continues vous permettent d'analyser les données entrant dans BigQuery en temps réel. Vous pouvez écrire ou exporter les lignes de sortie générées par une requête continue vers les destinations suivantes :

• les tables BigQuery
• Tables gérées Apache Iceberg
• Sujets Pub/Sub
• Tables Bigtable
• Tables Spanner

Les requêtes continues peuvent traiter les données écrites dans les tables BigQuery standards à l'aide de l'une des méthodes suivantes :

• L'API BigQuery Storage Write (gRPC)
• L'API BigQuery Storage Write (REST)
• Chargement par lot
• L'instruction LMD INSERT
• Instructions de langage de manipulation de données (LMD) telles que DELETE, UPDATE et MERGE lors de l'exportation de données vers Pub/Sub.
• Écrit les résultats d'une requête par lot dans une table permanente
• Écritures à partir des résultats d'une requête continue BigQuery dans une table permanente
• Un abonnement BigQuery Pub/Sub
• Écritures de Dataflow vers BigQuery
• Écrit des données depuis Datastream vers BigQuery à l'aide du mode d'écriture en mode Ajout uniquement

Vous pouvez utiliser des requêtes continues pour effectuer des tâches urgentes, telles que la création et l'action immédiate sur des insights, l'application de l'inférence de machine learning (ML) en temps réel et la réplication des données vers d'autres plates-formes. Cela vous permet d'utiliser BigQuery comme moteur de traitement de données basé sur des événements pour la logique de décision de votre application.

Le schéma suivant illustre des workflows de requêtes continues courants :

Cas d'utilisation

Voici quelques cas d'utilisation courants de requêtes continues :

• Services d'interaction personnalisés avec les clients : utilisez l'IA générative pour créer des messages sur mesure adaptés à chaque interaction client.
• Détection d'anomalies : créez des solutions vous permettant de détecter les anomalies et les menaces sur des données complexes en temps réel, afin de pouvoir réagir plus rapidement aux problèmes.
• Pipelines personnalisables basés sur des événements : utilisez l'intégration de requêtes continues avec Pub/Sub pour déclencher des applications en aval en fonction des données entrantes.
• Enrichissement des données et extraction d'entités : utilisez des requêtes continues pour enrichir et transformer des données en temps réel à l'aide de fonctions SQL et de modèles de ML.
• Opérations d'extraction, de transformation et de chargement (ETL, Extract-Transform-Load) inverses : effectuez un ETL inversé en temps réel dans d'autres systèmes de stockage plus adaptés à la diffusion d'applications à faible latence. Par exemple, analyser ou améliorer les données d'événements écrites dans BigQuery, puis les importer par flux dans Bigtable, Spanner ou les tables gérées Apache Iceberg pour la diffusion de l'application.
• Déclenchement autonome des agents : déclenchez des pipelines de données agentiques en temps réel en fonction d'événements complexes détectés dans les flux de données en direct. Pour obtenir un exemple, consultez l'atelier de programmation "Créer un agent de données basé sur des événements avec BigQuery et Agent Development Kit (ADK)".
• Surveillance autonome des agents : développez une surveillance et des alertes automatisées en temps réel pour les interactions agentives en temps réel à l'aide du plug-in BigQuery Agent Analytics, qui transmet en flux continu toutes les données de trace des agents, l'utilisation des outils et les journaux opérationnels directement dans BigQuery pour une observabilité approfondie de votre personnel d'IA.

Fonctionnalités compatibles

Les opérations suivantes sont acceptées dans les requêtes continues :

• L'exécution d'instructions INSERT pour écrire des données issues d'une requête continue dans une table BigQuery ou une table gérée Iceberg.

• L'exécution d'instructions EXPORT DATA pour publier le résultat de la requête continue dans des sujets Pub/Sub.

  Les requêtes continues qui exportent des données vers Pub/Sub doivent être exécutées à l'aide d'un compte de service. Pour en savoir plus, consultez Exporter des données vers Pub/Sub.

  À partir d'un sujet Pub/Sub, vous pouvez utiliser les données avec d'autres services, par exemple pour effectuer des analyses de flux à l'aide de Dataflow ou pour utiliser les données dans un workflow d'intégration d'applications.

• L'exécution d'instructions EXPORT DATA pour exporter des données depuis BigQuery vers des tables Bigtable Pour en savoir plus, consultez Exporter des données vers Bigtable.

• L'exécution d'instructions EXPORT DATA pour exporter des données depuis BigQuery vers des tables Spanner. Pour en savoir plus, consultez Exporter des données vers Spanner (ETL inversé).

• Appel des fonctions d'IA générative suivantes :

  • AI.GENERATE

  • AI.GENERATE_TEXT

    • Cette fonction nécessite un modèle distant BigQuery ML sur un modèle Gemini Enterprise Agent Platform.

• Appel des fonctions d'IA suivantes :

  • ML.UNDERSTAND_TEXT
  • ML.TRANSLATE

  Ces fonctions nécessitent que vous disposiez d'un modèle distant BigQuery ML sur une API d'IA Cloud.

• La normalisation des données numériques à l'aide de la fonction ML.NORMALIZER

• Analyser et traiter les données JSON, y compris la prise en charge des fonctions JSON et de la désimbrication JSON.

• L'utilisation de fonctions GoogleSQL sans état, telles que les fonctions de conversion. Dans les fonctions sans état, chaque ligne est traitée indépendamment des autres lignes du tableau.

• Utiliser des opérations avec état, par exemple JOIN, des agrégations et des agrégations de fenêtres. Dans les opérations avec état, l'état des données ingérées est conservé sur plusieurs lignes ou intervalles de temps afin de calculer un résultat précis.

• L'utilisation de la fonction d'historique des modifications APPENDS pour traiter les données ajoutées à partir d'un moment précis.

• L'utilisation de la fonction d'historique des modifications CHANGES pour traiter les données modifiées, y compris les ajouts et les mutations, à partir d'un moment précis lors de l'exportation des données vers Pub/Sub. Toutefois, CHANGES n'est pas compatible avec les opérations avec état.

• Interroger les vues, à condition que la requête SQL sous-jacente de la vue soit une requête continue valide.

Opérations avec état compatibles

Aperçu

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour demander de l'aide ou envoyer des commentaires concernant cette fonctionnalité, envoyez un e-mail à l'adresse [e-mail].

Les opérations avec état permettent aux requêtes continues d'effectuer des analyses complexes qui nécessitent de conserver des informations sur plusieurs lignes ou intervalles de temps. Alors que les fonctions sans état traitent chaque ligne indépendamment, les opérations avec état conservent l'état des données ingérées pour prendre en charge des fonctions telles que JOIN, les agrégations et les agrégations de fenêtres. Cette fonctionnalité vous permet de corréler des événements provenant de différents flux ou de calculer des métriques au fil du temps (par exemple, une moyenne sur 30 minutes) en stockant les données nécessaires en mémoire pendant l'exécution de la requête.

Les requêtes continues sont compatibles avec les opérations avec état suivantes :

• JOIN
• Agrégations et fenêtrage
• UNION ALL

Autorisation

Les jetons d'accèsGoogle Cloud utilisés lors de l'exécution de jobs de requête continue ont une valeur TTL (Time To Live) de deux jours lorsqu'ils sont générés par un compte utilisateur. Par conséquent, ces jobs cessent de s'exécuter après deux jours. Les jetons d'accès générés par les comptes de service peuvent s'exécuter plus longtemps, mais doivent toujours respecter la durée d'exécution maximale des requêtes. Pour en savoir plus, consultez Exécuter une requête continue à l'aide d'un compte de service.

Emplacements

Pour obtenir la liste des régions compatibles, consultez Emplacements des requêtes continues BigQuery.

Limites

Les requêtes continues sont soumises aux limites suivantes :

• L'état des données ingérées n'est conservé que pour les opérations avec état spécifiques en version Preview. Bien que les requêtes continues soient désormais compatibles avec certains types de JOIN, d'agrégations et d'agrégations de fenêtres, celles-ci sont limitées à des opérations avec état spécifiques. Tous les types d'opérations avec état ne sont pas acceptés.

• Vous ne pouvez pas utiliser les fonctionnalités SQL suivantes dans une requête continue, sauf si elles sont listées comme opération avec état acceptée :

  • Les opérateurs de requête suivants :

    • PIVOT
    • UNPIVOT
    • TABLESAMPLE

  • Opérateurs d'ensemble de requête, à l'exception de UNION ALL.

  • L'instruction SELECT DISTINCT

  • Sous-requêtes EXISTS ou NOT EXISTS

  • CTE récursifs

  • Fonctions définies par l'utilisateur

  • Appels de fonctions de fenêtrage

  • Fonctions BigQuery ML autres que celles listées dans la section Fonctionnalités compatibles

  • Instructions du langage de définition de données (LDD)

  • Instructions du langage de manipulation de données (LMD), à l'exception de INSERT.

  • Instructions de langage de contrôle de données (DCL)

  • Instructions EXPORT DATA qui ne ciblent pas Bigtable, Pub/Sub ni Spanner.

  • Langage procédural

  • Instructions de débogage

• Les requêtes continues ne sont pas compatibles avec les sources de données suivantes :

  • Tables externes.
  • Vues du schéma d'informations
  • Tables gérées Apache Iceberg Notez que, bien que les tables gérées Iceberg ne soient pas acceptées en tant que sources de données, elles le sont en tant que destinations pour les résultats de requêtes continues.
  • Tables génériques.
  • Upsert de données de capture des données modifiées (CDC).
  • Vues matérialisées
  • Vues dont la requête SQL sous-jacente utilise des fonctionnalités non compatibles, telles que des fonctions définies par l'utilisateur, des tables externes ou des tables compatibles avec la capture des données modifiées (CDC).

• Les requêtes continues ne sont pas compatibles avec les fonctionnalités de sécurité column- et au niveau des lignes.

• La sortie d'une requête continue est soumise aux quotas et limites inhérents du service de destination vers lequel elle est exportée.

• Lorsque vous exportez des données vers Bigtable, Spanner ou des points de terminaison régionaux Pub/Sub, vous ne pouvez cibler que les ressources Bigtable, Spanner ou Pub/Sub situées dans la même limite régionale Google Cloudque l'ensemble de données BigQuery contenant la table que vous interrogez. Cette restriction ne s'applique pas lors de l'exportation de données vers des points de terminaison mondiaux Pub/Sub. Pour en savoir plus sur l'exportation vers une règle de routage de profil d'application Bigtable, consultez Considérations relatives aux zones.

• Vous ne pouvez pas exécuter de requête continue à partir d'un canevas de données.

• Vous ne pouvez pas modifier le code SQL utilisé dans une requête continue pendant l'exécution du job de requête continue. Pour en savoir plus, consultez Modifier le code SQL d'une requête continue.

• Si un job de requête continue prend du retard dans le traitement des données entrantes et présente un décalage du filigrane de sortie de plus de 48 heures, il échoue. Vous pouvez exécuter à nouveau la requête et utiliser la fonction d'historique des modifications APPENDS ou CHANGES pour reprendre le traitement à partir du moment où vous avez arrêté le job de requête continue précédent. Pour en savoir plus, consultez Démarrer une requête continue à partir d'un moment précis.

• Une requête continue configurée avec un compte utilisateur peut s'exécuter pendant deux jours maximum. Une requête continue configurée avec un compte de service peut s'exécuter pendant 150 jours maximum. Lorsque la durée d'exécution maximale de la requête est atteinte, la requête échoue et cesse de traiter les données entrantes.

• Bien que les requêtes continues soient créées à l'aide des fonctionnalités de fiabilité BigQuery, des problèmes temporaires peuvent survenir de temps en temps. Les problèmes peuvent entraîner un certain nombre de retraitements automatiques de votre requête continue, ce qui peut entraîner des données en double dans la sortie de la requête continue. Concevez vos systèmes en aval pour gérer de tels scénarios.

Limites de réservation

• Pour exécuter des requêtes continues, vous devez créer une réservation Enterprise ou Enterprise Plus avec un type d'attribution CONTINUOUS. Les requêtes continues ne sont pas compatibles avec le modèle de facturation du calcul à la demande.
• Lorsque vous créez une CONTINUOUS attribution de réservation, la réservation associée est limitée à 500 emplacements maximum. Vous pouvez demander à augmenter cette limite en contactant [e-mail].
• Vous ne pouvez pas créer une attribution de réservation qui utilise un type de job différent dans la même réservation qu'une attribution de réservation de requête continue.

• BigQuery détermine le nombre de requêtes continues pouvant s'exécuter simultanément par projet en fonction de la taille configurée de l'attribution de réservation qui utilise le type de job CONTINUOUS. Pour accepter de nouveaux jobs, BigQuery exige un seuil de 10 emplacements par job de requête continue. La requête ne consomme pas nécessairement les 10 emplacements lors de l'exécution normale. Ce seuil garantit que chaque requête continue en cours d'exécution dispose d'une capacité de calcul de base suffisante pour gérer les pics soudains du volume de données entrantes sans prendre de retard ni compromettre le traitement à faible latence.

  Pour vous assurer que vos requêtes sont acceptées sans atteindre les limites de simultanéité, nous vous recommandons d'utiliser l'autoscaling des emplacements. Avec l'autoscaling, votre utilisation globale des emplacements évolue de manière dynamique en fonction de la demande réelle de ressources. Vous pouvez configurer une réservation de référence plus petite et définir une limite d'autoscaling maximale qui couvre confortablement le seuil de 10 emplacements par requête pour vos requêtes simultanées attendues.

• Lorsque vous exécutez plusieurs requêtes continues à l'aide de la même réservation, les jobs individuels peuvent ne pas répartir les ressources disponibles de manière équitable, comme défini par l'équité BigQuery.

Autoscaling des emplacements

Les requêtes continues peuvent utiliser l'autoscaling des emplacements pour ajuster de manière dynamique la capacité allouée en fonction de votre charge de travail. À mesure que la charge de travail de vos requêtes continues augmente ou diminue, BigQuery ajuste dynamiquement vos emplacements.

Une fois qu'une requête continue commence à s'exécuter, elle écoute activement les données entrantes, ce qui consomme des ressources d'emplacement. Bien qu'une réservation avec une requête continue en cours d'exécution ne soit pas réduite à zéro emplacement, une requête continue inactive qui écoute principalement les données entrantes devrait consommer un nombre minimal d'emplacements, généralement un seul.

Partage des emplacements inutilisés

Les requêtes continues peuvent utiliser le partage d'emplacements inactifs pour partager les ressources d'emplacements inutilisés avec d'autres réservations et types de jobs.

• Une attribution de réservation CONTINUOUS est toujours requise pour exécuter une requête continue. Vous ne pouvez pas vous appuyer uniquement sur les emplacements inactifs d'autres réservations. Par conséquent, une attribution de réservation CONTINUOUS nécessite une configuration d'autoscaling des emplacements ou une valeur de référence des emplacements différente de zéro.
• Seuls les emplacements de référence inactifs ou les emplacements sur engagement d'une attribution de réservation CONTINUOUS peuvent être partagés. Les emplacements autoscalés ne peuvent pas être partagés en tant qu'emplacements inactifs avec d'autres réservations.

Tarifs

Les requêtes continues peuvent utiliser le scaling fluide BigQuery.

Les requêtes continues utilisent les tarifs des calculs de capacité BigQuery, exprimée en emplacements. Pour exécuter des requêtes continues, vous devez disposer d'une réservation qui utilise l'édition Enterprise ou Enterprise Plus et d'une attribution de réservation qui utilise le type de job CONTINUOUS.

L'utilisation d'autres ressources BigQuery, comme l'ingestion et le stockage de données, est facturée selon les tarifs indiqués sur la page Tarifs de BigQuery.

L'utilisation d'autres services qui reçoivent des résultats de requêtes continues ou qui sont appelés pendant le traitement des requêtes continues est facturée selon les tarifs publiés pour ces services. Pour connaître la tarification des autres services Google Cloud utilisés par les requêtes continues, consultez les sections suivantes :

• Tarifs de Bigtable
• Tarifs de Pub/Sub
• Tarifs Spanner
• Tarifs d'Agent Platform

Estimer les exigences relatives à la capacité d'emplacements

Chaque charge de travail étant différente, il est souvent impossible d'estimer précisément le nombre d'emplacements pour les requêtes continues à l'avance. Le nombre d'emplacements requis par vos requêtes continues dépend de plusieurs facteurs :

• Nombre de requêtes continues exécutées simultanément.
• Complexité de l'instruction SQL.
• Utilisation de fonctions de traitement avec état, y compris les durées de fenêtres, les JOIN et les agrégations.
• Taux ou vitesse des données entrantes.
• La structure et la taille des données ingérées.

D'un point de vue conceptuel, vous pouvez estimer votre besoin total en emplacements en fonction de votre charge de travail de requêtes continues :

Emplacements estimés ≈ Nombre de requêtes continues x ∑ (Taux de données x Complexité de la requête)

Étant donné que la consommation de slots réelle dépend fortement de votre charge de travail et de vos schémas de données uniques, la méthode la plus précise pour estimer les coûts consiste à surveiller un job en cours d'exécution. Vous pouvez mesurer l'utilisation maximale des emplacements d'une exécution de requête continue isolée à l'aide des vues INFORMATION_SCHEMA. Pour obtenir des instructions détaillées et des exemples de requêtes permettant de suivre l'utilisation des emplacements au fil du temps, consultez Afficher des informations sur la consommation d'emplacements.

Étapes suivantes

Essayez de créer une requête continue.