ډیری خلک د اړونده ډیټابیسونو کې د ډیټا ایستلو ، بدلولو او بارولو لپاره معمول رامینځته کولو لپاره ځانګړي وسیلې کاروي. د وسیلو پروسه ننوتنه شوې ، غلطۍ ثبت شوي.
د تېروتنې په صورت کې، لاګ معلومات لري چې وسیله د دندې په بشپړولو کې پاتې راغلې او کوم ماډلونه (اکثرا جاوا) چیرته ودریدل. په وروستي کرښو کې ممکن د ډیټابیس تېروتنه وي، لکه د میز د ځانګړي کیلي څخه سرغړونه.
د دې پوښتنې ځواب لپاره چې د 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 یو بهرني میکانیزم ته اړتیا لري او پدې حالت کې دا .
پایلې
په دې توګه، د معلوماتو پروسس کولو وسیلو کې د تېروتنې راپور ورکول یو لوی مهم رول لوبوي. مګر دوی په سختۍ سره د ستونزې د علت موندلو لپاره غوره بلل کیدی شي. کله چې د پروسیجرونو شمیر سل ته ورسیږي، د پروسې څارنه په یوه پیچلې پروژه بدلیږي.
مقاله د پروټوټایپ په بڼه د ستونزې لپاره د ممکنه حل یوه بیلګه وړاندې کوي. د کوچني ذخیره ټول پروټوټایپ په ګیټلاب کې شتون لري .
سرچینه: www.habr.com