Migrazione da Amazon Redshift a BigQuery: panoramica
Questo documento fornisce indicazioni sulla migrazione da Amazon Redshift ad BigQuery, con particolare attenzione ai 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:
- Fornisci indicazioni generali alle organizzazioni che migrano da da Amazon Redshift a BigQuery, aiutandoti a ripensare i dati esistenti per sfruttare al meglio 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. it presuppone che tu abbia familiarità 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. SQL di Amazon Redshift è completamente supportato Servizi di traduzione SQL.
Attività preliminari alla migrazione
Per contribuire a garantire una migrazione del data warehouse di successo, inizia a pianificare la strategia di migrazione nelle prime fasi della sequenza temporale del progetto. Questo approccio ti consente 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 è l'unità 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 il 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 eseguire burst oltre questo limite per accelerare le query, ma il bursting non è garantito.
- Prezzi basati sulla capacità: Con i prezzi basati sulla capacità, acquisti slot BigQuery prenotazioni (un minimo di 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 di reporting ed estrazione, trasformazione del carico e trasformazione (ELT) con previsioni il consumo eccessivo.
Per facilitare la stima degli slot, ti consigliamo di configurare Monitoraggio di BigQuery con 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 il sistema di BigQuery dati delle tabelle per monitorare l'utilizzo degli slot tra job e prenotazioni (ecco 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 inizialmente prenoti 4000 BigQuery slot per eseguire 100 query a complessità media contemporaneamente. Se noti tempi di attesa elevati nelle query piani di esecuzione, e le tue dashboard mostrano un elevato utilizzo degli slot, il che potrebbe indicare hanno bisogno di altri Slot BigQuery per aiutarti 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 comporta la scrittura di Amazon Redshift Criteri relativi alle autorizzazioni API e come collegarli ai Identità Identity and Access Management (IAM). Le autorizzazioni dell'API Amazon Redshift forniscono l'accesso a livello di cluster, ma fornire 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 utilizza IAM per gestire l'accesso alle risorse a un livello più dettagliato. 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 elementi project. 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 di organizzazione e progetto influiscono sulla capacità 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, 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.
All'interno di IAM, BigQuery fornisce 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 senza concedere all'utente 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 usando i tag di criteri, o la classificazione dei dati basata sul tipo.
- Mascheramento dei dati dinamici a livello di colonna, che ti consente di oscurare selettivamente i dati delle colonne per gruppi di utenti, consentendo comunque l'accesso alla colonna.
- Sicurezza a livello di riga che ti consente di filtrare i dati e di accedere a righe specifiche di una tabella. in base a condizioni di utilizzo idonee.
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, 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 a riposo e in transito per impostazione predefinita, indipendentemente dall'origine o da qualsiasi altra condizione e non può essere disattivata. BigQuery supporta anche chiavi di crittografia gestite dal cliente (CMEK) se vuoi controllare e gestire le chiavi di crittografia delle chiavi 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 su cui è possibile archiviare in Google Cloud. Puoi utilizzare Sensitive Data Protection per eseguire la scansione delle tabelle BigQuery per 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 la migrazione sia schema che dati direttamente da Amazon Redshift a BigQuery. La tabella seguente elenca strumenti aggiuntivi 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 Amazon S3 in Cloud Storage utilizzando questa riga di comando lo strumento a riga di comando gcloud. |
Strumento a riga di comando bq | Interagisci con BigQuery utilizzando questo strumento a riga di comando. Comuni le interazioni includono la creazione di schemi delle tabelle BigQuery, il caricamento i dati di Cloud Storage in tabelle ed esecuzione di query. |
Client Cloud Storage biblioteche | 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 di BigQuery. |
Pianificazione query BigQuery | Pianifica query SQL ricorrenti utilizzando questa funzionalità di BigQuery integrata. |
Cloud Composer | Orchestra le trasformazioni e i job di caricamento BigQuery utilizzando questo un 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 tramite pipeline
La migrazione dei dati da Amazon Redshift a BigQuery può richiedere 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 mediante l'utilizzo di 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 crearne una utilizzando le opzioni descritte nelle sezioni seguenti.
Utilizzare gli estratti di file Amazon Redshift
- Esporta i dati di Amazon Redshift in Amazon S3.
Copia i dati da Amazon S3 a Cloud Storage utilizzando uno dei seguenti metodi opzioni:
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
-
Connettiti 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
Estrai, trasforma e carica (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 Amazon Redshift
Copia i dati da Amazon S3 a Cloud Storage utilizzando uno dei seguenti metodi opzioni:
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
Utilizzare uno dei prodotti descritti nella sezione Estrazione e Carica la sezione (EL), aggiungendo un passaggio in più alla 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 poi 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 warehouse 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 nello spazio ETL (Extract, Transform, Load). Consulta le Sito web partner BigQuery per un elenco dei partner principali con le soluzioni fornite.
Migrazione a Google Cloud: una panoramica dettagliata
Utilizza questa sezione per scoprire di più su come l'architettura del tuo data warehouse, e il dialetto SQL influisce sulla migrazione.
Confronto dell'architettura
Sia BigQuery che Amazon Redshift si basano su un'enorme elaborazione parallela dell'architettura (MPP). Le query vengono distribuite su più server accelerarne l'esecuzione. Per quanto riguarda l'architettura di sistema, Amazon Redshift e BigQuery differiscono principalmente nella modalità di archiviazione dei dati come sono le query eseguito. In BigQuery, l'hardware sottostante configurazioni sono astratte away; e risorse di archiviazione e computing consentono al tuo data warehouse di crescere senza un tuo intervento.
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. Prestazioni del cluster e capacità di archiviazione sono determinati dal tipo e dalla quantità di nodi di computing, che devono la configurazione iniziale. Per modificare le opzioni di elaborazione o archiviazione, devi ridimensionare il cluster Attraverso un processo (più di un paio d'ore oppure fino a due giorni o più) che crea un cluster e delle copie nuovi di zecca trasferire i dati. Amazon Redshift offre inoltre nodi RA3 con archiviazione gestita risorse di computing e archiviazione separate. Il nodo più grande della categoria RA3 ha un limite di 64 TB di archiviazione gestita per ciascun nodo.
Fin dall'inizio, BigQuery non unisce calcolo, memoria e archiviazione, ma li tratta separatamente.
Il computing di BigQuery è definito slot, un'unità di capacità di calcolo richiesta per eseguire le query. Google gestisce l'intera infrastruttura incapsulata da uno slot, eliminando tutto tranne l'attività scegliendo la quantità di slot appropriata 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, collegati agli slot di calcolo della 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, diverse statistiche su i dati persistenti e in seguito vengono utilizzati durante l'esecuzione della 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. Tutto questo 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.
Scale up o scale down
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 modifichi le dimensioni di un cluster Amazon Redshift, hai due opzioni:
- 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, la query sono 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 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), 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 esegue lo shuffling dei dati usando il proprio servizio di memoria remoto, mentre Amazon Redshift esegue lo shuffling dei dati utilizzando di memoria locale dei nodi di computing. Per ulteriori informazioni sullo spazio di archiviazione di dati intermedi provenienti dalle 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 (questa è l'impostazione predefinita).
- Query in batch, che vengono messi in coda per tuo conto, vengono avviate non appena le risorse inattive disponibili nel pool di risorse condiviso di BigQuery.
Prenotazioni di slot tramite prezzi basati sulla capacità. Anziché pagare per le query on demand, puoi crea e gestisci dinamicamente di slot chiamati prenotazioni e assegna di progetti, cartelle o organizzazioni a queste prenotazioni. Puoi acquistare slot BigQuery impegni (a partire da un minimo di 100) nel formato flessibile, mensile o annuale 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 che tu abbia acquistato una capacità di impegno totale 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 nell'immagine seguente:
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 dei carichi di lavoro in Amazon Redshift
Amazon Redshift offre due tipi di gestione del carico di lavoro (WLM):
- Automatico: Con WLM automatico, Amazon Redshift gestisce la contemporaneità e la memoria delle query l'allocazione delle risorse. 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, vedi Priorità delle query.
- Manuale: Al contrario, WLM manuale richiede di specificare i valori per la query contemporaneità e allocazione della memoria. L'impostazione predefinita per il WLM manuale è e la contemporaneità è di cinque query e la memoria è divisa equamente tra tutte e cinque.
Quando scalabilità della contemporaneità è abilitata, Amazon Redshift aggiunge automaticamente ulteriore capacità al cluster ne hai bisogno per elaborare un aumento delle query di lettura simultanee. Contemporaneità la scalabilità richiede alcune considerazioni a livello di regione e di 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: partizionamento, clustering e località dei dati. Queste configurazioni possono aiutare a mantenere e riducono il carico complessivo dei dati e il tempo di risposta per le query, aumentando così il dell'efficienza operativa dei carichi di lavoro di dati.
Partizionamento
Una tabella partizionata è una tabella divisa in segmenti, chiamati che semplificano la gestione e l'esecuzione di query sui dati. Gli utenti in genere suddividono le tabelle di grandi dimensioni in molte partizioni più piccole, dove ogni partizione contiene un per un totale di giorni. La gestione delle partizioni è una determinante chiave di BigQuery di prestazioni e costo quando si eseguono query in un intervallo di date specifico, BigQuery analizza 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 nel tempo, basata su colonne, evita la necessità di mantenere la partizione di rilevamento indipendente dal filtro dati esistente nella colonna del vincolo. 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 delle chiavi basate su colonne per cercare di mantenere i dati correlati archiviati insieme lo stesso nodo di computing, riducendo al minimo data shuffling che si verifica join e aggregazioni. BigQuery separa l'archiviazione dal computing, quindi sfrutta il partizionamento in base a colonne per ridurre al minimo la quantità di dati slot 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, vedi Introduzione alle tabelle partizionate.
Chiavi di clustering e ordinamento
Amazon Redshift supporta la specifica di colonne delle tabelle come composto o con interleaving di ordinamento. In BigQuery, puoi specificare chiavi di ordinamento composte aggregando la tabella. Le tabelle BigQuery in cluster migliorano le prestazioni delle query perché i dati di una tabella vengono ordinati automaticamente in base ai contenuti di un massimo di quattro colonne specificato nello schema della tabella. Queste colonne vengono utilizzate per posizionare e i dati di Google Cloud. 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, come che usano clausole di filtro e query 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 vengono utilizzati per organizzare i dati in più blocchi nello spazio di archiviazione di BigQuery. Quando invii una query contenente una clausola che filtra i dati in base a al clustering delle colonne, BigQuery utilizza i blocchi ordinati per eliminare le analisi i 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.
- I filtri o l'aggregazione sono configurati in base a determinate colonne in le 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 ogni di clustering viene organizzato in base ai valori delle colonne di clustering.
Quando specifichi le chiavi di ordinamento nelle tabelle in Amazon Redshift, a seconda del carico
sul sistema, Amazon Redshift avvia automaticamente l'ordinamento utilizzando
e la capacità di calcolo del cluster. Potresti anche dover eseguire manualmente
VACUUM
se vuoi ordinare completamente i dati della tabella il prima possibile, ad esempio
ad esempio dopo un grande carico di dati. 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 Spettro Amazon Redshift per eseguire query sui dati su Amazon S3, puoi utilizzare allo stesso modo un'origine dati esterna dati e query 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:
- Cloud SQL (MySQL o PostgreSQL completamente gestito)
- Bigtable (NoSQL completamente gestito)
- Google Drive (CSV, JSON, Avro, Fogli)
Località dei dati
Puoi creare i tuoi set di dati BigQuery sia in regioni singole che in più regioni mentre Amazon Redshift offre solo località regionali. BigQuery determina la posizione in cui eseguire i job di caricamento, query o esportazione in base alla ai set di dati a cui viene fatto 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 indirizzo Analogico Amazon Redshift:
Confronto SQL
GoogleSQL supporta la conformità allo standard SQL 2011 e include estensioni che supportano eseguire query su 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 di Amazon Redshift e GoogleSQL e 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 in funzione di BigQuery, puoi scegliere di implementare tecniche per ottimizzare le prestazioni delle query in BigQuery. Per ulteriori informazioni, vedi Introduzione all'ottimizzazione delle prestazioni 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.