איך הייתם מסירים כפילויות מטבלת אירועים ושומרים את האירוע האחרון לכל event_id?

אשתמש בפונקציית חלון כדי להקצות מספר שורה בתוך כל מחיצה של event_id. אמיין לפי עמודת העדכניות האמינה ביותר בסדר יורד, למשל ingestion_timestamp או updated_at. אם ייתכנו ערכים זהים, אוסיף שובר שוויון דטרמיניסטי כמו source_sequence_number או raw_file_name. תבנית השאילתה: לבחור את כל השורות, לחשב row_number() over(partition by event_id order by ingestion_timestamp desc, source_sequence_number desc), ואז לסנן where row_number = 1. הפרט החשוב בראיון הוא דטרמיניזם. אם לשתי רשומות יש אותו timestamp ואין שובר שוויון, התוצאה עלולה להשתנות בין הרצות. כדאי גם להבהיר אם "האירוע האחרון" פירושו זמן הקליטה האחרון, זמן האירוע האחרון או זמן העדכון האחרון במקור. בפרודקשן אנטר את שיעור הכפילויות, אירועים שמגיעים באיחור, מספר הערכים החסרים ב-event_id, והאם הסרת הכפילויות משנה באופן בלתי צפוי מדדים במורד הזרם.

כתבו SQL שבונה טבלת משתמשים פעילים יומיים מתוך אירועים גולמיים.

קודם כול אגדיר מהו משתמש פעיל. בדרך כלל לא כל אירוע צריך להיספר. ייתכן שיהיה צורך להחריג צפיות בדפים, אירועי בוטים, רענונים ברקע ומשתמשים פנימיים. אבחר אירועים משמעותיים כמו session_start, purchase, message_sent או feature_used, בהתאם למוצר. אבנה טרנספורמציה שמסננת לאירועים הרלוונטיים, ממירה את חותמות הזמן של האירועים לאזור הזמן העסקי, מקבצת לפי activity_date ו-user_id, ומפיקה שורה אחת לכל משתמש פעיל בכל יום. אם הטבלה הסופית היא אגרגציה, אספור משתמשים ייחודיים לפי יום. אם הטבלה היא מודל להגשה, אשמור date, user_id, platform, country ו-first_active_timestamp. פרטים חשובים לפרודקשן כוללים אזור זמן, אירועים שמגיעים באיחור, סינון בוטים ובדיקות, משתמשים שנמחקו, אירועים כפולים וחלוקה למחיצות לפי activity_date. בבנייה אינקרמנטלית אעבד מחדש גם את המחיצות האחרונות כדי לתפוס אירועים מאוחרים, ולא רק את היום הנוכחי. תשובה חזקה כוללת גם אימות: השוואת DAU מול ספירות האירועים במקור, ניטור שינויים מיום ליום ובדיקת עקביות ברמת הסגמנטים.

שאילתה שרצה בעבר 5 דקות לוקחת עכשיו שעתיים. איך תדבגו אותה?

קודם כול אבדוק אם הבעיה ספציפית לשאילתה, רוחבית לכל מחסן הנתונים או קשורה לתשתית. אם שאילתות רבות הואטו, ייתכן שמדובר בקיבולת האשכול, בעומס על מחסן הנתונים או בפגיעה בשירות. אם רק שאילתה אחת הואטה, אבחן את השאילתה ואת הנתונים. אבדוק שינויים אחרונים: גידול בגודל הטבלאות, שינויי סכמה, joins חדשים, פילטרים ששונו, היעדר partition pruning, סטטיסטיקות לא מעודכנות, הטיית נתונים (skew), joins שמנפחים שורות או פעולות distinct/order by שנוספו. אם אפשר, אעבור על תוכנית השאילתה. סיבות נפוצות: join ברמת פירוט שגויה, היעדר פילטרים על תאריך, joins של רבים-לרבים, סריקה של כל המחיצות, פונקציות חלון לא יעילות, shuffle גדול, או שימוש בפונקציות על עמודות המחיצה שמונע pruning. התיקונים יכולים לכלול סינון מוקדם יותר, אגרגציה מקדימה, הוספת פילטרים על מחיצות, clustering/מיון, הפיכת מודלי ביניים לטבלאות (materialization), עדכון סטטיסטיקות, צמצום העמודות הנבחרות או תיקון לוגיקת ה-join. בנוסף אוסיף ניטור של זמן ריצה, נפח הנתונים שנסרק (bytes scanned), ספירות שורות ועלות.

