Vue WRITE_API_TIMELINE

La vue INFORMATION_SCHEMA.WRITE_API_TIMELINE contient les statistiques d'ingestion de l'API BigQuery Storage Write agrégées par minute pour le projet en cours.

Vous pouvez interroger les vues de l'API INFORMATION_SCHEMA Write pour récupérer des informations historiques et en temps réel sur l'ingestion de données dans BigQuery à l'aide de l'API BigQuery Storage Write. Pour en savoir plus, consultez la page API BigQuery Storage Write.

Autorisation requise

Pour interroger la vue INFORMATION_SCHEMA.WRITE_API_TIMELINE, vous devez disposer de l'autorisation IAM (Identity and Access Management) bigquery.tables.list pour le projet.

Chacun des rôles IAM prédéfinis suivants inclut l'autorisation requise:

• roles/bigquery.user
• roles/bigquery.dataViewer
• roles/bigquery.dataEditor
• roles/bigquery.dataOwner
• roles/bigquery.metadataViewer
• roles/bigquery.resourceAdmin
• roles/bigquery.admin

Attention : L'autorisation "bigquery.tables.list" requise n'est pas incluse dans les rôles de base Propriétaire ou Éditeur.

Pour plus d'informations sur les autorisations BigQuery, consultez la page Contrôle des accès avec IAM.

Schéma

Lorsque vous interrogez les vues de l'API BigQuery Storage Write INFORMATION_SCHEMA, les résultats de la requête contiennent des informations historiques et en temps réel sur l'ingestion de données dans BigQuery à l'aide de l'API BigQuery Storage Write. Chaque ligne des vues suivantes représente les statistiques d'ingestion dans une table spécifique, regroupées sur un intervalle d'une minute à partir de start_timestamp. Les statistiques sont regroupées par type de flux et par code d'erreur. Par conséquent, il existe une ligne pour chaque type de flux et chaque code d'erreur rencontré au cours de l'intervalle d'une minute pour chaque combinaison d'horodatage et de table. Le code d'erreur des requêtes réussies est défini sur OK. Si aucune donnée n'a été transmise à une table au cours d'une période donnée, aucune ligne n'est présente pour les horodatages correspondants de cette table.

Les vues INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_* présentent le schéma suivant:

Nom de la colonne	Type de données	Valeur
start_timestamp	TIMESTAMP	(Colonne de partitionnement) Horodatage de début de l'intervalle d'une minute pour les statistiques agrégées
project_id	STRING	(Colonne de clustering) ID du projet.
project_number	INTEGER	Numéro du projet
dataset_id	STRING	(Colonne de clustering) ID de l'ensemble de données
table_id	STRING	(Colonne de clustering) ID de la table
stream_type	STRING	Type de flux utilisé pour l'ingestion de données avec l'API BigQuery Storage Write. La valeur doit être "DEFAULT", "COMMITTED", "BUFFERED" ou "PENDING".
error_code	STRING	Code d'erreur renvoyé pour les requêtes spécifiées par cette ligne "OK" pour les requêtes réussies.
total_requests	INTEGER	Nombre total de requêtes dans l'intervalle d'une minute
total_rows	INTEGER	Nombre total de lignes de toutes les requêtes dans l'intervalle d'une minute
total_input_bytes	INTEGER	Nombre total d'octets de toutes les lignes dans l'intervalle d'une minute

Conservation des données

Cette vue contient l'historique d'ingestion de l'API BigQuery Storage Write des 180 derniers jours.

Champ d'application et syntaxe

Les requêtes exécutées sur cette vue doivent inclure un qualificatif de région. Si vous ne spécifiez pas de qualificatif de région, les métadonnées sont extraites de toutes les régions. Le tableau suivant explique le champ d'application de la région pour cette vue :

Nom de la vue	Champ d'application de la ressource	Champ d'application de la région
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.WRITE_API_TIMELINE[_BY_PROJECT]	Niveau Projet	REGION

Remplacez les éléments suivants :

• Facultatif : PROJECT_ID : ID de votre projet Google Cloud. Si non spécifié, le projet par défaut est utilisé.

 + REGION : nom de la région de l'ensemble de données. Par exemple, region-us.

