Spremljanje ETL procesov v majhnem podatkovnem skladišču

Mnogi uporabljajo specializirana orodja za ustvarjanje postopkov za ekstrahiranje, preoblikovanje in nalaganje podatkov v relacijske zbirke podatkov. Proces delovnih orodij se beleži, napake so odpravljene.

V primeru napake dnevnik vsebuje informacije, da orodje ni uspelo dokončati naloge in kateri moduli (pogosto java) so se kje ustavili. V zadnjih vrsticah lahko najdete napako baze podatkov, na primer kršitev edinstvenega ključa tabele.

Da bi odgovoril na vprašanje, kakšno vlogo imajo informacije o napakah ETL, sem vse težave, ki so se pojavile v zadnjih dveh letih, razvrstil v precej veliko skladišče.

Spremljanje ETL procesov v majhnem podatkovnem skladišču

Napake zbirke podatkov vključujejo premalo prostora, izgubljeno povezavo, prekinitev seje itd.

Logične napake vključujejo kršitev ključev tabele, neveljavne objekte, pomanjkanje dostopa do objektov itd.
Razporejevalnik se morda ne zažene pravočasno, lahko zamrzne itd.

Popravljanje preprostih napak ne traja dolgo. Dober ETL jih zmore večino sam.

Zapleteni hrošči zahtevajo odkrivanje in testiranje postopkov za delo s podatki, raziskovanje virov podatkov. Pogosto vodi do potrebe po testiranju sprememb in uvajanju.

Polovica vseh težav je torej povezanih z bazo podatkov. 48 % vseh napak je preprostih napak.
Tretjina vseh težav je povezana s spreminjanjem logike ali modela shranjevanja, več kot polovica teh napak je kompleksnih.

Manj kot četrtina vseh težav je povezana z razporejevalnikom opravil, od tega je 18 % preprostih napak.

Na splošno je 22 % vseh napak, ki se pojavijo, kompleksnih in njihova odprava zahteva največ pozornosti in časa. Zgodijo se približno enkrat na teden. Medtem ko se preproste napake dogajajo skoraj vsak dan.

Očitno je, da bo spremljanje ETL procesov učinkovito, če je lokacija napake navedena v dnevniku čim bolj natančno in je potreben minimalen čas za iskanje vira težave.

Učinkovito spremljanje

Kaj sem želel videti v procesu spremljanja ETL?

Spremljanje ETL procesov v majhnem podatkovnem skladišču
Začeti ob - ko je začel delati,
Vir - vir podatkov,
Sloj – katera raven pomnilnika se nalaga,
ETL Job Name - postopek nalaganja, ki je sestavljen iz številnih majhnih korakov,
Številka koraka - številka koraka, ki se izvaja,
Prizadete vrstice – koliko podatkov je bilo že obdelanih,
Trajanje v sekundah - koliko časa traja,
Status - ali je vse v redu ali ne: OK, NAPAKA, TEČE, VISI
Sporočilo - zadnje uspešno sporočilo ali opis napake.

Glede na stanje evidence lahko pošljete e-pošto. pismo drugim članom. Če ni napak, pismo ni potrebno.

Tako je v primeru napake jasno označena lokacija dogodka.

Včasih se zgodi, da samo orodje za spremljanje ne deluje. V tem primeru je mogoče priklicati pogled (pogled) neposredno v bazi podatkov, na podlagi katere je zgrajeno poročilo.

Tabela za spremljanje ETL

Za izvedbo spremljanja ETL procesov sta dovolj ena tabela in en pogled.

Če želite to narediti, se lahko vrnete na vaš mali prostor za shranjevanje in ustvarite prototip v bazi podatkov sqlite.

tabele DDL

CREATE TABLE UTL_JOB_STATUS (
/* Table for logging of job execution log. Important that the job has the steps ETL_START and ETL_END or ETL_ERROR */
  UTL_JOB_STATUS_ID INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
  SID               INTEGER NOT NULL DEFAULT -1, /* Session Identificator. Unique for every Run of job */
  LOG_DT            INTEGER NOT NULL DEFAULT 0,  /* Date time */
  LOG_D             INTEGER NOT NULL DEFAULT 0,  /* Date */
  JOB_NAME          TEXT NOT NULL DEFAULT 'N/A', /* Job name like JOB_STG2DM_GEO */
  STEP_NAME         TEXT NOT NULL DEFAULT 'N/A', /* ETL_START, ... , ETL_END/ETL_ERROR */
  STEP_DESCR        TEXT,                        /* Description of task or error message */
  UNIQUE (SID, JOB_NAME, STEP_NAME)
);
INSERT INTO UTL_JOB_STATUS (UTL_JOB_STATUS_ID) VALUES (-1);