איך הייתם ממדלים מימדים משתנים לאט?

הגישה הנכונה תלויה בשאלה אם הדיוק ההיסטורי חשוב. Type 1 דורס ערכים ישנים, וזה פשוט ושימושי כשרק הערך העדכני רלוונטי. Type 2 שומר היסטוריה על ידי יצירת שורת מימד חדשה בכל שינוי במאפיין, בדרך כלל עם effective_start_date, effective_end_date, current_flag ומפתח חלופי (surrogate key). דוגמה: אם לקוח עובר מאזור West לאזור East, ב-Type 1 שורת הלקוח תתעדכן ל-East. דוחות הכנסות היסטוריים יציגו אז את ההכנסות הישנות תחת East, וזה עלול להיות שגוי. ב-Type 2 שורת West הישנה נשמרת ונוצרת שורת East חדשה, כך שטבלאות העובדות יכולות להתחבר לגרסה הנכונה לפי זמן האירוע. Type 2 מוסיף מורכבות: מפתחות חלופיים, joins לפי טווחי תאריכים, עובדות שמגיעות באיחור, דיווח עדכני לעומת היסטורי וטבלאות מימד גדולות יותר. כדאי להשתמש בו כשהדיווח חייב לשקף את המאפיינים כפי שהיו בזמן האירוע. תשובה חזקה מסבירה את הצורך העסקי לפני בחירת סוג ה-SCD.

Star schema לעומת טבלה רחבה לא מנורמלת: מתי תשתמשו בכל אחת?

Star schema מפריד בין טבלאות עובדות לטבלאות מימד. הוא שימושי כשנדרשים מימדים לשימוש חוזר, מדדים עקביים, ממשל נתונים, רמת פירוט ברורה וניתוח גמיש. הוא מצמצם כפילויות ומקל על ניהול שינויים במימדים. טבלה רחבה לא מנורמלת יכולה להתאים לאנליטיקה ספציפית בשימוש גבוה, לפיצ'רים של למידת מכונה או לדשבורדים שבהם פשטות השאילתות והביצועים חשובים. היא יכולה לחסוך לצרכנים מורכבות של joins, אבל עלולה לשכפל נתונים וליצור סיכון לממשל הנתונים אם טבלאות רחבות רבות מגדירות מדדים בצורה שונה. בפועל, לרוב אתחזק טבלאות עובדות ומימדים קנוניים ונקיים, ומעליהם אפרסם data marts מותאמים או טבלאות רחבות לתרחישי שימוש ספציפיים. הבסיס של מחסן הנתונים צריך להישאר אמין, ואילו המודלים במורד הזרם מותאמים לצורכי המשתמשים. ההחלטה תלויה בסקייל, בצרכנים, בהתנהגות כלי ה-BI, בעלות, בזמן ההשהיה ובתדירות השינוי של ההגדרות העסקיות.

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

