Komponenta ETL w hurtowni danych często pozostaje w cieniu samej hurtowni i jest mniej doceniana niż główna baza danych czy komponenty frontowe, BI, czy tworzenie raportów. Z perspektywy mechaniki wypełniania hurtowni danymi, ETL odgrywa kluczową rolę i wymaga nie mniejszej uwagi administratorów niż inne komponenty. Nazywam się Aleksander, aktualnie administruję ETL w Rostelecom, a w tym artykule postaram się trochę podzielić tym, z czym musi się mierzyć administrator jednej z najsłynniejszych systemów ETL w dużej hurtowni danych firmy Rostelecom.
Jeśli szanowni czytelnicy są już ogólnie zaznajomieni z naszym projektem hurtowni danych i z produktem Informatica PowerCenter, można od razu przejść do następnej sekcji.
Kilka lat temu w Rostelecom zrodziła się i zaczęła się realizować idea jednolitej korporacyjnej hurtowni danych. Powstało już kilka hurtowni, które rozwiązywały oddzielne zadania, ale liczba scenariuszy rosła, koszty utrzymania również wzrastały, i stało się jasne, że przyszłość należy do centralizacji. Architektonicznie sama hurtownia składa się z kilku warstw, realizowanej na Hadoop i GreenPlum, baz pomocniczych, mechanizmów ETL oraz BI.
W związku z dużą liczbą terytorialnie rozproszonych, zróżnicowanych źródeł danych, stworzono specjalny mechanizm do wyciągania danych, którego działanie jest zarządzane przez Informatica. W rezultacie pakiety z danymi trafiają do obszaru interfejsowego Hadoop, po czym rozpoczynają się procesy ładowania danych po warstwach hurtowni w Hadoop i GreenPlum, zarządzane przez tzw. mechanizm sterujący ETL, zrealizowany w Informatica. Tak więc, system Informatica jest jednym z kluczowych elementów, które zapewniają działanie hurtowni.
Bardziej szczegółowo o naszej hurtowni opowiemy w jednym z kolejnych postów.
Informatica PowerCenter/Big Data Management jest obecnie uważany za wiodące oprogramowanie w dziedzinie narzędzi integracji danych. To produkt amerykańskiej firmy Informatica, będącej jednym z najsilniejszych graczy w dziedzinie ETL (Extract Transform Load), zarządzania jakością danych, MDM (Master Data Management), ILM (Information Lifecycle Management) i innych.
Używana przez nas PowerCenter to zintegrowany serwer aplikacji Tomcat, na którym działają same aplikacje Informatica, realizujące jej usługi:
Domena, w zasadzie stanowi to podstawę dla wszystkiego, w ramach domeny działają usługi, użytkownicy, komponenty GRID.
Konsola administratora, narzędzie webowe do zarządzania i monitorowania, obok klienta Informatica Developer, głównego narzędzia do interakcji z produktem.
MRS, Usługa Repozytorium Modeli, magazyn metadanych, stanowi warstwę pośrednią między bazą, w której metadane są przechowywane fizycznie, a klientem Informatica Developer, w którym odbywa się rozwój. Repozytoria przechowują zarówno opisy danych, jak i inne informacje, w tym dla szeregu innych usług Informatica, na przykład harmonogramy uruchamiania zadań (Schedules) lub dane monitorowania, a także zestawy parametrów aplikacji, w szczególności umożliwiające użycie tej samej aplikacji do pracy z różnymi źródłami i odbiornikami danych.
DIS, Usługa Integracji Danych, to usługa, w której odbywają się główne procesy funkcjonalne, w niej działają aplikacje i są uruchamiane Workflows (opisy sekwencji mappings i ich interakcji) oraz Mappings (transformacje, bloki, w których odbywają się same przekształcenia i przetwarzanie danych).
Konfiguracja GRID – w zasadzie, wariant budowy kompleksu z wykorzystaniem kilku serwerów, gdy obciążenie uruchamiane przez DIS jest rozdzielane pomiędzy węzły (tj. serwery wchodzące w skład domeny). W przypadku tej opcji, oprócz rozdzielenia obciążenia w DIS przez dodatkową warstwę abstrakcji GRID, łączącą kilka węzłów, na którym działa DIS, zamiast pracy na konkretnej jednej węźle, mogą być również tworzone dodatkowe zapasowe egzemplarze MRS. Można nawet zrealizować wysoką dostępność, kiedy zewnętrzne zapytania mogą być realizowane przez zapasowe węzły w przypadku awarii głównej. Z tej opcji budowy na razie zrezygnowaliśmy.
Informatica PowerCenter, schematycznie
Na wczesnych etapach pracy w ramach łańcucha dostaw danych regularnie występowały problemy, część z nich dzięki niestabilnej wówczas pracy Informatica. Zamierzam podzielić się niektórymi z zapadających w pamięć momentów tej sagi — oswajania Informatica 10.
Poprzednie logo Informatica
Nasza odpowiedzialność obejmuje również inne środowiska Informatica, które mają swoją specyfikę ze względu na różne obciążenia. Na razie skupię się na tym, jak Informatica rozwijała się jako komponent ETL samego magazynu danych.
Jak to się stało
W 2016 roku, gdy zaczęliśmy odpowiadać za działanie Informatica, osiągnęła ona już wersję 10.0. Dla optymistycznie nastawionych kolegów, którzy podejmowali decyzję o wdrożeniu produktu w wersji z taką oznaczeniem, wszystko wydawało się oczywiste — trzeba używać nowej wersji! Pod względem zasobów sprzętowych sytuacja była wówczas znakomita.
Od wiosny 2016 r. za działanie Informatica odpowiadał wykonawca, a z relacji nielicznych użytkowników systemu wynikało, że „działała kilka razy w tygodniu”. Należy zaznaczyć, że magazyn był de facto na etapie PoC, w zespole nie było administratorów, a system często się zawieszał z różnych powodów, po czym inżynier wykonawcy musiał go ponownie uruchamiać.
Na jesieni w zespole pojawiło się trzech administratorów, którzy podzielili się odpowiedzialnościami, a normalna praca nad eksploatacją systemów w projekcie, w tym Informatica, zaczęła się organizować. Należy dodać, że ten produkt nie jest szeroko rozpowszechniony ani nie ma dużej społeczności, w której można znaleźć odpowiedzi na wszelkie pytania i rozwiązać jakikolwiek problem. Dlatego bardzo ważne było pełne wsparcie techniczne od rosyjskiego partnera Informatica, dzięki któremu naprawiano nasze błędy oraz błędy młodej wówczas wersji Informatica 10.
Pierwszą rzeczą, którą musieliśmy zrobić dla programistów naszego zespołu i wykonawcy, było ustabilizowanie pracy samej Informatica oraz osiągnięcie funkcjonalności webowej konsoli administracyjnej (Informatica Administrator).
Tak często spotykali nas programiści Informatica.
Pomijając sam proces ustalania przyczyn, głównym powodem awarii była interakcja oprogramowania Informatica z bazą danych repozytorium, która znajdowała się na dość odległym serwerze, z perspektywy sieciowej. Prowadziło to do opóźnień, które zakłócały działanie mechanizmów kontrolujących stan domeny Informatica. Po pewnym dostosowaniu bazy danych i zmianie parametrów Informatica, które uczyniły ją bardziej tolerancyjną na opóźnienia, oraz aktualizacji wersji Informatica do 10.1 i przeniesieniu bazy danych z poprzedniego serwera na serwer położony bliżej Informatica, problem stracił na znaczeniu i od tego czasu nie zaobserwowaliśmy podobnych awarii.
Jedna z prób osiągnięcia działania Informatica Monitor
Sytuacja z konsolą administracyjną była również krytyczna. Ponieważ aktywnie rozwijano ją w warunkach produkcyjnych, kolegom nieustannie było potrzebne analizowanie pracy mappingów i workflow 'na żywo'. W nowej wersji Informatica, w Data Integration Service, nie ma oddzielnego narzędzia do takiego monitorowania, ale w web-konsoli administracyjnej pojawiła się sekcja monitorowania (Informatica Administrator Monitor), w której można obserwować działanie aplikacji, workflow i mappingów, uruchomienia, logi. Okresowo konsola stawała się całkowicie niedostępna, lub informacje o bieżących procesach w DIS przestawały się aktualizować, albo występowały błędy podczas ładowania stron.
Dobór parametrów java dla stabilizacji pracy
Rozwiązanie problemu odbywało się wieloma drogami, prowadzono eksperymenty z zmianą parametrów, gromadzono logi, jstack, wysyłano do wsparcia, jednocześnie intensywnie przeszukiwano Google i po prostu prowadzono obserwację.
W pierwszej kolejności utworzono osobny MRS do monitorowania, co, jak się później okazało, jest jednym z głównych użytkowników zasobów w naszych środowiskach, ponieważ uruchomienia mappingów odbywają się bardzo intensywnie. Zmieniono parametry dotyczące java heap i szereg innych.
W rezultacie przy kolejnej aktualizacji Informatica 10.1.1 udało się ustabilizować pracę konsoli i monitora, deweloperzy zaczęli pracować efektywniej, a regularne procesy stawały się coraz bardziej regularne.
Interesującym doświadczeniem może być współpraca między rozwojem a administracją. Pytanie o ogólne zrozumienie tego, jak wszystko działa, co można robić, a czego nie, zawsze jest ważne przy korzystaniu ze skomplikowanych systemów. Dlatego można śmiało zalecić najpierw przeszkolenie zespołu administratorów w zakresie zarządzania oprogramowaniem, a zespołu deweloperów w tym, jak pisać kod i projektować procesy w systemie, a dopiero potem wysyłać ich do pracy nad rezultatem. To naprawdę istotne, gdy czas nie jest nieskończonym zasobem. Wiele problemów można rozwiązać nawet przypadkowym przeszukiwaniem opcji, ale czasami niektóre z nich wymagają a priori wiedzy — nasz przypadek potwierdza ważność zrozumienia tej aksjomat.
Na przykład, gdy próbowaliśmy włączyć wersjonowanie w MRS (jak się okazało, potrzebna była inna wersja SVN), po pewnym czasie z niepokojem odkryliśmy, że czas restartu systemu wydłużył się do kilku dziesiątek minut. Kiedy zidentyfikowaliśmy przyczynę opóźnienia uruchomienia i wyłączyliśmy wersjonowanie, wszystko wróciło do normy.
Wśród istotnych przeszkód związanych z Informatica można wspomnieć epicką walkę z rosnącymi wątkami java. W pewnym momencie nadszedł czas na replikację, czyli rozprzestrzenienie ustalonych procesów na dużą liczbę źródłowych systemów. Okazało się, że nie wszystkie procesy w 10.1.1 działały dobrze, a po pewnym czasie DIS stawał się nieaktywny. Odkryto dziesiątki tysięcy wątków, których liczba szczególnie wzrastała podczas procedury wdrażania aplikacji. Czasami trzeba było wielokrotnie restartować w ciągu dnia, aby przywrócić funkcjonalność.
Tutaj trzeba podziękować wsparciu, problemy zostały stosunkowo szybko zlokalizowane i naprawione za pomocą EBF (Emergency Bug Fix) – po tym wszyscy odczuli, że narzędzie naprawdę działa.
Jednak to działa!
W momencie rozpoczęcia pracy w trybie docelowym Informatica wyglądała następująco. Wersja Informatica 10.1.1HF1 (HF1 to HotFix1, wersja od dostawcy złożona z zestawu EBF) z dodatkowo zainstalowanymi EBF, które rozwiązywały nasze problemy z skalowaniem i kilka innych, na jednym z trzech serwerów wchodzących w skład GRID, 20 rdzeni x86_64 oraz przechowywanie na ogromnym, wolnym zestawie lokalnych dysków — to konfiguracja serwera dla klastra Hadoop. Na innym takim samym serwerze znajduje się baza danych Oracle, z którą współpracuje zarówno domena Informatica, jak i zarządzający mechanizm ETL. Wszystko to jest monitorowane przez standardowe narzędzia monitoringu używane w zespole (Zabbix + Grafana), dwóch stron — i sama Informatica z jej usługami, oraz procesy wczytywania, które do niej trafiają. Obecnie zarówno wydajność, jak i stabilność pracy, z pominięciem czynników zewnętrznych, zależy od ustawień ograniczających obciążenie.
Osobno można wspomnieć o GRID. Środowisko było budowane na trzech węzłach z możliwością balansowania obciążenia. Jednak podczas testowania odkryto, że z powodu problemów z interakcją między uruchamianymi instancjami naszych aplikacji taka konfiguracja nie działała zgodnie z oczekiwaniami, i tymczasowo zdecydowano się zrezygnować z tego schematu, wyłączając dwa z trzech węzłów z domeny. Schemat pozostał ten sam, więc obecnie jest to serwis GRID, ale zredukowany do jednego węzła.
Bezpośrednio teraz pozostaje trudność związana z spadkiem wydajności podczas regularnego czyszczenia schematu monitora — przy jednoczesnym uruchamianiu procesów w CHN i uruchomionym czyszczeniu mogą występować awarie w działaniu zarządzającego mechanizmu ETL. Na razie rozwiązanie to jest "prowizoryczne" — ręczne czyszczenie schematu monitora, z utratą wszystkich wcześniejszych danych. Nie jest to zbyt krytyczne dla produkcji, w normalnej operacyjnej pracy, ale wciąż trwa poszukiwanie normalnego rozwiązania.
Z tej samej sytuacji wynika także inny problem — czasami dochodzi do wielokrotnych uruchomień naszego zarządzającego mechanizmu.
Wielokrotne uruchomienia aplikacji prowadzące do awarii mechanizmu.
Podczas uruchamiania zgodnie z harmonogramem w momentach dużego obciążenia systemu zdarzają się sytuacje, które prowadzą do awarii mechanizmu. Do tej pory problem jest rozwiązany ręcznie, trwa poszukiwanie stałego rozwiązania.
Podsumowując, przy dużym obciążeniu niezwykle istotne jest zapewnienie odpowiednich zasobów, co dotyczy zarówno zasobów sprzętowych dla samej Informatica, jak i dla jej bazy danych, a także optymalnych ustawień dla tych elementów. Poza tym pozostaje otwarte pytanie, jaki schemat umiejscowienia bazy danych jest lepszy — na oddzielnym hoście, czy na tym samym, na którym działa oprogramowanie Informatica. Z jednej strony, na jednym serwerze będzie taniej, a łączenie praktycznie eliminuje potencjalny problem z komunikacją sieciową, z drugiej strony — obciążenie hosta przez bazę danych zwiększa ogólne obciążenie wynikające z działania Informatica.
Jak w każdym poważnym produkcie, w Informatica również zdarzają się kuriozalne momenty.
Pewnego razu, analizując jakąś awarię, zwróciłem uwagę na to, że w logach MRS dziwnie zaznaczone jest czas zdarzeń.
Czasowy dualizm w logach MRS "by design"
Okazało się, że znaczniki czasowe są zapisywane w formacie 12 godzin, bez wskazania AM/PM, co oznacza, że chodzi o czas przedpołudniowy lub popołudniowy. W tej sprawie została nawet otwarta reklamacja i uzyskano oficjalną odpowiedź — tak to było zaprojektowane, w logu MRS znaczniki są zapisywane w takim formacie. To więc czasami budzi pewną intrygę, jeśli chodzi o czas wystąpienia jakiegoś błędu...
Dążyć do lepszego
Dziś Informatica to stosunkowo stabilne narzędzie, wygodne dla administratorów i użytkowników, niezwykle potężne pod względem aktualnych możliwości i potencjału. W funkcjonalności znacznie przewyższa nasze potrzeby, a de facto obecnie wykorzystywane jest w projekcie w sposób niezbyt typowy. Trudności częściowo wynikają z tego, jak działają mechanizmy — specyfika polega na tym, że w krótkim czasie uruchamiana jest duża liczba wątków, które intensywnie aktualizują zestawy parametrów i pracują z bazą danych repozytorium, przy czym zasoby sprzętowe serwera są niemal całkowicie wykorzystywane przez CPU.
Obecnie zbliżamy się do przejścia na Informatica 10.2.1 lub 10.2.2, w których przeszły zmiany w niektórych mechanizmach wewnętrznych, a wsparcie obiecuje brak wielu obecnie występujących problemów z wydajnością i funkcjonowaniem. Oczekiwane są również serwery o optymalnej dla nas konfiguracji, biorąc pod uwagę zapas na najbliższy czas w związku z rozwojem i wzrostem magazynu.
Oczywiście, czeka nas testowanie, sprawdzanie kompatybilności i być może zmiany architektoniczne w części HA GRID. Rozwój w ramach Informatica będzie kontynuowany, ponieważ w krótkim okresie nie możemy wprowadzić żadnego zastępstwa dla systemu.
A ci, którzy w przyszłości będą odpowiedzialni za ten system, na pewno będą w stanie doprowadzić go do wymaganych wskaźników niezawodności i wydajności stawianych przez klientów.
Artykuł przygotowany przez zespół zarządzania danymi „Rosnieft”
Aktualne logo Informatica
Źródło: habr.com
