De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador

El component ETL del magatzem de dades sovint es veu eclipsat pel mateix magatzem i rep menys atenció que la base de dades principal o el component frontal, la BI i els informes. Al mateix temps, des del punt de vista de la mecànica d'omplir de dades el magatzem, ETL juga un paper clau i requereix no menys atenció per part dels administradors que altres components. Em dic Alexander, ara administro ETL a Rostelecom, i en aquest article intentaré compartir una mica del que ha de tractar l'administrador d'un dels sistemes ETL més famosos d'un gran magatzem de dades de Rostelecom.

Si estimats lectors ja estan familiaritzats en general amb el nostre projecte de magatzem de dades i amb el producte Informatica PowerCenter, podeu passar immediatament a la secció següent.

Fa uns quants anys, la idea d'un únic magatzem de dades corporatiu va madurar i es va començar a implementar a Rostelecom. Ja s'havien creat una sèrie de dipòsits que resolien problemes individuals, però el nombre d'escenaris va créixer, els costos de suport també van augmentar i es va fer evident que el futur passava per la centralització. Arquitectònicament, aquest és el propi emmagatzematge, format per diverses capes, implementades a Hadoop i GreenPlum, bases de dades auxiliars, mecanismes ETL i BI.

Al mateix temps, a causa del gran nombre de fonts de dades heterogènies i distribuïdes geogràficament, es va crear un mecanisme especial de càrrega de dades, el funcionament del qual està controlat per Informatica. Com a resultat, els paquets de dades acaben a l'àrea d'interfície Hadoop, després de la qual s'inicien els processos de càrrega de dades a través de les capes d'emmagatzematge, Hadoop i GreenPlum, i són gestionats per l'anomenat mecanisme de control ETL implementat a Informatica. Així, el sistema Informatica és un dels elements clau que assegura el funcionament del magatzem.

El nostre emmagatzematge es descriurà amb més detall en una de les publicacions següents.

Informatica PowerCenter/Big Data Management es considera actualment el programari líder en el camp de les eines d'integració de dades. Aquest és un producte de l'empresa nord-americana Informatica, que és un dels jugadors més forts en ETL (Extract Transform Load), gestió de la qualitat de les dades, MDM (Master Data Management), ILM (Information Lifecycle Management) i molt més.

El PowerCenter que fem servir és un servidor d'aplicacions Tomcat integrat en el qual s'executen les pròpies aplicacions d'Informatica, implementant els seus serveis:

domini, de fet, aquesta és la base de tota la resta; serveis, usuaris i components GRID operen dins del domini.

Consola de l'administrador, una eina de gestió i seguiment basada en web, a més del client Informatica Developer, l'eina principal per interactuar amb el producte

MRS, Servei de dipòsit de models, un dipòsit de metadades, és una capa entre la base de dades en què s'emmagatzemen físicament les metadades i el client de l'Informatica Developer en què s'està desenvolupant. Els repositoris emmagatzemen descripcions de dades i altra informació, inclòs per a una sèrie d'altres serveis d'Infromatica, per exemple, programacions per executar tasques (planificacions) o dades de supervisió, així com paràmetres de l'aplicació, en particular, que permeten l'ús de la mateixa aplicació per treballar amb diferents fonts de dades i receptors.

DIS, Servei d'Integració de Dades, es tracta d'un servei en el qual tenen lloc els principals processos funcionals, les aplicacions que s'hi executen i els llançaments reals de Workflows (descripcions de la seqüència de mapes i les seves interaccions) i Mappings (transformacions, blocs en què es produeixen les transformacions en si mateixes, processament de dades). ) tenir lloc.

Configuració GRID – essencialment, una opció per construir un complex utilitzant diversos servidors, quan la càrrega llançada per DIS es distribueix entre els nodes (és a dir, servidors que formen part del domini). En el cas d'aquesta opció, a més de distribuir la càrrega a DIS a través d'una capa d'abstracció GRID addicional que uneix diversos nodes, sobre els quals s'executa DIS en lloc de treballar en un únic node específic, també es poden crear instàncies MRS de còpia de seguretat addicionals. Fins i tot podeu implementar una alta disponibilitat, on es poden fer trucades externes a través de nodes de seguretat si falla el principal. Hem abandonat aquesta opció de construcció de moment.

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Informàtica PowerCenter, esquema

