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

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

Le aziende commerciali, i fornitori di Software as a Service (SaaS) e le organizzazioni governative devono spesso ospitare in modo sicuro dati interni e di terze parti oltre i confini geografici e amministrativi. BigQuery è un potente strumento in grado di soddisfare in modo coerente i requisiti della piattaforma multi-tenant per exabyte di dati e centinaia di migliaia di consumatori di dati nelle diverse unità aziendali. Questo documento è rivolto alle organizzazioni che eseguono il deployment di piattaforme multi-tenant su BigQuery e che vogliono conoscere i controlli dell'accesso e le funzionalità di gestione delle prestazioni disponibili.

Gli strumenti per la creazione di piattaforme multi-tenant spesso devono trovare un equilibrio tra le seguenti considerazioni:

• Isolamento dei dati: implementa controlli efficaci per prevenire le fughe di dati tra i tenant.
• Prestazioni costanti: configura e distribuisci prenotazioni BigQuery per mantenere prestazioni coerenti tra i tenant.
• Gestione delle risorse: pianifica l'impatto di quote e limiti.
• Distribuzione geografica: individua i dati nelle località geografiche designate e obbligatorie. Per problemi di conformità, consulta le offerte di conformità di Google Cloud.
• Controllo e sicurezza: proteggi i dati del tenant da esfiltrazioni e accessi inappropriati.
• Gestione dei costi: assicurati costi di BigQuery coerenti per ospitare ogni tenant.
• Complessità operativa: riduci al minimo la variabilità del sistema necessaria per ospitare nuovi tenant.

Fornitore SaaS con infrastruttura tenant condivisa

I fornitori di SaaS che ospitano dati di terze parti devono garantire l'affidabilità e l'isolamento dell'intero parco clienti. Questi clienti potrebbero essere decine di migliaia e i dati dei clienti potrebbero essere accessibili attraverso l'infrastruttura di servizi condivisi. Alcuni fornitori di SaaS dispongono inoltre di un datastore centralizzato sanitizzato per eseguire analisi sull'intero parco di tenant.

La progettazione di un set di dati per tenant aiuta a mitigare i seguenti problemi riscontrati da un'organizzazione quando scala a migliaia di tenant:

• Complessità amministrativa: numero totale di nuovi progetti e risorse cloud in base al cliente
• Latenza end-to-end: il livello di aggiornamento del datastore sia per i tenant che per le soluzioni di analisi tra clienti
• Aspettative di prestazioni: garantire che le prestazioni dei tenant restino entro limiti accettabili

Configura i set di dati per ogni tenant

All'interno di un progetto dedicato all'archiviazione dei dati dei clienti, i dati di ogni cliente sono separati da set di dati BigQuery. All'interno dell'organizzazione host, utilizzi un secondo progetto per il deployment di analisi e machine learning su dati combinati dei clienti. Puoi quindi configurare il motore di elaborazione dati, Dataflow, per la doppia scrittura dei dati in entrata nelle tabelle interne e specifiche per il tenant. La configurazione Dataflow utilizza tabelle completamente scritte anziché visualizzazioni autorizzate. L'utilizzo di tabelle completamente scritte consente una gestione uniforme della distribuzione geografica e consente di evitare di raggiungere i limiti di visualizzazioni autorizzati quando il numero di tenant viene scalato.

La separazione tra archiviazione e compute di BigQuery ti consente di configurare meno progetti rispetto ai warehouse basati su cluster per gestire problemi come i livelli di servizio e l'isolamento dei dati. Quando non è necessario configurare i tenant con risorse cloud dedicate aggiuntive, ti consigliamo di considerare la configurazione predefinita di un set di dati dedicato per ogni tenant. Il seguente diagramma mostra un esempio di configurazione di progetto basata su questo progetto consigliato:

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

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

