4
votes

Répertorier les requêtes planifiées dans BigQuery

J'ai besoin d'analyser (par programme) les détails des requêtes planifiées dans BigQuery (par exemple, quelles tables sont mises à jour et quelles tables accédées dans le SQL). J'ai fait quelque chose de similaire pour les tables / vues BQ en utilisant Apps Script BigQuery.Tables.list () , mais je ne trouve pas d'API pour accéder aux requêtes planifiées.

L'interface utilisateur est capable de les lister, donc je pense que cela devrait être possible par programme, par exemple via une API REST. Quelqu'un sait-il si cela est possible, quelle interface est prise en charge (Apps Script, REST ...), et éventuellement un exemple de son utilisation.


3 commentaires

Ce n'est pas parce que quelque chose peut être fait dans l'interface utilisateur d'un produit Google que Google expose cette fonctionnalité au public par programmation.


Est-ce cloud.google.com/bigquery/docs/reference/ reste / v2 / jobs / list -il?


J'ai regardé Jobs: list , mais il semble que ce soit pour interroger les travaux qui ont été des problèmes mais pas encore démarrés (en attente), les travaux en cours d'exécution et les travaux terminés. Je ne pense pas qu'il dispose d'informations sur les requêtes planifiées ... pas avant qu'il ne soit déclenché et ne devienne un travail


3 Réponses :


7
votes

Les requêtes planifiées font partie du service de transfert de données de BigQuery, vous devez donc utiliser son API. En particulier, les projects.transferConfigs. list méthode. Remplissez le champ dataSourceIds avec plan_source et parent avec projects / PROJECT_ID . Comme indiqué dans les commentaires, si vous utilisez un emplacement régional tel que europe-west2 au lieu d'un emplacement multirégional (UE ou États-Unis), vous devez utiliser projects.locations.transferConfigs.list à la place. Désormais, la ressource parent sera sous la forme de projects / PROJECT_ID / locations / REGIONAL_LOCATION .

De plus, pour les autres transferts, vous pouvez obtenir les dataSourceIds correspondants en utilisant le projects.dataSources.list méthode. C'est comme ça que j'ai eu la planifiée_query .

La réponse sera un tableau de requêtes planifiées telles que:

#!/bin/bash

# parameter(s)
location=europe-west2

authToken="$(gcloud auth print-access-token)"
projectId=$(gcloud config get-value project 2>\dev\null)

# API call
scheduled_queries=$(curl  -H "Authorization: Bearer $authToken" \
https://bigquerydatatransfer.googleapis.com/v1/projects/$projectId/locations/$location/transferConfigs?dataSourceIds=scheduled_query)

# pretty print results
echo $scheduled_queries | python -m json.tool

Exemple d'appel d'API avec bash et curl :

{
  "name": "projects/<PROJECT_NUMBER>/locations/us/transferConfigs/<TRANSFER_CONFIG_ID>",
  "destinationDatasetId": "<DATASET>",
  "displayName": "hacker-news",
  "updateTime": "2018-11-14T15:39:18.897911Z",
  "dataSourceId": "scheduled_query",
  "schedule": "every 24 hours",
  "nextRunTime": "2019-04-19T15:39:00Z",
  "params": {
    "write_disposition": "WRITE_APPEND",
    "query": "SELECT @run_time AS time,\n  title,\n  author,\n  text\nFROM `bigquery-public-data.hacker_news.stories`\nLIMIT\n  1000",
    "destination_table_name_template": "hacker_daily_news"
  },
  "state": "SUCCEEDED",
  "userId": "<USER_ID>",
  "datasetRegion": "us"
}


4 commentaires

Merci, cela semble plus prometteur, l'utilisation du volet 'TRY API' sur la page projects.dataSources.list donne les résultats attendus, y compris une source de données de projects / my_project / dataSources / planifié_query . Cependant, faire de même pour projects.transferConfigs.list renvoie des résultats vides, mais je sais qu'il existe des dizaines de requêtes planifiées dans Big Query. Je pense qu'il peut encore y avoir une lacune dans ma compréhension.


Il est probable que vous utilisiez un emplacement régional tel que europe-west2 au lieu d'une multirégionale ( EU ou US ). Si tel est le cas, vous devez utiliser < code> projects.locations.transferConfigs.list à la place. Désormais, la ressource parent sera projects / PROJECT_ID / locations / REGIONAL_LOCATION .


Woo hoo, c'est l'information qui me manquait. J'ai maintenant une liste complète de toutes les requêtes planifiées pour le projet BQ que j'utilise. Merci beaucoup, m'a sauvé des heures de copie manuelle (sujette aux erreurs) à partir de l'écran!


Cool, heureux de vous aider! n'hésitez pas à accepter la réponse pour marquer le problème comme résolu.



0
votes

Voici un script shell qui vous avertira dans Slack si l'une de vos requêtes planifiées échoue. Intégrez simplement à votre flux de travail existant (comme bloquant ou non bloquant) ou ayez-le sur un travail Cron séparé. J'ai utilisé httpie pour envoyer mon message HTTP mais vous pouvez également utiliser curl ou autres. Vous pouvez également modifier votre publication HTTP pour toute autre action.

Voir lien pour les états potentiels de l'objet d'état de transfert

echo $PROD_KEY >> temp_json.json
bash gcloud auth activate-service-account --key-file=temp_json.json --project=$PROJ_NAME_PROD

Si vous exécutez en dehors du cloud ou sur quelque chose qui n'a pas déjà été authentifié, vous devrez authentifier au préalable. Pour ce faire, utilisez avant ce qui précède:

#1/bin/bash

sudo apt-get install httpie

location=US
authToken="$(gcloud auth print-access-token)"
projectId=$(gcloud config get-value project 2>\dev\null)

scheduled_queries=$(curl  -H "Authorization: Bearer $authToken" https://bigquerydatatransfer.googleapis.com/v1/projects/$projectId/locations/$location/transferConfigs?dataSourceIds=scheduled_query)

# pretty print results
echo $scheduled_queries | python -m json.tool

length=$(echo "$scheduled_queries" | grep FAILED)
if [ $length -gt 0 ]; then
    echo A SCHEDULED TRANSFER HAS FAILED
    http POST https://hooks.slack.com/services/<your slack channel> text="A SCHEDULED TRANSFER HAS FAILED: HERE IS STDOUT  >>> $scheduled_queries"

else
    echo No errors in scheduled transfers
fi

où $ PROD_KEY est la clé de service pour tout ce que vous essayez d'accéder.


0 commentaires

2
votes

Les réponses ci-dessus sont d'excellentes réponses pour l'utilisation de l'API REST. Pour être complet, j'aimerais inclure l'approche des commandes CLI pour résoudre la même chose. Personnellement, je trouve cela mieux adapté aux scripts shell mais à YMMV.

Exemple: Liste des requêtes de planification du projet par défaut.

bq show --format=prettyjson --transfer_config [RESOURCE_NAME]
# RESOURCE_NAME is a value you can get from the above bq ls command.

Exemple: Détails d'une requête de planification à partir du projet par défaut .

bq ls --transfer_config --transfer_location=US --format=prettyjson

Plus de détails peut être trouvé ici.


0 commentaires