Remarque : Vous devez utiliser un qualificatif de région pour interroger les vues INFORMATION_SCHEMA. L'emplacement d'exécution de la requête doit correspondre à la région de la vue INFORMATION_SCHEMA.

Exemple

• Pour interroger des données dans l'emplacement multirégional "US", utilisez `region-us`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT.
• Pour interroger des données dans l'emplacement multirégional "EU", utilisez `region-eu`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT.
• Pour interroger des données dans la région asia-northeast1, utilisez `region-asia-northeast1`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT.

Pour obtenir la liste des régions disponibles, consultez la section Emplacements des ensembles de données.

Exemples

Exemple 1 : Échecs récents d'ingestion de l'API BigQuery Storage Write

L'exemple suivant calcule la répartition par minute du nombre total de requêtes ayant échoué pour toutes les tables du projet au cours des 30 dernières minutes, par type de flux et par code d'erreur :

SELECT
  start_timestamp,
  stream_type,
  error_code,
  SUM(total_requests) AS num_failed_requests
FROM
  `region-us`.INFORMATION_SCHEMA.WRITE_API_TIMELINE
WHERE
  error_code != 'OK'
  AND start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 30 MINUTE)
GROUP BY
  start_timestamp,
  stream_type,
  error_code
ORDER BY
  start_timestamp DESC;

Remarque : Les noms des vues INFORMATION_SCHEMA sont sensibles à la casse.

Le résultat ressemble à ce qui suit :

+---------------------+-------------+------------------+---------------------+
|   start_timestamp   | stream_type |    error_code    | num_failed_requests |
+---------------------+-------------+------------------+---------------------+
| 2023-02-24 00:25:00 | PENDING     | NOT_FOUND        |                   5 |
| 2023-02-24 00:25:00 | DEFAULT     | INVALID_ARGUMENT |                   1 |
| 2023-02-24 00:25:00 | DEFAULT     | DEADLINE_EXCEEDED|                   4 |
| 2023-02-24 00:24:00 | PENDING     | INTERNAL         |                   3 |
| 2023-02-24 00:24:00 | DEFAULT     | INVALID_ARGUMENT |                   1 |
| 2023-02-24 00:24:00 | DEFAULT     | DEADLINE_EXCEEDED|                   2 |
+---------------------+-------------+------------------+---------------------+

Exemple 2 : Répartition par minute pour toutes les requêtes avec codes d'erreur

L'exemple suivant calcule une répartition par minute des requêtes d'ajout ayant réussi ou échoué, regroupées par catégorie de code d'erreur. Cette requête peut être utilisée pour renseigner un tableau de bord.

SELECT
  start_timestamp,
  SUM(total_requests) AS total_requests,
  SUM(total_rows) AS total_rows,
  SUM(total_input_bytes) AS total_input_bytes,
  SUM(
    IF(
      error_code IN (
        'INVALID_ARGUMENT', 'NOT_FOUND', 'CANCELLED', 'RESOURCE_EXHAUSTED',
        'ALREADY_EXISTS', 'PERMISSION_DENIED', 'UNAUTHENTICATED',
        'FAILED_PRECONDITION', 'OUT_OF_RANGE'),
      total_requests,
      0)) AS user_error,
  SUM(
    IF(
      error_code IN (
        'DEADLINE_EXCEEDED','ABORTED', 'INTERNAL', 'UNAVAILABLE',
        'DATA_LOSS', 'UNKNOWN'),
      total_requests,
      0)) AS server_error,
  SUM(IF(error_code = 'OK', 0, total_requests)) AS total_error,
FROM
  `region-us`.INFORMATION_SCHEMA.WRITE_API_TIMELINE
GROUP BY
  start_timestamp
ORDER BY
  start_timestamp DESC;

Remarque : Les noms des vues INFORMATION_SCHEMA sont sensibles à la casse.

Le résultat ressemble à ce qui suit :

+---------------------+----------------+------------+-------------------+------------+--------------+-------------+
|   start_timestamp   | total_requests | total_rows | total_input_bytes | user_error | server_error | total_error |
+---------------------+----------------+------------+-------------------+------------+--------------+-------------+
| 2020-04-15 22:00:00 |         441854 |     441854 |       23784853118 |          0 |           17 |          17 |
| 2020-04-15 21:59:00 |         355627 |     355627 |       26101982742 |          8 |            0 |          13 |
| 2020-04-15 21:58:00 |         354603 |     354603 |       26160565341 |          0 |            0 |           0 |
| 2020-04-15 21:57:00 |         298823 |     298823 |       23877821442 |          2 |            0 |           2 |
+---------------------+----------------+------------+-------------------+------------+--------------+-------------+

