ETL

ETL to skrót od „extract, transform, load” (ekstrakcja, transformacja, ładowanie) i opisuje proces pobierania danych z systemów źródłowych, przekształcania ich w spójną strukturę i ładowania do miejsca docelowego, takiego jak magazyn danych. To fundament analityki, a jego niezawodność decyduje o tym, czy raporty tworzone na jego podstawie są wiarygodne.

Każdy etap wiąże się z odrębnymi trudnościami. Ekstrakcja musi uzyskać dane z systemów, które nie zostały zaprojektowane do zapytań zewnętrznych, obsługiwać limity przepustowości API, wykrywać zmiany przyrostowe oraz korzystać ze źródeł, które nie zapewniają wiarygodnego sposobu identyfikacji zmian. Transformacja musi uzgadniać niespójne formaty, różne identyfikatory, sprzeczne definicje i brakujące wartości. Ładowanie musi obsługiwać wolumen, przechowywać historię i obsługiwać rekordy, które docierają z opóźnieniem lub w niewłaściwej kolejności.

Wariant ELT odwraca dwa ostatnie etapy, ładując surowe dane do miejsca docelowego i tam je transformując. Stało się to powszechne, ponieważ nowoczesne platformy magazynowe mają wystarczającą moc przetwarzania, aby transformacja w miejscu docelowym była efektywna, a zachowanie surowych danych pozwala na ich korektę i ponowne zastosowanie bez konieczności ponownego wyodrębniania danych ze źródeł. Oznacza to również, że błędy w logice transformacji są naprawialne, a nie trwałe.

Przetwarzanie przyrostowe to praktyczna konieczność, która komplikuje większość implementacji. Ponowne przetwarzanie wszystkich danych historycznych przy każdym przebiegu jest proste i staje się niewykonalne wraz ze wzrostem wolumenu, dlatego potoki muszą identyfikować zmiany, które zaszły od ostatniego przebiegu. Źródła bez wiarygodnych znaczników czasu zmian, rekordy aktualizowane wstecznie i usunięcia nie pozostawiające śladu – wszystko to utrudnia to, niż się wydaje, a niepoprawna logika przyrostowa generuje po cichu niekompletne dane.

Obsługa awarii decyduje o tym, czy potok jest produktem klasy produkcyjnej. Potoki rutynowo ulegają awariom, ponieważ systemy źródłowe zmieniają swoje schematy, wygasają uprawnienia, usługi nadrzędne są niedostępne lub pojawiają się nieoczekiwane dane. Ważne są następujące cechy: awarie są wykrywane natychmiast, częściowe uruchomienia nie pozostawiają miejsca docelowego w niespójnym stanie, ponowne uruchomienia generują ten sam wynik, a nie duplikują rekordów, oraz powiadomienie użytkownika, a nie wykrycie awarii, gdy raport wygląda na nieprawidłowy.

Walidacja jakości danych powinna odbywać się wewnątrz procesu przetwarzania, a nie po nim. Sprawdzanie liczby wierszy pod kątem zgodności z oczekiwaniami, weryfikacja wypełnienia pól kluczowych, potwierdzenie, że wartości mieszczą się w dopuszczalnych zakresach oraz testowanie spójności referencyjnej pozwalają wykryć błędy już na wejściu. Bez tych testów błędne dane rozprzestrzeniają się na raporty i procesy decyzyjne, a zazwyczaj zostaje to wykryte przez osobę zauważającą nieprawdopodobną wartość kilka tygodni później.

Harmonogramowanie i zarządzanie zależnościami decydują o spójności wyników. Potoki rzadko działają w izolacji, a zadanie podrzędne, które rozpoczyna się przed zakończeniem działania źródła nadrzędnego, generuje częściowe wyniki, które wyglądają na kompletne. Istnieją narzędzia do orkiestracji, które pozwalają na jawne wyrażanie tych zależności, a potoki połączone w łańcuchy na podstawie założeń czasowych, a nie na podstawie zadeklarowanych zależności, okresowo ulegają awariom w sposób trudny do odtworzenia.

Dokumentacja i rodowód mają znaczenie, ponieważ potoki danych żyją dłużej niż ludzie, którzy je tworzą. Wiedza o pochodzeniu każdego pola, zastosowanych transformacjach i zakodowanych regułach biznesowych jest niezbędna, aby odpowiedzieć na pytania o to, dlaczego liczba wygląda tak, a nie inaczej, oraz ocenić wpływ zmiany systemu źródłowego. Nieudokumentowane potoki danych stają się systemami, których nikt nie odważy się modyfikować, przez co organizacje kończą z równoległymi potokami danych generującymi sprzeczne dane.

Ponieważ niezawodność, a nie wyrafinowanie, decyduje o dostarczanej wartości, dyscyplina inżynierska stosowana do rurociągów powinna być zgodna z tą stosowaną do oprogramowania produkcyjnego. W praktyce rurociągi są budowane i obsługiwane przez rozwój produktów albo Dział IT, logika transformacji kodująca definicje biznesowe jest określona za pomocą Analityka danych, a zasady walidacji warto uzgodnić przed utworzeniem pierwszego potoku, a nie dodawać je po pierwszym zdarzeniu.