Migrazione da Amazon Redshift a BigQuery: panoramica

Questo documento fornisce indicazioni sulla migrazione da Amazon Redshift a BigQuery, concentrandoti sui seguenti argomenti:

  • Strategie per la migrazione
  • Best practice per l'ottimizzazione delle query e la modellazione dei dati
  • Suggerimenti per la risoluzione dei problemi
  • Indicazioni per l'adozione da parte degli utenti

Gli obiettivi del presente documento sono i seguenti:

  • Fornisci indicazioni di alto livello alle organizzazioni che eseguono la migrazione da Amazon Redshift a BigQuery, aiutandoti anche a ripensare le pipeline di dati esistenti per ottenere il massimo da BigQuery.
  • Aiuta a confrontare le architetture di BigQuery e Amazon Redshift in modo da poter determinare come implementare le caratteristiche e le capacità esistenti durante la migrazione. L'obiettivo è mostrarti le nuove funzionalità disponibili per la tua organizzazione tramite BigQuery, non mappare le caratteristiche uno a uno con Amazon Redshift.

Questo documento è rivolto ad architetti aziendali, amministratori di database, sviluppatori di applicazioni ed esperti della sicurezza IT. Supponendo che tu abbia familiarità con Amazon Redshift.

Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione in blocco degli script SQL oppure la traduzione SQL interattiva per tradurre query ad hoc. SQL di Amazon Redshift è completamente supportato da entrambi i servizi di traduzione SQL.

Attività di pre-migrazione

Per garantire il successo della migrazione del data warehouse, inizia a pianificare la strategia di migrazione fin dalle prime fasi del progetto. Questo approccio ti consente di valutare le funzionalità di Google Cloud adatte alle tue esigenze.

Pianificazione della capacità

BigQuery utilizza gli slot per misurare la velocità effettiva dell'analisi. Uno slot BigQuery è l'unità di capacità di calcolo di proprietà di Google richiesta per eseguire query SQL. BigQuery calcola costantemente quanti slot sono richiesti dalle query durante l'esecuzione, ma alloca gli slot alle query in base a un equo scheduler.

Puoi scegliere tra i seguenti modelli di prezzi durante la pianificazione della capacità per gli slot BigQuery:

  • Prezzi on demand: con i prezzi on demand, BigQuery addebita il numero di byte elaborati (dimensioni dei dati), quindi paghi solo per le query eseguite. Per ulteriori informazioni su come BigQuery determina le dimensioni dei dati, consulta Calcolo delle dimensioni dei dati. Poiché gli slot determinano la capacità di calcolo di base, puoi pagare per l'utilizzo di BigQuery a seconda del numero di slot necessari (anziché i byte elaborati). Per impostazione predefinita, tutti i progetti Google Cloud sono limitati a un massimo di 2000 slot. BigQuery potrebbe superare questo limite per accelerare le query, ma il bursting non è garantito.
  • Prezzi basati sulla capacità: con i prezzi basati sulla capacità, acquisti prenotazioni di slot BigQuery (almeno 100) anziché pagare per i byte elaborati dalle query che esegui. Consigliamo prezzi basati sulla capacità per i carichi di lavoro dei data warehouse aziendali, che di solito prevedono molte query simultanee di reporting ed estrazione, trasformazione del carico e trasformazioni del carico (ELT) con un consumo prevedibile.

Per facilitare la stima degli slot, consigliamo di configurare il monitoraggio di BigQuery mediante Cloud Monitoring e di analizzare gli audit log utilizzando BigQuery. Puoi utilizzare Looker Studio (ecco un esempio open source di una dashboard di Looker Studio) o Looker per visualizzare i dati degli audit log di BigQuery, in particolare per l'utilizzo degli slot in query e progetti. Puoi anche utilizzare i dati delle tabelle di sistema di BigQuery per monitorare l'utilizzo degli slot in job e prenotazioni (ecco un esempio open source di dashboard di Looker Studio). Il monitoraggio e l'analisi regolari dell'utilizzo degli slot ti aiutano a stimare il numero totale di slot di cui la tua organizzazione ha bisogno man mano che cresci su Google Cloud.

