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

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

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

I builder di piattaforme multi-tenant spesso devono trovare un equilibrio tra le considerazioni per seguenti:

• Isolamento dei dati: implementa controlli rigorosi per impedire la fuga di dati tra gli utenti.
• Rendimento coerente: configura e ripartisci 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 richieste. Per problemi relativi alla conformità, consulta le offerte di conformità di Google Cloud.
• Controllo e sicurezza: proteggi i dati del tenant da accessi e esfiltrazioni inappropriati.
• Gestione dei costi: assicurati 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 SaaS che ospitano dati di terze parti devono garantire l'affidabilità e l'isolamento dell'intero parco risorse dei clienti. Questi clienti potrebbero decine di migliaia di utenti e ai dati dei clienti era possibile accedere e l'infrastruttura dei servizi. Alcuni fornitori SaaS gestiscono anche un datastore centralizzato e sanificato per eseguire analisi nell'intera flotta di tenant.

La progettazione di un set di dati per tenant aiuta a mitigare i problemi indicati di seguito alle esperienze di ogni organizzazione, con la scalabilità fino a migliaia di tenant:

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

Configura i set di dati per ogni tenant

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

La separazione di BigQuery tra spazio di archiviazione computing consente di configurare meno progetti rispetto ai warehouse basati su cluster per gestire ad esempio i livelli di servizio e l'isolamento dei dati. Quando non è necessario e configurare i tenant con altre risorse cloud dedicato di risorse, consigliamo di considerare la configurazione predefinita di un per ogni tenant. Il seguente diagramma mostra un progetto di esempio in base a questa progettazione consigliata:

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

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

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

Condividere le prenotazioni

Con questo approccio, le prenotazioni si basano pianificazione equa integrato nelle prenotazioni BigQuery. Ogni prenotazione di livello di calcolo viene assegnata a un singolo progetto. Le query degli inquilini utilizzano gli slot di pianificazione disponibili per ogni progetto del livello di computing e non utilizzati gli slot di qualsiasi livello vengono riutilizzati automaticamente in un altro livello. Se un tenant ha requisiti di tempo specifici, puoi utilizzare una coppia è dedicato a fornire un numero esatto di slot.

Configura i perimetri Controlli di servizio VPC

Per questa configurazione, consigliamo Perimetri Controlli di servizio VPC per prevenire l'esposizione accidentale del tenant all'esterno della tua organizzazione Google Cloud e per prevenire unione di dati non autorizzati all'interno dell'organizzazione.

Perimetri

In questa configurazione, ti consigliamo di creare quanto segue: perimetri di servizio:

• Pipeline di dati: un perimetro attorno ai progetti della pipeline di dati dovrebbe applicare in modo forzato tutti i servizi che non richiedono la ricezione dei dati dei tenant.
• Dati tenant: un perimetro che circonda il progetto del set di dati tenant. dei progetti di computing BigQuery del tenant. Applica tutti i servizi per impedire l'accesso dall'esterno dell'organizzazione.
• Applicazioni interne: applica in modo forzato tutti i servizi e gli utilizzi livelli di accesso per concedere l'accesso alle risorse ai team dei reparti.
• Applicazioni esterne: un perimetro intorno alle tue applicazioni SaaS. Applica in modo forzato tutti i servizi che non sono necessari per il funzionamento delle applicazioni.

Bridge del perimetro

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

• Pipeline di dati e dati del tenant: consenti alla pipeline di scrivere dati nei set di dati del tenant.
• Pipeline di dati e applicazioni interne: consente alla pipeline di scrivere nel set di dati tra clienti.
• Applicazioni esterne e dati tenant: consenti l'accesso rivolto all'esterno per eseguire query sui dati dei tenant.
• Applicazioni esterne e applicazioni interne: consentono alle applicazioni rivolte all'esterno di elaborare i dati utilizzando i modelli sviluppati e implementati dalle applicazioni interne.

Fornitore SaaS con infrastruttura tenant dedicata

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

Il progetto di un'infrastruttura tenant dedicato affronta i seguenti aspetti quando si esegue il deployment dell'infrastruttura per ogni tenant BigQuery:

• Responsabilità della fatturazione: monitoraggio dei costi dell'infrastruttura associati con ogni tenant che ha effettuato l'onboarding.
• Latenza end-to-end: indica quanto è aggiornato il datastore sia per i tenant sia per le soluzioni di analisi cross-customer.
• Aspettative di rendimento: garantire che le prestazioni del tenant rimangano entro limiti accettabili.

