Présentation des tables BigLake

Ce document présente BigLake et suppose que vous maîtrisez les tables de base de données et Identity and Access Management (IAM). Pour interroger des données stockées dans les data stores compatibles, vous devez d'abord créer des tables BigLake, puis les interroger à l'aide de la syntaxe GoogleSQL :

Vous pouvez également mettre à niveau une table externe vers BigLake. Pour en savoir plus, consultez la page Mettre à niveau une table externe vers BigLake.

Les tables BigLake vous permettent d'interroger des données structurées dans des data stores externes avec délégation d'accès. La délégation d'accès dissocie l'accès à la table BigLake de l'accès au data store sous-jacent. Une connexion externe associée à un compte de service permet de se connecter au data store. Étant donné que le compte de service gère la récupération des données du data store, il vous suffit d'accorder aux utilisateurs l'accès à la table BigLake. Cela vous permet d'appliquer une sécurité précise au niveau de la table, y compris au niveau des lignes et des colonnes. Pour les tables BigLake basées sur Cloud Storage, vous pouvez également utiliser le masquage des données dynamiques. Pour en savoir plus sur les solutions analytiques multicloud utilisant des tables BigLake avec des données Amazon S3 ou Blob Storage, consultez la page BigQuery Omni.

Data stores compatibles

Vous pouvez utiliser les tables BigLake avec les data stores suivants :

Compatibilité avec les tables temporaires

Les tables BigLake basées sur Cloud Storage peuvent être temporaires ou permanentes. Les tables BigLake basées sur Amazon S3 ou Blob Storage doivent être permanentes.

Plusieurs fichiers sources

Vous pouvez créer une table BigLake basée sur plusieurs sources de données externes, à condition que ces sources de données possèdent le même schéma.

Jointures multi-cloud

Les jointures multicloud vous permettent d'exécuter des requêtes couvrant à la fois Google Cloud et les régions BigQuery Omni. Vous pouvez utiliser des opérations Google SQL JOIN pour analyser des données sur de nombreuses solutions de stockage différentes, telles qu'AWS, Azure, des ensembles de données publics et d'autres services Google Cloud. Les jointures multicloud éliminent le besoin de copier des données sur plusieurs sources avant d'exécuter des requêtes.

Vous pouvez référencer des tables BigLake n'importe où dans une instruction SELECT comme s'il s'agissait de tables BigQuery standards, y compris dans des instructions LMD (langage de manipulation de données) et LDD (langage de définition de données) qui utilisent des sous-requêtes pour récupérer des données. Vous pouvez utiliser plusieurs tables BigLake provenant de différents clouds et de différentes tables BigQuery dans la même requête. Toutes les tables BigQuery doivent se trouver dans la même région.

Autorisations requises pour exécuter une jointure multicloud

Pour obtenir les autorisations nécessaires pour exécuter une jointure multicloud, demandez à votre administrateur de vous accorder le rôle IAM Éditeur de données BigQuery (roles/bigquery.dataEditor) sur le projet dans lequel la jointure est exécutée. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour exécuter une jointure multicloud. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour exécuter une jointure multicloud :

  • bigquery.datasets.create
  • bigquery.tables.create

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Les jointures inter-cloud créent des ensembles de données avec le préfixe __bigquery_xregion_sink_ et des tables temporaires au sein de ces ensembles de données. Par conséquent, pour n'accorder l'accès qu'aux ressources créées par les jointures multicloud, utilisez resource.name.startsWith pour les types de ressources Table et Dataset.

Pour plus d'informations sur les rôles et les autorisations IAM dans BigQuery, consultez la page Présentation d'IAM.

Coûts de jointure multicloud

Lorsque vous exécutez une opération de jointure multicloud, BigQuery analyse la requête entre les parties locales et distantes. La partie locale est traitée comme une requête standard dans la région BigQuery. La partie distante est convertie en opération CREATE TABLE AS SELECT (CTAS) sur la table BigLake référencée dans la région BigQuery Omni, qui crée une table temporaire dans votre région BigQuery. BigQuery utilise ensuite cette table temporaire pour exécuter votre jointure multicloud et supprime automatiquement la table au bout de huit heures.

Des frais de transfert de données sont facturés pour les données des tables BigLake référencées. Cependant, BigQuery permet de réduire ces coûts en ne transférant que les colonnes et les lignes de la table BigLake référencées dans la requête, plutôt que la table entière. Nous vous recommandons de spécifier un filtre de colonne le plus restreint possible pour réduire davantage les coûts de transfert. Le job CTAS s'affiche dans l'historique des jobs avec des informations telles que le nombre d'octets transférés. Les transferts réussis entraînent des coûts même si le job de la requête principale échoue. Pour en savoir plus, consultez les Tarifs de BigQuery Omni.

