Best practice per i carichi di lavoro multi-tenant su BigQuery

Questo documento fornisce tecniche e best practice per pattern comuni utilizzati nelle piattaforme di dati multi-tenant e nei data mart aziendali.

Le imprese commerciali, i fornitori di software as a service (SaaS) e le organizzazioni governative devono spesso ospitare in modo sicuro i dati interni e di terze parti in diversi confini geografici e amministrativi. BigQuery è uno strumento potente che può soddisfare in modo coerente i requisiti delle piattaforme multi-tenant per exabyte di dati e centinaia di migliaia di utenti di dati in unità aziendali diverse. Questo documento è rivolto alle organizzazioni che implementano piattaforme multi-tenant su BigQuery e che vogliono comprendere i controlli di accesso e le funzionalità di gestione del rendimento disponibili.

I creator di piattaforme multi-tenant devono spesso trovare un equilibrio tra le considerazioni relative a quanto segue:

• Isolamento dei dati: implementa controlli rigorosi per impedire la fuga di dati tra gli utenti.
• Rendimento costante: configura e ripartisce le prenotazioni BigQuery per mantenere un rendimento costante tra i tenant.
• Gestione delle risorse: pianifica l'impatto di quote e limiti.
• Distribuzione geografica: individua i dati nelle località geografiche designate e richieste. Per problemi relativi alla conformità, consulta le offerte di conformità di Google Cloud.
• Controllo e sicurezza: proteggi i dati del tenant da accessi e esfiltrazioni inappropriati.
• Gestione dei costi: assicurati che i costi di BigQuery per ospitare ogni tenant siano coerenti.
• Complessità operativa: riduci al minimo la variabilità del sistema necessaria per ospitare nuovi tenant.

Fornitore SaaS con infrastruttura tenant condivisa

I fornitori SaaS che ospitano dati di terze parti devono garantire l'affidabilità e l'isolamento dell'intero parco risorse dei clienti. Questi clienti potrebbero essere decine di migliaia e i dati dei clienti potrebbero essere accessibili tramite l'infrastruttura dei servizi condivisi. Alcuni fornitori SaaS gestiscono anche un datastore centralizzato e sanificato per eseguire analisi nell'intera flotta di tenant.

Un design basato su set di dati per tenant aiuta a mitigare i seguenti problemi riscontrati da un'organizzazione quando esegue la scalabilità a migliaia di tenant:

• Complessità amministrativa: il numero totale di nuovi progetti e risorse cloud per cliente
• Latenza end-to-end: indica quanto è aggiornato il datastore sia per i tenant sia per le soluzioni di analisi cross-customer
• Aspettative di rendimento: assicurati che il rendimento del tenant rimanga nei limiti accettabili

Configura i set di dati per ogni tenant

In un progetto dedicato allo stoccaggio dei dati dei clienti, i dati di ciascun cliente sono separati dai set di dati BigQuery. All'interno dell'organizzazione ospitante, utilizzi un secondo progetto per implementare l'analisi e il machine learning sui dati combinati dei clienti. Puoi quindi configurare il motore di elaborazione dei dati, Dataflow, per eseguire la scrittura doppia dei dati in arrivo nelle tabelle interne e specifiche dell'utente. La configurazione di Dataflow utilizza tabelle completamente scritte anziché viste autorizzate. L'utilizzo di tabelle completamente scritte consente una gestione uniforme della distribuzione geografica e aiuta a evitare di raggiungere i limiti di visualizzazione autorizzati quando il numero di tenant aumenta.

La separazione di archiviazione e computing di BigQuery ti consente di configurare meno progetti rispetto ai data warehouse basati su cluster per gestire problemi come i livelli di servizio e l'isolamento dei dati. Se non hai bisogno di configurare i tenant con risorse aggiuntive del cloud dedicato, ti consigliamo di prendere in considerazione la configurazione predefinita di un set di dati dedicato per ogni tenant. Il seguente diagramma mostra un esempio di configurazione del progetto basata su questo design consigliato:

Figura 1. Un numero costante di progetti gestisce le esigenze di dati ed elaborazione man mano che il numero di tenant aumenta.

La configurazione del progetto nella figura 1 include i seguenti progetti:

