Organizzazione delle risorse BigQuery

Come gli altri servizi Google Cloud, le risorse BigQuery sono organizzate in una gerarchia. Puoi utilizzare questa gerarchia per gestire aspetti dei tuoi carichi di lavoro BigQuery, come autorizzazioni, quote, prenotazioni di slot e fatturazione.

Gerarchia delle risorse

BigQuery eredita la gerarchia delle risorse di Google Cloud e aggiunge un ulteriore meccanismo di raggruppamento denominato set di dati specifici di BigQuery. Questa sezione descrive gli elementi di questa gerarchia.

Set di dati

I set di dati sono container logici utilizzati per organizzare e controllare l'accesso alle risorse BigQuery. I set di dati sono simili agli schemi di altri sistemi di database.

La maggior parte delle risorse BigQuery create, incluse tabelle, viste, funzioni e procedure, viene creata all'interno di un set di dati. Le connessioni e i job sono eccezioni e sono associati a progetti anziché a set di dati.

Un set di dati ha una location. Quando crei una tabella, i dati della tabella vengono archiviati nella posizione del set di dati. Prima di creare tabelle per i dati di produzione, pensa ai requisiti di località. Non puoi modificare la località di un set di dati dopo averlo creato.

Progetti

Ogni set di dati è associato a un progetto. Per usare Google Cloud, devi creare almeno un progetto. I progetti sono la base per creare, abilitare e utilizzare tutti i servizi Google Cloud. Per maggiori informazioni, consulta Gerarchia delle risorse. Un progetto può contenere più set di dati e nello stesso progetto possono esistere set di dati con località diverse.

Quando esegui operazioni sui dati BigQuery, ad esempio l'esecuzione di una query o l'importazione di dati in una tabella, crei un job. Un job è sempre associato a un progetto, ma non deve essere eseguito nello stesso progetto che contiene i dati. Infatti, un job potrebbe fare riferimento a tabelle di set di dati in più progetti. Un job di query, un job di caricamento o un job di esportazione viene eseguito sempre nella stessa località delle tabelle a cui fa riferimento.

A ogni progetto è collegato un account di fatturazione Cloud. I costi accumulati per un progetto vengono fatturati a quell'account. Se utilizzi i prezzi on demand, le tue query vengono fatturate al progetto che le esegue. Se utilizzi i prezzi basati sulla capacità, le prenotazioni di slot vengono fatturate al progetto di amministrazione utilizzato per acquistare gli slot. Lo spazio di archiviazione viene addebitato al progetto in cui si trova il set di dati.

Cartelle

Le cartelle sono un ulteriore meccanismo di raggruppamento sopra i progetti. I progetti e le cartelle all'interno di una cartella ereditano automaticamente i criteri di accesso della relativa cartella padre. Le cartelle possono essere usate per modellare varie persone giuridiche, reparti, e team all'interno di un'azienda.

Organizzazioni

La risorsa organizzazione rappresenta un'organizzazione (ad esempio un'azienda) ed è il nodo radice nella gerarchia delle risorse di Google Cloud.

Non hai bisogno di una risorsa organizzazione per iniziare a utilizzare BigQuery, ma ti consigliamo di crearne una. L'utilizzo di una risorsa organizzazione consente agli amministratori di controllare centralmente le risorse BigQuery, anziché i singoli utenti a controllare le risorse che creano.

Il seguente diagramma mostra un esempio della gerarchia delle risorse. In questo esempio, l'organizzazione ha un progetto all'interno di una cartella. Il progetto è associato a un account di fatturazione e contiene tre set di dati.

Gerarchia delle risorse

Considerazioni

Al momento di scegliere come organizzare le risorse BigQuery, tieni in considerazione i seguenti punti:

  • Quote. Molte quotas di BigQuery vengono applicate a livello di progetto. Alcuni si applicano a livello del set di dati. Le quote a livello di progetto che coinvolgono le risorse di calcolo, come query e job di caricamento, vengono conteggiate in base al progetto che crea il job e non in base al progetto di archiviazione.
  • Fatturazione. Se vuoi che reparti diversi dell'organizzazione utilizzino account di fatturazione Cloud diversi, crea progetti diversi per ogni team. Creare gli account di fatturazione Cloud a livello organizzazione e associarvi i progetti.
  • Prenotazioni di slot. Gli slot riservati hanno come ambito la risorsa organizzazione. Dopo aver acquistato una capacità di slot prenotata, puoi assegnare un pool di slot a qualsiasi progetto o cartella all'interno dell'organizzazione oppure assegnare slot all'intera risorsa organizzazione. I progetti ereditano le prenotazioni degli slot dalla cartella principale o dall'organizzazione. Gli slot prenotati sono associati a un progetto di amministrazione, che viene utilizzato per gestire gli slot. Per maggiori informazioni, consulta Gestione dei carichi di lavoro tramite le prenotazioni.
  • Autorizzazioni. Valuta come la tua gerarchia delle autorizzazioni influisce sulle persone della tua organizzazione che devono accedere ai dati. Ad esempio, se vuoi concedere a un intero team l'accesso a dati specifici, potresti archiviare i dati in un singolo progetto per semplificare la gestione degli accessi.

    Le tabelle e altre entità ereditano le autorizzazioni del set di dati padre. I set di dati ereditano le autorizzazioni dalle entità padre nella gerarchia delle risorse (progetti, cartelle, organizzazioni). Per eseguire un'operazione su una risorsa, un utente deve disporre sia delle autorizzazioni pertinenti per la risorsa sia dell'autorizzazione per creare un job BigQuery. L'autorizzazione per creare un job è associata al progetto utilizzato per quel job.