Prenons la requête suivante comme exemple :

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

Cet exemple comporte deux transferts : un pour une table des employés (avec un filtre de niveau) et l'autre pour une table des employés actifs. La jointure est effectuée dans la région BigQuery après le transfert. Si un transfert échoue et que l'autre réussit, les frais de transfert de données sont tout de même appliqués pour le transfert réussi.

Limites des jointures multicloud

  • Les jointures multicloud ne sont pas disponibles dans la version sans frais de BigQuery ni dans le bac à sable BigQuery.
  • Les agrégations peuvent ne pas être transférées vers les régions BigQuery Omni si la requête contient des instructions JOIN.
  • Chaque table temporaire n'est utilisée que pour une seule requête multicloud et n'est pas réutilisée, même si la même requête est répétée plusieurs fois.
  • La taille maximale pour chaque transfert est de 60 Go. Plus précisément, si vous appliquez un filtre sur une table BigLake et que vous chargez le résultat, celui-ci doit être inférieur à 60 Go. Si nécessaire, vous pouvez demander une augmentation de limite de quota. Le nombre d'octets analysés n'est pas limité.
  • Les requêtes de jointure cloud à cloud utilisent un quota interne sur le taux de requêtes. Si le taux de requêtes dépasse le quota, vous pouvez recevoir une erreur All our servers are busy processing data transferred between regions. Une nouvelle tentative de la requête devrait fonctionner dans la plupart des cas. Contactez l'assistance pour augmenter le quota interne afin de pouvoir accepter un taux de requêtes plus élevé.
  • Les jointures multiclouds ne sont compatibles qu'avec les régions BigQuery colocalisées avec leurs régions BigQuery Omni correspondantes, ainsi que dans les emplacements multirégionaux US et EU. Les jointures multiclouds exécutées dans les emplacements multirégionaux US ou EU ne peuvent accéder qu'aux données des régions BigQuery Omni des États-Unis ou de l'UE, respectivement.
  • Si une requête de jointure cloud à cloud fait référence à 10 ensembles de données ou plus de régions BigQuery Omni, elle peut échouer avec l'erreur Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Pour éviter ce problème, nous vous recommandons de spécifier explicitement un emplacement lorsque vous exécutez une jointure multicloud qui fait référence à plus de dix ensembles de données. Sachez que si vous spécifiez explicitement une région BigQuery et que votre requête ne contient que des tables BigLake, votre requête est exécutée en tant que requête multicloud et entraîne des coûts de transfert de données.
  • Vous ne pouvez pas interroger la pseudo-colonne _FILE_NAME avec des jointures multicloud.
  • Lorsque vous référencez les colonnes d'une table BigLake dans une clause WHERE, vous ne pouvez pas utiliser les littéraux NUMERIC, BIGNUMERIC, BYTES, TIME, ou INTERVAL.
  • Les jobs de jointure cloud à cloud n'indiquent pas le nombre d'octets traités et transférés depuis d'autres clouds. Ces informations sont disponibles dans les jobs CTAS enfants créées lors de l'exécution de requêtes multicloud.
  • Les vues autorisées et les routines autorisées faisant référence à des tables ou à des vues BigQuery Omni ne sont disponibles que dans les régions BigQuery Omni.
  • Si votre requête cloud à cloud fait référence à des colonnes STRUCT ou JSON, aucun pushdown n'est appliqué aux sous-requêtes distantes. Pour optimiser les performances, envisagez de créer une vue dans la région BigQuery Omni qui filtre les colonnes STRUCT et JSON, et renvoie uniquement les champs nécessaires en tant que colonnes individuelles.
  • Les requêtes temporelles ne sont pas compatibles avec les jointures cloud à cloud.

Exemples de jointure multicloud

La requête suivante joint une table orders dans une région BigQuery à une table lineitem dans une région BigQuery Omni :

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Cette requête est divisée en parties locales et distantes. La requête suivante est envoyée à la région BigQuery Omni pour s'exécuter en premier. Il en résulte une table temporaire dans la région BigQuery. Vous pouvez afficher ce job CTAS enfant et ses métadonnées dans l'historique des jobs.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Une fois la table temporaire créée, l'opération JOIN se termine et la requête suivante est exécutée :

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Pour analyser un autre exemple, considérons la jointure multicloud suivante :

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
  SELECT c_mktsegment, c_name
  FROM aws_dataset.customer
  WHERE c_mktsegment = 'FURNITURE'
  LIMIT 10;