• Progetto pipeline di dati: i componenti di infrastruttura di base che ricevono, elaborano e distribuiscono i dati del tenant sono tutti pacchettizzati in un unico progetto.
• Progetto di dati tenant combinati: il progetto di dati di base che gestisce un set di dati per cliente. Si prevede che i dati del tenant vengano accessibili tramite i progetti di livello di calcolo.
• Progetti di sviluppo interno: progetti che rappresentano le risorse autogestite utilizzate dai team di analisi per valutare i dati del tenant e creare nuove funzionalità.
• Progetti di applicazioni per utenti finali: progetti che contengono risorse progettate per interagire con gli utenti finali. Ti consigliamo di utilizzare account di servizio basati sul tenant per accedere ai set di dati del tenant e di utilizzare una pipeline di compilazione solida e sicura per il deployment delle applicazioni.
• Progetti di livello di calcolo delle prenotazioni: i progetti che mappano l'attività di query del tenant alle prenotazioni BigQuery.

Condividere le prenotazioni

Le prenotazioni in questo approccio si basano sull'algoritmo di programmazione equa integrato nelle prenotazioni di BigQuery. Ogni prenotazione di livello di calcolo viene assegnata a un singolo progetto. Le query del tenant utilizzano gli slot di pianificazione equa disponibili per ogni progetto di livello di calcolo e gli slot inutilizzati di qualsiasi livello vengono riutilizzati automaticamente in un altro livello. Se un tenant ha requisiti di tempistica specifici, puoi utilizzare una coppia progetto-prenotazione dedicata a fornire un numero esatto di slot.

Configurare i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo di utilizzare i perimetri dei Controlli di servizio VPC per impedire l'esposizione accidentale dei set di dati dei tenant all'esterno dell'organizzazione Google Cloud e per impedire l'unione non autorizzata dei dati all'interno dell'organizzazione.

Perimetri

In questa configurazione, ti consigliamo di creare i seguenti perimetri di servizio:

• Pipeline di dati: un perimetro intorno ai progetti di pipeline di dati deve applicare tutti i servizi che non devono ricevere i dati del tenant.
• Dati del tenant: un perimetro attorno al progetto del set di dati del tenant e ai progetti di calcolo BigQuery del tenant. Applica tutti i servizi per impedire l'accesso dall'esterno dell'organizzazione.
• Applicazioni interne: applica tutti i servizi e utilizza livelli di accesso per concedere l'accesso alle risorse ai team dei reparti.
• Applicazioni esterne: un perimetro intorno alle tue applicazioni SaaS. Applica tutti i servizi non necessari per il funzionamento delle applicazioni.

Bridge del perimetro

In questa configurazione, ti consigliamo di creare i seguenti ponti di perimetro:

• Pipeline di dati e dati del tenant: consenti alla pipeline di scrivere dati nei set di dati del tenant.
• Pipeline di dati e applicazioni interne: consenti alla pipeline di scrivere dati nel set di dati cross-customer.
• Dati del tenant e applicazioni esterne: consente alle applicazioni rivolte all'esterno di eseguire query sui dati del tenant.
• Applicazioni esterne e applicazioni interne: consentono alle applicazioni rivolte all'esterno di elaborare i dati utilizzando i modelli sviluppati e implementati dalle applicazioni interne.

Fornitore SaaS con infrastruttura tenant dedicata

In scenari più complessi, i fornitori SaaS potrebbero implementare un'infrastruttura di calcolo dedicata per ogni tenant. In questo scenario, l'infrastruttura dedicata è responsabile dell'erogazione delle richieste relative ai dati dell'utente in BigQuery.

Un design dell'infrastruttura del tenant dedicata risolve i seguenti problemi comuni durante il deployment dell'infrastruttura per ogni tenant insieme a BigQuery:

• Accountabilità della fatturazione: monitoraggio dei costi di infrastruttura associati a ogni tenant di cui è stato eseguito il provisioning.
• Latenza end-to-end: indica quanto è aggiornato il datastore sia per i tenant sia per le soluzioni di analisi cross-customer.
• Aspettative di rendimento: assicurati che il rendimento del tenant rimanga nei limiti accettabili.

Esegui il coordinamento dei set di dati con risorse dedicate

Quando esegui il deployment dell'infrastruttura del tenant dedicata, ti consigliamo di creare una cartella principale per i progetti specifici del tenant. Poi, esegui la colocazione dei set di dati BigQuery del tenant nei progetti con le risorse dedicate che accedono a questi dati per conto del tenant. Per ridurre al minimo la latenza end-to-end per i dati del tenant, le pipeline Dataflow inseriscono i dati direttamente nei set di dati del tenant.

Questo design gestisce l'elaborazione e la distribuzione dei dati a monte, in modo simile al design dell'infrastruttura condivisa precedente. Tuttavia, i dati e le applicazioni del tenant che accedono ai dati del tenant sono organizzati in progetti specifici per il tenant (e se vuoi in cartelle dedicate al tenant) per semplificare la fatturazione e la gestione delle risorse. Il seguente diagramma mostra un esempio di configurazione del progetto basata su questo design consigliato:

