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

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

Aziende commerciali, fornitori di Software as a Service (SaaS) e organizzazioni governative devono spesso ospitare in modo sicuro dati sia interni che 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 in diverse unità aziendali. Questo documento è rivolto alle organizzazioni che eseguono il deployment di piattaforme multi-tenant su BigQuery e che vogliono comprendere i controlli dell'accesso disponibili e le funzionalità di gestione delle prestazioni.

I builder di piattaforme multi-tenant spesso devono bilanciare le considerazioni per quanto segue:

• Isolamento dei dati: implementa controlli efficaci per impedire la fuga di dati tra i tenant.
• Prestazioni coerenti: configura e ripartisci le prenotazioni BigQuery per mantenere prestazioni coerenti tra i tenant.
• Gestione delle risorse: pianifica l'impatto di quote e limiti.
• Distribuzione geografica: individua i dati in località geografiche designate e obbligatorie. Per problemi relativi alla conformità, consulta le offerte per la conformità di Google Cloud.
• Controllo e sicurezza: proteggi i dati del tenant da accessi ed esfiltrazioni inappropriati.
• Gestione dei costi: assicurati costi coerenti di BigQuery per ospitare ogni tenant.
• Complessità operativa: riduci al minimo la quantità di variabilità del sistema necessaria per ospitare i 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 di clienti. È possibile che si tratti di decine di migliaia di clienti e che è possibile accedere ai dati dei clienti tramite un'infrastruttura di servizi condivisi. Alcuni fornitori SaaS dispongono anche di un datastore centrale sanitizzato per eseguire analisi su tutti i loro tenant.

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

• Complessità amministrativa: il numero totale di nuovi progetti e risorse cloud in base al cliente.
• Latenza end-to-end: quanto è aggiornato il datastore per i tenant e le soluzioni di analisi cross-customer
• Aspettative di prestazioni: garantire che le prestazioni del tenant rimangano entro i 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 ciascun cliente sono separati da set di dati BigQuery. All'interno dell'organizzazione host, utilizzi un secondo progetto per eseguire il deployment di analisi e machine learning su dati combinati dei clienti. Puoi quindi configurare il motore di elaborazione dati Dataflow in modo che esegua la doppia scrittura dei dati in entrata nelle tabelle interne e specifiche per il tenant. La configurazione di Dataflow utilizza tabelle completamente scritte anziché viste autorizzate. L'uso di tabelle completamente scritte consente una gestione uniforme della distribuzione geografica e consente di evitare di raggiungere i limiti di visualizzazione autorizzati quando il numero di tenant viene scalato.

La separazione di BigQuery tra archiviazione e compute consente di configurare un numero inferiore di progetti rispetto ai warehouse basati su cluster per gestire problemi quali livelli di servizio e isolamento dei dati. Se non devi configurare i tenant con risorse cloud dedicate, 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 di progetto basata sulla progettazione consigliata:

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

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

• Progetto della pipeline di dati: i componenti principali dell'infrastruttura che ricevono, elaborano e distribuiscono i dati del tenant sono tutti pacchettizzati in un unico progetto.
• Progetto dati tenant combinato: il progetto di dati principale che gestisce un set di dati per cliente. Si prevede che i dati tenant siano accessibili tramite progetti di livello di computing.
• Progetti di sviluppo interni: progetti che rappresentano le risorse autogestite che i team di analisi utilizzano per valutare i dati dei tenant e creare nuove funzionalità.
• Progetti di applicazioni per gli utenti finali: 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 dei tenant e di utilizzare una pipeline di build robusta e sicura per il deployment delle applicazioni.
• Progetti di livello di computing della prenotazione: i progetti che mappano l'attività delle query del tenant alle prenotazioni BigQuery.

Condividi le prenotazioni

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

Configura i perimetri Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per evitare l'esposizione accidentale dei set di dati dei tenant all'esterno dell'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 attorno ai progetti della pipeline di dati dovrebbe applicare tutti i servizi che non devono ricevere dati dei tenant.
• Dati tenant: un perimetro intorno al progetto del set di dati tenant e ai progetti di computing BigQuery del tenant. Applica tutti i servizi per impedire l'accesso dall'esterno dell'organizzazione.
• Applicazioni interne: applica tutti i servizi e utilizza i livelli di accesso per concedere l'accesso alle risorse ai team dei reparti.
• Applicazioni esterne: un perimetro che circonda le applicazioni SaaS. Applica in modo forzato tutti i servizi che non sono necessari per il funzionamento delle applicazioni.

