Migrazione da Amazon Redshift a BigQuery: panoramica
Questo documento fornisce indicazioni sulla migrazione da Amazon Redshift a BigQuery, concentrandosi 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 dell'utente
Gli obiettivi di questo documento sono i seguenti:
- Forniscono indicazioni di alto livello per le organizzazioni che eseguono la migrazione da Amazon Redshift a BigQuery, ad esempio aiutandoti a ripensare alle tue pipeline di dati esistenti per ottenere il massimo da BigQuery.
- Ti aiutano a confrontare le architetture di BigQuery e Amazon Redshift in modo da poter determinare come implementare le funzionalità esistenti durante la migrazione. L'obiettivo è mostrarti le nuove funzionalità disponibili per la tua organizzazione tramite BigQuery, non mappare le funzionalità una a una con Amazon Redshift.
Questo documento è rivolto ad architetti aziendali, amministratori di database, sviluppatori di applicazioni e specialisti della sicurezza IT. Si assume che tu abbia dimestichezza con Amazon Redshift.
Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione collettiva degli script SQL o la traduzione SQL interattiva per tradurre query ad hoc. Amazon Redshift SQL è completamente supportato da entrambi i servizi di traduzione SQL.
Attività preliminari alla migrazione
Per contribuire a garantire una migrazione del data warehouse efficace, inizia a pianificare la strategia di migrazione nelle prime fasi della sequenza temporale del progetto. Questo approccio ti consente di valutare le funzionalità di Google Cloud più adatte alle tue esigenze.
Pianificazione della capacità
BigQuery utilizza gli slot per misurare la velocità effettiva delle analisi. Uno slot BigQuery è un'unità di capacità di calcolo di proprietà di Google necessaria per eseguire query SQL. BigQuery calcola continuamente il numero di slot necessari per le query durante l'esecuzione, ma li assegna in base a un programmatore equo.
Quando pianifichi la capacità per gli slot di BigQuery, puoi scegliere tra i seguenti modelli di determinazione dei prezzi:
- Prezzi on demand: con i prezzi on demand, BigQuery addebita i costi in base al numero di byte elaborati (dimensioni dei dati), quindi paghi solo per le query che esegui. 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 sottostante, puoi pagare per l'utilizzo di BigQuery in base al numero di slot di cui avrai bisogno (anziché in base ai byte elaborati). Per impostazione predefinita, tutti i progetti Google Cloud sono limitati a un massimo di 2000 slot. BigQuery potrebbe consentire il bursting oltre questo limite per accelerare le query, ma il bursting non è garantito.
- Prezzi basati sulla capacità: con i prezzi basati sulla capacità, acquisti reservations di slot BigQuery (un minimo di 100) anziché pagare per i byte elaborati dalle query che esegui. Consigliamo i prezzi basati sulla capacità per i carichi di lavoro dei data warehouse aziendali, che in genere presentano molte query ELT (estrazione, caricamento e trasformazione) e di generazione di report concorrenti con un consumo prevedibile.
Per facilitare la stima degli slot, ti consigliamo di configurare il monitoraggio di BigQuery utilizzando Cloud Monitoring e analizzare gli audit log utilizzando BigQuery. Puoi utilizzare Looker Studio (qui è riportato un esempio open source di una dashboard di Looker Studio) o Looker per visualizzare i dati dei log di controllo di BigQuery, in particolare per l'utilizzo degli slot tra query e progetti. Puoi anche utilizzare i dati delle tabelle di sistema di BigQuery per monitorare l'utilizzo degli slot tra job e prenotazioni (di seguito è riportato un esempio open source di una dashboard di Looker Studio). Monitorare e analizzare regolarmente l'utilizzo degli slot ti aiuta a stimare il numero totale di slot di cui la tua organizzazione ha bisogno man mano che cresce su Google Cloud.
Ad esempio, supponiamo che tu prenoti inizialmente 4000 slot BigQuery per eseguire 100 query di media complessità contemporaneamente. Se noti tempi di attesa elevati nei piani di esecuzione delle query e le tue dashboard mostrano un utilizzo elevato degli slot, potrebbe indicare che hai bisogno di altri slot BigQuery per supportare i tuoi carichi di lavoro. Se vuoi acquistare gli slot autonomamente tramite impegni annuali o di tre anni, 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 del carico di lavoro, sull'esecuzione delle query e sull'architettura di BigQuery, consulta Migrazione a Google Cloud: una visione approfondita.
Security in Google Cloud Platform
Le sezioni seguenti descrivono i controlli di sicurezza comuni di Amazon Redshift e come puoi contribuire a garantire che il tuo 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 di criteri di autorizzazione dell'API Amazon Redshift e il loro collegamento alle identità Identity and Access Management (IAM). Le autorizzazioni dell'API Amazon Redshift forniscono accesso a livello di cluster, ma non forniscono livelli di accesso più granulari del cluster. Se vuoi un accesso più granulare a risorse come tabelle o viste, puoi utilizzare gli account utente nel database Amazon Redshift.
BigQuery utilizza 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 figlie degli 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 utente, un gruppo o un account di servizio. I ruoli dell'organizzazione e del progetto influiscono sulla possibilità di eseguire job o gestire il progetto, mentre i ruoli dei set di dati influiscono sulla possibilità di accedere ai dati o modificarli all'interno di un progetto.
IAM fornisce i seguenti tipi di ruoli:
- Ruoli predefiniti, che hanno lo scopo di supportare casi d'uso comuni e modelli di controllo dell'accesso.
- Ruoli personalizzati, che forniscono un accesso granulare in base a un elenco di autorizzazioni specificato dall'utente.
In IAM, BigQuery fornisce un 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 vista. Puoi concedere a un utente l'accesso a tabelle o viste specifiche senza concedergli l'accesso al set di dati completo. Per un accesso più granulare, puoi anche valutare la possibilità di implementare uno o più dei seguenti meccanismi di sicurezza:
- Controllo dell'accesso a livello di colonna, che fornisce un accesso granulare alle colonne sensibili utilizzando i tag di criteri o la classificazione dei dati in base al tipo.
- Occultamento dei dati dinamici a livello di colonna, che consente di oscurare in modo selettivo i dati delle colonne per gruppi di utenti, mantenendo però l'accesso alla colonna.
- Sicurezza a livello di riga, che consente di filtrare i dati e di accedere a righe specifiche di una tabella in base a condizioni utente idonee.
Crittografia completa del disco
Oltre alla gestione delle identità e dell'accesso, la crittografia dei dati aggiunge un ulteriore livello di difesa per la loro protezione. In caso di esposizione dei dati, i dati criptati non sono leggibili.
In Amazon Redshift, la crittografia sia per i dati at-rest sia per i dati in transito non è attivata per impostazione predefinita. La crittografia dei dati at-rest deve essere abilitata esplicitamente quando viene lanciato un cluster o modificando un cluster esistente per utilizzare la crittografia di AWS Key Management Service. La crittografia dei dati in transito deve essere anche attivata esplicitamente.
BigQuery cripta tutti i dati at-rest e in transito per impostazione predefinita, indipendentemente dall'origine o da qualsiasi altra condizione e questa operazione 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.
I dati in transito su Google Cloud vengono criptati e autenticati quando si spostano al di fuori dei confini fisici controllati da Google o per conto di Google. All'interno di 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 scansionare le tabelle BigQuery al fine di 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
Consulta questa sezione per scoprire di più sull'utilizzo di strumenti e pipeline per supportare la migrazione.
Strumenti di migrazione
BigQuery Data Transfer Service fornisce uno strumento automatizzato per eseguire la migrazione sia dello schema sia dei dati da Amazon Redshift direttamente a BigQuery. La tabella seguente elenca altri strumenti utili per la migrazione da Amazon Redshift a BigQuery:
Strumento | Purpose |
---|---|
BigQuery Data Transfer Service | Esegui un trasferimento batch automatico dei dati di Amazon Redshift in BigQuery utilizzando questo servizio completamente gestito. |
Storage Transfer Service | Importa rapidamente i dati di Amazon S3 in Cloud Storage e configura un programma ripetuto per il trasferimento dei dati utilizzando questo servizio completamente gestito. |
gcloud |
Copia i file di 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 comuni includono la creazione di schemi di tabelle BigQuery, il caricamento dei dati di Cloud Storage nelle tabelle ed esecuzione di query. |
Librerie client di Cloud Storage | Copia i file di Amazon S3 in Cloud Storage utilizzando il tuo strumento personalizzato, sviluppato sulla base della libreria client di Cloud Storage. |
Librerie client di BigQuery | Interagisci con BigQuery utilizzando il tuo strumento personalizzato, creato sulla base della libreria client BigQuery. |
Programmatore delle query BigQuery | Pianifica query SQL ricorrenti utilizzando questa funzionalità di BigQuery integrata. |
Cloud Composer | Orchestra le trasformazioni e i job di caricamento di BigQuery utilizzando questo ambiente Apache Airflow completamente gestito. |
Apache Sqoop | Invia job Hadoop utilizzando Sqoop e il driver JDBC di Amazon Redshift per estrarre i dati da Amazon Redshift in HDFS o Cloud Storage. Sqoop viene eseguito in un ambiente Dataproc. |
Per saperne di più sull'utilizzo di BigQuery Data Transfer Service, consulta Eseguire la migrazione dello schema e dei dati da Amazon Redshift.
Migrazione mediante pipeline
La migrazione dei dati da Amazon Redshift a BigQuery può seguire percorsi diversi in base agli strumenti di migrazione disponibili. Sebbene l'elenco in questa sezione non sia esaustivo, fornisce un'idea dei diversi schemi di pipeline di dati disponibili per lo spostamento dei dati.
Per informazioni più generali sulla migrazione dei dati a BigQuery tramite le pipeline, consulta Eseguire la migrazione delle pipeline di dati.
Estrazione e caricamento (EL)
Puoi automatizzare completamente una pipeline EL utilizzando BigQuery Data Transfer Service, che può copiare automaticamente gli schemi e i dati delle tabelle dal cluster Amazon Redshift a BigQuery. Se vuoi un maggiore controllo sui passaggi della pipeline di dati, puoi creare una pipeline utilizzando le opzioni descritte nelle sezioni seguenti.
Utilizzare gli estratti di file di Amazon Redshift
- Esporta i dati di Amazon Redshift in Amazon S3.
Copia i dati da Amazon S3 a Cloud Storage utilizzando una delle seguenti opzioni:
- Storage Transfer Service (opzione consigliata)
- Interfaccia a riga di comando gcloud
- Librerie client di Cloud Storage
Carica i dati di Cloud Storage in BigQuery utilizzando 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:
-
- Modello fornito da Google: JDBC to BigQuery
-
Connettersi ad Amazon Redshift tramite JDBC utilizzando Apache Spark
Utilizza Sqoop e il driver JDBC di Amazon Redshift per estrarre i dati da Amazon Redshift in Cloud Storage
Estrazione, trasformazione e caricamento (ETL)
Se vuoi trasformare alcuni dati prima di caricarli in BigQuery, segui gli stessi consigli per le pipeline descritti nella sezione Estrazione e caricamento (EL), aggiungendo un passaggio aggiuntivo per trasformare i dati prima di caricarli in BigQuery.
Utilizzare gli estratti di file di Amazon Redshift
Copia i dati da Amazon S3 a Cloud Storage utilizzando una delle seguenti opzioni:
- Storage Transfer Service (opzione consigliata)
- Interfaccia a riga di comando gcloud
- Librerie client di Cloud Storage
Trasforma e carica i dati in BigQuery utilizzando una delle seguenti opzioni:
-
- Lettura da Cloud Storage
- Scrivere in BigQuery
- Modello fornito da Google: Testo Cloud Storage a BigQuery
Utilizzare una connessione JDBC di Amazon Redshift
Utilizza uno dei prodotti descritti nella sezione Estrazione e caricamento (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 scriverli in BigQuery.
-
- Clona il codice del modello JDBC to BigQuery e modificalo per aggiungere trasformazioni Apache Beam.
-
- Trasforma i dati utilizzando uno dei plug-in CDAP.
Estrazione, caricamento e trasformazione (ELT)
Puoi trasformare i dati utilizzando BigQuery stesso, tramite una delle opzioni Extract and Load (EL) per caricarli in una tabella intermedia. Trasformi quindi i dati in questa tabella intermedia utilizzando query SQL che scrivono l'output nella tabella di produzione finale.
Change Data Capture (CDC)
Il Change Data Capture è uno dei diversi pattern di progettazione software utilizzati per monitorare le modifiche ai dati. Viene spesso utilizzato nei data warehousing perché questi vengono utilizzati 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 nel settore dell'estrazione, trasformazione e caricamento (ETL). Consulta il sito web del partner BigQuery per un elenco dei partner chiave e delle soluzioni fornite.
Migrazione a Google Cloud: una panoramica dettagliata
Utilizza questa sezione per scoprire 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 massivamente 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 il modo in cui vengono archiviati i dati e per il modo in cui vengono eseguite le query. In BigQuery, l'hardware e le configurazioni sottostanti vengono astratti. L'archiviazione e il calcolo consentono al tuo data warehouse di crescere senza alcun intervento da parte tua.
Computing, memoria e spazio di archiviazione
In Amazon Redshift, la CPU, la memoria e lo spazio di archiviazione su disco sono collegati tramite nodi di calcolo, come illustrato in questo diagramma della documentazione di Amazon Redshift. Le prestazioni e la capacità di archiviazione del cluster sono determinate dal tipo e dalla quantità di nodi di calcolo, che devono entrambi essere configurati. Per modificare l'elaborazione o lo spazio di archiviazione, devi ridimensionare il cluster tramite una procedura (che può richiedere alcune ore o fino a due giorni o più) che crea un nuovo cluster e copia i dati. Amazon Redshift offre anche nodi RA3 con archiviazione gestita che consentono di separare l'elaborazione e l'archiviazione. Il nodo più grande della categoria RA3 ha un limite di 64 TB di archiviazione gestita per ogni nodo.
Fin dall'inizio, BigQuery non unisce calcolo, memoria e archiviazione, ma li tratta separatamente.
Il calcolo 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 la scelta della quantità corretta di slot per i carichi di lavoro BigQuery. Consulta la pianificazione della capacità per decidere quanti slot acquistare per il tuo 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.
BigQuery e Amazon Redshift utilizzano entrambi lo spazio di archiviazione a colonne, ma BigQuery utilizza variazioni e miglioramenti sullo spazio di archiviazione a colonne. Durante la codifica delle colonne, vengono conservate varie statistiche sui dati, che in seguito vengono utilizzate durante l'esecuzione delle query per compilare piani ottimali e scegliere l'algoritmo di runtime più efficiente. BigQuery archivia i 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 tue query. Separare lo spazio di archiviazione dal calcolo ti consente di scalare fino a decine di petabyte di spazio di archiviazione senza problemi, senza richiedere risorse di calcolo aggiuntive e costose. Esistono anche altri vantaggi della separazione di calcolo e archiviazione.
Scalata in alto o in basso
Quando lo spazio di archiviazione o le risorse di calcolo diventano limitati, i cluster Amazon Redshift devono essere ridimensionati modificando la quantità o i tipi di nodi nel cluster.
Quando regoli le dimensioni di un cluster Amazon Redshift, hai due approcci a tua disposizione:
- Ridimensionamento classico: Amazon Redshift crea un cluster in cui vengono copiati i dati, un processo che può richiedere un paio d'ore o anche due giorni o più per grandi quantità di dati.
- Ridimensionamento elastico: se modifichi solo il numero di nodi, le query vengono messe temporaneamente 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 piattaforma as a service (PaaS), devi solo preoccuparti del numero di slot BigQuery che vuoi prenotare per la tua organizzazione. Prenoti gli slot BigQuery nelle prenotazioni e poi assegni i progetti a queste prenotazioni. Per scoprire come configurare queste prenotazioni, consulta la sezione Pianificazione della capacità.
Esecuzione delle 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), eseguendoli (contemporaneamente, se possibile) e riassemblando i risultati. Amazon Redshift genera un piano di query statico, ma BigQuery no perché ottimizza dinamicamente i piani di query durante l'esecuzione della query. BigQuery mescola i dati utilizzando il proprio servizio di memoria remota, mentre Amazon Redshift li mescola utilizzando la memoria del nodo di calcolo locale. Per ulteriori informazioni sullo stoccaggio dei dati intermedi di BigQuery nelle varie fasi del piano di query, consulta Esecuzione in memoria delle query in Google BigQuery.
Gestione dei carichi di lavoro in BigQuery
BigQuery offre i seguenti controlli per la gestione del carico di lavoro (WLM):
- Query interattive, che vengono eseguite il prima possibile (questa è l'impostazione predefinita).
- Query batch, che vengono messe in coda per tuo conto e avviate non appena le risorse inattive sono disponibile nel pool di risorse condivise di BigQuery.
Prenotazioni di slot tramite prezzi basati sulla capacità. Invece di pagare per le query on demand, puoi creare e gestire dinamicamente bucket di slot chiamati reservations e assegnare progetti, cartelle o organizzazioni a queste prenotazioni. Puoi acquistare commitments sulla base di slot BigQuery (a partire da un minimo di 100) con impegni flessibili, mensili o annuali per contribuire a 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 seguente diagramma, supponiamo che tu abbia 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 a questa 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 i progetti collegati ai tuoi strumenti di BI a questa prenotazione.
Questa configurazione è mostrata nella seguente grafica:
Invece di distribuire le prenotazioni ai carichi di lavoro della tua organizzazione, ad esempio alla produzione e ai test, puoi scegliere di assegnare le prenotazioni a singoli team o reparti, a seconda del caso d'uso.
Per ulteriori informazioni, consulta Gestione dei carichi di lavoro utilizzando le prenotazioni.
Gestione del carico di lavoro in Amazon Redshift
Amazon Redshift offre due tipi di gestione del carico di lavoro (WLM):
- Automatica: con la gestione automatica della WLM, Amazon Redshift gestisce la concorrenza delle query e l'allocazione della memoria. Vengono create fino a otto code con gli identificatori della classe di servizio 100-107. La gestione automatica dei carichi di lavoro determina la quantità di risorse necessarie per le query e regola la concorrenza in base al carico di lavoro. Per ulteriori informazioni, consulta Priorità delle query.
- Manuale: al contrario, la gestione della concorrenza delle query manuale richiede di specificare valori per la concorrenza delle query e l'allocazione della memoria. Il valore predefinito per la gestione della concorrenza manuale è la concorrenza di cinque query e la memoria viene divisa equamente tra tutte e cinque.
Quando la scalabilità della concorrenza è attivata, Amazon Redshift aggiunge automaticamente la capacità del cluster aggiuntiva quando è necessaria per elaborare un aumento delle query di lettura simultanee. Lo scaling della concorrenza presenta alcune considerazioni regionali e relative alle query. Per ulteriori informazioni, consulta Candidati per la scalabilità della concorrenza.
Configurazioni di set di dati e tabelle
BigQuery offre diversi modi per configurare i dati e le tabelle, ad esempio la suddivisione in parti, il clustering e la localizzazione dei dati. Queste configurazioni possono aiutarti a gestire 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 dei dati.
Partizionamento
Una tabella partizionata è una tabella divisa in segmenti, denominati partizioni, che semplificano la gestione e l'interrogazione dei dati. In genere, gli utenti suddividono le tabelle di grandi dimensioni in molte partizioni più piccole, in cui ogni partizione contiene i dati di un giorno. La gestione delle partizioni è un fattore determinante per le prestazioni e i costi di BigQuery quando esegui query su un intervallo di date specifico, perché consente a BigQuery di analizzare meno dati per query.
In BigQuery esistono tre tipi di partizionamento delle tabelle:
- Tabelle partizionate per data di importazione: le tabelle vengono partizionate in base alla data di importazione dei dati.
- Tabelle partizionate per colonna:
le tabelle sono partizionate in base a una colonna
TIMESTAMP
oDATE
. - Tabelle partizionate per intervallo di numeri interi: le tabelle vengono partizionate in base a una colonna di tipo intero.
Una tabella partizionata in base al tempo e basata su colonne elimina la necessità di mantenere la conoscenza della partizione indipendente dal filtro dei dati esistente nella colonna vincolata. I datiscritti in una tabella basata su colonne e partizionata in base al tempo vengono inviati automaticamente alla partizione appropriata in base al valore dei dati. Analogamente, le query che esprimono filtri nella colonna di partizionamento possono ridurre i dati complessivamente scansionati, il che può migliorare le prestazioni e ridurre il 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 nello stesso nodo di calcolo, riducendo al minimo il data shuffling che si verifica durante le unioni e le aggregazioni. BigQuery separa l'archiviazione dal calcolo, quindi sfrutta la partizione basata su colonne per ridurre al minimo la quantità di dati che gli slot leggono dal disco.
Una volta che gli slot worker hanno letto i dati dal disco, BigQuery può determinare automaticamente un'ottimizzazione dello sharding dei dati e ripartire rapidamente i dati utilizzando il servizio di ordinamento in-memory di BigQuery.
Per ulteriori informazioni, consulta Introduzione alle tabelle partizionate.
Chiavi di clustering e ordinamento
Amazon Redshift supporta la specifica delle colonne della tabella come chiavi di ordinamento composte o intercalate. In BigQuery, puoi specificare chiavi di ordinamento composte aggregando la tabella. Le tabelle in cluster di BigQuery 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 vengono utilizzate per collocare vicini i dati correlati. L'ordine delle colonne di clustering specificate è importante perché determina l'ordinamento dei dati.
Il clustering può migliorare le prestazioni di determinati tipi di query, ad esempio quelle che usano clausole di filtro e quelle che aggregano dati. Quando i dati vengono scritti in una tabella in cluster da un job di query o di caricamento, BigQuery li ordina automaticamente utilizzando i valori delle colonne di clustering. Questi valori vengono utilizzati per organizzare i dati in più blocchi nello spazio di archiviazione BigQuery. Quando invii una query che contiene una clausola che filtra i dati in base alle colonne di clustering, BigQuery usa blocchi ordinati per evitare analisi dei dati non necessari.
Allo stesso modo, quando invii una query che aggrega i dati in base ai valori delle colonne di clustering, le prestazioni migliorano perché i blocchi ordinati avvicinano tra loro le righe con valori simili.
Utilizza il clustering nelle seguenti circostanze:
- Le chiavi di ordinamento composte sono configurate nelle tabelle Amazon Redshift.
- Il filtro o l'aggregazione viene configurato in base a colonne specifiche nelle tue query.
Quando usi insieme il clustering e il partizionamento, i dati possono essere partizionati per colonna di data, timestamp o numero intero e quindi raggruppati in cluster in un diverso insieme di colonne (fino a quattro colonne raggruppate in cluster). In questo caso, i dati in ciascuna partizione vengono raggruppati in cluster 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 caricamento di dati di grandi dimensioni. BigQuery
gestisce automaticamente
questo ordinamento e non utilizza gli slot BigQuery assegnati, pertanto non influisce sul rendimento di nessuna delle tue query.
Per ulteriori informazioni sull'utilizzo delle tabelle in cluster, consulta la sezione Introduzione alle tabelle in cluster.
Chiavi di distribuzione
Amazon Redshift utilizza le chiavi di distribuzione per ottimizzare la posizione dei blocchi di dati per eseguire le query. BigQuery non utilizza le chiavi di distribuzione perché determina e aggiunge automaticamente le fasi in un piano di query (durante l'esecuzione della query) per migliorare la distribuzione dei dati tra i worker di query.
Sorgenti esterne
Se utilizzi Amazon Redshift Spectrum per eseguire query sui dati su Amazon S3, puoi utilizzare in modo simile la funzionalità di 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 query direttamente dai seguenti prodotti:
- Cloud SQL (MySQL o PostgreSQL completamente gestiti)
- Bigtable (NoSQL completamente gestito)
- Google Drive (CSV, JSON, Avro, Fogli)
Località dei dati
Puoi creare i set di dati BigQuery in località sia regionali sia multiregionali, mentre Amazon Redshift offre solo località regionali. BigQuery determina la posizione in cui eseguire i job di caricamento, query o esportazione in base ai set di dati a cui si fa riferimento nella richiesta. Consulta le considerazioni sulla posizione di BigQuery per suggerimenti su come utilizzare i set di dati regionali e multiregionali.
Mappatura dei tipi di dati in BigQuery
I tipi di dati di Amazon Redshift sono diversi da quelli di BigQuery. Per maggiori dettagli sui tipi di dati di BigQuery, consulta la documentazione ufficiale.
BigQuery supporta anche i seguenti tipi di dati, che non hanno un diretto analogo di Amazon Redshift:
Confronto SQL
GoogleSQL supporta la conformità allo standard SQL 2011 e dispone di estensioni che supportano le query sui dati nidificati e ripetuti. Amazon Redshift SQL si basa su PostgreSQL, ma presenta diverse differenze descritte 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 di 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 in funzione di BigQuery, puoi scegliere di implementare tecniche per ottimizzare le prestazioni delle query in BigQuery. Per ulteriori informazioni, consulta Introduzione all'ottimizzazione del rendimento delle query.
Passaggi successivi
- Consulta le istruzioni dettagliate per eseguire la migrazione dello schema e dei dati da Amazon Redshift.
- Consulta le istruzioni dettagliate per eseguire la migrazione di Amazon Redshift a BigQuery con VPC.