Figura 2. Un progetto di pipeline di dati gestisce i dati di un singolo tenant provenienti da diversi altri progetti.

La configurazione del progetto nella figura 2 include i seguenti progetti:

• Progetto di pipeline di dati: i componenti di infrastruttura di base che ricevono, elaborano e distribuiscono i dati del tenant sono tutti pacchettizzati in un unico progetto.
• Progetti tenant dedicati: progetti che contengono tutte le risorse cloud dedicate a un singolo tenant, inclusi i set di dati BigQuery. Ti consigliamo di utilizzare Identity and Access Management (IAM) per limitare notevolmente l'ambito degli account e degli account di servizio che possono accedere ai set di dati dei clienti.
• Progetti di analisi interna: progetti che rappresentano le risorse autogestite utilizzate dai team di analisi per valutare i dati dell'utente e sviluppare nuove funzionalità.
• Progetto di networking esterno: progetto che gestisce e inoltra le richieste dei tenant ai relativi backend dedicati.

Condividere le prenotazioni

Le prenotazioni in questo approccio si basano sull'algoritmo di pianificazione equa integrato nelle prenotazioni di BigQuery. In questa configurazione, le prenotazioni del livello di calcolo vengono assegnate a ogni progetto del tenant che utilizza quel livello. Se un tenant ha requisiti di tempo specifici, puoi creare una prenotazione dedicata per fornire un numero preciso di slot a un progetto del tenant.

Utilizza i controlli IAM e disattiva la creazione di chiavi

I perimetri dei Controlli di servizio VPC potrebbero non essere appropriati per questo scenario. I limiti correlati ai progetti impediscono a un'organizzazione di utilizzare i confini del perimetro intorno ai progetti che interagiscono con i progetti del tenant. Ti consigliamo invece di utilizzare controlli IAM rigorosi e di disattivare la creazione di chiavi per proteggerti dall'accesso esterno indesiderato.

Data mart con autorità centrale

I data mart sono un tema di progettazione comune in cui i dati di analisi di base vengono archiviati in un repository centrale e i sottoinsiemi vengono condivisi in base alle linee di business. I data mart spesso contengono decine o centinaia di tenant, rappresentati come linee di business da prendere in considerazione.

Un design del data mart in BigQuery soddisfa le seguenti esigenze:

• Collaborazione sicura dei dati: condivisione dei dati con controlli tecnici per minimizzare l'accesso inappropriato tra i team.
• Governance dei dati centralizzata: assicurati che gli asset di dati principali utilizzati per i report aziendali critici siano standardizzati e convalidati.
• Attribuzione dei costi alle unità aziendali: monitoraggio e aggiustamento dell'utilizzo del calcolo da parte delle unità aziendali.

Utilizzare un repository amministrato centralmente

In questo design, i dati di base vengono acquisiti in un repository amministrato centralmente. Le visualizzazioni autorizzate, le funzioni definite dall'utente (UDF) autorizzate e i criteri delle colonne vengono spesso utilizzati insieme per condividere i dati con le linee di business, impedendo al contempo la distribuzione accidentale di dati sensibili.

I team dei progetti del tenant possono accedere ai set di dati governati centralmente in base alle loro autorizzazioni dell'account. I team utilizzano gli slot allocati ai propri progetti per creare report e set di dati derivati. Il team di dati di base utilizza le viste autorizzate per mantenere la piena proprietà del controllo dell'accesso dell'accesso alle risorse del data mart. In questa configurazione, ti consigliamo di evitare di creare più livelli di visualizzazioni sopra gli oggetti presentati dal progetto di dati di base. Il seguente diagramma mostra un esempio di configurazione del progetto in base a questo design consigliato:

Figura 3. Un progetto di dati di base gestisce un data mart centralizzato accessibile da tutta l'organizzazione.

La configurazione del progetto nella figura 3 include i seguenti progetti:

• Progetto di dati di base: il perimetro di governance per la gestione dell'accesso ai dati di base e alle visualizzazioni dei data mart. Gestisci le visualizzazioni autorizzate all'interno dei set di dati di questo progetto e concedile ai tuoi team di analisi in base all'appartenenza al gruppo.
• Infrastruttura di estrazione, trasformazione e caricamento (ETL): l'infrastruttura per l'elaborazione delle origini dati a monte nei dati di base. A seconda delle esigenze di separazione amministrativa, potresti scegliere di implementare l'infrastruttura ETL come progetto autonomo o come parte del progetto di dati di base.
• Progetti del team di analisi: i consumatori del data mart utilizzano questi progetti e il proprio accesso all'infrastruttura di cui è stato eseguito il provisioning per elaborare i dati all'interno del data mart. I progetti del team di analisi dovrebbero essere in grado di creare set di dati derivati per l'utilizzo locale.

