ЕТЛ компонента складишта података је често у сенци самог складишта и добија мање пажње него главна база података или фронт-енд компонента, БИ и извештавање. Истовремено, са становишта механике пуњења складишта подацима, ЕТЛ игра кључну улогу и захтева ништа мање пажње од администратора него друге компоненте. Зовем се Александар, сада администрирам ЕТЛ у Ростелекому, а у овом чланку ћу покушати да поделим нешто од онога са чиме треба да се бави администратор једног од најпознатијих ЕТЛ система у великом складишту података у Ростелекому.
Ако су драги читаоци већ уопштено упознати са нашим пројектом складишта података и са производом Информатица ПоверЦентер, онда можете одмах да пређете на следећи одељак.
Пре неколико година, идеја о јединственом складишту корпоративних података сазрела је и почела да се спроводи у Ростелекому. Већ је створен велики број репозиторија који су решавали појединачне проблеме, али је број сценарија растао, трошкови подршке су такође порасли и постало је јасно да је будућност у централизацији. Архитектонски, ово је сама меморија, која се састоји од неколико слојева, имплементираних на Хадооп и ГреенПлум, помоћних база података, ЕТЛ механизама и БИ.
Истовремено, због великог броја географски распоређених, хетерогених извора података, створен је посебан механизам за уплоад података чији рад контролише Информатица. Као резултат тога, пакети података завршавају у области Хадооп интерфејса, након чега почињу процеси учитавања података кроз меморијске слојеве, Хадооп и ГреенПлум, а њима управља такозвани ЕТЛ контролни механизам имплементиран у Информатици. Дакле, систем Информатица је један од кључних елемената који обезбеђује рад складишта.
Више детаља о нашем складишту биће речи у једном од следећих постова.
Информатица ПоверЦентер/Биг Дата Манагемент се тренутно сматра водећим софтвером у области алата за интеграцију података. Ово је производ америчке компаније Информатица, која је један од најјачих играча у ЕТЛ (Ектрацт Трансформ Лоад), управљању квалитетом података, МДМ (Мастер Дата Манагемент), ИЛМ (Информатион Лифецицле Манагемент) и још много тога.
ПоверЦентер који користимо је интегрисани Томцат сервер апликација у којем се покрећу саме Информатица апликације, имплементирајући своје услуге:
Домен, у ствари, ово је основа за све остало; услуге, корисници и ГРИД компоненте раде унутар домена.
Администраторска конзола, алат за управљање и праћење на вебу, поред клијента Информатица Девелопер, главног алата за интеракцију са производом
МРС, Служба за складиште модела, спремиште метаподатака, је слој између базе података у којој се метаподаци физички чувају и клијента Информатица Девелопер у којем се одвија развој. Репозиторијуми чувају описе података и друге информације, укључујући и за бројне друге услуге Инфроматица, на пример, распореде за извршавање задатака (распоред) или податке надгледања, као и параметре апликације, посебно, омогућавајући коришћење исте апликације за рад са разни извори података и пријемници.
ДИС, Служба за интеграцију података, ово је сервис у којем се одвијају главни функционални процеси, у њему се покрећу апликације и стварна покретања токова рада (описи редоследа пресликавања и њихових интеракција) и мапирања (трансформације, блокови у којима се саме трансформације дешавају, обрада података ) узети место.
ГРИД конфигурација – у суштини, опција за изградњу комплекса коришћењем више сервера, када се оптерећење које покреће ДИС распоређује на чворове (односно сервере који су део домена). У случају ове опције, поред расподеле оптерећења у ДИС-у преко додатног слоја ГРИД апстракције који обједињује неколико чворова, на којима ДИС ради уместо да ради на одређеном једном чвору, могу се креирати и додатне резервне МРС инстанце. Можете чак применити и високу доступност, где се спољни позиви могу упутити преко резервних чворова ако главни не успе. За сада смо напустили ову опцију изградње.
Информатица ПоверЦентер, шема
У раним фазама рада у оквиру ланца снабдевања подацима редовно су се јављали проблеми, неки од њих због нестабилног рада Информатике у то време. Поделићу са вама неке од незаборавних тренутака ове саге - савладавање Информатике 10.
Некадашњи лого Информатике
У нашу област одговорности спадају и друга Информатица окружења, она имају своје специфичности због другачијег оптерећења, али за сада ћу се сетити како се тачно Информатица развијала као ЕТЛ компонента самог складишта података.
Како се то догодило
2016. године, када смо постали одговорни за рад Информатике, она је већ достигла верзију 10.0, а оптимистичним колегама који су се одлучили да производ са мањом верзијом .0 користе у озбиљном решењу, све је изгледало очигледно – треба да користимо нова верзија! Са становишта хардверских ресурса, тада је све било у реду.
Од пролећа 2016. године за рад Информатике задужен је извођач радова, који је, према речима малобројних корисника система, „радио пар пута недељно“. Овде је потребно разјаснити да је спремиште де фацто било у фази ПоЦ-а, није било администратора у тиму и систем је константно падао из разних разлога, након чега га је инжењер извођача поново покупио.
На јесен су се тиму придружила три администратора, који су међусобно поделили своје области одговорности и почео је нормалан рад на организовању рада система у пројекту, укључујући и Информатику. Посебно треба рећи да овај производ није широко распрострањен и да има велику заједницу у којој можете пронаћи одговоре на сва питања и ријешити било који проблем. Због тога је била веома важна пуна техничка подршка руског партнера Информатике, уз помоћ које су исправљене све наше грешке и грешке тада младе Информатике 10.
Прво што смо морали да урадимо за програмере нашег тима и извођача радова било је да стабилизујемо рад саме Информатице, да обезбедимо функционалност веб администрацијске конзоле (Информатица Администратор).
Тако смо се често сретали са програмерима Информатике
Остављајући по страни процес откривања разлога, главни разлог кварова био је образац интеракције софтвера Информатица са базом података репозиторија, која се налазила на релативно удаљеном серверу, са становишта мрежног пејзажа. То је изазвало кашњења и пореметило механизме који прате стање домена Информатица. Након одређеног подешавања базе података, промене параметара Информатице, што је учинило толерантнијом на кашњење базе података, и на крају ажурирања верзије Информатице на 10.1 и преноса базе података са претходног сервера на сервер који се налази ближе Информатици, проблем је изгубио своју релевантност, и од тада је било падова ове врсте које не примећујемо.
Један од покушаја да Информатица Монитор проради
Критична је била и ситуација са административном конзолом. Пошто је активан развој био у току директно у релативно продуктивном окружењу, колеге су стално морале да анализирају рад мапирања и тока посла „у покрету“. У новој Информатици, Сервис за интеграцију података нема посебан алат за такво праћење, али се у административној веб конзоли (Информатица Администратор Монитор) појавио одељак за праћење у којем можете пратити рад апликација, ток рада и мапирања, лансирања, евиденције. Периодично је конзола постала потпуно недоступна, или су информације о тренутним процесима у ДИС-у престајале да се ажурирају или је долазило до грешака при учитавању страница.
Избор јава параметара за стабилизацију перформанси
Проблем је исправљен на много начина, вршени су експерименти за промену параметара, прикупљани су логови и јстацк, слати на подршку, истовремено је било активног гуглања и једноставног посматрања.
Пре свега, направљена је засебна МРС за праћење, како се касније испоставило, ово је један од главних потрошача ресурса у нашим срединама, пошто се мапирања покрећу веома интензивно. Параметри који се односе на јава хеап и низ других су промењени.
Као резултат тога, до следећег ажурирања Информатица 10.1.1, рад конзоле и монитора је стабилизован, програмери су почели да раде ефикасније, а редовни процеси су постајали све редовнији.
Искуство интеракције између развоја и администрације може бити занимљиво. Питање општег разумевања како ствари функционишу, шта се може, а шта не може, увек је важно када се користе сложени системи. Стога можемо са сигурношћу препоручити да прво обучите административни тим како да администрира софтвер, а развојни тим како да пише код и црта процесе у систему, па тек онда пошаљете првог и другог да раде на резултату. Ово је заиста важно када време није бесконачан ресурс. Многи проблеми се могу решити чак и насумичним претраживањем опција, али понекад је за неке потребно а приори знање - наш случај потврђује важност разумевања овог аксиома.
На пример, када смо покушали да омогућимо верзионисање у МРС-у (како се на крају испоставило, била је потребна другачија верзија СВН-а), после неког времена смо узнемирени открили да се време поновног покретања система повећало на неколико десетина минута. Пронашли смо разлог за кашњење у старту и онемогућили верзионисање, поново смо добро прошли.
Значајне препреке повезане са Информатицом укључују епску битку са растућим јава нитима. У неком тренутку је дошло време за репликацију, односно проширење успостављених процеса на велики број изворних система. Испоставило се да нису сви процеси у 10.1.1 добро функционисали, а након неког времена ДИС је постао неоперативан. Детектоване су десетине хиљада нити, а њихов број је посебно растао током процедуре постављања апликације. Понекад сам морао да рестартујем неколико пута дневно да бих вратио функционалност.
Овде треба да се захвалимо подршци; проблеми су релативно брзо локализовани и отклоњени помоћу ЕБФ-а (Емергенци Буг Фик) – након тога су сви стекли осећај да алат заиста ради.
И даље ради!
У време када смо почели да радимо у циљном режиму, Информатица је изгледала овако. Верзија Информатице 10.1.1ХФ1 (ХФ1 је ХотФик1, вендорски склоп из комплекса ЕБФ-ова) са додатно инсталираним ЕБФ-ом, који исправља наше проблеме са скалирањем и неке друге, на једном од три сервера који су били део ГРИД-а, 20 к86_64 језгара и складиште, на огромном спором низу локалних дискова - ово је конфигурација сервера за Хадооп кластер. На другом сличном серверу – Орацле ДБМС са којим раде и домен Информатица и ЕТЛ контролни механизам. Све ово прати стандардни алати за праћење који се користе у тиму (Заббик + Графана) са обе стране - сама Информатица са својим сервисима, и процеси учитавања који улазе у њу. Сада и перформансе и стабилност, без узимања у обзир спољних фактора, сада зависе од подешавања која ограничавају оптерећење.
Одвојено, можемо рећи о ГРИД-у. Окружење је изграђено на три чвора, са могућношћу балансирања оптерећења. Међутим, током тестирања је откривено да због проблема у интеракцији између покренутих инстанци наших апликација, ова конфигурација није функционисала како се очекивало, па су одлучили да привремено напусте ову шему конструкције, уклањајући два од три чвора из домена. Истовремено, сама шема је остала иста, и сада је то управо ГРИД услуга, али дегенерисана на један чвор.
Тренутно, потешкоћа остаје повезана са падом перформанси при редовном чишћењу круга монитора - са истовременим процесима у ЦНН-у и активним чишћењем, може доћи до кварова у раду ЕТЛ контролног механизма. Ово се тренутно решава „као штака“ - ручним брисањем кола монитора, уз губитак свих његових претходних података. Ово није превише критично за продуктивност, током нормалног рутинског рада, али за сада је у току потрага за нормалним решењем.
Још један проблем произилази из исте ситуације - понекад долази до вишеструких покретања нашег контролног механизма.
Вишеструко покретање апликација доводи до отказивања механизма
Када се ради по распореду, у време великог оптерећења система, понекад се дешавају ситуације које доводе до квара механизма. Проблем се и даље решава ручно и тражи се трајно решење.
Уопштено говорећи, можемо да резимирамо да је при великом оптерећењу веома важно обезбедити ресурсе адекватне за то, то се односи и на хардверске ресурсе за саму Информатику, а исто тако и за њено складиште базе података, као и да обезбеди оптимална подешавања за њих. Осим тога, остаје отворено питање која је шема постављања базе података боља - на засебном хосту или на истом на коме ради софтвер Информатица. С једне стране, биће јефтиније на једном серверу, а када се комбинује, могући проблем са мрежном интеракцијом је практично елиминисан, с друге стране, оптерећење хоста из базе података се допуњава оптерећењем од Информатике.
Као и код сваког озбиљног производа, Информатица има и смешних момената.
Једном, док сам решавао некакву несрећу, приметио сам да је у записницима МРС-а чудно назначено време догађаја.
Темпорални дуализам у МРС евиденцијама „по дизајну“
Испоставило се да се временске ознаке пишу у формату од 12 сати, без навођења АМ/ПМ, односно пре подне или после. Чак је отворена и пријава по овом питању, а добијен је и званичан одговор - тако је и замишљено, у дневнику МРС-а се уписују оцене управо у овом формату. Односно, понекад остане нека интрига око времена настанка неке ГРЕШКЕ...
Тежите најбољем
Данас је Информатица прилично стабилан алат, погодан за администраторе и кориснике, изузетно моћан у погледу својих тренутних могућности и потенцијала. Вишеструко превазилази наше функционалне потребе и де фацто се сада користи у пројекту на начин који није најтипичнији и типичнији. Потешкоће су делимично везане и за начин рада механизама – специфичност је то што се у кратком временском периоду покреће велики број нити које интензивно ажурирају параметре и раде са базом репозиторија, док су хардверски ресурси сервера искоришћени скоро у потпуности. од стране ЦПУ-а.
Сада смо близу преласка на Информатица 10.2.1 или 10.2.2, који су прерадили неке интерне механизме и обећања подршке да ће елиминисати неке проблеме са перформансама и функционалношћу које тренутно имамо. А са хардверске тачке гледишта, очекујемо сервере са оптималном конфигурацијом за нас, узимајући у обзир резерву за блиску будућност због раста и развоја складишта.
Наравно, биће тестирања, провере компатибилности и евентуално архитектонских промена у делу ХА ГРИД. Развој у оквиру Информатике ће се наставити, јер краткорочно не можемо испоручити ништа што би заменило систем.
А они који ће у будућности бити одговорни за овај систем, сигурно ће моћи да га доведу до захтеваних показатеља поузданости и перформанси које постављају купци.
Чланак је припремио тим за управљање подацима Ростелекома
Актуелни лого Информатике
Извор: ввв.хабр.цом