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

Questo documento fornisce tecniche e best practice per pattern comuni che sono utilizzate in piattaforme dati multi-tenant e 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 efficaci per impedire la fuga di dati tra i tenant.
• 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 in designati e obbligatori località geografiche. Per problemi relativi alla conformità, consulta Google Cloud offerte in materia di conformità.
• Controllo e sicurezza: proteggi i dati del tenant da contenuti inappropriati l'accesso e l'esfiltrazione.
• Gestione dei costi: assicurati costi coerenti di BigQuery per ospitare ogni tenant.
• Complessità operativa: riduci al minimo la quantità di variabilità del sistema necessario 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 clienti. Questi clienti potrebbero decine di migliaia di utenti e ai dati dei clienti era possibile accedere della tua infrastruttura di servizi. Alcuni fornitori SaaS dispongono inoltre di un centro sanitizzato per eseguire analisi sull'intero parco 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: quanto è aggiornato il datastore per entrambi tenant e soluzioni di analisi tra clienti
• Aspettative di rendimento: 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, sono separati da set di dati BigQuery. All'interno dell'host un'organizzazione, utilizzerai un secondo progetto per eseguire il deployment di analisi sulla combinazione dei dati dei clienti. Puoi quindi configurare il motore di elaborazione dei dati, Dataflow per eseguire la doppia scrittura dei dati in entrata nelle tabelle interne e specifiche per il tenant. La La configurazione di Dataflow utilizza tabelle completamente scritte anziché viste autorizzate. L'utilizzo di tabelle completamente scritte consente una gestione uniforme distribuzione geografica e aiuta a evitare di raggiungere limiti di visualizzazione autorizzati quando il numero di tenant viene scalato.

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 struttura consigliata:

Figura 1. Un numero costante di progetti gestisce le esigenze dei dati e di elaborazione il numero di inquilini cresce.

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 dati tenant combinato: il progetto di dati principale che mantiene un per ogni cliente. Si prevede che i dati dei tenant siano accessibili tramite di computing a livello di progetto.
• 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 che sono progettati per interagire con gli utenti finali. Ti consigliamo di utilizzare con ambito tenant per accedere ai set di dati dei tenant e utilizzare una e sicuro pipeline di creazione 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.

Condividi le prenotazioni

Con questo approccio, le prenotazioni si basano pianificazione equa integrato nelle prenotazioni BigQuery. Ogni unità di elaborazione è assegnata a un singolo progetto. Le query degli inquilini utilizzano fair use 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 di dati dei tenant.
• Dati tenant: un perimetro che circonda il progetto del set di dati tenant. dei progetti di computing BigQuery del tenant. Applica tutto 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 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 quanto segue: 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 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 interne: consenti le applicazioni rivolte all'esterno per elaborare i dati utilizzando i modelli lo sviluppo e il deployment di applicazioni.

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 della gestione delle richieste per i dati tenant 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: quanto è aggiornato il datastore per entrambi tra i tenant e le soluzioni di analisi tra clienti.
• Aspettative di rendimento: garantire che le prestazioni del tenant rimangano entro limiti accettabili.

Colloca set di dati con risorse dedicate

Quando esegui il deployment di un'infrastruttura tenant dedicata, ti consigliamo di creare padre cartella per i progetti specifici per il 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 tenant che accedono ai dati del tenant sono organizzati in progetti specifici per il tenant (e organizzati facoltativamente in cartelle dedicate al tenant) per semplificare 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 per un singolo tenant 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 dei livelli 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. Correlate ai progetti limiti impediscono a un'organizzazione di usare confini perimetrali intorno a progetti a interagire con i progetti tenant. Consigliamo invece di utilizzare le regole IAM rigide controlli e disabilita 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 di base vengono archiviati in il repository centrale e i sottoinsiemi sono condivisi lungo le linee di business. Data mart hanno spesso decine o centinaia di inquilini, rappresentati come linee di business le informazioni da considerare.

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

• Collaborazione sicura sui dati: condividi i dati con i controlli tecnici per per ridurre al minimo gli accessi inappropriati tra i team.
• Governance centrale dei dati: garantire l'utilizzo dei principali asset di dati per attività critiche i report aziendali sono standardizzati e convalidati.
• Attribuzione del costo per unità aziendale: monitoraggio e aggiustamento dei calcoli per unità aziendali.

Utilizza un repository amministrato centralmente

In questa progettazione, i dati principali 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 usano gli slot allocati ai propri progetti per creare e set di dati derivati. Il team dei dati principali utilizza le viste autorizzate mantiene la piena proprietà del controllo dell'accesso alle risorse del data mart. In questo ti consigliamo di evitare di creare più livelli di viste parte superiore degli oggetti presentati nel progetto di dati principali. Il seguente diagramma mostra una configurazione di progetto di esempio basata su questa progettazione consigliata:

Figura 3. Un progetto di dati di base mantiene un data mart centralizzato accessibili 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 set di dati all'interno di questo progetto e concedere viste autorizzate ai tuoi dati e analisi i team in base all'appartenenza ai gruppi.
• 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 proprio o come parte il progetto di dati principali.
• Progetti del team di Analytics: i consumatori del data mart utilizzano questi ai progetti e utilizzare l'accesso all'infrastruttura di cui è stato eseguito il provisioning per elaborare 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 della prenotazione a due livelli

Quando si lavora con i data mart, consigliamo di utilizzare una progettazione a due livelli. In un la progettazione a due livelli, risorsa 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.

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.
• 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 una maggiore di accesso permissivo rispetto al perimetro dei dati di base con cui è collegato.

Bridge perimetrali

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

• Pipeline di dati e dati principali: consentono alle pipeline di dati di scrivere in il progetto di dati principali.
• Dati principali e analisi: consenti agli utenti dei progetti di analisi di a 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 segmentare i dati con viste autorizzate quando devono esistere data mart in più regioni. Puoi utilizzare invece BigQuery Data Transfer Service per copiare i set di dati pertinenti in in un'altra regione. In questo scenario, crei criteri di colonna all'interno dei dati per ogni regione aggiuntiva in cui risiedono i dati. Le seguenti mostra una configurazione per più regioni:

Figura 4. Una configurazione per più regioni 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 dati principali: il perimetro di governance per la gestione dell'accesso a e le 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, potresti scegliere di eseguire il deployment dell'infrastruttura ETL come progetto proprio o come parte il progetto di dati principali.
• 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 Analytics dovrebbe essere in grado di creare set di dati derivati per l'uso locale.

BigQuery Data Transfer Service è un'ulteriore soluzione componente 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 altri script per creare specifici per regione nello scheduler 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 sui dati: condividi i dati con i controlli tecnici per 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 avere in grado di fidarsi dell'origine dei dati che vengono inseriti nei loro prodotti di analisi.

Delega l'amministrazione dei dati di base

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

Figura 5. Un progetto di governance di base aiuta a garantire una sicurezza coerente, mentre i singoli gruppi contengono le loro operazioni sui dati.

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

• Core governance Progetto: il progetto responsabile dei problemi di gestione all'interno dell'organizzazione. In questo progetto, crei risorse di sicurezza come i keyring di Cloud KMS e il catalogo dati criteri delle colonne. Questo progetto funge da BigQuery progetto di amministrazione delle prenotazioni, consentendo la condivisione degli slot a livello di organizzazione.
• Progetti di dati di unità organizzative: i proprietari dei dati autogestiti. all'interno dell'organizzazione nel suo complesso. Il progetto di governance di base gestisce per i progetti relativi ai 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 della prenotazione a due livelli

Ti consigliamo di far sì che i data mart decentralizzati utilizzino lo stesso design a due livelli come data mart standard. In questa configurazione, assegni il ruolo risorsa 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.

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 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 la creazione e il deployment di asset di analisi all'interno 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 il seguente perimetro bridge:

• 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 è una considerazione particolare per la progettazione di un data mart la progettazione. 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 relativi ai dati chi condivide:

• Condivisione di riservatezza: solo la parte prevista può accedere ai contenuti condivisi e i dati di Google Cloud.
• Protezione da accessi inappropriati: solo risorse che sono a cui si accede dall'esterno.
• Separazione del calcolo: alle parti esterne vengono addebitate le query che avviano.

Nota: in alcuni casi, le query provenienti dall'organizzazione esterna possono errore imprevisto. 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 multi-organizzativa si concentra sulla protezione progetti interni dell'organizzazione dall'attività nei progetti di dati condivisi. La progetto di set di dati condiviso agisce da buffer per non consentire l'accesso a il trattamento dati, offrendo al contempo la possibilità di condividerli esternamente.

Le query che vengono avviate dal progetto esterno utilizzano il metodo di risorse di computing. Se tutti i set di dati sottoposti a query condividono lo stesso Google Cloud regione, queste query possono unire i dati di più 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 in in altri progetti condivisi.

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

• Progetto interno dell'organizzazione: il progetto che contiene dati sensibili dati interni. Il progetto interno può condividere dati esternamente copiando sanitizzati nei set di dati del progetto di dati condivisi. L'interfaccia deve essere proprietario dell'account di servizio responsabile dell'aggiornamento 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 il servizio seguente perimetri:

• 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 l'accesso 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 sui sistemi multi-tenant

Questa sezione fornisce un'analisi più approfondita dei 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 la 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 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.
• I Controlli di servizio VPC hanno un limite di 10.000 progetti all'interno del servizio perimetri 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 delle viste autorizzate o delle tabelle di sottoinsiemi materializzati