Utilizza un design di prenotazione a due livelli

Quando utilizzi i data mart, ti consigliamo di utilizzare un design a due livelli. In un design a due livelli, assegni alla risorsa dell'organizzazione una prenotazione con un numero ridotto di slot per coprire l'utilizzo generale. Se i team hanno esigenze maggiori, assegna le prenotazioni a livello di progetto o cartella.

Configurare i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri dei controlli di servizio VPC per evitare l'esposizione accidentale dei set di dati BigQuery al di fuori della tua organizzazione Google Cloud.

Perimetri

In questa configurazione, ti consigliamo di creare i seguenti perimetri di servizio:

• Dati principali: un perimetro per proteggere i set di dati del data warehouse e del data mart.
• Pipeline di dati: un perimetro per il progetto dell'infrastruttura ETL. Se le pipeline di dati devono effettuare richieste al di fuori della tua organizzazione Google Cloud, ti consigliamo di separare questo perimetro dal perimetro dei dati di base.
• Analytics: un perimetro per creare ed eseguire il deployment di asset di analisi interni alla tua organizzazione. Questo perimetro dovrebbe avere un criterio di accesso più permissivo rispetto al perimetro dei dati di base con cui è collegato.

Bridge del perimetro

In questa configurazione, ti consigliamo di creare i seguenti ponti di perimetro:

• Pipeline di dati e dati principali: consenti alle pipeline di dati di scrivere nel progetto di dati principali.
• Dati e analisi di base: consente agli utenti dei progetti di analisi di eseguire query sulle visualizzazioni autorizzate.

Copiare i set di dati per le configurazioni multiregionali

Poiché BigQuery non consente query interregionali, non puoi utilizzare la strategia di segmentazione dei dati con viste autorizzate quando i data mart devono esistere in più regioni. In alternativa, puoi utilizzare BigQuery Data Transfer Service per copiare i set di dati pertinenti in un'altra regione. In questo scenario, crei criteri per le colonne all'interno del catalogo di dati per ogni regione aggiuntiva in cui si trovano i dati. Il seguente diagramma mostra una configurazione multiregionale:

Figura 4. Una configurazione multiregionale utilizza BigQuery Data Transfer Service per copiare i set di dati tra regioni.

La configurazione del progetto nella figura 4 include i seguenti progetti.

• Progetto di dati di base: il perimetro di governance per la gestione dell'accesso ai dati di base e alle visualizzazioni dei data mart. I dati vengono copiati e gestiti in set di dati regionali che possono essere utilizzati dai team a livello globale.
• Infrastruttura ETL: l'infrastruttura per l'elaborazione delle origini dati a monte nei dati di base. A seconda delle esigenze di separazione amministrativa, potresti scegliere di implementare l'infrastruttura ETL come progetto autonomo o come parte del progetto di dati di base.
• Progetti del team di analisi: i consumatori del data mart utilizzano questi progetti e la propria infrastruttura di provisioning per elaborare i dati all'interno dei set di dati regionali del data mart. I progetti del team di analisi dovrebbero essere in grado di creare set di dati derivati per l'utilizzo locale.

BigQuery Data Transfer Service è un componente aggiuntivo pianificato con alcune limitazioni. Il programmatore del servizio integrato è limitato a un intervallo minimo di 15 minuti e deve copiare tutte le tabelle dal set di dati di origine. Non è possibile incorporare script aggiuntivi per creare sottoinsiemi di dati specifici per regione nel programmatore di BigQuery Data Transfer Service.

Se la tua organizzazione ha bisogno di maggiore flessibilità, sono disponibili le seguenti opzioni:

• Job Cloud Composer: puoi pianificare i job Cloud Composer per emettere job ETL che creano sottoinsiemi regionali prima di attivare BigQuery Data Transfer Service tramite la sua API client. Se la tua organizzazione può supportare una latenza aggiuntiva, ti consigliamo questa opzione.
• Infrastruttura ETL: l'infrastruttura ETL, come Dataflow, può eseguire la scrittura duale di sottoinsiemi regionali nelle regioni di destinazione. Se la tua organizzazione richiede una latenza minima dei dati tra le regioni, ti consigliamo questa opzione.

