La componente ETL del data warehouse è spesso messa in ombra dal warehouse stesso e riceve meno attenzione rispetto al database principale o al componente front-end, alla BI e al reporting. Allo stesso tempo, dal punto di vista della meccanica di riempimento del magazzino con i dati, ETL gioca un ruolo chiave e richiede non meno attenzione da parte degli amministratori rispetto ad altri componenti. Mi chiamo Alexander, ora amministro ETL presso Rostelecom e in questo articolo cercherò di condividere un po 'di ciò che deve affrontare l'amministratore di uno dei sistemi ETL più famosi in un grande data warehouse di Rostelecom.
Se cari lettori avete già familiarità in generale con il nostro progetto di data warehouse e con il prodotto Informatica PowerCenter, allora potete passare subito alla sezione successiva.
Diversi anni fa, l'idea di un unico data warehouse aziendale è maturata e ha iniziato ad essere implementata in Rostelecom. Erano già stati creati diversi archivi che risolvevano problemi individuali, ma il numero degli scenari è cresciuto, anche i costi di supporto sono aumentati ed è diventato chiaro che il futuro risiede nella centralizzazione. Dal punto di vista architettonico, questo è lo storage stesso, costituito da diversi livelli, implementati su Hadoop e GreenPlum, database ausiliari, meccanismi ETL e BI.
Allo stesso tempo, a causa del gran numero di fonti dati eterogenee e distribuite geograficamente, è stato creato uno speciale meccanismo di caricamento dei dati, il cui funzionamento è controllato da Informatica. Di conseguenza, i pacchetti di dati finiscono nell'area dell'interfaccia Hadoop, dopodiché iniziano i processi di caricamento dei dati attraverso i livelli di archiviazione, Hadoop e GreenPlum, e sono controllati dal cosiddetto meccanismo di controllo ETL implementato in Informatica. Pertanto, il sistema Informatica è uno degli elementi chiave che garantisce il funzionamento del magazzino.
Il nostro storage sarà descritto più dettagliatamente in uno dei post seguenti.
Informatica PowerCenter/Big Data Management è attualmente considerato il software leader nel campo degli strumenti di integrazione dati. Questo è un prodotto dell'azienda americana Informatica, che è uno dei più forti attori nell'ETL (Extract Transform Load), nella gestione della qualità dei dati, nell'MDM (Master Data Management), nell'ILM (Information Lifecycle Management) e altro ancora.
Il PowerCenter da noi utilizzato è un application server Tomcat integrato nel quale girano le stesse applicazioni Informatica, implementandone i servizi:
Dominio, infatti, questa è la base per tutto il resto; all'interno del dominio operano servizi, utenti e componenti GRID.
Console amministratore, uno strumento di gestione e monitoraggio basato sul web, oltre al client Informatica Developer, lo strumento principale per interagire con il prodotto
MRS, servizio di archivio di modelli, un repository di metadati, è un livello tra il database in cui sono archiviati fisicamente i metadati e il client Informatica Developer in cui avviene lo sviluppo. I repository memorizzano descrizioni di dati e altre informazioni, anche per una serie di altri servizi Infromatica, ad esempio, pianificazioni per l'esecuzione di attività (Schedules) o dati di monitoraggio, nonché parametri dell'applicazione, in particolare, consentendo l'utilizzo della stessa applicazione per lavorare con varie fonti di dati e ricevitori.
DIS, Servizio Integrazione Dati, si tratta di un servizio in cui hanno luogo i principali processi funzionali, le applicazioni in esso eseguite e i veri e propri lanci di Workflow (descrizioni della sequenza delle mappature e delle loro interazioni) e Mappature (trasformazioni, blocchi in cui avvengono le trasformazioni stesse, elaborazioni dei dati ) avere luogo.
Configurazione GRIGLIA – in sostanza, un'opzione per costruire un complesso utilizzando più server, quando il carico lanciato da DIS è distribuito tra i nodi (cioè i server che fanno parte del dominio). Nel caso di questa opzione, oltre a distribuire il carico in DIS attraverso un ulteriore livello di astrazione GRID che unisce più nodi, su cui DIS gira invece di lavorare su un singolo nodo specifico, possono anche essere create ulteriori istanze MRS di backup. Puoi anche implementare l'alta disponibilità, dove le chiamate esterne possono essere effettuate tramite nodi di backup se quello principale fallisce. Per ora abbiamo abbandonato questa opzione di costruzione.
Informatica PowerCenter, schema
Nelle prime fasi del lavoro nell'ambito della catena di fornitura dei dati sorgevano regolarmente problemi, in parte dovuti al funzionamento instabile di Informatica in quel momento. Condividerò alcuni dei momenti memorabili di questa saga: padroneggiare Informatica 10.
Ex logo di Informatica
La nostra area di responsabilità comprende anche altri ambienti Informatica, hanno le loro specificità a causa di un carico diverso, ma per ora ricorderò esattamente come Informatica si è sviluppata come componente ETL del data warehouse stesso.
Come è successo
Nel 2016, quando siamo diventati responsabili del lavoro di Informatica, aveva già raggiunto la versione 10.0, e per i colleghi ottimisti che stavano decidendo di utilizzare un prodotto con una versione minore .0 in una soluzione seria, tutto sembrava ovvio: dobbiamo usare la nuova versione! Dal punto di vista delle risorse hardware a quel tempo andava tutto bene.
Dalla primavera del 2016, un appaltatore è responsabile del lavoro di Informatica e, secondo i pochi utenti del sistema, "lavorava un paio di volte a settimana". Qui è necessario chiarire che il repository era di fatto in fase PoC, non c'erano amministratori nel team e il sistema andava costantemente in crash per vari motivi, dopodiché l'ingegnere dell'appaltatore lo ha ripreso.
In autunno, tre amministratori si sono uniti al team, dividendo tra loro le aree di responsabilità, e sono iniziati i normali lavori per organizzare il funzionamento dei sistemi del progetto, inclusa Informatica. A parte, va detto che questo prodotto non è molto diffuso e dispone di una vasta community in cui è possibile trovare risposte a qualsiasi domanda e risolvere qualsiasi problema. Pertanto, è stato molto importante il supporto tecnico completo da parte del partner russo Informatica, con l'aiuto del quale sono stati corretti tutti i nostri errori ed errori dell'allora giovane Informatica 10.
La prima cosa che dovevamo fare per gli sviluppatori del nostro team e per il contraente era stabilizzare il lavoro di Informatica stessa, per garantire la funzionalità della console di amministrazione web (Informatica Administrator).
È così che spesso incontravamo gli sviluppatori di Informatica
Lasciando da parte la ricerca delle ragioni, il motivo principale dei crash è stato il modello di interazione del software Informatica con il database del repository, che si trovava su un server relativamente remoto, dal punto di vista del panorama della rete. Ciò ha causato ritardi e interrotto i meccanismi che monitorano lo stato del dominio Informatica. Dopo qualche messa a punto del database, la modifica dei parametri di Informatica, che lo ha reso più tollerante ai ritardi del database, e infine l'aggiornamento della versione di Informatica alla 10.1 e il trasferimento del database dal server precedente a un server situato più vicino a Informatica, il problema ha perso la sua rilevanza. rilevanza, e da allora ci sono stati incidenti di questo tipo che non osserviamo.
Uno dei tentativi per far funzionare Informatica Monitor
Anche la situazione con la console di amministrazione era critica. Poiché lo sviluppo attivo era in corso direttamente in un ambiente relativamente produttivo, i colleghi avevano costantemente bisogno di analizzare il lavoro di mappatura e il flusso di lavoro “in movimento”. Nella nuova Informatica, il Data Integration Service non dispone di uno strumento separato per tale monitoraggio, ma è apparsa una sezione di monitoraggio nella console web di amministrazione (Informatica Administrator Monitor), in cui è possibile monitorare il funzionamento delle applicazioni, dei flussi di lavoro e delle mappature, lanci, registri. Periodicamente, la console diventava completamente non disponibile oppure le informazioni sui processi correnti in DIS smettevano di aggiornarsi oppure si verificavano errori durante il caricamento delle pagine.
Selezione dei parametri Java per stabilizzare il funzionamento
Il problema è stato corretto in molti modi, sono stati condotti esperimenti per modificare i parametri, sono stati raccolti log e jstack, inviati al supporto, allo stesso tempo c'era ricerca attiva su Google e semplice osservazione.
Innanzitutto, è stato creato un MRS separato per il monitoraggio; come si è scoperto in seguito, questo è uno dei principali consumatori di risorse nei nostri ambienti, poiché le mappature vengono eseguite in modo molto intenso. I parametri relativi all'heap Java e molti altri sono stati modificati.
Di conseguenza, con il successivo aggiornamento Informatica 10.1.1, il funzionamento della console e del monitor è stato stabilizzato, gli sviluppatori hanno iniziato a lavorare in modo più efficiente e i processi regolari sono diventati sempre più regolari.
Può essere interessante l'esperienza di interazione tra sviluppo e amministrazione. La questione di una comprensione generale di come funzionano le cose, cosa si può fare e cosa non si può fare, è sempre importante quando si utilizzano sistemi complessi. Pertanto, possiamo tranquillamente consigliare di formare prima il team amministrativo su come amministrare il software e il team di sviluppo su come scrivere codice e disegnare processi nel sistema, e solo successivamente inviare il primo e il secondo a lavorare sul risultato. Questo è davvero importante quando il tempo non è una risorsa infinita. Molti problemi possono essere risolti anche con una ricerca casuale di opzioni, ma a volte alcuni richiedono una conoscenza a priori: il nostro caso conferma l'importanza di comprendere questo assioma.
Ad esempio, quando abbiamo provato ad abilitare il controllo delle versioni in MRS (come alla fine si è scoperto che era necessaria una versione diversa di SVN), dopo un po' di tempo abbiamo scoperto con allarme che il tempo di riavvio del sistema era aumentato fino a diverse decine di minuti. Individuato il motivo del ritardo nell'avvio e disattivato il controllo delle versioni, abbiamo fatto nuovamente bene.
Gli ostacoli notevoli associati a Informatica includono l'epica battaglia con i thread Java in crescita. Ad un certo punto, è giunto il momento della replica, cioè dell’estensione dei processi stabiliti a un gran numero di sistemi sorgente. Si è scoperto che non tutti i processi nella versione 10.1.1 funzionavano bene e dopo qualche tempo DIS è diventato inutilizzabile. Sono stati rilevati decine di migliaia di thread, il cui numero è aumentato in modo particolarmente evidente durante la procedura di distribuzione dell'applicazione. A volte dovevo riavviare più volte al giorno per ripristinare la funzionalità.
Qui dobbiamo ringraziare il supporto; i problemi sono stati localizzati e risolti in tempi relativamente brevi utilizzando EBF (Emergency Bug Fix) - dopodiché tutti hanno avuto la sensazione che lo strumento funziona davvero.
Funziona ancora!
Quando abbiamo iniziato a lavorare in modalità target, Informatica si presentava così. Versione di Informatica 10.1.1HF1 (HF1 è HotFix1, un assembly del fornitore da un complesso di EBF) con EBF installato aggiuntivo, che corregge i nostri problemi con il ridimensionamento e alcuni altri, su un server su tre che facevano parte di GRID, 20 x86_64 core e archiviazione, su un enorme array lento di dischi locali: questa è la configurazione del server per un cluster Hadoop. Su un altro server simile: il DBMS Oracle con cui funzionano sia il dominio Informatica che il meccanismo di controllo ETL. Tutto questo è monitorato dagli strumenti di monitoraggio standard utilizzati nel team (Zabbix + Grafana) da entrambe le parti: Informatica stessa con i suoi servizi e i processi di caricamento che vi partecipano. Ora sia le prestazioni che la stabilità, senza tener conto dei fattori esterni, dipendono ora dalle impostazioni che limitano il carico.
Separatamente, possiamo dire di GRID. L'ambiente è stato realizzato su tre nodi, con possibilità di bilanciamento del carico. Tuttavia, durante i test, si è scoperto che a causa di problemi di interazione tra le istanze in esecuzione delle nostre applicazioni, questa configurazione non funzionava come previsto, e si è deciso di abbandonare temporaneamente questo schema di costruzione, rimuovendo due dei tre nodi dal dominio. Allo stesso tempo, lo schema stesso è rimasto lo stesso, e ora è proprio un servizio GRID, ma degenerato in un nodo.
Al momento, la difficoltà rimane associata a un calo delle prestazioni durante la pulizia regolare del circuito del monitor: con processi simultanei nella CNN e la pulizia in corso, potrebbero verificarsi malfunzionamenti nel funzionamento del meccanismo di controllo ETL. Attualmente il problema viene risolto “come una stampella” - cancellando manualmente il circuito del monitor, con la perdita di tutti i dati precedenti. Ciò non è troppo critico per la produttività, durante le normali operazioni di routine, ma per ora è in corso la ricerca di una soluzione normale.
Da questa stessa situazione sorge un altro problema: a volte si verificano più lanci del nostro meccanismo di controllo.
Avvii multipli di applicazioni che portano al fallimento del meccanismo
Quando si esegue secondo un programma, nei momenti di carico pesante del sistema, a volte si verificano situazioni che portano alla rottura del meccanismo. Il problema viene ancora risolto manualmente e si sta cercando una soluzione permanente.
In generale possiamo riassumere che quando c'è un carico pesante, è molto importante fornire risorse adeguate allo stesso, questo vale anche per le risorse hardware per Informatica stessa, e lo stesso per il suo repository di database, oltre a fornire impostazioni ottimali per loro. Inoltre, rimane aperta la questione su quale schema di posizionamento del database sia migliore: su un host separato o sullo stesso su cui viene eseguito il software Informatica. Da un lato costerà meno su un server e, in combinazione, il possibile problema con l'interazione di rete viene praticamente eliminato, dall'altro il carico sull'host dal database viene integrato dal carico di Informatica.
Come ogni prodotto serio, Informatica ha anche momenti divertenti.
Una volta, mentre risolvevo un incidente, ho notato che i registri MRS indicavano stranamente l'ora degli eventi.
Dualismo temporale nei log MRS “by design”
Si è scoperto che i timestamp sono scritti nel formato 12 ore, senza specificare AM/PM, cioè prima di mezzogiorno o dopo. È stata persino aperta una domanda in merito a questo argomento ed è stata ricevuta una risposta ufficiale: questo è ciò che era previsto, i voti sono scritti nel registro MRS esattamente in questo formato. Cioè, a volte rimane qualche intrigo riguardo al momento in cui si è verificato qualche ERRORE...
Puntare per il meglio
Oggi Informatica è uno strumento abbastanza stabile, conveniente per amministratori e utenti, estremamente potente in termini di capacità e potenzialità attuali. Supera molte volte le nostre esigenze funzionali e di fatto viene ora utilizzato nel progetto in un modo che non è il più tipico e tipico. Le difficoltà sono in parte legate al modo in cui funzionano i meccanismi: la cosa specifica è che in un breve periodo di tempo vengono avviati un gran numero di thread che aggiornano intensamente i parametri e lavorano con il database del repository, mentre le risorse hardware del server vengono utilizzate quasi completamente dalla CPU.
Siamo ormai prossimi al passaggio a Informatica 10.2.1 o 10.2.2, che ha rielaborato alcuni meccanismi interni e il supporto promette di eliminare alcuni dei problemi di prestazioni e funzionalità che abbiamo attualmente. E dal punto di vista hardware ci aspettiamo server con una configurazione ottimale per noi, tenendo conto della riserva per il prossimo futuro dovuta alla crescita e allo sviluppo dello storage.
Naturalmente, ci saranno test, controlli di compatibilità ed eventualmente modifiche all'architettura nella parte HA GRID. Lo sviluppo all'interno di Informatica continuerà, poiché a breve termine non possiamo fornire nulla per sostituire il sistema.
E coloro che saranno responsabili di questo sistema in futuro saranno sicuramente in grado di portarlo agli indicatori di affidabilità e prestazioni richiesti proposti dai clienti.
L'articolo è stato preparato dal team di gestione dei dati di Rostelecom
Logo attuale di Informatica
Fonte: habr.com