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 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 ad aiutarti a ripensare le pipeline di dati esistenti per ottenere il massimo da BigQuery.
  • Aiutarti a confrontare le architetture di BigQuery e Amazon Redshift in modo da poter determinare come implementare le caratteristiche e le funzionalità esistenti durante la migrazione. L'obiettivo è mostrarti le nuove funzionalità disponibili per la tua organizzazione tramite BigQuery, non mappare le singole funzionalità con Amazon Redshift.

Questo documento è destinato ad enterprise architect, amministratori di database, sviluppatori di applicazioni e specialisti della sicurezza informatica. Presuppone che tu abbia familiarità con Amazon Redshift.

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

Attività di pre-migrazione

Per garantire una migrazione del data warehouse senza problemi, inizia a pianificare la tua strategia di migrazione all'inizio della sequenza temporale del progetto. Questo approccio 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 necessaria per eseguire le query SQL. BigQuery calcola continuamente il numero di slot richiesti dalle query durante l'esecuzione, ma assegna gli slot alle query in base a un calendario equo.

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

  • Prezzi on demand: con i prezzi on demand, BigQuery addebita il numero di byte elaborati (dimensione 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 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 (minimo 100) invece di pagare per i byte elaborati dalle query che esegui. Consigliamo i prezzi basati sulla capacità per i carichi di lavoro di data warehouse aziendali, che di solito eseguono molte query di reporting in contemporanea ed estrazione di trasformazione del carico (ELT) 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 (ecco un esempio open source di una dashboard di Looker Studio) oppure 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 di quanti slot totali ha bisogno la tua organizzazione man mano che cresci su Google Cloud.

Ad esempio, supponi di prenotare inizialmente 4000 slot BigQuery per eseguire 100 query a 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, è possibile che siano necessari ulteriori slot BigQuery per supportare i 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 maggiori dettagli sulla gestione dei carichi di lavoro, l'esecuzione delle query e l'architettura di BigQuery, consulta Migrazione a Google Cloud: analisi approfondita.

Security in Google Cloud Platform

Le seguenti sezioni 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 dei criteri di autorizzazione dell'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 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 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 utente, un gruppo o un account di servizio. I ruoli di organizzazione e di progetto influiscono sulla capacità di eseguire job o gestire il progetto, mentre i ruoli dei set di dati influiscono sulla possibilità di accedere o modificare i dati all'interno di un progetto.

IAM fornisce i seguenti tipi di ruoli:

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

All'interno di IAM, BigQuery offre 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 concedergli l'accesso al set di dati completo. Per un accesso più granulare, puoi anche considerare l'implementazione di uno o più dei seguenti meccanismi di sicurezza:

Crittografia dell'intero disco

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

Su Amazon Redshift, la crittografia sia per i dati at-rest sia per i dati in transito non è abilitata per impostazione predefinita. La crittografia dei dati at-rest deve essere abilitata esplicitamente quando un cluster viene avviato o modificando un cluster esistente per utilizzare la crittografia di AWS Key Management Service. Anche la crittografia dei dati in transito deve essere abilitata esplicitamente.

BigQuery cripta tutti i dati at-rest e in transito per impostazione predefinita, indipendentemente dall'origine o da qualsiasi altra condizione, e questa opzione 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. 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 eseguire la scansione delle 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

Utilizza questa sezione per scoprire di più sull'utilizzo di strumenti e pipeline per 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 seguente tabella elenca ulteriori strumenti per facilitare la migrazione da Amazon Redshift a BigQuery:

Strumento Purpose
BigQuery Data Transfer Service Esegui un trasferimento batch automatizzato dei tuoi 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 una pianificazione ricorrente per il trasferimento dei dati utilizzando questo servizio completamente gestito.
gsutil Copia i file di Amazon S3 in Cloud Storage utilizzando questo strumento a riga di comando.
Strumento a riga di comando bq Utilizza questo strumento a riga di comando per interagire con BigQuery. Le interazioni comuni includono la creazione di schemi di tabelle BigQuery, il caricamento dei dati di Cloud Storage nelle tabelle e l'esecuzione di query.
Librerie client di Cloud Storage Copia i file di Amazon S3 in Cloud Storage utilizzando lo 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.
Strumento di pianificazione delle query BigQuery Pianifica query SQL ricorrenti utilizzando questa funzionalità integrata di BigQuery.
Cloud Composer Orchestra le trasformazioni e i job di caricamento BigQuery utilizzando questo ambiente Apache Airflow completamente gestito.
Apache Sqoop Invia job Hadoop utilizzando il driver JDBC di Sqoop e Amazon Redshift per estrarre i dati da Amazon Redshift in HDFS o 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 in base agli strumenti di migrazione disponibili. Sebbene l'elenco in questa sezione non sia esaustivo, fornisce un'idea dei diversi pattern di pipeline di dati disponibili durante lo spostamento dei dati.

Per informazioni più generali sulla migrazione dei dati a BigQuery utilizzando le pipeline, consulta Eseguire la 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 un maggiore controllo sui passaggi della pipeline dei dati, puoi crearne una utilizzando le opzioni descritte nelle sezioni seguenti.

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

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

  3. 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:

Estrazione, trasformazione e caricamento (ETL)

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

Utilizzare le estrazioni di file di Amazon Redshift

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

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

  3. Trasforma e carica i 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 in più per trasformare i dati prima del caricamento 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 stesso, utilizzando una qualsiasi delle opzioni Estrai e carica (EL) per caricare i dati in una tabella temporanea. Poi trasformerai i dati in questa tabella temporanea utilizzando query SQL che scrivono l'output nella tabella di produzione finale.

Change Data Capture (CDC)

L'acquisizione dei dati delle modifiche è uno dei vari pattern di progettazione del software utilizzati per tenere traccia delle modifiche ai dati. È 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

Nello spazio ETL (estrazione, trasformazione e caricamento), sono presenti diversi fornitori. Consulta il sito web dei partner BigQuery per un elenco dei partner principali e delle soluzioni fornite.

Migrazione a Google Cloud: analisi approfondita

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

Confronto dell'architettura

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

Computing, memoria e archiviazione

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

Fin dall'inizio BigQuery non lega computing, memoria e archiviazione, ma le tratta separatamente.

Il calcolo di BigQuery è definito dagli slot, un'unità di capacità di calcolo necessaria 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. Per decidere quanti slot acquistare per il tuo data warehouse, consulta la pianificazione della capacità. La memoria BigQuery è fornita da un servizio distribuito remoto, collegato a slot di calcolo dalla rete Petabit di Google, tutte gestite da Google.

BigQuery e Amazon Redshift utilizzano entrambi l'archiviazione a colonne, mentre BigQuery utilizza variazioni e progressi sull'archiviazione a colonne. Durante la codifica delle colonne, varie statistiche sui dati sono persistenti e, successivamente, vengono utilizzate durante l'esecuzione della query per compilare piani ottimali e per scegliere l'algoritmo di runtime più efficiente. BigQuery archivia i tuoi dati nel file system distribuito di Google, dove vengono automaticamente compressi, criptati, replicati e distribuiti. Tutto questo senza influire sulla potenza di calcolo disponibile per le query. Separando lo spazio di archiviazione dal calcolo, puoi fare lo scale up fino a decine di petabyte di spazio di archiviazione senza problemi, senza la necessità di costose risorse di calcolo aggiuntive. Esistono anche altri vantaggi della separazione di computing e archiviazione.

Scale up o scale down

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

Quando ridimensioni un cluster Amazon Redshift, puoi seguire due approcci:

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

Poiché BigQuery è una soluzione Platform as a Service (PaaS), devi solo preoccuparti del numero di slot BigQuery che vuoi prenotare per la tua organizzazione. Prenoti slot BigQuery nelle prenotazioni e poi assegni progetti a queste prenotazioni. Per scoprire 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), quindi riassemblando i risultati. Amazon Redshift genera un piano di query statico, al contrario di BigQuery perché ottimizza dinamicamente i piani di query durante l'esecuzione della query. BigQuery esegue lo shuffling dei dati utilizzando il suo servizio di memoria remoto, mentre Amazon Redshift esegue lo shuffling dei dati utilizzando la memoria locale dei nodi di computing. Per ulteriori informazioni sull'archiviazione di BigQuery per i dati intermedi provenienti da varie fasi del tuo 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 inserite nella coda per tuo conto, vengono avviate non appena le risorse inattive sono disponibili nel pool di risorse condiviso di BigQuery.

  • Prenotazioni 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 seguente diagramma, supponi 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 a quella prenotazione.
    • Puoi creare la prenotazione elt con 300 slot e assegnare a quella prenotazione i progetti utilizzati per i carichi di lavoro ELT.
    • Puoi creare la prenotazione bi con 200 slot e assegnare alla prenotazione i progetti collegati ai tuoi strumenti BI.

    Questa configurazione è mostrata nella seguente grafica:

    Come funzionano insieme impegni di slot, prenotazioni e assegnazioni.

    Anziché 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 maggiori informazioni, consulta Gestione del carico di lavoro mediante 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à e l'allocazione della memoria delle query. Vengono create fino a otto code con gli identificatori delle classi di servizio 100-107. Il modello WLM automatico determina la quantità di risorse necessarie alle query e regola la contemporaneità in base al carico di lavoro. Per ulteriori informazioni, consulta la sezione Priorità delle query.
  • Manuale: al contrario, il modello WLM manuale richiede di specificare valori per la contemporaneità e l'allocazione della memoria delle query. L'impostazione predefinita per il modello WLM manuale è la contemporaneità di cinque query e la memoria è divisa equamente tra tutte e cinque.

