Présentation des tables externes

Ce document explique comment utiliser des données stockées en dehors de BigQuery dans des tables externes. Pour travailler avec des sources de données externes, vous pouvez également utiliser des ensembles de données externes.

Les tables externes non BigLake vous permettent d'interroger des données structurées dans des data stores externes. Pour interroger une table externe non BigLake, vous devez disposer d'autorisations sur la table externe et la source de données externe. Par exemple, pour interroger une table externe autre que BigLake qui utilise une source de données dans Cloud Storage, vous devez disposer des autorisations suivantes :

  • bigquery.tables.getData
  • bigquery.jobs.create
  • storage.buckets.get
  • storage.objects.get

Data stores compatibles

Vous pouvez utiliser des tables externes autres que BigLake avec les datastores suivants :

Compatibilité avec les tables temporaires

Vous pouvez interroger une source de données externe dans BigQuery à l'aide d'une table permanente ou d'une table temporaire. Une table permanente est une table créée dans un ensemble de données et liée à votre source de données externe. La table étant permanente, vous pouvez utiliser des contrôles d'accès au niveau de l'ensemble de données pour la partager avec d'autres utilisateurs ayant également accès à la source de données externe sous-jacente. Vous avez par ailleurs la possibilité d'interroger la table à tout moment.

Lorsque vous interrogez une source de données externe à l'aide d'une table temporaire, vous exécutez une commande qui inclut une requête et crée une table non permanente associée à la source de données externe. En cas d'utilisation d'une table temporaire, vous ne créez pas de table dans l'un de vos ensembles de données BigQuery. La table n'étant pas stockée de manière permanente dans un ensemble de données, elle ne peut pas être partagée avec d'autres utilisateurs. L'interrogation d'une source de données externe à l'aide d'une table temporaire est utile pour les requêtes ad hoc ponctuelles qui sont exécutées sur des données externes ou pour les processus d'extraction, de transformation et de chargement (ETL, Extract-Transform-Load).

Plusieurs fichiers sources

Si vous créez une table externe autre que BigLake basée sur Cloud Storage, vous pouvez utiliser plusieurs sources de données externes, à condition que ces sources aient le même schéma. Cette option n'est pas disponible pour les tables externes non-BigLake basées sur Bigtable ou Google Drive.

Limites

Les limites suivantes s'appliquent aux tables externes :

  • BigQuery ne garantit pas la cohérence des données des sources de données externes. Les modifications apportées aux données sous-jacentes lors de l'exécution d'une requête peuvent entraîner un comportement inattendu.
  • Les performances des requêtes portant sur des tables externes peuvent être ralenties par rapport aux requêtes sur des données dans une table BigQuery standard. Si la vitesse d'exécution des requêtes est une priorité, chargez les données dans BigQuery au lieu de configurer une source de données externe. Les performances d'une requête portant sur une table externe dépendent du type de stockage externe. Par exemple, interroger des données stockées dans Cloud Storage est plus rapide qu'interroger des données stockées dans Google Drive. Les performances des requêtes pour une table externe sont généralement équivalentes à celles de la lecture directe de données depuis la source de données.
  • Vous ne pouvez pas modifier des tables de données externes à l'aide du langage LMD ou d'autres méthodes. Les tables externes sont en lecture seule pour BigQuery.
  • Vous ne pouvez pas utiliser la méthode de l'API JSON TableDataList pour extraire des données de tables externes. Pour en savoir plus, consultez la page sur la méthode tabledata.list. Pour contourner cette limitation, vous pouvez enregistrer les résultats de la requête dans une table de destination. La méthode TableDataList peut ensuite être utilisée sur la table de résultats.
  • Vous ne pouvez pas exécuter une tâche BigQuery qui exporte des données depuis une table externe. Pour contourner cette limitation, vous pouvez enregistrer les résultats de la requête dans une table de destination. Exécutez ensuite un job d'exportation sur la table de résultats.
  • Il n'est pas possible de référencer une table externe dans une requête de table générique.
  • Les tables externes ne sont pas compatibles avec le clustering. Elles sont compatibles de façon limitée avec le partitionnement. Pour en savoir plus, consultez la section Interroger des données partitionnées en externe.
  • Lorsque vous interrogez une source de données externe autre que Cloud Storage, les résultats ne sont pas mis en cache. (Les requêtes GoogleSQL sur Cloud Storage sont compatibles.) Chaque requête effectuée sur une table externe vous est facturée, même si vous lancez plusieurs fois la même requête. Si vous devez effectuer une même requête à plusieurs reprises sur une table externe qui ne change pas fréquemment, envisagez plutôt d'écrire les résultats de la requête dans une table permanente et d'exécuter les requêtes sur cette table.
  • Il est possible d'exécuter un maximum de quatre requêtes simultanées sur une source de données externe Bigtable.
  • La simulation d'une requête fédérée utilisant une table externe peut indiquer une limite inférieure de 0 octet de données, même si des lignes sont renvoyées. En effet, il est impossible de déterminer la quantité de données traitées à partir de la table externe tant que la requête n'est pas terminée. L'exécution de la requête fédérée entraîne des frais pour le traitement de ces données.
  • Vous ne pouvez pas utiliser _object_metadata comme nom de colonne dans les tables externes. Il est réservé à un usage interne.
  • BigQuery n'est pas compatible avec l'affichage des statistiques de stockage de tables pour les tables externes.
  • Les tables externes ne sont pas compatibles avec les noms de colonnes flexibles.

