Database
 sql >> Database >  >> RDS >> Database

ETL vs ELT:Noi postuliamo, tu giudichi

Divulgazione completa:poiché questo articolo è stato scritto da un'azienda incentrata su ETL con il suo punto di forza nella manipolazione di big data al di fuori dei database, ciò che segue non sembrerà obiettivo a molti. Ciononostante ha lo scopo di presentare spunti di riflessione e apre la parola alla discussione.

Sin dall'inizio, i data warehouse architect (DWA) hanno avuto il compito di creare e popolare un data warehouse con dati formattati e di provenienza eterogenea. A causa della notevole crescita dei volumi di dati, queste stesse DWA devono implementare l'integrazione dei dati e le operazioni di staging in modo più efficiente. La questione se la trasformazione dei dati avverrà all'interno o all'esterno del database di destinazione è diventata critica a causa delle prestazioni, della convenienza e delle conseguenze finanziarie coinvolte.

Nelle operazioni ETL (estrai, trasforma, carica), i dati vengono estratti da diverse origini, trasformati separatamente e caricati in un database DW e possibilmente in altre destinazioni. In ELT, gli estratti vengono inseriti nel database di staging unico che gestisce anche le trasformazioni.

L'ETL rimane prevalente perché il mercato prospera con attori affermati come Informatica, IBM, Oracle e IRI con Voracity, che combina le trasformazioni FACT (Fast Extract), CoSort o Hadoop e il caricamento in blocco nella stessa GUI di Eclipse - per estrarre e trasformare i dati. Questo approccio evita di sovraccaricare i database progettati per l'archiviazione e il recupero (ottimizzazione delle query) con il sovraccarico della trasformazione dei dati su larga scala.

Tuttavia, con lo sviluppo di nuove tecnologie di database e dispositivi hardware come Oracle Exadata in grado di gestire le trasformazioni "in una scatola", ELT potrebbe essere una soluzione pratica in determinate circostanze. E ci sono vantaggi specifici nell'isolare i livelli di staging (carico) e semantico (trasformare).

Un vantaggio citato di ELT è l'isolamento del processo di carico dal processo di trasformazione, poiché rimuove una dipendenza intrinseca tra queste fasi.

Notiamo che l'approccio ETL di IRI li isola comunque perché Voracity mette in scena i dati nel file system (o HDFS). Qualsiasi blocco di dati associato al database può essere acquisito, ripulito e trasformato esternamente prima di un caricamento (preordinato). Ciò elimina il peso delle trasformazioni su larga scala dal database (così come strumenti BI/analitici, ecc.).

I volumi di dati e i budget sono spesso ciò che determina se un DWA deve sviluppare una soluzione ETL o ELT. Nel suo articolo sul blog di ITToolbox "So What Is Better, ETL or ELT?", Vincent McBurney espone i suoi pro e contro per entrambi gli approcci, che ho ripetuto qui sotto, e poi li ha seguiti con una tipica risposta che IRI ETL gli utenti orientati fanno sul punto  (secondo il mio avvertimento iniziale sulla soggettività):

Pro ETL
  • ETL può bilanciare il carico di lavoro e condividere il carico di lavoro con l'RDBMS – e di fatto rimuovere quel carico di lavoro trasformando i dati tramite il programma SortCL o Hadoop senza codificare in Voracity
  • ETL può eseguire operazioni più complesse in singoli diagrammi di flusso di dati tramite mappe di dati, come con la mappatura Voracity e i diagrammi di flusso di lavoro che astraggono anche brevi, aperti  Script 4GL e SQL
  • ETL può essere scalato con hardware separato:su scatole di prodotti puoi rifornirti e mantenerti a costi molto inferiori rispetto alle apparecchiature di un singolo fornitore
  • ETL può gestire il partizionamento e il parallelismo indipendentemente dal modello di dati, dal layout del database e dall'architettura del modello di dati di origine  – sebbene i lavori CoSort SortCL di Voracity non è necessario partizionare affatto...
  • ETL può elaborare i dati in-stream, poiché li trasferisce dall'origine alla destinazione – o anche in batch se ha senso
  • ETL non richiede la co-localizzazione dei set di dati per svolgere il proprio lavoro, consentendoti di mantenere le piattaforme di origine dati esistenti senza problemi di sincronizzazione dei dati
  • L'ETL acquisisce enormi quantità di lignaggio di metadati oggi- in che modo un DB di staging può farlo in modo intuitivo o efficace?
  • ETL può essere eseguito su hardware SMP o MPP, che, ancora una volta, puoi gestire e sfruttare in modo più conveniente, senza preoccuparti di conflitti di prestazioni con il DB
  • ETL elabora le informazioni riga per riga e sembra funzionare bene con l'integrazione dei dati in prodotti di terze parti – meglio ancora,  blocco completo, tabella o file alla volta, che Voracity esegue in volume.
