🥇 Gdy macie ogromne potrzeby. Wykorzystanie Ab Initio w pracy z Hive i GreenPlum

Kilka czasu temu pojawił się przed nami problem wyboru narzędzia ETL do pracy z Big Data. Wcześniej używane rozwiązanie Informatica BDM nie spełniało naszych oczekiwań ze względu na ograniczoną funkcjonalność. Jego wykorzystanie ograniczało się do frameworka do uruchamiania poleceń spark-submit. Na rynku nie było zbyt wielu odpowiedników, które mogłyby pracować z tak dużą ilością danych, z jaką mamy do czynienia na co dzień. Ostatecznie wybraliśmy Ab Initio. Podczas pilotażowych prezentacji produkt pokazał bardzo wysoką szybkość przetwarzania danych. Informacji o Ab Initio w języku rosyjskim jest prawie brak, dlatego zdecydowaliśmy się podzielić naszym doświadczeniem na Habrze.

Ab Initio oferuje wiele klasycznych i nietypowych transformacji, których kod może być rozszerzany za pomocą własnego języka PDL. Dla małych firm to potężne narzędzie może być prawdopodobnie zbyt rozbudowane, a większość jego możliwości może okazać się kosztowna i niewykorzystana. Ale jeśli twoje potrzeby zbliżają się do tych Sberbanku, Ab Initio może być interesującym rozwiązaniem.

Pomaga biznesowi globalnie gromadzić wiedzę i rozwijać ekosystem, a programiście - rozwijać swoje umiejętności w ETL oraz poszerzać wiedzę w shell, oferując możliwość nauki języka PDL, wizualizując procesy ładowania, ułatwiając rozwój dzięki bogactwu komponentów funkcjonalnych.

W tym poście opowiem o możliwościach Ab Initio oraz przedstawię porównawcze charakterystyki jego pracy z Hive i GreenPlum.

Opis frameworka MDW oraz prace nad jego dostosowaniem do GreenPlum
Porównawcze charakterystyki wydajności Ab Initio w pracy z Hive i GreenPlum
Praca Ab Initio z GreenPlum w trybie Near Real Time

Funkcjonalność tego produktu jest bardzo szeroka i wymaga sporo czasu na jego opanowanie. Jednak przy odpowiednich umiejętnościach pracy i właściwych ustawieniach wydajności wyniki przetwarzania danych są imponujące. Użycie Ab Initio może dostarczyć programiście ciekawego doświadczenia. To nowe spojrzenie na rozwój ETL, hybryda między wizualnym środowiskiem a tworzeniem ładowań w języku przypominającym skrypt.

Biznes rozwija swoje ekosystemy, a to narzędzie wydaje się być bardziej przydatne niż kiedykolwiek. Dzięki Ab Initio można gromadzić wiedzę o bieżącym biznesie i wykorzystywać ją do rozwijania istniejących oraz otwierania nowych przedsięwzięć. Alternatywami dla Ab Initio są wizualne środowiska programistyczne, takie jak Informatica BDM oraz niewizualne środowiska, takie jak Apache Spark.

Opis Ab Initio

Ab Initio, podobnie jak inne narzędzia ETL, jest zbiorem produktów.

Ab Initio GDE (Graphical Development Environment) to środowisko dla programisty, w którym ustawia on transformacje danych i łączy je w strumieniach danych w postaci strzałek. Taki zestaw transformacji nazywany jest grafem:

Wejściowe i wyjściowe połączenia komponentów funkcjonalnych to porty i zawierają pola, które są obliczane wewnątrz transformacji. Kilka grafów, połączonych strumieniami w postaci strzałek w kolejności ich wykonywania, nazywa się planem.

Dostępnych jest kilka stów komponentów funkcjonalnych, co stanowi znaczną liczbę. Wiele z nich jest wąsko wyspecjalizowanych. Możliwości klasycznych transformacji w Ab Initio są szersze niż w innych narzędziach ETL. Na przykład Join ma kilka wyjść. Oprócz wyniku połączenia zestawów danych można uzyskać na wyjściu rekordy zestawów danych wejściowych, dla których nie udało się połączyć. Można również uzyskać rejects, errors i log pracy transformacji, który może być odczytany jako plik tekstowy i przetwarzany przez inne transformacje:

Lub, na przykład, można zmaterializować odbiornik danych w postaci tabeli i w tym samym grafie odczytać z niego dane.