• Progetto della pipeline di dati: i componenti di base dell'infrastruttura che ricevono, elaborano e distribuiscono i dati del tenant sono tutti pacchettizzati in un unico progetto.
• Progetto di dati tenant combinato: il progetto di dati principali che gestisce un set di dati per cliente. Ai dati tenant è previsto l'accesso tramite progetti di livello Compute.
• Progetti di sviluppo interno: progetti che rappresentano le risorse autogestite che i team di analisi utilizzano per valutare i dati del tenant e creare nuove funzionalità.
• Progetti di applicazioni per l'utente finale: progetti che contengono risorse progettate per interagire con gli utenti finali. Ti consigliamo di utilizzare account di servizio con ambito tenant per accedere ai set di dati tenant e di utilizzare una pipeline di creazione solida e sicura per eseguire il deployment delle applicazioni.
• Progetti di livello di computing di prenotazione: i progetti che mappano l'attività di query del tenant alle prenotazioni BigQuery.

Condividi le prenotazioni

Le prenotazioni con questo approccio si basano sull'algoritmo di pianificazione equilibrata integrato nelle prenotazioni BigQuery. Ogni prenotazione del livello di computing è assegnata a un singolo progetto. Le query tenant utilizzano slot di pianificazione equa disponibili per ogni progetto del livello di computing e gli slot non utilizzati di qualsiasi livello vengono riutilizzati automaticamente in un altro livello. Se un tenant ha requisiti di tempo specifici, puoi utilizzare una coppia di prenotazione-progetto destinata a fornire un numero esatto di slot.

Configura i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per impedire l'esposizione accidentale dei set di dati tenant al di fuori della tua organizzazione Google Cloud e per impedire l'unione di dati non autorizzati all'interno dell'organizzazione.

Perimetri

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

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

Ponti perimetrali

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

• Dati della pipeline di dati e del tenant: consentono alla pipeline di scrivere dati nei set di dati tenant.
• pipeline di dati e applicazioni interne: consentono alla pipeline di scrivere dati nel set di dati tra clienti.
• Applicazioni esterne e dati tenant: consenti alle applicazioni rivolte all'esterno di eseguire query sui dati del tenant.
• Applicazioni esterne e applicazioni interne: consenti alle applicazioni rivolte all'esterno di elaborare i dati utilizzando modelli sviluppati e distribuiti dalle applicazioni interne.

Fornitore SaaS con infrastruttura tenant dedicata

In scenari più complessi, i fornitori di SaaS potrebbero eseguire il deployment di un'infrastruttura di computing dedicata per ogni tenant. In questo scenario, l'infrastruttura dedicata è responsabile della gestione delle richieste per i dati del tenant all'interno di BigQuery.

Una progettazione di un'infrastruttura tenant dedicata risponde alle seguenti preoccupazioni comuni durante il deployment dell'infrastruttura per ogni tenant insieme a BigQuery:

• Responsabilità della fatturazione: monitoraggio dei costi dell'infrastruttura associati a ogni tenant che ha effettuato l'onboarding.
• Latenza end-to-end: il livello di aggiornamento del datastore sia per i tenant che per le soluzioni di analisi tra clienti.
• Aspettative di prestazioni: garantire che le prestazioni dei tenant rimangano entro limiti accettabili.

Colocalizza set di dati con risorse dedicate

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

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

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

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

• Progetto di pipeline di dati: i componenti di base dell'infrastruttura che ricevono, elaborano e distribuiscono i dati del tenant sono tutti pacchettizzati in un unico progetto.
• Progetti tenant dedicati: progetti contenenti 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 di account e account di servizio che possono accedere ai set di dati dei clienti.
• Progetti di analisi interni: progetti che rappresentano le risorse autogestite che i team di analisi utilizzano per valutare i dati del tenant e creare nuove funzionalità.
• Progetto di networking esterno: progetto che gestisce e instrada le richieste dei tenant ai propri backend dedicati.

Condividi le prenotazioni

Le prenotazioni con questo approccio si basano sull'algoritmo di pianificazione equo integrato nelle prenotazioni BigQuery. In questa configurazione, le prenotazioni a livello di computing vengono assegnate a ciascun progetto 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 tenant.

Utilizza i controlli IAM e disabilita la creazione delle chiavi

I perimetri dei Controlli di servizio VPC potrebbero non essere appropriati per questo scenario. I limiti relativi ai progetti impediscono a un'organizzazione di utilizzare i confini perimetrali intorno ai progetti che interagiscono con i progetti tenant. Ti consigliamo invece di utilizzare controlli IAM rigorosi e di disabilitare la creazione di chiavi per proteggerti da accessi esterni indesiderati.

