מה זה ETL? הסבר פשוט + כמה משרות פתוחות בישראל

זמן קריאה: 6 דקות

ETL הוא תהליך בשלושה שלבים שמעביר נתונים ממערכת אחת לאחרת: Extract - שליפה מהמקור, Transform - ניקוי והתאמה, Load - טעינה ליעד. זו הדרך שבה נתונים מגיעים ממערכות התפעול אל מחסן הנתונים שמדווחים ממנו. בלוח HiTakeJob פתוחות כרגע 14 משרות שמזכירות ETL, 14 שמזכירות Airflow ו-30 שמזכירות הנדסת נתונים.

שלושת השלבים, בפירוט שמשנה בפועל

כל שלב נראה טריוויאלי בתיאור ומכיל את רוב העבודה האמיתית:

Extract: שליפה ממסד נתונים, מ-API או מקבצים. ההחלטה המרכזית היא אם מושכים הכול בכל פעם או רק מה שהשתנה. משיכה מלאה פשוטה אך יקרה; משיכה מצטברת דורשת שדה זמן אמין - ולא תמיד יש כזה.
Transform: איחוד פורמטים של תאריכים, המרת מטבע, פיצול שדות, החלת הגדרות עסקיות והסרת כפילויות. כאן נצרבות ההחלטות שקובעות מה הדוח יראה.
Load: כתיבה ליעד. השאלה היא אם מוסיפים, מחליפים, או מעדכנים שורות קיימות - ולכל אפשרות התנהגות שונה כשהתהליך רץ פעמיים.

הכלל החשוב ביותר בתחום: תהליך חייב להיות בטוח להרצה חוזרת. אם הרצה שנייה של אותו יום מכפילה שורות, כל כשל יהפוך לתקלת נתונים במקום לניסיון נוסף.

ETL מול ELT - מה ההבדל ולמה זה השתנה?

	ETL	ELT
איפה קורה העיבוד	בשרת ביניים, לפני הטעינה	בתוך מחסן הנתונים, אחרי הטעינה
מה נשמר ביעד	רק התוצאה המעובדת	גם הגולמי וגם המעובד
שינוי לוגיקה בדיעבד	דורש למשוך מהמקור מחדש	אפשר לחשב מחדש מהגולמי
מתי מתאים	מקורות כבדים, דרישות פרטיות	ברירת המחדל במחסנים בענן

המעבר ל-ELT קרה מסיבה כלכלית: כוח החישוב במחסנים בענן נעשה זול וגמיש, ולכן אין סיבה לתחזק שרת עיבוד נפרד. היתרון המעשי הגדול הוא היכולת לתקן טעות בלוגיקה ולחשב הכול מחדש מהנתון הגולמי, בלי להטריד שוב את מערכות המקור.

איך נראה תהליך ETL אמיתי

דוגמה קונקרטית - טעינה יומית של נתוני מועמדויות:

בשעה קבועה נשלפות כל הרשומות שהשתנו מאז ההרצה הקודמת.
העותק הגולמי נשמר כפי שהתקבל, עם חותמת זמן, בלי שינוי.
התאריכים מומרים לאזור זמן אחיד, וסטטוסים ממופים לרשימה מוסכמת.
רשומות שמזהה שלהן כבר קיים מתעדכנות במקום להתווסף.
בדיקות: מספר שורות בטווח סביר, אין ערכים חסרים בשדה מזהה, והסכום מתיישב מול מקור שני.
אם בדיקה נכשלת - התהליך עוצר ומתריע, במקום להמשיך ולכתוב נתון שגוי.

הסעיף האחרון הוא ההבדל בין תהליך מקצועי לסקריפט. מערכת שממשיכה בשקט אחרי כשל בבדיקה גרועה ממערכת שלא בודקת כלל, כי היא יוצרת אשליית ביטחון.

מה משתבש בתהליכי ETL

שינוי במקור. צוות אחר שינה שם עמודה, והתהליך ממשיך לרוץ עם שדה ריק.
נתונים שמגיעים באיחור. אירוע של אתמול שנרשם היום - אם לא מטפלים בו, אתמול נשאר שגוי לתמיד.
אזורי זמן. חישוב ב-UTC מול דוח בשעון ישראל מייצר פער של שעתיים-שלוש שמזיז נתונים בין ימים.
עומס על מערכת המקור. שליפה כבדה בשעת שיא יכולה להאט את המערכת התפעולית עצמה.
תלות שרשרתית. כשתהליך אחד נכשל, כל מה שמתבסס עליו מייצר תוצאה חלקית - וזו הסיבה לקיומם של כלי תזמון עם ניהול תלויות.

באילו כלים זה נעשה בישראל

כלי	משרות פעילות	תפקידו
Python	365	כתיבת הלוגיקה עצמה
SQL	133	שלב הטרנספורמציה, במיוחד ב-ELT
Airflow	22	תזמון, תלויות וניסיונות חוזרים
Spark	21	עיבוד נפחים שלא נכנסים למכונה אחת
ETL	14	המונח עצמו, כשמופיע במודעה
BigQuery / Snowflake	13 / 10	היעד שאליו נטען