Bridge perimetrali

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

• Pipeline di dati e dati tenant: consenti alla pipeline di scrivere dati nei set di dati dei tenant.
• Pipeline di dati e applicazioni interne: consente alla pipeline di scrivere i 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 interne: consentono alle applicazioni rivolte all'esterno di elaborare i dati utilizzando i modelli sviluppati e di cui le applicazioni interne eseguono il deployment.

Fornitore SaaS con infrastruttura tenant dedicata

In scenari più complessi, i fornitori 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 tenant all'interno di BigQuery.

La 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 ciascun tenant inserito.
• Latenza end-to-end: quanto è aggiornato il datastore sia per i tenant che per le soluzioni di analisi cross-customer.
• Aspettative di prestazioni: garantire che le prestazioni del tenant rimangano entro limiti accettabili.

Colloca set di dati con risorse dedicate

Quando esegui il deployment dell'infrastruttura tenant dedicata, ti consigliamo di creare una cartella padre per i progetti specifici per il tenant. Quindi, colloca i set di dati BigQuery del tenant in 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 dei tenant, le pipeline Dataflow inseriscono i dati direttamente nei set di dati dei tenant.

Questa progettazione gestisce l'elaborazione e la distribuzione dei dati upstream, in modo simile alla precedente progettazione dell'infrastruttura condivisa. Tuttavia, i dati e le applicazioni tenant che accedono ai dati tenant sono organizzati in progetti specifici per il 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 sulla progettazione consigliata:

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

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

• Progetto pipeline di dati: i componenti principali 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 degli account e degli 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 dei tenant e creare nuove funzionalità.
• Progetto di rete esterno: progetto che gestisce e instrada le richieste tenant ai rispettivi backend dedicati.

Condividi le prenotazioni

Le prenotazioni con questo approccio si basano sull'algoritmo di pianificazione equa, integrato nelle prenotazioni BigQuery. In questa configurazione, le prenotazioni del 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 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 autorità centrale

I data mart sono un tema di progettazione comune in cui i dati di analisi principali vengono archiviati in un repository centrale e i sottoinsiemi vengono condivisi lungo le linee di business. I data mart spesso hanno decine o centinaia di tenant, rappresentati come linee di business da considerare.

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 gli accessi inappropriati tra i team.
• Governance centrale dei dati: garantisce che gli asset di dati principali utilizzati per i report aziendali critici siano standardizzati e convalidati.
• Attribuzione del costo per unità aziendale: monitoraggio e regolazione dell'utilizzo di 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 autorizzate e i criteri delle colonne vengono spesso utilizzati insieme per condividere dati con i settori di business, evitando la distribuzione accidentale di dati sensibili.

I team nei progetti tenant possono accedere a set di dati regolati centralmente in base alle autorizzazioni dei loro account. I team utilizzano gli slot allocati ai propri progetti per creare report e set di dati derivati. Il team dei dati di base utilizza le viste autorizzate per mantenere la proprietà completa delcontrollo dell'accessoo dell'accesso alle risorse del data mart. In questa configurazione, consigliamo di evitare di creare più livelli di viste sopra gli oggetti presentati dal progetto di dati di base. Il seguente diagramma mostra un esempio di configurazione di progetto basata sulla progettazione consigliata:

Figura 3. Un progetto di dati di base mantiene 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 alle viste del 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 al gruppo.
• Estrai, trasforma, carica (ETL) Infrastructure: infrastruttura per l'elaborazione delle origini dati upstream nei dati principali. A seconda delle esigenze di separazione amministrativa, puoi scegliere di eseguire il deployment dell'infrastruttura ETL come progetto proprio o come parte del progetto di dati principale.
• Progetti del team di analisi: 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 all'interno del data mart. I progetti del team di Analytics dovrebbero poter creare set di dati derivati da usare a livello locale.

