Interroger BigQuery en langage naturel

Pour analyser des commandes dans BigQuery, précisez la période et la mesure : « Compte les commandes payées par jour pour août 2026. » Datarelix génère une requête GoogleSQL, l’exécute après validation en lecture seule et produit un graphique. Il vous faut un accès au dataset et un projet autorisé à exécuter le job.

Identifier les projets de données et de facturation

Le projet de données contient le dataset. Le projet de facturation exécute le job ; ils peuvent être différents. Demandez le dataset autorisé, la localisation du job et la méthode d’authentification. Datarelix propose Google OAuth, un fichier JSON de compte de service et l’usurpation d’identité de compte de service, selon le guide de connexion.

L’identité doit pouvoir créer des jobs dans le projet de facturation et lire les données visées. Une configuration courante associe BigQuery Job User sur le projet de facturation à BigQuery Data Viewer sur le dataset choisi, plutôt que sur tout le projet de données. Les politiques d’organisation et les contrôles plus fins continuent de s’appliquer. Autorisations BigQuery

Se connecter à Datarelix avec Google ne connecte pas un dataset BigQuery. Autorisez séparément cette connexion et vérifiez que la localisation du job correspond aux données interrogées.

Préciser un filtre de dates exploitable

Cet exemple suppose une table partitionnée sur la colonne order_date, de type DATE :

SELECT order_date, COUNT(*) AS paid_orders
FROM `example-project.sales.orders`
WHERE order_date >= DATE '2026-08-01'
  AND order_date < DATE '2026-09-01'
  AND status = 'paid'
GROUP BY order_date
ORDER BY order_date;

Un extrait pourrait afficher 40 commandes le 1er août et 55 le 2 août. Ces deux jours totalisent 95 commandes ; ce n’est pas le total mensuel. Les dates sans lignes correspondantes sont absentes : demandez une série calendaire complète si le graphique doit distinguer zéro commande et données manquantes. La période découle de la formulation de la question, comme le montre comment le text-to-SQL génère les requêtes : nommez-la explicitement.

Un filtre sur la colonne de partitionnement peut permettre à BigQuery d’ignorer des partitions. Une condition sur une autre date peut définir la bonne période métier sans réduire les partitions comme prévu. Faites examiner le filtre SQL si le coût ou l’obligation de filtrer les partitions est déterminant. Interroger les tables partitionnées

Une limite par requête n’est pas un budget global

Le connecteur BigQuery de Datarelix fixe maximum_bytes_billed à 10 GiB par requête. Ce contrôle s’applique au job, pas à la dépense mensuelle ni à l’ensemble des services Google Cloud. Les questions répétées et les actualisations de tableaux de bord créent d’autres jobs.

Avec la facturation à la demande, cette limite peut refuser une requête dont l’estimation dépasse le seuil. Un LIMIT sur les lignes renvoyées ne réduit pas généralement les octets parcourus. Examinez plutôt les colonnes sélectionnées et les filtres de partition. Contrôles de coût BigQuery

Les frais Google Cloud restent distincts de votre forfait Datarelix. Pour un projet facturé à la capacité, examinez les réservations et les frais de capacité avec le responsable ; les octets parcourus ne décrivent pas tout le coût.

Choisir l’identité avec le responsable de la source

La connexion Google identifie votre compte Datarelix ; l’autorisation BigQuery est une étape distincte. Avec OAuth, examinez l’identité autorisée et ses droits Google Cloud effectifs. Le périmètre de consentement et les droits IAM décrivent des contrôles différents ; le texte du consentement ne suffit pas à établir les données lisibles.

Une clé de compte de service constitue une autre méthode, avec un responsable et une procédure de rotation. L’impersonation dépend d’une identité configurée côté service hébergé ; se connecter avec gcloud sur votre ordinateur ne configure pas ce service. La référence BigQuery précise chaque mode.

