Best practice per i workload multitenant su BigQuery

Questo documento fornisce tecniche e best practice per i pattern comuni utilizzati nelle piattaforme di dati multitenant 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 in confini geografici e amministrativi. BigQuery è uno strumento potente 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 unità aziendali disparate. Questo documento è destinato alle organizzazioni che implementano piattaforme multi-tenant su BigQuery e che vogliono comprendere i controlli dell'accesso e le funzionalità di gestione delle prestazioni disponibili.

I builder di piattaforme multitenant spesso devono bilanciare le considerazioni per quanto riguarda:

• Isolamento dei dati: implementa controlli rigorosi per impedire la perdita di dati tra i tenant.
• Rendimento coerente: configura e ripartisci le prenotazioni BigQuery per mantenere un rendimento coerente tra i tenant.
• Gestione delle risorse: pianifica l'impatto di quote e limiti.
• Distribuzione geografica: individua i dati nelle posizioni geografiche designate e richieste. Per dubbi relativi alla conformità, consulta le offerte di conformità di Google Cloud.
• Audit e sicurezza: proteggi i dati del tenant da accessi e esfiltrazione inappropriati.
• Gestione dei costi: garantisci costi 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 SaaS che ospitano dati di terze parti devono garantire l'affidabilità e l'isolamento dell'intera flotta di clienti. Questi clienti potrebbero essere decine di migliaia e i dati dei clienti potrebbero essere accessibili tramite un'infrastruttura di servizi condivisa. Alcuni fornitori SaaS gestiscono anche un datastore centrale e pulito per eseguire analisi sull'intera flotta di tenant.

Un design con un set di dati per tenant contribuisce a mitigare i seguenti problemi che un'organizzazione riscontra quando si espande a migliaia di tenant:

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

Configurare 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 dai set di dati BigQuery. All'interno dell'organizzazione host, utilizzi un secondo progetto per eseguire il deployment di analisi e machine learning sui dati dei clienti combinati. Puoi quindi configurare il motore di elaborazione dei dati, Dataflow, per scrivere i dati in entrata nelle tabelle interne e specifiche del tenant. La configurazione Dataflow utilizza tabelle scritte completamente anziché viste autorizzate. L'utilizzo di tabelle scritte interamente 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 tra archiviazione e computing di BigQuery 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. Quando non è necessario configurare i tenant con risorse cloud dedicate aggiuntive, ti consigliamo di prendere in considerazione la configurazione predefinita di un dataset dedicato per ogni tenant. Il seguente diagramma mostra una configurazione di progetto di esempio basata su questa progettazione consigliata:

Figura 1. Un numero costante di progetti gestisce i dati e le esigenze di 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 dell'infrastruttura di base che ricevono, elaborano e distribuiscono i dati dei tenant sono tutti raggruppati in un unico progetto.
• Progetto di dati del tenant combinato: il progetto di dati principale che gestisce un set di dati per cliente. Si prevede che i dati del tenant vengano accessibili tramite i progetti del livello di calcolo.
• 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 utenti finali: progetti che contengono risorse progettate per interagire con gli utenti finali. Ti consigliamo di utilizzare service account con ambito tenant per accedere ai set di dati del tenant e utilizzare una pipeline di build solida e sicura per il deployment delle applicazioni.
• Progetti del livello di calcolo della prenotazione: 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 pianificazione equa integrato nelle prenotazioni BigQuery. Ogni prenotazione del livello di calcolo viene assegnata a un singolo progetto. Le query tenant utilizzano slot di pianificazione equa disponibili per ogni progetto di livello di calcolo e gli slot non utilizzati 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.

Configura i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri dei controlli di servizio VPC per impedire l'esposizione accidentale dei set di dati dei tenant al di fuori della tua 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 della 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 intorno 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. Forza tutti i servizi non necessari per il funzionamento delle applicazioni.

Bridge del perimetro

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