Utilizza un design della prenotazione a due livelli

Quando si lavora con i data mart, consigliamo di utilizzare una progettazione a due livelli. Con una progettazione a due livelli, assegni alla risorsa 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 Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per prevenire 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 di data warehouse e 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 dal perimetro dei dati principale.
• Analisi: un perimetro per creare ed eseguire il deployment di asset di analisi interni all'organizzazione. Questo perimetro dovrebbe avere un criterio di accesso più permissivo rispetto al perimetro dei dati principali con cui è collegato.

Bridge perimetrali

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

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

Copia i set di dati per le 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. In alternativa, puoi utilizzare BigQuery Data Transfer Service per copiare i set di dati pertinenti in un'altra regione. In questo scenario, creerai criteri di colonna all'interno del catalogo dati per ogni regione aggiuntiva in cui si trovano i dati. Il seguente diagramma mostra una configurazione per più regioni:

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

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

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

BigQuery Data Transfer Service è un componente programmato 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 per emettere job ETL che creano sottoinsiemi regionali prima di attivare BigQuery Data Transfer Service tramite l'API client. Se la tua organizzazione è in grado di supportare una latenza aggiuntiva, ti consigliamo questa opzione.
• Infrastruttura ETL: l'infrastruttura ETL, come Dataflow, può eseguire la doppia scrittura di sottoinsiemi di regioni nelle regioni di destinazione. Se la tua organizzazione richiede una latenza dei dati minima tra le regioni, ti consigliamo questa opzione.

Data mart con autorità decentralizzata

Utilizza l'autorità decentralizzata quando hai bisogno di una separazione amministrativa per proprietario del sistema, linee di attività o 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 gli accessi inappropriati tra i team.
• Rilevabilità dei dati: i team devono essere in grado di rilevare e richiedere l'accesso ai set di dati.
• Provenienza dei dati: senza un team di curatori centrale, i team devono potersi fidare dell'origine dei dati inseriti nei loro prodotti di analisi.

Delega l'amministrazione dei dati di base

Questo design è diverso da un approccio data mart convenzionale, perché l'autorità decentralizzata delega le decisioni principali di amministrazione dei dati ai sottogruppi di componenti dell'organizzazione. Quando si utilizza l'autorità decentralizzata, puoi mantenere 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. Di conseguenza, eviterai la proliferazione dei dati tipica dei 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 mantengono le operazioni sui dati.

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

• Core governance Progetto: il progetto responsabile dei problemi di gestione tra organizzazioni. In questo progetto, creerai risorse di sicurezza come i keyring di Cloud KMS e i criteri delle colonne del catalogo dati. Questo progetto funge da progetto di amministrazione delle prenotazioni di BigQuery, consentendo la condivisione degli slot a livello di organizzazione.
• Progetti di dati di unità organizzative: i proprietari di datamart autogestiti all'interno dell'organizzazione più ampia. Il progetto di governance di base 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 l'infrastruttura e gli slot di cui sono stati di cui è stato eseguito il provisioning per accedere ai dati ed elaborarli.

Utilizza un design della prenotazione a due livelli

Ti consigliamo di far usare ai data mart decentralizzati lo stesso design a due livelli dei data mart standard. In questa configurazione, assegnerai alla risorsa 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.

Usa un catalogo dati

Un catalogo dati fornisce funzionalità di rilevamento, tagging dei metadati e 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 nuovi asset di dati e applicare controlli appropriati.

Configura i perimetri Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC per prevenire 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 di data warehouse e data mart. Questo perimetro deve includere tutti i progetti di unità organizzativa e il progetto di governance dei dati.
• Analisi: un perimetro per creare ed eseguire il deployment di asset di analisi all'interno dell'organizzazione. Questo perimetro dovrebbe avere un criterio di accesso più permissivo rispetto al perimetro dei dati principali con cui è collegato.

Bridge perimetrali

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

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

Condivisione dei dati tra più organizzazioni

La condivisione tra più organizzazioni è un aspetto particolarmente importante per la progettazione di un data mart. Questo progetto di condivisione dei dati è rivolto alle organizzazioni che vogliono condividere in modo sicuro i propri set di dati con un'altra entità che ha la propria organizzazione Google.