Ad esempio, supponiamo che inizialmente prenoti 4000 slot BigQuery per eseguire contemporaneamente 100 query a complessità media. Se noti tempi di attesa elevati nei piani di esecuzione delle tue query e le tue dashboard mostrano un elevato utilizzo degli slot, questo potrebbe indicare che hai bisogno di ulteriori slot BigQuery per supportare i tuoi carichi di lavoro. Se vuoi acquistare slot autonomamente con impegni annuali o triennali, puoi iniziare a utilizzare le prenotazioni di BigQuery utilizzando la console Google Cloud o lo strumento a riga di comando bq. Per ulteriori dettagli sulla gestione dei carichi di lavoro, sull'esecuzione delle query e sull'architettura di BigQuery, consulta Migrazione a Google Cloud: una vista approfondita.

Security in Google Cloud Platform

Le sezioni seguenti descrivono i controlli di sicurezza comuni di Amazon Redshift e come contribuire a garantire che il data warehouse rimanga protetto in un ambiente Google Cloud.

Gestione di identità e accessi

La configurazione dei controlli dell'accesso in Amazon Redshift prevede la scrittura dei criteri delle autorizzazioni API di Amazon Redshift e il loro collegamento alle identità Identity and Access Management (IAM). Le autorizzazioni dell'API Amazon Redshift forniscono l'accesso a livello di cluster, ma non forniscono livelli di accesso più granulari rispetto al cluster. Se vuoi un accesso più granulare a risorse come tabelle o viste, puoi utilizzare gli account utente nel database Amazon Redshift.

BigQuery usa IAM per gestire l'accesso alle risorse a un livello più granulare. I tipi di risorse disponibili in BigQuery sono organizzazioni, progetti, set di dati, tabelle, colonne e viste. Nella gerarchia dei criteri IAM, i set di dati sono risorse figlio dei progetti. Una tabella eredita le autorizzazioni dal set di dati che la contiene.

Per concedere l'accesso a una risorsa, assegna uno o più ruoli IAM a un account utente, gruppo o di servizio. I ruoli di organizzazione e progetto influiscono sulla possibilità di eseguire job o gestire il progetto, mentre i ruoli del set di dati influiscono sulla possibilità di accedere o modificare i dati all'interno di un progetto.

IAM offre i seguenti tipi di ruoli:

  • Ruoli predefiniti, pensati per supportare casi d'uso comuni e pattern di controllo dell'accesso.
  • Ruoli personalizzati, che forniscono un accesso granulare in base a un elenco di autorizzazioni specificate dall'utente.

All'interno di IAM, BigQuery fornisce il controllo dell'accesso a livello di tabella. Le autorizzazioni a livello di tabella determinano gli utenti, i gruppi e gli account di servizio che possono accedere a una tabella o una visualizzazione. Puoi concedere a un utente l'accesso a tabelle o visualizzazioni specifiche senza concedere l'accesso al set di dati completo. Per un accesso più granulare, puoi anche prendere in considerazione l'implementazione di uno o più dei seguenti meccanismi di sicurezza:

Crittografia completa del disco

Oltre alla gestione di identità e accessi, la crittografia dei dati aggiunge un ulteriore livello di difesa per la protezione dei dati. In caso di esposizione dei dati, i dati criptati non sono leggibili.

Su Amazon Redshift, la crittografia sia dei dati at-rest che dei dati in transito non è abilitata per impostazione predefinita. La crittografia dei dati at-rest deve essere esplicitamente abilitata all'avvio di un cluster oppure modificando un cluster esistente per utilizzare la crittografia di AWS Key Management Service. Anche la crittografia dei dati in transito deve essere esplicitamente abilitata.

BigQuery cripta tutti i dati at-rest e in transito per impostazione predefinita, indipendentemente dall'origine o da qualsiasi altra condizione, e questa impostazione non può essere disattivata. BigQuery supporta anche le chiavi di crittografia gestite dal cliente (CMEK) se vuoi controllare e gestire le chiavi di crittografia delle chiavi in Cloud Key Management Service.

Per ulteriori informazioni sulla crittografia in Google Cloud, consulta i white paper sulla crittografia dei dati at-rest e sulla crittografia dei dati in transito.

Per i dati in transito su Google Cloud, i dati vengono criptati e autenticati quando si spostano al di fuori dei confini fisici controllati da Google o per conto di Google. Entro questi confini, i dati in transito sono generalmente autenticati, ma non necessariamente criptati.

Prevenzione della perdita di dati

