L'ETL del data warehouse spesso rimane nell'ombra del warehouse stesso e riceve meno attenzione rispetto al database principale o al front-end, BI, nella generazione di report. Tuttavia, dal punto di vista della meccanica di riempimento del magazzino con dati, l'ETL gioca un ruolo chiave e richiede altrettanta attenzione da parte degli amministratori quanto gli altri componenti. Mi chiamo Alessandro, attualmente gestisco l'ETL in Rostelecom, e in questo articolo cercherò di condividere un po' le sfide che affronta l'amministratore di uno dei più celebri sistemi ETL in un grande data warehouse di Rostelecom.
Se i rispettati lettori sono già a conoscenza del nostro progetto di data warehouse e del prodotto Informatica PowerCenter, possono subito passare alla sezione successiva.
Qualche anno fa, in Rostelecom è nata e si è concretizzata l'idea di un unico data warehouse aziendale. Diversi magazzini, che affrontavano compiti specifici, erano già stati creati, ma il numero degli scenari cresceva, i costi di supporto aumentavano e si è compreso che il futuro era nella centralizzazione. Architetturalmente, questo stesso magazzino, composto da diversi strati, è realizzato su Hadoop e GreenPlum, database ausiliari, meccanismi ETL e BI.
Tuttavia, a causa del gran numero di fonti di dati distribuite geograficamente e di natura eterogenea, è stato creato un meccanismo speciale per l'estrazione dei dati, il cui funzionamento è gestito da Informatica. Di conseguenza, i pacchetti di dati si trovano nell'area dell'interfaccia Hadoop, dopo di che iniziano i processi di caricamento dei dati attraverso gli strati del magazzino, in Hadoop e GreenPlum, gestiti dal cosiddetto meccanismo di controllo ETL, implementato in Informatica. Pertanto, il sistema Informatica è uno degli elementi chiave che assicurano il funzionamento del magazzino.
Maggiori dettagli sul nostro magazzino saranno forniti in uno dei prossimi post.
Informatica PowerCenter/Big Data Management è considerato attualmente il software leader nel campo degli strumenti di integrazione dei dati. Questo prodotto appartiene alla società americana Informatica, uno dei più forti attori nel campo dell'ETL (Extract Transform Load), gestione della qualità dei dati, MDM (Master Data Management), ILM (Information Lifecycle Management) e altro.
Il PowerCenter che utilizziamo è un server applicativo integrato Tomcat, in cui funzionano le applicazioni Informatica che forniscono i suoi servizi:
Dominio, in sostanza è la base per tutto il resto, all'interno del dominio funzionano servizi, utenti e componenti GRID.
Console di Amministrazione, uno strumento web per la gestione e il monitoraggio, oltre al client Informatica Developer, è lo strumento principale per interagire con il prodotto
MRS, Servizio Repository Modello, un deposito di metadati, rappresenta uno strato intermedio tra il database, in cui i metadati sono fisicamente archiviati, e il client Informatica Developer, dove avviene lo sviluppo. I repository memorizzano sia la descrizione dei dati che altre informazioni, inclusi per vari altri servizi Informatica, come ad esempio la pianificazione delle esecuzioni dei compiti (Schedules) o i dati di monitoraggio, nonché i parameterset delle applicazioni, in particolare quelli che permettono di utilizzare la stessa applicazione per lavorare con diverse fonti e riceventi di dati.
DIS, Servizio di Integrazione Dati, questo servizio è dove avvengono i principali processi funzionali, qui funzionano le applicazioni e avvengono effettivamente le esecuzioni dei Workflows (descrizioni della sequenza di mappings e delle loro interazioni) e dei Mappings (trasformazioni, blocchi in cui avvengono i veri e propri cambiamenti, elaborazione dei dati).
Configurazione GRID – in sostanza, una variante di costruzione di un complesso che utilizza più server, quando il carico attivato da DIS è distribuito tra i nodi (ovvero i server che fanno parte del dominio). In questo caso, oltre alla distribuzione del carico in DIS tramite uno strato di astrazione aggiuntivo GRID, che unisce più nodi, su cui opera DIS invece di lavorare su un singolo nodo specifico, possono anche essere creati istanze di backup aggiuntive di MRS. Si può anche realizzare alta disponibilità, quando le richieste esterne possono essere gestite tramite nodi di riserva in caso di fallimento del nodo principale. Abbiamo al momento deciso di non adottare questa configurazione.
Informatica PowerCenter, schematicamente
Nelle fasi iniziali del lavoro nella catena di approvvigionamento dei dati si sono verificati regolarmente problemi, alcuni dei quali erano dovuti al funzionamento instabile di Informatica a quel tempo. Intendo condividere alcuni dei momenti memorabili di questa saga - l'adozione di Informatica 10.
Il precedente logo Informatica
Nell'ambito delle nostre responsabilità rientrano anche altri ambienti di Informatica, che hanno le proprie specificità a causa di carichi diversi. Per ora, tuttavia, mi concentrerò su come si è evoluta Informatica come componente ETL del data warehouse stesso.
Com'è potuto succedere
Nel 2016, quando abbiamo iniziato a gestire Informatica, era già arrivata alla versione 10.0, e per i colleghi ottimisti che stavano decidendo di adottarla in una soluzione seria con una versione minore .0, tutto sembrava ovvio: bisognava usare la nuova versione! Dal punto di vista delle risorse hardware, tutto andava bene in quel momento.
Dalla primavera del 2016, un appaltatore ha gestito il lavoro di Informatica, e secondo le parole di pochi utenti del sistema, "questa funzionava un paio di volte a settimana". Qui è necessario chiarire che il data warehouse era de facto nella fase PoC, non c'erano amministratori nel team e il sistema si bloccava continuamente per vari motivi, dopo di che l'ingegnere dell'appaltatore lo riavviava.
In autunno, nel team sono arrivati tre amministratori, che hanno suddiviso le responsabilità tra loro, e ha iniziato a costruirsi un lavoro normale per l'esercizio dei sistemi del progetto, compresa Informatica. È importante notare che questo prodotto non è ampiamente diffuso e non ha una grande comunità, nella quale si possano trovare risposte a qualsiasi domanda e risolvere qualsiasi problema. Pertanto, è stata fondamentale un'assistenza tecnica completa da parte del partner russo di Informatica, che ha fornito supporto per correggere tutti i nostri errori e quelli di Informatica 10, ancora giovane.
La prima cosa che abbiamo dovuto fare per gli sviluppatori del nostro team e dell'appaltatore è stata stabilizzare il funzionamento di Informatica, raggiungere la funzionalità della web console di amministrazione (Informatica Administrator).
Così abbiamo spesso accolto gli sviluppatori di Informatica.
Lasciando da parte il processo di indagine delle cause, la principale ragione delle interruzioni era lo schema di interazione del software Informatica con il database del repository, situato su un server relativamente remoto dal punto di vista del paesaggio di rete. Questo portava a ritardi e comprometteva il funzionamento dei meccanismi che garantivano il controllo dello stato del dominio Informatica. Dopo alcune ottimizzazioni del database e modifiche ai parametri di Informatica che lo rendevano più tollerante ai ritardi del database, e infine l'aggiornamento della versione di Informatica a 10.1 e il trasferimento del database da un server precedente a uno più vicino a Informatica, il problema ha perso rilevanza, e da allora non abbiamo più osservato interruzioni di questo tipo.
Uno dei tentativi di far funzionare il monitor di Informatica
La situazione con la console di amministrazione era altrettanto critica. Poiché si stava sviluppando attivamente direttamente in un ambiente considerato produttivo, i colleghi dovevano costantemente analizzare il funzionamento dei mappings e dei workflow 'in tempo reale'. Nella nuova Informatica, nel Data Integration Service non c'è uno strumento separato per tale monitoraggio, ma nella console di amministrazione web è comparsa una sezione di monitoraggio (Informatica Administrator Monitor) in cui è possibile osservare il funzionamento delle applicazioni, dei workflow e dei mappings, delle esecuzioni e dei log. Periodicamente, la console diventava completamente non disponibile, oppure smetteva di aggiornare le informazioni sui processi in corso nel DIS, oppure si verificavano errori durante il caricamento delle pagine.
Selezione dei parametri java per stabilizzare il funzionamento
La risoluzione del problema avveniva in molti modi, venivano condotti esperimenti per modificare i parametri, venivano raccolti log, jstack, inviati al supporto, mentre parallelamente si faceva attiva ricerca su Google e si osservava.
Innanzitutto è stato creato un MRS separato per il monitoraggio, che si è rivelato essere uno dei principali consumatori di risorse nei nostri ambienti, poiché le esecuzioni dei mappings avvenivano in modo molto intenso. Sono stati modificati i parametri riguardanti la java heap e diversi altri.
Di conseguenza, con il successivo aggiornamento a Informatica 10.1.1, è stato possibile stabilizzare il funzionamento della console e del monitor, gli sviluppatori hanno iniziato a lavorare in modo più efficiente e i processi regolari diventavano sempre più regolari.
Un'esperienza interessante può essere l'interazione tra sviluppo e amministrazione. La questione della comprensione comune di come funziona tutto, cosa si può fare e cosa non si può fare, è sempre importante quando si utilizzano sistemi complessi. Pertanto, si può tranquillamente raccomandare di formare prima il team degli amministratori su come gestire il software, e il team degli sviluppatori su come scrivere codice e disegnare processi nel sistema, per poi mandare entrambi a lavorare sui risultati. Questo è davvero importante quando il tempo non è una risorsa infinita. Molti problemi possono essere risolti anche attraverso un tentativo casuale di varianti, ma a volte alcuni richiedono conoscenze a priori — il nostro caso conferma l'importanza di comprendere questo assunto.
Ad esempio, quando abbiamo tentato di attivare la versioning in MRS (come si è rivelato, era necessaria un'altra versione di SVN), dopo un po' di tempo, abbiamo scoperto con preoccupazione che il tempo di riavvio del sistema era aumentato a diverse decine di minuti. Identificata la causa del ritardo e disattivata la versioning, le cose sono tornate a funzionare.
Tra gli ostacoli considerevoli legati a Informatica, possiamo ricordare l'epica battaglia con i crescenti flussi Java. A un certo punto siamo arrivati al momento della replicazione, cioè di estendere processi collaudati a un gran numero di sistemi sorgente. Tuttavia, si è scoperto che non tutti i processi in 10.1.1 funzionavano bene, e dopo un po' di tempo DIS diventava inoperante. Venivano scoperti decine di migliaia di flussi, il cui numero cresceva soprattutto durante la procedura di deploy delle applicazioni. A volte era necessario riavviare più volte al giorno per ripristinare la funzionalità.
Qui bisogna ringraziare il supporto, i problemi sono stati relativamente rapidamente localizzati e risolti con l'uso di EBF (Emergency Bug Fix) – dopo di che tutti hanno avuto la sensazione che lo strumento funzionasse davvero.
Funziona davvero!
Al momento dell'inizio del lavoro in modalità target, Informatica si presentava come segue. Versione Informatica 10.1.1HF1 (HF1 è HotFix1, una build del fornitore dal pacchetto di EBF), con EBF addizionali installati, che correggevano i nostri problemi di scalabilità e alcuni altri, su un server dei tre inclusi nel GRID, 20 core x86_64 e uno storage, su un enorme e lento array di dischi locali — questo configurazione del server per il cluster Hadoop. Su un altro server identico è installato il database Oracle, con cui interagiscono sia il dominio Informatica sia il meccanismo di gestione ETL. Tutto ciò è monitorato tramite gli strumenti di monitoraggio standard utilizzati dal team (Zabbix + Grafana), da entrambe le parti — sia dalla stessa Informatica con i suoi servizi, sia dai processi di caricamento che vi confluiscono. Attualmente, sia le prestazioni che la stabilità operativa, senza considerare fattori esterni, dipendono dalle impostazioni che limitano il carico.
Si può menzionare separatamente il GRID. L'ambiente è stato costruito su tre nodi, con possibilità di bilanciamento del carico. Tuttavia, durante i test è emerso che a causa di problemi di interazione tra le istanze delle nostre applicazioni in esecuzione, tale configurazione non funzionava come previsto, e abbiamo deciso temporaneamente di abbandonare questo schema di costruzione, rimuovendo due dei tre nodi dal dominio. La configurazione rimane la stessa, e attualmente è un servizio GRID, ma ridotto a un solo nodo.
Attualmente, rimane una difficoltà legata al calo delle prestazioni durante la pulizia regolare dello schema di monitoraggio: quando ci sono più processi simultanei in esecuzione nel CBN e viene avviata la pulizia, possono verificarsi malfunzionamenti nel meccanismo di gestione ETL. Questo viene al momento risolto in modo "provvisorio" — con una pulizia manuale dello schema di monitoraggio, con perdita di tutti i dati precedenti. Questo non è troppo critico per l'ambiente produttivo, quando tutto funziona normalmente, ma è in corso la ricerca di una soluzione adeguata.
Da questa stessa situazione nasce un ulteriore problema: a volte si verificano più avviamenti del nostro meccanismo di gestione.
Avviamenti multipli dell'applicazione, che portano a malfunzionamenti del meccanismo
Durante l'avvio programmato, in momenti di grande carico sul sistema, possono verificarsi situazioni che portano a malfunzionamenti del meccanismo. Fino ad ora, il problema è stato risolto manualmente e si sta cercando una soluzione permanente.
In generale, si può riassumere che sotto un carico elevato è molto importante fornire risorse adeguate, sia per i risorse hardware di Informatica, sia per il suo database repository, oltre a garantire impostazioni ottimali per questi. Inoltre, rimane aperta la questione su quale schema di posizionamento del database sia migliore — su un host separato o sullo stesso dove lavora il software Informatica. Da un lato, su un unico server risulta più economico e, combinando tutto, si elimina praticamente il possibile problema di interazione di rete, dall'altro — il carico sull'host dal database si aggiunge al carico di Informatica.
Come in qualsiasi prodotto serio, in Informatica ci sono anche momenti curiosi.
Una volta, mentre analizzavo un incidente, ho notato che nei log MRS il tempo degli eventi era segnato in modo strano.
Dualismo temporale nei log MRS “per design”
Si è scoperto che i timestamp vengono scritti nel formato delle 12 ore, senza indicazione AM/PM, cioè prima o dopo mezzogiorno. È stata anche aperta una richiesta a riguardo, e ricevuto una risposta ufficiale — era proprio così che era stato pensato, i log MRS vengono scritti in quel modo. Cioè rimane talvolta un certo mistero riguardo al momento di insorgenza di un qualsiasi ERROR...
Puntare al meglio
Oggi Informatica è uno strumento sufficientemente stabile, comodo per l'amministratore e gli utenti, estremamente potente nelle attuali capacità e potenzialità. Supera di gran lunga le nostre necessità funzionali e de facto viene utilizzato nel progetto in modo non del tutto caratteristico e tipico. Le difficoltà sono parzialmente legate a come funzionano i meccanismi — la specificità sta nel fatto che, in un breve intervallo di tempo, viene avviato un gran numero di thread che aggiornano intensamente i parameterset e lavorano con il database repository, mentre le risorse hardware del server vengono utilizzate praticamente al massimo della CPU.
Ora siamo giunti a un passo dal passaggio a Informatica 10.2.1 o 10.2.2, in cui sono stati rielaborati alcuni meccanismi interni, e l'assistenza promette l'assenza di una serie di attuali problemi di prestazioni e funzionamento. E anche dal punto di vista hardware, ci si aspettano server di configurazione ottimale per noi, tenendo conto della riserva per il prossimo futuro a causa della crescita e dello sviluppo dello storage.
Naturalmente, ci sarà un test, una verifica della compatibilità e, probabilmente, modifiche architettoniche per quanto riguarda l'HA GRID. Lo sviluppo nell'ambito di Informatica continuerà, poiché nel breve termine non possiamo sostituire il sistema.
E coloro che in futuro saranno responsabili di questo sistema saranno sicuramente in grado di portarlo ai livelli richiesti di affidabilità e prestazioni richiesti dai clienti.
Articolo preparato dal team di gestione dei dati di «Rostelecom»
Logo attuale di Informatica
Fonte: habr.com
