אחת המיומנויות החיוניות של מקצוען נתונים מיומן היא טיפול יעיל במערך נתונים גדולים, הבטחת איכות ואמינות נתונים. נתונים הם החלק המרכזי והבסיסי של כל מערכת נתונים, וכל כישורים טובים שיש לך בהיבטים אחרים של המסחר שלנו, זה אחד שאתה לא יכול להרשות לעצמך להתעלם ממנו. במאמר זה, אני בוחן טכניקות חזקות לביצוע בדיקות QA על מערכי נתונים גדולים באמצעות ספריית Deequ ושיטות סטטיסטיות. על ידי שילוב הגישות שאני מסביר להלן, תוכל לשמור על שלמות הנתונים, לשפר את שיטות ניהול הנתונים שלך ולמנוע בעיות פוטנציאליות ביישומים במורד הזרם. בדיקות QA באמצעות ספריית Deequ למה Deequ? הבטחת איכות הנתונים בקנה מידה היא משימה מרתיעה, במיוחד כאשר מתמודדים עם מיליארדי שורות המאוחסנות במערכות קבצים מבוזרות או במחסני נתונים. ספריית Deequ היא מסגרת פרופיל נתונים ו-QA בקוד פתוח הבנויה על Spark שהיא כלי מודרני ורב-תכליתי שנועד לפתור בעיה זו. מה שמייחד אותו מכלים דומים הוא היכולת שלו להשתלב בצורה חלקה עם Spark, תוך מינוף כוח עיבוד מבוזר לטיפול יעיל במערכי נתונים בקנה מידה גדול. כשתנסה אותו, תראה כיצד הגמישות שלו מאפשרת לך להגדיר כללי אימות מורכבים המותאמים לדרישות הספציפיות שלך, מה שמבטיח כיסוי מקיף. בנוסף, Deequ כולל מדדים נרחבים ויכולות זיהוי חריגות שיעזרו לך לזהות ולטפל באופן יזום בבעיות איכות הנתונים. עבור אנשי מקצוע בתחום הנתונים העובדים עם מערכי נתונים גדולים ודינמיים, Deequ הוא פתרון סכין שוויצרי. בואו נראה איך אנחנו יכולים להשתמש בו. הגדרת Deequ פרטים נוספים על הגדרת ספריית Deequ ומקרי שימוש סביב פרופיל נתונים נגישים . למען הפשטות, בדוגמה זו, רק יצרנו כמה רשומות צעצוע: כאן val rdd = spark.sparkContext.parallelize(Seq( Item(1, "Thingy A", "awesome thing.", "high", 0), Item(2, "Thingy B", "available at http://thingb.com", null, 0), Item(3, null, null, "low", 5), Item(4, "Thingy D", "checkout https://thingd.ca", "low", 10), Item(5, "Thingy E", null, "high", 12))) val data = spark.createDataFrame(rdd) הגדרת הנחות נתונים רוב יישומי הנתונים מגיעים עם הנחות מרומזות לגבי תכונות נתונים, כגון ערכים שאינם NULL וייחודיות. עם Deequ, הנחות אלו הופכות מפורשות באמצעות בדיקות יחידה. להלן מספר בדיקות נפוצות: ודא שמערך הנתונים מכיל מספר מסוים של שורות. ספירת שורות: בדוק שתכונות כמו id ו-productName לעולם אינן NULL. שלמות התכונה: ודא שתכונות מסוימות, כגון id, הן ייחודיות. ייחודיות תכונה: אמת שתכונות כמו priority ו-numViews נופלות בטווחים הצפויים. טווח ערכים: ודא שתיאורים מכילים כתובות אתרים כאשר צפוי. התאמת דפוסים: ודא שהחציון של תכונות מספריות עומד בקריטריונים ספציפיים. מאפיינים סטטיסטיים: כך תוכל ליישם את הבדיקות הללו באמצעות Deequ: import com.amazon.deequ.VerificationSuite import com.amazon.deequ.checks.{Check, CheckLevel, CheckStatus} val verificationResult = VerificationSuite() .onData(data) .addCheck( Check(CheckLevel.Error, "unit testing my data") .hasSize(_ == 5) // we expect 5 rows .isComplete("id") // should never be NULL .isUnique("id") // should not contain duplicates .isComplete("productName") // should never be NULL // should only contain the values "high" and "low" .isContainedIn("priority", Array("high", "low")) .isNonNegative("numViews") // should not contain negative values // at least half of the descriptions should contain a url .containsURL("description", _ >= 0.5) // half of the items should have less than 10 views .hasApproxQuantile("numViews", 0.5, _ <= 10)) .run() פירוש תוצאות לאחר הפעלת הבדיקות הללו, Deequ מתרגם אותן לסדרה של עבודות Spark, אותן היא מבצעת כדי לחשב מדדים על הנתונים. לאחר מכן, הוא מפעיל את פונקציות ההצהרה שלך (למשל, _ == 5 לבדיקת הגודל) במדדים אלה כדי לראות אם האילוצים מתקיימים בנתונים. אנו יכולים לבדוק את האובייקט "verificationResult" כדי לראות אם הבדיקה מצאה שגיאות: import com.amazon.deequ.constraints.ConstraintStatus if (verificationResult.status == CheckStatus.Success) { println("The data passed the test, everything is fine!") } else { println("We found errors in the data:\n") val resultsForAllConstraints = verificationResult.checkResults .flatMap { case (_, checkResult) => checkResult.constraintResults } resultsForAllConstraints .filter { _.status != ConstraintStatus.Success } .foreach { result => println(s"${result.constraint}: ${result.message.get}") } } אם נריץ את הדוגמה, נקבל את הפלט הבא: We found errors in the data: CompletenessConstraint(Completeness(productName)): Value: 0.8 does not meet the requirement! PatternConstraint(containsURL(description)): Value: 0.4 does not meet the requirement! הבדיקה מצאה שההנחות שלנו הופרו! רק 4 מתוך 5 (80%) מהערכים של התכונה productName אינם אפסיים, ורק 2 מתוך 5 (כלומר, 40%) ערכים של תכונת התיאור אכן הכילו כתובת URL. למרבה המזל, הרצנו בדיקה ומצאנו את השגיאות; מישהו צריך לתקן מיד את הנתונים! בדיקות QA בשיטות סטטיסטיות בעוד Deequ מציעה מסגרת חזקה לאימות נתונים, שילוב שיטות סטטיסטיות יכול לשפר עוד יותר את בדיקות ה-QA שלך, במיוחד אם אתה עוסק במדדים מצטברים של מערך נתונים. בוא נראה איך אתה יכול להשתמש בשיטות סטטיסטיות כדי לנטר ולהבטיח את איכות הנתונים. מעקב אחר ספירת רשומות שקול תרחיש עסקי שבו תהליך ETL (חילוץ, טרנספורמציה, טעינה) מייצר N רשומות בעבודה מתוזמנת יומית. צוותי תמיכה עשויים לרצות להגדיר בדיקות QA כדי להעלות התראה אם יש סטייה משמעותית בספירת הרשומות. לדוגמה, אם התהליך יוצר בדרך כלל בין 9,500 ל-10,500 רשומות מדי יום במשך חודשיים, כל עלייה או ירידה משמעותית יכולה להצביע על בעיה בנתונים הבסיסיים. אנו יכולים להשתמש בשיטה סטטיסטית כדי להגדיר את הסף הזה על איזה תהליך צריך להעלות התראה לצוות התמיכה. להלן המחשה של מעקב אחר ספירת שיאים במשך חודשיים: כדי לנתח זאת, אנו יכולים להפוך את נתוני ספירת הרשומות כדי לצפות בשינויים היומיומיים. שינויים אלה נעים בדרך כלל סביב האפס, כפי שמוצג בתרשים הבא: כאשר אנו מייצגים את קצב השינוי הזה בהתפלגות נורמלית, הוא יוצר עקומת פעמון, המעידה על כך שהנתונים מחולקים בצורה נורמלית. השינוי הצפוי הוא סביב 0%, עם סטיית תקן של 2.63%. ניתוח זה מצביע על כך שספירת השיא נופלת בדרך כלל בטווח של -5.26% עד +5.25% עם ביטחון של 90%. בהתבסס על זה, אתה יכול לקבוע כלל להעלאת התראה אם ספירת הרשומות חורגת מטווח זה, מה שמבטיח התערבות בזמן. מעקב אחר כיסוי תכונה מתייחס ליחס בין ערכים שאינם NULL לספירת הרשומות הכוללת עבור תמונת מצב של מערך נתונים. לדוגמה, אם ל-8 מתוך 100 רשומות יש ערך NULL עבור תכונה מסוימת, הכיסוי עבור תכונה זו הוא 92%. כיסוי תכונה בואו נסקור מקרה עסקי נוסף עם תהליך ETL המייצר תמונת מצב של טבלת מוצר מדי יום. אנחנו רוצים לעקוב אחר הכיסוי של תכונות תיאור המוצר. אם הכיסוי יורד מתחת לסף מסוים, יש להעלות התראה לצוות התמיכה. להלן ייצוג חזותי של כיסוי מאפיינים עבור תיאורי מוצרים במשך חודשיים: על ידי ניתוח ההבדלים המוחלטים ביום-יום בכיסוי, אנו רואים שהשינויים נעים סביב האפס: הצגת נתונים אלה כהתפלגות נורמלית מראה שהם מתפלגים נורמלית עם שינוי צפוי של סביב 0% וסטיית תקן של 2.45%. כפי שאנו רואים, עבור מערך נתונים זה, כיסוי תכונת תיאור המוצר נע בדרך כלל בין -4.9% ל-+4.9% עם ביטחון של 90%. בהתבסס על מחוון זה, אנו יכולים להגדיר כלל להעלאת התראה אם הכיסוי חורג מעבר לטווח זה. בדיקות QA עם אלגוריתמים של סדרות זמן אם אתה עובד עם מערכי נתונים שמציגים שינויים משמעותיים עקב גורמים כמו עונתיות או מגמות, שיטות סטטיסטיות מסורתיות עשויות להפעיל התראות שווא. אלגוריתמים של סדרות זמן מציעים גישה מעודנת יותר, ומשפרים את הדיוק והאמינות של בדיקות ה-QA שלך. כדי לייצר התראות הגיוניות יותר, אתה יכול להשתמש ב- או את . הראשון טוב מספיק עבור מערכי נתונים עם מגמות, אבל השני מאפשר לנו להתמודד עם מערכי נתונים עם מגמה וגם עונתיות. שיטה זו משתמשת ברכיבים לרמה, מגמה ועונתיות, מה שמאפשר לה להסתגל בצורה גמישה לשינויים לאורך זמן. Autoregressive Integrated Moving Average (ARIMA) שיטת הולט-חורף בואו נדגמן מכירות יומיות המציגות גם דפוסים מגמתיים וגם עונתיים באמצעות Holt-Winters: import pandas as pd from statsmodels.tsa.holtwinters import ExponentialSmoothing # Load and preprocess the dataset data = pd.read_csv('sales_data.csv', index_col='date', parse_dates=True) data = data.asfreq('D').fillna(method='ffill') # Fit the Holt-Winters model model = ExponentialSmoothing(data, trend='add', seasonal='add', seasonal_periods=365) fit = model.fit() # Forecast and detect anomalies forecast = fit.fittedvalues residuals = data - forecast threshold = 3 * residuals.std() anomalies = residuals[abs(residuals) > threshold] print("Anomalies detected:") print(anomalies) באמצעות שיטה זו, אתה יכול לזהות סטיות משמעותיות שעשויות להצביע על בעיות באיכות הנתונים, מה שמספק גישה ניואנסית יותר לבדיקות QA. אני מקווה שמאמר זה יעזור לך ליישם ביעילות בדיקות QA עבור מערכי הנתונים הגדולים שלך. על ידי שימוש בספריית Deequ ושילוב שיטות סטטיסטיות ואלגוריתמים של סדרות זמן, אתה יכול להבטיח שלמות ואמינות נתונים, ובסופו של דבר לשפר את שיטות ניהול הנתונים שלך. יישום הטכניקות המתוארות לעיל יעזור לך למנוע בעיות פוטנציאליות ביישומים במורד הזרם ולשפר את האיכות הכוללת של זרימות העבודה של הנתונים שלך.