Dans cette requête, la clause LIMIT n'est pas transmise à la région BigQuery Omni. Tous les clients du segment de marché FURNITURE sont d'abord transférés vers la région BigQuery, puis la limite de dix est appliquée.

Connecteurs

Vous pouvez accéder aux données de tables BigLake basées sur Cloud Storage à partir d'autres outils de traitement de données à l'aide de connecteurs BigQuery. Par exemple, vous pouvez accéder aux données de tables BigLake à partir d'Apache Spark, d'Apache Hive, de TensorFlow, de Trino ou de Presto. L'API BigQuery Storage applique des règles de gouvernance au niveau des lignes et des colonnes sur tous les accès aux données des tables BigLake, y compris via des connecteurs.

Par exemple, le schéma suivant illustre comment l'API BigQuery Storage permet aux utilisateurs d'accéder aux données autorisées à l'aide de moteurs de requête Open Source tels qu'Apache Spark :

Architecture de BigLake.

Pour en savoir plus sur les connecteurs compatibles avec BigQuery, consultez la page Connecteurs BigQuery.

Tables BigLake sur des magasins d'objets

Pour les administrateurs de lacs de données, BigLake vous permet de définir des contrôles d'accès sur les tables plutôt que sur les fichiers, ce qui vous permet d'obtenir des options plus précises pour définir l'accès des utilisateurs aux données du lac de données.

Les tables BigLake simplifient le contrôle des accès de cette manière. Nous vous recommandons donc d'utiliser des tables BigLake pour créer et gérer les connexions aux espaces de stockage d'objets externes.

Vous pouvez utiliser des tables externes dans les cas où aucune gouvernance n'est requise, ou pour des activités ad hoc de découverte et de manipulation de données.

Limites

  • Toutes les limites des tables externes s'appliquent aux tables BigLake.
  • Les tables BigLake sur des magasins d'objets sont soumises aux mêmes limites que les tables BigQuery. Pour en savoir plus, consultez la page consacrée aux quotas.

  • BigLake n'est pas compatible avec les identifiants aux champs d'application limités dans l'authentification personnelle de cluster Dataproc. Pour contourner ce problème, afin d'utiliser des clusters avec l'authentification personnelle de cluster, vous devez injecter vos identifiants à l'aide d'une limite d'accès aux identifiants avec l'option --access-boundary=<(echo -n "{}"). Par exemple, la commande suivante active une session de propagation des identifiants dans un projet nommé myproject pour le cluster nommé mycluster : 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • Les tables BigLake sont en lecture seule. Vous ne pouvez pas les modifier à l'aide d'instructions LMD ou d'autres méthodes.

  • Les tables BigLake sont compatibles avec les formats suivants :

  • Vous ne pouvez pas utiliser les métadonnées mises en cache avec des tables BigLake Apache Iceberg. BigQuery utilise déjà les métadonnées capturées par Iceberg dans les fichiers manifestes.

  • L'API BigQuery Storage n'est pas disponible dans d'autres environnements cloud, tels qu'AWS et Azure.

  • Si vous utilisez des métadonnées mises en cache, les limites suivantes s'appliquent :

    • Vous ne pouvez utiliser des métadonnées mises en cache qu'avec des tables BigLake aux formats Avro, ORC, Parquet, JSON et CSV.
    • Si vous créez, mettez à jour ou supprimez des fichiers dans Amazon S3, l'interrogation des fichiers ne renvoie pas les données mises à jour avant la prochaine actualisation du cache de métadonnées. Cela peut entraîner des résultats inattendus. Par exemple, si vous supprimez un fichier et que vous en écrivez un nouveau, les résultats de votre requête peuvent exclure à la fois l'ancien et le nouveau fichier, selon la date de la dernière mise à jour des métadonnées mises en cache.
    • L'utilisation de clés de chiffrement gérées par le client (CMEK) avec des métadonnées mises en cache n'est pas compatible avec les tables BigLake qui référencent des données Amazon S3 ou Blob Storage.

Modèle de sécurité

Les rôles organisationnels suivants sont généralement impliqués dans la gestion et l'utilisation des tables BigLake :

  • Administrateurs de lacs de données. Ces administrateurs gèrent généralement les stratégies de gestion de l'authentification et des accès (IAM) sur les buckets et les objets Cloud Storage.
  • Administrateurs d'entrepôts de données. De manière générale, ces administrateurs créent, suppriment et mettent à jour des tables.
  • Analystes de données. De manière générale, les analystes lisent les données et exécutent des requêtes.