Istnieją oryginalne transformacje. Na przykład, transformacja Scan ma funkcjonalność podobną do funkcji analitycznych. Istnieją transformacje z mówiącymi nazwami: Create Data, Read Excel, Normalize, Sort within Groups, Run Program, Run SQL, Join with DB i inne. Grafy mogą korzystać z parametrów czasu wykonania, w tym możliwe jest przekazywanie parametrów z systemu operacyjnego lub do systemu operacyjnego. Pliki z gotowym zestawem przekazywanych do grafu parametrów nazywane są parameter sets (psets).

Jak przystało, Ab Initio GDE ma swoje repozytorium, nazywane EME (Enterprise Meta Environment). Programiści mają możliwość pracy z lokalnymi wersjami kodu i dokonania check in swoich opracowań w centralnym repozytorium.

W trakcie lub po wykonaniu grafu istnieje możliwość kliknięcia w dowolne połączenie transformacji strumienia i przejrzenia danych, które przeszły między tymi transformacjami:

Można również kliknąć w dowolny strumień i zobaczyć szczegóły śledzenia - ile równoległych transformacji było realizowanych, ile wierszy i bajtów załadowano w której z równoległych operacji:

Istnieje możliwość podzielenia wykonania grafu na fazy i oznaczenia, które transformacje powinny być wykonywane w pierwszej kolejności (w zerowej fazie), następne w pierwszej fazie, następne w drugiej fazie itd.

Każda transformacja ma możliwość wyboru tzw. układu (gdzie będzie wykonywana): bez równoległości lub w równoległych strumieniach, której liczbę można określić. Ponadto pliki tymczasowe, które Ab Initio tworzy podczas pracy transformacji, można umieszczać zarówno w systemie plików serwera, jak i w HDFS.

W każdej transformacji na bazie szablonu domyślnego można stworzyć własny skrypt w języku PDL, który przypomina nieco shell.

Dzięki językowi PDL można rozszerzać funkcjonalność transformacji i, w szczególności, dynamicznie (w czasie wykonania) generować dowolne fragmenty kodu w zależności od parametrów wykonania.

W Ab Initio dobrze rozwinięta jest integracja z systemem operacyjnym przez shell. W Sberbanku używa się konkretnego linux ksh. Można wymieniać się ze shell zmiennymi i używać ich jako parametrów grafów. Można z shell wywoływać wykonanie grafów Ab Initio i zarządzać Ab Initio.

Oprócz Ab Initio GDE dostarczanych jest wiele innych produktów. Jest własny system Co>Operation, który aspiruje do nazwy systemu operacyjnego. Istnieje Control>Center, w którym można ustawiać harmonogramy i monitorować strumienie załadunku. Są również produkty do realizacji rozwoju na bardziej prymitywnym poziomie, niż pozwala na to Ab Initio GDE.

Opis frameworka MDW oraz prace nad jego dostosowaniem do GreenPlum

Wraz ze swoimi produktami dostawca dostarcza także produkt MDW (Metadata Driven Warehouse), który stanowi konfigurator grafów, przeznaczony do wspomagania w typowych zadaniach związanych z zapełnianiem hurtowni danych lub vaultów danych.

Zawiera on parsery metadanych dostosowane do projektu oraz gotowe generatory kodu 'z pudełka'.

MDW otrzymuje model danych, plik konfiguracyjny do ustawienia połączenia z bazą danych (Oracle, Teradata lub Hive) oraz inne ustawienia. Część specyficzna dla projektu, na przykład, wdraża model w bazie danych. Standardowa część produktu generuje grafy oraz pliki konfiguracyjne do nich podczas ładowania danych do tabel modelu. Przy tym tworzone są grafy (i psety) dla kilku trybów inicjalizacyjnych i inkrementalnych aktualizacji jednostek.

W przypadku Hive i RDBMS generowane są różne grafy dla inicjalizacji i inkrementalnej aktualizacji danych.

W przypadku Hive otrzymane dane delta są łączone za pomocą Ab Initio Join z danymi, które znajdowały się w tabeli przed aktualizacją. Ładowarki danych w MDW (zarówno w Hive, jak i RDBMS) nie tylko wstawiają nowe dane z delty, ale także zamykają okresy ważności danych, dla których delta została przesłana. Ponadto, należy ponownie zapisać niezmienioną część danych. Tak trzeba robić, ponieważ w Hive nie ma operacji delete ani update.

W przypadku RDBMS grafy dla inkrementalnej aktualizacji danych wyglądają bardziej optymalnie, ponieważ RDBMS mają rzeczywiste możliwości aktualizacji.

