ETL vs ELT: Jak Dostępne Zasoby Obliczeniowe Chmury Odwróciły Porządkowanie Pipelin Danych

Dlaczego transformacja przed ładowaniem miała sens w 2005 roku

Extract, Transform, Load — ETL — było domyślnym wzorcem z powodów prostych: magazyn danych, do którego końcowe dane docierają, były drogimi i ograniczonymi w pojemności systemami, a cykle obliczeniowe w magazynie traktowano jako skrażone zasoby nie przeznaczone na czyszczenie i przekształcanie niewykorzystanych danych. Zatem krok transformacji odbywał się na osobnym serwerze etapowym, przed dotarciem danych do magazynu: ekstrakcja z systemów źródłowych, transformacja (czyszczenie, połączenia, agregacje, przekształcenia) na dedykowanej infraestrucie ETL, a dopiero potem ładowanie końcowych, gotowych do magazynu tabel do drogiego systemu.

To miało prawdziwe koszty: serwer etapowy musiał być zaplanowany dla maksymalnej obciążenia transformacji, nawet jeśli większość czasu między oknami batchowymi był pusty, a każda nowa wymagana transformacja oznaczała dodatkowe zaplanowanie tych dedykowanych zasobów w przeszłości, proces wolny i kosztowny, gdy infrastruktura oznaczona była fizycznymi serwerami z cyklami zakupu wielokrotnie trwającymi. To również oznaczało, że niewykorzystane dane były często dysponowane po transformacji, ponieważ przechowywanie ich było też drogim — więc jeśli potem okazało się, że wystąpił błąd w transformacji, lub biznes chciał zadać nowe pytanie dotyczące oryginalnych niewykorzystanych danych, te dane mogły być już nieistniejące.

Co zmieniły chmurne magazyny danych

Chmurne magazyny danych, takie jak Snowflake, BigQuery i Redshift zrezygnowały z założenia, że obliczenia w magazynie danych są ograniczone i oddzielne od transformacji. Działały na tym, że obliczenia były elastyczne i tanie — można było uruchomić dużą klastrę przez dwadzieścia minut do wykonania ciężkiej transformacji i płacić tylko za te dwadzieścia minut, zamiast zaplanować stałą pojemność na niezwykle wysoką przepustowość. To umożliwiło ekonomiczne zarządzanie danymi wstecznymi bezpośrednio z źródła i uruchamianie transformacji jako zapytań SQL bezpośrednio w magazynie danych — Extract, Load, Transform lub ELT.

Znaczący wpływ na projekt linii przepływu danych wyniósł to. Ponieważ dane wsteczne docierają nieprzetworzone, zawsze pozostawiasz wierną kopię dokładnie tego, co system źródłowy wygenerował, więc błąd transformacji można naprawić po prostu ponownym uruchomieniem zapytań SQL nad nadal obecnymi danymi wstecznymi, zamiast odnowienia danych z systemu źródłowego, który może już się przesunąć lub usunąć swoją własną historię. A ponieważ teraz logika transformacji jest zapytaniami SQL uruchamianymi bezpośrednio w magazynie danych, a nie niestandardowym kodem działającym na oddzielnej infrastrukturze, narzędzia takie jak dbt mogły przekształcić transformację w warstwę kontrolowaną wersjami i testowalnych modeli SQL, które kompilują się do zapytań magazynu — proces, który nie istniał, gdy transformacja miała miejsce na niestandardowych serwerach ETL.

Warstwowy transformator: brąz, srebro, złoto

Pipeliny ELT zazwyczaj organizują transformację w kolejnych warstwach, często nazywanych brązem (lub oryginalnym), srebrem (lub czyszczone) i złotem (lub gotowym do biznesu) — konwencja nazw popularna dzięki architekturze medaliowej. Warstwa brązowa to oryginalne dane ładowane prawie w całości z źródła, zachowując nawet uszkodzone lub powtarzające się rekordy, ponieważ tutaj priorytetem jest lojalność względem źródła, a nie użyteczność. Warstwa srebra stosuje deduplikację, typowanie, obsługę wartości null i podstawowe walidacje, tworząc czystą, ale nadal dość granularną reprezentację. Warstwa złota stosuje logikę biznesową — łączenie po stronach, agregowanie do grainu potrzebnego dla panelu kontrolnego, a także zastosowanie modelowania gwiazdowego odpowiedniego dla konsumpcji BI.

Każda warstwa to oddzielny zestaw tabel. Ponieważ wszystkie trzy są umieszczone w tej samej magazynie danych, inżynier marnując czas na debugowanie błędu w panelu złotej warstwy może śledzić wartość wstecz do srebra, a nawet brązu, używając zwykłego SQL, aby znaleźć dokładnie tam, gdzie została wprowadzona różnica — coś, czego było znacznie trudniej zrobić, gdy logika transformacji była rozproszona między niestandardowymi skryptami ETL bez intermedyjnego stanu zapytalnego. Ta śledzimność, a nie tylko argument dotyczące wydajności, często jest tym, co zespoły cytują jako najważniejszy praktyczny zwycięstwo ELT nad starym podejściem.

Gdy ETL nadal wygrywa

ELT nie jest zawsze lepszym zastąpielem dla ETL w każdym przypadku; to jest kompromis, który przewyższa inny zestaw ograniczeń. Dzielne dane — takie jak rekordy zdrowotne, liczby kart płatniczych, wszystko pod ścisłym nadzorem regulacyjnym — często muszą być zaszyfrowane, tokenizowane lub usunięte przed tym, jak mogą znaleźć się w dowolnym miejscu, w tym warstwie oryginalnej chmury magazynu, co oznacza, że transformacja naprawdę musi mieć miejsce przed ładowaniem, a nie po nim, aby zaspokoić wymagania regulacyjne dotyczące miejsc, w których może istnieć dane niezaszyfrowane.

Inne przypadki bardzo wysokiego obciążenia strumieniowego, takie jak źródła streamingu, również stanowią sytuację, w której puro ELT ma trudności: ciągłe ładowanie pełnych, niespłaszczonych danych zdarzeń do magazynu i spłaszczanie tylko po ładowaniu może być znacznie droższe niż spłaszczanie przed ładowaniem za pomocą procesora strumieniowego (np. Flink lub Kafka Streams), ponieważ obliczenia w magazynie, choć elastyczne, kosztują znacząco więcej na jednostkę pracy niż specjalistyczna infrastruktura streamingu dla wysokoprzepustowych spłaszczonych agregacji. W praktyce większość dojrzałych platform danych kończy z hibridem: lekka transformacja (filtracja jasno widocznych śmieci, zaszyfrowywanie delikatnych poleceń, podstawowe spłaszczanie dużych voluemów firehose) przed ładowaniem, a większość logiki biznesowej i modelowania jest przeprowadzana jako ELT po tym, jak dane bezpiecznie i ekonomicznie znajduje się w magazynie.

Często zadawane pytania