La condivisione dei dati tra più organizzazioni risolve i seguenti problemi per la persona che condivide i dati:

• Condivisione di riservatezza: solo la parte interessata può accedere ai dati condivisi.
• Protezione da accessi inappropriati: solo le risorse a cui è previsto l'accesso sono accessibili dall'esterno.
• Separazione del calcolo: alle parti esterne vengono addebitati i costi per le query avviate.

Nota: in alcuni casi, le query provenienti dall'organizzazione esterna possono non riuscire in modo imprevisto. L'assistenza clienti Google Cloud può aiutarti ad avviare una modifica alla configurazione per risolvere il problema.

Proteggi i progetti interni da quelli di dati condivisi

La progettazione della condivisione dei dati tra più organizzazioni è incentrata sulla protezione dei progetti interni dell'organizzazione dalle attività nei progetti di dati condivisi. Il progetto del set di dati condiviso agisce da buffer per non consentire l'accesso all'elaborazione interna dei dati sensibili, offrendo 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. Se tutti i set di dati sottoposti a query condividono la stessa regione Google Cloud, queste query possono unire i dati tra organizzazioni. Il seguente diagramma mostra come vengono condivisi i set di dati nella configurazione di un progetto multi-organizzazione:

Figura 6. Un'organizzazione esterna esegue query sui dati di più set di dati di 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 di dati condivisi. Il progetto interno deve essere proprietario dell'account di servizio responsabile dell'aggiornamento dei dati condivisi.
• Progetto di dati condivisi: il progetto che contiene le informazioni sanitizzate che vengono copiate dal progetto interno. Utilizza i gruppi di utenti esterni per gestire l'accesso da parte di parti esterne. In questo scenario, gestisci l'appartenenza ai gruppi come funzione amministrativa e assegni agli account esterni l'autorizzazione di visualizzazione, in modo che possano accedere al set di dati attraverso questi gruppi.

Configura i perimetri Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri 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. I Controlli di servizio VPC applicano l'accesso a BigQuery.
• Dati condivisi esternamente: un perimetro per ospitare set di dati che possono essere condivisi con organizzazioni esterne. Questo perimetro disabilita l'applicazione dell'accesso a BigQuery.

Bridge perimetrali

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

• Dati interni ed 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 sui sistemi multi-tenant

Questa sezione fornisce un'analisi più approfondita dei casi speciali da prendere in considerazione insieme alle best practice precedenti.

Limiti e quote delle risorse Google Cloud

• Gli account di servizio sono limitati a una quota temporanea 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 ha una contemporaneità predefinita di 100 query per progetto che invia query (i progetti che contengono set di dati non hanno questi limiti). Per aumentare questa quota flessibile, contatta il tuo rappresentante di vendita.
• I Controlli di servizio VPC hanno un limite di 10.000 progetti all'interno dei perimetri di servizio a livello di organizzazione. Se le tue progettazioni progetto per tenant hanno uno scale up elevato, ti consigliamo di usare una progettazione per set di dati per tenant.
• Controlli di servizio VPC ha un limite di 100 perimetri, inclusi i bridge, per organizzazione.

Utilizzo delle viste autorizzate o delle tabelle di sottoinsiemi materializzati

Per gestire l'accesso del tenant a sottoinsiemi di tabelle di oggetti di grandi dimensioni, puoi utilizzare le viste autorizzate specifiche per il tenant o creare tabelle di sottoinsiemi specifiche per il tenant. La tabella seguente offre un confronto tra i seguenti approcci:

Selezione delle	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 alle tabelle in un set di dati.
Partizionamento e clustering	Le viste autorizzate devono condividere lo schema di partizionamento e 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 eseguire il partizionamento della tabella del sottoinsieme e la creazione di cluster 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 influisce sui 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 relative autorizzazioni.	Affinché abbia effetto, ogni tabella sottoinsieme deve applicare il criterio della colonna.
Logging degli accessi ai dati	I log di accesso ai dati si riflettono nel logging della tabella di base.	L'accesso a ogni tabella sottoinsieme viene registrato separatamente.
Flessibilità nella trasformazione	Le viste autorizzate consentono di riprogettare immediatamente l'oggetto a cui accedono i tenant.	Per modificare le tabelle di sottoinsiemi sono necessarie modifiche complesse allo schema.

