ETL პროცესების მონიტორინგი მცირე მონაცემთა საწყობში

ბევრი იყენებს სპეციალიზებულ ინსტრუმენტებს მონაცემთა ამოღების, ტრანსფორმაციისა და რელაციურ მონაცემთა ბაზებში ჩატვირთვის პროცედურების შესაქმნელად. სამუშაო ინსტრუმენტების პროცესი აღრიცხულია, შეცდომები ფიქსირდება.

შეცდომის შემთხვევაში ჟურნალი შეიცავს ინფორმაციას იმის შესახებ, რომ ინსტრუმენტმა ვერ შეასრულა დავალება და რომელი მოდულები (ხშირად java) სად გაჩერდა. ბოლო სტრიქონებში შეგიძლიათ იპოვოთ მონაცემთა ბაზის შეცდომა, მაგალითად, ცხრილის უნიკალური გასაღების დარღვევა.

პასუხის გასაცემად, თუ რა როლს ასრულებს ETL შეცდომის შესახებ ინფორმაცია, მე დავახარისხე ყველა პრობლემა, რომელიც წარმოიშვა ბოლო ორი წლის განმავლობაში საკმაოდ დიდ საცავში.

მონაცემთა ბაზის შეცდომებს მოიცავს არასაკმარისი სივრცე, დაკარგული კავშირი, სესიის დაკიდება და ა.შ.

ლოგიკური შეცდომები მოიცავს მაგიდის კლავიშების დარღვევას, არასწორ ობიექტებს, ობიექტებზე წვდომის ნაკლებობას და ა.შ.
დაგეგმილი შეიძლება არ დაიწყოს დროულად, შეიძლება გაიყინოს და ა.შ.

მარტივი შეცდომების გამოსწორებას დიდი დრო არ სჭირდება. კარგ ETL-ს შეუძლია დამოუკიდებლად გაუმკლავდეს მათ უმეტესობას.

კომპლექსური შეცდომები საჭიროებს მონაცემებთან მუშაობის პროცედურების აღმოჩენას და ტესტირებას, მონაცემთა წყაროების შესწავლას. ხშირად იწვევს ცვლილებების ტესტირებისა და განლაგების აუცილებლობას.

ასე რომ, ყველა პრობლემის ნახევარი დაკავშირებულია მონაცემთა ბაზასთან. ყველა შეცდომის 48% მარტივი შეცდომაა.
ყველა პრობლემის მესამედი დაკავშირებულია შენახვის ლოგიკის ან მოდელის შეცვლასთან, ამ შეცდომების ნახევარზე მეტი რთულია.

და ყველა პრობლემის მეოთხედზე ნაკლები დაკავშირებულია დავალების განრიგთან, რომელთა 18% არის მარტივი შეცდომები.

ზოგადად, ყველა შეცდომის 22% კომპლექსურია და მათი გამოსწორება ყველაზე დიდ ყურადღებას და დროს მოითხოვს. ისინი დაახლოებით კვირაში ერთხელ ხდება. მაშინ როცა მარტივი შეცდომები თითქმის ყოველდღე ხდება.

აშკარაა, რომ ETL პროცესების მონიტორინგი ეფექტური იქნება მაშინ, როდესაც შეცდომის ადგილმდებარეობა იქნება მითითებული ჟურნალში რაც შეიძლება ზუსტად და მინიმალური დროა საჭირო პრობლემის წყაროს მოსაძებნად.

ეფექტური მონიტორინგი

რისი ნახვა მინდოდა ETL მონიტორინგის პროცესში?

დაწყება - როდესაც მან დაიწყო მუშაობა,
წყარო - მონაცემთა წყარო,
ფენა - რა დონის საცავი იტვირთება,
ETL Job Name - ატვირთვის პროცედურა, რომელიც შედგება მრავალი მცირე ნაბიჯისგან,
ნაბიჯის ნომერი - შესრულებული ნაბიჯის რაოდენობა,
დაზარალებული რიგები - რამდენი მონაცემია უკვე დამუშავებული,
ხანგრძლივობა წამი - რამდენი ხანი სჭირდება,
სტატუსი - ყველაფერი კარგად არის თუ არა: OK, ERROR, RUNNING, HANGS
შეტყობინება - ბოლო წარმატებული შეტყობინება ან შეცდომის აღწერა.

ჩანაწერების სტატუსიდან გამომდინარე, შეგიძლიათ გაგზავნოთ ელ.წერილი. წერილი სხვა წევრებს. თუ შეცდომები არ არის, მაშინ წერილი არ არის საჭირო.

ამრიგად, შეცდომის დაშვების შემთხვევაში, მკაფიოდ არის მითითებული შემთხვევის ადგილი.

ზოგჯერ ხდება, რომ თავად მონიტორინგის ინსტრუმენტი არ მუშაობს. ამ შემთხვევაში შესაძლებელია ხედის (ხედის) გამოძახება პირდაპირ მონაცემთა ბაზაში, რომლის საფუძველზეც აგებულია ანგარიში.

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 მოითხოვს გარე მექანიზმს და ამ შემთხვევაში მას პროტოტიპი PHP-ში.

გამოყვანის

ამრიგად, მონაცემთა დამუშავების ინსტრუმენტებში შეცდომის შეტყობინებები მეგა-მნიშვნელოვან როლს თამაშობს. მაგრამ ძნელია მათ უწოდო ოპტიმალური პრობლემის მიზეზის სწრაფად დასადგენად. როცა პროცედურების რაოდენობა ასს უახლოვდება, მაშინ პროცესის მონიტორინგი რთულ პროექტად იქცევა.

სტატიაში მოცემულია პრობლემის შესაძლო გადაწყვეტის მაგალითი პროტოტიპის სახით. მთელი მცირე საცავის პროტოტიპი ხელმისაწვდომია gitlab-ში SQLite PHP ETL Utilities.

წყარო: www.habr.com