Ихэнх нь өгөгдлийг задлах, хувиргах, харилцааны мэдээллийн сан руу ачаалах процедурыг бий болгохын тулд тусгай хэрэгслийг ашигладаг. Ажлын багаж хэрэгслийн үйл явцыг бүртгэж, алдааг зассан.
Алдаа гарсан тохиолдолд уг хэрэгсэл нь даалгавраа гүйцэтгэж чадаагүй, аль модулиуд (ихэвчлэн java) хаана зогссон тухай мэдээллийг бүртгэлд агуулна. Сүүлийн мөрөнд та мэдээллийн сангийн алдаа, жишээлбэл, хүснэгтийн өвөрмөц түлхүүрийн зөрчлийг олж болно.
ETL алдааны мэдээлэл ямар үүрэг гүйцэтгэдэг вэ гэсэн асуултад хариулахын тулд би сүүлийн хоёр жилийн хугацаанд гарсан бүх асуудлыг нэлээд том санд ангилсан.
Өгөгдлийн сангийн алдаанууд нь хангалттай зай байхгүй, холболт тасарсан, сесс гацсан гэх мэт.
Логик алдаанууд нь хүснэгтийн товчлууруудыг зөрчсөн, хүчин төгөлдөр бус объект, объект руу нэвтрэх боломжгүй гэх мэт орно.
Төлөвлөгч нь цагтаа эхлэхгүй, хөлдөх гэх мэт.
Энгийн алдааг засахад удаан хугацаа шаардагдахгүй. Сайн ETL нь ихэнхийг нь өөрөө зохицуулж чадна.
Нарийн төвөгтэй алдаанууд нь өгөгдөлтэй ажиллах процедурыг илрүүлэх, турших, мэдээллийн эх сурвалжийг судлах шаардлагатай болгодог. Ихэнхдээ өөрчлөлтийг турших, байршуулах хэрэгцээнд хүргэдэг.
Тэгэхээр бүх асуудлын тал нь мэдээллийн сантай холбоотой байдаг. Нийт алдааны 48% нь энгийн алдаа байдаг.
Бүх асуудлын гуравны нэг нь санах ойн логик эсвэл загварыг өөрчлөхтэй холбоотой байдаг бөгөөд эдгээр алдааны талаас илүү хувь нь нарийн төвөгтэй байдаг.
Бүх асуудлын дөрөвний нэгээс бага хувь нь даалгавар төлөвлөгчтэй холбоотой байдаг бөгөөд үүний 18% нь энгийн алдаа юм.
Ерөнхийдөө бүх алдааны 22% нь нарийн төвөгтэй байдаг бөгөөд тэдгээрийг засах нь хамгийн их анхаарал, цаг хугацаа шаарддаг. Тэд долоо хоногт нэг удаа тохиолддог. Харин энгийн алдаа бараг өдөр бүр гардаг.
Алдааны байршлыг бүртгэлд аль болох үнэн зөв зааж, асуудлын эх үүсвэрийг олоход хамгийн бага хугацаа шаардагдах үед ETL процессын хяналт нь үр дүнтэй байх нь ойлгомжтой.
Үр дүнтэй хяналт
Би ETL хяналтын үйл явцад юу харахыг хүссэн бэ?
Эхлэх - тэр ажил эхлэхэд,
Эх сурвалж - мэдээллийн эх сурвалж,
Давхарга - ямар түвшний хадгалалт ачаалагдаж байна,
ETL ажлын нэр - олон жижиг алхмуудаас бүрдсэн байршуулах журам,
Алхам дугаар - хийж буй алхамын тоо,
Нөлөөлөлд өртсөн мөрүүд - хэр их өгөгдлийг аль хэдийн боловсруулсан,
Үргэлжлэх хугацаа секунд - хэр их хугацаа шаардагдах вэ,
Статус - бүх зүйл сайхан байна уу, үгүй юу: ЗА, АЛДАА, ГҮЙЖ БАЙНА, ӨГЖ БАЙНА
Зурвас - Сүүлийн амжилттай мессеж эсвэл алдааны тайлбар.
Бүртгэлийн төлөвт үндэслэн та имэйл илгээх боломжтой. бусад гишүүдэд захидал. Хэрэв алдаа байхгүй бол захидал бичих шаардлагагүй.
Тиймээс алдаа гарсан тохиолдолд үйл явдлын байршлыг тодорхой зааж өгдөг.
Заримдаа хяналтын хэрэгсэл өөрөө ажиллахгүй байх тохиолдол гардаг. Энэ тохиолдолд өгөгдлийн санд шууд харагдац (харагдах байдал) дуудах боломжтой бөгөөд үүний үндсэн дээр тайланг бүтээдэг.
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 дээр авах боломжтой .
Эх сурвалж: www.habr.com