En les primeres etapes del treball com a part de la cadena de subministrament de dades, van sorgir regularment problemes, alguns d'ells a causa del funcionament inestable d'Informatica en aquell moment. Vaig a compartir alguns dels moments memorables d'aquesta saga: dominar Informatica 10.

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Antic logotip d'Informatica

La nostra àrea de responsabilitat també inclou altres entorns Informatica, tenen les seves pròpies especificitats a causa d'una càrrega diferent, però de moment recordaré exactament com es va desenvolupar Informatica com a component ETL del mateix magatzem de dades.

Com va passar això

L'any 2016, quan ens vam fer responsables del treball d'Informàtica, ja havia arribat a la versió 10.0, i per als companys optimistes que estaven decidint utilitzar un producte amb una versió menor .0 en una solució seriosa, tot semblava obvi: cal fer servir la nova versió! Des del punt de vista dels recursos de maquinari, tot estava bé en aquell moment.

Des de la primavera de 2016, un contractista s'encarrega de la feina d'Informàtica i, segons els pocs usuaris del sistema, “funcionava un parell de vegades per setmana”. Aquí cal aclarir que el dipòsit estava de facto en l'etapa de PoC, no hi havia administradors a l'equip i el sistema es va estavellar constantment per diversos motius, després de la qual cosa l'enginyer del contractista el va tornar a recollir.

A la tardor, tres administradors es van incorporar a l'equip, repartint-se les seves àrees de responsabilitat entre ells, i es va començar a treballar amb normalitat per organitzar el funcionament dels sistemes del projecte, entre ells Informatica. A part, cal dir que aquest producte no està molt estès i compta amb una gran comunitat en la qual pots trobar respostes a qualsevol dubte i resoldre qualsevol problema. Per tant, el suport tècnic complet del soci rus Informatica va ser molt important, amb l'ajuda del qual es van corregir tots els nostres errors i errors de l'aleshores jove Informatica 10.

El primer que vam haver de fer pels desenvolupadors del nostre equip i el contractista va ser estabilitzar el treball de la mateixa Informatica, per garantir la funcionalitat de la consola d'administració web (Administrator d'Informatica).

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Així és com sovint ens trobem amb els desenvolupadors d'Informatica

Deixant de banda el procés d'esbrinar els motius, el principal motiu dels bloquejos va ser el patró d'interacció del programari Informatica amb la base de dades del repositori, que es trobava en un servidor relativament remot, des del punt de vista del paisatge de la xarxa. Això va provocar retards i va interrompre els mecanismes que controlen l'estat del domini Informatica. Després d'una mica d'ajust de la base de dades, canviant els paràmetres d'Informatica, que la feia més tolerant als retards de la base de dades, i finalment actualitzar la versió d'Informatica a la 10.1 i transferir la base de dades del servidor anterior a un servidor situat més a prop d'Informatica, el problema va perdre el seu nivell. rellevància, i des de llavors hi ha hagut accidents d'aquest tipus que no observem.

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Un dels intents de fer funcionar Informatica Monitor

La situació amb la consola d'administració també era crítica. Com que el desenvolupament actiu estava en marxa directament a l'entorn relativament productiu, els col·legues necessitaven analitzar constantment el treball dels mapes i el flux de treball "sobre la marxa". A la nova Informatica, el Servei d'Integració de Dades no disposa d'una eina separada per a aquest seguiment, però a la consola web d'administració (Informatica Administrator Monitor) ha aparegut una secció de monitorització, en la qual es pot supervisar el funcionament de les aplicacions, el flux de treball i els mapes, llançaments, registres. Periòdicament, la consola no estava completament disponible o la informació sobre els processos actuals del DIS deixava d'actualitzar-se o es produïen errors en carregar les pàgines.

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Selecció de paràmetres java per estabilitzar el funcionament