Une connexion peut sélectionner plusieurs jeux de données autorisés. Confirmez leurs noms complets et une localisation de requête compatible. Une source accessible dans un autre projet n’est pas nécessairement disponible dans la région choisie pour le job.

Date de partition et date métier peuvent différer

Une commande passée le 31 août peut être chargée le 1er septembre. Un rapport par date de commande et un filtre d’ingestion portent alors sur des événements différents. Si la table exige un filtre de partition, l’analyste doit combiner une restriction de partition valide et la période métier attendue.

Sur une table partitionnée par order_date, l’exemple applique directement l’intervalle à cette colonne. Avec un partitionnement par ingestion, examinez plutôt la pseudo-colonne et le rythme de chargement. Un filtre d’ingestion trop étroit peut exclure des commandes arrivées tardivement mais appartenant à la période métier.

Datarelix découvre les métadonnées de partition pour aider à former les requêtes. Vérifiez le prédicat généré et relancez la découverte si les métadonnées pertinentes changent. Elles ne garantissent pas les bonnes bornes ni l’élimination de partitions pour chaque requête. Filtres de partition BigQuery

Interpréter les lignes après jointure ou développement

Les champs répétés BigQuery peuvent contenir plusieurs articles dans une commande. Leur développement avec UNNEST change le nombre de lignes. Si le total de commande apparaît sur chaque ligne développée, sa somme multiplie la contribution de la commande. Comptez les identifiants distincts pour un nombre de commandes, ou additionnez les montants au niveau article pour une mesure d’articles.

BigQuery ne fait pas respecter les clés primaires et étrangères déclarées. Vérifiez les données avant de vous appuyer sur la relation et examinez les jointures déduites en l’absence de clé. Une description utile précise le sens d’une ligne et la présence possible de plusieurs enfants ; conservez ces notes comme contexte du schéma et définitions métier. Contraintes de clés BigQuery

Côté métier, précisez si « commandes » désigne commandes, articles ou expéditions. Côté analyste, examinez jointure ou UNNEST et rapprochez un sous-total connu. Le guide de vérification montre pourquoi le nombre de lignes final ne révèle pas toutes les duplications.

Examiner le travail réellement exécuté pendant l’essai

Gardez quelques questions représentatives : décompte journalier, total mensuel, ventilation et jointure du reporting habituel. Notez les informations de job accessibles au responsable du projet avec le résultat. Comparez les mêmes périodes pour évaluer l’effet d’une sélection de colonnes ou d’un filtre de partition adapté.

Le responsable examine le travail global avec les contrôles de requêtes et la facturation du projet. Une question réussie sous la limite par job ne décrit pas un mois de questions, de corrections et d’actualisations. Séparez calcul BigQuery, abonnement Datarelix et quotas d’usage.

Produire un livrable pour le métier et l’analyse

Pour une investigation, conservez SQL, résultat vérifié et période exacte. Pour un graphique récurrent, décidez si les dates évoluent à chaque actualisation et comment représenter les jours absents. Si la source reçoit des enregistrements tardifs, notez la date d’extraction afin de préciser quand la réponse était à jour.

Un graphique exporté pour un collègue est un instantané. Gardez mesure, source et période dans le titre ou les notes. L’analyste conserve le SQL pour le rapprochement ; l’utilisateur métier réutilise le graphique vérifié via le tableau de bord sans reconstruire l’analyse à chaque fois.

Vérifier et réutiliser le rapport

Comparez une courte période avec un nombre de commandes connu. Vérifiez le sens du statut « paid » et assurez-vous qu’une ligne représente une commande avant d’utiliser COUNT(*). Une table avec une ligne par article de commande demande un autre calcul.

Demandez une courbe, puis ajoutez le résultat vérifié à un tableau de bord privé. L’actualisation manuelle relance la requête enregistrée ; des dates fixes continueront à viser août. Le guide des tableaux de bord décrit le parcours complet.