Considérations relatives aux emplacements

Lorsque vous choisissez un emplacement pour votre table externe, vous devez tenir compte à la fois de l'emplacement de l'ensemble de données BigQuery et de la source de données externe.

Cloud Storage

Lorsque vous interrogez des données dans Cloud Storage à l'aide d'une BigLake ou non BigLake, le bucket doit être cohébergé avec votre ensemble de données BigQuery contenant la définition de la table externe. Exemple :

  • Buckets régionaux uniques

    Si votre bucket Cloud Storage se trouve dans la région us-central1 (Iowa), votre ensemble de données BigQuery doit se trouver dans la région us-central1 (Iowa) ou dans la multirégion US.

    Si votre bucket Cloud Storage se trouve dans la région europe-west4 (Pays-Bas), votre ensemble de données BigQuery doit se trouver dans la région europe-west4 (Pays-Bas) ou dans l'emplacement multirégional EU.

    Si votre bucket Cloud Storage se trouve dans la région europe-west1 (Belgique), l'ensemble de données BigQuery correspondant doit également se trouver dans la région europe-west1 (Belgique).

  • Buckets birégionaux

    Si votre bucket Cloud Storage se trouve dans la zone birégionale NAM4 prédéfinie ou dans une zone birégionale configurable qui inclut la région us-central1 (Iowa), l'ensemble de données BigQuery correspondant doit se trouver dans la région us-central1 (Iowa) ou dans la zone multirégionale US.

    Si votre bucket Cloud Storage se trouve dans la zone birégionale EUR4 prédéfinie ou dans une zone birégionale configurable incluant la région europe-west4 (Pays-Bas), l'ensemble de données BigQuery correspondant doit se trouver dans la région europe-west4 (Pays-Bas) ou dans la zone multirégionale EU.

    Si votre bucket Cloud Storage se trouve dans la zone birégionale ASIA1 prédéfinie, l'ensemble de données BigQuery correspondant doit se trouver dans la région asia-northeast1 (Tokyo) ou asia-northeast2 (Osaka).

    Si votre bucket Cloud Storage utilise une zone birégionale configurable qui inclut les régions australia-southeast1 (Sydney) et australia-southeast2 (Melbourne), le bucket BigQuery correspondant doit se trouver dans la région australia-southeast1 (Sydney) ou australia-southeast2 (Melbourne).

  • Buckets multirégionaux

    L'utilisation d'emplacements d'ensembles de données multirégionaux avec des buckets Cloud Storage multirégionaux n'est pas recommandée pour les tables externes, car les performances des requêtes externes dépendent d'une latence minimale et d'une bande passante réseau optimale.

    Si votre ensemble de données BigQuery se trouve dans la zone multirégionale US, le bucket Cloud Storage correspondant doit se trouver dans la zone multirégionale US, dans une zone birégionale qui inclut us-central1 (Iowa), par exemple la zone birégionale NAM4, ou dans une zone birégionale configurable qui inclut us-central1.

    Si votre ensemble de données BigQuery se trouve dans la zone multirégionale EU, le bucket Cloud Storage correspondant doit se trouver dans la zone multirégionale EU, dans une zone birégionale qui inclut europe-west4 (Pays-Bas), par exemple la zone birégionale EUR4, ou dans une zone birégionale configurable qui inclut europe-west4.