Controllo dei 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 non può 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.

Consigliamo al mittente di dati di utilizzare le 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 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 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 data mart. Le viste 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 del criterio. Anche quando il criterio non viene applicato in modo forzato, registra tutti gli accessi degli utenti nella colonna classificata.

Protezione dei dati sensibili

Sensitive Data Protection fornisce API e utilità di analisi che ti aiutano a identificare e ridurre i contenuti sensibili archiviati all'interno dei set di dati BigQuery o Cloud Storage. In scenari multi-tenant, le organizzazioni 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 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 di amministrazione della prenotazione. Gli impegni di slot acquistati all'interno dello stesso progetto amministrativo sono condivisibili tra tutte le prenotazioni che hanno origine dal progetto amministrativo. Un progetto che utilizza impegni di slot può essere assegnato a una sola prenotazione alla volta. Tutte le query originate da un progetto condividono slot in base alle risorse disponibili.

Per assicurarti che gli obiettivi del livello di servizio (SLO) del tenant siano soddisfatti, puoi monitorare le prenotazioni tramite Cloud Logging e lo schema di informazioni di BigQuery. Le organizzazioni che riscontrano periodi di maggiore attività a causa delle attività degli analisti o di job prioritari possono allocare capacità aggiuntiva tramite slot flessibili.

Prenotazioni come livelli di computing tenant

I fornitori SaaS con decine fino a tante migliaia di tenant di solito 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 tenant di gruppo per condividere il progetto per il calcolo di BigQuery. Questo design riduce l'overhead amministrativo associato alla necessità di avere migliaia di progetti e prenotazioni aggiuntivi, consentendo al contempo all'organizzazione di allocare una 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 impedire l'utilizzo di 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 dei dati: 2000 slot, ignora i dati inattivi. Questa prenotazione è configurata in modo da soddisfare gli SLO di elaborazione dati.
• Progetti interni: 1000 slot, consentiti in caso di inattività. Questa prenotazione viene applicata ai progetti utilizzati per le analisi interne.Gli slot vengono riutilizzati se provengono da livelli di elaborazione dati o di calcolo.
• Livello di computing basso: 2000 slot, ignora l'inattività. Questa prenotazione viene applicata ai tenant con poche risorse. A differenza del livello alto, questa prenotazione ignora gli slot inattivi.
• Livello di computing elevato: 3000 slot, consentiti in caso di inattività. Questa prenotazione viene applicata ai tenant con risorse elevate. Per velocizzare le query, vengono applicati automaticamente gli slot inattivi di altre prenotazioni.

Se i tenant utilizzano un'infrastruttura dedicata, ti consigliamo di assegnare la cartella o il progetto designato 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 ulteriori capacità di calcolo. Quindi assegna questa prenotazione alla cartella principale che contiene i progetti del team. Tutti i nuovi progetti per quel team utilizzano slot di equa pianificazione provenienti dalla stessa allocazione di risorse.

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

• Prenotazione a livello di organizzazione: 500 slot, consentiti in caso di 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 dei dati: 1000 slot, ignora i dati inattivi. Questa prenotazione è configurata per soddisfare gli SLO minimi di elaborazione dei dati.
• Amministrazione dei dati principali: 500 slot, consentiti in caso di inattività. Questa prenotazione viene applicata ai progetti utilizzati per l'amministrazione interna. Gli slot vengono riutilizzati se provengono da livelli di elaborazione dati o di calcolo.
• Prenotazioni di elaborazione dati e analisi: 500 slot, consentiti in caso di inattività. Questa è una prenotazione dedicata che viene assegnata a un team di analisi.

Requisiti di hosting per più regioni

I requisiti di hosting multiregionali 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. BigQuery considera i set di dati, i criteri delle colonne e gli impegni di slot come risorse 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 regione che contiene set di dati.

Per indicazioni sul rispetto dei requisiti normativi, consulta il tuo rappresentante di vendita.

Passaggi successivi

• Scopri di più sulle best practice IAM.