Quando è abilitata la scalabilità in tempo reale, Amazon Redshift aggiunge automaticamente ulteriore capacità per i cluster quando è necessaria per elaborare un aumento delle query di lettura in parallelo. La scalabilità della contemporaneità prevede alcune considerazioni a livello di regione e di query. Per maggiori informazioni, consulta Candidati per la scalabilità della contemporaneità.

Configurazioni di set di dati e tabelle

BigQuery offre diversi modi per configurare dati e tabelle, ad esempio partizionamento, clustering e località dei dati. Queste configurazioni possono aiutare a gestire tabelle di grandi dimensioni e a ridurre il carico complessivo dei dati e i tempi 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'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 giorno di dati. 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.

Esistono tre tipi di partizionamento delle tabelle in BigQuery:

Una tabella partizionata nel tempo basata su colonne elimina la necessità di mantenere la consapevolezza della partizione indipendentemente dal filtro dei dati esistenti nella colonna associata. I dati scritti in una tabella partizionata nel tempo e basata su colonne vengono inviati automaticamente alla partizione appropriata in base al valore dei dati. Allo stesso modo, le query che esprimono i filtri nella colonna di partizionamento possono ridurre il volume complessivo dei dati analizzati, con un conseguente miglioramento delle prestazioni e una riduzione dei costi 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 di chiavi basata su colonne per cercare di mantenere i dati correlati archiviati insieme nello stesso nodo di computing, riducendo al minimo lo data shuffling che si verifica durante join e aggregazioni. BigQuery separa l'archiviazione e l'elaborazione, quindi sfrutta il partizionamento basato su colonne per ridurre al minimo la quantità di dati che gli slot leggono dal disco.

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