Colloca set di dati con risorse dedicate

Quando esegui il deployment dell'infrastruttura del tenant dedicata, ti consigliamo di creare una cartella principale per i progetti specifici del tenant. Colloca quindi la posizione del tenant set di dati BigQuery in progetti con risorse dedicate che per accedere ai dati per conto del tenant. Per ridurre al minimo la latenza end-to-end i dati tenant, le pipeline Dataflow inseriscono i dati direttamente set di dati tenant.

Questa progettazione gestisce l'elaborazione e la distribuzione dei dati upstream, in modo simile precedente la progettazione di un'infrastruttura condivisa. Tuttavia, i dati e le applicazioni del tenant che accedono ai dati del tenant sono organizzati in progetti specifici per il tenant (e optionally in cartelle dedicate al tenant) per semplificare la fatturazione e la gestione delle risorse. Il seguente diagramma mostra un progetto di esempio in base a questa progettazione consigliata:

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

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

• Progetto pipeline di dati: i componenti fondamentali dell'infrastruttura ricevere, elaborare e distribuire i dati tenant sono pacchettizzati in un unico progetto.
• Progetti tenant dedicati: progetti che contengono tutte le risorse cloud dedicati a un singolo tenant, tra cui BigQuery e dei set di dati. Ti consigliamo di utilizzare Identity and Access Management (IAM) per limitino notevolmente l'ambito di accesso degli account e degli account di servizio per i set di dati dei clienti.
• Progetti di analisi interni: progetti che rappresentano le risorse autogestite che i team di analisi usano per valutare i dati tenant creare nuove funzionalità.
• Progetto di rete esterno: progetto che gestisce e instrada il tenant richieste ai propri backend dedicati.

Condividi le prenotazioni

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

Utilizza i controlli IAM e disabilita la creazione delle chiavi

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

Data mart con autorità centrale

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

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

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

Utilizzare un repository amministrato centralmente

In questo design, i dati di base vengono acquisiti in un repository amministrato centralmente. Visualizzazioni autorizzate funzioni definite dall'utente autorizzate, e i criteri delle colonne vengono spesso utilizzati insieme per condividere i dati con righe di e impedire la distribuzione accidentale di dati sensibili.

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

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

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

• Progetto dati principali: il perimetro di governance per la gestione dell'accesso a e le viste del data mart. Gestisci le visualizzazioni autorizzate all'interno dei set di dati di questo progetto e concedile ai tuoi team di analisi in base all'appartenenza al gruppo.
• Estrai, trasforma e carica (ETL) Infrastructure: infrastruttura per l'elaborazione delle origini dati upstream in i dati principali. A seconda delle esigenze di separazione amministrativa, potresti scegliere di eseguire il deployment dell'infrastruttura ETL come progetto autonomo o come parte del progetto di dati di base.
• Progetti del team di analisi: i consumatori del data mart utilizzano questi progetti e il proprio accesso all'infrastruttura di cui è stato eseguito il provisioning per elaborare i dati all'interno del data mart. I progetti del team di Analytics dovrebbero poter per creare set di dati derivati da usare a livello locale.

Utilizza un design di prenotazione a due livelli

Quando si lavora con i data mart, consigliamo di utilizzare una progettazione a due livelli. In un design a due livelli, assegni alla risorsa dell'organizzazione una prenotazione con un numero ridotto di slot per coprire l'utilizzo generale. Se i team se hai esigenze più elevate, assegna prenotazioni a livello di progetto o cartella.

Configurare i perimetri dei Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC impedire l'esposizione accidentale dei set di dati BigQuery al di fuori del proprio dell'organizzazione Google Cloud.

Perimetri

In questa configurazione, ti consigliamo di creare il servizio seguente perimetri:

• 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 di Google Cloud organizzazione, ti consigliamo di separare questo perimetro dal il perimetro dei dati.
• Analytics: un perimetro per creare ed eseguire il deployment di asset di analisi che interni all'organizzazione. Questo perimetro dovrebbe avere un criterio di accesso più permissivo rispetto al perimetro dei dati di base con cui è collegato.

Bridge del perimetro

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

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

Copiare i set di dati per le configurazioni multiregionali

Poiché BigQuery non consente le query tra regioni, non puoi utilizzare la strategia di segmentare i dati con viste autorizzate quando devono esistere data mart 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 di colonna all'interno dei dati per ogni regione aggiuntiva in cui risiedono i dati. Il seguente diagramma mostra una configurazione multiregionale:

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

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

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

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