Contro ETL
  • È necessario un ulteriore investimento hardware per i motori ETL, a meno che non lo si esegua sui server di database
  • Costo aggiuntivo per la creazione di un sistema ETL o la licenza di strumenti ETL – che sono ancora più economici rispetto alle appliance ELT, ma sono ancora più economici strumenti IRI come Voracity che combinano Fast Extract (FACT) e CoSort per velocizzare ETL senza tale complessità
  • Possibile riduzione delle prestazioni dell'approccio basato su righe – giusto, e perché la capacità di Voracity di profilare, acquisire, trasformare e generare dati in blocchi più grandi è più veloce
  • Competenze specializzate e curva di apprendimento necessarie per implementare lo strumento ETL –  a meno che tu non stia utilizzando una GUI ergonomica come quella di Voracity che fornisce più opzioni di progettazione del lavoro nello stesso IDE Eclipse
  • Ridotta flessibilità dovuta alla dipendenza dal fornitore di strumenti ETL – Non sono sicuro di come sia migliorata affidandosi invece a un singolo fornitore di ELT/appliance; l'indipendenza dal fornitore non è la chiave per la flessibilità e il risparmio sui costi?
  • I dati devono attraversare un altro livello prima di atterrare nel data mart, a meno che il mart non sia solo un altro output del processo ETL, tipico delle operazioni Voracity multi-target.
Pro ELT
  • ELT sfrutta l'hardware del motore RDBMS per la scalabilità, ma tassa anche le risorse DB destinate all'ottimizzazione delle query. Le trasformazioni CoSort e Hadoop in Voracity sfruttano algoritmi di ridimensionamento lineare e consolidamento delle attività, non la memoria o le risorse I/O del DB
  • ELT conserva sempre tutti i dati nell'RDBMS, il che va bene purché i dati di origine e di destinazione si trovino nello stesso DB
  • L'ELT è parallelizzato in base al set di dati e l'I/O del disco è generalmente ottimizzato a livello di motore per un throughput più rapido – sì, ma è ancora più vero per le trasformazioni esterne che non sono in conflitto con le risorse del server DB 
  • ELT è scalabile fintanto che l'hardware e il motore RDBMS possono continuare a scalare:quale costa quanto rispetto all'alternativa sopra?
  • ELT può raggiungere velocità di trasmissione da 3 a 4 volte superiori sulla piattaforma MPP RDBMS opportunamente sintonizzata, il che pone l'appliance a livelli di prestazioni Voracity rispetto agli strumenti ETL, ma a un costo 20 volte superiore.
  • La trasformazione ELT viene eseguita sul server RDBMS una volta che il database si trova sulla piattaforma di destinazione e non pone più stress sulla rete  – quindi mette invece lo stress sul database (utenti)?
  • ELT ha semplici specifiche di trasformazione tramite SQL – che non sono così semplici, flessibili o ricche di funzionalità come la sintassi CoSort SortCL o la mappatura dei campi drag-and-drop nella GUI Eclipse di Voracity.
Contro ELT
  • Strumenti disponibili in numero limitato con supporto completo per ELT – ea prezzi molto elevati per appliance DB che promuovono prestazioni ad alto volume
  • Perdita di statistiche dettagliate di monitoraggio in fase di esecuzione e derivazione dei dati: in particolare le analisi dell'impatto dei metadati sulle modifiche a file, tabelle o origini non strutturate disparate
  • Perdita di modularità dovuta alla progettazione basata sul set per le prestazioni – e alla perdita di funzionalità/flessibilità che ne deriva
  • Le trasformazioni utilizzerebbe le risorse del database, con un potenziale impatto sulle prestazioni dei report BI, per non parlare delle prestazioni delle query e di altre operazioni del database

Architetture ibride come ETLT, TELT e persino TETLT stanno successivamente emergendo nel tentativo di rafforzare i punti deboli in entrambi gli approcci. Ma questi sembrano aggiungere ulteriori livelli di complessità a processi già così pesanti. Non c'è davvero nessun proiettile d'argento e molti progetti di integrazione dei dati falliscono sotto il peso di SLA, superamento dei costi e complessità.

È per questi motivi che IRI ha creato Voracity per integrare i dati tramite il programma CoSort SortCL nei file system esistenti o nei fabric Hadoop senza ricodificare. Voracity è l'unica piattaforma orientata a ETL (sebbene anche a supporto di ELT) che offre entrambe le opzioni per trasformazioni di dati esterne. Oltre a un rapporto prezzo/prestazioni superiore nella movimentazione e manipolazione dei dati, Voracity include:

  • trasformazione avanzata dei dati, qualità dei dati, MDM e reportistica
  • dimensioni che cambiano lentamente, modifica dell'acquisizione dei dati, federazione dei dati
  • Profilazione dei dati, mascheramento dei dati, generazione dei dati di test e gestione dei metadati
  • semplici script 4GL creati e gestiti da te o da procedure guidate, diagrammi e finestre di dialogo di Eclipse
  • esecuzione perfetta in Hadoop MR2, Spark, Spart Stream Storm e Tez
  • supporto per erwin Smart Connectors (conversione da altri strumenti ETL)
  • driver MongoDB nativi e connessioni ad altre origini NoSQL, Hadoop, cloud e legacy
  • Rapporti integrati, statistiche e funzioni predittive, collegamenti KNIME e Splunk e feed di dati dello strumento analitico.

Vedi anche:

  • http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
  • http://www.iri.com/solutions/data-integration/etl
  • http://www.iri.com/solutions/data-integration/elt
  • http://www.iri.com/solutions/data-integration/implement