El problema es va corregir de moltes maneres, es van fer experiments per canviar paràmetres, es van recollir logs i jstack, enviar-los al suport, alhora que hi havia google actiu i simplement observació.

En primer lloc, es va crear un MRS a part per al monitoratge, que com es va comprovar més tard, aquest és un dels principals consumidors de recursos dels nostres entorns, ja que els mapes es llancen de manera molt intensa. S'han canviat els paràmetres relatius a l'emmagatzematge de Java i una sèrie d'altres.
Com a resultat, amb la següent actualització Informatica 10.1.1, el funcionament de la consola i el monitor es va estabilitzar, els desenvolupadors van començar a treballar de manera més eficient i els processos habituals es van fer cada cop més regulars.

L'experiència d'interacció entre desenvolupament i administració pot ser interessant. La qüestió d'una comprensió general de com funcionen les coses, què es pot fer i què no es pot fer, sempre és important quan s'utilitzen sistemes complexos. Per tant, podem recomanar amb seguretat que primer entreneu l'equip administratiu sobre com administrar el programari i l'equip de desenvolupament sobre com escriure codi i dibuixar processos al sistema, i només després envieu el primer i el segon per treballar en el resultat. Això és molt important quan el temps no és un recurs infinit. Molts problemes es poden resoldre fins i tot amb una cerca aleatòria d'opcions, però de vegades alguns requereixen coneixements a priori: el nostre cas confirma la importància d'entendre aquest axioma.

Per exemple, quan vam intentar habilitar el control de versions a MRS (com va resultar que al final es necessitava una versió diferent de SVN), després d'un temps ens va alarmar descobrir que el temps de reinici del sistema havia augmentat a diverses desenes de minuts. Després d'haver trobat el motiu del retard en l'inici i desactivat el control de versions, vam tornar a fer-ho bé.

Els obstacles notables associats a Informatica inclouen l'èpica batalla amb els fils java creixents. En algun moment ha arribat el moment de la replicació, és a dir, d'estendre els processos establerts a un gran nombre de sistemes font. Va resultar que no tots els processos de la 10.1.1 funcionaven bé, i després d'un temps DIS es va tornar inoperable. Es van detectar desenes de milers de fils, el seu nombre va créixer especialment durant el procediment de desplegament de l'aplicació. De vegades he hagut de reiniciar diverses vegades al dia per restaurar la funcionalitat.

Aquí hem d'agrair el suport; els problemes es van localitzar i es van solucionar amb relativa rapidesa mitjançant EBF (Emergency Bug Fix) - després d'això, tothom va tenir la sensació que l'eina realment funciona.

Encara funciona!

Quan vam començar a treballar en mode objectiu, Informatica tenia aquest aspecte. Versió d'Informatica 10.1.1HF1 (HF1 és HotFix1, un conjunt de proveïdors d'un complex d'EBF) amb EBF instal·lat addicionalment, que corregeix els nostres problemes amb l'escala i alguns altres, en un servidor de cada tres que formaven part de GRID, 20 nuclis x86_64 i emmagatzematge, en una gran matriu lenta de discos locals: aquesta és la configuració del servidor per a un clúster Hadoop. En un altre servidor similar: el SGBD Oracle amb el qual funcionen tant el domini Informatica com el mecanisme de control ETL. Tot això es controla mitjançant eines de monitorització estàndard utilitzades a l'equip (Zabbix + Grafana) per ambdues parts: la mateixa Informatica amb els seus serveis, i els processos de càrrega que hi intervenen. Ara tant el rendiment com l'estabilitat, sense tenir en compte factors externs, ara depenen de les configuracions que limiten la càrrega.

Per separat, podem dir sobre GRID. L'entorn es va construir en tres nodes, amb possibilitat d'equilibri de càrrega. Tanmateix, durant les proves, es va descobrir que a causa de problemes d'interacció entre les instàncies en execució de les nostres aplicacions, aquesta configuració no funcionava com s'esperava, i van decidir abandonar temporalment aquest esquema de construcció, eliminant dos dels tres nodes del domini. Al mateix temps, l'esquema en si s'ha mantingut igual, i ara és precisament un servei GRID, però degenerat a un node.

