Introduzione alle tabelle di oggetti

Questo documento descrive le tabelle di oggetti, ovvero tabelle di sola lettura su oggetti di dati non strutturati che risiedono in Cloud Storage.

Le tabelle di oggetti ti consentono di analizzare i dati non strutturati in Cloud Storage. Puoi eseguire l'analisi con funzioni remote o l'inferenza utilizzando BigQuery ML, quindi unire i risultati di queste operazioni al resto dei dati strutturati in BigQuery.

Come le tabelle BigLake, le tabelle di oggetti utilizzano la delega dell'accesso, che disaccoppia l'accesso alla tabella di oggetti dall'accesso agli oggetti Cloud Storage. Per connetterti a Cloud Storage viene utilizzata una connessione esterna associata a un account di servizio, quindi devi solo concedere agli utenti l'accesso alla tabella degli oggetti. In questo modo, puoi applicare la sicurezza a livello di riga e gestire gli oggetti a cui gli utenti hanno accesso.

Puoi utilizzare l'istruzione CREATE EXTERNAL TABLE per creare una tabella di oggetti, come mostrato nell'esempio seguente:

CREATE EXTERNAL TABLE `myproject.mydataset.myobjecttable`
WITH CONNECTION `myproject.us.myconnection`
OPTIONS ( object_metadata = 'SIMPLE', uris = ['gs://mybucket/*'] );

Per scoprire di più sulla creazione di tabelle di oggetti, consulta Crea tabelle di oggetti.

Schema della tabella di oggetti

Una tabella di oggetti fornisce un indice dei metadati sugli oggetti di dati non strutturati in un bucket Cloud Storage specificato. Ogni riga della tabella corrisponde a un oggetto e le colonne della tabella corrispondono ai metadati dell'oggetto generati da Cloud Storage, inclusi eventuali metadati personalizzati.

Una tabella di oggetti contiene anche una pseudocolonna data che rappresenta il contenuto del file in byte non elaborati, che viene compilata automaticamente al momento della creazione della tabella di oggetti. Questa pseudocolonna viene utilizzata dalla funzione ML.DECODE_IMAGE quando esegui l'inferenza sui dati immagine. Non puoi includere la pseudocolonna data nelle query e non viene visualizzata come parte dello schema della tabella degli oggetti.

La tabella seguente descrive lo schema fisso utilizzato dalle tabelle di oggetti:

Nome campo Tipo Modalità Descrizione
uri STRING NULLABLE uri: l'Uniform Resource Identifier (URI) dell'oggetto, nel formato gs://bucket_name/[folder_name/]object_name.
generation INTEGER NULLABLE La generation di questo oggetto, che identifica la versione dell'oggetto.
content_type STRING NULLABLE Il Content-Type dei dati dell'oggetto, che identifica il tipo di media. Se un oggetto viene archiviato senza un Content-Type, viene pubblicato come application/octet-stream.
size INTEGER NULLABLE La Content-Length dei dati in byte.
md5_hash STRING NULLABLE L'hash MD5 dei dati, codificato utilizzando base64. Per saperne di più sull'utilizzo dell'hash MD5, consulta Metadati degli oggetti Cloud Storage.
updated TIMESTAMP NULLABLE L'ultima volta che i metadati dell'oggetto sono stati modificati.
metadata RECORD REPEATED Metadati personalizzati per l'oggetto. Ogni metadato è rappresentato come una coppia chiave-valore nei campi secondari (metadata.)name e (metadata.)value del campo metadata.
(metadata.)name STRING NULLABLE Chiave in una singola voce di metadati.
(metadata.)value STRING NULLABLE Valore in una singola voce di metadati.
ref STRUCT NULLABLE Metadati di Cloud Storage gestiti da Google archiviati nel formato ObjectRef.

Puoi utilizzare questa colonna per mantenere i valori ObjectRef nelle tabelle standard. I valori ObjectRef ti consentono di integrare i dati degli oggetti con i dati strutturati.

Le righe di una tabella di oggetti sono simili alle seguenti:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  | ref.uri              | ref.version | ref.authorizer | ref.details                                              |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              | gs://mybucket/a.jpeg | 12345678    | us.conn        | {"gcs_metadata":{"content_type":"image/jpeg","md5_hash"… |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              | gs://mybucket/b.bmp  | 23456789    | us.conn        | {"gcs_metadata":{"content_type":"image/bmp","md5_hash"…  |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Casi d'uso

