Componenta ETL a depozitului de date adesea rămâne în umbra depozitului însuși și primește mai puțină atenție decât baza de date principală sau componentele frontale, BI, generarea rapoartelor. Totuși, din punctul de vedere al mecanicii de umplere a depozitului cu date, ETL joacă un rol cheie și necesită la fel de multă atenție din partea administratorilor ca și celelalte componente. Mă numesc Alexandru, acum administrez ETL la Rostelecom și în acest articol voi încerca să împărtășesc puțin din ceea ce se confruntă un administrator al unei cunoscute ETL-sisteme într-un mare depozit de date al companiei Rostelecom.
Dacă cititorii respectabili sunt deja familiarizați în general cu proiectul nostru de depozit de date și cu produsul Informatica PowerCenter, putem trece direct la secțiunea următoare.
Acum câțiva ani, la Rostelecom a apărut și a început să devină realitate ideea unui depozit de date corporativ unic. O serie de depozite, care rezolvau sarcini separate, fuseseră deja create, dar numărul scenariilor creștea, cheltuielile pentru suport creșteau de asemenea, și a devenit clar că viitorul este în centralizare. Din punct de vedere arhitectural, acest depozit constă din mai multe straturi, fiind implementat pe Hadoop și GreenPlum, cu baze de date auxiliare, mecanisme ETL și BI.
În același timp, datorită numărului mare de surse de date distribuite geografic și diverse, a fost creat un mecanism special de extragere a datelor, a cărui funcționare este gestionată de Informatica. Ca rezultat, pachetele cu date ajung în zona de interfață Hadoop, după care încep procesele de încărcare a datelor pe straturile depozitului, în Hadoop și GreenPlum, și sunt gestionate de așa-numitul mecanism de control ETL, implementat în Informatica. Astfel, sistemul Informatica este unul dintre elementele cheie care asigură funcționarea depozitului.
Mai multe detalii despre depozitul nostru vor fi prezentate într-unul dintre următoarele posturi.
Informatica PowerCenter / Big Data Management este în prezent considerat lider în domeniul instrumentelor de integrare a datelor. Este un produs al companiei americane Informatica, care este unul dintre cei mai puternici jucători în ETL (Extract Transform Load), managementul calității datelor, MDM (Master Data Management), ILM (Information Lifecycle Management) și altele.
PowerCenter utilizat de noi este un server de aplicații integrat Tomcat, unde rulează aplicațiile Informatica care implementează serviciile acesteia:
Domeniu, de fapt, acesta este baza pentru tot ce este altceva, în cadrul domeniului funcționează servicii, utilizatori, componente GRID.
Panou de Administrare, un instrument web de gestionare și monitorizare, pe lângă clientul Informatica Developer, principalul instrument pentru interacțiunea cu produsul
MRS, Serviciul de Repositoriu al Modelului, un depozit de metadate, reprezintă un strat între baza de date în care metadatele sunt stocate fizic și clientul Informatica Developer, în care se face dezvoltarea. Repositoarele stochează atât descrierea datelor, cât și alte informații, inclusiv pentru mai multe servicii Informatica, de exemplu, programarea execuțiilor (Schedules) sau datele de monitorizare, precum și seturile de parametri ale aplicațiilor, permițând utilizarea aceleași aplicații pentru lucrul cu diverse surse și destinații de date.
DIS, Serviciul de Integrare a Datelor, acesta este serviciul în care au loc procesele funcționale principale, în care rulează aplicațiile și are loc în mod real execuția Workflows (descrierea secvențelor de mappings și interacțiunea acestora) și Mappings (transformări, blocuri în care au loc efectiv transformările, procesarea datelor).
Configurația GRID – de fapt, este o variantă de construire a unui complex utilizând mai multe servere, când sarcina generată de DIS este distribuită pe noduri (adică serverele care fac parte din domeniu). În acest caz, pe lângă distribuția sarcinii în DIS printr-un strat suplimentar de abstractizare GRID, care unește mai multe noduri, pe care funcționează DIS în loc să lucreze pe un singur nod specific, pot fi create și instanțe de rezervă suplimentare MRS. Poate fi realizată chiar și o disponibilitate ridicată, când accesările externe pot avea loc prin noduri de rezervă în cazul în care nodul principal eșuează. Am decis să renunțăm la această variantă de construcție pentru moment.
Informatica PowerCenter, schematic
În primele etape ale lucrului în cadrul lanțului de aprovizionare a datelor au apărut frecvent probleme, unele dintre ele din cauza funcționării instabile a Informatica la acel moment. Voi împărtăși câteva dintre momentele memorabile ale acestei saga – învățarea Informatica 10.
Fostul logo Informatica
Aria de responsabilitate a direcției noastre include și alte medii Informatica, care au specifice diferite din cauza sarcinii diferite. Deocamdată, voi aminti doar cum s-a dezvoltat Informatica ca componentă ETL a depozitului de date.
Cum s-a întâmplat asta
În anul 2016, când am început să ne ocupăm de funcționarea Informatica, aceasta atingea deja versiunea 10.0, iar pentru colegii optimiști care luau decizia de a utiliza acest produs cu o versiune minoră .0, totul părea clar - trebuie folosită noua versiune! Din punct de vedere al resurselor hardware, totul era excelent la acel moment.
Din primăvara anului 2016, funcționarea Informatica a fost gestionată de un subcontractor, iar din spusele câtorva utilizatori ai sistemului, „aceasta funcționa de câteva ori pe săptămână”. Aici trebuie menționat că depozitul era, de facto, într-o etapă PoC, nu existau administratori în echipă, iar sistemul cădea constant din diverse motive, după care inginerul subcontractorului îl repunea în funcțiune.
În toamnă, echipa a primit trei administratori, care și-au împărțit responsabilitățile și a început să se consolideze o muncă normală în exploatarea sistemelor din proiect, inclusiv Informatica. Este important de menționat că acest produs nu este foarte răspândit și nu dispune de o comunitate mare în care să găsești răspunsuri la întrebări sau să rezolvi probleme. De aceea, suportul tehnic complet oferit de partenerul rus al Informatica a fost extrem de important, ajutând la corectarea tuturor greșelilor noastre și a problemelor Informatica 10, care era atunci încă tânără.
Primul lucru pe care a trebuit să-l facem pentru dezvoltatorii echipei noastre și pentru subcontractor - a fost stabilizarea funcționării Informatica însăși, asigurarea funcționalității consolei web de administrare (Informatica Administrator).
Așa că, de multe ori, întâlneam dezvoltatori Informatica
Trecând peste procesul de identificare a cauzelor, principala cauză a căderilor a fost schema de interacțiune a software-ului Informatica cu baza de date a depozitului, care se afla pe un server relativ îndepărtat, din perspectiva peisajului de rețea. Aceasta ducea la întârzieri și afecta funcționarea mecanismelor ce asigurau controlul stării domeniului Informatica. După unele ajustări ale bazei de date, modificarea parametrilor Informatica pentru a o face mai tolerantă la întârzierile bazei de date, și, în cele din urmă, actualizarea versiunii Informatica la 10.1 și mutarea bazei de date de pe serverul anterior pe un server mai apropiat de Informatica, problema a devenit irelevantă, iar de atunci nu am observat căderi de acest tip.
Una dintre încercările de a obține funcționarea Informatica Monitor
Situația cu consola de administrare a fost de asemenea critică. Fiindcă se desfășura o dezvoltare activă direct pe un mediu considerat de producție, colegii aveau nevoie constant să analizeze funcționarea mappings-urilor și a fluxurilor de lucru „în timp real”. În noua versiune de Informatica, în Data Integration Service nu există un instrument separat pentru această monitorizare, dar în consola de administrare web a apărut o secțiune de monitorizare (Informatica Administrator Monitor), în care se pot observa aplicațiile, fluxurile de lucru și mappings-urile, executările, logurile. Periodic, consola devenea complet inaccesibilă, fie că nu se mai actualizau informațiile despre procesele curente în DIS, fie că apăreau erori la încărcarea paginilor.
Ajustarea parametrilor java pentru stabilizarea funcționării
Rezolvarea problemei a fost abordată din multe perspective, au fost efectuate experimente cu modificarea parametrilor, au fost colectate loguri, jstackuri, care au fost trimise la suport, paralel cu o căutare activă pe Google și se făcea pur și simplu observație.
În primul rând, a fost creat un MRS separat pentru monitorizare, care, așa cum s-a dovedit, este unul dintre principalii consumatori de resurse în medii, deoarece executările de mappings au loc foarte intens. Au fost modificate parametrii referitori la heap-ul java și altele.
Ca urmare, la următoarea actualizare a Informatica 10.1.1, funcționarea consolei și a monitorului a fost stabilizată, dezvoltatorii au început să lucreze mai eficient, iar procesele regulate deveneau din ce în ce mai regulate.
O experiență interesantă poate fi interacțiunea între dezvoltare și administrare. Întrebarea înțelegerii generale despre cum funcționează totul, ce se poate face și ce nu se poate face, este întotdeauna importantă în utilizarea sistemelor complexe. De aceea, se poate recomanda cu încredere ca mai întâi să fie instruită echipa de administratori cu privire la modul în care trebuie administrat software-ul, iar echipa de dezvoltatori cu privire la modul în care trebuie scris cod și să fie desenate procesele în sistem, și abia apoi să fie trimise ambele echipe să lucreze pentru rezultate. Acest lucru este cu adevărat important atunci când timpul nu este o resursă infinită. Multe probleme pot fi rezolvate chiar și prin încercări aleatorii, dar unele necesită uneori cunoștințe anterioare - cazul nostru confirmă importanța înțelegerii acestei axiomă.
De exemplu, în încercarea de a activa versiunea în MRS (așa cum s-a dovedit, era necesară o altă versiune SVN), după un timp am descoperit cu îngrijorare că timpul de repornire a sistemului crescuse la câteva zeci de minute. După ce am identificat cauza întârzierii la pornire și am dezactivat versiunea, totul a fost din nou bine.
Printre obstacolele notabile legate de Informatica, poate fi menționată epica luptă cu fluxurile java în expansiune. La un moment dat, a venit vremea replicării, adică de a extinde procesele stabilite pe un număr mare de sisteme de sursă. Cu toate acestea, s-a dovedit că nu toate procesele din 10.1.1 funcționau bine, și după un timp, DIS devenea ineficient. Sute de mii de fluxuri erau descoperite, numărul acestora crescând în mod special în timpul procedurii de implementare a aplicațiilor. Uneori a fost nevoie să facem reporniri de câteva ori pe zi pentru a restabili funcționalitatea.
Aici trebuie să mulțumim suportului, problemele au fost relativ rapid localizate și rezolvate cu ajutorul EBF (Emergency Bug Fix) - după aceasta, toată lumea a avut senzația că instrumentul funcționează cu adevărat.
Chiar funcționează!
La momentul începerii activității în modul țintă, Informatica arăta astfel. Versiunea Informatica 10.1.1HF1 (HF1 este HotFix1, o compilare de vânzător din complexul EBF) cu EBF-uri suplimentare instalate, rezolvând problemele noastre de scalare și altele, pe un server din cele trei incluse în GRID, 20 de nuclee x86_64 și un stocare pe un uriaș și lent array de discuri locale - acesta configurația serverului pentru clusterul Hadoop. Pe un alt server similar se află SGBD Oracle, cu care lucrează atât domeniul Informatica, cât și mecanismul de gestionare ETL. Totul este monitorizat prin instrumente standard de monitorizare utilizate în echipă (Zabbix + Grafana), din două direcții — atât Informatica și serviciile sale, cât și procesele de încărcare care îi vin. Acum, atât performanța, cât și stabilitatea funcționării, fără a lua în considerare factorii externi, depind de setările care limitează la maximum încărcătura.
Separat, se poate spune despre GRID. Mediul a fost construit pe trei noduri, cu posibilitate de echilibrare a încărcării. Cu toate acestea, în timpul testării s-a descoperit că, din cauza problemelor de interacțiune între instanțele aplicațiilor noastre, această configurație nu funcționa așa cum se aștepta, iar temporar s-a decis abandonarea acestui sistem de construcție, scoțând două din cele trei noduri din domeniu. Cu toate acestea, schema a rămas aceeași, și acum este un serviciu GRID, dar degenerat la un singur nod.
În prezent, rămâne o dificultate legată de scăderea performanței în timpul curățării regulate a schemei de monitorizare — în timpul proceselor simultane în CNN și curățarea inițiată, pot apărea defecțiuni în funcționarea mecanismului de gestionare ETL. Acest lucru este rezolvat deocamdată «cumpănit» — prin curățarea manuală a schemei monitorului, cu pierderea tuturor datelor anterioare. Aceasta nu este critică pentru producție, în condiții normale de operare, dar se caută o soluție viabilă.
Din această situație derivă și o altă problemă — uneori au loc lansări multiple ale mecanismului nostru de gestionare.
Lansări multiple ale aplicației, care duc la defectarea mecanismului
La lansarea conform programului, în momente de mare încărcare a sistemului, uneori apar situații care duc la defectarea mecanismului. Până acum, problema este corectată manual, se caută o soluție permanentă.
În ansamblu, se poate concluziona că, în condiții de încărcare mare, este foarte important să se ofere resurse adecvate, ceea ce se referă atât la resursele hardware pentru Informatica, cât și la cele pentru baza sa de date, precum și la asigurarea unor configurații optime pentru acestea. În plus, rămâne deschisă întrebarea privind cea mai bună schemă de amplasare a bazei de date - pe un server separat sau pe același server pe care rulează software-ul Informatica. Pe de o parte, pe un singur server costurile vor fi mai mici și se elimină practic posibilele probleme de interacțiune rețea, pe de altă parte, sarcina pe server de la baza de date este completată de sarcina de la Informatica.
La fel ca în orice produs serios, și în Informatica există momente amuzante.
Odată, analizând un accident, am observat că în log-urile MRS timpul evenimentelor era marcat ciudat.
Dualitatea temporală în log-urile MRS "by design"
S-a dovedit că timpii sunt scriși în format de 12 ore, fără indicație AM/PM, adică înainte sau după prânz. A fost deschis chiar un bilet în acest sens, și am primit un răspuns oficial - așa a fost conceput, timpii în log-ul MRS sunt scriși în acest format. Asta înseamnă că rămâne uneori o anumită intrigă cu privire la timpul de apariție al unei erori...
Aspirați spre mai bine
Astăzi, Informatica este un instrument destul de stabil, convenabil pentru administrator și utilizatori, extrem de puternic în ceea ce privește capacitățile actuale și potențialul. Acesta depășește de multe ori nevoile noastre funcționale și de facto este folosit acum în proiect într-un mod mai puțin tipic. Dificultățile sunt parțial legate de modul în care funcționează mecanismele - specificitatea constă în faptul că, într-un interval scurt de timp, se lansează un mare număr de fire care actualizează intensiv seturile de parametri și lucrează cu baza de date a depozitului, în timp ce resursele hardware ale serverului sunt utilizate aproape complet pe CPU.
Acum suntem aproape de tranziția la Informatica 10.2.1 sau 10.2.2, în care au fost revizuite unele mecanisme interne, iar suportul promite absența unui număr de probleme de performanță și de funcționare pe care le avem în prezent. De asemenea, din punct de vedere hardware, se așteaptă servere configureate optim pentru noi, având în vedere rezervă pentru perioada imediat următoare, în virtutea creșterii și dezvoltării depozitului.
Desigur, va fi necesar să efectueze teste, să verifice compatibilitatea și, posibil, să facă modificări arhitecturale în ceea ce privește HA GRID. Dezvoltarea în cadrul Informatica va continua, deoarece pe termen scurt nu putem implementa nimic înlocuitor pentru sistem.
Și cei care vor fi responsabili de acest sistem în viitor cu siguranță vor reuși să îl aducă la nivelurile necesare de fiabilitate și performanță solicitate de clienți.
Articolul a fost pregătit de echipa de management al datelor de la «Rostelecom»
Logo-ul actual al Informatica
Sursa: habr.com
