{"id":37701,"date":"2019-10-31T22:19:10","date_gmt":"2019-10-31T19:19:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-etl-protsessov-v-malenkom-hranilishhe-dannyh\/"},"modified":"2019-10-31T22:19:10","modified_gmt":"2019-10-31T19:19:10","slug":"monitoring-etl-protsessov-v-malenkom-hranilishhe-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-etl-protsessov-v-malenkom-hranilishhe-dannyh","title":{"rendered":"Monitoraggio dei processi ETL in un piccolo data store","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Molti utilizzano strumenti specializzati per creare procedure di estrazione, trasformazione e caricamento dei dati in database relazionali. Il processo di utilizzo degli strumenti viene registrato e gli errori vengono documentati.<\/p>\n

In caso di errore, il log contiene informazioni su cosa ha impedito all'utensile di portare a termine il compito e quali moduli (spesso sono java) si sono bloccati. Nelle ultime righe si pu\u00f2 trovare l'errore del database, ad esempio, una violazione della chiave unica della tabella.<\/p>\n

Per rispondere alla domanda riguardo al ruolo delle informazioni sugli errori ETL, ho classificato tutti i problemi verificatisi negli ultimi due anni in un considerevole data warehouse. <\/p>\n

\"Monitoraggio<\/a><\/noindex><\/p>\n

Gli errori di database includono situazioni come mancanza di spazio, connessione interrotta, sessione bloccata, e cos\u00ec via.<\/p>\n

Gli errori logici comprendono questioni come violazione delle chiavi di tabella, oggetti non validi, mancanza di accesso agli oggetti, ecc.
\nIl pianificatore pu\u00f2 essere avviato in ritardo, pu\u00f2 bloccarsi, e cos\u00ec via.<\/p>\n

Gli errori semplici non richiedono molto tempo per essere corretti. La maggior parte di essi un buon ETL riesce a gestirli autonomamente.<\/p>\n

Gli errori complessi richiedono l'apertura e il controllo delle procedure di gestione dei dati, l'esplorazione delle fonti di dati. Spesso portano alla necessit\u00e0 di testare le modifiche e fare il deployment.<\/p>\n

Quindi, met\u00e0 di tutti i problemi \u00e8 correlata al database. Il 48% di tutti gli errori sono semplici errori.
\nUn terzo di tutti i problemi \u00e8 legato al cambiamento della logica o del modello del data warehouse, la maggior parte di questi errori \u00e8 complessa.<\/p>\n

E meno di un quarto di tutti i problemi \u00e8 associato al pianificatore di attivit\u00e0, il 18% di questi sono errori semplici.<\/p>\n

In generale, il 22% di tutti gli errori registrati sono complessi, la loro correzione richiede il maggior tempo e attenzione. Si verificano circa una volta a settimana, mentre gli errori semplici accadono quasi ogni giorno.<\/p>\n

\u00c8 evidente che il monitoraggio dei processi ETL sar\u00e0 efficace solo quando il log indica con precisione il luogo dell'errore e richiede il minimo tempo per reperire la fonte del problema.<\/p>\n

Monitoraggio efficace<\/h4>\n

\nCosa mi piacerebbe vedere nel processo di monitoraggio ETL?<\/p>\n

\"Monitoraggio
\nStart at \u2014 quando ha iniziato a lavorare,
\nSource \u2014 fonte dei dati,
\nLayer \u2014 quale livello del data warehouse vieneCaricato,
\nETL Job Name \u2014 procedura di caricamento che consiste in molti piccoli passi,
\nStep Number \u2014 numero del passo eseguito,
\nAffected Rows \u2014 quanti dati sono gi\u00e0 stati elaborati,
\nDuration sec \u2014 quanto tempo impiega,
\nStatus \u2014 tutto bene o no: OK, ERROR, RUNNING, HANGS
\nMessage \u2014 ultimo messaggio riuscito o descrizione dell'errore.<\/p>\n

Sulla base dello stato dei record, \u00e8 possibile inviare un'email ad altri partecipanti. Se non ci sono errori, l'email non \u00e8 necessaria.<\/p>\n

In questo modo, in caso di errore, il luogo dell'incidente \u00e8 chiaramente indicato.<\/p>\n

A volte accade che lo stesso strumento di monitoraggio non funzioni. In tal caso, \u00e8 possibile richiamare direttamente il view nel database sul quale si basa il report.<\/p>\n

Tabella di monitoraggio ETL<\/h4>\n

\nPer implementare il monitoraggio dei processi ETL \u00e8 sufficiente una tabella e una vista.<\/p>\n

Per fare ci\u00f2, possiamo tornare nel il nostro piccolo data warehouse<\/a><\/noindex> e creare un prototipo nel database sqlite.<\/p>\n

DDL tabella<\/b><\/p>\n

CREATE TABLE UTL_JOB_STATUS (\n\/* Tabella per la registrazione del log di esecuzione del lavoro. \u00c8 importante che il lavoro abbia i passi ETL_START e ETL_END o ETL_ERROR *\/\n  UTL_JOB_STATUS_ID INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,\n  SID               INTEGER NOT NULL DEFAULT -1, \/* Identificatore di sessione. Unico per ogni esecuzione del lavoro *\/\n  LOG_DT            INTEGER NOT NULL DEFAULT 0,  \/* Data e ora *\/\n  LOG_D             INTEGER NOT NULL DEFAULT 0,  \/* Data *\/\n  JOB_NAME          TEXT NOT NULL DEFAULT 'N\/A', \/* Nome del lavoro come JOB_STG2DM_GEO *\/\n  STEP_NAME         TEXT NOT NULL DEFAULT 'N\/A', \/* ETL_START, ... , ETL_END\/ETL_ERROR *\/\n  STEP_DESCR        TEXT,                        \/* Descrizione del compito o messaggio d'errore *\/\n  UNIQUE (SID, JOB_NAME, STEP_NAME)\n);\nINSERT INTO UTL_JOB_STATUS (UTL_JOB_STATUS_ID) VALUES (-1);<\/code><\/pre>\n
\nDDL vista\/report<\/b><\/p>\n
CREA VISTA SE NON ESISTE UTL_JOB_STATUS_V\nAS \/* Contenuto: Log di Esecuzione del Pacchetto per gli ultimi 3 Mesi. *\/\nCON SRC AS (\n  SELEZIONA LOG_D,\n    LOG_DT,\n    UTL_JOB_STATUS_ID,\n    SID,\n\tCASE WHEN INSTR(JOB_NAME, 'FTP') THEN 'TRASFERIMENTO' \/* trasferimento file *\/\n\t     WHEN INSTR(JOB_NAME, 'STG') THEN 'STAGE' \/* fase *\/\n\t     WHEN INSTR(JOB_NAME, 'CLS') THEN 'PULIZIA' \/* pulizia *\/\n\t     WHEN INSTR(JOB_NAME, 'DIM') THEN 'DIMENSIONE' \/* dimensione *\/\n\t     WHEN INSTR(JOB_NAME, 'FCT') THEN 'FATTO' \/* fatto *\/\n\t\t WHEN INSTR(JOB_NAME, 'ETL') THEN 'STAGE-MART' \/* data mart *\/\n\t     WHEN INSTR(JOB_NAME, 'RPT') THEN 'REPORT' \/* report *\/\n\t     ELSE 'N\/A' END AS LAYER,\n\tCASE WHEN INSTR(JOB_NAME, 'ACCESS') THEN 'LOG ACCESSO' \/* sorgente *\/\n\t     WHEN INSTR(JOB_NAME, 'MASTER') THEN 'DATI MASTER' \/* sorgente *\/\n\t     WHEN INSTR(JOB_NAME, 'AD-HOC') THEN 'AD-HOC' \/* sorgente *\/\n\t     ELSE 'N\/A' END AS SOURCE,\n    JOB_NAME,\n    STEP_NAME,\n    CASE WHEN STEP_NAME='ETL_START' THEN 1 ELSE 0 END AS START_FLAG,\n    CASE WHEN STEP_NAME='ETL_END' THEN 1 ELSE 0 END AS END_FLAG,\n    CASE WHEN STEP_NAME='ETL_ERROR' THEN 1 ELSE 0 END AS ERROR_FLAG,\n    STEP_NAME || ' : ' || STEP_DESCR AS STEP_LOG,\n\tSUBSTR( SUBSTR(STEP_DESCR, INSTR(STEP_DESCR, '***')+4), 1, INSTR(SUBSTR(STEP_DESCR, INSTR(STEP_DESCR, '***')+4), '***')-2 ) AS AFFECTED_ROWS\n  DA UTL_JOB_STATUS\n  DOVE datetime(LOG_D, 'unixepoch') >= date('now', 'start of month', '-3 month')\n)\nSELEZIONA JB.SID,\n  JB.MIN_LOG_DT COME START_DT,\n  strftime('%d.%m.%Y %H:%M', datetime(JB.MIN_LOG_DT, 'unixepoch')) COME LOG_DT,\n  JB.SOURCE,\n  JB.LAYER,\n  JB.JOB_NAME,\n  CASE\n  WHEN JB.ERROR_FLAG = 1 ALLORA 'ERRORE'\n  WHEN JB.ERROR_FLAG = 0 E JB.END_FLAG = 0 E strftime('%s','now') - JB.MIN_LOG_DT > 0.5*60*60 ALLORA 'IN ATTESA' \/* mezz'ora *\/\n  WHEN JB.ERROR_FLAG = 0 E JB.END_FLAG = 0 ALLORA 'IN ESECUZIONE'\n  ELSE 'OK'\n  FINE COME STATO,\n  ERR.STEP_LOG     COME STEP_LOG,\n  JB.CNT           COME STEP_CNT,\n  JB.AFFECTED_ROWS COME AFFECTED_ROWS,\n  strftime('%d.%m.%Y %H:%M', datetime(JB.MIN_LOG_DT, 'unixepoch')) COME JOB_START_DT,\n  strftime('%d.%m.%Y %H:%M', datetime(JB.MAX_LOG_DT, 'unixepoch')) COME JOB_END_DT,\n  JB.MAX_LOG_DT - JB.MIN_LOG_DT COME JOB_DURATION_SEC\nDA\n  ( SELECT SID, SOURCE, LAYER, JOB_NAME,\n           MAX(UTL_JOB_STATUS_ID) COME UTL_JOB_STATUS_ID,\n           MAX(START_FLAG)       COME START_FLAG,\n           MAX(END_FLAG)         COME END_FLAG,\n           MAX(ERROR_FLAG)       COME ERROR_FLAG,\n           MIN(LOG_DT)           COME MIN_LOG_DT,\n           MAX(LOG_DT)           COME MAX_LOG_DT,\n           SUM(1)                COME CNT,\n           SUM(IFNULL(AFFECTED_ROWS, 0)) COME AFFECTED_ROWS\n    DA SRC\n    GROUP BY SID, SOURCE, LAYER, JOB_NAME\n  ) JB,\n  ( SELECT UTL_JOB_STATUS_ID, SID, JOB_NAME, STEP_LOG\n    DA SRC\n    DOVE 1 = 1\n  ) ERR\nDOVE 1 = 1\n  E JB.SID = ERR.SID\n  E JB.JOB_NAME = ERR.JOB_NAME\n  E JB.UTL_JOB_STATUS_ID = ERR.UTL_JOB_STATUS_ID\nORDINA PER JB.MIN_LOG_DT DESC, JB.SID DESC, JB.SOURCE;<\/code><\/pre>\n
\nVerifica SQL della possibilit\u00e0 di ottenere un nuovo numero di sessione<\/b><\/p>\n
SELEZIONA SOMMA (\n  CASE WHEN start_job.JOB_NAME IS NOT NULL E end_job.JOB_NAME IS NULL \/* il lavoro esistente \u00e8 terminato *\/\n\t    E NON ( 'y' = 'n' ) \/* forza riavvio PARAMETRO *\/\n       ALLORA 1 ELSE 0\n  FINE ) COME IS_RUNNING\n  DA\n    ( SELEZIONA 1 COME dummy DA UTL_JOB_STATUS DOVE sid = -1) d_job\n  LEFT OUTER JOIN\n    ( SELEZIONA JOB_NAME, SID, 1 COME dummy\n      DA UTL_JOB_STATUS\n      DOVE JOB_NAME = 'RPT_ACCESS_LOG' \/* nome lavoro PARAMETRO *\/\n\t    E STEP_NAME = 'ETL_START'\n      GROUP BY JOB_NAME, SID\n    ) start_job \/* inizio *\/\n  ON d_job.dummy = start_job.dummy\n  LEFT OUTER JOIN\n    ( SELEZIONA JOB_NAME, SID\n      DA UTL_JOB_STATUS\n      DOVE JOB_NAME = 'RPT_ACCESS_LOG'  \/* nome lavoro PARAMETRO *\/\n\t    E STEP_NAME in ('ETL_END', 'ETL_ERROR') \/* stato di fermo *\/\n      GROUP BY JOB_NAME, SID\n    ) end_job \/* fine *\/\n  ON start_job.JOB_NAME = end_job.JOB_NAME\n     E start_job.SID = end_job.SID<\/code><\/pre>\n
\nCaratteristiche della tabella:<\/p>\n