Puoi eseguire query sui metadati in una tabella di oggetti nello stesso modo in cui eseguirai query su qualsiasi altra tabella BigQuery. Tuttavia, il caso d'uso principale delle tabelle di oggetti è rendere i dati non strutturati accessibili per l'analisi. Puoi utilizzare BigQuery ML per eseguire l'inferenza sulle tabelle degli oggetti immagine con i modelli TensorFlow, TensorFlow Lite e PyTorch. Puoi anche utilizzare le funzioni remote per analizzare i dati non strutturati quasi in qualsiasi modo tu voglia. Ad esempio, puoi creare una funzione remota che ti consente di analizzare le immagini utilizzando Cloud Vision o una che ti consente di estrarre i metadati dai documenti PDF utilizzando Apache Tika.

La tabella seguente descrive i punti di integrazione che puoi utilizzare per eseguire il machine learning sui dati delle tabelle di oggetti:

Integrazione Descrizione Caso d'uso Tutorial
La funzione AI.GENERATE_TEXT Genera testo utilizzando un modello partner, aperto o di Gemini Enterprise Agent Platform. Vuoi generare testo dai dati degli oggetti. Genera testo utilizzando la funzione AI.GENERATE_TEXT
La funzione AI.GENERATE_EMBEDDING Genera embedding utilizzando un modello multimodale di Gemini Enterprise Agent Platform. Vuoi generare embedding per dati video o immagini da utilizzare in Vector Search, input di modelli o altri casi d'uso. Genera gli embedding delle immagini utilizzando la funzione AI.GENERATE_EMBEDDING

Genera gli embedding dei video utilizzando la funzione AI.GENERATE_EMBEDDING
Modelli BigQuery ML importati Importa modelli TensorFlow, TensorFlow Lite o ONNX in BigQuery ML per eseguire l'inferenza locale in BigQuery . Utilizzi modelli open source o personalizzati che rientrano nelle limitazioni supportate. Tutorial: esegui l'inferenza su una tabella di oggetti utilizzando un modello di vettore di caratteristiche
Cloud Run Functions Utilizza Cloud Run Functions per chiamare servizi o modelli ospitati. Questa è l'integrazione più generica. Ospiti i tuoi modelli su Compute Engine, Google Kubernetes Engine o un'altra infrastruttura di proprietà del cliente.
La funzione ML.ANNOTATE_IMAGE Utilizzare l'API Cloud Vision per annotare le immagini. Vuoi annotare le immagini utilizzando un modello preaddestrato dell'API Vision. Annota le immagini con la funzione ML.ANNOTATE_IMAGE
La funzione ML.PROCESS_DOCUMENT Utilizza l'API Document AI per estrarre insight dai documenti. Vuoi utilizzare i processori di documenti preaddestrati o personalizzati di Document AI. Elabora i documenti con la funzione ML.PROCESS_DOCUMENT
La funzione ML.TRANSCRIBE Utilizzare l'API Speech-to-Text per trascrivere file audio. Vuoi utilizzare i riconoscitori vocali preaddestrati o personalizzati di Speech-to-Text. Trascrivi i file audio con la funzione ML.TRANSCRIBE

Puoi creare una vista o una tabella dai risultati dell'analisi se vuoi unire i risultati ad altri dati strutturati. Ad esempio, la seguente istruzione crea una tabella basata sui risultati dell'inferenza:

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
);

Dopo aver creato la tabella, puoi unirla ad altre tabelle in base ai campi dei metadati standard o personalizzati, come mostrato di seguito:

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;

Puoi anche creare un indice della Ricerca per potenziare le ricerche sui risultati della tua analisi. Ad esempio, la seguente istruzione crea un indice della Ricerca sui dati estratti dai file PDF:

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Puoi quindi utilizzare l'indice per trovare ciò di cui hai bisogno in questi risultati:

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

Vantaggi

L'analisi dei dati non strutturati in modo nativo in BigQuery offre i seguenti vantaggi:

  • Riduce il lavoro manuale consentendoti di automatizzare i passaggi di pre-elaborazione, come la regolazione delle dimensioni delle immagini in base ai requisiti del modello.
  • Ti consente di utilizzare la familiare interfaccia SQL per lavorare con dati non strutturati.
  • Ti aiuta a risparmiare sui costi utilizzando gli slot BigQuery esistenti anziché dover eseguire il provisioning di nuove forme di computing.

URL firmati

