Présentation des tables d'objets

Ce document décrit les tables d'objets, qui sont des tables en lecture seule sur des objets de données non structurés stockés dans Cloud Storage.

Les tables d'objets vous permettent d'analyser des données non structurées dans Cloud Storage. Vous pouvez effectuer une analyse avec des fonctions à distance ou réaliser des inférences à l'aide de BigQuery ML, puis joindre les résultats de ces opérations aux autres données structurées dans BigQuery.

Tout comme les tables BigLake, les tables d'objets utilisent la délégation d'accès, qui dissocie l'accès à la table d'objets de l'accès aux objets Cloud Storage. Une connexion externe associée à un compte de service permet de se connecter à Cloud Storage. Il vous suffit donc d'accorder aux utilisateurs l'accès à la table d'objets. Cela vous permet d'appliquer des règles de sécurité au niveau des lignes et de gérer les objets auxquels les utilisateurs ont accès.

Schéma d'une table d'objets

Une table d'objets fournit un index de métadonnées sur les objets de données non structurés d'un bucket Cloud Storage spécifié. Chaque ligne de la table correspond à un objet. Les colonnes de la table correspondent aux métadonnées d'objets générées par Cloud Storage, y compris aux métadonnées personnalisées.

Une table d'objets contient également une pseudo-colonne data représentant le contenu du fichier en octets bruts qui est automatiquement renseigné lors de la création de la table d'objets. Cette pseudo-colonne est utilisée par la fonction ML.DECODE_IMAGE lorsque vous exécutez une inférence sur les données d'image. Vous ne pouvez pas inclure la pseudo-colonne data dans les requêtes. Elle n'apparaît pas dans le schéma de la table d'objets.

Le tableau suivant décrit le schéma fixe utilisé par les tables d'objets :

fieldName Type Mode Description
uri STRING NULLABLE uri : URI (Uniform Resource Identifier) de l'objet, au format gs://bucket_name/[folder_name/]object_name.
generation INTEGER NULLABLE Génération de cet objet, qui identifie la version de l'objet.
content_type STRING NULLABLE Content-Type des données d'objet, qui identifie le type de contenu multimédia. Si un objet est stocké sans Content-Type, il est diffusé en tant qu'application/octet-stream.
size INTEGER NULLABLE Content-Length des données en octets.
md5_hash STRING NULLABLE Hachage MD5 des données, encodé en base64. Pour en savoir plus sur l'utilisation du hachage MD5, consultez la page Hachages et ETags Cloud Storage.
updated TIMESTAMP NULLABLE Date et heure de la dernière modification des métadonnées de l'objet.
metadata RECORD REPEATED Métadonnées personnalisées de l'objet. Chaque métadonnée est représentée sous la forme d'une paire clé-valeur dans les champs enfants (metadata.)name et (metadata.)value du champ metadata.
(metadata.)name STRING NULLABLE Clé dans une entrée de métadonnées individuelle.
(metadata.)value STRING NULLABLE Valeur d'une entrée de métadonnées individuelle.

Les lignes d'une table d'objets se présentent comme suit :

------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------

Cas d'utilisation

Vous pouvez interroger les métadonnées d'une table d'objets de la même manière que vous interrogeriez n'importe quelle autre table BigQuery. Toutefois, le principal cas d'utilisation des tables d'objets consiste à rendre les données non structurées accessibles à des fins d'analyse. Vous pouvez utiliser BigQuery ML pour exécuter des inférences sur des tables d'objets image avec des modèles TensorFlow, TensorFlow Lite et PyTorch. Vous pouvez également exécuter des fonctions à distance pour analyser des données non structurées comme vous le souhaitez. Par exemple, vous pouvez créer une fonction à distance qui vous permet d'analyser des images à l'aide de Cloud Vision ou d'extraire des métadonnées de documents PDF à l'aide d'Apache Tika.

Le tableau suivant décrit les points d'intégration que vous pouvez utiliser pour effectuer du machine learning sur des données de table d'objets :

Intégration Description Cas d'utilisation Tutoriel
Modèles BigQuery ML importés Importez des modèles TensorFlow, TensorFlow Lite ou ONNX dans BigQuery ML pour exécuter une inférence locale dans BigQuery. Vous utilisez des modèles Open Source ou personnalisés qui respectent les limites autorisées. Tutoriel : Exécuter une inférence sur une table d'objets à l'aide d'un modèle de vecteur de caractéristiques
Cloud Functions Utilisez Cloud Functions pour appeler des services ou des modèles hébergés. Il s'agit de l'intégration la plus générique. Vous hébergez vous-même vos modèles sur Compute Engine, Google Kubernetes Engine ou une autre infrastructure appartenant au client. Tutoriel : Analyser une table d'objets à l'aide d'une fonction distante
La fonction ML.ANNOTATE_IMAGE Utilisez l'API Cloud Vision pour annoter des images. Vous souhaitez annoter des images à l'aide d'un modèle pré-entraîné de l'API Vision. Annoter des images avec la fonction ML.ANNOTATE_IMAGE
La fonction ML.PROCESS_DOCUMENT Utilisez l'API Document AI pour extraire des insights sur les documents. Vous souhaitez utiliser des processeurs de documents pré-entraînés ou personnalisés. Traiter des documents avec la fonction ML.PROCESS_DOCUMENT
La fonction ML.TRANSCRIBE Utilisez l'API Speech-to-Text pour transcrire des fichiers audio. Vous souhaitez utiliser des reconnaissances vocales pré-entraînées ou personnalisées de Speech-to-Text. Transcrire des fichiers audio avec la fonction ML.TRANSCRIBE

