ETL компонентата на хранилището на данни често остава в сянка на самото хранилище и й се обръща по-малко внимание, отколкото на главната база данни или фронт компонентите, BI, формированието на отчети. Въпреки това, от гледна точка на механиката на запълване на хранилището с данни, ETL играе ключова роля и изисква не по-малко внимание от администраторите в сравнение с останалите компоненти. Аз съм Александър, в момента администрирам ETL в Ростелеком, и в тази статия ще се опитам да споделя малко за това, с което се сблъсква администраторът на една известна ETL система в голямото хранилище на данни на компанията Ростелеком.
Ако уважаемите читатели вече са запознати в общи линии с нашия проект за хранилище на данни и с продукта Informatica PowerCenter, може веднага да преминете към следващия раздел.
Преди няколко години в Ростелеком се зароди и започна да се реализира идеята за единно корпоративно хранилище на данни. Бяха създадени няколко хранилища, решаващи отделни задачи, но броят на сценарите нарастваше, разходите за поддръжка също се увеличаваха и стана ясно, че бъдещето е в централизацията. Архитектурно, това хранилище се състои от няколко слоя, реализирано на Hadoop и GreenPlum, спомагателни бази данни, ETL механизми и BI.
Въпреки това, поради голямото количество териториално разпределени, хетерогенни източници на данни, беше създаден специален механизъм за извличане на данни, чиято работа се управлява от Informatica. В резултат на това пакетите с данни попадаха в интерфейната зона на Hadoop, след което започват процесите на прехвърляне на данни по слоевете на хранилището, в Hadoop и GreenPlum, а те се управляват от т.нар. управляващ механизъм ETL, реализиран в Informatica. По този начин, системата Informatica е един от ключовите елементи, осигуряващи функционирането на хранилището.
По-подробно за нашето хранилище ще бъде разказано в една от следващите публикации.
Informatica PowerCenter / Big Data Management в момента се счита за водещ софтуер в сферата на инструментите за интеграция на данни. Това е продукт на американската компания Informatica, която е един от най-силните играчи в ETL (Extract Transform Load), управлението на качеството на данните, MDM (Master Data Management), ILM (Information Lifecycle Management) и др.
Използваният от нас PowerCenter представлява интегриран сървър за приложения Tomcat, в който работят самите приложения Informatica, реализиращи нейните услуги:
Domain, по същество това е основата за всичко останало, в рамките на домейна работят услуги, потребители, компоненти GRID.
Конзола на администратора, уеб-инструмент за управление и мониторинг, освен клиента Informatica Developer, основният инструмент за взаимодействие с продукта
MRS, Услуга за хранилище на модели, хранилище на метаданни, представляващо прослойка между базата, в която метаданните се съхраняват физически, и клиента Informatica Developer, в който се извършва разработката. Репозиториите съхраняват както описанието на данните, така и друга информация, включително за редица други услуги на Informatica, например, график на стартиранията на задания (Schedules) или данни за мониторинг, както и параметрите на приложенията, позволяващи да се използва едно и също приложение за работа с различни източници и приемници на данни.
DIS, Услуга за интеграция на данни, това е услугата, в която се извършват основните функционални процеси, в която работят приложенията и се стартират самите работни потоци (описания на последователността на mappings и тяхното взаимодействие) и Mappings (трансформации, блокове, в които се извършват самите преобразования, обработка на данни).
Конфигурация на GRID – по същество вариант на изграждане на комплекс с използване на няколко сървъра, при който натоварването, стартирано от DIS, се разпределя между нодовете (т.е. сървърите, които са част от домейна). В случай на такъв вариант, освен разпределението на натоварването в DIS чрез допълнителен слой абстракция GRID, обединяващ няколко нода, на който работи DIS вместо да работи на конкретен един нод, могат да бъдат създадени и допълнителни резервни инстанции на MRS. Може дори да се реализира висока наличност, когато външните запитвания могат да се осъществяват чрез резервни нодовe в случай на отказ на основния. От такъв вариант на изграждане засега се отказахме.
Informatica PowerCenter, схематично
В началните етапи на работа в рамките на веригата за доставки на данни редовно възникваха проблеми, част от тях поради нестабилната в този период работа на Informatica. Смятам да споделя някои от запомнящите се моменти от тази сага — опознаване на Informatica 10.
Предишното лого на Informatica
В сферата на отговорностите на нашето направление влизат и други среди на Informatica, където има специфични особености поради различно натоварване. За момента обаче ще спомена именно как се е развивала Informatica като ETL компонент на самото хранилище за данни.
Как така се случи
През 2016 година, когато започнахме да отговаряме за работата на Informatica, тя вече беше достигнала версия 10.0. За оптимистично настроените колеги, които взеха решение да приложат продукта в сериозно решение с минорна версия .0, всичко изглеждаше очевидно — необходимо беше да се използва новата версия! От гледна точка на хардуерните ресурси всичко беше отлично по това време.
От пролетта на 2016 година работата на Informatica се ръководеше от изпълнител, а според немногобройните потребители на системата "тя работеше няколко пъти в седмицата". Тук е важно да се поясни, че хранилището всъщност беше на етап PoC, нямаше администратори в екипа и системата постоянно падеше по различни причини, след което инженерът от изпълнителя я възстановяваше.
През есента в екипа се присъединиха трима администратори, които разпределиха помежду си сфери на отговорност и започна нормална работа по експлоатацията на системите в проекта, включително и Informatica. Особено важно е да се спомене, че този продукт не е широко разпространен и не разполага с голямо общност, в която да се намерят отговори на всякакви въпроси и да се решат всякакви проблеми. Затова пълната техническа поддръжка от руския партньор на Informatica беше изключително важна, чрез която бяха коригирани всичките ни грешки и грешките на все още младата Informatica 10.
Първото нещо, което трябваше да направим за разработчиците от нашия екип и изпълнителя, беше да стабилизираме работата на самата Informatica и да постигнем работоспособност на уеб конзолата за администриране (Informatica Administrator).
Така често се срещахме с разработчиците на Informatica.
Оставяйки настрана самия процес по изясняване на причините, основната причина за паденията беше схемата на взаимодействие между софтуера Informatica и базата данни на репозитория, която се намираше на сравнително отдалечен, от гледна точка на мрежовия пейзаж, сървър. Това водеше до забавяния и нарушаваше работата на механизмите, осигуряващи контрол на състоянието на домейна Informatica. След известно настройване на базата данни, промени в параметрите на Informatica, които я направиха по-толерантна към забавянията на базата данни, и в крайна сметка актуализиране на версията на Informatica до 10.1 и пренос на базата данни от предишния сървър на сървър, разположен по-близо до Informatica, проблемът загуби актуалност и оттогава не наблюдаваме падения от този вид.
Една от опитите за осигуряване на работа на Informatica Monitor
Състоянието на административната конзола също беше критично. Тъй като активно се разработваше точно в условно продуктивната среда, на колегите постоянно им беше необходимо да анализират работата на mappings и workflow "на ходу". В новата Informatica, в Data Integration Service няма отделен инструмент за такова наблюдение, но в уеб-конзолата за администриране се появи раздел за мониторинг (Informatica Administrator Monitor), в който може да се наблюдава работата на приложенията, workflow и mappings, стартирания, лога. Периодично конзолата ставаше напълно недостъпна, или спираше да актуализира информацията за текущите процеси в DIS, или възникваха грешки при зареждане на страниците.
Избор на java параметри за стабилизиране на работата
Решаването на проблема ставаше по много начини, провеждаха се експерименти с промяна на параметрите, събираха се лога, jstack, изпращаха се в поддръжка, като паралелно се извършваше активно търсене в Google и просто се наблюдаваше.
На първо място, беше създаден отделен MRS за мониторинг, който впоследствие се оказа един от основните консуматори на ресурси в нашите среди, тъй като стартиранията на mappings стават много интензивно. Бяха променени параметрите, относно java heap, и редица други.
В резултат на следващото актуализиране на Informatica 10.1.1 работата на консолата и монитора беше стабилизирана, разработчиците започнаха да работят по-ефективно, а редовните процеси ставаха все по-редовни.
Интересен е опитът от взаимодействието между разработването и администрирането. Общото разбиране за това как всичко работи, какво може да се прави и какво не, винаги е важно при работа със сложни системи. Затова е препоръчително първо да се обучи екипът от администратори как да администрират софтуера, а след това екипът от разработчици как да пишат код и да проектират процесите в системата, и едва тогава да се изпратят първите и вторите да работят за постигане на резултати. Това е наистина важно, когато времето не е безкраен ресурс. Много проблеми могат да се решат дори случайно чрез проба и грешка, но понякога за някои от тях са необходими предварителни знания – нашият случай потвърдва важността на разбирането на тази аксиома.
Например, при опит да включим версия в MRS (както се оказа, необходима беше друга версия на SVN), след известно време с тревога открихме, че времето за рестарт на системата беше нараснало до няколко десетки минути. След като установихме причината за закъснението и изключихме версията, всичко стана отново наред.
Сред значителните препятствия, свързани с Informatica, можем да споменем епичната борба с нарастващите Java потоци. В определен момент дойде времето за тиражиране, тоест за разпространение на наложените процеси на голям брой системи източници. При това се оказа, че не всички процеси в 10.1.1 работят добре и след известно време DIS ставаше неработоспособен. Откриваха се десетки хиляди потоци, а техният брой нарастваше особено забележимо по време на процедурата по разгръщане на приложения. Понякога се налагаше да правим рестарт няколко пъти на ден, за да възстановим работоспособността.
Тук трябва да благодарим на поддръжката, проблемите бяха сравнително бързо локализирани и решени с помощта на EBF (Emergency Bug Fix) – след това у всички възникна усещането, че инструментът наистина функционира.
Той все пак работи!
Към момента на началото на работата в целевия режим, Informatica изглеждаше по следния начин. Версия на Informatica 10.1.1HF1 (HF1 е HotFix1, вендорска сборка от комплекса EBF) с допълнително инсталирани EBF, коригиращи нашите проблеми с мащабирането и някои други, на един от трите сървъра, включени в GRID, 20 ядра x86_64 и хранилище на огромен, бавен масив от локални дискове — това конфигурация на сървъра за Hadoop клъстер. На друг такъв сървър – СУБД Oracle, с която работи и домейнът Informatica, и управляващият механизъм ETL. Всичко това се наблюдава с наличните средства за мониторинг, използвани в екипа (Zabbix + Grafana), от две страни – самата Informatica с нейните услуги и процесите на зареждане, които протичат в нея. В момента производителността и стабилността на работа, без да се включват външните фактори, зависи от настройките, които ограничават натоварването.
Отделно може да се каже за GRID. Средата беше изградена на три възела, с възможност за баланс на натоварването. Въпреки това, при тестване беше установено, че поради проблеми с взаимодействието между стартираните примери на нашите приложения такава конфигурация не работи по очаквания начин, и временно решихме да се откажем от тази схема на строеж, извеждайки два от трите възела от домейна. Въпреки това самата схема остана същата, и в момента това е именно GRID-сервис, но намален до един възел.
В момента остава сложност, свързана с падането на производителността при регулярното почистване на схемата на монитора – при едновременно протичане на процеси в ЧНН и стартирано почистване, могат да възникват сривове в работата на управляващия механизъм ETL. Понастоящем това се решава по 'костилест' начин — ръчно почистване на схемата на монитора, с загуба на всички предишни данни. Това не е твърде критично за продукцията, при нормално штатно функциониране, но в момента се търси нормално решение.
От тази ситуация произлиза и още един проблем – понякога се случват многократни стартирания на нашия управляващ механизъм.
Многократни стартирания на приложението, водещи до повреда на механизма
При стартиране по график в моменти на голямо натоварване на системата понякога възникват такива ситуации, които водят до повреда на механизма. Досега проблемът се коригира ръчно, като се търси постоянно решение.
В общи линии, може да се обобщи, че при високо натоварване е изключително важно да се предоставят адекватни ресурси, което важи както за хардуерните ресурси на самата Informatica, така и за нейната база данни, и да се осигурят оптимални настройки за тях. Освен това остава неясен въпросът коя схема за разположение на базата данни е по-добра — на отделен хост или на същия, на който работи софтуерът Informatica. От една страна, на един сървър ще излезе по-евтино и при съвместяване практически ще се премахне възможният проблем с мрежовото взаимодействие, от друга — натоварването на хоста от базата данни се допълва от натоварването от Informatica.
Както и в всеки сериозен продукт, в Informatica има и куриозни моменти.
Един път, изследвайки някаква авария, забелязах, че в логовете MRS странно е отбелязано времето на събитията.
Времеви дуализъм в логовете MRS “по проект”
Оказа се, че времевите печати се записват във формат от 12 часа, без да се указва AM/PM, т.е. преди или след обяд. Беше подаден дори билет по този въпрос и получен официален отговор — точно така е било замислено, че обозначенията в логовете MRS се записват в такъв формат. Така остава понякога малко интрига относно времето на възникване на някаква ГРЕШКА…
Стремеж към най-доброто
Днес Informatica е достатъчно стабилен инструмент, удобен за администратора и потребителите, изключително мощен по текущите си възможности и потенциал. Той многократно надхвърля функционално нашите нужди и в момента се използва в проекта по начин, който не е най-характерен и типичен. Трудностите частично са свързани с начина, по който работят механизмите — спецификата е, че за кратък период от време се стартира голям брой потоци, които интензивно обновяват параметър сетовете и работят с базата данни на хранилището, като в същото време хардуерните ресурси на сървъра сеUtilizirат почти напълно.
Сега сме на прага на преминаването към Informatica 10.2.1 или 10.2.2, в които са преработени някои вътрешни механизми, и поддръжката обещава да премахне редица текущо съществуващи проблеми с производителността и функционирането. Освен това от хардуерна гледна точка се очакват сървъри в оптимална за нас конфигурация, като се вземе предвид резерв от близко бъдеще поради растежа и развитието на хранилището.
Разбира се, предстои тестване, проверка на съвместимостта и е възможно архитектурни изменения в частта за HA GRID. Развитието в рамките на Informatica ще продължи, тъй като в краткосрочен план не можем да заменим системата с нещо друго.
И тези, които в бъдеще ще отговарят за тази система, със сигурност ще успеят да я доведат до необходимите показатели за надеждност и производителност, изисквани от клиентите.
Статията е подготвена от екипа по управление на данни на „Ростелеком“
Актуален логотип на Informatica
Източник: habr.com