Data mart con autorità decentralizzata

Utilizza l'autorità decentralizzata quando hai bisogno di una separazione amministrativa in base al proprietario del sistema, alle linee di business o a problemi geografici.

Un data mart decentralizzato presenta i seguenti problemi rispetto a un data mart standard:

• Collaborazione sicura dei dati: condivisione dei dati con controlli tecnici per minimizzare l'accesso inappropriato tra i team.
• Riscoperta dei dati: i team devono essere in grado di rilevare e richiedere accesso ai set di dati.
• Origine dei dati: senza un team di curatori centrali, i team devono essere in grado di fidarsi dell'origine dei dati che vengono inseriti nei loro prodotti di analisi.

Delegare l'amministrazione dei dati principali

Questo design è diverso da un approccio di data mart convenzionale perché l'autorità decentralizzata delega le decisioni di amministrazione dei dati di base ai sottogruppi componenti dell'organizzazione. Quando utilizzi l'autorità decentralizzata, mantieni il controllo centrale della sicurezza e della capacità di BigQuery utilizzando Cloud Key Management Service (Cloud KMS), i criteri di colonna, i Controlli di servizio VPC e le prenotazioni. In questo modo, eviti la crescita disordinata dei dati, un problema comune nei magazzini gestiti autonomamente. Il seguente diagramma mostra un'architettura che utilizza l'autorità decentralizzata:

Figura 5. Un progetto di governance di base contribuisce a garantire una sicurezza coerente, mentre i singoli gruppi mantengono le proprie operazioni sui dati.

La configurazione del progetto nella figura 5 include i seguenti progetti:

• Progetto di governance di base: il progetto responsabile dei problemi di gestione tra organizzazioni. In questo progetto crei risorse di sicurezza come keyring Cloud KMS e criteri per le colonne del catalogo di dati. Questo progetto funge da progetto di amministrazione delle prenotazioni di BigQuery, consentendo la condivisione degli slot a livello di organizzazione.
• Progetti di dati delle unità organizzative: i proprietari dei data mart autogestiti all'interno dell'organizzazione più grande. Il progetto di governance di base gestisce un ambito limitato per i progetti di dati delle unità organizzative.
• Progetti del team di analisi: i progetti utilizzati dai consumatori dei data mart. Questi progetti utilizzano la propria infrastruttura e i propri slot di provisioning per accedere ed elaborare i dati all'interno del data mart.

Utilizza un design di prenotazione a due livelli

Ti consigliamo di utilizzare lo stesso design a due livelli dei data mart standard per i tuoi data mart decentralizzati. In questa configurazione, assegni alla risorsa dell'organizzazione una prenotazione con un numero ridotto di slot per coprire l'utilizzo generale. Se i team hanno esigenze maggiori, assegna le prenotazioni a livello di progetto o cartella.

Utilizzare un catalogo di dati

Un catalogo di dati fornisce il rilevamento a livello di organizzazione, il tagging dei metadati e la configurazione dei criteri delle colonne. Il rilevamento di Dataplex crea automaticamente voci di metadati per tutte le nuove tabelle BigQuery dell'organizzazione. Le funzionalità di Dataplex aiutano anche gli amministratori della governance dei dati a identificare rapidamente nuovi asset di dati e applicare controlli appropriati.

Configurare i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri dei controlli di servizio VPC per evitare l'esposizione accidentale dei set di dati BigQuery al di fuori della tua organizzazione Google Cloud.

Perimetri

In questa configurazione, ti consigliamo di creare i seguenti perimetri di servizio:

• Dati principali: un perimetro per proteggere i set di dati del data warehouse e del data mart. Questo perimetro deve includere tutti i progetti delle unità organizzative e il progetto di governance dei dati.
• Analytics: un perimetro per creare e implementare asset di analisi interni all'organizzazione. Questo perimetro dovrebbe avere un criterio di accesso più permissivo rispetto al perimetro dei dati di base con cui è collegato.

Bridge del perimetro

In questa configurazione, ti consigliamo di creare i seguenti ponti di perimetro:

• Dati e analisi di base: consente agli utenti dei progetti di analisi di eseguire query sulle visualizzazioni autorizzate.

Condivisione dei dati tra più organizzazioni

La condivisione tra più organizzazioni è un aspetto di progettazione speciale per la progettazione di un data mart. Questo modello di condivisione dei dati è destinato alle organizzazioni che vogliono condividere in modo sicuro i propri set di dati con un'altra entità che dispone della propria organizzazione Google.

