Az adattárház ETL összetevőjét gyakran maga a raktár árnyékolja be, és kevesebb figyelmet kap, mint a fő adatbázis vagy előtér-komponens, a BI és a jelentéskészítés. Ugyanakkor a raktár adatokkal való feltöltésének mechanikája szempontjából az ETL kulcsszerepet játszik, és nem kevesebb figyelmet igényel a rendszergazdáktól, mint a többi komponens. A nevem Alexander, most én adminisztrálom az ETL-t a Rostelecomnál, és ebben a cikkben megpróbálok egy kicsit megosztani, mivel kell megküzdenie a Rostelecom egyik leghíresebb ETL-rendszerének adminisztrátorának egy nagy adattárházában.
Ha a kedves olvasók már általánosságban ismerik adattárház projektünket és az Informatica PowerCenter terméket, akkor azonnal továbbléphet a következő részre.
Néhány évvel ezelőtt az egyetlen vállalati adattárház ötlete érlelődött, és elkezdődött a megvalósítás a Rostelecomban. Az egyedi problémákat megoldó repozitóriumok sora már létrejött, de nőtt a forgatókönyvek száma, nőttek a támogatási költségek is, és egyértelművé vált, hogy a központosításban van a jövő. Építészetileg ez maga a tároló, amely több rétegből áll, Hadoop és GreenPlum felületeken, kiegészítő adatbázisokból, ETL mechanizmusokból és BI-ból.
Ugyanakkor a földrajzilag elosztott, heterogén adatforrások nagy száma miatt egy speciális adatfeltöltési mechanizmus jött létre, melynek működését az Informatica irányítja. Ennek eredményeként az adatcsomagok a Hadoop interfész területére kerülnek, ezt követően megkezdődnek az adatok tárolási rétegeken, Hadoop és GreenPlum keresztül történő betöltésének folyamatai, melyeket az Informaticában implementált úgynevezett ETL vezérlő mechanizmus kezel. Így az Informatica rendszer az egyik kulcselem, amely biztosítja a raktár működését.
Tárhelyünkről bővebben a következő bejegyzések egyikében lesz szó.
Az Informatica PowerCenter/Big Data Management jelenleg a vezető szoftvernek számít az adatintegrációs eszközök területén. Ez az amerikai Informatica cég terméke, amely az egyik legerősebb szereplő az ETL (Extract Transform Load), az adatminőség-menedzsment, az MDM (Master Data Management), az ILM (Information Lifecycle Management) és egyebek területén.
Az általunk használt PowerCenter egy integrált Tomcat alkalmazásszerver, amelyben maguk az Informatica alkalmazások futnak, megvalósítva a szolgáltatásait:
DoménValójában minden másnak ez az alapja, a szolgáltatások, a felhasználók és a GRID összetevők a tartományon belül működnek.
Felügyeleti konzol, egy web alapú felügyeleti és felügyeleti eszköz, az Informatica Developer kliens mellett, amely a termékkel való interakció fő eszköze
MRS, Model Repository Service, egy metaadattár, egy réteg a metaadatokat fizikailag tárolt adatbázis és az Informatica Developer kliens között, amelyben a fejlesztés zajlik. A tárolók adatleírásokat és egyéb információkat tárolnak, beleértve számos más Infromatica szolgáltatáshoz is, például a futó feladatok ütemezését (Ütemezések) vagy a megfigyelési adatokat, valamint az alkalmazás paramétereit, különösen, amelyek lehetővé teszik ugyanazon alkalmazás használatát különböző adatforrások és vevők.
DIS, adatintegrációs szolgáltatás, ez egy olyan szolgáltatás, amelyben a fő funkcionális folyamatok zajlanak, az alkalmazások futnak benne és a Workflow-k (leképezések sorrendjének leírása és interakcióik) és a Mapping-ek (transzformációk, blokkok, amelyekben maguk az átalakítások megtörténnek, adatfeldolgozás) tényleges elindítása ) megtörténik.
GRID konfiguráció – lényegében több szervert használó komplexum felépítésének lehetősége, amikor a DIS által indított terhelés a csomópontok (vagyis a tartomány részét képező szerverek) között oszlik meg. Ennél az opciónál amellett, hogy a DIS-ben a terhelést egy további, több csomópontot egyesítő GRID absztrakciós rétegen keresztül osztják el, amelyen a DIS fut, ahelyett, hogy egy adott csomóponton dolgozna, további tartalék MRS példányok is létrehozhatók. Akár magas rendelkezésre állást is megvalósíthat, ahol külső hívások indíthatók tartalék csomópontokon keresztül, ha a fő meghibásodik. Ettől az építési lehetőségtől egyelőre lemondtunk.
Informatika PowerCenter, sematikus
Az adatszolgáltatási lánc részeként végzett munka kezdeti szakaszában rendszeresen felmerültek problémák, amelyek egy része az Informatika akkori instabil működéséből adódóan. Megosztok néhány emlékezetes pillanatot ebből a sagából – az Informatica 10 elsajátításáról.
Korábbi Informatika logó
Feladatkörünkbe más Informatica környezetek is tartoznak, ezeknek megvannak a sajátosságai az eltérő terhelés miatt, de most pontosan emlékszem, hogyan fejlődött az Informatica magának az adattárháznak az ETL komponenseként.
Hogy történt
2016-ban, amikor az Informatica munkájáért felelõssé váltunk, már elérte a 10.0-s verziót, és az optimista kollégáknak, akik úgy döntöttek, hogy egy kisebb .0-ás verziójú terméket komoly megoldásban használnak, minden magától értetõdõnek tûnt - használnunk kell az új verzió! A hardver erőforrások szempontjából akkoriban minden rendben volt.
2016 tavasza óta egy vállalkozó felel az Informatika munkájáért, és a rendszer kevés felhasználója szerint „hetente párszor működött”. Itt tisztázni kell, hogy az adattár de facto a PoC szakaszban volt, nem voltak adminisztrátorok a csapatban, és a rendszer különböző okok miatt folyamatosan összeomlott, ami után a kivitelező mérnöke újra felvette.
Ősszel három adminisztrátor csatlakozott a csapathoz, felosztották egymás között a felelősségi köröket, és megkezdődött a normál munka a projektben szereplő rendszerek, köztük az Informatika működésének megszervezésében. Külön meg kell mondani, hogy ez a termék nem elterjedt, és nagy közösséggel rendelkezik, amelyben minden kérdésre választ találhat, és bármilyen problémát megoldhat. Ezért nagyon fontos volt az orosz Informatica partner teljes körű technikai támogatása, melynek segítségével az akkor még fiatal Informatica 10 minden hibáját és hibáját kijavították.
Csapatunk fejlesztőinek és a kivitelezőnek az első dolgunk volt magának az Informatica munkájának stabilizálása, a webes adminisztrációs konzol (Informatica Administrator) működőképességének biztosítása.
Így találkoztunk gyakran az Informatica fejlesztőivel
Az okok felderítésétől eltekintve a leállások fő oka az Informatica szoftver interakciós mintázata volt a tároló adatbázissal, amely a hálózati környezet szempontjából viszonylag távoli szerveren volt. Ez késéseket okozott, és megzavarta az Informatica tartomány állapotát figyelő mechanizmusokat. Az adatbázis némi tuningolása, az Informatica paramétereinek megváltoztatása, amivel jobban tolerálta az adatbázis késéseket, végül az Informatica verzió 10.1-re való frissítése és az adatbázis átvitele az előző szerverről az Informaticához közelebb található szerverre, a probléma megszűnt. relevanciája, és azóta voltak ilyen jellegű összeomlások, amelyeket nem figyelünk meg.
Az egyik kísérlet az Informatika Monitor működésbe hozására
Az adminisztrációs konzol helyzete is kritikus volt. Mivel az aktív fejlesztés közvetlenül a viszonylag produktív környezetben zajlott, a kollégáknak folyamatosan „menet közben” kellett elemezniük a leképezések és a munkafolyamatok munkáját. Az új Informaticában az Adatintegrációs Szolgáltatásnak nincs külön eszköze az ilyen felügyeletre, de az adminisztrációs webkonzolban megjelent egy felügyeleti rész (Informatica Administrator Monitor), amelyben az alkalmazások működését, a munkafolyamatokat és a leképezéseket lehet nyomon követni, elindítja, naplózza. Időnként a konzol teljesen elérhetetlenné vált, vagy a DIS aktuális folyamataira vonatkozó információk frissítése leállt, vagy hibák léptek fel az oldalak betöltésekor.
Java paraméterek kiválasztása a teljesítmény stabilizálása érdekében
A problémát sokféleképpen kijavították, kísérleteket végeztek a paraméterek megváltoztatására, naplókat és jstack-et gyűjtöttek, elküldték a támogatásnak, ugyanakkor aktív guglizás és egyszerű megfigyelés zajlott.
Mindenekelőtt külön MRS-t hoztak létre a monitorozáshoz, amely, mint később kiderült, ez az egyik fő erőforrás-fogyasztó környezetünkben, hiszen a leképezések nagyon intenzíven indulnak. A java kupac és számos más paraméterek megváltoztak.
Ennek eredményeként a következő Informatica 10.1.1 frissítéssel a konzol és a monitor működése stabilizálódott, a fejlesztők hatékonyabban kezdtek dolgozni, a szabályos folyamatok pedig egyre rendszeresebbek lettek.
Érdekes lehet a fejlesztés és az adminisztráció közötti interakció tapasztalata. A dolgok működésének általános megértésének kérdése, mit lehet tenni és mit nem, mindig fontos összetett rendszerek használatakor. Ezért nyugodtan javasolhatjuk, hogy először az adminisztratív csapatot képezze ki a szoftver adminisztrálására, a fejlesztő csapatot pedig a kódírásra és a folyamatok rajzolására a rendszerben, és csak ezután küldje el az elsőt és a másodikat, hogy dolgozzanak az eredményen. Ez nagyon fontos, ha az idő nem végtelen erőforrás. Sok probléma még véletlenszerű kereséssel is megoldható, de néha néhányhoz előzetes tudásra van szükség – esetünk megerősíti ennek az axiómának a megértésének fontosságát.
Például, amikor megpróbáltuk engedélyezni a verziókezelést az MRS-ben (mint a végén kiderült, az SVN másik verziójára volt szükség), egy idő után megriadva tapasztaltuk, hogy a rendszer újraindítási ideje több tíz percre nőtt. Miután megtaláltuk az indítás késésének okát és letiltottuk a verziót, ismét jól jártunk.
Az Informaticával kapcsolatos figyelemre méltó akadályok közé tartozik a növekvő java szálak elleni epikus küzdelem. Valamikor elérkezett az ideje a replikációnak, vagyis a kialakult folyamatok kiterjesztésének számos forrásrendszerre. Kiderült, hogy a 10.1.1-ben nem minden folyamat működött jól, és egy idő után a DIS működésképtelenné vált. Több tízezer szálat észleltek, számuk különösen észrevehetően nőtt az alkalmazástelepítési eljárás során. Néha naponta többször is újra kellett indítanom a működőképesség helyreállításához.
Ezúton is köszönjük a támogatást, az EBF (Emergency Bug Fix) segítségével viszonylag gyorsan sikerült lokalizálni és kijavítani a problémákat – ezek után mindenki azt érezte, hogy az eszköz tényleg működik.
Még mindig működik!
Mire elkezdtünk cél üzemmódban dolgozni, az Informatika így nézett ki. Az Informatica 10.1.1HF1 verziója (a HF1 a HotFix1, az EBF-ek komplexumából származó gyártói összeállítás) kiegészítő telepített EBF-fel, amely kijavítja a méretezéssel és néhány mással kapcsolatos problémáinkat, a GRID részét képező három szerver közül egyen, 20 x86_64 mag és tárhely, a helyi lemezek hatalmas, lassú tömbjén – ez a Hadoop-fürt szerverkonfigurációja. Egy másik hasonló szerveren - az Oracle DBMS-en, amellyel az Informatica tartomány és az ETL vezérlő mechanizmus is működik. Mindezt a csapatban használt szabványos monitorozó eszközök (Zabbix + Grafana) figyelik mindkét oldalon - maga az Informatika szolgáltatásaival, illetve a betöltési folyamatokkal. Most már mind a teljesítmény, mind a stabilitás – külső tényezők figyelembevétele nélkül – a terhelést korlátozó beállításoktól függ.
Külön elmondhatjuk a GRID-ről. A környezet három csomópontra épült, terheléselosztás lehetőségével. A tesztelés során azonban kiderült, hogy az alkalmazásaink futó példányai közötti interakciós problémák miatt ez a konfiguráció nem a várt módon működött, ezért úgy döntöttek, hogy ideiglenesen felhagynak ezzel az építési sémával, eltávolítva a három csomópont közül kettőt a tartományból. Ugyanakkor maga a séma ugyanaz maradt, és most már pontosan egy GRID szolgáltatás, de egy csomópontig degenerálódott.
Jelenleg a nehézség továbbra is a teljesítmény csökkenésével jár a monitoráramkör rendszeres tisztítása során - a CNN egyidejű folyamatai és a tisztítási folyamat során az ETL vezérlőmechanizmus működési zavarai léphetnek fel. Ezt jelenleg „mankóként” oldják meg – a monitor áramkörének manuális törlésével, minden korábbi adat elvesztésével. Ez nem túl kritikus a termelékenység szempontjából, normál rutinüzem közben, de egyelőre a normál megoldás keresése folyik.
Ugyanebből a helyzetből egy másik probléma is adódik – néha előfordul, hogy vezérlő mechanizmusunk többször is elindul.
Több alkalmazás elindul, ami a mechanizmus meghibásodásához vezet
Ha ütemterv szerint működik, a rendszer nagy terhelése esetén néha előfordulnak olyan helyzetek, amelyek a mechanizmus meghibásodásához vezetnek. A problémát továbbra is manuálisan javítják, és állandó megoldást keresnek.
Általánosságban elmondható, hogy nagy terhelés esetén nagyon fontos a megfelelő erőforrások biztosítása, ez vonatkozik magának az Informaticának a hardver erőforrásaira is, és ugyanez vonatkozik az adatbázis tárolójára is, valamint az optimális beállítások biztosítására. nekik. Emellett továbbra is nyitva marad a kérdés, hogy melyik adatbázis-elhelyezési séma a jobb - külön gazdagépen, vagy ugyanazon, ahol az Informatica szoftver fut. Egyrészt olcsóbb lesz egy szerveren, és kombinálva gyakorlatilag megszűnik a hálózati interakció esetleges problémája, másrészt az adatbázisból érkező gazdagép terhelése kiegészül az Informaticától érkező terheléssel.
Mint minden komoly terméknél, az Informaticának is vannak vicces pillanatai.
Egyszer valami baleset rendezése közben észrevettem, hogy az MRS naplói furcsán jelzik az események idejét.
Időbeli dualizmus az MRS-naplókban „tervezés szerint”
Kiderült, hogy az időbélyegeket 12 órás formátumban írják, de nem / délelőtt, azaz dél előtt vagy után. Ezzel kapcsolatban még pályázatot is nyitottak, és hivatalos válasz is érkezett - így volt szándékozva, az MRS-naplóba pontosan ebben a formátumban írják a jegyeket. Vagyis néha marad némi intrika valamilyen HIBA bekövetkezésének időpontját illetően...
Törekedj a legjobbra
Ma az Informatica egy meglehetősen stabil eszköz, kényelmes az adminisztrátorok és a felhasználók számára, rendkívül erős a jelenlegi képességeit és potenciálját tekintve. Funkcionális igényeinket többszörösen meghaladja, és de facto ma már nem a legjellemzőbb és legtipikusabb módon kerül felhasználásra a projektben. A nehézségek részben a mechanizmusok működésével kapcsolatosak - az a sajátosság, hogy rövid időn belül nagyszámú szál indul el, amelyek intenzíven frissítik a paramétereket és dolgoznak a repository adatbázissal, miközben a szerver hardver erőforrásait szinte teljesen kihasználják. a CPU által.
Közel állunk az Informatica 10.2.1-es vagy 10.2.2-es verziójára való átálláshoz, amelyek átdolgoztak néhány belső mechanizmust és támogatási ígéreteket, hogy kiküszöböljék a jelenlegi teljesítmény- és funkcionalitási problémákat. Hardveres szempontból pedig a tárhely növekedése és fejlesztése miatti közeljövő tartalékát is figyelembe véve számunkra optimális konfigurációjú szervereket várunk.
Természetesen lesz tesztelés, kompatibilitás-ellenőrzés, esetleg építészeti változtatások a HA GRID részben. Az Informaticán belül folytatódik a fejlesztés, hiszen rövid távon nem tudunk semmivel sem pótolni a rendszert.
Azok pedig, akik a jövőben felelősek lesznek ezért a rendszerért, minden bizonnyal képesek lesznek elérni az ügyfelek által előírt megbízhatósági és teljesítménymutatókat.
A cikket a Rostelecom adatkezelő csapata készítette
Jelenlegi Informatika logó
Forrás: will.com