Per accedere ai dati rappresentati da un oggetto, genera un URL firmato. Puoi utilizzare l'URL firmato per visualizzare direttamente i dati dell'oggetto e puoi anche passare gli URL firmati alle funzioni remote per consentire loro di utilizzare i dati della tabella degli oggetti.

Utilizza la funzione EXTERNAL_OBJECT_TRANSFORM per generare URL firmati, come mostrato nell'esempio seguente:

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

Vengono restituiti risultati simili ai seguenti:

---------------------------------------------------------------------------------------------------
|  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&...  |
—--------------------------------------------------------------------------------------------------

Gli URL firmati generati dalle tabelle di oggetti consentono a qualsiasi utente o procedura che li possiede di leggere gli oggetti corrispondenti. Gli URL firmati generati scadono dopo 6 ore. Per saperne di più, consulta URL firmati di Cloud Storage.

Controllo degli accessi

Le tabelle di oggetti sono basate su BigLake, quindi utilizzano una connessione esterna basata su un account di servizio per accedere ai dati di Cloud Storage. In questo modo, l'accesso alla tabella viene disaccoppiato dall'accesso all'archivio di oggetti sottostante tramite la delega dell'accesso. Concedi al account di servizio le autorizzazioni per accedere ai dati e ai metadati degli oggetti e visualizzarli nella tabella. Concedi agli utenti le autorizzazioni solo sulla tabella, dove puoi gestire l'accesso ai dati utilizzando Identity and Access Management (IAM) e la sicurezza a livello di riga.

Le tabelle di oggetti si differenziano dalle altre tabelle che utilizzano la delega dell'accesso, in quanto l'accesso a una riga di una tabella di oggetti conferisce l'accesso ai contenuti del file sottostante. Anche se un utente non può accedere direttamente all'oggetto, può generare un URL firmato che gli consente di visualizzare i contenuti del file. Ad esempio, se l'utente ha accesso alla riga della tabella degli oggetti che rappresenta il file immagine flower.jpg, può generare un URL firmato per visualizzare il file e vedere che si tratta dell'immagine di una margherita.

L'impostazione di una policy di accesso a livello di riga su una tabella di oggetti limita l'accesso di un utente o di un gruppo ai metadati degli oggetti nelle righe selezionate e anche agli oggetti rappresentati da queste righe. Ad esempio, la seguente istruzione concede all'utente Alice l'accesso solo alle righe che rappresentano gli oggetti creati prima del 25 giugno 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"));

Con questa policy di accesso a livello di riga, i seguenti risultati sono veri per Alice:

  • L'esecuzione della query SELECT * FROM my_dataset.my_object_table; restituisce solo le righe con un valore updated precedente al 25 giugno 2022.
  • L'esecuzione dell'inferenza su my_dataset.my_object_table restituisce solo le previsioni per gli oggetti che hanno un valore updated precedente al 25 giugno 2022.
  • La generazione di URL firmati per my_dataset.my_object_table crea solo URL per gli oggetti che hanno un valore updated precedente al 25 giugno 2022.

Puoi anche limitare l'accesso alle righe della tabella degli oggetti utilizzando metadati personalizzati. Ad esempio, la seguente istruzione limita il gruppo users all'accesso solo alle righe in cui l'oggetto è stato taggato come non contenente informazioni che consentono l'identificazione personale:

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")

Modello di sicurezza

I seguenti ruoli organizzativi sono in genere coinvolti nella gestione e nell'utilizzo delle tabelle di oggetti:

  • Amministratori di data lake. In genere, questi amministratori gestiscono le policy di Identity and Access Management (IAM) su bucket Cloud Storage e oggetti.
  • Amministratori di data warehouse. In genere, questi amministratori creano, eliminano e aggiornano le tabelle.
  • Analisti di dati. Gli analisti in genere leggono i dati ed eseguono query.

Gli amministratori dei data lake sono responsabili della creazione delle connessioni e della loro condivisione con gli amministratori dei data warehouse. A loro volta, gli amministratori del data warehouse creano tabelle, impostano i controlli di accesso appropriati e condividono le tabelle con gli analisti di dati.

File oggetto supportati

Puoi creare una tabella di oggetti su qualsiasi tipo e dimensione di file di dati non strutturati e puoi creare funzioni remote per lavorare con qualsiasi tipo di dati non strutturati. Tuttavia, per eseguire l'inferenza utilizzando BigQuery ML, una tabella di oggetti può essere utilizzata solo su file immagine che soddisfano diversi requisiti di dimensioni e tipo. Per ulteriori informazioni, vedi Limitazioni.