המשרות עצמן נמצאות בעיקר תחת הנדסת נתונים - אפשר לראות אותן במשרות Data Engineering ובמשרות Airflow.

איך מתכננים תהליך שאפשר לסמוך עליו

ארבעה עקרונות שמפרידים בין תהליך שמחזיק שנים לבין אחד שדורש טיפול ידני בכל שבוע:

עמידות להרצה חוזרת: הרצה שנייה של אותו טווח תאריכים חייבת להוביל לאותה תוצאה - לרוב באמצעות מחיקת המחיצה לפני הכתיבה או עדכון לפי מפתח.
עיבוד לפי טווח ולא לפי "עכשיו": תהליך שמקבל תאריך כפרמטר אפשר להריץ על אתמול או על חודש שעבר. תהליך שמחשב את התאריך בעצמו אי אפשר לתקן למפרע.
כשל רועש: עדיף שהתהליך ייעצר ויתריע מאשר שיכתוב נתון חלקי שאיש לא ישים לב אליו.
תיעוד מקור: שמירת המקור וזמן הטעינה של כל שורה - זה מה שמאפשר לחקור פער כשהוא מתגלה חודשים אחר כך.

העיקרון השני הוא הפחות אינטואיטיבי והכי חשוב. הוא ההבדל בין "אפשר לתקן את השבוע שעבר בפקודה אחת" לבין "נצטרך לשחזר ידנית".

מי כותב תהליכי ETL בארגון

בחברות קטנות זה לרוב מפתח Backend או אנליסט שנדחף לתפקיד בדיעבד, ובחברות בינוניות ומעלה מהנדס נתונים ייעודי. ההבדל ניכר: תהליך שנכתב כתוספת לתפקיד אחר נוטה להיות סקריפט שרץ במחשב של מישהו ונשבר כשהוא בחופשה. הסימן שהגיע הזמן לתפקיד ייעודי הוא כשמספר התהליכים עובר את מה שאדם אחד מסוגל לזכור, או כשתקלה בנתונים מתחילה להגיע להנהלה. הרחבנו על התפקיד במה זה Data Engineering.

למה הסעיף הזה מופיע גם במשרות שאינן דאטה

ETL מופיע היום במקומות שאין להם קשר ל"ביג דאטה": הטמעת מערכות ERP שדורשת העברת נתונים ממערכת ישנה, אינטגרציות בין מערכת CRM למערכת חיוב, והגירות נתונים בפרויקטי הטמעה. בכל אחד מהם אותם עקרונות חלים - מיפוי שדות, טיפול בערכים חריגים, ובדיקת התאמה בין המקור ליעד אחרי ההעברה.

זו הסיבה שהמיומנות מועילה גם למי שאינו מכוון לתפקיד דאטה מובהק: מי שיודע לתכנן העברת נתונים מסודרת נדרש גם בפרויקטי מערכות מידע ובהטמעות.

שאלות נפוצות

מה ההבדל בין ETL ל-pipeline נתונים?

ETL מתאר תבנית ספציפית של שליפה, עיבוד וטעינה. Pipeline הוא מונח רחב יותר לכל שרשרת מעובדת של נתונים, כולל זרימה בזמן אמת שאינה ETL קלאסי. בפועל בישראל שתי המילים משמשות לסירוגין במודעות.

צריך ללמוד Airflow כדי לעבוד בתחום?

זה הכלי הנפוץ ביותר לתזמון - 22 משרות פעילות מזכירות אותו - וכדאי להכיר אותו. אבל העקרונות חשובים יותר מהכלי: תלויות בין משימות, ניסיונות חוזרים, והרצה בטוחה מחדש קיימים בכל כלי תזמון.

אפשר לעשות ETL רק עם SQL?

את שלב הטרנספורמציה - כן, וזו בדיוק הגישה של ELT. את השליפה מ-API ואת התזמון קשה לעשות בלי שפת תכנות. לכן הצירוף המבוקש הוא SQL יחד עם Python - 132 ו-365 משרות פעילות בהתאמה.

מה קורה כשמגלים שהנתונים היו שגויים חודש אחורה?

אם נשמר עותק גולמי, מתקנים את הלוגיקה ומריצים מחדש את התקופה. אם לא נשמר, צריך לפנות שוב למערכות המקור - ולעיתים הנתון כבר לא קיים שם. זו הסיבה המרכזית לשמור תמיד את הגולמי.

כמה זמן לוקח לבנות תהליך ETL ראשון?

למקור אחד ויעד אחד - ימים ספורים. מה שמאריך הוא כל מה שסביב: בדיקות איכות, טיפול בכשלים, טעינה מצטברת ותיעוד. כלל אצבע מעשי הוא שהקוד הראשוני הוא כרבע מהעבודה, וכל השאר הוא מה שהופך אותו למערכת.

האם כלי ETL מוכנים מייתרים את הצורך במהנדס?

הם מקצרים מאוד את שלב החיבור למקורות נפוצים, ולכן שווים שימוש. מה שהם לא פותרים הוא הגדרות עסקיות, בדיקות איכות וטיפול במקרי קצה - וזה בדיוק החלק שבו נקבע אם הדוח בסוף נכון.