Otrzymana delta jest ładowana do tymczasowej tabeli w bazie danych. Następnie delta jest łączona z danymi, które były w tabeli przed aktualizacją. Dzieje się to za pomocą SQL przy użyciu wygenerowanego zapytania SQL. Następnie, za pomocą poleceń SQL delete+insert do docelowej tabeli, następuje wstawienie nowych danych z delty i zamknięcie okresów ważności danych, dla których delta została przesłana.
Nie ma potrzeby ponownego zapisywania niezmienionych danych.

W ten sposób doszliśmy do wniosku, że w przypadku Hive MDW musi zdecydować się na ponowne zapisanie całej tabeli, ponieważ Hive nie ma funkcji aktualizacji. I nic lepszego niż pełne przepisanie danych podczas aktualizacji nie zostało wymyślone. W przypadku RDBMS, przeciwnie, twórcy produktu uznali za stosowne zlecić łączenie i aktualizację tabel wykorzystaniu SQL.

Dla projektu w Sberbanku stworzyliśmy nową wielokrotnego użytku implementację ładowarki bazy danych dla GreenPlum. Zostało to zrealizowane na podstawie wersji, którą MDW generuje dla Teradata. To właśnie Teradata, a nie Oracle, okazała się lepsza i najbliższa, ponieważ również jest systemem MPP. Sposoby pracy oraz składnia Teradata i GreenPlum okazały się bliskie.

Przykłady krytycznych różnic dla MDW między różnymi RDBMS są następujące. W GreenPlum, w przeciwieństwie do Teradata, podczas tworzenia tabel należy napisać klauzulę

distributed by

W Teradata pisze się

usuń <table> wszystko

, a w GreenPlum pisze się

usuń z <table>

W Oracle w celu optymalizacji pisze się

delete from t where rowid in ()

, a w Teradata i GreenPlum pisze się

delete from t where exists (select * from delta where delta.pk=t.pk)

Dodatkowo zauważamy, że do pracy Ab Initio z GreenPlum konieczne było zainstalowanie klienta GreenPlum na wszystkich węzłach klastra Ab Initio. Dzieje się tak, ponieważ połączyliśmy się z GreenPlum jednocześnie ze wszystkich węzłów naszego klastra. Aby odczyt z GreenPlum odbywał się równolegle i każdy równoległy wątek Ab Initio odczytywał swoją porcję danych z GreenPlum, musieliśmy umieścić w sekcji „where” zapytania SQL konstrukcję rozumianą przez Ab Initio

where ABLOCAL()

i zdefiniować wartość tej konstrukcji, wskazując czytającej z bazy danych transformacji parametr

ablocal_expr=„string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))„

, która kompiluje się w coś w rodzaju

mod(sk,10)=3

, tzn. musimy podsunąć GreenPlum wyraźny filtr dla każdej partycji. Dla innych baz danych (Teradata, Oracle) Ab Initio może wykonać to równoleglenie automatycznie.

Porównawcze charakterystyki wydajności Ab Initio w pracy z Hive i GreenPlum

W Sberbanku przeprowadzono eksperyment porównawczy wydajności wygenerowanych grafów MDW w odniesieniu do Hive i GreenPlum. W ramach eksperymentu w przypadku Hive było 5 węzłów w tym samym klastrze, co Ab Initio, a w przypadku GreenPlum było 4 węzły w osobnym klastrze. Tzn. Hive miało pewną przewagę nad GreenPlum „na sprzęcie”.

Rozważono dwie pary grafów, które wykonują to samo zadanie aktualizacji danych w Hive i GreenPlum. Przy tym uruchomiono grafy wygenerowane przez konfigurator MDW:

inicjalizujące ładowanie + inkrementalne ładowanie losowo wygenerowanych danych do tabeli Hive
inicjalizujące ładowanie + inkrementalne ładowanie losowo wygenerowanych danych do identycznej tabeli GreenPlum

W obu przypadkach (Hive i GreenPlum) uruchomiono ładowania w 10 równoległych wątkach na tym samym klastrze Ab Initio. Pośrednie dane do obliczeń Ab Initio były przechowywane w HDFS (w terminach Ab Initio użyto układu MFS używającego HDFS). Jedna losowo wygenerowana linia danych zajmowała w obu przypadkach po 200 bajtów.

Wynik jest następujący:

Hive:

Inicjalne ładowanie w Hive

Wstawiono wierszy
6 000 000
60 000 000
600 000 000

Czas trwania inicjalnego
ładowania w sekundach
41
203
1 601

Inkrementalne ładowanie w Hive

Liczba wierszy, które znajdowały się w
docelowej tabeli na początku eksperymentu
6 000 000
60 000 000
600 000 000