Les administrateurs de lacs de données sont chargés de créer des connexions et de les partager avec les administrateurs d'entrepôts de données. À leur tour, les administrateurs d'entrepôts de données créent des tables, définissent des contrôles d'accès appropriés et partagent les tables avec les analystes de données.

Mise en cache des métadonnées pour améliorer les performances

Vous pouvez utiliser des métadonnées mises en cache pour améliorer les performances des requêtes sur certains types de tables BigLake. La mise en cache des métadonnées est particulièrement utile lorsque vous travaillez avec un grand nombre de fichiers ou lorsque les données sont partitionnées avec Hive. Les types de tables BigLake suivants sont compatibles avec la mise en cache des métadonnées :

  • Tables Amazon S3 BigLake
  • Tables BigLake Cloud Storage
Les métadonnées incluent les noms de fichiers, les informations de partitionnement et les métadonnées physiques des fichiers, telles que le nombre de lignes. Vous pouvez choisir d'activer ou non la mise en cache des métadonnées sur une table. Les requêtes comportant un grand nombre de fichiers et des filtres de partitionnement Hive tirent le meilleur parti de la mise en cache des métadonnées.

Si vous n'activez pas la mise en cache des métadonnées, les requêtes effectuées sur la table doivent lire la source de données externe pour obtenir les métadonnées d'objet. La lecture de ces données augmente la latence des requêtes. Répertorier des millions de fichiers depuis la source de données externe peut prendre plusieurs minutes. Si vous activez la mise en cache des métadonnées, les requêtes peuvent éviter de répertorier les fichiers de la source de données externe et ainsi partitionner et supprimer les fichiers plus rapidement.

Deux propriétés contrôlent cette fonctionnalité :

  • L'obsolescence maximale spécifie le moment auquel les requêtes utilisent des métadonnées mises en cache..
  • Le mode de cache des métadonnées spécifie la manière dont les métadonnées sont collectées.

Lorsque la mise en cache des métadonnées est activée, vous spécifiez l'intervalle maximal d'obsolescence des métadonnées acceptable pour les opérations sur la table. Par exemple, si vous spécifiez un intervalle d'une heure, les opérations sur la table utilisent les métadonnées mises en cache si celles-ci ont été actualisées au cours de la dernière heure. Si les métadonnées mises en cache sont plus anciennes, l'opération extrait les métadonnées du datastore (Amazon S3 ou Cloud Storage). Vous pouvez spécifier un intervalle d'obsolescence compris entre 30 minutes et sept jours.

Vous pouvez choisir d'actualiser le cache automatiquement ou manuellement :

  • Pour les actualisations automatiques, le cache est actualisé à un intervalle défini par le système, généralement compris entre 30 et 60 minutes. L'actualisation automatique du cache est une bonne approche si les fichiers dans le datastore sont ajoutés, supprimés ou modifiés à intervalles irréguliers. Si vous devez contrôler le moment de l'actualisation, par exemple pour déclencher l'actualisation à la fin d'un job d'extraction, de transformation et de chargement, utilisez l'actualisation manuelle.

  • Pour les actualisations manuelles, exécutez la procédure système BQ.REFRESH_EXTERNAL_METADATA_CACHE afin d'actualiser le cache de métadonnées selon une programmation répondant à vos besoins. Pour les tables BigLake, vous pouvez actualiser les métadonnées de manière sélective en fournissant des sous-répertoires du répertoire de données de la table. Cela vous permet d'éviter le traitement inutile de métadonnées. L'actualisation manuelle du cache est une bonne approche si les fichiers dans le datastore sont ajoutés, supprimés ou modifiés à des intervalles connus, par exemple en tant que sortie d'un pipeline.

    Si vous émettez plusieurs actualisations manuelles simultanées, une seule réussira.

Le cache des métadonnées expire au bout de sept jours s'il n'est pas actualisé.

Les actualisations manuelles et automatiques du cache sont exécutées avec la priorité de requête INTERACTIVE.

Si vous choisissez d'utiliser les actualisations automatiques, nous vous recommandons de créer une réservation, puis de créer une attribution avec un type de job BACKGROUND pour le projet qui exécute les jobs d'actualisation du cache de métadonnées. Cela empêche les jobs d'actualisation d'être en concurrence avec les requêtes utilisateur pour les ressources et d'échouer potentiellement si les ressources sont insuffisantes.