Si vous souhaitez joindre vos résultats à d'autres données structurées, vous pouvez créer une vue ou une table à partir des résultats de votre analyse. Par exemple, l'instruction suivante crée une table basée sur les résultats d'une inférence :

CREATE TABLE my_dataset.my_inference_results AS
SELECT uri, content_type, vision_feature
FROM ML.PREDICT(
  MODEL my_dataset.vision_model,
  SELECT ML.DECODE_IMAGE(data) AS vision_input
  FROM my_dataset.object_table
);

Une fois la table créée, vous pouvez la joindre à d'autres tables en fonction de champs de métadonnées standards ou personnalisés, comme indiqué ci-dessous :

SELECT a.vision_feature, a.uri, b.description
FROM my_dataset.my_inference_results a
JOIN my_dataset.image_description b
ON a.uri = b.uri;

Vous pouvez également créer un index de recherche pour optimiser les recherches sur les résultats de votre analyse. Par exemple, l'instruction suivante crée un index de recherche sur les données extraites des fichiers PDF :

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Vous pouvez ensuite utiliser l'index pour trouver ce dont vous avez besoin dans ces résultats :

SELECT * FROM pdf_text_extract WHERE SEARCH(pdf_text, 'Google');

Avantages

L'analyse native des données non structurées dans BigQuery offre les avantages suivants :

  • Elle réduit les efforts manuels en vous permettant d'automatiser les étapes de prétraitement, telles que l'ajustement de la taille des images en fonction des exigences du modèle.
  • Elle vous permet d'utiliser des données non structurées à l'aide de l'interface SQL simple et conviviale.
  • Cela vous permet de réduire les coûts en utilisant des emplacements BigQuery existants au lieu de devoir provisionner de nouvelles formes de calcul.

URL signées

Pour accéder aux données représentées par un objet, générez une URL signée. Vous pouvez utiliser l'URL signée pour afficher directement les données d'objet et transmettre les URL signées à des fonctions à distance afin de leur permettre d'utiliser les données d'une table d'objets.

Exécutez la fonction EXTERNAL_OBJECT_TRANSFORM pour générer des URL signées, comme illustré dans l'exemple suivant :

SELECT uri, signed_url
FROM EXTERNAL_OBJECT_TRANSFORM(TABLE mydataset.myobjecttable, ['SIGNED_URL']);

Elle renvoie des résultats semblables aux suivants :

---------------------------------------------------------------------------------------------------
|  uri                 | signed_url                                                               |
—--------------------------------------------------------------------------------------------------
| gs://mybucket/a.docx | https://storage.googleapis.com/mybucket/a.docx?X-Goog-Signature=abcd&... |
—-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-Signature=wxyz&...  |
—--------------------------------------------------------------------------------------------------

Les URL signées générées à partir de tables d'objets permettent à tous les utilisateurs ou procédures qui en disposent de lire les objets correspondants. Les URL signées générées expirent au bout de six heures. Pour en savoir plus, consultez la page URL signées Cloud Storage.

Contrôle des accès

Les tables d'objets reposent sur BigLake. Elles utilisent donc une connexion externe basée sur un compte de service pour accéder aux données Cloud Storage. Cela permet de dissocier l'accès à la table de l'accès au magasin d'objets sous-jacent via la délégation d'accès. Vous accordez au compte de service des autorisations pour accéder aux données et aux métadonnées des objets, et les afficher dans la table. Vous n'accordez aux utilisateurs que des autorisations sur la table, où vous pouvez régir l'accès aux données à l'aide d'Identity and Access Management (IAM) et de règles de sécurité au niveau des lignes.

Les tables d'objets diffèrent des autres tables qui utilisent la délégation d'accès, car le fait d'avoir accès à une ligne d'une table d'objets permet d'accéder au contenu du fichier sous-jacent. Bien qu'un utilisateur ne puisse pas accéder directement à l'objet, il peut générer une URL signée qui lui permet d'afficher le contenu du fichier. Par exemple, si l'utilisateur a accès à une ligne de la table d'objets représentant le fichier image flower.jpg, il peut générer une URL signée pour afficher le fichier et voir s'il s'agit d'une image de marguerite.

