Uświadomiłem sobie, że moja firma stosuje proces ELT (ekstrakcja-transformacja-ładowanie) zamiast ETL (ekstrakcja-transformacja-ładowanie).
Jakie są różnice między tymi dwoma podejściami i w jakich sytuacjach jedno byłoby „lepsze” od drugiego? Byłoby wspaniale, gdybyś mógł podać kilka przykładów.
Odpowiedzi:
wiele dyskusji na temat ETL vs ELT.
Główna różnica między ETL a ELT polega na tym, że przetwarzanie odbywa się ETL przetwarzanie danych odbywa się w narzędziu ETL (zwykle rejestruje się je w pamięci i w pamięci) Przetwarzanie danych ELT odbywa się w silniku bazy danych
Dane są takie same, a końcowe wyniki danych można osiągnąć w obu metodach.
to bardzo zależy od ciebie i twojego środowiska Jeśli masz silny silnik bazy danych i dobry sprzęt i możesz wykonać na nim ciężkie przetwarzanie, ELT jest dla ciebie dobry, jeśli masz zajęty silnik bazy danych i musisz go zwolnić z przetwarzania, przejdź do dla ETL.
zauważ, że posiadanie narzędzia ETL daje obie opcje, takie jak ETL (T), możesz wykonać transformację w narzędziu ETL, a także możesz przeprowadzić transformację w silniku bazy danych
ale ELT masz tylko opcję transformacji w silniku bazy danych, ale powinieneś wiedzieć, że bazy danych są lepsze w operacjach opartych na zestawach niż narzędzia ETL do nagrywania na raz.
podobne pytanie zadane na temat SO, ale wspierające ETL, a także ładny artykuł porównujący ETL vs ELT, ale faworyzujący ELT
To prawie kwestia semantyki. Dużo gorącego powietrza uwalnia się w dyskusjach na ten temat, ale tak naprawdę nie jestem przekonany, że istnieje jakakolwiek głęboka filozoficzna różnica między tymi dwoma.
Na pewnym poziomie możesz zobaczyć ETL jako transformację danych w narzędziu po stronie klienta przed ostatecznym załadowaniem, przy czym ELT oznacza, że dane są przenoszone do pewnego rodzaju obszaru pomostowego przy stosunkowo niewielkiej zmianie formatu. Następnie następuje „transformacja”.
Są to bardzo puszyste definicje, które można zastosować w wielu różnych architekturach technicznych. Istnieje wiele możliwych projektów, które można by opisać w każdym z tych terminów.
Jestem zdecydowanie zwolennikiem architektury, w której cała logika transformacji i biznesowa może zostać wbudowana w mniej lub bardziej jednorodną bazę kodu, i zrobiłem wiele systemów, w których logika transformacji była dość złożona. Zwykle używało to narzędzia ETL do wyładowywania danych, a następnie cała transformacja została wykonana w procedurach przechowywanych. Prawdopodobnie można to opisać jako ETL lub ELT, przy czym różnica polega jedynie na semantyce.
Niektóre narzędzia są jednak bardzo skoncentrowane na bazach danych (na przykład Oracle Data Integrator jest często nazywany narzędziem ELT). Jeśli zasubskrybujesz ten widok, wówczas „Wyodrębnij” i „Załaduj” mają miejsce przed przetworzeniem danych, gdy są one lądowane w obszarze pomostowym, a następnie poddawane działaniu kodu SQL lub PL / SQL (które mogą być generowane przez narzędzie lub odręcznie). Kilka osób, z którymi rozmawiałem, uważa, że główną zaletą ODI jest to, że nie jest to OWB.
Jeśli korzystasz z narzędzia po stronie klienta, takiego jak Informatica Powercentre lub MS SQL Server Integration Services, narzędzie to może przeprowadzić rozległą transformację danych po stronie klienta. Niektóre narzędzia ETL, takie jak Ascential Datastage i Ab Initio, zostały zaprojektowane z myślą o szybkiej pracy z płaskimi plikami i strukturami danych w pamięci. W tego rodzaju architekturze transformacja została już wykonana przed załadowaniem. Być może ten typ architektury można zdecydowanie sklasyfikować jako „ETL”, chociaż widziałem wiele projektów zorientowanych na narzędzia, w których cała prawdziwa praca jest wykonywana przez mnóstwo kodu procedury składowanej.
Różnorodne narzędzia i podejścia architektoniczne mają zalety, ale nie można ogólnie powiedzieć o zaletach podejść „ETL” vs. „ELT”, ponieważ terminy są tak szerokie, że różnica jest prawie bez znaczenia. Niektóre narzędzia i architektury mogą mieć określone zalety - na przykład duże użycie plików płaskich przez Ab Initio daje znaczącą przewagę wydajności w przypadku dużych woluminów danych.
W praktyce dokonanie rozróżnienia między „ETL” i „ELT” jest dość pozbawione sensu bez głębszej dyskusji na temat wymagań systemowych, platformy i architektury technicznej.
To także kwestia pieniędzy. Tam, gdzie wskazane są duże ilości danych, rozwiązania oparte na plikach płaskich, takie jak Ab Initio i DataStage Parallel Extender, są rzeczywiście szybsze, ale mogą być sześciocyfrowymi propozycjami od średniej do wysokiej. IRI CoSort jest bardzo skoncentrowany na ETL (według ich porównania ELT) i jest to jedyny przystępny sposób, w jaki widziałem rozwiązanie problemu transformacji z szybkością systemu plików, oprócz złożonej implementacji Hadoop. Myślę też, że rzucanie sprzętem na problem ogólnie (co robią również urządzenia ELT i DB w pamięci), nie skaluje się również pod względem kosztów.