קודם כול אבהיר את הדרישות: עדכניות הנתונים, נפח ההזמנות, השהיה מקובלת, מגבלות עומס על מסד הנתונים במקור, הצרכנים במורד הזרם והאם מתבצעים תיקונים היסטוריים. תכנון פשוט: לחלץ הזמנות באופן אינקרמנטלי באמצעות updated_at או CDC, להנחית את הנתונים הגולמיים באחסון אובייקטים או בטבלה גולמית במחסן הנתונים, לבצע טרנספורמציה לטבלאות staging, ואז לפרסם טבלאות עובדות ממודלות כמו fact_orders ו-fact_order_items. התזמור יתבצע עם Airflow, Dagster, dbt Cloud או כלי workflow מנוהל. הפייפליין צריך להיות אידמפוטנטי. אם הוא רץ שוב עבור תאריך או batch מסוים, עליו להחליף או למזג נתונים באופן דטרמיניסטי במקום להוסיף כפילויות. אשתמש ב-watermarks בזהירות ואעבד מחדש חלון lookback כדי לתפוס עדכונים מאוחרים. בדיקות אימות: ספירות שורות, מפתחות ראשיים ריקים, מזהי הזמנה כפולים, סכומי הכנסות, התפלגות סטטוסים, עדכניות והתאמה מול המקור. הניטור צריך להתריע על כשלים, שינויים חריגים בנפח, שיעורי כפילויות גבוהים או נתונים מתעכבים. כמו כן אתעד בעלות ותלויות במורד הזרם.

מה המשמעות של פייפליין אידמפוטנטי?

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

איך הייתם מטפלים בשינויי סכמה ממקור במעלה הזרם?

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

מתי תבחרו ב-streaming במקום ב-batch?

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

תכננו פייפליין אירועים לזיהוי הונאות בזמן אמת.

אתחיל בדרישות: נפח האירועים, יעד ההשהיה, סוג ההחלטה לגבי הונאה, הסבילות ל-false positives, והאם ההחלטות חוסמות עסקאות או מעבירות אותן לבדיקה. תכנון אפשרי: אירועי תשלום מתפרסמים ל-Kafka או ל-Kinesis. מעבד זרם צורך את האירועים, מאמת סכמה, מסיר כפילויות לפי event_id, מעשיר בנתוני משתמש, מכשיר, בית עסק ופיצ'רים היסטוריים של קצב (velocity), ואז מפעיל כללים או מודל. אירועים בסיכון גבוה מפעילים שירות החלטות, תור לבדיקה ידנית או אימות מוגבר (step-up). האירועים הגולמיים וההחלטות נכתבים לאחסון עמיד לצורכי ביקורת ואימון מודלים. שיקולים הנדסיים מרכזיים: אירועים כפולים, אירועים שלא לפי הסדר, עדכניות הפיצ'רים, גודל ה-state store, עיבוד exactly-once או effectively-once, backpressure, תורי dead-letter, הרצה חוזרת, ניטור השהיה וניהול גרסאות של מודלים וכללים. איכות נתונים וממשל נתונים חשובים כאן כי החלטות הונאה משפיעות על לקוחות. אתעד קודי סיבה, אנטר את שיעור ה-false positives ואאפשר rollback אם כלל או מודל מתנהגים בצורה לא תקינה.

מהו shuffle ב-Spark ולמה הוא יקר?

Shuffle מתרחש כש-Spark צריך לפזר מחדש נתונים בין מחיצות, בדרך כלל בפעולות כמו groupBy, join, distinct, orderBy ו-repartition. הוא יקר כי הנתונים צריכים לעבור ברשת, לעבור סריאליזציה ודה-סריאליזציה, להיכתב לדיסק ולהיות מתואמים בין ה-executors. פעולות shuffle מכתיבות לעיתים קרובות את זמן הריצה של הג'וב ועלולות לגרום לכשלים כשיש הטיית נתונים או כשנתוני הביניים גדולים מדי. מפתח "חם" יחיד עלול לשלוח יותר מדי נתונים למחיצה אחת, וליצור משימות מתעכבות (stragglers) או שגיאות out-of-memory. דרכים לצמצם את עלות ה-shuffle: סינון מוקדם, בחירת העמודות הנחוצות בלבד, אגרגציה מקדימה, שימוש ב-broadcast join לטבלאות קטנות, חלוקה למחיצות לפי מפתחות ה-join, salting למפתחות מוטים, הימנעות מ-distinct/orderBy מיותרים וכוונון מספר המחיצות. תשובה חזקה מחברת את המושג לדיבוג מעשי: בדיקה ב-Spark UI של ה-stages, קריאה/כתיבה של shuffle, הטיית נתונים, spill, משך המשימות והזיכרון של ה-executors.