La condivisione dei dati tra più organizzazioni risolve i seguenti problemi per chi condivide i dati:

• Riservatezza della condivisione: solo la parte prevista può accedere ai dati condivisi.
• Protezione da accessi inappropriati: solo alle risorse a cui è previsto l'accesso è possibile accedere dall'esterno.
• Separazione del calcolo: le parti esterne vengono fatturate per le query che avviano.

Proteggere i progetti interni dai progetti di dati condivisi

Il design della condivisione dei dati tra più organizzazioni si concentra sulla protezione dei progetti interni dell'organizzazione dalle attività nei progetti di dati condivisi. Il progetto del set di dati condiviso funge da buffer per impedire l'accesso all'elaborazione dei dati sensibili interni, pur fornendo la possibilità di condividere i dati esternamente.

Le query avviate dal progetto esterno utilizzano le risorse di calcolo del progetto che le richiama. Se tutti i set di dati sottoposti a query condividono la stessa regione Google Cloud, queste query possono unire i dati di più organizzazioni. Il seguente diagramma mostra come i set di dati vengono condivisi in una configurazione di progetto multi-organizzazione:

Figura 6. Un'organizzazione esterna esegue query sui dati di più set di dati in progetti condivisi.

La configurazione del progetto nella figura 6 include i seguenti progetti:

• Progetto interno dell'organizzazione: il progetto contenente dati interni sensibili. Il progetto interno può condividere i dati esternamente copiandoli nei set di dati del progetto di dati condivisi. Il progetto interno deve possedere l'account di servizio responsabile dell'aggiornamento dei dati condivisi.
• Progetto di dati condivisi: il progetto contenente le informazioni sanitize che vengono copiate dal progetto interno. Utilizza i gruppi di utenti esterni per gestire l'accesso da parte di terze parti. In questo scenario, gestisci l'appartenenza al gruppo come funzione amministrativa e concedi agli account esterni l'autorizzazione di visualizzatore in modo che possano accedere al set di dati tramite questi gruppi.

Configurare i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri dei Controlli di servizio VPC per condividere i dati esternamente e per impedire l'esposizione accidentale dei set di dati BigQuery al di fuori dei progetti interni.

Perimetri

In questa configurazione, ti consigliamo di creare i seguenti perimetri di servizio:

• Dati interni: un perimetro per proteggere gli asset di dati principali. Controlli di servizio VPC applica l'accesso a BigQuery.
• Dati condivisi esternamente: un perimetro per ospitare set di dati che possono essere condivisi con organizzazioni esterne. Questo perimetro disattiva l'applicazione dell'accesso a BigQuery.

Bridge del perimetro

In questa configurazione, ti consigliamo di creare il seguente bridge perimetrale:

• Dati interni a dati esterni: un bridge del perimetro consente ai progetti di dati interni più protetti di esportare i dati in progetti di condivisione dei dati esterni.

Considerazioni aggiuntive nei sistemi multi-tenant

Questa sezione fornisce un approfondimento sui casi speciali che puoi prendere in considerazione insieme alle best practice precedenti.

Limiti e quote delle risorse Google Cloud

• Gli account di servizio sono limitati a una quota flessibile di 100 account di servizio per progetto. Puoi richiedere una quota tramite Google Cloud Console per i progetti che gestiscono gli account di servizio del tenant.
• La concorrenza di BigQuery ha una concorrenza predefinita di 100 query per progetto che esegue query (i progetti che contengono set di dati non hanno questi limiti). Per aumentare questa quota flessibile, contatta il tuo rappresentante di vendita.
• Controlli di servizio VPC ha un limite di 10.000 progetti all'interno dei perimetri di servizio a livello di organizzazione. Se i tuoi progetti per tenant hanno un elevato scaling up, ti consigliamo di utilizzare un design per set di dati per tenant.
• Controlli di servizio VPC ha un limite di 100 perimetri, inclusi i bridge, per organizzazione.

Utilizzo di viste autorizzate o tabelle di sottoinsiemi materializzate

Per gestire l'accesso del tenant a sottoinsiemi di tabelle di fatti di grandi dimensioni, puoi utilizzare viste autorizzate specifiche del tenant o creare tabelle di sottoinsiemi specifiche del tenant. La tabella seguente fornisce un confronto di questi approcci:

Funzionalità	Visualizzazioni autorizzate	Tabelle di sottoinsiemi
Numero di tenant supportati	Esiste un limite massimo di 2500 risorse autorizzate per set di dati.	Le risorse autorizzate includono visualizzazioni autorizzate, set di dati autorizzati e funzioni autorizzate.Non esistono limiti al numero di set di dati in un progetto o di tabelle in un set di dati.
Partizionamento e clustering	Le viste autorizzate devono condividere lo schema di partizione e cluster comune della tabella di base. Per migliorare il rendimento della segmentazione dei tenant, ti consigliamo di aggregare la tabella principale in base all'ID tenant.	Puoi partizionare la tabella del sottoinsieme e raggrupparla in base alle esigenze del tenant.
Aree geografiche	Le viste autorizzate non possono attraversare regioni e devono trovarsi nella regione Google Cloud della tabella di base. La regionalizzazione interessa gli utenti con sede geografica remota.	Le tabelle di sottoinsiemi possono esistere nella regione più appropriata per il tenant. Potrebbero essere applicati costi aggiuntivi.
Applicazione delle norme relative alle colonne	I criteri delle colonne applicati a una tabella di base vengono applicati a tutte le visualizzazioni autorizzate, indipendentemente dalle autorizzazioni su queste visualizzazioni.	Per ogni tabella del sottoinsieme deve essere applicato il criterio della colonna affinché venga applicato.
Logging dell'accesso ai dati	I log di accesso ai dati vengono riportati nel logging della tabella di base.	L'accesso a ogni tabella del sottoinsieme viene registrato separatamente.
Flessibilità della trasformazione	Le viste autorizzate consentono di ridisegnare immediatamente l'oggetto a cui accedono gli utenti.	Per modificare le tabelle dei sottoinsiemi sono necessarie modifiche complesse allo schema.

Controllo per i dati sensibili

Per impedire l'accesso non autorizzato ai dati, BigQuery offre diverse funzionalità aggiuntive oltre alle autorizzazioni IAM standard.

Crittografia fornita dal cliente

La crittografia dei dati client riguarda i casi in cui un'organizzazione di hosting archivia ed elabora i dati per conto di un tenant, ma non può accedere ad alcuni dei contenuti dei dati. Ad esempio, all'organizzazione ospitante potrebbe essere impedito di accedere ai dati personali o del dispositivo considerati sensibili.

Consigliamo al mittente dei dati di utilizzare chiavi di crittografia AEAD della libreria Tink open source per criptare i dati sensibili. Le chiavi di crittografia AEAD della libreria Tink sono compatibili con le funzioni AEAD di BigQuery. Il tenant può quindi decriptare i dati accedendo al materiale della chiave in un UDF autorizzato o passando il materiale della chiave come parametro di query a BigQuery, dove l'organizzazione host non può registrare la chiave.

Criteri di accesso alle colonne

Nei data mart multi-tenant, i criteri delle colonne vengono spesso utilizzati per impedire la fuga accidentale di contenuti sensibili tra i team che collaborano. Le visualizzazioni autorizzate sono il meccanismo preferito per condividere i dati tra i team in uno scenario di data mart. Le visualizzazioni autorizzate non possono concedere l'accesso a una colonna protetta.

Quando imposti il criterio per applicare il controllo dell'accesso#39;accesso, impedisci l'accesso agli utenti a cui non è stato concesso il ruolo Lettore granulare nel criterio. Anche se il criterio non viene applicato, registra tutto l'accesso degli utenti alla colonna classificata.

Sensitive Data Protection

Sensitive Data Protection fornisce API e utilità di scansione che ti aiutano a identificare e mitigare i contenuti sensibili archiviati all'interno dei set di dati BigQuery o Cloud Storage. Le organizzazioni in scenari multi-tenant utilizzano spesso l'API DLP (parte di Sensitive Data Protection) per identificare e, facoltativamente, tokenizzare i dati sensibili prima che vengano archiviati.

Gestione delle prenotazioni di slot

La gestione delle prenotazioni nei sistemi multi-tenant consente di controllare i costi man mano che i tenant vengono scalati e garantisce prestazioni garantite per ogni tenant.

Per gestire le prenotazioni, ti consigliamo di creare un unico progetto amministrativo per le prenotazioni. Gli impegni per gli slot acquistati nello stesso progetto amministrativo sono condivisibili tra tutte le reservations che hanno origine dal progetto amministrativo. Un progetto che utilizza gli impegni per gli slot può essere assegnato a una sola prenotazione alla volta. Tutte le query che provengono da un progetto condividono gli slot in base alle risorse disponibili.

