Mi sono reso conto che la mia azienda utilizza un processo ELT (extract-load-transform) invece di utilizzare un processo ETL (extract-transform-load).
Quali sono le differenze tra i due approcci e in quali situazioni uno sarebbe "migliore" dell'altro? Sarebbe bello se potessi fornire alcuni esempi.
Risposte:
molte discussioni su ETL vs ELT là fuori.
La differenza principale tra ETL vs ELT è dove l'elaborazione avviene L' elaborazione ETL dei dati avviene nello strumento ETL (di solito record alla volta e in memoria) L'elaborazione ELT dei dati avviene nel motore di database
I dati sono gli stessi e i risultati finali dei dati possono essere raggiunti in entrambi i metodi.
dipende molto da te e dal tuo ambiente Se disponi di un potente motore di database e di un buon hardware e puoi eseguire elaborazioni pesanti su di esso, ELT fa bene a te, se hai un motore di datawarehouse occupato e devi liberarlo dall'elaborazione vai per ETL.
nota che avere uno strumento ETL ti offre entrambe le opzioni, come ETL (T), puoi fare la trasformazione nello strumento ETL e puoi anche fare la trasformazione nel motore di database
ma ELT hai solo l'opzione di trasformazione nel motore di database, ma dovresti sapere che i database sono migliori nelle operazioni basate su set rispetto agli strumenti ETL record alla volta.
domanda simile chiesto il SO , ma di supporto ETL e anche un bel articolo confrontando ETL vs ELT, ma favorendo ELT
È quasi una questione di semantica. Molta aria calda viene rilasciata nelle discussioni su questo, ma non sono davvero convinto che ci sia una vera profondità filosofica in una distinzione tra i due.
Ad un certo livello è possibile visualizzare ETL come trasformazione dei dati in uno strumento lato client prima di caricarlo definitivamente, con ELT che implica che i dati vengono trasferiti in una sorta di area di gestione temporanea con modifiche relativamente ridotte al formato. La "trasformazione" ha luogo dopo.
Queste sono definizioni molto morbide e potrebbero essere applicate a un'ampia varietà di architetture tecniche, e ci sono molti possibili progetti che entrambi i termini potrebbero essere usati per descrivere.
Sono fortemente a favore di un'architettura in cui tutta la trasformazione e la logica aziendale possano essere integrate in una base di codice più o meno omogenea e ho realizzato molti sistemi in cui la logica di trasformazione era piuttosto complessa. Ciò tendeva a utilizzare semplicemente lo strumento ETL per atterrare i dati e quindi tutta la trasformazione veniva eseguita in stored procedure. Probabilmente questo potrebbe essere descritto come ETL o ELT con la differenza che è semplicemente una semantica.
Alcuni strumenti sono molto incentrati sul database (Oracle Data Integrator, ad esempio, viene spesso definito strumento ELT). Se ti iscrivi a questa vista, allora 'Estrai' e 'Carica' stanno accadendo prima che i dati vengano trasformati mentre vengono sbarcati in un'area di gestione temporanea e quindi scricchiolati dal codice SQL o PL / SQL (che può essere generato dallo strumento o scritto a mano). Diverse persone con cui ho parlato sembrano considerare il merito principale di ODI in quanto non è OWB.
Se si utilizza uno strumento lato client come Informatica Powercentre o MS SQL Server Integration Services, lo strumento può effettuare una trasformazione estesa sul lato client dei dati. Alcuni strumenti ETL, come Ascential Datastage e Ab Initio, sono progettati per fare molto lavoro con file flat e strutture di dati in memoria per la velocità. In questo tipo di architettura la trasformazione è già stata eseguita prima del caricamento. Forse questo tipo di architettura potrebbe essere sicuramente classificato come "ETL", anche se ho visto molti progetti incentrati su strumenti in cui tutto il lavoro reale è svolto da un gruppo di codici di stored procedure.
Ci sono vantaggi per vari strumenti e approcci architetturali, ma non si può fare una dichiarazione generale sui meriti degli approcci "ETL" vs "ELT" perché i termini sono così ampi che la differenza è quasi insignificante. Alcuni strumenti e architetture possono presentare vantaggi specifici: ad esempio, l'uso intensivo di file flat da parte di Ab Initio offre un notevole vantaggio in termini di prestazioni su grandi volumi di dati.
In pratica, distinguere tra "ETL" ed "ELT" è piuttosto insignificante senza entrare in una discussione molto più approfondita sui requisiti di sistema, sulla piattaforma e sull'architettura tecnica.
È anche una questione di soldi. Laddove i volumi di dati sono elevati, come indicato, le soluzioni basate su file flat come Ab Initio e DataStage Parallel Extender sono effettivamente più veloci, ma possono essere proposizioni a sei cifre medio-alte. IRI CoSort è molto incentrato su ETL (secondo il loro confronto ELT) e l'unico modo conveniente che ho visto per affrontare il volume di trasformazione con la velocità del file system, a parte una complessa implementazione di Hadoop. Penso anche che lanciare l'hardware al problema in generale (cosa che fanno anche le appliance ELT e i DB in memoria), non si adatta neanche ai costi.