מהו ההבדל בין תהליך ETL VS ELT
במאמר זה אפרט את ההבדל שבין תהליך ETL VS ELT וכן את הכלים המודרנים לביצוע התהליך
המאמר תהליך ETL VS ELT נכתב ע"י איתמר שטינברג – מומחה ETL | ELT | DWH ו בינה עסקית (BI).
להלן מצגת שפורסמה ב Youtube
נתחיל ב ETL ה ETL (Extract Transfer Load) נועד לבצע העתקה של מידע ממקורות נתונים ( Extract ),
ביצוע לוגיקה על המידע בתהליך (Transform)
ולבסוף לטעון את הנתונים במבנה הסופי. (Load)
קיימות מספר סיבות לבצע תהליך זה:
1. המרת מבנה הנתונים רילציוני (מבנה מנורמל מבוסס קשרים בין טבלאות) למבנה אנליטי. מימדים ומדדים. לדוגמא: Star schema .
2. הרצת שאילתות הדורשות משאבים על בסיס נתונים שאינו התפעולי.
3. העתקת המידע לבסיס נתונים DWH בעל משאבים משמעותיים במבנה הנועד לניתוח מידע.
כגון: Columnar וכן In memory . המסוגל גם להתרחב במידת הצורך. Scale up , scale out. בסיסי נתונים כגון: Snowflake, Redshift, Big Query ואחרים.
4. חיבור מספר מקורות מידע על מנת לבצע קשרים וניתוחים ממספר מקורות.
5. אינטגרציה בין מערכות מידע שונות
ישנן 2 גישות מרכזיות לביצוע התהליך:
גישת ה ETL :
הגישה היא התחברות למקורות הנתונים ותוך כדי התהליך לבצע חיבורים בין מקורות שונים וביצוע לוגיקות שונות,
כאשר סיום התהליך הוא העברת הנתונים במבנה האופטימלי המוגמר.
גישת ה ELT:
הגישה היא התחברות למקור הנתונים והעברת הנתונים As is ליעד,
בדרך כלל לסכימה יעודית, כגון staging. רק לאחר העברת הנתונים ליעד ביצוע טרנספורמציות, T (לוגיקה).
השיטה האחרונה הפכה לפופולרית מאוד בשנים האחרונות ונסקור מדוע.
גישת ה ETL מבוססת על כך שהנתונים זורמים דרך שרתי ה ETL, כלומר הנתונים זורמים ממקורות הנתונים ועוברים לזיכרון של שרתי ה ETL,
שם מחברים גם מקורות נוספים במידה הצורך ומבצעים טרנספורמציות.
התהליך מבוצע בדרך כלל בכלים יעודיים הכוללים GUI – ממשק משתמש נוח וכמעט ללא כתיבת קוד. (Pentaho, Talend, SSIS, informatica ועוד…).
הכלים ידידותיים ומכילים קומפוננטות רבות לביצוע שינויים בזרם הנתונים.
פעולות של חיבור עמודות, חישובים, מיון, לולאות, חיבור מקורות שונים ועוד…
התוצר הינו טבלה המכילה את הנתונים האופטימליים לצורך ניתוח.
יתרונות ה ETL:
• רק הנתונים הרלוונטים נלקחים מהמקורות
• כלי ה GUI נוחים ומכילים תמיכה בכלל התהליך. לוגים, התרעות, ניהול משתמשים
• ניתן להשתמש בכלי ETL ככלי ELT.
חסרונות ה ETL:
• רק נתונים רלוונטים נלקחים – כל נתון חדש גורם לתחזוקה ותוספות. אם המקור נעלם / נמחק. לא ניתן לשחזר או להוסיף.
• הנתונים זורמים דרך שרתי ה ETL. כלומר שרתי ה ETL הופכים לצוואר בקבוק, דורשים משאבים רבים,
במיוחד בפעולות לוגיות כגון: מיון וחיבור בין זרמי מקורות שונים. התהליך הופך להיות Production והתחזוקה הנדרשת יקרה
• חיבור מקורות שונים בכמויות גדולות של מידע לאורך זמן עלול להיות רגיש לנפילות, התנתקויות, אובדן תקשורת
משפיע משמעותית כל יציבות התהליך.על מנת לשמור על האינטגריטי של התהליך יש לפתח הגנות מתאימות והפיתוח מתארך בהתאם.
השינוי המשמעותי שחל בשנים האחרונות:
הינו כניסת בסיסי הנתונים MPP בענן וכמות הנתונים שהחברות מאחסנות.
כלים כגון: Snowflake ו Redshift גרמו לכך שהחברות משלמות רק על משאבים בהם הן משתמשות יחד
עם היכולת להתרחב בהתאם לכמות הנתונים או העיבוד ללא גבול.
מכך נובע שכדאי לעשות שימוש במשאבים של ה DWH לביצוע טרנספורמציות באמצעות SQL
ופחות בכלים צד ג' שמוסיפים שכבת ניהול וסיכון נוספת.
הפעלת שאילתא מורכבת בתוך בסיס הנתונים הכוללת transaction עם rollback
בהחלט משפר משמעותית את יציבות והאינטגריטי של התהליך.
בנוסף בסיסי הנתונים המודרנים, תומכים בטרנספורמציות מתוחכמות כגון: windows function, פירסור של Json ואף כתיבת UDF,
נושאים שבעבר לא היה להם פיתרון כחלק אינטגרלי בבסיס הנתונים.
לכן בחברה שנדרשת לעבד כמויות גדולות של נתונים ומראש עובדים בענן כשיטה, לא פלא שגם תהליך ה ELT
יהיה העברת מידע לתוך בסיס הנתונים ה MPP באמצעות כלי SAAS ורק לאחר מכן ביצוע טרנספורמציות על המידע.
כיוון שהתהליך מעביר את הנתונים מכל המקורות לאותו יעד.
ברור כי כאשר הנתונים נמצאים בבסיס נתונים אחד, ניתן יהיה לבצע SQL שמאחד, ממיין, מחשב ומיצר טבלאות חדשות בהתאם.
גישת ה ELT פירוט:
הגישה הזו גורסת כי נעביר את כל הנתונים במבנה המקורי שלהם אל היעד, ישירות, ללא חיבורים, חישובים, תוספות.
גם מכל מקור ומקור לאותו יעד וגם את כול העמודות הנדרשות לנו.
אנו בעצם מאחסנים את המידע בכפילות.
כך שאם תגיע דרישה לחישוב נוסף או תוספת לא נצטרך להביא את כל המידע החסר מהמקור אלא הוא כבר יהיה ביעד ב Staging.
לשם כך פותחו כלים ברובם SAAS לביצוע חלק זה בתהליך: Fivetran, Rivery, Airbyte (open source) ועוד.
התשלום עבורם הינו על בסיס שימוש כפי שהתרגלו החברות לשלם גם על יתר רכיבי החומרה והתוכנה שלהן.
כלים אלו מאפשרים בקלות יחסית לבצע סינכרון בין מקורות מידע לבסיסי נתונים MPP.
כולל שמירה על שינויים במבנה, הבאת נתונים אינקרמנטלים (משינוי אחרון), לוגים, מעקב והתרעות.
לאחר שהנתונים נמצאים במקום אחד, יש צורך לבצע את החלק המורכב של הטרנספורמציות
וכיוון ש SQL הינו הכלי לעבודה מול בסיסי הנתונים, מפעילים תהליכים מבוססי SQL.
לאחרונה חברות רבות עוברות לעבוד עם כלי בשם DBT data build tool.
כלי ה ELT תומכים בו ע"י הרצת תהליכי DBT לאחר ביצוע ה EL.
לדוגמא: Fivetran עוזרת לפתח את DBT ומייצרת תוספים.
Airbyte מאפשר להריץ תהליך DBT בסוף העברה ואפילו Holistics – כלי BI מאפשר להריץ DBT בתזמון.
יתרונות ה ELT:
• תהליך ה EL מנוהל ע"י כלים שהופכים את הפעולה לפשוטה יחסית.
• כל מקור עומד בפני עצמו, אין תהליכים מורכבים בחלק ה EL
• קל להתחל את התהליך מראש, הנתונים כבר ביעד.
• ניתן להריץ serverless.
• אין צורך בשרתי ETL בעלי משאבים, שכבה נוספת של מומחיות נדרשת שאין צורך בה.
חיסרונות ה ELT:
• שימוש בבסיסי הנתונים MPP ושפת SQL לביצוע טרנספורמציות מחזירה אותנו לימים של כתיבת קוד,
קושי ב Debug, אין ממשק GUI ומתבסס על יכולות גבוהות ב SQL) – גם עם DBT.
• השליטה בתהליך כולו מאתגרת. יש נתק בין העברת הנתונים בין המקורות ליעד וביצוע המשך התהליך.
• איחסון כמויות נתונים ב Staging
טענה באשר לכוח האדם הנדרש:
יש הטוענים שגישת ה ELT פשוטה יותר כיוון שבעלי המקצוע הנדרשים לביצוע התהליך
אינם מהנדסי הנתונים (Data engineers) אלא אנשי ה BI והאנליזה (data analysis) שעלותם נמוכה יותר.
אינני מסכים עם טענה זו, יש לבחון כל מקרה לגופו, המורכבות של הטרנספורמציות (T) לא משתנה,
היא רק עוברת בזרימה מאמצע התהליך ב ETL ל סוף התהליך ב ELT .
אומנם ה T מתבצע באמצעות SQL אך לרוב התפיסה והיכולת של מהנדסי נתונים שונה בתכלית מאנליסטים.
קיים הבדל משמעותי בין כתיבת שאילתות לניתוח נתונים לבין יצירת טרנספורמציות.
המעבר מסכימה ב Staging ל Prod מורכב לעיתים אף יותר ב SQL,
כיוון שכלי ETL הינם מובנים, בעלי GUI, debug, מבניות, שליטה על הזרימה ונועדו מראש לטרנספורמציות של נתונים.
לרוב ללא צורך בכתיבת שורות קוד כלל. לעומת SQL .
אז מי מהם טוב יותר ETL VS ELT:
התשובה היא: תלוי.
הפיתוח בכלי ETL הסטנדרטם הינו מובנה, מנוהל, מבוקר לרוב ללא כתיבת קוד.
עומת זאת ELT דומה יותר לתהליך של פיתוח תוכנה.
ההיסטוריה של העתקת מידע החלה בכתיבת קוד ומשם פותחו כלי ה ETL שנועדו לפשט את התהליך.
החזרה לפיתוח ה T ב SQL או ב Python מהווה סוג של חזרה לפיתוח תהליכי גזירה בקוד.
לעיתים הבחירה בין השניים קלה.
במידה ומדובר במיעוט מקורות מבסיסי נתונים מובנים ומערכות תפעוליות,
בסיס נתונים מקומי או שאינו MPP ואינו מהווה יתרון למשאבים בביצוע ELT אזי נבחר ב ETL.
לעומת זאת במידה ומדובר בחברה שרכיבי התוכנה שלה בענן, עושה שימוש בכלי ענן, מדובר ב Big Data,
עובדת כבר או רוצה לעבוד עם בסיס נתונים MPP כגון Snowflake, Redshift, Bigquery ודמויהם אזי נבחר ללא ספק ב ELT.