Liczba wierszy różnicy, które zastosowano do
docelowej tabeli w trakcie eksperymentu
6 000 000
6 000 000
6 000 000

Czas trwania inkrementalnego
ładowania w sekundach
88
299
2 541

GreenPlum:

Inicjalne ładowanie w GreenPlum

Wstawiono wierszy
6 000 000
60 000 000
600 000 000

Czas trwania inicjalnego
ładowania w sekundach
72
360
3 631

Inkrementalne ładowanie w GreenPlum

Liczba wierszy, które znajdowały się w
docelowej tabeli na początku eksperymentu
6 000 000
60 000 000
600 000 000

Liczba wierszy różnicy, które zastosowano do
docelowej tabeli w trakcie eksperymentu
6 000 000
6 000 000
6 000 000

Czas trwania inkrementalnego
ładowania w sekundach
159
199
321

Widzimy, że prędkość inicjalnego ładowania zarówno w Hive, jak i w GreenPlum liniowo zależy od objętości danych, a z powodu lepszego sprzętu jest nieco szybsza dla Hive niż dla GreenPlum.

Inkrementalne ładowanie w Hive także liniowo zależy od objętości danych wcześniej załadowanych do docelowej tabeli i przebiega stosunkowo wolno w miarę wzrostu objętości. Spowodowane jest to koniecznością całkowitego przepisania docelowej tabeli. Oznacza to, że zastosowanie małych zmian w ogromnych tabelach nie jest najlepszym sposobem wykorzystania dla Hive.

Z kolei inkrementalne ładowanie w GreenPlum ma słabo rozwiniętą zależność od objętości dotychczasowych danych w docelowej tabeli i przebiega wystarczająco szybko. Udało się to dzięki SQL Joins i architekturze GreenPlum, która pozwala na operację delete.

Zatem GreenPlum wprowadza różnicę metodą delete+insert, a w Hive nie ma operacji delete ani update, dlatego cały zbiór danych podczas inkrementalnej aktualizacji musiał być przepisywany w całości. Najbardziej wyraźne jest porównanie wyróżnionych pogrubionych komórek, ponieważ odpowiada ono najczęstszemu wariantowi użytkowania zasobochłonnych ładowań. Widzimy, że GreenPlum wygrał z Hive w tym teście 8 razy.

Praca Ab Initio z GreenPlum w trybie Near Real Time

W tym eksperymencie sprawdzimy możliwość Ab Initio dokonywania aktualizacji tabeli GreenPlum losowo generowanymi porcjami danych w trybie zbliżonym do rzeczywistego czasu. Rozważymy tabelę GreenPlum dev42_1_db_usl.TESTING_SUBJ_org_finval, z którą będzie prowadzona praca.

Będziemy używać trzech grafów Ab Initio do pracy z nią:

1) Graf Create_test_data.mp – tworzy w 10 równoległych wątkach pliki z danymi w HDFS zawierające 6 000 000 wierszy. Dane są losowe, ich struktura jest zorganizowana do wstawienia w naszą tabelę.

2) Graf mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset – wygenerowany graf MDW do inicjalizującego wstawienia danych do naszej tabeli w 10 równoległych wątkach (używane są dane testowe, wygenerowane przez graf (1)).

3) Graf mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset – wygenerowany graf MDW do inkrementalnej aktualizacji naszej tabeli w 10 równoległych wątkach z użyciem nowej porcji danych (delta), wygenerowanej przez graf (1).

Wykonamy poniższy skrypt w trybie NRT:

wygenerować 6 000 000 testowych wierszy.
przeprowadzić inicjalizującą załadunek i wstawić 6 000 000 testowych wierszy do pustej tabeli.
powtórzyć 5 razy załadunek inkrementalny.
- wygenerować 6 000 000 testowych wierszy.
- przeprowadzić inkrementalne wstawienie 6 000 000 testowych wierszy do tabeli (w tym przypadku starym danym przypisywany jest czas wygaśnięcia valid_to_ts i wstawiane są nowsze dane z tym samym kluczem głównym).

Ten scenariusz emuluje tryb rzeczywistej pracy pewnego systemu biznesowego – w czasie rzeczywistym pojawia się znaczna porcja nowych danych i natychmiast zlewa się w GreenPlum.

Teraz przyjrzyjmy się logowi pracy scenariusza:

Start Create_test_data.input.pset at 2020-06-04 11:49:11
Finish Create_test_data.input.pset at 2020-06-04 11:49:37
Start mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:49:37
Finish mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:50:42
Start Create_test_data.input.pset at 2020-06-04 11:50:42
Finish Create_test_data.input.pset at 2020-06-04 11:51:06
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:51:06
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:53:41
Start Create_test_data.input.pset at 2020-06-04 11:53:41
Finish Create_test_data.input.pset at 2020-06-04 11:54:04
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:54:04
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:56:51
Start Create_test_data.input.pset at 2020-06-04 11:56:51
Finish Create_test_data.input.pset at 2020-06-04 11:57:14
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:57:14
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:59:55
Start Create_test_data.input.pset at 2020-06-04 11:59:55
Finish Create_test_data.input.pset at 2020-06-04 12:00:23
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:00:23
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:03:23
Start Create_test_data.input.pset at 2020-06-04 12:03:23
Finish Create_test_data.input.pset at 2020-06-04 12:03:49
Rozpocznij mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset o 2020-06-04 12:03:49
Zakończ mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset o 2020-06-04 12:06:46

Uzyskuje się taki obraz:

Wykres
Czas rozpoczęcia
Czas zakończenia
Długość

Create_test_data.input.pset
04.06.2020 11:49:11
04.06.2020 11:49:37
00:00:26

mdw_load.day_one.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:49:37
04.06.2020 11:50:42
00:01:05

Create_test_data.input.pset
04.06.2020 11:50:42
04.06.2020 11:51:06
00:00:24

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:51:06
04.06.2020 11:53:41
00:02:35

Create_test_data.input.pset
04.06.2020 11:53:41
04.06.2020 11:54:04
00:00:23

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:54:04
04.06.2020 11:56:51
00:02:47

Create_test_data.input.pset
04.06.2020 11:56:51
04.06.2020 11:57:14
00:00:23

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:57:14
04.06.2020 11:59:55
00:02:41

Create_test_data.input.pset
04.06.2020 11:59:55
04.06.2020 12:00:23
00:00:28

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12:00:23
04.06.2020 12:03:23
00:03:00

Create_test_data.input.pset
04.06.2020 12:03:23
04.06.2020 12:03:49
00:00:26

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12:03:49
04.06.2020 12:06:46
00:02:57

Widzimy, że 6 000 000 wierszy inkrementalnych przetwarza się w ciągu 3 minut, co jest wystarczająco szybkie.
Dane w docelowej tabeli zostały rozłożone w następujący sposób:

select valid_from_ts, valid_to_ts, count(1), min(sk), max(sk) from dev42_1_db_usl.TESTING_SUBJ_org_finval group by valid_from_ts, valid_to_ts order by 1,2;

Można dostrzec zgodność wstawionych danych z momentami uruchamiania wykresów.
Oznacza to, że można uruchamiać w Ab Initio inkrementalne ładowanie danych do GreenPlum z bardzo wysoką częstotliwością i obserwować wysoką prędkość wstawiania tych danych do GreenPlum. Oczywiście, uruchomienie co sekundę nie będzie możliwe, ponieważ Ab Initio, jak każde narzędzie ETL, wymaga czasu na "rozkręcenie".

Podsumowanie

Obecnie Ab Initio jest używane w Sberbanku do budowy Jednolitej semantycznej warstwy danych (ESS). Projekt ten zakłada budowę jedynej wersji stanu różnych bankowych bytów biznesowych. Informacje pochodzą z różnych źródeł, których repliki są przygotowywane na Hadoop. W zależności od potrzeb biznesowych, opracowywany jest model danych i opisane są transformacje danych. Ab Initio ładuje informacje do ESS, a załadowane dane nie tylko same w sobie mają znaczenie dla biznesu, ale są również źródłem do budowy witryn danych. Funkcjonalność produktu pozwala na używanie różnych systemów jako odbiorników (Hive, Greenplum, Teradata, Oracle), co daje możliwość przygotowania danych dla biznesu w różnych jego wymaganych formatach.

Możliwości Ab Initio są szerokie, na przykład dołączony framework MDW pozwala na budowanie technicznej i biznesowej historii danych "z pudełka". Dla programistów Ab Initio daje możliwość "nie wymyślania koła na nowo", a korzystania z wielu istniejących komponentów funkcjonalnych, będących de facto bibliotekami, które są potrzebne przy pracy z danymi.

Autor — ekspert profesjonalnej społeczności Sberbanku SberProfi DWH/BiGoData. Społeczność profesjonalna SberProfi DWH/BiGoData odpowiada za rozwój kompetencji w takich dziedzinach jak ekosystem Hadoop, Teradata, Oracle DB, GreenPlum, a także narzędzia BI takie jak Qlik, SAP BO, Tableau i inne.

Źródło: habr.com