La définition d'une stratégie d'accès au niveau des lignes dans une table d'objets limite l'accès d'un utilisateur ou d'un groupe aux métadonnées de l'objet dans les lignes sélectionnées, ainsi qu'aux objets représentés par ces lignes. Par exemple, l'instruction suivante permet à l'utilisatrice Alice d'accéder uniquement aux lignes représentant des objets créés avant le 25 juin 2022 :

CREATE ROW ACCESS POLICY before_20220625
ON my_dataset.my_object_table
GRANT TO ("user:alice@example.com")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

Une fois cette stratégie d'accès appliquée au niveau d'une ligne, les résultats suivants sont vrais pour Alice :

  • L'exécution de la requête SELECT * FROM my_dataset.my_object_table; renvoie uniquement les lignes ayant une valeur updated antérieure au 25 juin 2022.
  • L'exécution de l'inférence sur my_dataset.my_object_table ne renvoie que les prédictions pour les objets ayant une valeur updated antérieure au 25 juin 2022.
  • La génération d'URL signées pour my_dataset.my_object_table ne crée des URL que pour les objets ayant une valeur updated antérieure au 25 juin 2022.

Vous pouvez également restreindre l'accès aux lignes d'une table d'objets à l'aide de métadonnées personnalisées. Par exemple, l'instruction suivante limite l'accès du groupe users aux lignes sur lesquelles l'objet a été marqué comme ne contenant aucune information permettant d'identifier personnellement l'utilisateur :

CREATE ROW ACCESS POLICY no_pii
ON my_dataset.my_object_table
GRANT TO ("group:users@example.com")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

Modèle de sécurité

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

  • 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.

Fichiers d'objets compatibles

Vous pouvez créer une table d'objets sur tout type de fichier de données non structurées, quelle que soit leur taille. Vous pouvez également créer des fonctions à distance qui fonctionnent avec n'importe quel type de données non structurées. Toutefois, pour effectuer une inférence à l'aide de BigQuery ML, une table d'objets ne peut porter que sur des fichiers image répondant à plusieurs exigences de taille et de type. Pour en savoir plus, consultez la section Limites.

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 de l'inférence et d'autres types d'analyses sur les tables d'objets. La mise en cache des métadonnées est particulièrement utile dans les cas où la table d'objets fait référence à un grand nombre d'objets. 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 dans la source de données externe pour obtenir des métadonnées d'objet, ce qui augmente la latence des requêtes : l'identification de plusieurs 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 sauter la phase d'identification des fichiers depuis la source de données externe, et éliminer plus rapidement des partitions et fichiers.

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

  • L'obsolescence maximale, qui contrôle le moment auquel les requêtes utilisent des métadonnées mises en cache.
  • Le mode de mise en cache des métadonnées, qui contrôle 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 depuis 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 Cloud Storage 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. L'actualisation manuelle du cache est une bonne approche si les fichiers dans Cloud Storage 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é.

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 de Cloud Storage 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 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 d'objets.

Limites

  • Les tables d'objets sont en lecture seule, car elles correspondent à des objets de données non structurés dans Cloud Storage. Vous ne pouvez pas modifier une table d'objets ni les données qu'elle contient.
  • La table d'objets n'est pas disponible en ancien SQL ou dans d'autres environnements cloud tels qu'AWS et Microsoft Azure.
  • Si vous souhaitez effectuer une inférence à l'aide de BigQuery ML, le modèle et la table d'objets que vous utilisez doivent répondre aux exigences décrites dans la section Limites.
  • Les requêtes qui incluent des tables d'objets ne peuvent pas accéder à plus de 10 Go de métadonnées d'objets. Par exemple, si une requête accède à 100 To à partir d'une combinaison de colonnes de métadonnées dans des tables d'objets et des données d'objet via des URL signées, seuls 10 Go de ces 100 To peuvent provenir des colonnes de métadonnées.
  • Les tables d'objets sont soumises aux mêmes limites que toutes les autres tables externes BigQuery. Pour en savoir plus, consultez la page consacrée aux quotas.
  • Les requêtes sur les tables d'objets sont soumises aux mêmes limites que toutes les autres requêtes BigQuery. Pour en savoir plus, consultez la page consacrée aux quotas.
  • Les fonctions à distance qui traitent les données non structurées des tables d'objets sont soumises aux mêmes limites que toutes les autres fonctions à distance.
  • Les URL signées générées pour les objets d'une table d'objets expirent au bout de six heures, ce qui correspond au délai d'exécution des requêtes.
  • L'inférence avec BigQuery ML n'est pas compatible avec les tarifs à la demande ni avec l'édition Standard.

  • Les fonctions suivantes ne sont pas compatibles avec la tarification à la demande ni avec l'édition Standard :

Coûts

Les coûts sont associés aux aspects suivants des tables d'objets :

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.

Utiliser des tables d'objets avec Analytics Hub

Les tables d'objets sont compatibles avec Analytics Hub. Les ensembles de données contenant des tables d'objets 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 d'objets. Pour en savoir plus, consultez la page S'abonner à une liste.

Étapes suivantes