איך הייתם מבצעים אופטימיזציה לג'וב Spark שנכשל בשגיאות out-of-memory?

קודם כול אזהה איפה הכשל מתרחש בעזרת Spark UI או הלוגים: באיזה stage, פעולה, מחיצה ו-executor. OOM יכול לנבוע מהטיית נתונים, joins גדולים, פעולות collect, מחיצות גדולות מדי, UDFs לא יעילים או caching של יותר מדי נתונים. לאחר מכן אצמצם נתונים כמה שיותר מוקדם: סינון שורות, בחירת העמודות הנחוצות בלבד, דחיפת predicates והימנעות מקריאת מחיצות מיותרות. אבדוק את ה-joins: אם טבלה אחת קטנה, אשתמש ב-broadcast join. אם מפתח מוטה, אשתמש ב-salting או אפצל את המפתחות הכבדים. אם המחיצות גדולות מדי, אגדיל את מספר המחיצות; אם יש יותר מדי מחיצות זעירות, אבצע coalesce בהתאם. אמנע מ-collect() על נתונים גדולים, מ-Python UDFs כשפונקציות מובנות מספיקות, ואשתמש ב-cache רק כשיש שימוש חוזר וכשהזיכרון מאפשר. בכתיבת קבצים אמנע מריבוי קבצים קטנים ואבחר פורמטים עמודתיים כמו Parquet עם דחיסה. אם נדרש כוונון משאבים, אתאים את זיכרון ה-executor, הליבות, מספר מחיצות ה-shuffle ותקורת הזיכרון, אבל לא אסתמך רק על אשכולות גדולים יותר. תיקון מבנה הנתונים ותוכנית השאילתה הוא בדרך כלל פתרון עמיד יותר.

Parquet לעומת CSV: למה מהנדסי נתונים מעדיפים Parquet לאנליטיקה?

Parquet הוא פורמט קבצים עמודתי, והוא יעיל לאנליטיקה כי שאילתות קוראות לרוב רק חלק מהעמודות. הוא תומך בדחיסה, מקודד טיפוסי נתונים, שומר את הסכמה ומאפשר predicate pushdown ו-column pruning במנועים רבים. CSV הוא טקסט פשוט מבוסס שורות. הוא קריא לבני אדם ונייד, אבל חסרים בו טיפוסים חזקים, הוא עלול להיות גדול יותר ואיטי יותר לסריקה, מועד יותר לשגיאות בתווי הפרדה ובתווי escape, ואינו יכול לדלג ביעילות על עמודות לא רלוונטיות. ב-data lakes ובמחסני נתונים, Parquet מוזיל בדרך כלל את עלות האחסון ומשפר את ביצועי השאילתות. CSV עדיין יכול להתאים לייצוא פשוט, לקבצים קטנים או לתאימות בין מערכות, אבל הוא אינו אידיאלי כפורמט האחסון העיקרי לאנליטיקה.

אילו בדיקות איכות נתונים הייתם מוסיפים לפייפליין הכנסות קריטי?

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

מספר בדשבורד השתנה באופן בלתי צפוי אחרי פריסה של פייפליין. מה תעשו?

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

תכננו feature store לצוותי למידת מכונה.

Feature store צריך לספק פיצ'רים אמינים לשימוש חוזר, הן לאימון והן להגשה. הדרישות כוללות הגדרות פיצ'רים, נכונות לנקודת זמן (point-in-time correctness), נתוני אימון offline, הגשה online בהשהיה נמוכה, עדכניות, בקרת גישה וניטור. פיצ'רים offline יכולים להישמר במחסן נתונים או ב-lakehouse, מחולקים למחיצות לפי תאריך וישות. פיצ'רים online יכולים להיות מוגשים ממאגר key-value בהשהיה נמוכה. רישום פיצ'רים (feature registry) שומר מטא-דאטה: שם הפיצ'ר, בעלים, מפתח הישות, לוגיקת הטרנספורמציה, SLA לעדכניות, טבלאות מקור ותיאור. נכונות לנקודת זמן היא קריטית. נתוני האימון חייבים להשתמש בערכי הפיצ'רים שהיו זמינים בזמן החיזוי, ולא בערכים עתידיים. לשם עקביות בין online ל-offline, כדאי לעשות שימוש חוזר באותה לוגיקת טרנספורמציה ככל האפשר, או לבדוק אותה היטב כשקיימים פייפליינים נפרדים. הניטור צריך לכסות עדכניות פיצ'רים, שיעורי ערכים ריקים, סחיפה בהתפלגות (drift), השהיית הגשה online, פער בין אימון להגשה (training-serving skew) וההשפעה על המודלים במורד הזרם. ממשל נתונים כולל בקרות PII, lineage, הוצאה משימוש ובעלות.