Se la tua organizzazione ha bisogno di maggiore flessibilità, è possibile disponibili:

• Job Cloud Composer: puoi pianificare 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: infrastruttura ETL, come Dataflow, può eseguire la doppia scrittura di sottoinsiemi regionali nei target regioni. Se la tua organizzazione richiede una latenza minima tra regioni, consigliamo questa opzione.

Data mart con autorità decentralizzata

Utilizza l'autorità decentralizzata quando è necessaria la separazione amministrativa in base al sistema proprietario, settori di attività o aree geografiche.

Un data mart decentralizzato presenta le seguenti preoccupazioni diverse rispetto a un standard data mart:

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

Delegare l'amministrazione dei dati principali

Questo design è diverso da un approccio di data mart convenzionale perché l'autorità decentralizzata delega le decisioni di amministrazione dei dati principali ai sottogruppi componenti dell'organizzazione. Quando utilizzi l'autorità decentralizzata, mantieni il controllo centrale della sicurezza e della capacità di BigQuery utilizzando Cloud Key Management Service (Cloud KMS), i criteri di colonna, i Controlli di servizio VPC e le prenotazioni. Di conseguenza, eviterai il proliferazione di dati comune con i data warehouse autogestiti. Il seguente diagramma mostra un'architettura che utilizza l'autorità decentralizzata:

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

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

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

Utilizza un design di prenotazione a due livelli

Ti consigliamo di utilizzare per i tuoi data mart decentralizzati lo stesso design a due livelli dei data mart standard. In questa configurazione, assegni 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 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 dell'organizzazione. Le funzionalità di Dataplex aiutano anche gli amministratori della governance dei dati a identificare rapidamente nuovi asset di dati e applicare controlli appropriati.

Configura i perimetri Controlli di servizio VPC

In questa configurazione, consigliamo i perimetri Controlli di servizio VPC impedire l'esposizione accidentale dei set di dati BigQuery al di fuori del proprio dell'organizzazione Google Cloud.

Perimetri

In questa configurazione, ti consigliamo di creare il servizio seguente perimetri:

• Dati principali: un perimetro per proteggere il data warehouse e il data mart. e dei set di dati. Questo perimetro deve includere tutti i progetti dell'unità organizzativa e il progetto di governance dei dati.
• Analytics: un perimetro per creare e implementare asset di analisi interni all'organizzazione. Questo perimetro dovrebbe avere un livello di rispetto al perimetro dei dati principali con cui è collegato.

Bridge perimetrali

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

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

Condivisione dei dati tra più organizzazioni

La condivisione tra più organizzazioni è un aspetto di progettazione speciale per la progettazione di un data mart. Questo modello di condivisione dei dati è pensato per le organizzazioni che vogliono Condividere 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 chi condivide i dati:

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

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

Proteggi i progetti interni da quelli di dati condivisi

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

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

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

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

• Progetto interno dell'organizzazione: il progetto contenente dati interni sensibili. Il progetto interno può condividere dati esternamente copiando sanitizzati nei set di dati del progetto di dati condivisi. Il progetto interno deve possedere l'account di servizio responsabile dell'aggiornamento dei dati condivisi.
• Progetto di dati condivisi: il progetto che contiene i dati sottoposti a sanitizzazione e le informazioni copiate dal progetto interno. Utilizzare utenti esterni gruppi per gestire l'accesso da parte di soggetti esterni. In questo scenario, gestisci come funzione amministrativa e di assegnare agli account esterni l'autorizzazione di visualizzazione, in modo da poter 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 condividere i dati esternamente e per impedire l'esposizione accidentale delle 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. 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 forzata per accedere a BigQuery.

Bridge perimetrali

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

• Da interno a dati esterni: un bridge del perimetro consente di eseguire progetti di dati interni protetti per il traffico in uscita verso la condivisione esterna dei dati in modo programmatico a gestire i progetti.

Considerazioni aggiuntive nei sistemi multi-tenant

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

Limiti e quote delle risorse Google Cloud

• Gli account di servizio sono limitati a una quota temporanea di 100 account di servizio per progetto. Puoi richiedere una quota tramite Google Cloud Console per i progetti che gestiscono gli account di servizio del tenant.
• La contemporaneità di BigQuery ha una contemporaneità predefinita di 100 per progetto che inviano query (i progetti che contengono set di dati hanno limiti di questo tipo). Per aumentare questa quota flessibile, contatta il tuo rappresentante di vendita.
• Controlli di servizio VPC ha un limite di 10.000 progetti all'interno dei perimetri di servizio a livello di organizzazione. Se i progetti per progetto per tenant hanno un'alta con lo scale up, consigliamo una progettazione con set di dati per tenant.
• I Controlli di servizio VPC hanno un limite di 100 perimetri, tra cui bridge, per organizzazione.

