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, реализиращи нейните услуги:
Домейн, по същество това е основата за всичко останало, в рамките на домейна работят услуги, потребители и компоненти на GRID.
Administrator Console, уеб инструмент за управление и мониторинг, освен клиента Informatica Developer, основният инструмент за взаимодействие с продукта
MRS, Model Repository Service, хранилище на метаданни, представлява прослойка между базата, в която метаданните физически се съхраняват, и клиента Informatica Developer, в който се извършва разработка. Репозиториите съхраняват както описание на данните, така и друга информация, включително за редица други услуги на Informatica, например, графиците за стартиране на задания (Schedules) или данните за мониторинг, както и параметрични набори на приложенията, които по-специално позволяват използването на едно и също приложение за работа с различни източници и приемници на данни.
DIS, Data Integration Service, това е услуга, в която протичат основните функционални процеси, в нея работят приложенията и се извършват самите стартирания на Workflows (описания на последователността на mappings и тяхното взаимодействие) и Mappings (трансформации, блокове, в които протичат самите преобразования, обработка на данни).
Конфигурация GRID – по същество, вариант на изграждане на комплекс с използване на няколко сървъра, когато натоварването, генерирано от DIS, се разпределя между нодовете (тоест сървърите, включени в състава на домейна). В случая на такъв вариант, освен разпределението на натоварването в DIS чрез допълнителен слой абстракция GRID, обединяващ няколко нода, на който и работи DIS вместо работа на конкретен един нод, могат да бъдат създадени и допълнителни резервни екземпляри на MRS. Може дори да се реализира висока наличност, когато външните обращения могат да се извършват чрез резервни ноды при отказ на основната. От този вариант на изграждане ние все още се отказахме.
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 е достатъчно стабилен инструмент, удобен за администратора и потребителите, изключително мощен в съвременните възможности и потенциал. Той многократно надхвърля функциите на нашите нужди и де факто в момента се използва в проекта по начин, който не е напълно характерен и типичен. Трудностите отчасти са свързани с начина, по който работят механизмите — спецификата е, че за кратък период от време се стартират много потоци, които интензивно актуализират параметрите и работят с базата данни, докато хардуерните ресурси на сървъра практически се използват напълно от ЦПУ-то.
Сега сме на крачка да преминем на Informatica 10.2.1 или 10.2.2, в които са преработени някои вътрешни механизми, а поддръжката обещава да няма множество от текущите ни проблеми с производителността и функционирането. Освен това, от хардуерна перспектива се очакват сървъри с оптимална конфигурация за нас, имайки предвид наличностите за близкото бъдеще поради растежа и развитието на хранилището.
Разбира се, предстои тестване, проверка на съвместимост и възможни архитектурни промени в частта на HA GRID. Развитието в рамките на Informatica ще продължи, тъй като в краткосрочен план не можем да внедрим нещо като заместител на системата.
А тези, които в бъдеще ще отговарят за тази система, определено ще успеят да я доведат до необходимите показатели за надеждност и производителност, поставени от клиентите.
Статията е подготвена от екипа за управление на данни на "Ростелеком"
Актуален логотип на Informatica
Източник: habr.com