I requisiti di conformità potrebbero limitare i dati che possono essere archiviati su Google Cloud. Puoi utilizzare Sensitive Data Protection per analizzare le tabelle BigQuery in modo da rilevare e classificare i dati sensibili. Se vengono rilevati dati sensibili, le trasformazioni di anonimizzazione di Sensitive Data Protection possono mascherare, eliminare o oscurare in altro modo questi dati.

Migrazione a Google Cloud: nozioni di base

Utilizza questa sezione per saperne di più sull'utilizzo di strumenti e pipeline per facilitare la migrazione.

Strumenti di migrazione

BigQuery Data Transfer Service fornisce uno strumento automatizzato per la migrazione diretta di schemi e dati da Amazon Redshift a BigQuery. La tabella seguente elenca ulteriori strumenti utili per la migrazione da Amazon Redshift a BigQuery:

Strumento Purpose
BigQuery Data Transfer Service Esegui un trasferimento batch automatizzato dei tuoi dati Amazon Redshift in BigQuery utilizzando questo servizio completamente gestito.
Storage Transfer Service Importa rapidamente i dati Amazon S3 in Cloud Storage e configura una pianificazione ripetuta per il trasferimento dei dati utilizzando questo servizio completamente gestito.
gsutil Copia i file Amazon S3 in Cloud Storage utilizzando questo strumento a riga di comando.
strumento a riga di comando bq Interagisci con BigQuery utilizzando questo strumento a riga di comando. Le interazioni più comuni includono la creazione di schemi delle tabelle BigQuery, il caricamento dei dati di Cloud Storage nelle tabelle e l'esecuzione di query.
Librerie client di Cloud Storage Copia i file Amazon S3 in Cloud Storage utilizzando il tuo strumento personalizzato, basato sulla libreria client di Cloud Storage.
Librerie client di BigQuery Interagisci con BigQuery utilizzando il tuo strumento personalizzato, basato sulla libreria client di BigQuery.
Pianificazione query BigQuery Pianifica query SQL ricorrenti utilizzando questa funzionalità integrata di BigQuery.
Cloud Composer Orchestra trasformazioni e job di caricamento BigQuery utilizzando questo ambiente Apache Airflow completamente gestito.
Apache Sqoop Invia i job Hadoop utilizzando Sqoop e il driver JDBC di Amazon Redshift per estrarre i dati da Amazon Redshift in HDFS o in Cloud Storage. Sqoop viene eseguito in un ambiente Dataproc.

Per ulteriori informazioni sull'utilizzo di BigQuery Data Transfer Service, consulta Eseguire la migrazione di schema e dati da Amazon Redshift.

Migrazione tramite pipeline

La migrazione dei dati da Amazon Redshift a BigQuery può seguire percorsi diversi a seconda degli strumenti di migrazione disponibili. Sebbene l'elenco di questa sezione non sia esaustivo, fornisce un'idea dei diversi pattern della pipeline di dati disponibili durante lo spostamento dei dati.

Per informazioni più generali sulla migrazione dei dati a BigQuery tramite le pipeline, consulta Migrazione delle pipeline di dati.

Estrai e carica (EL)

Puoi automatizzare completamente una pipeline EL utilizzando BigQuery Data Transfer Service, che può copiare automaticamente gli schemi e i dati delle tue tabelle dal cluster Amazon Redshift a BigQuery. Se vuoi avere un maggiore controllo sui passaggi della pipeline di dati, puoi creare una pipeline utilizzando le opzioni descritte nelle sezioni seguenti.

Utilizza le estrazioni dei file Amazon Redshift
  1. Esporta i dati di Amazon Redshift in Amazon S3.

  2. Copia i dati da Amazon S3 in Cloud Storage utilizzando una delle seguenti opzioni:

  3. Carica i dati di Cloud Storage in BigQuery usando una delle seguenti opzioni:

Utilizzare una connessione JDBC di Amazon Redshift

Utilizza uno dei seguenti prodotti Google Cloud per esportare i dati di Amazon Redshift utilizzando il driver JDBC di Amazon Redshift:

Estrai, trasforma e carica (ETL)

Se vuoi trasformare alcuni dati prima di caricarli in BigQuery, segui gli stessi suggerimenti per la pipeline descritti nella sezione Estrai e carica (EL), aggiungendo un passaggio aggiuntivo per trasformare i dati prima di caricarli in BigQuery.

