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

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

אשתמש בפונקציית חלון כדי להקצות מספר שורה בתוך כל מחיצה של 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, והאם הסרת הכפילויות משנה באופן בלתי צפוי מדדים במורד הזרם.

גישה: סינון אירועי פעילות ← נרמול תאריך ← קיבוץ לפי תאריך ומשתמש

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

גישה: היקף ← תוכנית שאילתה ← גידול בנתונים ← joins ← מחיצות ← שינויים אחרונים

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

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

אתחיל בתהליכים העסקיים המרכזיים: גלישה, עגלת קניות, הזמנות, תשלומים, משלוחים, החזרות, זיכויים, מלאי וייחוס שיווקי. כל תהליך יכול להפוך לטבלת עובדות או למודל אירועים, בהתאם לשימוש. טבלאות עובדות חשובות כוללות את 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 לכספים, שיווק, מוצר ותפעול. האימות כולל התאמה של ההכנסות מול הכספים, של מספר ההזמנות מול המערכות התפעוליות, של סך הזיכויים מול מערכת התשלומים ושל המלאי מול מערכות המחסן.

גישה: Type 1 לעומת Type 2 לפי הצורך בהיסטוריה

הגישה הנכונה תלויה בשאלה אם הדיוק ההיסטורי חשוב. 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 מפריד בין טבלאות עובדות לטבלאות מימד. הוא שימושי כשנדרשים מימדים לשימוש חוזר, מדדים עקביים, ממשל נתונים, רמת פירוט ברורה וניתוח גמיש. הוא מצמצם כפילויות ומקל על ניהול שינויים במימדים. טבלה רחבה לא מנורמלת יכולה להתאים לאנליטיקה ספציפית בשימוש גבוה, לפיצ'רים של למידת מכונה או לדשבורדים שבהם פשטות השאילתות והביצועים חשובים. היא יכולה לחסוך לצרכנים מורכבות של joins, אבל עלולה לשכפל נתונים וליצור סיכון לממשל הנתונים אם טבלאות רחבות רבות מגדירות מדדים בצורה שונה. בפועל, לרוב אתחזק טבלאות עובדות ומימדים קנוניים ונקיים, ומעליהם אפרסם data marts מותאמים או טבלאות רחבות לתרחישי שימוש ספציפיים. הבסיס של מחסן הנתונים צריך להישאר אמין, ואילו המודלים במורד הזרם מותאמים לצורכי המשתמשים. ההחלטה תלויה בסקייל, בצרכנים, בהתנהגות כלי ה-BI, בעלות, בזמן ההשהיה ובתדירות השינוי של ההגדרות העסקיות.

גישה: חילוץ ← נחיתה גולמית ← טרנספורמציה ← אימות ← פרסום ← ניטור

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

גישה: זיהוי ה-stage ← צמצום נתונים ← תיקון skew ← כוונון מחיצות ← הימנעות מפעולות בעייתיות

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

גישה: אחסון עמודתי, סכמה, דחיסה, predicate pushdown

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

גישה: עדכניות ← שלמות ← ייחודיות ← תקינות ← התאמה

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

גישה: הערכת השפעה ← השוואת גרסאות ← בדיקת lineage ← מיתון ← שורש הבעיה

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

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

אתחיל בדרישות: נפח האירועים, השהיה, צרכנים, תקופת שמירה, התפתחות סכמה, פרטיות ואמינות. אירועי אנליטיקת מוצר עשויים להזין דשבורדים, ניסויים, פרסונליזציה ופיצ'רים של למידת מכונה. אפליקציות הלקוח שולחות אירועים דרך 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, סכמה קשיחה לעומת גמישה, תקופת שמירת האירועים הגולמיים, מורכבות ניהול הזהויות, וכמה לוגיקה צריכה לשבת בשלב הקליטה לעומת שלב הטרנספורמציה.

גישה: עקביות offline/online ← הגדרות פיצ'רים ← עדכניות ← הגשה ← ניטור

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 או בקרות פריסה טובות יותר? הימנעו מהאשמת צוותים במעלה הזרם. הראו אחריות על המערכת ועל התקשורת. סיימו במה שלמדתם על אמינות ואיך התהליך שלכם השתנה בעקבות זאת.

גישה: הבהרה ← שחזור ← מעקב lineage ← פתרון ← תיעוד

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

גישה: השפעה ← אמינות ← דחיפות ← תלויות ← מינוף

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