Bir çoxları məlumatların çıxarılması, çevrilməsi və əlaqəli verilənlər bazalarına yüklənməsi üçün prosedurlar yaratmaq üçün xüsusi vasitələrdən istifadə edirlər. İş alətləri prosesi qeyd olunur, səhvlər düzəldilir.
Səhv olduqda, jurnalda alətin tapşırığı yerinə yetirə bilmədiyi və hansı modulların (çox vaxt java) harada dayandığı barədə məlumatlar var. Son sətirlərdə verilənlər bazası səhvini, məsələn, cədvəlin unikal açarının pozulmasını tapa bilərsiniz.
ETL səhv məlumatının hansı rol oynadığı sualına cavab vermək üçün son iki il ərzində baş verən bütün problemləri kifayət qədər böyük bir depoda təsnif etdim.
Verilənlər bazası xətalarına kifayət qədər yer olmaması, əlaqənin itirilməsi, sessiyanın dayandırılması və s. daxildir.
Məntiqi səhvlərə masa açarlarının pozulması, etibarlı olmayan obyektlər, obyektlərə girişin olmaması və s.
Planlayıcı vaxtında başlamaya bilər, dondura bilər və s.
Sadə səhvləri düzəltmək çox vaxt çəkmir. Yaxşı bir ETL onların əksəriyyətini təkbaşına idarə edə bilər.
Mürəkkəb səhvlər verilənlərlə işləmək üçün prosedurları aşkar etməyi və sınaqdan keçirməyi, məlumat mənbələrini araşdırmağı zəruri edir. Tez-tez dəyişiklik testi və yerləşdirmə ehtiyacına səbəb olur.
Belə ki, bütün problemlərin yarısı verilənlər bazası ilə bağlıdır. Bütün səhvlərin 48%-i sadə səhvlərdir.
Bütün problemlərin üçdə biri saxlama məntiqinin və ya modelinin dəyişdirilməsi ilə bağlıdır, bu səhvlərin yarısından çoxu mürəkkəbdir.
Və bütün problemlərin dörddə birindən azı tapşırıq planlaşdırıcısı ilə bağlıdır, bunların 18% -i sadə səhvlərdir.
Ümumiyyətlə, baş verən bütün səhvlərin 22% -i mürəkkəbdir və onların düzəldilməsi ən çox diqqət və vaxt tələb edir. Onlar təxminən həftədə bir dəfə olur. Halbuki sadə səhvlər demək olar ki, hər gün olur.
Aydındır ki, xətanın yeri jurnalda mümkün qədər dəqiq göstərildikdə və problemin mənbəyini tapmaq üçün minimum vaxt tələb olunduqda ETL proseslərinin monitorinqi effektiv olacaqdır.
Effektiv monitorinq
ETL monitorinq prosesində mən nə görmək istəyirdim?
Başlayın - işə başlayanda,
Mənbə - məlumat mənbəyi,
Layer - hansı səviyyədə saxlama yüklənir,
ETL İş Adı - bir çox kiçik addımdan ibarət yükləmə proseduru,
Addım nömrəsi - yerinə yetirilən addımın nömrəsi,
Təsirə məruz qalan sətirlər - artıq nə qədər məlumat emal edilmişdir,
Müddət saniyə - nə qədər vaxt aparır,
Vəziyyət - hər şeyin yaxşı olub-olmamasından asılı olmayaraq: OK, ERROR, RUNING, ANGS
Mesaj - Son uğurlu mesaj və ya xətanın təsviri.
Qeydlərin statusuna əsasən siz e-poçt göndərə bilərsiniz. digər üzvlərə məktub. Heç bir səhv yoxdursa, məktub lazım deyil.
Beləliklə, xəta baş verdikdə, hadisənin yeri aydın şəkildə göstərilir.
Bəzən elə olur ki, monitorinq aləti özü işləmir. Bu halda, hesabatın qurulduğu məlumat bazasında birbaşa görünüşü (görünüşü) çağırmaq mümkündür.
ETL monitorinq cədvəli
ETL proseslərinin monitorinqini həyata keçirmək üçün bir cədvəl və bir görünüş kifayətdir.
Bunu etmək üçün geri qayıda bilərsiniz və sqlite verilənlər bazasında prototip yaradın.
DDL cədvəlləri
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-ə baxın/Report
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 Yeni sessiya nömrəsi əldə etməyin mümkün olub olmadığını yoxlayır
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.SIDCədvəlin xüsusiyyətləri:
- məlumat emalı prosedurunun başlanğıcı və sonu ETL_START və ETL_END addımları ilə izlənməlidir
- xəta baş verdikdə onun təsviri ilə ETL_ERROR addımı yaradılmalıdır
- işlənmiş məlumatların miqdarı, məsələn, ulduzlarla vurğulanmalıdır
- eyni prosedur force_restart=y parametri ilə eyni vaxtda başlana bilər, onsuz sessiya nömrəsi yalnız tamamlanmış prosedura verilir.
- normal rejimdə eyni verilənlərin emal prosedurunu paralel olaraq icra edə bilməzsiniz
Cədvəllə işləmək üçün lazım olan əməliyyatlar aşağıdakılardır:
- işləyən ETL prosedurunun sessiya nömrəsini əldə etmək
- cədvələ log girişini daxil edin
- ETL prosedurunun son uğurlu qeydini əldə etmək
Oracle və ya Postgres kimi verilənlər bazalarında bu əməliyyatlar daxili funksiyalar kimi həyata keçirilə bilər. sqlite xarici mexanizm tələb edir və bu halda .
Buraxılış
Beləliklə, məlumatların işlənməsi alətlərində səhv mesajları çox vacib rol oynayır. Ancaq problemin səbəbini tez tapmaq üçün onları optimal adlandırmaq çətindir. Prosedurların sayı yüzə yaxınlaşdıqda, prosesin monitorinqi mürəkkəb bir layihəyə çevrilir.
Məqalə prototip şəklində problemin mümkün həlli nümunəsini təqdim edir. Bütün kiçik repozitor prototipi gitlab-da mövcuddur .
Mənbə: www.habr.com