Réfléchissez à la manière dont l'intervalle d'obsolescence et les valeurs du mode de mise en cache des métadonnées interagissent avant de les définir. Prenons les exemples suivants :

  • Si vous actualisez manuellement le cache de métadonnées d'une table et que vous définissez l'intervalle d'obsolescence sur deux jours, vous devez exécuter la procédure système BQ.REFRESH_EXTERNAL_METADATA_CACHE tous les deux jours ou moins si vous souhaitez effectuer des opérations sur la table pour utiliser les métadonnées mises en cache.
  • Si vous actualisez automatiquement le cache de métadonnées d'une table et que vous définissez l'intervalle d'obsolescence sur 30 minutes, il est possible que certaines de vos opérations sur la table lisent les données du datastore si l'actualisation du cache de métadonnées s'approche de la durée maximum de la fenêtre habituelle de 30 à 60 minutes.

Pour trouver des informations sur les jobs d'actualisation des métadonnées, interrogez la vue INFORMATION_SCHEMA.JOBS, comme illustré dans l'exemple suivant :

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Pour les tables BigLake Cloud Storage basées sur des fichiers Parquet, les statistiques de table sont collectées lors de l'actualisation du cache de métadonnées et sont utilisées pour améliorer les plans de requêtes.

Pour en savoir plus, consultez la section Mise en cache de métadonnées.

Pour en savoir plus sur la définition des options de mise en cache des métadonnées, consultez la page Créer des tables BigLake Amazon S3 ou Créer des tables BigLake Cloud Storage.

Tables compatibles avec le cache avec vues matérialisées

Vous pouvez utiliser des vues matérialisées sur des tables BigLake pour lesquelles le cache de métadonnées a été activé, afin de gagner en performances et en efficacité lors de l'interrogation de données structurées stockées dans Cloud Storage ou Amazon Simple Storage Service (Amazon S3). Ces vues matérialisées fonctionnent comme les vues matérialisées sur des tables de stockage gérées par BigQuery, ce qui inclut les avantages de l'actualisation automatique et du réglage intelligent.

Intégrations

Les tables BigLake sont accessibles à partir d'un certain nombre d'autres fonctionnalités BigQuery et de services gcloud CLI, y compris les services mis en avant ci-dessous.

Analytics Hub

Les tables BigLake sont compatibles avec Analytics Hub. Les ensembles de données contenant des tables BigLake peuvent être publiés sous forme de listes Analytics Hub. Les abonnés Analytics Hub peuvent s'abonner à ces listes, qui provisionnent un ensemble de données en lecture seule, appelé ensemble de données associé, dans leur projet. Les abonnés peuvent interroger toutes les tables de l'ensemble de données associé, y compris toutes les tables BigLake. Pour en savoir plus, consultez la page S'abonner à une liste.

BigQuery ML

Vous pouvez utiliser BigQuery ML pour entraîner et exécuter des modèles sur BigLake dans Cloud Storage.

Protection des données sensibles

La protection des données sensibles analyse vos tables BigLake afin d'identifier les données sensibles et de les classifier en tant que telles. Si des données sensibles sont détectées, les transformations d'anonymisation de la protection des données sensibles peuvent masquer, supprimer ou dissimuler ces données.

Coûts

Les coûts sont associés aux aspects suivants des tables BigLake :

Si vous avez des réservations d'emplacements, l'interrogation des tables externes ne vous est pas facturée. À la place, ces requêtes consomment des emplacements.

La table suivante montre comment votre modèle de tarification affecte la tarification de ces coûts :


Tarifs à la demande
Éditions Standard, Enterprise et Enterprise Plus

Requêtes
Vous êtes facturé pour les octets traités par les requêtes d'utilisateur.
Les emplacements dans les attributions de réservation avec un type de job QUERY sont consommés lors de la requête.

Actualisation manuelle du cache des métadonnées.
Vous êtes facturé pour les octets traités pour actualiser le cache.
Les emplacements dans les attributions de réservation avec un type de job QUERY sont consommés lors de l'actualisation du cache.

Actualisation automatique du cache des métadonnées.
Vous êtes facturé pour les octets traités pour actualiser le cache.
Les emplacements dans les attributions de réservation avec un type de job BACKGROUND sont consommés lors de l'actualisation du cache.

Si aucune réservation BACKGROUND n'est disponible pour actualiser le cache de métadonnées, BigQuery utilise automatiquement les emplacements dans les réservations QUERY si vous utilisez l'édition Enterprise ou Enterprise Plus.

Cloud Storage, Amazon S3 et Azure Blob Storage vous sont également facturés pour le stockage et l'accès aux données. conformément aux consignes de tarification de chaque produit.

Étape suivante