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.
Кансоль адміністратара, web-інструмент кіравання і маніторынгу, акрамя кліента Informatica Developer, асноўны інструмент для ўзаемадзеяння з прадуктам
MRS, Model Repository Service, сховішча метададзеных, уяўляе сабой праслойку паміж базай, у якой метададзеныя захоўваюцца фізічна, і кліентам Informatica Developer, у якім ідзе распрацоўка. Рэпазітары захоўваюць і апісанне дадзеных, і іншую інфармацыю, у тым ліку, для шэрагу іншых сэрвісаў Infromatica, напрыклад, расклад запускаў заданняў (Schedules) або дадзеныя маніторынгу, а таксама parameterset'ы прыкладанняў, у прыватнасці якія дазваляюць выкарыстоўваць адно і тое ж прыкладанне для працы з рознымі крыніцамі і прымачамі даных.
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, з дапамогай якога і выпраўляліся ўсе нашы памылкі і памылкі маладой яшчэ тады Informatca 10.
Першае, што нам прыйшлося рабіць для распрацоўшчыкаў нашай каманды і падрадчыка – стабілізаваць працу самой Informatica, дамагчыся працаздольнасці web-кансолі адміністравання (Informatica Administrator).
Так у нас часцяком сустракала распрацоўшчыкаў Informatica
Пакінуўшы за рамкамі сам працэс высвятлення прычын, асноўнай прычынай падзенняў была схема ўзаемадзеяння ПЗ Informatica з БД рэпазітара, якая знаходзілася на параўнальна выдаленым, з пункту гледжання сеткавага ландшафту, серверы. Гэта прыводзіла да затрымак і парушала працу механізмаў, якія забяспечваюць кантроль стану дамена Informatica. Пасля некаторага цюнінгу БД, змены параметраў Informatica, якія зрабілі яе больш талерантнай да затрымак БД, а ў выніку абнаўленні версіі Informatica да 10.1 і пераносу БД з папярэдняга сервера, на сервер размешчаны бліжэй да Informatica, праблема страціла актуальнасць, і з тых часоў падзенняў падобнага роду мы не назіраем.
Адна са спроб дамагчыся працы Informatica Monitor
З кансоллю адміністравання сітуацыя таксама была крытычнай. Паколькі ішла актыўная распрацоўка прама на ўмоўна прадуктыўным асяроддзі, калегам стала было неабходна аналізаваць працу mappings, workflow "на ходу". У новай Informatica, у Data Integration Service няма асобнай прылады для такога маніторынгу, але ў web-кансолі адміністравання з'явіўся падзел маніторынгу (Informatica Administrator Monitor), у якім можна назіраць працу прыкладанняў, workflow і mappings, запускі, логі. Перыядычна кансоль станавілася недаступнай цалкам, альбо пераставалі абнаўляцца звесткі аб бягучых працэсах у DIS, альбо ўзнікалі памылкі пры загрузцы старонак.
Падбор параметраў java для стабілізацыі працы
Выпраўленне праблемы ішло шматлікімі шляхамі, праводзіліся эксперыменты па змене параметраў, збіраліся логі, jstack, адпраўляліся ў падтрымку, раўналежна ішло актыўнае гугление і проста вялося назіранне.
У першую чаргу быў створаны асобны 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 “by design”
Аказалася, што часовыя пазнакі пішуцца ў фармаце 12 гадзін, без указання AM/PM, гэта значыць да поўдня ці пасля. Была нават адкрыта заяўка з гэтай нагоды, і атрыманы афіцыйны адказ - так і было задумана, у лог MRS адзнакі пішуцца менавіта ў такім фармаце. Гэта значыць, застаецца часам некаторая інтрыга адносна часу ўзнікнення якога-небудзь ERROR-а…
Імкнуцца да лепшага
Сёння Informatica - гэта досыць стабільны інструмент, зручны для адміністратара і карыстальнікаў, надзвычай магутны па бягучых магчымасцях і патэнцыялу. Ён шматкроць перавышае функцыянальна нашы патрэбы і дэ-факта зараз выкарыстоўваецца ў праекце не самым характэрным і тыпавым чынам. Складанасці збольшага звязаныя з тым, як працуюць механізмы – спецыфіка ў тым, што за кароткі прамежак часу запускаецца вялікая колькасць патокаў, якія інтэнсіўна абнаўляюць parameterset'ы і працуюць з БД рэпазітара, пры гэтым апаратныя рэсурсы сервера ўтылізуюцца па ЦПУ практычна цалкам.
Цяпер мы ўшчыльную падышлі да пераходу на Informatica 10.2.1 або 10.2.2, у якіх перапрацаваны некаторыя ўнутраныя механізмы, і падтрымка абяцае адсутнасць шэрагу цяпер наяўных у нас праблем з прадукцыйнасцю і функцыянаванню. Ды і з апаратнага пункта гледжання чакаюцца серверы аптымальнай для нас канфігурацыі, улічваючы запас на бліжэйшы час з прычыны росту і развіцця сховішча.
Само сабой, маецца быць тэсціраванне, праверка сумяшчальнасці, і магчыма, архітэктурныя змены ў частцы HA GRID. Развіццё ў рамках Informatica будзе ісці, паколькі ў кароткатэрміновай перспектыве нешта паставіць на замену сістэме мы не можам.
І тыя, хто ў далейшым будуць адказваць за дадзеную сістэму, абавязкова здолеюць давесці яе да патрабаваных паказчыкаў надзейнасці і прадукцыйнасці якія высоўваюцца заказчыкамі.
Артыкул падрыхтаваны камандай кіравання дадзенымі «Ростелекома»
Актуальны лагатып Informatica
Крыніца: habr.com