Pour en savoir plus sur les emplacements Cloud Storage, consultez la section Emplacements des buckets dans la documentation de Cloud Storage.

Bigtable

Lorsque vous interrogez des données dans Bigtable via une table externe BigQuery, votre instance Bigtable doit se trouver au même emplacement que votre ensemble de données BigQuery:

  • Région unique : si votre ensemble de données BigQuery se trouve dans la région régionale Belgique (europe-west1), l'instance Bigtable correspondante doit se trouver dans la région Belgique.
  • Multirégional : les performances des requêtes externes dépendent d'une latence minimale et d'une bande passante réseau optimale. Il n'est donc pas recommandé d'utiliser des emplacements d'ensembles de données multirégionaux pour les tables externes sur Bigtable.

Pour en savoir plus sur les emplacements Bigtable compatibles, consultez la page Emplacements Bigtable.

Google Drive

Les considérations concernant les emplacements ne s'appliquent pas aux sources de données externes Google Drive.

Gestion des données

Élaborez un plan de gestion des données :
  • Si vous choisissez une ressource de stockage régionale, telle qu'un ensemble de données BigQuery ou un bucket Cloud Storage, élaborez un plan de gestion géographique des données.

Déplacer des données entre des emplacements

Pour déplacer manuellement un ensemble de données d'un emplacement à un autre, procédez comme suit :

  1. Exportez les données de vos tables BigQuery vers un bucket Cloud Storage situé dans le même emplacement que votre ensemble de données ou dans un emplacement contenu dans l'emplacement de votre ensemble de données. Par exemple, si votre ensemble de données se trouve dans l'emplacement multirégional EU, vous pouvez exporter vos données vers l'emplacement europe-west1 en Belgique, qui fait partie de l'UE.

    L'exportation de données depuis BigQuery est gratuite, mais vous engagez des frais pour le stockage des données exportées dans Cloud Storage. Les exportations BigQuery sont soumises aux limites applicables aux jobs d'exportation.

  2. Copiez ou déplacez les données de votre bucket Cloud Storage d'exportation vers un nouveau bucket que vous avez créé dans l'emplacement de destination. Par exemple, si vous déplacez vos données de l'emplacement multirégional US vers la région asia-northeast1 de Tokyo, vous les transférez vers un bucket que vous avez créé à Tokyo. Pour en savoir plus sur le transfert d'objets Cloud Storage, consultez la page Renommer, copier et déplacer des objets de la documentation Cloud Storage.

    Le transfert de données entre régions entraîne des frais de sortie réseau dans Cloud Storage.

  3. Créez un ensemble de données BigQuery au nouvel emplacement, puis chargez vos données à partir du bucket Cloud Storage dans le nouvel ensemble de données.

    Le chargement des données dans BigQuery est gratuit, mais vous devrez payer des frais pour le stockage des données dans Cloud Storage jusqu'à ce que vous supprimiez les données ou le bucket. Le stockage des données dans BigQuery après leur chargement vous est également facturé. Le chargement de données dans BigQuery est soumis aux limites des jobs de chargement.

Vous pouvez également utiliser Cloud Composer pour déplacer et copier automatiquement des ensembles de données volumineux.

Pour en savoir plus sur le stockage de données à l'aide de Cloud Storage, consultez la section Utiliser Cloud Storage avec Big Data.

Tarifs

Lorsque vous interrogez une table externe à partir de BigQuery, vous êtes facturé pour l'exécution de la requête et les octets lus applicables si vous utilisez la tarification à la demande de BigQuery (par Tio), ou pour la consommation d'emplacement si vous utilisez la tarification basée sur la capacité de BigQuery (par emplacement et par heure).

Si vos données sont stockées dans ORC ou Parquet sur Cloud Storage, consultez la section Calcul de la taille des données.

Le stockage des données et toute ressource utilisée par l'application source vous sont également facturés, selon les règles de tarification de l'application :

  • Pour en savoir plus sur les tarifs de Cloud Storage, consultez la page Tarifs de Cloud Storage.
  • Pour en savoir plus sur les tarifs Bigtable, consultez la section Tarifs.
  • Pour en savoir plus sur les tarifs de Drive, consultez la section Tarifs.

Étapes suivantes