Utilizzo di viste autorizzate o tabelle di sottoinsiemi materializzate

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

Funzionalità	Visualizzazioni autorizzate	Tabelle di sottoinsiemi
Numero di tenant supportati	Il limite fisso è 2500 autorizzate per set di dati.	Le risorse autorizzate includono visualizzazioni autorizzate, set di dati autorizzati e funzioni autorizzate. Non ci sono limiti al numero di set di dati in un progetto o di tabelle in un set di dati.
Partizionamento e clustering	Le viste autorizzate devono condividere lo schema di partizione e cluster comune della tabella di base. Per migliorare il rendimento della segmentazione dei tenant, ti consigliamo di aggregare la tabella principale in base all'ID tenant.	Puoi partizionare la tabella del sottoinsieme e raggrupparla in base alle esigenze del tenant.
Aree geografiche	Le viste autorizzate non possono attraversare regioni e devono trovarsi nella regione Google Cloud della tabella di base. La regionalizzazione interessa gli utenti con sede geografica remota.	Le tabelle di sottoinsiemi possono trovarsi 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 risorse autorizzate di visualizzazione 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 vengono riportati nel logging della tabella di base.	L'accesso a ogni tabella sottoinsieme viene registrato separatamente.
Flessibilità della trasformazione	Le viste autorizzate consentono di riprogettare istantaneamente l'oggetto che i tenant sono accedono.	Per modificare le tabelle dei sottoinsiemi sono necessarie modifiche complesse dello schema.

Controllo per i dati sensibili

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

Crittografia fornita dal client

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

Consigliamo che il mittente dei dati utilizzi le chiavi di crittografia AEAD, disponibili fonte Libreria Tink per criptare i dati sensibili. Le chiavi di crittografia AEAD della libreria Tink sono compatibili con Funzioni AEAD BigQuery. Il tenant può quindi decriptare i dati accedendo al materiale della chiave in un UDF autorizzata o passando il materiale della chiave come parametro di query e in 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 a causa di fughe accidentali tra i team che collaborano. Le visualizzazioni autorizzate sono il meccanismo preferito per condividere i dati tra i team in uno scenario di data mart. Le visualizzazioni autorizzate non possono concedere l'accesso a una colonna protetta.

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

Protezione dei dati sensibili

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

Gestione delle prenotazioni di slot

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

Per gestire le prenotazioni, ti consigliamo di creare un unico progetto amministrativo per le prenotazioni. Impegni slot acquistati all'interno dello stesso i progetti amministrativi sono condivisibili tra tutti prenotazioni che hanno origine dal progetto amministrativo. Un progetto che utilizza gli impegni per gli slot può essere assegnato a una sola prenotazione alla volta. Tutte le query che ha origine da un progetto gli slot possono essere condivisi in base alle risorse disponibili.

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

Prenotazioni come livelli di calcolo del tenant

I fornitori SaaS con decine o anche migliaia di tenant configurano comunemente un numero finito di prenotazioni BigQuery come risorse condivise.

Se sei un fornitore SaaS con un'infrastruttura tenant condivisa, ti consigliamo di dedicare ogni prenotazione a un singolo progetto e di raggruppare i tenant per condividere il progetto per l'elaborazione BigQuery. Questo design riduce di avere migliaia di altri progetti consentendo alla tua organizzazione di allocare un minimo capacità slot necessarie per soddisfare le esigenze di prestazioni previste per la prenotazione.

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

Di seguito è riportato un esempio di come configurare le prenotazioni come computing tenant del programma:

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

Se i tenant utilizzano un'infrastruttura dedicata, ti consigliamo e assegnare la cartella o il progetto designato alla prenotazione condivisa appropriata.

Prenotazioni per team

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

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

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

Requisiti di hosting per più regioni

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

I progetti in Google Cloud sono considerati globali e possono eseguire il provisioning delle risorse in qualsiasi regione. BigQuery considera i set di dati, le colonne e gli impegni slot sono risorse regionali. Gli slot possono accedere solo nella regione locale e i criteri delle colonne possono essere applicati solo alle tabelle all'interno di 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

• Informazioni su Best practice IAM.