כיצד לאמת נתונים, ניתוחים והדמיות נתונים

בדיקת יישומים היא תחום מתבגר עם כלים המסייעים לצוותי אבטחת איכות לפתח ולבנות בדיקות פונקציונליות, להריץ בדיקות עומס וביצועים, לבצע ניתוח קוד סטטי, לעטוף ממשקי API עם בדיקות יחידה ולאמת יישומים כנגד בעיות אבטחה ידועות. צוותים המתאמנים ב- devops יכולים ליישם בדיקות רציפות על ידי הכללת כל הבדיקות האוטומטיות או תת-קבוצה שלהם בצינורות ה- CI / CD שלהם ולהשתמש בתוצאות כדי לקבוע אם יש להעביר מבנה לסביבת היעד.

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

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

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

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

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

הבנת שושלת הנתונים ואיכות הנתונים

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

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

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

Informatica, Talend, IBM, Oracle, Microsoft, ורבים אחרים מציעים כלים באיכות נתונים המתחברים לפלטפורמות ה- ETL שלהם, בעוד שלכלים להכנת נתונים של Tableau, Alteryx, Paxata, Trifacta ואחרות יכולות איכות נתונים.

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

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

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

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

זה אמנם מושג פשוט יחסית, אך לא טריוויאלי ליישום.

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

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

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

עבודה עם מומחי נושא ביעילות

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

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

כדי לנצל את זמנם ביעילות, אני ממליץ על שלוש פעילויות נפרדות:

  • יישם כמה שיותר מאיכות הנתונים, שושלת הנתונים ובדיקת A / B על מערכי נתונים זהובים. לפני שתצטרף למומחים בנושא, עשה מאמצים סבירים לאמת שנתונים גולמיים ומחושבים נכונים. זה צריך להיעשות בביטחון כדי שתוכל להסביר ולהמחיש באופן אידיאלי למומחי נושא שהנתונים הבסיסיים, השינויים והחישובים מדויקים - כך שהם יכולים להיות בטוחים שהם לא צריכים להשקיע זמן משמעותי כדי לבדוק אותם באופן ידני.
  • תכנן ויזואליזציה של נתונים שיעזרו למומחים לנושאים לסקור ולאמת את הנתונים והניתוחים. חלק מההדמיות יכולות להיות תפוקות ממבחני A / B, בעוד שאחרות צריכות להיות הדמיות החושפות נתונים ברמה נמוכה. כאשר מיישמים נתונים בקנה מידה גדול יותר, אלגוריתם, מודל או הדמיה, זה עוזר לעיתים קרובות להדמיה של נתוני בקרת איכות אלה כדי לסייע למומחי נושא לבצע אימות מהיר.
  • אתה רוצה שמומחי נושא יבצעו בדיקות קבלת משתמשים (UAT) על היישומים הסופיים והדמיית הנתונים. עד שהם מגיעים לשלב זה הם צריכים להיות בטוחים לחלוטין שהנתונים והניתוחים תקפים.

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

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