Data mart con l'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 sono condivisi lungo le linee di business. I data mart hanno spesso decine o centinaia di tenant, rappresentati come linee di business da prendere in considerazione.

Una progettazione di data mart in BigQuery soddisfa le seguenti esigenze:

• Collaborazione sicura sui dati: condivisione dei dati con controlli tecnici per ridurre al minimo l'accesso inappropriato tra i team.
• Governance dei dati centrale: garantisce che gli asset di dati principali utilizzati per i report aziendali critici siano standardizzati e convalidati.
• Attribuzione dei costi per le unità aziendali: monitorare e regolare l'utilizzo del calcolo in base alle unità aziendali.

Utilizza un repository amministrato centralmente

In questa progettazione, i dati principali vengono acquisiti in un repository amministrato centralmente. Le viste autorizzate, le funzioni definite dall'utente (UDF) autorizzate e i criteri delle colonne vengono spesso utilizzati insieme per condividere dati con i settori di attività, impedendo al contempo la distribuzione accidentale di dati sensibili.

I team nei progetti tenant possono accedere a set di dati regolati centralmente in base alle autorizzazioni del proprio account. I team usano gli slot assegnati ai propri progetti per creare report e set di dati derivati. Il team dedicato ai dati principali utilizza le viste autorizzate per mantenere la proprietà completa del controllo dell'accesso dell'accesso alle risorse del data mart. In questa configurazione, consigliamo di evitare di creare più livelli di viste sugli oggetti presentati nel progetto di dati di base. Il seguente diagramma mostra una configurazione di progetto di esempio basata su questo design consigliato:

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

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

• Progetto dati principali: il perimetro di governance per la gestione dell'accesso ai dati principali e le viste Data Mart. Manterrai le viste autorizzate all'interno dei set di dati all'interno di questo progetto e concedi le viste autorizzate ai tuoi team di analisi in base all'appartenenza ai gruppi.
• Infrastruttura ETL (estrazione, trasformazione e caricamento): infrastruttura per l'elaborazione delle origini dati upstream nei dati principali. A seconda delle esigenze di separazione amministrativa, potresti scegliere di eseguire il deployment dell'infrastruttura ETL come progetto proprio o come parte del progetto di dati principali.
• Progetti del team Analytics: i consumatori del Data Mart utilizzano questi progetti e utilizzano il proprio accesso all'infrastruttura di cui è stato eseguito il provisioning per elaborare i dati nel Data Mart. I progetti del team di Analytics sono in grado di creare set di dati derivati

Utilizza un design di prenotazione a due livelli

Quando lavori con i data mart, ti consigliamo di utilizzare una progettazione a due livelli. In una progettazione 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 prenotazioni a livello di progetto o cartella.

Configura i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per impedire 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 di infrastruttura ETL. Se le pipeline di dati devono effettuare richieste al di fuori della tua organizzazione Google Cloud, ti consigliamo di separare questo perimetro da quello dei dati principali.
• Analytics: un perimetro per creare ed eseguire il deployment di asset di analisi interni alla tua organizzazione. Si prevede che questo perimetro abbia un criterio di accesso più permissivo rispetto al perimetro dei dati principali con cui è collegato.

Ponti perimetrali

In questa configurazione, consigliamo di creare i seguenti ponti perimetrali:

• Pipeline di dati e dati di base: consente la scrittura delle pipeline di dati nel progetto di dati principali.
• Dati e analisi principali: consentono agli utenti dei progetti di analisi di eseguire query sulle viste autorizzate.

Copia set di dati per configurazioni multiregionali

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

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

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

• Progetto dati principali: il perimetro di governance per la gestione dell'accesso ai dati principali e le viste Data Mart. I dati vengono copiati e conservati in set di dati regionali che possono servire i team a livello globale.
• Infrastruttura ETL: infrastruttura per l'elaborazione di origini dati upstream nei dati principali. A seconda delle esigenze di separazione amministrativa, potresti scegliere di eseguire il deployment dell'infrastruttura ETL come progetto proprio o come parte del progetto di dati principali.
• Progetti del team di analisi: i consumatori del data mart utilizzano questi progetti e la propria infrastruttura di cui è stato eseguito il provisioning per elaborare i dati all'interno dei set di dati regionali del data mart. Si prevede che i progetti dei team di analisi siano in grado di creare set di dati derivati per l'uso locale.

