چھوٹے ڈیٹا گودام میں ای ٹی ایل کے عمل کی نگرانی

بہت سے لوگ متعلقہ ڈیٹا بیس میں ڈیٹا کو نکالنے، تبدیل کرنے اور لوڈ کرنے کے طریقہ کار بنانے کے لیے خصوصی ٹولز کا استعمال کرتے ہیں۔ کام کرنے والے ٹولز کا عمل لاگ ان ہوتا ہے، غلطیاں ٹھیک ہوجاتی ہیں۔

خرابی کی صورت میں، لاگ میں معلومات ہوتی ہے کہ ٹول کام مکمل کرنے میں ناکام رہا اور کون سے ماڈیول (اکثر جاوا) کہاں رک گئے۔ آخری لائنوں میں، آپ کو ڈیٹا بیس کی خرابی مل سکتی ہے، مثال کے طور پر، ایک ٹیبل منفرد کلید کی خلاف ورزی۔

اس سوال کا جواب دینے کے لیے کہ ای ٹی ایل کی غلطی کی معلومات کیا کردار ادا کرتی ہے، میں نے ان تمام مسائل کی درجہ بندی کی ہے جو پچھلے دو سالوں کے دوران پیش آئے ہیں ایک بڑے ذخیرہ میں۔

چھوٹے ڈیٹا گودام میں ای ٹی ایل کے عمل کی نگرانی

ڈیٹا بیس کی خرابیوں میں کافی جگہ نہ ہونا، کنکشن کھونا، سیشن ہینگ وغیرہ شامل ہیں۔

منطقی خرابیوں میں شامل ہیں جیسے ٹیبل کیز کی خلاف ورزی، غیر درست اشیاء، اشیاء تک رسائی کی کمی وغیرہ۔
شیڈولر وقت پر شروع نہیں ہو سکتا، یہ جم سکتا ہے، وغیرہ۔

معمولی غلطیوں کو ٹھیک ہونے میں دیر نہیں لگتی۔ ایک اچھا ETL ان میں سے بیشتر کو خود ہی سنبھال سکتا ہے۔

پیچیدہ کیڑے ڈیٹا کے ساتھ کام کرنے، ڈیٹا کے ذرائع کو دریافت کرنے کے لیے طریقہ کار کو دریافت کرنا اور جانچنا ضروری بناتے ہیں۔ اکثر تبدیلی کی جانچ اور تعیناتی کی ضرورت کا باعث بنتی ہے۔

لہذا، تمام مسائل میں سے نصف ڈیٹا بیس سے متعلق ہیں. تمام غلطیوں میں سے 48% سادہ غلطیاں ہیں۔
تمام مسائل کا ایک تہائی سٹوریج کی منطق یا ماڈل کو تبدیل کرنے سے متعلق ہے، ان میں سے نصف سے زیادہ خرابیاں پیچیدہ ہیں۔

اور تمام مسائل میں سے ایک چوتھائی سے بھی کم ٹاسک شیڈولر سے متعلق ہیں، جن میں سے 18% سادہ غلطیاں ہیں۔

عام طور پر، پیش آنے والی تمام خرابیوں میں سے 22% پیچیدہ ہوتی ہیں، اور ان کی اصلاح کے لیے سب سے زیادہ توجہ اور وقت درکار ہوتا ہے۔ وہ ہفتے میں ایک بار ہوتے ہیں۔ جبکہ معمولی غلطیاں تقریباً ہر روز ہوتی ہیں۔

ظاہر ہے، ای ٹی ایل کے عمل کی نگرانی اس وقت موثر ہو گی جب لاگ میں غلطی کی جگہ کو ہر ممکن حد تک درست طریقے سے ظاہر کیا جائے اور مسئلہ کا ماخذ تلاش کرنے کے لیے کم از کم وقت درکار ہو۔

موثر نگرانی

میں ای ٹی ایل کی نگرانی کے عمل میں کیا دیکھنا چاہتا تھا؟

چھوٹے ڈیٹا گودام میں ای ٹی ایل کے عمل کی نگرانی
شروع کریں - جب اس نے کام شروع کیا،
ماخذ - ڈیٹا سورس،
پرت - اسٹوریج کی کس سطح کو لوڈ کیا جا رہا ہے،
ای ٹی ایل جاب کا نام - اپ لوڈ کا طریقہ کار، جو بہت سے چھوٹے مراحل پر مشتمل ہوتا ہے،
مرحلہ نمبر - انجام دیئے جانے والے قدم کی تعداد،
متاثرہ قطاریں - کتنے ڈیٹا پر پہلے ہی کارروائی ہو چکی ہے،
دورانیہ سیکنڈ - کتنا وقت لگتا ہے،
حیثیت - چاہے سب کچھ ٹھیک ہے یا نہیں: ٹھیک ہے، خرابی، چل رہی ہے، ہینگس
پیغام - آخری کامیاب پیغام یا غلطی کی تفصیل۔

ریکارڈ کی حیثیت کی بنیاد پر، آپ ای میل بھیج سکتے ہیں۔ دوسرے اراکین کو خط. اگر کوئی غلطی نہیں ہے، تو خط ضروری نہیں ہے.

اس طرح غلطی کی صورت میں واقعہ کی جگہ واضح طور پر بتائی جاتی ہے۔

کبھی کبھی ایسا ہوتا ہے کہ مانیٹرنگ ٹول خود کام نہیں کرتا۔ اس صورت میں، ڈیٹا بیس میں براہ راست ایک منظر (ویو) کو کال کرنا ممکن ہے، جس کی بنیاد پر رپورٹ بنائی جاتی ہے۔

ای ٹی ایل مانیٹرنگ ٹیبل

ای ٹی ایل کے عمل کی نگرانی کو لاگو کرنے کے لئے، ایک میز اور ایک نقطہ نظر کافی ہے.

ایسا کرنے کے لیے، آپ پر واپس جا سکتے ہیں۔ آپ کا چھوٹا ذخیرہ اور sqlite ڈیٹا بیس میں پروٹو ٹائپ بنائیں۔

ڈی ڈی ایل ٹیبلز

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 طریقہ کار کا آخری کامیاب ریکارڈ حاصل کرنا

ڈیٹا بیس جیسے اوریکل یا پوسٹگریس میں، ان آپریشنز کو بلٹ ان فنکشنز کے طور پر لاگو کیا جا سکتا ہے۔ sqlite کو ایک بیرونی میکانزم کی ضرورت ہے، اور اس صورت میں یہ پی ایچ پی میں پروٹو ٹائپ.

آؤٹ پٹ

اس طرح، ڈیٹا پروسیسنگ ٹولز میں غلطی کے پیغامات ایک بڑا اہم کردار ادا کرتے ہیں۔ لیکن مسئلہ کی وجہ کو فوری طور پر تلاش کرنے کے لیے انہیں بہترین کہنا مشکل ہے۔ جب طریقہ کار کی تعداد سو تک پہنچ جاتی ہے، تو عمل کی نگرانی ایک پیچیدہ منصوبے میں بدل جاتی ہے۔

مضمون ایک پروٹو ٹائپ کی شکل میں مسئلے کے ممکنہ حل کی ایک مثال فراہم کرتا ہے۔ پورا چھوٹا ذخیرہ پروٹو ٹائپ gitlab میں دستیاب ہے۔ SQLite PHP ETL افادیت.

ماخذ: www.habr.com

نیا تبصرہ شامل کریں