Ogled/poročilo DDL

CREATE VIEW IF NOT EXISTS UTL_JOB_STATUS_V
AS /* Content: Package Execution Log for last 3 Months. */
WITH SRC AS (
  SELECT LOG_D,
    LOG_DT,
    UTL_JOB_STATUS_ID,
    SID,
	CASE WHEN INSTR(JOB_NAME, 'FTP') THEN 'TRANSFER' /* file transfer */
	     WHEN INSTR(JOB_NAME, 'STG') THEN 'STAGE' /* stage */
	     WHEN INSTR(JOB_NAME, 'CLS') THEN 'CLEANSING' /* cleansing */
	     WHEN INSTR(JOB_NAME, 'DIM') THEN 'DIMENSION' /* dimension */
	     WHEN INSTR(JOB_NAME, 'FCT') THEN 'FACT' /* fact */
		 WHEN INSTR(JOB_NAME, 'ETL') THEN 'STAGE-MART' /* data mart */
	     WHEN INSTR(JOB_NAME, 'RPT') THEN 'REPORT' /* report */
	     ELSE 'N/A' END AS LAYER,
	CASE WHEN INSTR(JOB_NAME, 'ACCESS') THEN 'ACCESS LOG' /* source */
	     WHEN INSTR(JOB_NAME, 'MASTER') THEN 'MASTER DATA' /* source */
	     WHEN INSTR(JOB_NAME, 'AD-HOC') THEN 'AD-HOC' /* source */
	     ELSE 'N/A' END AS SOURCE,
    JOB_NAME,
    STEP_NAME,
    CASE WHEN STEP_NAME='ETL_START' THEN 1 ELSE 0 END AS START_FLAG,
    CASE WHEN STEP_NAME='ETL_END' THEN 1 ELSE 0 END AS END_FLAG,
    CASE WHEN STEP_NAME='ETL_ERROR' THEN 1 ELSE 0 END AS ERROR_FLAG,
    STEP_NAME || ' : ' || STEP_DESCR AS STEP_LOG,
	SUBSTR( SUBSTR(STEP_DESCR, INSTR(STEP_DESCR, '***')+4), 1, INSTR(SUBSTR(STEP_DESCR, INSTR(STEP_DESCR, '***')+4), '***')-2 ) AS AFFECTED_ROWS
  FROM UTL_JOB_STATUS
  WHERE datetime(LOG_D, 'unixepoch') >= date('now', 'start of month', '-3 month')
)
SELECT JB.SID,
  JB.MIN_LOG_DT AS START_DT,
  strftime('%d.%m.%Y %H:%M', datetime(JB.MIN_LOG_DT, 'unixepoch')) AS LOG_DT,
  JB.SOURCE,
  JB.LAYER,
  JB.JOB_NAME,
  CASE
  WHEN JB.ERROR_FLAG = 1 THEN 'ERROR'
  WHEN JB.ERROR_FLAG = 0 AND JB.END_FLAG = 0 AND strftime('%s','now') - JB.MIN_LOG_DT > 0.5*60*60 THEN 'HANGS' /* half an hour */
  WHEN JB.ERROR_FLAG = 0 AND JB.END_FLAG = 0 THEN 'RUNNING'
  ELSE 'OK'
  END AS STATUS,
  ERR.STEP_LOG     AS STEP_LOG,
  JB.CNT           AS STEP_CNT,
  JB.AFFECTED_ROWS AS AFFECTED_ROWS,
  strftime('%d.%m.%Y %H:%M', datetime(JB.MIN_LOG_DT, 'unixepoch')) AS JOB_START_DT,
  strftime('%d.%m.%Y %H:%M', datetime(JB.MAX_LOG_DT, 'unixepoch')) AS JOB_END_DT,
  JB.MAX_LOG_DT - JB.MIN_LOG_DT AS JOB_DURATION_SEC