Utilizza le estrazioni dei file Amazon Redshift

  1. Esporta i dati di Amazon Redshift in Amazon S3.

  2. Copia i dati da Amazon S3 in Cloud Storage utilizzando una delle seguenti opzioni:

  3. Trasforma e poi carica i tuoi dati in BigQuery utilizzando una delle seguenti opzioni:

Utilizzare una connessione JDBC di Amazon Redshift

Utilizza uno dei prodotti descritti nella sezione Estrai e carica (EL), aggiungendo un passaggio aggiuntivo per trasformare i dati prima di caricarli in BigQuery. Modifica la pipeline per introdurre uno o più passaggi per trasformare i dati prima di scrivere in BigQuery.

Estrazione, caricamento e trasformazione (ELT)

Puoi trasformare i tuoi dati utilizzando BigQuery, utilizzando una qualsiasi delle opzioni Estrai e carica (EL) per caricarli in una tabella temporanea. Poi trasformerai i dati in questa tabella temporanea utilizzando query SQL che scrivono il loro output nella tabella di produzione finale.

Change Data Capture (CDC)

Change Data Capture è uno dei vari pattern di progettazione di software utilizzati per tenere traccia delle modifiche ai dati. Viene spesso utilizzato nel data warehousing perché viene utilizzato per raccogliere e monitorare i dati e le relative modifiche da vari sistemi di origine nel tempo.

Strumenti dei partner per la migrazione dei dati

Esistono diversi fornitori nello spazio ETL (Extract, Transform, Load). Consulta il sito web del partner BigQuery per un elenco dei partner principali e delle soluzioni fornite.

Migrazione a Google Cloud: approfondimento

Utilizza questa sezione per saperne di più su come l'architettura, lo schema e il dialetto SQL del data warehouse influiscono sulla migrazione.

Confronto dell'architettura

Sia BigQuery che Amazon Redshift si basano su un'architettura di elaborazione estremamente parallela (MPP). Le query vengono distribuite su più server per accelerarne l'esecuzione. Per quanto riguarda l'architettura di sistema, Amazon Redshift e BigQuery differiscono principalmente per le modalità di archiviazione dei dati e di esecuzione delle query. In BigQuery, le configurazioni e l'hardware sottostanti sono astratti; le sue funzionalità di archiviazione e computing consentono al tuo data warehouse di crescere senza che sia necessario alcun intervento da parte tua.

Computing, memoria e archiviazione

