Modellazione dimensionale ed ETL in Redshift

Ho studiato il database Redshift di Amazon come possibile rimpiazzo futuro per il nostro data warehouse. La mia esperienza è sempre stata nell'uso della modellazione dimensionale e dei metodi di Ralph Kimball, quindi è stato un po 'strano vedere che Redshift non supporta funzionalità come il tipo di dati seriale per le colonne a incremento automatico.

C'è, tuttavia, questo recente post sul blog AWS Big Data su come ottimizzare Redshift per uno schema a stella: https://blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas -e-Interleaved-Ordinamento-on-Amazon-Redshift

La domanda che ho è su quale sia la migliore pratica per caricare uno schema a stella in Redshift? Non riesco a trovare una risposta nella documentazione di Redshift.

Mi sto orientando verso l'importazione dei miei file da S3 in tabelle di gestione temporanea e quindi utilizzo SQL per eseguire trasformazioni come ricerche e generare chiavi surrogate prima di inserirle nelle tabelle di destinazione.

È quello che stanno facendo gli altri? Esiste uno strumento ETL che vale i soldi per renderlo più semplice?

Sei sicuramente sulla strada giusta con Kimball piuttosto che inmon per Redshift.

Ci sono un certo numero di modelli per questo, li ho usati tutti in diversi casi d'uso

1. Modello "ELT": carica le tabelle di origine per spostarle completamente in rosso, non eseguire trasformazioni significative fino a quando i dati non sono stati caricati. Per questo puoi caricare su s3, quindi utilizzare il comando redshift copy o ti consiglierei di utilizzare "AWS Data Migration Services", che può sincronizzare una sorgente (egmysql o postgres) con una destinazione (es. Redshift) Quindi, su base regolare i processi sql all'interno di redshift per popolare i dim, quindi i fatti. Puoi utilizzare strumenti basati su cloud di terze parti per "semplificare" questo processo, se lo desideri, come Matillion (non consiglio di utilizzare uno strumento di terze parti)
2. "Pattern ETL" - Trasforma i dati in volo, usando apache spark. e carica i dim e i fatti in redshift spark-> s3-> redshift. Ho usato EMR per questo che è buono. questo è anche l'approccio adottato se si utilizza AWS Glue
3. Non trasformare! - simile a 1) ma usa solo le tabelle che sono state caricate.

Si noti che Redshift a volte funziona MEGLIO se si dispone di una tabella ampia con valori ripetuti anziché un fatto e dimensioni. La ragione di ciò è che l'approccio colonnare consente a Redshift di comprimere i diversi valori fino a un livello abbastanza efficiente. Non ho una formula per quando usare molte dimensioni rispetto a un tavolo piano largo, l'unico modo è provarlo e vedere!

Alcuni link

AWS DMS per taret Redshift

AWS Glue

Per ETL c'è AWS Glue. È un servizio ETL gestito senza server che carica su Redshift (tra le altre cose).

https://aws.amazon.com/glue/

Attualmente sto affrontando un compito simile. Serve per costruire il processo ETL e progettare un modello dimensionale. Ho cercato molto il modo migliore per affrontarlo e ho trovato un'incredibile utile fonte di tecniche che dovremmo assolutamente applicare quando lavoriamo con MPP.

Per rispondere alla domanda

La domanda che ho è su quale sia la migliore pratica per caricare uno schema a stella in Redshift?

assicurati di dare un'occhiata a questa risorsa . Scommetto che lo troverai incredibilmente utile. È un documento di ~ 35 pagine con potenti tecniche per sfruttare l'uso dei negozi colonnari MPP. Supporta i commenti che vedi come

Si noti che Redshift a volte funziona MEGLIO se si dispone di una tabella ampia con valori ripetuti anziché un fatto e dimensioni. La ragione di ciò è che l'approccio colonnare consente a Redshift di comprimere i diversi valori fino a un livello abbastanza efficiente. Non ho una formula per quando usare molte dimensioni rispetto a un tavolo piano largo, l'unico modo è provarlo e vedere!

commento di Jon Scott

Spero che lo trovi utile come me

Penso che il caricamento da S3 sia un modello comune.

Avevamo bisogno di imporre vincoli di unicità, quindi abbiamo scelto di scrivere su Postgres e quindi replicare i nuovi dati per spostarli verso il rosso ogni 10 minuti.

Usiamo https://github.com/uswitch/blueshift per caricare in Redshift.

Poiché Redshift è un database colonnare, le prestazioni di archiviazione e query saranno diverse rispetto ai modelli RDBMS. Anche l'ottimizzazione per un database colonnare è diversa. Poiché di solito c'è meno I / O su disco e meno dati caricati dal disco, le query sono più veloci.

In termini di post di blog AWS a cui fai riferimento, presumo che tu abbia esaminato quei consigli e considerato quali opzioni funzionano meglio per i tuoi dati per distribuzione, chiavi, cursori, gestione del carico di lavoro, ecc. E hai almeno una buona idea dell'approccio tu useresti. Trovo più facile lavorare con una rappresentazione visiva, potresti considerare un diagramma DB veloce e sporco che mostra come le tue tabelle esistenti migrerebbero su Redshift. Coprendo quelli principali per avere un'idea di quanti dati stanno andando dove. E certamente utilizzerei i driver ODBC / JDBC di Amazon, il caricamento di grandi quantità di dati può essere comunque problematico, tanto meno il passaggio a un diverso tipo di DB.

Per quanto riguarda ETL / ELT, c'è AWS Glue come altri poster hanno menzionato. E sì, ci sono una serie di strumenti, alcuni dei quali sono gratuiti. Amazon ha una DB Best Practices Guide , che potrebbe aiutarti anche tu. Un suggerimento che ho visto in altri forum è caricare i tuoi dati il ​​più crudo possibile e fare le trasformazioni in Redshift. Ciò ti condurrebbe a un processo ELT. Con così tante opzioni, forse guardando un confronto tra i 2 metodi sarebbe di aiuto. Ecco un articolo del blog di Panopoly che spiega le differenze, potrebbe aiutarti a decidere su un percorso.

Amazon ha recentemente pubblicato alcune best practice per ETL in Redshift

https://aws.amazon.com/blogs/big-data/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/

In una presentazione su questo argomento Tony Gibbs, AWS Solution Architect consiglia il seguente schema per i carichi in stile UPSERT:

1. Carica dati CSV (da S3) nella tabella di gestione temporanea
2. Elimina le righe corrispondenti dalla tabella prd

3. Inserisci i dati dallo stage

   BEGIN;
   CREATE TEMP TABLE staging(LIKE …); — copies dist keys
   copy staging from ’s3://… COMPUTE OFF;
   DELETE deep_dive d
   USING staging s WHERE d.aid = s.aid;
   INSERT INTO deep_dive SELECT * FROM staging
   DROP table staging;
   COMMIT;

Se possibile, preferisci DROP TABLE o TRUNCATE a DELETE per evitare le file fantasma

Guarda un video dei suoi discorsi e delle diapositive .

Nel nostro team, in genere cariciamo i dati in Redshift direttamente da S3 utilizzando l' istruzione SQL COPY .

E gestisci tutto il nostro ETL utilizzando l'eccellente strumento Apache Airflow .

Utilizziamo anche servizi di integrazione come Stich che scrivono direttamente in Redshift, quindi CREATE TABLE LIKE e SELECT INTO per spostare i dati in un altro schema.