FROM
  ( SELECT SID, SOURCE, LAYER, JOB_NAME,
           MAX(UTL_JOB_STATUS_ID) AS UTL_JOB_STATUS_ID,
           MAX(START_FLAG)       AS START_FLAG,
           MAX(END_FLAG)         AS END_FLAG,
           MAX(ERROR_FLAG)       AS ERROR_FLAG,
           MIN(LOG_DT)           AS MIN_LOG_DT,
           MAX(LOG_DT)           AS MAX_LOG_DT,
           SUM(1)                AS CNT,
           SUM(IFNULL(AFFECTED_ROWS, 0)) AS AFFECTED_ROWS
    FROM SRC
    GROUP BY SID, SOURCE, LAYER, JOB_NAME
  ) JB,
  ( SELECT UTL_JOB_STATUS_ID, SID, JOB_NAME, STEP_LOG
    FROM SRC
    WHERE 1 = 1
  ) ERR
WHERE 1 = 1
  AND JB.SID = ERR.SID
  AND JB.JOB_NAME = ERR.JOB_NAME
  AND JB.UTL_JOB_STATUS_ID = ERR.UTL_JOB_STATUS_ID
ORDER BY JB.MIN_LOG_DT DESC, JB.SID DESC, JB.SOURCE;

SQL Preverjanje, ali je mogoče dobiti novo številko seje

SELECT SUM (
  CASE WHEN start_job.JOB_NAME IS NOT NULL AND end_job.JOB_NAME IS NULL /* existed job finished */
	    AND NOT ( 'y' = 'n' ) /* force restart PARAMETER */
       THEN 1 ELSE 0
  END ) AS IS_RUNNING
  FROM
    ( SELECT 1 AS dummy FROM UTL_JOB_STATUS WHERE sid = -1) d_job
  LEFT OUTER JOIN
    ( SELECT JOB_NAME, SID, 1 AS dummy
      FROM UTL_JOB_STATUS
      WHERE JOB_NAME = 'RPT_ACCESS_LOG' /* job name PARAMETER */
	    AND STEP_NAME = 'ETL_START'
      GROUP BY JOB_NAME, SID
    ) start_job /* starts */
  ON d_job.dummy = start_job.dummy
  LEFT OUTER JOIN
    ( SELECT JOB_NAME, SID
      FROM UTL_JOB_STATUS
      WHERE JOB_NAME = 'RPT_ACCESS_LOG'  /* job name PARAMETER */
	    AND STEP_NAME in ('ETL_END', 'ETL_ERROR') /* stop status */
      GROUP BY JOB_NAME, SID
    ) end_job /* ends */
  ON start_job.JOB_NAME = end_job.JOB_NAME
     AND start_job.SID = end_job.SID

Lastnosti mize:

  • začetku in koncu postopka obdelave podatkov morata slediti koraka ETL_START in ETL_END
  • v primeru napake je treba ustvariti korak ETL_ERROR z njegovim opisom
  • količina obdelanih podatkov mora biti označena, na primer z zvezdicami
  • isti postopek je mogoče zagnati istočasno s parametrom force_restart=y, brez njega se številka seje izda le zaključenemu postopku
  • v običajnem načinu ne morete izvajati istega postopka obdelave podatkov vzporedno

Potrebne operacije za delo s tabelo so naslednje:

  • pridobivanje številke seje izvajajoče se procedure ETL
  • vstavite dnevniški vnos v tabelo
  • pridobivanje zadnjega uspešnega zapisa postopka ETL

V zbirkah podatkov, kot sta Oracle ali Postgres, je te operacije mogoče implementirati kot vgrajene funkcije. sqlite zahteva zunanji mehanizem in v tem primeru ga prototipiziran v PHP.

Izhod

Tako imajo sporočila o napakah v orodjih za obdelavo podatkov izjemno pomembno vlogo. Vendar jih je težko imenovati optimalne za hitro iskanje vzroka težave. Ko se število postopkov približa stoti, se spremljanje procesov spremeni v kompleksen projekt.

Članek podaja primer možne rešitve problema v obliki prototipa. Celoten prototip majhnega repozitorija je na voljo v gitlabu Pripomočki SQLite PHP ETL.

Vir: www.habr.com

Dodaj komentar