Per gestire l'accesso dei tenant a sottoinsiemi di tabelle dei fatti di grandi dimensioni, puoi utilizzare viste autorizzate specifiche per il tenant o creare tabelle di sottoinsiemi specifici per il tenant. La la seguente tabella mette a confronto 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 viste autorizzate, set di dati autorizzati e funzioni autorizzate.Non esistono limiti al numero di set di dati in un o tabelle in un set di dati.
Partizionamento e clustering	Le viste autorizzate devono condividere lo schema di partizionamento e cluster comune di la tabella di base. Per migliorare le prestazioni della segmentazione dei tenant, è consigliabile: raggruppa la tabella padre sull'ID tenant.	Puoi partizionare la tabella del sottoinsieme e raggrupparla in base alle esigenze del tenant.
Aree geografiche	Le viste autorizzate non possono intercorrere tra regioni e devono trovarsi nella regione Google Cloud della tabella di base. La regionalizzazione influisce tenant geograficamente remoti.	Le tabelle di sottoinsiemi possono trovarsi nella regione più appropriata per il tenant. Aggiuntivo costi.
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 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 istantaneamente l'oggetto che i tenant sono accedono.	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 oltre alle autorizzazioni IAM standard.

Crittografia fornita dal client

La crittografia dei dati client riguarda i casi in cui un'organizzazione di hosting archivia e elabora i dati per conto di un tenant, ma gli viene impedito di accedere ad alcune contenuti di 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 un uno scenario di data mart. Le visualizzazioni autorizzate non possono concedere l'accesso a un colonna.

Quando imposti il criterio per applicare il controllo dell'accesso, impedisci l'accesso agli utenti a cui non è stato concesso Lettore granulare ruolo al criterio. Anche se non viene applicato in modo forzato, il criterio registra tutti l'accesso degli utenti alla colonna categorizzata.

Protezione dei dati sensibili

Sensitive Data Protection fornisce API e utilità di analisi che ti consentono di identificare e mitigare i contenuti sensibili archiviati set di dati BigQuery o Cloud Storage. 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 aiuta a controllare i costi lo scale up dei tenant e garantisce prestazioni garantite per ogni tenant.

Per gestire le prenotazioni, ti consigliamo di creare un'unica prenotazione un progetto amministrativo di un'organizzazione. 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 uno slot gli impegni possono essere assegnati 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 garantire che gli obiettivi del livello di servizio (SLO) del tenant siano soddisfatti, puoi monitor tramite Cloud Logging e BigQuery schema delle informazioni. Organizzazioni che subiscono periodi di punta dall'attività degli analisti o dalla priorità i job possono allocare capacità aggiuntiva slot flessibili.

Prenotazioni come livelli di computing 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 dedichi ogni prenotazione a un singolo progetto e gruppo di tenant per condividere il progetto per il computing di BigQuery. Questa progettazione riduce di avere migliaia di altri progetti consentendo alla tua organizzazione di allocare un minimo capacità slot necessarie per soddisfare le esigenze di rendimento previste per la prenotazione.

Se Trattamento dati ELT la tempestività è una priorità assoluta, ti consigliamo di assegnare 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 dei dati: 2000 slot, ignora i dati inattivi. Questa prenotazione è configurate per soddisfare gli SLO di elaborazione dati.
• Progetti interni: 1000 slot, consentiti in caso di inattività. Questa prenotazione è applicati ai progetti usati per le analisi interne.Gli slot riutilizzate se provengono da livelli di elaborazione dati o di calcolo.
• Livello di computing basso: 2000 slot, ignora l'inattività. Questa prenotazione è applicate ai tenant con poche risorse. A differenza del livello alto, ignora gli slot inattivi.
• Livello di computing elevato: 3000 slot, consentiti in caso di inattività. Questa prenotazione è applicate 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 lavori con i team in un'impostazione data mart, ti consigliamo di creare un'immagine per ogni team che richiede ulteriori risorse di calcolo. Poi assegna nella cartella principale che contiene i progetti del team. Tutti nuovi per i progetti che quel team utilizza pianificazione equa di slot 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à. Questo assegnata all'organizzazione di primo livello e concede slot a qualsiasi utente di BigQuery che non utilizza un progetto con 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, consentiti in caso di inattività. Questa prenotazione è applicati ai progetti usati per l'amministrazione interna. Slot machine vengono riutilizzati se provengono dall'elaborazione dei dati o da livelli di calcolo.
• Prenotazioni di elaborazione dati e analisi: 500 slot, consentiti in caso di inattività. Si tratta di un una prenotazione dedicata inviata a un team di analisi.

Requisiti di hosting per più regioni

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

I progetti in Google Cloud sono considerati globali e possono eseguire il provisioning di 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 che contiene set di dati.

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

Passaggi successivi

• Informazioni su Best practice IAM.