Memorizzazione nella cache dei metadati per le prestazioni

Puoi utilizzare i metadati memorizzati nella cache per migliorare le prestazioni dell'inferenza e di altri tipi di analisi sulle tabelle degli oggetti. La memorizzazione nella cache dei metadati è particolarmente utile nei casi in cui la tabella degli oggetti fa riferimento a un numero elevato di oggetti. BigQuery utilizza CMETA come sistema di metadati distribuito per gestire in modo efficiente tabelle di grandi dimensioni. CMETA fornisce metadati granulari a livello di colonna e blocco, accessibili tramite le tabelle di sistema. Questo sistema contribuisce a migliorare le prestazioni delle query ottimizzando l'accesso e l'elaborazione dei dati. Per accelerare ulteriormente le prestazioni delle query su tabelle di grandi dimensioni, BigQuery gestisce una cache dei metadati. I job di aggiornamento CMETA mantengono aggiornata questa cache.

I metadati includono nomi di file, informazioni di partizionamento e metadati fisici dei file, come i conteggi delle righe. Puoi scegliere se abilitare o meno la memorizzazione nella cache dei metadati su una tabella. Le query con un numero elevato di file e con filtri di partizione Apache Hive traggono il massimo vantaggio dalla memorizzazione nella cache dei metadati.

Se non attivi la memorizzazione nella cache dei metadati, le query sulla tabella devono leggere l'origine dati esterna per ottenere i metadati degli oggetti. La lettura di questi dati aumenta la latenza delle query; l'elenco di milioni di file dall'origine dati esterna può richiedere diversi minuti. Se abiliti la memorizzazione nella cache dei metadati, le query possono evitare di elencare i file dall'origine dati esterna e possono partizionare e ridurre i file più rapidamente.

La memorizzazione nella cache dei metadati si integra anche con il controllo delle versioni degli oggetti di Cloud Storage. Quando la cache viene compilata o aggiornata, acquisisce i metadati in base alla versione live degli oggetti Cloud Storage in quel momento. Di conseguenza, le query abilitate per la memorizzazione dei metadati nella cache leggono i dati corrispondenti alla versione specifica dell'oggetto memorizzato nella cache, anche se in Cloud Storage sono disponibili versioni più recenti. L'accesso ai dati da qualsiasi versione degli oggetti aggiornata successivamente in Cloud Storage richiede un aggiornamento della cache dei metadati.

Esistono due proprietà che controllano questa funzionalità:

  • Staleness massima specifica quando le query utilizzano i metadati memorizzati nella cache.
  • La modalità cache dei metadati specifica come vengono raccolti i metadati.

Quando la memorizzazione nella cache dei metadati è abilitata, specifichi l'intervallo massimo di inattività dei metadati accettabile per le operazioni sulla tabella. Ad esempio, se specifichi un intervallo di 1 ora, le operazioni sulla tabella utilizzano i metadati memorizzati nella cache se sono stati aggiornati nell'ultima ora. Se i metadati memorizzati nella cache sono più vecchi, l'operazione torna a recuperare i metadati da Cloud Storage. Puoi specificare un intervallo di inattività compreso tra 30 minuti e 7 giorni.

Quando abiliti la memorizzazione nella cache dei metadati per le tabelle BigLake o degli oggetti, BigQuery attiva i job di aggiornamento della generazione dei metadati. Puoi scegliere di aggiornare la cache automaticamente o manualmente:

  • Per gli aggiornamenti automatici, la cache viene aggiornata a un intervallo definito dal sistema, in genere compreso tra 30 e 60 minuti. L'aggiornamento automatico della cache è un buon approccio se i file in Cloud Storage vengono aggiunti, eliminati o modificati a intervalli casuali. Se devi controllare i tempi di aggiornamento, ad esempio per attivare l'aggiornamento alla fine di un job di estrazione, trasformazione e caricamento, utilizza l'aggiornamento manuale.

  • Per gli aggiornamenti manuali, esegui la procedura di sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE per aggiornare la cache dei metadati in base a una pianificazione che soddisfi i tuoi requisiti. L'aggiornamento manuale della cache è un buon approccio se i file in Cloud Storage vengono aggiunti, eliminati o modificati a intervalli noti, ad esempio come output di una pipeline.

    Se esegui più aggiornamenti manuali contemporaneamente, solo uno andrà a buon fine.

