Każda operacja z dużymi danymi wymaga dużej mocy obliczeniowej. Zwykłe przenoszenie danych z bazy na Hadoop może trwać tygodnie lub kosztować tyle, co skrzydło samolotu. Nie chcesz czekać i wydawać pieniędzy? Równoważ obciążenie na różnych platformach. Jednym ze sposobów jest optymalizacja pushdown.
Poprosiłem wiodącego szkoleniowca w Polsce w zakresie opracowywania i zarządzania produktami Informatica, Aleksieja Ananieva, aby opowiedział o funkcji optymalizacji pushdown w Informatica Big Data Management (BDM). Kiedyś uczyliście się pracować z produktami Informatica? Prawdopodobnie to Aleksiej uczył was podstaw PowerCenter i wyjaśniał, jak budować mapowania.
Aleksiej Ananiew, kierownik działu szkoleń DIS Group
Czym jest pushdown?
Wielu z was jest już zaznajomionych z Informatica Big Data Management (BDM). Produkt potrafi integrować duże dane z różnych źródeł, przemieszczać je pomiędzy różnymi systemami, zapewnia łatwy dostęp, umożliwia profilowanie i wiele więcej.
W zręcznych rękach BDM potrafi czynić cuda: zadania będą wykonywane szybko i z minimalnymi zasobami obliczeniowymi.
Czy również tego pragniecie? Nauczcie się korzystać z funkcji pushdown w BDM, aby rozłożyć obciążenie obliczeniowe między różnymi platformami. Technologia pushdown pozwala przekształcić mapowanie w skrypt i wybrać środowisko, w którym ten skrypt zostanie uruchomiony. Możliwość takiego wyboru pozwala łączyć mocne strony różnych platform i osiągać ich maksymalną wydajność.
Aby skonfigurować środowisko wykonania skryptu, należy wybrać typ pushdown. Skrypt może być całkowicie uruchomiony na Hadoop lub częściowo rozłożony między źródłem a odbiorcą. Istnieją 4 możliwe typy pushdown. Mapowanie można nie przekształcać w skrypt (native). Mapowanie można wykonać maksymalnie na źródle (source) lub całkowicie na źródle (full). Również mapowanie można przekształcić w skrypt Hadoop (none).
Optymalizacja pushdown
Wymienione 4 typy można łączyć w różny sposób – optymalizować pushdown pod konkretne potrzeby systemu. Na przykład często sensowniej jest wydobywać dane z bazy danych, wykorzystując jej własne możliwości. A przetwarzać dane przy pomocy Hadoop, aby nie przeciążać samej bazy.
Rozważmy przypadek, w którym zarówno źródło, jak i odbiornik znajdują się w bazie danych, a platforma realizacji transformacji może być wybrana: w zależności od ustawień będzie to Informatica, serwer bazy danych lub Hadoop. Taki przykład pozwoli najlepiej zrozumieć techniczne aspekty działania tego mechanizmu. Oczywiście, w rzeczywistym życiu taka sytuacja się nie zdarza, ale do celów demonstracyjnych jest to idealne rozwiązanie.
Weźmy mapowanie do odczytu dwóch tabel w jednej bazie danych Oracle. A wyniki odczytu niech będą zapisywane w tabeli w tej samej bazie. Schemat mapowania będzie wyglądał następująco:
W postaci mapowania w Informatica BDM 10.2.1 wygląda to w ten sposób:
Typ pushdown – native
Jeśli wybierzemy typ pushdown native, mapowanie zostanie wykonane na serwerze Informatica. Dane zostaną odczytane z serwera Oracle, przeniesione na serwer Informatica, tam przekształcone i przekazane do Hadoop. Innymi słowy, otrzymamy standardowy proces ETL.
Typ pushdown – source
W przypadku wyboru typu source zyskujemy możliwość rozdzielenia naszego procesu między serwerem bazy danych (BDB) a Hadoop. W trakcie realizacji procesu z tym ustawieniem do bazy będą wysyłane zapytania o odczyt danych z tabel. A reszta będzie realizowana w formie kroków w Hadoop.
Schemat wykonania będzie wyglądał tak:
Poniżej znajduje się przykład ustawienia środowiska wykonawczego.
W tym przypadku mapowanie będzie realizowane w dwóch krokach. W jego ustawieniach zobaczymy, że przekształciło się w skrypt, który zostanie wysłany do źródła. Połączenie tabel i przekształcenie danych zostanie zrealizowane w formie nadpisanego zapytania w źródle.
Na poniższym obrazku widzimy zoptymalizowane mapowanie w BDM, a w źródle – nadpisane zapytanie.
Rola Hadoop w tej konfiguracji sprowadza się do zarządzania przepływem danych – dyrygowania nimi. Wynik zapytania będzie kierowany do Hadoop. Po zakończeniu odczytu plik z Hadoop zostanie zapisany w odbiorniku.
Typ pushdown – full
W przypadku wyboru typu full mapowanie całkowicie przekształca się w zapytanie do bazy danych. A wynik zapytania będzie kierowany do Hadoop. Schemat takiego procesu przedstawiono poniżej.
Przykład ustawienia przedstawiono poniżej.
W rezultacie otrzymamy zoptymalizowane mapowanie podobne do poprzedniego. Różnica polega jedynie na tym, że cała logika przenosi się na odbiornik w postaci nadpisania jego wstawienia. Przykład zoptymalizowanego mapowania przedstawiono poniżej.
Podobnie jak w poprzednim przypadku, Hadoop pełni rolę dyrygenta. Tutaj jednak odczyt źródła odbywa się w całości, a następnie na poziomie odbiornika wykonywana jest logika przetwarzania danych.
Typ pushdown – null
Ostatnia opcja to typ pushdown, w którym nasze mapowanie przekształci się w skrypt na Hadoop.
Optymalizowane mapowanie będzie teraz wyglądać następująco:
Tutaj dane z plików źródłowych najpierw będą odczytane na Hadoop. Następnie za pomocą jego narzędzi te dwa pliki zostaną połączone. Po tym dane zostaną przekształcone i załadowane do bazy danych.
Rozumiejąc zasady optymalizacji pushdown, można bardzo efektywnie zorganizować wiele procesów pracy z dużymi danymi. Na przykład niedawno jedna dużą firma w ciągu zaledwie kilku tygodni wyeksportowała z magazynu w Hadoop ogromne dane, które wcześniej gromadziła przez kilka lat.
Źródło: habr.com