• Pipeline di dati e dati tenant: consente alla pipeline di scrivere dati nei set di dati tenant.
• Pipeline di dati e applicazioni interne: consente alla pipeline di scrivere dati nel set di dati cross-customer.
• Applicazioni esterne e dati del tenant: consentono alle applicazioni esterne di eseguire query sui dati del tenant.
• Applicazioni esterne e interne: consentono alle applicazioni rivolte all'esterno di elaborare i dati utilizzando 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 della gestione delle richieste di dati dei tenant all'interno di BigQuery.

Una progettazione dell'infrastruttura tenant dedicata risolve i seguenti problemi comuni quando viene eseguita il deployment dell'infrastruttura per ogni tenant insieme a BigQuery:

• Responsabilità della fatturazione: monitoraggio dei costi dell'infrastruttura associati a ogni tenant integrato.
• Latenza end-to-end: quanto è aggiornato il datastore per le soluzioni di analisi cross-customer e per i tenant.
• Aspettative di rendimento: garantire che il rendimento del tenant rimanga entro limiti accettabili.

Collocare i set di dati con risorse dedicate

Quando implementi un'infrastruttura tenant dedicata, ti consigliamo di creare una cartella principale per i progetti specifici del tenant. Poi, 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 dataset dei tenant.

Questo design gestisce l'elaborazione e la distribuzione dei dati upstream, 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 del tenant (e facoltativamente in cartelle dedicate al tenant) per semplificare la fatturazione e la gestione delle risorse. Il seguente diagramma mostra una configurazione di progetto di esempio basata su questa 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 dell'infrastruttura di base che ricevono, elaborano e distribuiscono i dati dei tenant sono tutti raggruppati 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 di accesso ai set di dati dei clienti da parte di account e service account.
• 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 networking esterno: progetto che gestisce e indirizza 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 BigQuery. In questa configurazione, le prenotazioni dei livelli di calcolo vengono assegnate a ogni progetto tenant che utilizza quel livello. Se un tenant ha requisiti di tempistica specifici, puoi creare una prenotazione dedicata per fornire un numero preciso di slot a un progetto tenant.

Utilizzare i controlli IAM e disattivare la creazione di chiavi

I perimetri di Controlli di servizio VPC potrebbero non essere adatti a questo scenario. I limiti correlati al progetto impediscono a un'organizzazione di utilizzare i confini del perimetro intorno ai progetti che interagiscono con i progetti tenant. Ti consigliamo invece di utilizzare controlli IAM rigorosi e di disattivare 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 analitici principali vengono archiviati in un repository centrale e i sottoinsiemi vengono condivisi in base alle linee di business. I data mart spesso hanno decine o centinaia di tenant, rappresentati come linee di business da considerare.

La progettazione di un 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 centralizzata dei dati: garantire che gli asset di dati principali utilizzati per i report aziendali critici siano standardizzati e convalidati.
• Attribuzione dei costi dell'unità aziendale: monitoraggio e aggiustamento dell'utilizzo del calcolo da parte delle unità aziendali.

Utilizzare 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 i dati con le linee di business, evitando la distribuzione accidentale di dati sensibili.