La cache dei metadati scade dopo 7 giorni se non viene aggiornata.

Gli aggiornamenti della cache sia manuali che automatici vengono eseguiti con la priorità di query INTERACTIVE.

Utilizza le prenotazioni BACKGROUND

Se scegli di utilizzare gli aggiornamenti automatici, ti consigliamo di creare una prenotazione e poi un assegnazione con un tipo di prestazione BACKGROUND per il progetto che esegue i job di aggiornamento della cache dei metadati. Con le prenotazioni BACKGROUND, i job di aggiornamento utilizzano un pool di risorse dedicato che impedisce ai job di aggiornamento di competere con le query degli utenti e di non riuscire se non sono disponibili risorse sufficienti.

Sebbene l'utilizzo di un pool di slot condiviso non comporti costi aggiuntivi, l'utilizzo di prenotazioni BACKGROUND offre prestazioni più coerenti allocando un pool di risorse dedicato e migliora l'affidabilità dei job di aggiornamento e l'efficienza complessiva delle query in BigQuery.

Prima di impostarli, devi considerare l'interazione tra i valori dell'intervallo di inattività e della modalità di memorizzazione nella cache dei metadati. Considera i seguenti esempi:

  • Se aggiorni manualmente la cache dei metadati per una tabella e imposti l'intervallo di inattività su 2 giorni, devi eseguire la procedura di sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE ogni 2 giorni o meno se vuoi che le operazioni sulla tabella utilizzino i metadati memorizzati nella cache.
  • Se aggiorni automaticamente la cache dei metadati per una tabella e imposti l'intervallo di inattività su 30 minuti, è possibile che alcune delle tue operazioni sulla tabella leggano da Cloud Storage se l'aggiornamento della cache dei metadati richiede più tempo rispetto alla consueta finestra di 30-60 minuti.

Per trovare informazioni sui job di aggiornamento dei metadati, esegui una query sulla vista INFORMATION_SCHEMA.JOBS, come mostrato nell'esempio seguente:

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;

Per saperne di più, consulta Memorizzazione dei metadati nella cache.

Per saperne di più sull'impostazione delle opzioni di memorizzazione dei metadati nella cache, consulta Crea tabelle di oggetti.

Limitazioni

  • Le tabelle di oggetti sono di sola lettura, perché vengono mappate a oggetti di dati non strutturati in Cloud Storage. Non puoi alterare una tabella di oggetti o modificarne i dati.
  • Il supporto delle tabelle di oggetti non è disponibile in SQL precedente o in altri ambienti cloud come Amazon Web Services (AWS) e Microsoft Azure.
  • Se vuoi eseguire l'inferenza utilizzando BigQuery ML, il modello e la tabella di oggetti che utilizzi devono soddisfare i requisiti descritti in Limitazioni.
  • Le query che includono tabelle di oggetti non possono accedere a più di 10 GB di metadati degli oggetti. Ad esempio, se una query accede a 100 TB da una combinazione di colonne di metadati nelle tabelle degli oggetti e dati degli oggetti tramite URL firmati, solo 10 GB di questi 100 TB possono provenire dalle colonne di metadati.
  • Le tabelle di oggetti sono soggette alle stesse limitazioni di tutte le altre tabelle esterne di BigQuery. Per scoprire di più, consulta Quote.
  • Le query sulle tabelle di oggetti sono soggette alle stesse limitazioni di tutte le altre query BigQuery. Per scoprire di più, consulta Quote.
  • Le funzioni remote che elaborano dati non strutturati dalle tabelle degli oggetti sono soggette alle stesse limitazioni di tutte le altre funzioni remote.
  • Gli URL firmati generati per gli oggetti in una tabella di oggetti scadono dopo 6 ore, ovvero il limite di tempo di esecuzione delle query.
  • L'inferenza con BigQuery ML non è supportata con i prezzi on demand o con l'edizione Standard.

  • Le seguenti funzioni non sono supportate con i prezzi on demand o con l'edizione Standard:

  • Le tabelle di oggetti possono avere un massimo di 300 milioni di righe. Per prestazioni ottimali di elenco e query, specifica un massimo di 10 URI di origine nell'opzione uris di una tabella di oggetti. Se specifichi più di 10 URI dei bucket, il numero massimo di file supportati dalla tabella degli oggetti si riduce e le query potrebbero non riuscire con un errore di memoria Resources exceeded during query execution quando il numero totale di file nei bucket è elevato. Se devi fare riferimento a più di 10 bucket, suddividili in più tabelle di oggetti.

  • Le operazioni UNION ALL che combinano tabelle di oggetti vuote e non vuote non sono supportate e potrebbero restituire un errore.

  • All'interno di un perimetro dei Controlli di servizio VPC, le funzioni AI non possono elaborare la colonna ref di una tabella esterna. La colonna ref utilizza sempre la connessione della tabella di oggetti come autorizzatore, il che significa che BigQuery genera un URL HTTPS firmato per l'oggetto e Gemini Enterprise Agent Platform blocca i recuperi HTTP e HTTPS per i progetti all'interno di un perimetro. La funzione scrive l'errore INVALID_ARGUMENT: HTTP links are not supported for requests restricted by VPCSC. nel campo status del suo output. Per analizzare l'oggetto, passa invece un valore OBJ.MAKE_REF(uri) con un singolo argomento, che invia l'URI Cloud Storage al modello senza generare un URL firmato. OBJ.MAKE_REF recupera i metadati degli oggetti da Cloud Storage ogni volta che viene eseguito, il che potrebbe essere meno scalabile per workload di grandi dimensioni. Per saperne di più, consulta Mantenimento dei valori ObjectRef.