BigQuery Data Transfer Service è un componente pianificato aggiuntivo con alcune limitazioni. Lo scheduler 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 nello scheduler di BigQuery Data Transfer Service.

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

• Job Cloud Composer: puoi pianificare job Cloud Composer in modo che vengano emessi job ETL che creano sottoinsiemi a livello di regione prima di attivare BigQuery Data Transfer Service tramite la relativa API client. Ti consigliamo questa opzione se la tua organizzazione può supportare un'ulteriore latenza.
• Infrastruttura ETL: l'infrastruttura ETL, come Dataflow, può eseguire la doppia scrittura di sottoinsiemi regionali nelle aree geografiche di destinazione. Ti consigliamo questa opzione se la tua organizzazione richiede una latenza minima tra le regioni.

Data mart con autorità decentralizzata

Utilizza l'autorità decentralizzata quando hai bisogno della separazione amministrativa in base al proprietario del sistema, al settore di attività o a problemi geografici.

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

• Collaborazione sicura sui dati: condivisione dei dati con controlli tecnici per ridurre al minimo l'accesso inappropriato tra i team.
• Rilevabilità dei dati: i team devono essere in grado di scoprire e richiedere l'accesso ai set di dati.
• Origine dei dati: senza un team di curatori centrale, i team devono essere in grado di fidare dell'origine dei dati inseriti nei loro prodotti di analisi.

Delega l'amministrazione dei dati principali

Questo design è diverso da un approccio convenzionale di data mart perché l'autorità decentralizzata delega le decisioni principali di amministrazione dei dati a sottogruppi di 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 delle colonne, i Controlli di servizio VPC e le prenotazioni. Pertanto, eviterai la proliferazione di dati comune ai warehouse autogestiti. Il seguente diagramma mostra un'architettura che utilizza l'autorità decentralizzata:

Figura 5. Un progetto di governance di base garantisce una sicurezza coerente, mentre i singoli gruppi gestiscono le operazioni sui dati.

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

• Progetto di governance principale: il progetto responsabile di problemi di gestione tra organizzazioni. In questo progetto creerai risorse di sicurezza come i keyring Cloud KMS e i criteri delle colonne del catalogo dati. Questo progetto funge da progetto di amministrazione delle prenotazioni BigQuery, consentendo la condivisione degli slot a livello di organizzazione.
• Progetti relativi ai dati delle unità organizzative: proprietari di data mart autogestiti all'interno dell'organizzazione più ampia. Il progetto di governance principale gestisce un ambito limitato per i progetti relativi ai dati dell'unità organizzativa.
• Progetti del team di Analytics: i progetti utilizzati dai consumatori dei data mart. Questi progetti usano la propria infrastruttura e i propri slot, di cui è stato eseguito il provisioning, per accedere ai dati ed elaborarli nel data mart.

Utilizza un design di prenotazione a due livelli

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

Utilizzare un catalogo dati

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

Configura i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per impedire 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 la creazione e il deployment di asset di analisi all'interno dell'organizzazione. Si prevede che questo perimetro abbia un criterio di accesso più permissivo rispetto al perimetro dei dati principali con cui è collegato.

Ponti perimetrali

In questa configurazione, consigliamo di creare i seguenti ponti perimetrali:

• Dati e analisi principali: consentono agli utenti dei progetti di analisi di eseguire query sulle viste autorizzate.

Condivisione dei dati all'interno di più organizzazioni

La condivisione tra più organizzazioni è una considerazione speciale per la progettazione di un data mart. Questa struttura di condivisione dei dati è pensata per le organizzazioni che vogliono condividere in modo sicuro i propri set di dati con un'altra entità che ha una propria organizzazione Google.

La condivisione dei dati multi-organizzazione risponde alle seguenti preoccupazioni per chi condivide i dati:

• Riservatezza della condivisione: solo la parte interessata può accedere ai dati condivisi.
• Protezione da accessi inappropriati: solo le risorse il cui accesso è previsto sono accessibili dall'esterno.
• Separazione calcolo: le parti esterne ricevono i costi per le query avviate.