In Amazon Redshift, CPU, memoria e spazio di archiviazione su disco sono collegati tramite nodi di computing, come illustrato in questo diagramma tratto dalla documentazione di Amazon Redshift. Le prestazioni e la capacità di archiviazione del cluster sono determinate dal tipo e dalla quantità di nodi di computing, che devono essere entrambi configurati. Per modificare le risorse di elaborazione o archiviazione, devi ridimensionare il cluster tramite un processo (oltre un paio d'ore o fino a due giorni o più) che crei un nuovo cluster e copia i dati. Amazon Redshift offre inoltre nodi RA3 con archiviazione gestita, che aiutano a separare computing e archiviazione. Il nodo più grande della categoria RA3 ha un limite di 64 TB di spazio di archiviazione gestito per ogni nodo.

Fin dall'inizio, BigQuery non collega calcolo, memoria e archiviazione, ma li gestisce separatamente.

Il computing BigQuery è definito da slot, un'unità di capacità di calcolo richiesta per eseguire le query. Google gestisce l'intera infrastruttura incapsulata da uno slot, eliminando tutto tranne il compito di scegliere la quantità di slot adeguata per i carichi di lavoro BigQuery. Consulta la pianificazione della capacità per decidere quanti slot acquistare per il data warehouse. La memoria BigQuery è fornita da un servizio distribuito remoto, collegato agli slot di calcolo dalla rete Petabit di Google, il tutto gestito da Google.

Sia BigQuery che Amazon Redshift utilizzano l'archiviazione a colonne, mentre BigQuery impiega variazioni e progressi per l'archiviazione a colonne. Durante la codifica delle colonne, durante l'esecuzione della query vengono utilizzate varie statistiche sui dati persistenti e in un secondo momento per compilare piani ottimali e scegliere l'algoritmo di runtime più efficiente. BigQuery archivia i tuoi dati nel file system distribuito di Google, dove vengono compressi, criptati, replicati e distribuiti automaticamente. Il tutto senza influire sulla potenza di calcolo disponibile per le query. La separazione dell'archiviazione dal calcolo consente di fare facilmente lo scale up fino a decine di petabyte di spazio di archiviazione, senza la necessità di costose risorse di calcolo aggiuntive. Esistono anche numerosi altri vantaggi derivanti dalla separazione delle risorse di elaborazione e archiviazione.

Scale up o scale down

Quando l'archiviazione o il calcolo diventano vincolati, i cluster Amazon Redshift devono essere ridimensionati modificando la quantità o i tipi di nodi nel cluster.

Per ridimensionare un cluster Amazon Redshift, puoi scegliere tra due approcci:

  • Ridimensionamento classico: Amazon Redshift crea un cluster in cui vengono copiati i dati, un processo che può richiedere un paio d'ore, fino a due giorni o più per grandi quantità di dati.
  • Ridimensionamento elastico: se modifichi solo il numero di nodi, le query vengono temporaneamente messe in pausa e le connessioni vengono mantenute aperte, se possibile. Durante l'operazione di ridimensionamento, il cluster è di sola lettura. In genere il ridimensionamento elastico richiede da 10 a 15 minuti, ma potrebbe non essere disponibile per tutte le configurazioni.

Poiché BigQuery è una soluzione Platform as a Service (PaaS), devi preoccuparti solo del numero di slot BigQuery che vuoi prenotare per la tua organizzazione. Puoi prenotare slot BigQuery nelle prenotazioni e assegnare i progetti a queste prenotazioni. Per informazioni su come configurare queste prenotazioni, consulta Pianificazione della capacità.

Esecuzione della query

Il motore di esecuzione di BigQuery è simile a quello di Amazon Redshift in quanto entrambi orchestrano la query suddividendola in passaggi (un piano di query), eseguendo i passaggi (contemporaneamente, se possibile) e quindi riassemblando i risultati. Amazon Redshift genera un piano di query statico, ma BigQuery non lo fa perché ottimizza dinamicamente i piani di query man mano che la query viene eseguita. BigQuery esegue lo shuffling dei dati utilizzando il proprio servizio di memoria remoto, mentre Amazon Redshift esegue lo shuffling dei dati utilizzando la memoria dei nodi di computing locale. Per ulteriori informazioni sull'archiviazione in BigQuery dei dati intermedi di varie fasi del piano di query, consulta Esecuzione di query in memoria in Google BigQuery.

Gestione dei carichi di lavoro in BigQuery

BigQuery offre i seguenti controlli per la gestione dei carichi di lavoro (WLM):

  • Query interattive, che vengono eseguite il prima possibile (impostazione predefinita).
  • Le query in batch, che vengono messe in coda per tuo conto, vengono avviate non appena le risorse inattive sono disponibili nel pool di risorse condiviso di BigQuery.

  • Prenotazioni di slot tramite prezzi basati sulla capacità. Anziché pagare per le query on demand, puoi creare e gestire dinamicamente bucket di slot chiamati prenotazioni e assign progetti, cartelle o organizzazioni a queste prenotazioni. Puoi acquistare impegni di slot BigQuery (a partire da un minimo di 100) con impegni flessibili, mensili o annuali per ridurre al minimo i costi. Per impostazione predefinita, le query in esecuzione in una prenotazione utilizzano automaticamente gli slot inattivi di altre prenotazioni.

    Come illustrato nel diagramma seguente, supponiamo di aver acquistato una capacità di impegno totale di 1000 slot da condividere tra tre tipi di carichi di lavoro: data science, ELT e business intelligence (BI). Per supportare questi carichi di lavoro, puoi creare le seguenti prenotazioni:

    • Puoi creare la prenotazione ds con 500 slot e assegnare tutti i progetti di data science di Google Cloud alla prenotazione.
    • Puoi creare la prenotazione elt con 300 slot e assegnare i progetti che utilizzi per i carichi di lavoro ELT a questa prenotazione.
    • Puoi creare la prenotazione bi con 200 slot e assegnare alla prenotazione progetti collegati ai tuoi strumenti BI.

    Questa configurazione è mostrata nell'immagine seguente:

    Come funzionano insieme gli impegni, le prenotazioni e le assegnazioni degli slot.

    Anziché distribuire le prenotazioni ai carichi di lavoro della tua organizzazione, ad esempio per la produzione e i test, potresti scegliere di assegnare le prenotazioni a singoli team o reparti, a seconda del caso d'uso.

    Per maggiori informazioni, consulta Gestione dei carichi di lavoro tramite le prenotazioni.

Gestione dei carichi di lavoro in Amazon Redshift

Amazon Redshift offre due tipi di gestione dei carichi di lavoro (WLM):

  • Automatico: con WLM automatico, Amazon Redshift gestisce la contemporaneità delle query e l'allocazione della memoria. Vengono create fino a otto code con gli identificatori 100-107 delle classi di servizio. Il WLM automatico determina la quantità di risorse necessarie per le query e regola la contemporaneità in base al carico di lavoro. Per maggiori informazioni, consulta Priorità delle query.
  • Manuale: al contrario, WLM manuale richiede di specificare i valori per la contemporaneità delle query e l'allocazione della memoria. L'impostazione predefinita per WLM manuale è la contemporaneità di cinque query e la memoria è divisa equamente tra tutte e cinque.

Se la scalabilità della contemporaneità è abilitata, Amazon Redshift aggiunge automaticamente ulteriore capacità al cluster quando ne hai bisogno per elaborare un aumento delle query di lettura simultanee. La scalabilità della contemporaneità richiede alcune considerazioni a livello di regione e query. Per ulteriori informazioni, consulta Candidati per la scalabilità della contemporaneità.

Configurazioni di set di dati e tabelle

BigQuery offre diversi modi per configurare i dati e le tabelle, come partizionamento, clustering e località dei dati. Queste configurazioni possono aiutare a mantenere tabelle di grandi dimensioni e a ridurre il carico complessivo dei dati e il tempo di risposta per le query, aumentando così l'efficienza operativa dei carichi di lavoro di dati.

Partizionamento

Una tabella partizionata è una tabella divisa in segmenti, denominati partizioni, che semplificano la gestione e l'esecuzione di query sui dati. In genere gli utenti suddividono le tabelle di grandi dimensioni in molte partizioni più piccole, dove ogni partizione contiene i dati di un giorno. La gestione della partizione è un fattore determinante per le prestazioni e i costi di BigQuery durante l'esecuzione di query in un intervallo di date specifico, perché consente a BigQuery di analizzare meno dati per query.

In BigQuery esistono tre tipi di partizionamento delle tabelle:

Una tabella partizionata nel tempo, basata su colonne, elimina la necessità di mantenere la consapevolezza della partizione indipendente dal filtro dei dati esistente nella colonna associata. I dati scritti in una tabella partizionata in base al tempo e basata su colonne vengono inviati automaticamente alla partizione appropriata in base al valore dei dati. Allo stesso modo, le query che esprimono filtri nella colonna di partizionamento possono ridurre i dati complessivi scansionati, con un conseguente miglioramento delle prestazioni e una riduzione del costo delle query per le query on demand.

Il partizionamento basato su colonne di BigQuery è simile al partizionamento basato su colonne di Amazon Redshift, con una motivazione leggermente diversa. Amazon Redshift utilizza la distribuzione delle chiavi basata su colonne per cercare di mantenere i dati correlati archiviati insieme all'interno dello stesso nodo di computing, riducendo al minimo lo data shuffling che si verifica durante i join e le aggregazioni. BigQuery separa l'archiviazione dal calcolo, pertanto utilizza il partizionamento basato su colonne per ridurre al minimo la quantità di dati letti dagli slot sul disco.

Una volta che i worker di slot leggono i propri dati dal disco, BigQuery può determinare automaticamente uno sharding dei dati ottimale e ripartizionare rapidamente i dati utilizzando il servizio di shuffle in memoria di BigQuery.

Per ulteriori informazioni, consulta Introduzione alle tabelle partizionate.

Raggruppamento e ordinamento delle chiavi

Amazon Redshift supporta la specifica di colonne delle tabelle come chiavi di ordinamento compound o con interleaving. In BigQuery puoi specificare le chiavi di ordinamento composto mediante il clustering della tabella. Le tabelle BigQuery in cluster migliorano le prestazioni delle query perché i dati della tabella vengono ordinati automaticamente in base ai contenuti di un massimo di quattro colonne specificate nello schema della tabella. Queste colonne sono usate per allocare i dati correlati. L'ordine delle colonne di clustering specificato è importante perché determina l'ordinamento dei dati.

Il clustering può migliorare le prestazioni di alcuni tipi di query, ad esempio le query che utilizzano clausole di filtro e le query che aggregano i dati. Quando i dati vengono scritti in una tabella in cluster da un job di query o un job di caricamento, BigQuery ordina automaticamente i dati utilizzando i valori nelle colonne di clustering. Questi valori vengono utilizzati per organizzare i dati in più blocchi nell'archiviazione di BigQuery. Quando invii una query contenente una clausola che filtra i dati in base alle colonne di clustering, BigQuery utilizza i blocchi ordinati per eliminare le analisi di dati non necessari.

Analogamente, quando invii una query che aggrega i dati in base ai valori nelle colonne di clustering, le prestazioni vengono migliorate perché i blocchi ordinati allocano righe con valori simili.

Utilizza il clustering nelle seguenti circostanze:

  • Le chiavi di ordinamento composte sono configurate nelle tabelle Amazon Redshift.
  • I filtri o l'aggregazione sono configurati in base a colonne specifiche nelle query.

Quando utilizzi il clustering e il partizionamento insieme, i dati possono essere partizionati in base a una colonna con data, timestamp o numero intero e quindi raggruppati in un insieme diverso di colonne (fino a un totale di quattro colonne in cluster). In questo caso, i dati in ogni partizione sono raggruppati in base ai valori delle colonne di clustering.

Quando specifichi le chiavi di ordinamento nelle tabelle di Amazon Redshift, a seconda del carico sul sistema, Amazon Redshift avvia automaticamente l'ordinamento utilizzando la capacità di calcolo del tuo cluster. Potresti anche dover eseguire manualmente il comando VACUUM se vuoi ordinare completamente i dati della tabella il prima possibile, ad esempio dopo un carico di dati elevato. BigQuery gestisce automaticamente questo ordinamento per te e non utilizza gli slot BigQuery allocati, quindi non influisce sulle prestazioni delle tue query.

Per ulteriori informazioni sull'utilizzo delle tabelle in cluster, consulta Introduzione alle tabelle in cluster.

Chiavi di distribuzione

Amazon Redshift utilizza le chiavi di distribuzione per ottimizzare la posizione dei blocchi di dati per l'esecuzione delle query. BigQuery non utilizza le chiavi di distribuzione perché determina e aggiunge automaticamente le fasi in un piano di query (mentre la query è in esecuzione) per migliorare la distribuzione dei dati tra i worker di query.

Sorgenti esterne

Se usi Amazon Redshift Spectrum per eseguire query sui dati su Amazon S3, puoi utilizzare in modo analogo la funzionalità dell'origine dati esterna di BigQuery per eseguire query sui dati direttamente dai file su Cloud Storage.

Oltre a eseguire query sui dati in Cloud Storage, BigQuery offre funzioni di query federate per eseguire direttamente query dai seguenti prodotti:

Località di dati

Puoi creare i tuoi set di dati BigQuery sia in località a singola regione che in località multiregionali, mentre Amazon Redshift offre solo località regionali. BigQuery determina la località in cui eseguire i job di caricamento, query o esportazione in base ai set di dati a cui viene fatto riferimento nella richiesta. Per suggerimenti su come lavorare con set di dati regionali e multiregionali, consulta le considerazioni sulle località di BigQuery.

Mappatura dei tipi di dati in BigQuery

I tipi di dati di Amazon Redshift sono diversi da quelli di BigQuery. Per ulteriori informazioni sui tipi di dati di BigQuery, consulta la documentazione ufficiale.

BigQuery supporta anche i seguenti tipi di dati, che non dispongono di un metodo analogico diretto di Amazon Redshift:

Confronto SQL

GoogleSQL supporta la conformità allo standard SQL 2011 e include estensioni che supportano l'esecuzione di query su dati nidificati e ripetuti. SQL di Amazon Redshift si basa su PostgreSQL, ma presenta diverse differenze, descritte in dettaglio nella documentazione di Amazon Redshift. Per un confronto dettagliato tra la sintassi e le funzioni di Amazon Redshift e GoogleSQL, consulta la guida alla traduzione SQL di Amazon Redshift.

Puoi utilizzare il traduttore SQL batch per convertire script e altro codice SQL dalla tua piattaforma attuale a BigQuery.

Dopo la migrazione

Poiché hai eseguito la migrazione di script che non sono stati progettati per BigQuery, puoi scegliere di implementare tecniche per ottimizzare le prestazioni delle query in BigQuery. Per ulteriori informazioni, consulta Introduzione all'ottimizzazione delle prestazioni delle query.

Passaggi successivi