Costi

I costi sono associati ai seguenti aspetti delle tabelle di oggetti:

Se hai prenotazioni di slot, non ti vengono addebitati costi per le query su tabelle esterne. Invece, per queste query vengono consumati slot.

La tabella seguente mostra in che modo il modello di prezzi influisce sull'applicazione di questi costi:


Prezzi on demand
Versioni Standard, Enterprise ed Enterprise Plus

Query
Ti vengono addebitati i byte elaborati dalle query degli utenti.
Gli slot nelle assegnazioni di prenotazione con un QUERYtipo di prestazione vengono utilizzati durante il tempo di query.

Aggiornamento manuale della cache dei metadati.
Ti vengono addebitati i byte elaborati per aggiornare la cache.
Gli slot nelle assegnazioni di prenotazioni con un QUERYtipo di prestazione vengono utilizzati durante l'aggiornamento della cache.

Aggiornamento automatico della cache dei metadati.
Ti vengono addebitati i byte elaborati per aggiornare la cache.
Gli slot nelle assegnazioni di prenotazioni con un tipo di job BACKGROUND vengono utilizzati durante l'aggiornamento della cache.

Se non sono disponibili prenotazioni BACKGROUND per l'aggiornamento della cache dei metadati, BigQuery utilizza automaticamente gli slot nelle prenotazioni QUERY se utilizzi la versione Enterprise o Enterprise Plus.

Ti vengono addebitati anche i costi per l'archiviazione e l'accesso ai dati da parte di Cloud Storage, Amazon S3 e Azure Blob Storage, in base alle linee guida sui prezzi di ciascun prodotto.

Quando BigQuery interagisce con Cloud Storage, potresti incorrere nei seguenti costi di Cloud Storage:

  • Costi di archiviazione dei dati per la quantità di dati archiviati.
  • Costi di recupero dei dati per l'accesso ai dati nelle classi di archiviazione Nearline, Coldline e Archive. Presta attenzione quando esegui query sulle tabelle o aggiorni la cache dei metadati per queste classi di archiviazione, poiché i costi possono essere significativi.
  • Costi di utilizzo della rete per i dati che leggi in regioni diverse, ad esempio quando il set di dati BigQuery e il bucket Cloud Storage si trovano in regioni diverse.
  • Costi per il trattamento dei dati. Tuttavia, non ti vengono addebitati costi per le chiamate API effettuate da BigQuery per tuo conto, ad esempio per elencare o recuperare risorse.

Utilizzo delle tabelle di oggetti con BigQuery sharing

Le tabelle di oggetti sono compatibili con BigQuery sharing (in precedenza Analytics Hub). I set di dati contenenti tabelle di oggetti possono essere pubblicati come schede di condivisione. Gli abbonati alla condivisione possono iscriversi a queste schede, che eseguono il provisioning di un set di dati di sola lettura, chiamato set di dati collegato, nel loro progetto. Gli abbonati possono eseguire query su tutte le tabelle del set di dati collegato, incluse tutte le tabelle di oggetti. Per saperne di più, consulta Iscriviti a una scheda.

Passaggi successivi