Nota: in alcuni casi, le query provenienti dall'organizzazione esterna possono avere esito negativo inaspettatamente. L'assistenza clienti Google Cloud può aiutarti ad avviare una modifica della configurazione per risolvere il problema.

Proteggi i progetti interni da progetti di dati condivisi

La progettazione della condivisione dei dati multi-organizzazione è incentrata sulla protezione dei progetti interni dell'organizzazione dall'attività dei progetti di dati condivisi. Il progetto del set di dati condiviso agisce come buffer per non consentire l'accesso al trattamento dati interno sensibile, fornendo al contempo la possibilità di condividere i dati esternamente.

Le query che vengono avviate dal progetto esterno utilizzano le risorse di calcolo del progetto che richiama il progetto. 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 vengono condivisi i set di dati nell'ambito di una configurazione di progetto multi-organizzazione:

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

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

• Progetto interno dell'organizzazione: il progetto che contiene dati interni sensibili. Il progetto interno può condividere i dati esternamente copiando i dati sottoposti a sanitizzazione nei set di dati del progetto. Il progetto interno deve essere proprietario dell'account di servizio responsabile dell'aggiornamento dei dati condivisi.
• Progetto di dati condivisi: il progetto contenente le informazioni sottoposte a sanitizzazione copiate dal progetto interno. Utilizza i gruppi di utenti esterni per gestire l'accesso da parte di soggetti esterni. In questo scenario, gestisci l'appartenenza ai gruppi come funzione amministrativa e concedi agli account esterni l'autorizzazione di visualizzazione in modo che possano accedere al set di dati attraverso questi gruppi.

Configura i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per condividere i dati esternamente e impedire l'esposizione accidentale dei set di dati BigQuery al di fuori dei tuoi 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 impone 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 forzata dell'accesso a BigQuery.

Ponti perimetrali

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

• Dati da interni a esterni: un bridge del perimetro consente ai progetti di dati interni più protetti di inviare i dati in uscita verso progetti di condivisione 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 di Google Cloud

• Gli account di servizio sono limitati a una quota flessibile di 100 account di servizio per progetto. Puoi richiedere una quota tramite la console Google Cloud per i progetti che mantengono gli account di servizio tenant.
• La contemporaneità di BigQuery prevede una contemporaneità 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 prevede un limite di 10.000 progetti all'interno dei perimetri di servizio a livello di organizzazione. Se le progettazioni del progetto per-tenant hanno scale up elevato, ti consigliamo di utilizzare invece una progettazione per set di dati per tenant.
• Controlli di servizio VPC prevede un limite di 100 perimetri, inclusi i bridge, per organizzazione.

Utilizzo delle viste autorizzate o delle tabelle di sottoinsiemi materializzati

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

Funzionalità	Visualizzazioni autorizzate	Tabelle di sottoinsiemi
Numero di tenant supportati	Esiste un limite fisso di 2500 risorse autorizzate per set di dati.	Le risorse autorizzate includono viste autorizzate, set di dati autorizzati e funzioni autorizzate.Non esistono limiti al numero di set di dati in un progetto o in tabelle in un set di dati.
Partizionamento e clustering	Le visualizzazioni autorizzate devono condividere lo schema di partizionamento e di cluster comune della tabella di base. Per migliorare le prestazioni della segmentazione dei tenant, ti consigliamo di raggruppare la tabella padre sull'ID tenant.	Puoi partizionare la tabella del sottoinsieme e assegnarla in cluster in base alle esigenze del tenant.
Aree geografiche	Le visualizzazioni autorizzate non possono attraversare più regioni e devono trovarsi nella regione Google Cloud della tabella di base. La regionalizzazione interessa i tenant geograficamente remoti.	Le tabelle di sottoinsiemi possono esistere nella regione più appropriata per il tenant. Potrebbero essere applicati costi aggiuntivi.
Applicazione dei criteri delle colonne	I criteri delle colonne applicati a una tabella di base vengono applicati a tutte le viste autorizzate, indipendentemente dalle autorizzazioni per quelle viste.	Ogni tabella del sottoinsieme deve applicare il criterio delle colonne affinché abbia effetto.
Logging degli accessi ai dati	I log degli accessi ai dati vengono riportati nei log della tabella di base.	L'accesso a ogni tabella del sottoinsieme viene registrato separatamente.
Flessibilità nella trasformazione	Le viste autorizzate consentono una riprogettazione immediata dell'oggetto a cui accedono i tenant.	Per cambiare 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 client

