בקרת איכות נתונים מבוססת בינה מלאכותית: אוטומציה ואיתור אנומליות

בקרת איכות נתונים: איפה נשברים צינורות הנתונים

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

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

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

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

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

אנומליות בנתונים: מה נותן גילוי מוקדם

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

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

את הבדיקות מתארים בפריימוורק הפתוח Great Expectations — הכללים חיים לצד קוד הטעינה ומנוהלים בגרסאות יחד איתו.

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

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

שיטות בדיקה: כללים, סטטיסטיקה, מודלים

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

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

השוואת גישות

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

איך מתבצעת הטמעת הבדיקות בשלבים

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

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

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

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

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

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

מקרה בוחן: איך הסרנו תקלות בוויטרינות הדיווח

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

מה שינינו

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

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

מה השתנה

• הזמן עד גילוי התקלה: מכמה יממות ל-15 דקות — בתחילת הטעינה, ולא אחרי תלונה.
• שיעור האנומליות שנתפסות: כ-94% לעומת כשליש בבדיקות התאמה ידניות מדגמיות.
• חקירות ידניות: מ-28 בחודש ל-3–4, וגם הן — על סוגי כשל חדשים שעוד לא תוארו בכלל.
• לא היה צורך להרחיב את הצוות בגלל היקף הנתונים שגדל: מקורות חדשים מתחברים לפי תבנית בדיקות בתוך יום.

מה לעשות אם הבדיקות כבר מוגדרות חלקית

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

ביקורת כזו בדרך כלל מסירה 20–40% מהכללים: הם משכפלים זה את זה, מפנים לשדות ששמם שונה, או שלא הניבו הפעלה במשך שנים.

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

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

ספקות טכניים ומגבלות השיטות

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

איך נלקחים בחשבון גלי עונתיות ושיאים מתוכננים?

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

מה קורה עם נתונים רגישים?

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

האם נצטרך לעצור את הטעינה בזמן ההטמעה?

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

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

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

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

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

תארו את המשימה בצורה חופשית — את השאר נבהיר בשאלות.