Shumë njerëz përdorin mjete të specializuara për të krijuar rutina për nxjerrjen, transformimin dhe ngarkimin e të dhënave në bazat e të dhënave relacionale. Procesi i mjeteve regjistrohet, gabimet regjistrohen.
Në rast gabimi, regjistri përmban informacion që mjeti dështoi për të përfunduar detyrën dhe cilat module (shpesh java) ndaluan ku. Rreshtat e fundit mund të përmbajnë një gabim të bazës së të dhënave, siç është një shkelje e çelësit unik të tabelës.
Për t'iu përgjigjur pyetjes se çfarë roli luan informacioni i gabimit ETL, i klasifikova të gjitha problemet që ndodhën gjatë dy viteve të fundit në një depo mjaft të madhe.
Gabimet e bazës së të dhënave përfshijnë si p.sh.: nuk kishte hapësirë të mjaftueshme, lidhja u humb, seanca u pezullua, etj.
Gabimet logjike përfshijnë shkelje të çelësave të tabelës, objekte të pavlefshme, mungesë aksesi në objekte, etj.
Planifikuesi mund të mos lansohet në kohë, mund të ngrijë, etj.
Gabimet e thjeshta nuk kërkojnë shumë kohë për t'u korrigjuar. Një ETL e mirë mund t'i trajtojë vetë shumicën prej tyre.
Gabimet komplekse e bëjnë të nevojshme hapjen dhe kontrollimin e procedurave të trajtimit të të dhënave dhe hetimin e burimeve të të dhënave. Shpesh çojnë në nevojën për të testuar ndryshimet dhe vendosjen.
Pra, gjysma e të gjitha problemeve janë të lidhura me bazën e të dhënave. 48% e të gjitha gabimeve janë gabime të thjeshta.
Një e treta e të gjitha problemeve lidhen me ndryshimet në logjikën ose modelin e ruajtjes; më shumë se gjysma e këtyre gabimeve janë komplekse.
Dhe më pak se një e katërta e të gjitha problemeve lidhen me planifikuesin e detyrave, 18% e të cilave janë gabime të thjeshta.
Në përgjithësi, 22% e të gjitha gabimeve që ndodhin janë komplekse dhe kërkojnë më shumë vëmendje dhe kohë për t'u korrigjuar. Ato ndodhin rreth një herë në javë. Ndërsa gabimet e thjeshta ndodhin pothuajse çdo ditë.
Natyrisht, monitorimi i proceseve ETL do të jetë efektiv kur vendndodhja e gabimit tregohet në regjistër sa më saktë që të jetë e mundur dhe kërkohet kohë minimale për të gjetur burimin e problemit.
Monitorim efektiv
Çfarë doja të shihja në procesin e monitorimit të ETL?
Filloni në - kur fillova të punoj,
Burimi - burimi i të dhënave,
Shtresa - cili nivel ruajtjeje është i ngarkuar,
ETL Job Name është një procedurë ngarkimi që përbëhet nga shumë hapa të vegjël,
Numri i hapit - numri i hapit që po ekzekutohet,
Rreshtat e prekur - sa të dhëna janë përpunuar tashmë,
Kohëzgjatja sekondë - sa kohë duhet për të ekzekutuar,
Statusi - nëse çdo gjë është mirë apo jo: OK, ERROR, RUNNING, HANGS
Mesazh - mesazhi i fundit i suksesshëm ose përshkrimi i gabimit.
Bazuar në statusin e të dhënave, mund të dërgoni një email. letër pjesëmarrësve të tjerë. Nëse nuk ka gabime, atëherë një letër nuk është e nevojshme.
Në këtë mënyrë, në rast gabimi, tregohet qartë vendndodhja e incidentit.
Ndonjëherë ndodh që vetë mjeti i monitorimit të mos funksionojë. Në këtë rast, është e mundur të thirret pamja (pamja) drejtpërdrejt në bazën e të dhënave, në bazë të së cilës është ndërtuar raporti.
Tabela e monitorimit ETL
Për të zbatuar monitorimin e proceseve ETL mjafton një tabelë dhe një pamje.
Për ta bërë këtë ju mund të ktheheni në dhe krijoni një prototip në bazën e të dhënave sqlite.
Tabelat 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);Shiko/raporto 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 Kontrollimi i aftësisë për të marrë një numër të ri sesioni
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.SIDKarakteristikat e tabelës:
- fillimi dhe përfundimi i procedurës së përpunimit të të dhënave duhet të shoqërohet me hapat ETL_START dhe ETL_END
- në rast gabimi, duhet të krijohet një hap ETL_ERROR me përshkrimin e tij
- sasia e të dhënave të përpunuara duhet të theksohet, për shembull, me yje
- e njëjta procedurë mund të fillohet në të njëjtën kohë me parametrin force_restart=y; pa të, numri i seancës i jepet vetëm procedurës së përfunduar
- në modalitetin normal është e pamundur të kryhet paralelisht e njëjta procedurë e përpunimit të të dhënave
Operacionet e nevojshme për të punuar me tabelën janë si më poshtë:
- marrja e numrit të seancës së procedurës ETL që po fillon
- futja e një hyrjeje regjistri në një tabelë
- marrjen e rekordit të fundit të suksesshëm të një procedure ETL
Në bazat e të dhënave si Oracle ose Postgres, këto operacione mund të zbatohen me funksione të integruara. sqlite kërkon një mekanizëm të jashtëm dhe në këtë rast atë .
Prodhim
Kështu, raportimi i gabimeve në mjetet e përpunimit të të dhënave luan një rol shumë të rëndësishëm. Por ato vështirë se mund të quhen optimale për të gjetur shpejt shkakun e problemit. Kur numri i procedurave i afrohet njëqind, monitorimi i procesit kthehet në një projekt kompleks.
Artikulli ofron një shembull të një zgjidhjeje të mundshme të problemit në formën e një prototipi. I gjithë prototipi i depove të vogla është i disponueshëm në gitlab .
Burimi: www.habr.com