ספרו על תקלה בפייפליין נתונים שטיפלתם בה.

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

איך אתם עובדים עם אנליסטים שטוענים שהנתונים שגויים?

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

איך אתם מתעדפים עבודת הנדסת נתונים?

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

מדריך ראיון

מדריך ראיון לתפקיד מהנדס נתונים

התכוננו לראיונות להנדסת נתונים עם שאלות על SQL, מידול נתונים, פייפליינים של ETL, מערכות batch ו-streaming, Spark, תזמור, מחסני נתונים, איכות נתונים ותכנון מערכות.

35 דקות קריאה

21 שאלות

מהנדס נתונים

עודכן במאי 2026

לכל השאלות למהנדס נתונים

סקירה כללית

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

⁦4-6⁩

מספר שלבי ראיון טיפוסי

⁦45-75⁩ דק׳

משך ראיון טכני

תחומי ליבה בהנדסת נתונים

⁦5-8⁩ שבועות

זמן הכנה מומלץ

מה בודקים בראיונות להנדסת נתונים

•

עומק ב-SQL: האם תוכלו לכתוב שאילתות מדויקות ויעילות הכוללות joins, פונקציות חלון, הסרת כפילויות ולוגיקה אינקרמנטלית?

•

מידול נתונים: האם תוכלו לתכנן טבלאות, סכמות, רמת פירוט (grain), מחיצות ומימדים משתנים לאט עבור תרחישי שימוש אמיתיים?

•

תכנון פייפליינים: האם תוכלו לבנות תהליכי batch ו-streaming אמינים, ניתנים לניטור וניתנים לשחזור?

•

שיקול דעת במערכות מבוזרות: האם תוכלו לנתח Spark, חלוקה למחיצות, פעולות shuffle, state, זמן השהיה ותפוקה?

•

איכות נתונים: האם תוכלו למנוע מנתונים שגויים להגיע בשקט לדשבורדים, למודלים ולפיצ'רים בפרודקשן?

•

חשיבת פלטפורמה: האם תוכלו לאזן בין עלות, ביצועים, עדכניות, ממשל נתונים, שושלת נתונים (lineage) וחוויית המפתחים?

•

אחריות על פרודקשן: האם תוכלו לדבג תקלות, להריץ backfill בבטחה, לנהל שינויי סכמה ולתקשר את ההשפעה?

הנדסת נתונים היא הנדסת אמינות לנתונים

מהנדסי נתונים חזקים לא רק מעבירים נתונים מ-A ל-B. הם דואגים שהנתונים יהיו אמינים, מובנים, קלים לאיתור, סקיילביליים וניתנים לשחזור כשמשהו נשבר.

תהליך הראיונות להנדסת נתונים

תהליך הראיונות להנדסת נתונים כולל בדרך כלל SQL, Python או קוד, מידול נתונים, תכנון פייפליינים, תכנון מערכות, Spark או עיבוד מבוזר, דיבוג וראיונות התנהגותיים.

שלבים טיפוסיים בראיונות להנדסת נתונים

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

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

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

ראיון קוד: לרוב ממוקד ב-Python ובודק מבני נתונים, עיבוד קבצים, API, פענוח (parsing) או טרנספורמציות בסגנון פייפליין.