La crittografia dei dati client copre i casi in cui un'organizzazione di hosting archivia ed elabora i dati per conto di un tenant, ma viene impedito di accedere ad alcuni contenuti dei dati. Ad esempio, all'organizzazione di hosting potrebbe essere impedito l'accesso a dati personali o del dispositivo considerati sensibili.

Per criptare i dati sensibili, consigliamo al mittente di utilizzare chiavi di crittografia AEAD della libreria Tink open source. 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 una funzione definita dall'utente autorizzata 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 perdita accidentale di contenuti sensibili tra i team che collaborano tra loro. Le viste autorizzate sono il meccanismo preferito per condividere 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 di lettore granulare per il criterio. Anche quando il criterio non viene applicato in modo forzato, registra tutti gli accessi degli utenti alla colonna categorizzata.

Sensitive Data Protection

Sensitive Data Protection fornisce API e utilità di analisi che ti consentono di identificare e mitigare i contenuti sensibili archiviati all'interno di set di dati BigQuery o Cloud Storage. In scenari multi-tenant, le organizzazioni usano spesso l'API DLP (che fa 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 aiuta a controllare i costi man mano che i tenant fanno lo scale up e garantisce prestazioni garantite per ogni tenant.

Per gestire le prenotazioni, ti consigliamo di creare un singolo progetto amministrativo di prenotazione. Gli impegni slot acquistati all'interno dello stesso progetto amministrativo sono condivisibili tra tutte le prenotazioni provenienti dal progetto amministrativo. Un progetto che utilizza i commit di slot può essere assegnato a una sola prenotazione alla volta. Tutte le query che hanno origine da un progetto condividono slot in base alle risorse disponibili.

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

Prenotazioni come livelli di computing tenant

I fornitori di SaaS con decine fino a molte migliaia di tenant spesso configurano 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 gruppo di tenant per condividere il progetto per il calcolo di BigQuery. Questo design riduce il sovraccarico amministrativo di migliaia di progetti aggiuntivi e prenotazioni, consentendo all'organizzazione di allocare la capacità di slot minima necessaria per soddisfare le esigenze di prestazioni previste per la prenotazione.

Se la tempestività 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 i carichi di lavoro ad hoc, imposta la prenotazione in modo da ignorare gli slot inattivi.

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

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

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

Prenotazioni per team

Quando lavori con i team in un'impostazione Data mart, ti consigliamo di creare una prenotazione per ogni team che richiede ulteriore calcolo. Quindi assegna la prenotazione alla cartella principale che contiene i progetti del team. Tutti i nuovi progetti per il team utilizzano slot di pianificazione equa, con la stessa allocazione di risorse.

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

• Prenotazione a livello di organizzazione: 500 slot, consenti l'inattività. Questa prenotazione è assegnata all'organizzazione di primo livello e fornisce slot a tutti gli utenti BigQuery che non utilizzano un progetto con una prenotazione dedicata
• Elaborazione dati: 1000 slot, ignora gli slot inattivi. Questa prenotazione è configurata in modo da soddisfare gli SLO di elaborazione dati minimi.
• Amministrazione dei dati principali: 500 slot, consenti l'inattività. Questa prenotazione viene applicata ai progetti utilizzati per l'amministrazione interna. Gli slot vengono riutilizzati se sono rimasti dai livelli di elaborazione dati o computing.
• Analytics elabora le prenotazioni: 500 slot, consenti l'inattività. Questa è una prenotazione dedicata che viene concessa a un team di analisi.

Requisiti dell'hosting multiregionale

I requisiti di hosting multiregionale sono in genere il risultato della necessità di ridurre la latenza dei dati per i consumatori o di soddisfare i requisiti normativi.

I progetti in Google Cloud sono considerati globali e possono eseguire il provisioning delle risorse in qualsiasi regione. BigQuery considera set di dati, criteri delle colonne e impegni di slot come risorse a livello di regione. 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 area geografica che contiene set di dati.

Per indicazioni su come rispettare i requisiti normativi, consulta il tuo rappresentante di vendita.

Passaggi successivi

• Scopri di più sulle best practice per IAM.