I team nei progetti tenant possono accedere ai set di dati gestiti centralmente in base alle autorizzazioni dell'account. I team utilizzano gli slot assegnati ai propri progetti per creare report e set di dati derivati. Il team principale dei dati utilizza le viste autorizzate per mantenere la piena proprietà delcontrollo dell'accessoo dell'accesso agli asset del data mart. In questa configurazione, ti consigliamo di evitare di creare più livelli di visualizzazioni sopra gli oggetti presentati dal progetto di dati principale. Il seguente diagramma mostra una configurazione di progetto di esempio basata su questa progettazione consigliata:

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 di dati principali: il perimetro di governance per la gestione dell'accesso ai dati principali e alle visualizzazioni dei data mart. Mantieni le visualizzazioni autorizzate all'interno dei set di dati in questo progetto e concedi le visualizzazioni autorizzate ai tuoi team di analisi in base all'iscrizione al gruppo.
• Infrastruttura di estrazione, trasformazione e caricamento (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 autonomo o come parte del progetto di dati principale.
• Progetti del team di analisi: i consumatori del data mart utilizzano questi progetti e il proprio accesso all'infrastruttura di provisioning per elaborare i dati all'interno del data mart. I progetti del team di analisi devono essere in grado di creare set di dati derivati per l'utilizzo locale.

Utilizza una progettazione 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 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.

Configura i perimetri dei Controlli di servizio VPC

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

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 principale.
• Analytics: un perimetro per creare e implementare asset di analisi interni alla tua organizzazione. Questo perimetro dovrebbe avere una policy di accesso più permissiva rispetto al perimetro dei dati principale a cui è collegato.

Bridge del perimetro

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

• Pipeline di dati e dati principali: consente alle pipeline di dati di scrivere nel progetto di dati principali.
• Dati e analisi principali: consentono 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, crei criteri per le colonne all'interno del catalogo dei dati per ogni regione aggiuntiva in cui si trovano i dati. Il seguente diagramma mostra una configurazione multiregionale:

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

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

• Progetto di dati principali: il perimetro di governance per la gestione dell'accesso ai dati principali e alle visualizzazioni dei data mart. I dati vengono copiati e mantenuti in dataset regionali che possono essere utilizzati dai 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 autonomo o come parte del progetto di dati principale.
• 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 devono 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 servizio di pianificazione integrato è limitato a un intervallo di tempo 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 i job Cloud Composer per eseguire job ETL che creano sottoinsiemi regionali prima di attivare BigQuery Data Transfer Service tramite la relativa API client. Se la tua organizzazione può supportare una latenza aggiuntiva, ti consigliamo questa opzione.
• Infrastruttura ETL: l'infrastruttura ETL, come Dataflow, può scrivere in doppia copia i 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 per proprietario del sistema, linee di business o problemi geografici.

Un data mart decentralizzato presenta i seguenti problemi 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.
• Provenienza dei dati: senza un team di curatori centrale, i team devono essere in grado di fidarsi dell'origine dei dati inseriti nei loro prodotti di analisi.

Delegare 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 a livello di colonna, i Controlli di servizio VPC e le prenotazioni. Pertanto, eviti la proliferazione dei dati comune nei data warehouse autogestiti. Il seguente diagramma mostra un'architettura che utilizza un'autorità decentralizzata:

Figura 5. Un progetto di governance principale 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 principale: il progetto responsabile della gestione interorganizzativa. In questo progetto, crei risorse di sicurezza come keyring Cloud KMS e policy 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 di dati delle unità organizzative: i proprietari dei data mart autogestiti all'interno dell'organizzazione più ampia. Il progetto di governance principale gestisce l'ambito con limitazioni per i progetti di dati dell'unità organizzativa.
• Progetti del team di analisi: i progetti utilizzati dai consumer dei data mart. Questi progetti utilizzano la propria infrastruttura e i propri slot di cui è stato eseguito il provisioning per accedere ai dati e trattarli all'interno del data mart.

Utilizza una progettazione di prenotazione a due livelli

Ti consigliamo di utilizzare lo stesso design a due livelli per i data mart decentralizzati come per quelli standard. In questa configurazione, assegni alla risorsa 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 dei dati fornisce l'individuazione a livello di organizzazione, il tagging dei metadati e la configurazione delle policy per le colonne. Il rilevamento di Dataplex crea automaticamente voci di metadati per tutte le nuove tabelle BigQuery della tua organizzazione. Le funzionalità di Dataplex aiutano anche gli amministratori della governance dei dati a identificare rapidamente nuovi asset di dati e ad applicare controlli appropriati.

Configura i perimetri dei Controlli di servizio VPC

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

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 una policy di accesso più permissiva rispetto al perimetro dei dati principale a cui è collegato.

Bridge del perimetro

In questa configurazione, ti 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 tra più organizzazioni

La condivisione tra più organizzazioni è una considerazione di progettazione speciale per un data mart. Questa progettazione della condivisione dei dati è pensata per le 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 il condividente dei dati:

• Riservatezza della condivisione: solo la parte interessata può accedere ai dati condivisi.
• Protezione da accessi inappropriati: solo le risorse destinate all'accesso possono essere accessibili esternamente.
• Separazione del calcolo: le parti esterne vengono fatturate per le query che avviano.

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

Proteggere i progetti interni dai progetti di dati condivisi

La progettazione della condivisione dei dati tra più organizzazioni si concentra sulla protezione dei progetti interni dell'organizzazione dall'attività nei progetti di dati condivisi. Il progetto del set di dati condiviso funge da buffer per impedire l'accesso al trattamento dei dati interni sensibili, fornendo al contempo la possibilità di condividere i dati esternamente.

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

Immagine 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 che contiene dati interni sensibili. Il progetto interno può condividere i dati esternamente copiando i dati sanitizzati nei set di dati del progetto di dati condivisi. Il progetto interno deve essere proprietario delaccount di serviziot responsabile dell'aggiornamento dei dati condivisi.
• Progetto di dati condiviso: il progetto che contiene le informazioni sanitizzate 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 visualizzazione in modo che possano accedere al set di dati tramite questi gruppi.

Configura 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 di 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 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 ed esterni: un bridge del perimetro consente ai progetti di dati interni più protetti di trasferire i dati in progetti di condivisione di dati esterni.

Considerazioni aggiuntive nei sistemi multi-tenant

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

Google Cloud Quote e limiti delle risorse

• Gli account di servizio sono limitati a una quota flessibile di 100 account di servizio per progetto. Puoi richiedere la quota tramite la console Google Cloud per i progetti che gestiscono gli account di servizio tenant.
• La concorrenza di BigQuery ha una concorrenza predefinita di 100 query per progetto che emette query (i progetti che contengono set di dati non hanno questi limiti). Per aumentare questa quota soft, 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 i tuoi progetti per tenant hanno una scalabilità elevata, ti consigliamo di utilizzare un design con un set di dati per tenant.
• Controlli di servizio VPC prevede un limite di 100 perimetri, inclusi i bridge, per organizzazione.

Utilizzo di viste autorizzate o tabelle di sottoinsieme materializzate

Per gestire l'accesso dei tenant a sottoinsiemi di tabelle dei 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 tra questi approcci:

Funzionalità	Visualizzazioni autorizzate	Tabelle sottoinsieme
Numero di tenant supportati	Esiste un limite rigido 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 di tabelle in un set di dati.
Partizionamento e clustering	Le viste autorizzate devono condividere lo schema di partizionamento e clustering comune della tabella di base. Per migliorare il rendimento della segmentazione dei tenant, ti consigliamo di raggruppare la tabella principale in base all'ID tenant.	Puoi partizionare la tabella del sottoinsieme e raggrupparla in cluster in base alle esigenze del tenant.
Aree geografiche	Le viste autorizzate non possono estendersi a più regioni e devono trovarsi nella regione Google Cloud della tabella di base. La regionalizzazione interessa i tenant geograficamente remoti.	Le tabelle dei 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 per queste visualizzazioni.	Perché abbia effetto, ogni tabella del sottoinsieme deve applicare il criterio della colonna.
Logging dell'accesso ai dati	I log di accesso ai dati vengono registrati nella tabella di base.	L'accesso a ogni tabella sottoinsieme viene registrato separatamente.
Flessibilità della trasformazione	Le viste autorizzate consentono di riprogettare istantaneamente l'oggetto a cui accedono i tenant.	Per modificare le tabelle dei 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 cliente

La crittografia dei dati del cliente 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, l'organizzazione di hosting potrebbe non essere autorizzata ad accedere a dati personali o del dispositivo considerati sensibili.

Consigliamo al mittente dei dati di utilizzare chiavi di crittografia AEAD, dalla 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 UDF autorizzata o passando il materiale della chiave come parametro di query a BigQuery, dove l'organizzazione host non può registrare la chiave.

Policy di accesso alle colonne

Nei data mart multi-tenant, le norme a livello di colonna vengono spesso utilizzate per impedire la fuoriuscita accidentale di contenuti sensibili tra team che collaborano. Le viste autorizzate sono il meccanismo preferito per condividere i dati tra i team in uno scenario di data mart. Le viste autorizzate non possono concedere l'accesso a una colonna protetta.

Se 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 per il criterio. Anche quando il criterio non viene applicato, registra tutti gli accessi 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, se vuoi, 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 le prestazioni per ogni tenant.

Per gestire le prenotazioni, ti consigliamo di creare un unico progetto amministrativo per le prenotazioni. Gli impegni di slot acquistati all'interno dello stesso progetto amministrativo sono condivisibili in 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 che hanno origine da un progetto condividono gli slot in base alle risorse disponibili.

Per garantire il rispetto degli obiettivi del livello di servizio (SLO) dei tenant, puoi monitorare le prenotazioni tramite Cloud Logging e lo schema informativo di BigQuery. Le organizzazioni che registrano periodi di attività intensa da parte degli analisti o lavori prioritari possono allocare capacità aggiuntiva utilizzando gli slot flessibili.

Prenotazioni come livelli di calcolo tenant

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

Se sei un fornitore SaaS che ha condiviso l'infrastruttura tenant, ti consigliamo di dedicare ogni prenotazione a un singolo progetto e di raggruppare i tenant per condividere quel progetto per il calcolo BigQuery. Questo design riduce l'overhead amministrativo di migliaia di progetti e prenotazioni aggiuntivi, consentendo alla tua organizzazione di allocare una capacità di slot minima necessaria per soddisfare le esigenze di rendimento previste per la prenotazione.

Se l'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 slot inattivi.

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

• Elaborazione dati: 2000 slot, ignora inattività. Questa prenotazione è configurata per soddisfare gli SLO di trattamento dati.
• Progetti interni: 1000 slot, consentono l'inattività. Questa prenotazione viene applicata ai progetti utilizzati per l'analisi interna.Gli slot vengono riutilizzati se rimangono inutilizzati dopo l'elaborazione dei dati o i livelli di calcolo.
• Livello di calcolo basso: 2000 slot, ignora l'inattività. Questa prenotazione viene applicata ai tenant con poche risorse. A differenza del livello superiore, questa prenotazione ignora gli slot inattivi.
• Livello di calcolo elevato: 3000 slot, consente l'inattività. Questa prenotazione viene applicata ai tenant a cui sono state assegnate 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 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 ulteriore potenza di calcolo. Quindi, assegna la prenotazione alla cartella principale che contiene i progetti del team. Tutti i nuovi progetti per quel team utilizzano slot di pianificazione equa della stessa allocazione di risorse.

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

• Prenotazione a livello di organizzazione: 500 slot, consente l'inattività. Questa prenotazione è assegnata all'organizzazione di primo livello e fornisce slot a qualsiasi utente BigQuery che non utilizza un progetto con una prenotazione dedicata
• Trattamento dati: 1000 slot, ignora l'inattività. Questa prenotazione è configurata per soddisfare gli SLO minimi di trattamento dati.
• Amministrazione dei dati principali: 500 slot, consentire l'inattività. Questa prenotazione viene applicata ai progetti utilizzati per l'amministrazione interna. Gli slot vengono riutilizzati se sono rimasti dal livello di elaborazione dei dati o di calcolo.
• Prenotazioni di elaborazione di Analytics: 500 slot, consentono l'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 il risultato della necessità di ridurre la latenza dei dati per i consumatori o di rispettare 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 policy per le colonne e gli impegni di slot come risorse regionali. Gli slot possono accedere solo ai set di dati nella regione locale e le norme sulle colonne possono essere applicate 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 di più sulle best practice IAM.