ראיון מידול נתונים: תתבקשו לתכנן טבלאות במחסן נתונים, סכמות אירועים, מודלים של fact/dimension או מבנה lakehouse.

ראיון תכנון מערכות: תתבקשו לתכנן מערכות קליטה, ETL/ELT, streaming, תזמור, ניטור, lineage ואיכות נתונים.

ראיון התנהגותי: בוחן אחריות, תגובה לתקלות, תקשורת עם בעלי עניין, התמודדות עם עמימות והובלת תוצרים בשיתוף צוותים שונים.

	הנדסת נתונים לאנליטיקה	הנדסת נתונים לפלטפורמה / streaming
מיקוד עיקרי	מידול מחסן נתונים, טרנספורמציות dbt/SQL, איכות נתוני דיווח, מדדים עסקיים	תשתיות קליטה, streaming, עיבוד מבוזר, אמינות, סקייל של פלטפורמה
ראיונות נפוצים	SQL, מידול מימדי, דרישות של בעלי עניין, תזמור פייפליינים	תכנון מערכות, Spark/Flink/Kafka, state, חלוקה למחיצות, סקיילינג, תקלות תפעוליות
סימן חיובי בולט	בניית מודלים אמינים שאנליסטים וצוותים עסקיים יכולים להשתמש בהם בביטחון	תכנון מערכות עמידות שמתמודדות עם נפח גבוה, זמן השהיה נמוך ותקלות
טעות נפוצה	מידול טבלאות בלי רמת פירוט, בעלות או הגדרות מדדים ברורות	תכנון ארכיטקטורת streaming בלי להתייחס ל-exactly-once, הרצה חוזרת (replay), state או ניטור

דעו לאיזה תפקיד הנדסת נתונים אתם מכוונים

ראיון ל-analytics engineer שממוקד במחסן נתונים שונה מראיון למהנדס נתונים בפלטפורמת streaming. התאימו את ההכנה לסטאק ולתחומי האחריות שמופיעים בתיאור המשרה.

שאלות SQL וטרנספורמציית נתונים

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

שאלות מידול נתונים ומחסני נתונים

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

מושגי מידול נתונים שחשוב להכיר

טבלת עובדות (fact table)

טבלה שמכילה אירועים עסקיים או עסקאות מדידים, כמו הזמנות, תשלומים, סשנים או משלוחים.

טבלת מימד (dimension table)

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

רמת פירוט (grain)

הרמה שכל שורה מייצגת. הגדרת רמת הפירוט חיונית לפני בניית טבלאות עובדות, מימדים, מדדים או joins.

מימד משתנה לאט (SCD)

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

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

אתחיל בתהליכים העסקיים המרכזיים: גלישה, עגלת קניות, הזמנות, תשלומים, משלוחים, החזרות, זיכויים, מלאי וייחוס שיווקי. כל תהליך יכול להפוך לטבלת עובדות או למודל אירועים, בהתאם לשימוש. טבלאות עובדות חשובות כוללות את fact_orders בשורה אחת לכל הזמנה, fact_order_items בשורה אחת לכל מוצר בכל הזמנה, fact_payments, fact_refunds, fact_shipments ו-fact_inventory_snapshot. המימדים כוללים dim_customer, dim_product, dim_date, dim_store או warehouse, dim_channel ו-dim_campaign. אגדיר את רמת הפירוט במפורש. הכנסות לפי קטגוריית מוצר צריכות בדרך כלל להגיע מרמת פריט ההזמנה, לא מרמת ההזמנה. מדדי מחזור חיי לקוח יכולים להתבסס על רמת הלקוח או המינוי. ניתוח מלאי עשוי לדרוש רמת פירוט של תמונת מצב יומית. שיקולי מידול: מאפייני לקוח או מוצר שמשתנים לאט, זיכויים וביטולים, הנחות ברמת ההזמנה לעומת רמת הפריט, מטבע, מסים, משלוח, רכישה כאורח ונתונים שמגיעים באיחור. אגדיר מדדים שמהווים מקור אמת ואבנה מודלים סמנטיים או data marts לכספים, שיווק, מוצר ותפעול. האימות כולל התאמה של ההכנסות מול הכספים, של מספר ההזמנות מול המערכות התפעוליות, של סך הזיכויים מול מערכת התשלומים ושל המלאי מול מערכות המחסן.

