Komponent ETL hurtowni danych jest często przyćmiony przez samą hurtownię i poświęca się jej mniej uwagi niż główna baza danych lub komponent front-end, BI i raportowanie. Jednocześnie z punktu widzenia mechaniki zapełniania hurtowni danymi, ETL odgrywa kluczową rolę i wymaga nie mniejszej uwagi administratorów niż inne komponenty. Nazywam się Alexander, obecnie administruję ETL w Rostelecom i w tym artykule postaram się podzielić trochę z tym, z czym musi sobie radzić administrator jednego z najsłynniejszych systemów ETL w dużej hurtowni danych w Rostelecom.
Jeśli drodzy czytelnicy już ogólnie zapoznaliście się z naszym projektem hurtowni danych i produktem Informatica PowerCenter, to możecie od razu przejść do kolejnej sekcji.
Kilka lat temu pomysł jednej korporacyjnej hurtowni danych dojrzał i zaczął być wdrażany w Rostelecom. Powstało już wiele repozytoriów rozwiązujących poszczególne problemy, ale wzrosła liczba scenariuszy, wzrosły koszty wsparcia i stało się jasne, że przyszłość leży w centralizacji. Architektonicznie jest to sam magazyn, składający się z kilku warstw, zaimplementowany na Hadoopie i GreenPlum, pomocniczych bazach danych, mechanizmach ETL i BI.
Jednocześnie ze względu na dużą liczbę rozproszonych geograficznie, heterogenicznych źródeł danych, stworzono specjalny mechanizm przesyłania danych, którego działaniem steruje Informatica. W rezultacie pakiety danych trafiają do obszaru interfejsu Hadoopa, po czym rozpoczynają się procesy ładowania danych przez warstwy przechowywania, Hadoop i GreenPlum, którymi zarządza tzw. mechanizm kontrolny ETL zaimplementowany w Informatica. Tym samym system Informatica jest jednym z kluczowych elementów zapewniających funkcjonowanie magazynu.
Nasz magazyn zostanie opisany szerzej w jednym z kolejnych wpisów.
Informatica PowerCenter/Big Data Management jest obecnie uznawana za wiodące oprogramowanie w zakresie narzędzi do integracji danych. To produkt amerykańskiej firmy Informatica, która jest jednym z najsilniejszych graczy w obszarze ETL (Extract Transform Load), zarządzania jakością danych, MDM (Master Data Management), ILM (Information Lifecycle Management) i nie tylko.
PowerCenter, z którego korzystamy, to zintegrowany serwer aplikacji Tomcat, na którym działają same aplikacje Informatica, realizując swoje usługi:
Domenaw rzeczywistości jest to podstawa wszystkiego innego; usługi, użytkownicy i komponenty GRID działają w domenie.
Konsola administratora, internetowe narzędzie do zarządzania i monitorowania, oprócz klienta Informatica Developer, głównego narzędzia do interakcji z produktem
MRS, usługa repozytorium modeli, repozytorium metadanych, to warstwa pomiędzy bazą danych, w której fizycznie przechowywane są metadane, a klientem Informatica Developer, w którym odbywa się programowanie. W repozytoriach przechowywane są opisy danych i inne informacje, w tym dla szeregu innych usług Infromatica, na przykład harmonogramy wykonywania zadań (Harmonogramy) czy monitorowanie danych, a także parametry aplikacji, w szczególności umożliwiające wykorzystanie tej samej aplikacji do pracy z różnych źródeł i odbiorców danych.
DIS, usługa integracji danych, jest to usługa, w której odbywają się główne procesy funkcjonalne, uruchamiane są w niej aplikacje oraz faktyczne uruchomienia Workflows (opisy sekwencji odwzorowań i ich interakcji) oraz Mapowania (przekształcenia, bloki, w których zachodzą same przekształcenia, przetwarzanie danych ) odbywać się.
Konfiguracja GRID-u – zasadniczo opcja budowy kompleksu z kilku serwerów, gdy obciążenie uruchamiane przez DIS jest rozdzielane pomiędzy węzły (czyli serwery wchodzące w skład domeny). W przypadku tej opcji oprócz rozłożenia obciążenia w DIS poprzez dodatkową warstwę abstrakcji GRID spajającą kilka węzłów, na której działa DIS zamiast pracować na konkretnym pojedynczym węźle, można także utworzyć dodatkowe zapasowe instancje MRS. Można nawet wdrożyć wysoką dostępność, w której połączenia zewnętrzne mogą być realizowane za pośrednictwem węzłów zapasowych, jeśli główny ulegnie awarii. Na razie porzuciliśmy tę opcję konstrukcyjną.
Informatica PowerCenter, schemat
Na wczesnych etapach pracy w ramach łańcucha dostaw danych regularnie pojawiały się problemy, część z nich wynikała z niestabilnego wówczas działania Informatica. Podzielę się kilkoma pamiętnymi momentami z tej sagi – opanowaniem Informatica 10.
Dawne logo Informatica
Nasz obszar odpowiedzialności obejmuje również inne środowiska Informatica, mają one swoją specyfikę ze względu na różne obciążenie, ale na razie będę dokładnie pamiętał, jak Informatica rozwijała się jako komponent ETL samej hurtowni danych.
Jak to się stało
W 2016 roku, kiedy staliśmy się odpowiedzialni za pracę Informatica, osiągnęła ona już wersję 10.0, a dla optymistycznych kolegów, którzy w poważnym rozwiązaniu decydowali się na zastosowanie produktu z wersją pomniejszą .0, wszystko wydawało się oczywiste – trzeba skorzystać nowa wersja! Z punktu widzenia zasobów sprzętowych wszystko było wówczas w porządku.
Od wiosny 2016 roku za pracę Informatica odpowiada wykonawca i według nielicznych użytkowników systemu „działał kilka razy w tygodniu”. W tym miejscu należy doprecyzować, że repozytorium znajdowało się de facto na etapie PoC, w zespole nie było administratorów, a system z różnych powodów ciągle się zawieszał, po czym inżynier wykonawcy zabrał się za nie ponownie.
Jesienią do zespołu dołączyło trzech administratorów, dzieląc między sobą swoje obszary odpowiedzialności i rozpoczęła się normalna praca nad organizacją działania systemów w projekcie, w tym Informatica. Osobno trzeba powiedzieć, że ten produkt nie jest powszechny i ma dużą społeczność, w której można znaleźć odpowiedzi na wszelkie pytania i rozwiązać każdy problem. Dlatego bardzo ważne było pełne wsparcie techniczne ze strony rosyjskiego partnera Informatica, przy pomocy którego zostały poprawione wszystkie nasze błędy i pomyłki młodej wówczas Informatica 10.
Pierwszą rzeczą, którą musieliśmy zrobić dla programistów naszego zespołu i wykonawcy, było ustabilizowanie pracy samej Informatica, aby zapewnić funkcjonalność internetowej konsoli administracyjnej (Administrator Informatica).
W ten sposób często spotykaliśmy programistów Informatica
Pomijając proces poszukiwania przyczyn, główną przyczyną awarii był schemat interakcji oprogramowania Informatica z bazą danych repozytorium, która znajdowała się na stosunkowo odległym serwerze z punktu widzenia krajobrazu sieciowego. Spowodowało to opóźnienia i zakłóciło mechanizmy monitorujące stan domeny Informatica. Po pewnym dostrojeniu bazy danych, zmianie parametrów Informatica, co uczyniło ją bardziej tolerancyjną na opóźnienia bazy danych i ostatecznie aktualizacji Informatica do wersji 10.1 i przeniesieniu bazy danych z poprzedniego serwera na serwer zlokalizowany bliżej Informatica, problem zniknął znaczenie i od tego czasu zdarzały się tego typu awarie, których nie obserwujemy.
Jedna z prób uruchomienia Informatica Monitor
Krytyczna była także sytuacja z konsolą administracyjną. Ponieważ aktywny rozwój odbywał się bezpośrednio w stosunkowo produktywnym środowisku, współpracownicy musieli stale analizować działanie mapowań i przepływ pracy „w drodze”. W nowej Informatica Usługa Integracji Danych nie posiada osobnego narzędzia do takiego monitorowania, ale w internetowej konsoli administracyjnej pojawiła się sekcja monitorowania (Informatica Administrator Monitor), w której można monitorować działanie aplikacji, przepływ pracy i mapowania, uruchomienia, logi. Okresowo konsola stawała się całkowicie niedostępna, informacje o bieżących procesach w DIS przestały się aktualizować lub pojawiały się błędy podczas ładowania stron.
Wybór parametrów Java w celu stabilizacji wydajności
Problem został rozwiązany na wiele sposobów, przeprowadzono eksperymenty ze zmianą parametrów, zebrano logi i jstack, wysłano do wsparcia, jednocześnie aktywnie googlowano i po prostu obserwowano.
Przede wszystkim stworzono osobny MRS do monitoringu; jak się później okazało, jest to jeden z głównych konsumentów zasobów w naszych środowiskach, gdyż mapowania uruchamiane są bardzo intensywnie. Zmieniono parametry dotyczące sterty Java i wielu innych.
W rezultacie, wraz z kolejną aktualizacją Informatica 10.1.1, działanie konsoli i monitora zostało ustabilizowane, programiści zaczęli wydajniej pracować, a regularne procesy stały się coraz bardziej regularne.
Interesujące może być doświadczenie interakcji pomiędzy rozwojem i administracją. Kwestia ogólnego zrozumienia tego, jak coś działa, co można, a czego nie można zrobić, jest zawsze ważna w przypadku stosowania złożonych systemów. Dlatego śmiało możemy polecić, aby najpierw przeszkolić zespół administracyjny w zakresie administrowania oprogramowaniem, a zespół programistów w zakresie pisania kodu i rysowania procesów w systemie, a dopiero potem wysłać pierwszego i drugiego do pracy nad efektem. Jest to naprawdę ważne, gdy czas nie jest zasobem nieskończonym. Wiele problemów można rozwiązać nawet losowo przeszukując opcje, ale czasami niektóre wymagają wiedzy apriorycznej - nasz przypadek potwierdza wagę zrozumienia tego aksjomatu.
Przykładowo, gdy próbowaliśmy włączyć wersjonowanie w MRS (jak się ostatecznie okazało, potrzebna była inna wersja SVN), po pewnym czasie z niepokojem odkryliśmy, że czas ponownego uruchomienia systemu wydłużył się do kilkudziesięciu minut. Po znalezieniu przyczyny opóźnienia w uruchomieniu i wyłączeniu wersjonowania, znów poszło nam dobrze.
Godne uwagi przeszkody związane z Informaticą obejmują epicką bitwę z rosnącymi wątkami Java. W pewnym momencie przyszedł czas na replikację, czyli rozszerzenie ustalonych procesów na dużą liczbę systemów źródłowych. Okazało się, że nie wszystkie procesy w wersji 10.1.1 działały dobrze i po pewnym czasie DIS przestał działać. Wykryto dziesiątki tysięcy wątków, których liczba szczególnie zauważalnie wzrosła podczas procedury wdrażania aplikacji. Czasami musiałem uruchamiać ponownie kilka razy dziennie, aby przywrócić funkcjonalność.
W tym miejscu należy podziękować wsparciu; problemy zostały zlokalizowane i naprawione stosunkowo szybko za pomocą narzędzia EBF (Emergency Bug Fix) - po tym wszyscy mieli poczucie, że narzędzie naprawdę działa.
To nadal działa!
Kiedy zaczęliśmy pracować w trybie docelowym, Informatica wyglądała tak. Informatica w wersji 10.1.1HF1 (HF1 to HotFix1, kompilacja dostawcy pakietu EBF) z zainstalowanym dodatkowym EBF, rozwiązująca problemy ze skalowaniem i kilka innych, na jednym z trzech serwerów wchodzącym w skład GRID, z 20 rdzeniami x86_64 i pamięcią masową, na ogromnej, powolnej macierzy dysków lokalnych – i to wszystko. konfiguracja serwera dla klastra Hadoop. Na innym identycznym serwerze działa system Oracle DBMS, który obsługuje zarówno domenę Informatica, jak i mechanizm zarządzania ETL. Wszystko to jest monitorowane przez standardowe narzędzia monitorujące zespołu (Zabbix + Grafana) po obu stronach – samej Informatici z jej usługami oraz procesów do niej ładowanych. Obecnie zarówno wydajność, jak i stabilność, niezależnie od czynników zewnętrznych, zależą od ustawień limitujących obciążenie.
Osobno możemy powiedzieć o GRID. Środowisko zostało zbudowane na trzech węzłach, z możliwością równoważenia obciążenia. Jednak podczas testów odkryto, że ze względu na problemy z interakcją pomiędzy działającymi instancjami naszych aplikacji, ta konfiguracja nie działała zgodnie z oczekiwaniami, w związku z czym postanowiono tymczasowo porzucić ten schemat budowy, usuwając dwa z trzech węzłów z domeny. Jednocześnie sam schemat pozostał ten sam i teraz jest to właśnie usługa GRID, tyle że zdegenerowana do jednego węzła.
W tej chwili trudność pozostaje związana ze spadkiem wydajności podczas regularnego czyszczenia obwodu monitora - przy równoczesnych procesach w CNN i bieżącym czyszczeniu mogą wystąpić nieprawidłowe działanie mechanizmu sterującego ETL. Obecnie jest to rozwiązywane „w zasadzie” – poprzez ręczne czyszczenie obwodu monitora, z utratą wszystkich poprzednich danych. Nie jest to zbyt krytyczne dla produktywności podczas normalnej, rutynowej pracy, ale na razie trwają poszukiwania normalnego rozwiązania.
Z tej samej sytuacji wynika kolejny problem - czasami dochodzi do wielokrotnych uruchomień naszego mechanizmu sterującego.
Wiele uruchomień aplikacji prowadzi do awarii mechanizmu
Podczas pracy zgodnie z harmonogramem, w okresach dużego obciążenia systemu, czasami zdarzają się sytuacje, które prowadzą do awarii mechanizmu. Problem jest nadal rozwiązywany ręcznie i poszukuje się trwałego rozwiązania.
Ogólnie można podsumować, że przy dużym obciążeniu bardzo ważne jest zapewnienie adekwatnych do tego zasobów, dotyczy to także zasobów sprzętowych samej Informaticy, tym samym jej repozytorium baz danych, a także zapewnienia optymalnych ustawień dla nich. Ponadto otwartym pozostaje pytanie, który schemat umieszczenia bazy danych jest lepszy – na oddzielnym hoście, czy na tym samym, na którym działa oprogramowanie Informatica. Z jednej strony taniej będzie na jednym serwerze, a przy połączeniu praktycznie wyeliminowany zostanie ewentualny problem z interakcją sieciową, z drugiej strony obciążenie hosta z bazy danych zostanie uzupełnione obciążeniem z Informatica.
Jak w przypadku każdego poważnego produktu, Informatica ma również zabawne momenty.
Któregoś razu przy porządkowaniu jakiejś awarii zauważyłem, że logi MRS dziwnie wskazują czas zdarzeń.
Dualizm czasowy w logach MRS „z założenia”
Okazało się, że znaczniki czasu zapisywane są w formacie 12-godzinnym, bez określenia AM/PM, czyli przed południem lub później. Otwarto nawet wniosek w tej sprawie i otrzymano oficjalną odpowiedź - tak było zamierzone, oceny w dzienniku MRS są zapisywane dokładnie w tym formacie. Oznacza to, że czasami pozostaje pewna intryga dotycząca czasu wystąpienia jakiegoś BŁĘDU...
Staraj się o to, co najlepsze
Dziś Informatica jest narzędziem w miarę stabilnym, wygodnym dla administratorów i użytkowników, niezwykle potężnym w stosunku do swoich obecnych możliwości i potencjału. Wielokrotnie przekracza nasze potrzeby funkcjonalne i de facto jest obecnie wykorzystywany w projekcie w sposób, który nie jest najbardziej typowy i typowy. Trudności po części wynikają ze sposobu działania mechanizmów - specyfika polega na tym, że w krótkim czasie uruchamiana jest duża liczba wątków intensywnie aktualizujących parametry i współpracujących z bazą danych repozytorium, przy niemal całkowitym wykorzystaniu zasobów sprzętowych serwera przez procesor.
Jesteśmy teraz blisko przejścia na Informatica 10.2.1 lub 10.2.2, w których przerobiono niektóre wewnętrzne mechanizmy i zapewniono wsparcie, aby wyeliminować niektóre obecne problemy z wydajnością i funkcjonalnością. A ze sprzętowego punktu widzenia oczekujemy serwerów o optymalnej dla nas konfiguracji, biorąc pod uwagę rezerwę na najbliższą przyszłość ze względu na wzrost i rozwój pamięci masowej.
Oczywiście będą testy, sprawdzanie kompatybilności i ewentualnie zmiany architektoniczne w części HA GRID. Rozwój Informatica będzie kontynuowany, ponieważ w krótkim okresie nie jesteśmy w stanie dostarczyć niczego, co zastąpiłoby system.
A ci, którzy będą w przyszłości odpowiedzialni za ten system, z pewnością będą w stanie doprowadzić go do wymaganych wskaźników niezawodności i wydajności proponowanych przez klientów.
Artykuł został przygotowany przez zespół zarządzający danymi Rostelecom
Aktualne logo Informatyki
Źródło: www.habr.com