Per ulteriori informazioni, consulta Introduzione alle tabelle partizionate.

Clustering 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 chiavi di ordinamento composte mediante il clustering della tabella. Le tabelle in cluster 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 i dati correlati. L'ordine delle colonne di clustering specificato è importante perché determina l'ordinamento dei dati.

Il clustering può migliorare le prestazioni di determinati tipi di query, come quelle 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 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 nello spazio di 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 collocano righe con valori simili.

Utilizza il clustering nelle seguenti circostanze:

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

Quando utilizzi il clustering e il partizionamento insieme, i dati possono essere partizionati in base a una colonna di data, timestamp o numero intero e poi raggruppati in un cluster diverso di colonne (fino a quattro colonne in cluster totali). In questo caso, i dati in ogni partizione vengono raggruppati 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 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 di grandi dimensioni. BigQuery gestisce automaticamente questo ordinamento per conto tuo e non utilizza gli slot BigQuery allocati, pertanto non influisce sulle prestazioni delle query.

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

Chiavi di distribuzione

Amazon Redshift utilizza le chiavi di distribuzione per ottimizzare la posizione dei blocchi di dati al fine di eseguire le query. BigQuery non utilizza le chiavi di distribuzione perché determina e aggiunge automaticamente 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 utilizzi Amazon Redshift Spectrum per eseguire query sui dati su Amazon S3, puoi utilizzare in modo simile la funzionalità delle origini dati esterne di BigQuery per eseguire query sui dati direttamente dai file in Cloud Storage.

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

Località dei dati

Puoi creare set di dati BigQuery in località a livello di una o più regioni, mentre Amazon Redshift offre solo località a livello di regione. 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. Fai riferimento alle considerazioni sulle località di BigQuery per suggerimenti su come lavorare con set di dati a livello di una o più regioni.

Mappatura dei tipi di dati in BigQuery

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

BigQuery supporta anche i seguenti tipi di dati, che non hanno un analogo 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 Redshift 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 SQL di Amazon Redshift.

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

Post-migrazione

Poiché hai eseguito la migrazione degli 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