שאלות המשך צפויות

מהי רמת הפירוט של fact_order_items?

איך הייתם ממדלים זיכויים?

איך הייתם מטפלים בשינויים בקטגוריות מוצרים לאורך זמן?

תכנון ותזמור פייפליינים

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

תהליך לתכנון פייפליין אמין

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

בחרו דפוס קליטה: חילוץ batch, CDC, זרם אירועים, משיכה מ-API, קבצים שמונחים במיקום משותף (file drop) או מחבר מנוהל.

הגדירו אזור נחיתה, אחסון גולמי, טיפול בסכמה ואסטרטגיית הרצה חוזרת (replay).

העבירו את הנתונים דרך שכבות ברורות: גולמית, נקייה/staging, ממודלת ו-data marts להגשה.

הפכו את הפייפליינים לאידמפוטנטיים כך שהרצות חוזרות לא ישכפלו או ישחיתו נתונים.

הוסיפו בדיקות איכות נתונים, lineage, לוגים, התראות, מדדים ופרטי בעלות.

תכננו מראש backfills, התפתחות סכמה, נתונים מאוחרים, ניסיונות חוזרים, כשלים חלקיים ובקרת עלויות.

מערכות batch ו-streaming

שאלות על batch ו-streaming בודקות אם אתם מבינים זמן השהיה, תפוקה, סדר אירועים, state, חלונות זמן, הרצה חוזרת (replay) ואת הפשרות התפעוליות בין ארכיטקטורות פשוטות יותר לארכיטקטורות בזמן אמת.

	עיבוד batch	עיבוד streaming
השימושים המתאימים	דיווח תקופתי, backfills היסטוריים, טרנספורמציות גדולות, אנליטיקה חסכונית	פיצ'רים בזמן אמת, התראות, זיהוי הונאות, דשבורדים חיים, החלטות בהשהיה נמוכה
הפשרה העיקרית	השהיה גבוהה יותר, אבל תפעול פשוט יותר והרצה חוזרת קלה יותר	השהיה נמוכה יותר, אבל יותר מורכבות סביב state, סדר אירועים וטיפול בכשלים
כלים נפוצים	Airflow, dbt, Spark batch, Snowflake, BigQuery, Databricks	Kafka, Flink, Spark Structured Streaming, Kinesis, Pub/Sub
סיכוני כשל	נתונים מאוחרים, טעינות חלקיות, זמני ריצה ארוכים, עלות backfill	כפילויות, אירועים שלא לפי הסדר, checkpointing, גידול ב-state, סמנטיקת exactly-once

שאלות Spark ועיבוד מבוזר

שאלות על Spark ועיבוד מבוזר בודקות אם אתם מבינים חלוקה למחיצות, shuffle, הטיית נתונים (skew), caching, joins, פורמטי קבצים, ולמה ג'ובים נכשלים או נעשים יקרים.

איכות נתונים ו-observability

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

דוגמה מפורטת

צ'קליסט לתקלת נתונים בפרודקשן

בדשבורד ההכנסות של ההנהלה חסרים נתוני אתמול, שעתיים לפני ישיבת הנהלה.

תעדוף ראשוני

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

מיתון

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

תקשורת

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

מניעה

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

תוצאה

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

תכנון מערכות בהנדסת נתונים

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

גישה: אינסטרומנטציה ← קליטה ← אחסון ← עיבוד ← מידול ← הגשה ← ממשל נתונים

