AI-מעקב Data Lineage: אוטומציה והטמעה

Data Lineage: היכן נשברת שרשרת מקור הנתונים

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

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

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

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

מה נותן מעקב אוטומטי אחר מקור הנתונים

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

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

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

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

פורמטי הטמעת Data Lineage: השוואת גישות

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

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

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

איך אנחנו בונים מעקב: שלבי העבודה ההנדסית

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

1. ביקורת מקורות. מלאי: אילו מערכות כותבות, אילו קוראות, מי הבעלים, איזה גישה נדרשת. מסמנים נקודות שמהן ניתן לאסוף מטא-נתונים אוטומטית.
2. מפת נתונים. מתאמים מודל גרף: צמתים — מערכי נתונים, דוחות, Data Marts; קשתות — פעולות ותלויות. מסכמים על רמת הפירוט — עד עמודה או עד טבלה.
3. הגדרת איסוף. מחברים ניתוח לוגים, יירוט שאילתות ומטא-נתונים של המתזמר. במקום שבו האוטומציה אינה רואה את המקור — תיאור ידני עם בעלים מחייב.
4. בדיקת הגרף. משווים את המודל למציאות: מעבר לאחור מהדוח הסופי עד הרשומה המקורית והשוואת סכומי ביקורת על מדגם. אי-התאמות — לרשימה נפרדת.
5. תחום ניסוי. לוקחים זרימה אחת ומריצים עליה את כל המסלול: בודקים את שיעור הצמתים המכוסים בקשרים וכמה זמן דורש בירור תקלה.
6. נוהל ומסירה. מתארים כיצד מתעדכנת המפה ומי אחראי על מקורות חדשים, מוסרים הרשאות, תיעוד והדרכת הצוות.

תוצרי מסירה: סכימות, נהלים, קונפיגורציות

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

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

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

מקרה בוחן: בירור תקלות התקצר מימים לשעות

נקודת מוצא

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

מה שינינו ומה קיבלנו

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

מעל הקטלוג הוגדרו התראות: שינוי סכימה או טיפוס שדה במקור מפעיל התראה לפני שאי-ההתאמה מגיעה ל-Data Mart.

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

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

במה שונה ניתוח קוד ממעקב בזרימת נתונים

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

מה קורה לגרף כשהסכימה משתנה — שינוי שם, עמודה חדשה, drop?

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

אפשר להתחיל מתחום אחד ולא מכל הפלטפורמה?

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

החיבור של מקורות ידרוש שינויים בסביבת הייצור?

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

מה נשאר אצלנו אחרי המסירה?

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

נדון במשימה ונחזור עם תוכנית והערכה

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

תארו את המשימה בצורה חופשית: אילו דוחות ומודלים צריכים להיות מכוסים ב-data lineage ראשונים, מה כבר נאסף מהמטא-נתונים ובאיזו נקודת חיבור התמונה הולכת לאיבוד — בין המקורות, בטרנספורמציות או ב-Data Marts.

מצד הלקוח, לצורך החישוב בדרך כלל מספיק:

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

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