Exemple 3 : Tables avec le plus de trafic entrant

L'exemple suivant renvoie les statistiques d'ingestion de l'API BigQuery Storage Write pour les 10 tables avec le plus de trafic entrant :

SELECT
  project_id,
  dataset_id,
  table_id,
  SUM(total_rows) AS num_rows,
  SUM(total_input_bytes) AS num_bytes,
  SUM(total_requests) AS num_requests
FROM
  `region-us`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT
GROUP BY
  project_id,
  dataset_id,
  table_id
ORDER BY
  num_bytes DESC
LIMIT 10;

Remarque : Les noms des vues INFORMATION_SCHEMA sont sensibles à la casse.

Le résultat ressemble à ce qui suit :

+----------------------+------------+-------------------------------+------------+----------------+--------------+
|      project_id      | dataset_id |           table_id            |  num_rows  |   num_bytes    | num_requests |
+----------------------+------------+-------------------------------+------------+----------------+--------------+
| my-project           | dataset1   | table1                        | 8016725532 | 73787301876979 |   8016725532 |
| my-project           | dataset1   | table2                        |   26319580 | 34199853725409 |     26319580 |
| my-project           | dataset2   | table1                        |   38355294 | 22879180658120 |     38355294 |
| my-project           | dataset1   | table3                        |  270126906 | 17594235226765 |    270126906 |
| my-project           | dataset2   | table2                        |   95511309 | 17376036299631 |     95511309 |
| my-project           | dataset2   | table3                        |   46500443 | 12834920497777 |     46500443 |
| my-project           | dataset2   | table4                        |   25846270 |  7487917957360 |     25846270 |
| my-project           | dataset1   | table4                        |   18318404 |  5665113765882 |     18318404 |
| my-project           | dataset1   | table5                        |   42829431 |  5343969665771 |     42829431 |
| my-project           | dataset1   | table6                        |    8771021 |  5119004622353 |      8771021 |
+----------------------+------------+-------------------------------+------------+----------------+--------------+

Exemple 4 : Taux d'erreur d'ingestion de l'API BigQuery Storage Write pour une table

L'exemple suivant calcule une répartition quotidienne des erreurs pour une table spécifique, divisée par code d'erreur :

SELECT
  TIMESTAMP_TRUNC(start_timestamp, DAY) as day,
  project_id,
  dataset_id,
  table_id,
  error_code,
  SUM(total_rows) AS num_rows,
  SUM(total_input_bytes) AS num_bytes,
  SUM(total_requests) AS num_requests
FROM
  `region-us`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT
WHERE
  table_id LIKE 'my_table'
GROUP BY
  project_id, dataset_id, table_id, error_code, day
ORDER BY
  day, project_id, dataset_id DESC;

Remarque : Les noms des vues INFORMATION_SCHEMA sont sensibles à la casse.

Le résultat ressemble à ce qui suit :

+---------------------+-------------+------------+----------+----------------+----------+-----------+--------------+
|         day         |  project_id | dataset_id | table_id |   error_code   | num_rows | num_bytes | num_requests |
+---------------------+-------------+------------+----------+----------------+----------+-----------+--------------+
| 2020-04-21 00:00:00 | my_project  | my_dataset | my_table | OK             |       41 |    252893 |           41 |
| 2020-04-20 00:00:00 | my_project  | my_dataset | my_table | OK             |     2798 |  10688286 |         2798 |
| 2020-04-19 00:00:00 | my_project  | my_dataset | my_table | OK             |     2005 |   7979495 |         2005 |
| 2020-04-18 00:00:00 | my_project  | my_dataset | my_table | OK             |     2054 |   7972378 |         2054 |
| 2020-04-17 00:00:00 | my_project  | my_dataset | my_table | OK             |     2056 |   6978079 |         2056 |
| 2020-04-17 00:00:00 | my_project  | my_dataset | my_table | INTERNAL       |        4 |     10825 |            4 |
+---------------------+-------------+------------+----------+----------------+----------+-----------+--------------+