אתחיל בדרישות: נפח האירועים, השהיה, צרכנים, תקופת שמירה, התפתחות סכמה, פרטיות ואמינות. אירועי אנליטיקת מוצר עשויים להזין דשבורדים, ניסויים, פרסונליזציה ופיצ'רים של למידת מכונה. אפליקציות הלקוח שולחות אירועים דרך SDK עם event_name, user_id, session_id, timestamp, properties, גרסת אפליקציה, פלטפורמה ומזהה אנונימי. האירועים מגיעים ל-API קליטה או לרכיב איסוף אירועים (event collector), ומשם לזרם עמיד כמו Kafka/Kinesis/Pub/Sub. האירועים הגולמיים נכתבים לאחסון אובייקטים לצורך הרצה חוזרת, ולמחסן נתונים או ל-lakehouse לצורכי אנליטיקה. העיבוד כולל אימות סכמה, הסרת כפילויות, סינון בוטים ותעבורה פנימית, חלוקה לסשנים, איחוד זהויות (identity resolution) וטרנספורמציה לטבלאות ממודלות כמו fact_events, fact_sessions, dim_users ו-data marts ייעודיים למוצר. מסלולי batch ו-streaming יכולים להתקיים במקביל, בהתאם לדרישות העדכניות. איכות וממשל נתונים: חוזי אירועים, schema registry, טיפול ב-PII, אכיפת הסכמת המשתמשים, lineage, בעלות, בדיקות עדכניות, התראות על חריגות בנפח ותיעוד. שכבות ההגשה כוללות דשבורדים של BI, ניתוח ניסויים, reverse ETL ו-feature stores. הפשרות כוללות עלות של זמן אמת לעומת batch, סכמה קשיחה לעומת גמישה, תקופת שמירת האירועים הגולמיים, מורכבות ניהול הזהויות, וכמה לוגיקה צריכה לשבת בשלב הקליטה לעומת שלב הטרנספורמציה.

שאלות המשך צפויות

איך הייתם מטפלים בהתפתחות סכמה?

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

על אילו טבלאות אנליסטים יריצו שאילתות?

שאלות התנהגותיות ושיתוף פעולה

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

אסטרטגיית הכנה להנדסת נתונים

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

תוכנית הכנה של 6 שבועות לראיונות בהנדסת נתונים

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

שבוע 2: מידול נתונים. תרגלו טבלאות עובדות, מימדים, רמות פירוט, SCDs, מודלי אירועים, data marts במחסן הנתונים והגדרות מדדים.

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

שבוע 4: עיבוד מבוזר. חזרו על Spark, shuffle, חלוקה למחיצות, skew, פורמטי קבצים, מושגי streaming ופשרות בין עלות לביצועים.

שבוע 5: תכנון מערכות. תרגלו פלטפורמות לאנליטיקת מוצר, קליטה עם CDC, feature stores, פייפליינים לזיהוי הונאות ב-streaming וארכיטקטורת מחסני נתונים.

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

הכנה לפי מסלול בהנדסת נתונים

•

Analytics engineering: התמקדו ב-dbt, מודלי SQL, שכבות סמנטיות, הגדרות מדדים, אמינות BI ותהליכי עבודה עם בעלי עניין.

•

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

•

הנדסת נתונים ל-streaming: התמקדו ב-Kafka, ב-Flink/Spark streaming, ב-state, בחלונות זמן, בכפילויות, בסדר אירועים, בהרצה חוזרת ובהשהיה.

•

הנדסת נתונים ל-ML: התמקדו בפייפליינים של פיצ'רים, ב-feature stores, בנכונות לנקודת זמן, בנתוני אימון ובניטור.

•

הנדסת מחסני נתונים בענן: התמקדו ב-Snowflake, BigQuery, Databricks, חלוקה למחיצות, clustering, בקרת עלויות וניהול עומסי עבודה.

אל תדברו רק על כלים

למראיינים פחות חשוב שאתם מכירים בשמם את Airflow, dbt, Spark או Kafka, ויותר חשוב שאתם מבינים אמינות, נכונות נתונים, פשרות ותרחישי כשל.

המסקנה העיקרית

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

תרגלו את השאלות האלה בזמן אמת

Interview Pilot מעניק לכם עוזר ראיונות AI בזמן אמת במהלך ראיונות אמיתיים, כדי שתוכלו לענות בבהירות כשהשאלות האלה עולות.

נסו את Interview Pilot בחינם