Per assicurarti che gli obiettivi del livello di servizio (SLO) del tenant vengano raggiunti, puoi monitorare le prenotazioni tramite Cloud Logging e lo schema di informazioni di BigQuery. Le organizzazioni che registrano periodi di picco a causa dell'attività degli analisti o dei job con priorità possono allocare una capacità aggiuntiva utilizzando gli slot flessibili.

Prenotazioni come livelli di calcolo del tenant

I fornitori di SaaS che hanno da decine a molte migliaia di tenant configurano comunemente un numero limitato di prenotazioni BigQuery come risorse condivise.

Se sei un fornitore SaaS con un'infrastruttura tenant condivisa, ti consigliamo di dedicare ogni prenotazione a un singolo progetto e di raggruppare i tenant per condividere il progetto per il calcolo di BigQuery. Questo design riduce l'overhead amministrativo derivante dalla presenza di migliaia di progetti e prenotazioni aggiuntivi, consentendo al contempo alla tua organizzazione di allocare una capacità minima degli slot necessaria per soddisfare le esigenze di prestazioni previste per la prenotazione.

Se la puntualità dell'elaborazione dei dati ELT è una priorità assoluta, ti consigliamo di allocare una prenotazione per gestire l'elaborazione. Per evitare di utilizzare slot aggiuntivi che potrebbero essere utilizzati per carichi di lavoro ad hoc, imposta la prenotazione su ignora gli slot inattivi.

Di seguito è riportato un esempio di come configurare le prenotazioni come livelli di calcolo del tenant:

• Elaborazione dati: 2000 slot, ignora inattività. Questa prenotazione è configurata per soddisfare gli SLO di elaborazione dei dati.
• Progetti interni: 1000 slot, consenti inattività. Questa prenotazione viene applicata ai progetti utilizzati per l'analisi interna.Gli slot vengono riutilizzati se rimangono disponibili dopo l'elaborazione dei dati o i livelli di calcolo.
• Livello di calcolo basso: 2000 slot, ignora inattività. Questa prenotazione viene applicata agli utenti con risorse limitate. A differenza del livello alto, questa prenotazione ignora gli slot inattivi.
• Livello di calcolo elevato: 3000 slot, consenti inattività. Questa prenotazione viene applicata agli utenti con risorse elevate. Per velocizzare le query, gli slot inattivi di altre prenotazioni vengono applicati automaticamente.

Se i tuoi tenant operano su un'infrastruttura dedicata, ti consigliamo di assegnare la cartella o il progetto designato alla prenotazione condivisa appropriata.

Prenotazioni per team

Quando collabori con team in un ambiente di data mart, ti consigliamo di creare una prenotazione per ogni team che richiede risorse di calcolo aggiuntive. Quindi, assegna la prenotazione alla cartella principale che contiene i progetti del team. Tutti i nuovi progetti per il team utilizzano gli spazi della pianificazione equa con la stessa allocazione delle risorse.

Di seguito è riportato un esempio di come configurare le prenotazioni per team:

• Prenotazione a livello di organizzazione: 500 slot, consenti inattività. Questa prenotazione viene assegnata all'organizzazione di primo livello e offre slot a qualsiasi utente BigQuery che non utilizza un progetto con una prenotazione dedicata.
• Elaborazione dei dati: 1000 slot, ignora inattività. Questa prenotazione è configurata per soddisfare gli SLO minimi per l'elaborazione dei dati.
• Amministrazione dei dati principali: 500 slot, consenti inattività. Questa prenotazione viene applicata ai progetti utilizzati per l'amministrazione interna. Gli slot vengono riutilizzati se rimangono inutilizzati dai livelli di calcolo o di elaborazione dei dati.
• Prenotazioni per l'elaborazione di Analytics: 500 slot, consenti inattività. Si tratta di una prenotazione dedicata assegnata a un team di analisi.

Requisiti di hosting multiregionale

I requisiti di hosting multiregionale sono in genere dovuti alla necessità di ridurre la latenza dei dati per i consumatori o di soddisfare i mandati normativi.

I progetti in Google Cloud sono considerati globali e possono eseguire il provisioning delle risorse in qualsiasi regione. BigQuery considera i set di dati, le norme per le colonne e gli impegni relativi agli slot come risorse regionali. Gli slot possono accedere solo ai set di dati nella regione locale e i criteri delle colonne possono essere applicati solo alle tabelle all'interno dei set di dati locali. Per utilizzare i prezzi basati sulla capacità, devi acquistare slot in ogni regione che contiene set di dati.

Per indicazioni su come rispettare i requisiti normativi, rivolgiti al tuo rappresentante di vendita.

Passaggi successivi

• Scopri le best practice per l'IAM.