Modelli

Questa sezione illustra due pattern comuni per organizzare le risorse di BigQuery.

  • Data lake centrale, data mart di reparto. L'organizzazione crea un progetto di archiviazione unificata per l'archiviazione dei dati non elaborati. I reparti all'interno dell'organizzazione creano i propri progetti Data Mart per l'analisi.

  • Data lake di reparto, data warehouse centrale. Ogni reparto crea e gestisce il proprio progetto di archiviazione per conservare i dati non elaborati del reparto. L'organizzazione crea quindi un progetto di data warehouse centrale per l'analisi.

Entrambi gli approcci hanno pro e contro. Molte organizzazioni combinano elementi di entrambi i pattern.

Data lake centrale, data mart di reparto

Con questo pattern, crei un progetto di archiviazione unificato in cui conservare i dati non elaborati della tua organizzazione. La pipeline di importazione dati può anche essere eseguita in questo progetto. Il progetto di archiviazione unificato funge da data lake per la tua organizzazione.

Ogni reparto ha il proprio progetto dedicato, che utilizza per eseguire query sui dati, salvare i risultati delle query e creare visualizzazioni. Questi progetti a livello di dipartimento agiscono come data mart. Sono associati all'account di fatturazione del reparto.

Modello di data lake centrale

I vantaggi di questa struttura includono:

  • Un team centralizzato di data engineering può gestire la pipeline di importazione in un unico posto.
  • I dati non elaborati sono isolati dai progetti a livello di reparto.
  • Con i prezzi on demand, la fatturazione per l'esecuzione delle query viene addebitata al reparto che le esegue.
  • Con i prezzi basati sulla capacità, puoi assegnare slot a ciascun reparto in base ai requisiti di calcolo previsti.
  • Ogni reparto è isolato dagli altri in termini di quote a livello di progetto.

Quando si utilizza questa struttura, le seguenti autorizzazioni sono tipiche:

  • Al team centrale di data engineering vengono concessi i ruoli Editor dati BigQuery e Utente job BigQuery per il progetto di archiviazione. Ciò consente loro di importare e modificare i dati nel progetto di archiviazione.
  • Agli analisti di dipartimento è concesso il ruolo di Visualizzatore dati BigQuery per set di dati specifici nel progetto Ciò consente loro di eseguire query sui dati, ma non di aggiornare o eliminare i dati non elaborati.
  • Agli analisti di dipartimento viene concesso anche il ruolo Editor dati BigQuery e Utente job per il progetto Data Mart del loro reparto. Ciò consente loro di creare e aggiornare tabelle nel progetto ed eseguire job di query al fine di trasformare e aggregare i dati per l'utilizzo specifico del reparto.

Per ulteriori informazioni, consulta Ruoli e autorizzazioni di base.

Data lake dei dipartimenti, data warehouse centrale

Con questo pattern, ciascun reparto crea e gestisce il proprio progetto di archiviazione, che contiene i dati non elaborati di quel reparto. Un progetto di data warehouse centrale archivia aggregazioni o trasformazioni di dati non elaborati.

Gli analisti possono eseguire query e leggere i dati aggregati del progetto di data warehouse. Il progetto di data warehouse fornisce inoltre un livello di accesso per gli strumenti di business intelligence (BI).

Modello di data lake dei dipartimenti

I vantaggi di questa struttura includono:

  • La gestione dell'accesso ai dati a livello di reparto è più semplice, utilizzando progetti separati per ciascun reparto.
  • Un team centrale di analisi dispone di un unico progetto per l'esecuzione dei job di analisi, il che semplifica il monitoraggio delle query.
  • Gli utenti possono accedere ai dati da uno strumento BI centralizzato, che viene mantenuto isolato dai dati non elaborati.
  • È possibile assegnare slot al progetto di data warehouse per gestire tutte le query da analisti e strumenti esterni.

Quando si utilizza questa struttura, le seguenti autorizzazioni sono tipiche:

  • I data engineer ricevono i ruoli BigQuery Data Editor e BigQuery Job User nel data mart del loro reparto. Questi ruoli consentono loro di importare e trasformare i dati nel proprio data mart.
  • Agli analisti sono stati assegnati i ruoli Editor dati e Utente job BigQuery nel progetto data warehouse. Questi ruoli consentono loro di creare viste aggregate nel data warehouse ed eseguire job di query.
  • Agli account di servizio che collegano BigQuery agli strumenti BI viene concesso il ruolo Visualizzatore dati BigQuery per set di dati specifici, che possono contenere dati non elaborati provenienti dal data lake o dati trasformati nel progetto di data warehouse.

Per ulteriori informazioni, consulta Ruoli e autorizzazioni di base.

Puoi anche utilizzare funzionalità di sicurezza come le viste autorizzate e le funzioni definite dall'utente autorizzate (UDF) per rendere i dati aggregati disponibili a determinati utenti senza concedere loro l'autorizzazione a visualizzare i dati non elaborati nei progetti Datamart.

Questa struttura di progetto può generare molte query in parallelo nel progetto di data warehouse. Di conseguenza, potresti raggiungere il limite di query simultanee. Se adotti questa struttura, ti consigliamo di aumentare il limite di quota per il progetto. Valuta anche la possibilità di utilizzare la fatturazione basata sulla capacità, in modo da poter acquistare un pool di slot per eseguire le query.