Ara mateix, la dificultat continua associada a una caiguda del rendiment quan es neteja regularment el circuit del monitor: amb processos simultanis a la CNN i neteja en execució, es poden produir mal funcionament del mecanisme de control ETL. Actualment, això s'està solucionant "com una crossa", esborrant manualment el circuit del monitor, amb la pèrdua de totes les seves dades anteriors. Això no és massa crític per a la productivitat, durant el funcionament normal de rutina, però de moment s'està buscant una solució normal.

Un altre problema sorgeix d'aquesta mateixa situació: de vegades es produeixen múltiples llançaments del nostre mecanisme de control.

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Llançaments múltiples d'aplicacions que provoquen un error del mecanisme

Quan s'executa d'acord amb un programa, en moments de gran càrrega del sistema, de vegades es produeixen situacions que porten a l'avaria del mecanisme. El problema encara s'està solucionant manualment i s'està buscant una solució permanent.

En general, podem resumir que quan hi ha una càrrega pesada, és molt important dotar-hi de recursos adequats, això també s'aplica als recursos de maquinari per a la pròpia Informatica, i el mateix per al seu repositori de bases de dades, així com per oferir una configuració òptima. per ells. A més, la pregunta continua oberta sobre quin esquema de col·locació de bases de dades és millor: en un host separat o en el mateix on s'executa el programari d'Informatica. D'una banda, serà més barat en un servidor i, combinat, pràcticament s'elimina el possible problema d'interacció amb la xarxa; d'altra banda, la càrrega de l'amfitrió des de la base de dades es complementa amb la càrrega d'Informatica.

Com amb qualsevol producte seriós, Informatica també té moments divertits.
Una vegada, mentre resolva algun tipus d'accident, em vaig adonar que els registres de l'MRS indicaven estranyament l'hora dels esdeveniments.

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Dualisme temporal als registres de MRS "per disseny"

Va resultar que les marques de temps s'escriuen en format de 12 hores, sense especificar AM/PM, és a dir, abans del migdia o després. Fins i tot es va obrir una sol·licitud sobre aquest assumpte i es va rebre una resposta oficial: així és com es pretenia, les marques s'escriuen al registre de MRS exactament en aquest format. És a dir, de vegades queda alguna intriga pel que fa al moment en què es produeix algun ERROR...

Esforçar-se pel millor

Avui, Informatica és una eina força estable, convenient per a administradors i usuaris, extremadament potent pel que fa a les seves capacitats i potencials actuals. Supera moltes vegades les nostres necessitats funcionals i ara s'està utilitzant de facto en el projecte d'una manera que no és la més típica i típica. Les dificultats estan en part relacionades amb la forma en què funcionen els mecanismes: l'específic és que en un curt període de temps es llança un gran nombre de fils que actualitzen intensament els paràmetres i treballen amb la base de dades del repositori, mentre que els recursos de maquinari del servidor s'utilitzen gairebé completament. per la CPU.

Ara estem a punt de passar a Informatica 10.2.1 o 10.2.2, que han reelaborat alguns dels mecanismes interns i promeses de suport per eliminar alguns dels problemes de rendiment i funcionalitat que tenim actualment. I des del punt de vista del maquinari, esperem servidors amb una configuració òptima per a nosaltres, tenint en compte la reserva per a un futur proper a causa del creixement i desenvolupament de l'emmagatzematge.

Per descomptat, hi haurà proves, comprovació de compatibilitat i possiblement canvis arquitectònics a la part HA GRID. El desenvolupament dins d'Informatica continuarà, ja que a curt termini no podem subministrar res per substituir el sistema.
I els que seran responsables d'aquest sistema en el futur, sens dubte, podran portar-lo als indicadors de fiabilitat i rendiment requerits proposats pels clients.

L'article va ser preparat per l'equip de gestió de dades de Rostelecom

De l'accident quotidià a l'estabilitat: Informatica 10 a través de la mirada d'un administrador
Logotip actual d'Informatica

Font: www.habr.com

Afegeix comentari