Pełne ujawnienie:Ponieważ autorem tego artykułu jest firma zorientowana na ETL, która ma silną pozycję w manipulowaniu dużymi danymi poza bazami danych, poniższe informacje nie będą dla wielu obiektywne. Niemniej jednak nadal ma dawać do myślenia i otwierać drogę do dyskusji.
Od samego początku architekci hurtowni danych (DWA) mieli za zadanie tworzenie i zapełnianie hurtowni danych danymi pochodzącymi z różnych źródeł i sformatowanymi. Ze względu na gwałtowny wzrost ilości danych, te same DWA stoją przed wyzwaniem bardziej efektywnej implementacji ich integracji danych i operacji przemieszczania. Pytanie, czy transformacja danych nastąpi w docelowej bazie danych, czy poza nią, stało się kluczowe ze względu na wydajność, wygodę i konsekwencje finansowe.
W operacjach ETL (wyodrębnianie, przekształcanie, ładowanie) dane są wyodrębniane z różnych źródeł, osobno transformowane i ładowane do bazy danych DW i ewentualnie innych celów. W ELT ekstrakty są wprowadzane do pojedynczej tymczasowej bazy danych, która również obsługuje przekształcenia.
ETL pozostaje powszechny, ponieważ rynek rozwija się dzięki sprawdzonym graczom, takim jak Informatica, IBM, Oracle — i IRI z Vorcity, który łączy transformacje FACT (Fast Extract), CoSort lub Hadoop oraz ładowanie zbiorcze w tym samym graficznym interfejsie użytkownika Eclipse — w celu wyodrębniania i przekształcania danych. Takie podejście zapobiega obciążaniu baz danych zaprojektowanych do przechowywania i wyszukiwania (optymalizacja zapytań) kosztami transformacji danych na dużą skalę.
Jednak wraz z rozwojem nowej technologii baz danych i urządzeń sprzętowych, takich jak Oracle Exadata, które mogą obsługiwać transformacje „w pudełku”, ELT może być praktycznym rozwiązaniem w pewnych okolicznościach. Istotną zaletą jest izolowanie warstw pomostowych (obciążenie) i semantycznych (przekształcenia).
Przytaczaną zaletą ELT jest izolacja procesu ładowania od procesu transformacji, ponieważ usuwa nieodłączną zależność między tymi etapami.
Zauważamy, że podejście ETL IRI i tak je izoluje, ponieważ Vorality etapuje dane w systemie plików (lub HDFS). Każda porcja danych powiązana z bazą danych może zostać pobrana, oczyszczona i przekształcona zewnętrznie przed (wstępnie posortowanym) ładowaniem. To zdejmuje ciężar przekształceń na dużą skalę z bazy danych (jak również narzędzi BI/analitycznych itp.).
Ilość danych i budżety często decydują o tym, czy DWA powinien opracować rozwiązanie ETL czy ELT. W swoim artykule na blogu ITToolbox „So What Is Better, ETL or ELT?”, Vincent McBurney przedstawia swoje wady i zalety każdego z tych podejść, które powtórzyłem tutaj poniżej, a następnie za każdym razem z typową odpowiedzią IRI ETL zorientowani użytkownicy robią punkt (zgodnie z moim początkowym zastrzeżeniem dotyczącym podmiotowości):
Zalety ETLWady ETL
- ETL może równoważyć obciążenie i dzielić się obciążeniem z RDBMS – i faktycznie usuwać to obciążenie, przekształcając dane za pomocą programu SortCL lub Hadoop bez kodowania w Vorality
- ETL może wykonywać bardziej złożone operacje na pojedynczych diagramach przepływu danych za pomocą map danych – tak jak w przypadku mapowania żarłoczności i diagramów przepływu pracy, które również abstrahują krótkie, otwarte Skrypty 4GL a SQL
- ETL można skalować za pomocą oddzielnego sprzętu — na pudełkach z towarami możesz samodzielnie zaopatrywać się i utrzymywać przy znacznie niższych kosztach niż urządzenia od jednego dostawcy
- ETL może obsłużyć partycjonowanie i równoległość niezależnie od modelu danych, układu bazy danych i architektury modelu danych źródłowych – chociaż zadania CoSort SortCL Voracity w ogóle nie muszą być partycjonowane…
- ETL może przetwarzać dane w strumieniu, ponieważ przesyłane są ze źródła do celu — lub wsadowo, jeśli to ma sens
- ETL nie wymaga kolokacji zbiorów danych w celu wykonania swojej pracy – umożliwia utrzymanie istniejących platform źródeł danych bez obaw o synchronizację danych
- ETL przechwytuje dziś ogromne ilości metadanych — jak dobrze lub intuicyjnie może to zrobić jedna pomostowa baza danych?
- ETL może działać na sprzęcie SMP lub MPP – którym znowu możesz zarządzać i wykorzystywać w bardziej oszczędny sposób, i nie martwić się o rywalizację o wydajność z bazą danych
- ETL przetwarza informacje wiersz po wierszu i wydaje się, że działa to dobrze w przypadku integracji danych z produktami innych firm — chociaż jeszcze lepiej cały blok, tabela lub plik(i)-w-czasie, które Voracity są uruchamiane w woluminie.
Zalety ELT
- Potrzebne są dodatkowe inwestycje w sprzęt dla silników ETL – chyba że uruchomisz je na serwerze(-ach) bazy danych
- Dodatkowy koszt budowy systemu ETL lub licencjonowania narzędzi ETL – które wciąż są tańsze w porównaniu z urządzeniami ELT, ale wciąż tańsze są narzędzia IRI, takie jak Vorality, które łączą Fast Extract (FACT) i CoSort, aby przyspieszyć ETL bez takiej złożoności
- Możliwa zmniejszona wydajność podejścia opartego na wierszach — dobrze i dlaczego zdolność Vorality do profilowania, pozyskiwania, przekształcania i wyprowadzania danych w większych fragmentach jest szybsza
- Wyspecjalizowane umiejętności i krzywa uczenia się wymagane do wdrożenia narzędzia ETL – chyba że używasz ergonomicznego GUI, takiego jak Vorality, który zapewnia wiele opcji projektowania pracy w tym samym środowisku Eclipse IDE
- Zmniejszona elastyczność ze względu na zależność od dostawcy narzędzi ETL — Nie jestem pewien, jak można to poprawić, polegając na jednym dostawcy ELT/urządzenia; czy niezależność od dostawcy nie jest kluczem do elastyczności i oszczędności?
- Dane muszą przejść przez jeszcze jedną warstwę, zanim trafią do zbiorczej bazy danych – chyba że zbiorcza baza danych była tylko kolejnym wynikiem procesu ETL, typowym dla wielocelowych operacji Voracity.
Wady ELT
- ELT wykorzystuje sprzęt RDBMS do skalowalności — ale także obciąża zasoby bazy danych przeznaczone do optymalizacji zapytań. Transformacje CoSort i Hadoop w Vorality wykorzystują algorytmy skalowania liniowego i konsolidację zadań, a nie pamięć lub zasoby we/wy bazy danych
- ELT przechowuje wszystkie dane w RDBMS przez cały czas – co jest w porządku, o ile dane źródłowe i docelowe znajdują się w tej samej bazie danych
- ELT jest zrównoleglony zgodnie z zestawem danych, a dyskowe operacje we/wy są zwykle optymalizowane na poziomie silnika w celu uzyskania większej przepustowości — tak, ale jest to nawet bardziej prawdziwe w przypadku zewnętrznych transformacji, które nie walczą z zasobami serwera DB
- ELT skaluje się tak długo, jak sprzęt i silnik RDBMS mogą nadal się skalować – co ile kosztuje w porównaniu z alternatywą powyżej?
- ELT może osiągnąć od 3 do 4 razy większą przepustowość na odpowiednio dostrojonej platformie MPP RDBMS – co stawia urządzenie na poziomach wydajności Vorality w porównaniu z narzędziami ETL, ale przy 20-krotnym koszcie.
- Transformacja ELT jest wykonywana na serwerze RDBMS, gdy baza danych znajduje się na platformie docelowej i nie obciąża już sieci – – więc zamiast tego obciąża bazę danych (użytkowników)?
- ELT ma proste specyfikacje transformacji za pośrednictwem języka SQL — które nie są tak proste, elastyczne ani tak bogate w funkcje, jak składnia CoSort SortCL lub mapowanie pól metodą „przeciągnij i upuść” w interfejsie graficznym Eclipse Vorality.
- Ograniczone narzędzia dostępne z pełnym wsparciem dla ELT – i po bardzo wysokich cenach dla urządzeń DB zachwalających wysoką wydajność
- Utrata szczegółowych statystyk monitorowania w czasie wykonywania i pochodzenia danych – zwłaszcza analizy wpływu metadanych na zmiany w odmiennych plikach, tabelach lub źródłach nieustrukturyzowanych
- Utrata modułowości z powodu projektowania opartego na zestawach dla wydajności – i wynikająca z tego utrata funkcjonalności/elastyczności
- Przekształcenia wykorzystywałyby zasoby bazy danych, potencjalnie wpływając na wydajność raportowania BI – nie wspominając o wydajności zapytań i innych operacji bazy danych
Architektury hybrydowe, takie jak ETLT, TELT, a nawet TETLT, pojawiają się następnie w celu uzupełnienia słabości obu podejść. Wydaje się jednak, że dodają one dodatkowe poziomy złożoności procesom, które już są tak napięte. Naprawdę nie ma żadnej srebrnej kuli, a wiele projektów integracji danych kończy się niepowodzeniem z powodu umów SLA, przekroczeń kosztów i złożoności.
Z tych powodów firma IRI stworzyła Voracity, aby integrować dane za pośrednictwem programu CoSort SortCL z istniejącymi systemami plików lub strukturami Hadoop bez ponownego kodowania. Voracity to jedyna platforma zorientowana na ETL (choć również obsługująca ELT), która oferuje obie opcje zewnętrznej transformacji danych. Oprócz doskonałego stosunku ceny do wydajności w zakresie przenoszenia i manipulacji danymi, Vorality obejmuje:
- zaawansowana transformacja danych, jakość danych, MDM i raportowanie
- powoli zmiana wymiarów, zmiana przechwytywania danych, federacja danych
- profilowanie danych, maskowanie danych, generowanie danych testowych i zarządzanie metadanymi
- proste skrypty 4GL, które Ty lub kreatory, diagramy i okna dialogowe Eclipse tworzysz i zarządzasz
- bezproblemowe wykonanie w Hadoop MR2, Spark, Spart Stream Storm i Tez
- obsługa erwin Smart Connectors (konwersja z innych narzędzi ETL)
- natywne sterowniki MongoDB i połączenia z innymi źródłami NoSQL, Hadoop, chmurą i starszymi źródłami
- wbudowane funkcje raportowania, statystyk i predykcji, powiązania KNIME i Splunk oraz kanały danych narzędzi analitycznych.
Zobacz też:
- 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
