Многія выкарыстоўваюць спецыялізаваныя інструменты для стварэння працэдур здабывання, трансфармацыі і загрузкі даных у рэляцыйныя базы даных. Працэс працы прылад лагуецца, памылкі фіксуюцца.
У выпадку памылкі ў логу ўтрымоўваецца інфармацыя аб тым, што прыладзе не атрымалася выканаць задачу і якія модулі (часта гэта java) дзе спыніліся. У апошніх радках можна знайсці памылку базы дадзеных, напрыклад, парушэнне ўнікальнага ключа табліцы.
Каб адказаць на пытанне, якую ролю гуляе інфармацыя пра памылкі ETL, я класіфікаваў усе праблемы, якія адбыліся за апошнія два гады ў немаленькім сховішчы.
Да памылак базы дадзеных адносяцца такія, як не хапіла месца, абарвалася злучэнне, завісла сесія і да т.п.
Да лагічных памылак адносяцца такія, як парушэнне ключоў табліцы, не валідныя аб'екты, адсутнасць доступу да аб'ектаў і да т.п.
Планавальнік можа быць запушчаны не ў час, можа завіснуць і да т.п.
Простыя памылкі не патрабуюць шмат часу на выпраўленне. З большай іх часткай добры ETL умее спраўляцца самастойна.
Складаныя памылкі выклікаюць неабходнасць адчыняць і правяраць працэдуры працы з дадзенымі, даследаваць крыніцы дадзеных. Часта прыводзяць да неабходнасці тэсціравання змяненняў і дэплойменту.
Такім чынам, палова ўсіх праблем злучана з базай дадзеных. 48% усіх памылак - гэта простыя памылкі.
Трэцяя частка ўсіх праблем звязана са змяненнем логікі або мадэлі сховішчы, больш за палову гэтых памылак з'яўляюцца складанымі.
І менш за чвэрць усіх праблем звязана з планавальнікам задач, 18% якіх - гэта простыя памылкі.
У цэлым, 22% усіх якія здарыліся памылак з'яўляюцца складанымі, іх выпраўленне патрабуе найвялікай увагі і часу. Адбываюцца яны прыкладна раз на тыдзень. У той час, як простыя памылкі здараюцца амаль кожны дзень.
Відавочна, што маніторынг ETL-працэсаў будзе тады эфектыўным, калі ў логу максімальна сапраўды паказана месца памылкі і патрабуецца мінімальнае час на пошук крыніцы праблемы.
Эфектыўны маніторынг
Што мне хацелася бачыць у працэсе маніторынгу ETL?
Start at - калі пачаў працу,
Source - крыніца дадзеных,
Layer - які ўзровень сховішча загружаецца,
ETL Job Name - пацэдура загрузкі, якая складаецца з мноства дробных крокаў,
Step Number - нумар выкананага кроку,
Affected Rows – колькі дадзеных ужо апрацавалася,
Duration sec - як доўга выконваецца,
Status – ці ўсё добра ці не: OK, ERROR, RUNNING, HANGS
Message - апошняе паспяховае паведамленне або апісанне памылкі.
На падставе статуса запісаў можна даслаць эл. ліст іншым удзельнікам. Калі памылак няма, то і ліст не абавязкова.
Такім чынам, у выпадку памылкі дакладна пазначана месца здарэння.
Часам здараецца, што сама прылада маніторынгу не працуе. У такім выпадку ёсць магчымасць прама ў базе дадзеных выклікаць уяўленне (люхту), на падставе якой пабудаваны справаздачу.
Табліца маніторынгу ETL
Каб рэалізаваць маніторынг ETL-працэсаў дастаткова адной табліцы і аднаго прадстаўлення.
Для гэтага можна вярнуцца ў і стварыць прататып у базе дадзеных sqlite.
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);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 Праверка магчымасці атрымаць новы нумар сесіі
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Асаблівасці табліцы:
- пачатак і канец працэдуры апрацоўкі дадзеных павінен суправаджацца крокамі ETL_START і ETL_END
- у выпадку памылкі павінен стварацца крок ETL_ERROR з яе апісаннем
- колькасць апрацаваных дадзеных трэба вылучыць, напрыклад, зорачкамі
- адначасова адну і тую ж працэдуру можна запусціць з параметрам force_restart=y, без яго нумар сесіі выдаецца толькі завершанай працэдуры
- у звычайным рэжыме нельга запусціць раўналежна адну і тужэй працэдуру апрацоўкі дадзеных
Неабходнымі аперацыямі працы з табліцай з'яўляюцца наступныя:
- атрыманне нумара сесіі запускаемай працэдуры ETL
- устаўка запісу лога ў табліцу
- атрыманне апошняга паспяховага запісу працэдуры ETL
У такіх базах дадзеных, як, напрыклад, Oracle ці Postgres гэтыя аперацыі можна рэалізаваць убудаванымі функцыямі. Для sqlite неабходны вонкавы механізм і ў дадзеным выпадку ён .
Выснова
Такім чынам, паведамленні аб памылках у прыладах апрацоўкі дадзеных гуляюць мега-важную ролю. Але аптымальнымі для хуткага пошуку прычыны праблемы іх цяжка назваць. Калі колькасць працэдур набліжаецца да сотні, то маніторынг працэсаў ператвараецца ў складаны праект.
У артыкуле прыведзены прыклад магчымага рашэння праблемы ў выглядзе прататыпа. Увесь прататып маленькага сховішча даступны ў gitlab .
Крыніца: habr.com