מה יכול להשתבש ב-Data Science? איסוף נתונים

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

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

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

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

והכי חשוב, נדון מה לעשות כדי למנוע זאת.

לפי הערכות שונות, ניקוי, טרנספורמציה, עיבוד נתונים, הנדסת תכונות וכו' לוקחים 80-90% מהזמן, וניתוח 10-20%, כאשר כמעט כל החומר החינוכי מתמקד אך ורק בניתוח.

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

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

1. שני סאמדיטים של Reddit
2. שני חלקים מהבר
3. שתי קבוצות של Odnoklassniki

גישה מותנית בתיאוריה

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

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

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

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

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

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

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

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

השוואה בין קהילות Reddit

נתחיל מהמקרה הפשוט ביותר (כפי שמתברר בהמשך). באופן כללי, למען האמת, יש לנו מקרה כמעט אידיאלי, בואו נבדוק את רשימת המורכבות שלנו:

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

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

נלקח מ זה מבחר כלי עזר נוחים לעיטוף.

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

• מגבלות API – אנו נאלצים לקחת נתונים באצוות (שינה בין בקשות וכו').
• זמן איסוף - לניתוח והשוואה מלאים, תצטרכו להקדיש זמן משמעותי רק כדי שהעכביש יעבור דרך הסוברדיט.
• הבוט חייב לפעול על שרת - אתה לא יכול פשוט להריץ אותו על המחשב הנייד שלך, לשים אותו בתרמיל שלך ולעשות את העסק שלך. אז הרצתי הכל על VPS. באמצעות קוד הקידום habrahabr10 תוכל לחסוך עוד 10% מהעלות.
• חוסר הנגישות הפיזית של חלק מהנתונים (הם גלויים למנהלים או קשים מדי לאיסוף) - יש לקחת זאת בחשבון; עקרונית, לא ניתן לאסוף את כל הנתונים בזמן הולם.
• שגיאות רשת: יצירת רשת היא כאב.
• אלו נתונים אמיתיים חיים - הם אף פעם לא טהורים.

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

השוואה בין קטעי חאב

נעבור למקרה יותר מעניין ולא טריוויאלי של השוואה בין שרשורים ו/או קטעים של חבר.

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

• בהתחלה אתה חושב שיש API, אבל אין. כן, כן, ל-Habr יש API, אבל הוא פשוט לא נגיש למשתמשים (או שאולי הוא לא עובד בכלל).
• ואז אתה פשוט מתחיל לנתח html - "בקשות יבוא", מה יכול להשתבש?
• איך לנתח בכל זאת? הגישה הפשוטה והנפוצה ביותר היא לבצע איטרציה על תעודות זהות, שימו לב שהיא לא היעילה ביותר ותצטרך לטפל במקרים שונים - הנה דוגמה לצפיפות של תעודות זהות אמיתיות בין כל הקיימות.

  
  נלקח מ זה מאמרים.

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

  1) int(score) זורק שגיאה: מכיוון שעל Habré יש מינוס, כמו, למשל, בשורה "–5" - זהו מקף en, לא סימן מינוס (באופן בלתי צפוי, נכון?), אז ב- בשלב מסוים הייתי צריך להחיות את המנתח עם תיקון כל כך נורא.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  ייתכן שלא יהיו תאריך, פלוסים ומינוסים בכלל (כפי שאנו רואים למעלה בפונקציית check_date, זה קרה).

  2) דמויות מיוחדות שלא נמלטו - הן יבואו, צריך להתכונן.

  3) המבנה משתנה בהתאם לסוג הפוסט.

  4) לפוסטים ישנים עשוי להיות **מבנה מוזר**.

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

רשימת בדיקה כוללת לפי מורכבות:

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

הזמן המשוער למשימה זו יהיה גבוה פי 3-5 מאשר לאיסוף נתונים מ- Reddit.

השוואה בין קבוצות Odnoklassniki

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

נתחיל ברשימת הקשיים שלנו ונשים לב שרבים מהם יתבררו כקשים הרבה יותר ממה שהם נראים בהתחלה:

• יש ממשק API, אבל כמעט חסר לו את הפונקציות הדרושות.
• לפונקציות מסוימות אתה צריך לבקש גישה בדואר, כלומר, הענקת הגישה אינה מיידית.
• זה נורא מתועד (לכתחילה, מונחים רוסית ואנגלית מתערבבים בכל מקום, ולגמרי לא עקבי - לפעמים צריך רק לנחש מה רוצים ממך איפשהו) ויותר מכך, העיצוב לא מתאים להשגת נתונים, למשל , הפונקציה שאנו צריכים.
• דורש סשן בתיעוד, אבל לא ממש משתמש בו - ואין דרך להבין את כל המורכבויות של מצבי ה-API מלבד לחטט ולקוות שמשהו יעבוד.
• אין דוגמאות ואין קהילה; נקודת התמיכה היחידה באיסוף מידע היא קטנה עֲטִיפָה ב-Python (ללא הרבה דוגמאות לשימוש).
• נראה כי סלניום הוא האפשרות הישימה ביותר, מכיוון שרבים מהנתונים הדרושים נעולים.
  1) כלומר, ההרשאה מתבצעת באמצעות משתמש פיקטיבי (ורישום ביד).

  2) עם זאת, עם סלניום אין ערבויות לעבודה נכונה וניתנת לחזרה (לפחות במקרה של ok.ru בוודאות).

  3) אתר Ok.ru מכיל שגיאות JavaScript ולעיתים מתנהג בצורה מוזרה ובלתי עקבית.

  4) אתה צריך לעשות עימוד, טעינת אלמנטים וכו'...

  5) שגיאות API שהעטיפה נותנת יצטרכו להיות מטופלות בצורה לא נוחה, למשל, כך (חתיכת קוד ניסיוני):

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #makes sense to keep track of already processed discussions
          for discussion in tqdm(discussions): 
              try:
                  comments = get_comments_from_discussion_via_api(context, discussion)
              except odnoklassniki.api.OdnoklassnikiError as e:
                  if "NOT_FOUND" in str(e):
                      comments = set()
                  else:
                      print(e)
                      bp()
                      pass
              all_comments |= comments
              time.sleep(pause)
          return all_comments
  

  הטעות האהובה עלי הייתה:

  OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

  6) בסופו של דבר, סלניום + API נראה כמו האפשרות הרציונלית ביותר.

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

אומדן הזמן המותנה למשימה זו יהיה גבוה פי 3-5 מאשר לאיסוף נתונים מהבר. למרות העובדה שבמקרה של Habr אנו משתמשים בגישה פרונטלית עם ניתוח HTML, ובמקרה של OK נוכל לעבוד עם ה-API במקומות קריטיים.

ממצאים

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

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

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

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

מניסיוני, הגישה היעילה ביותר היא להעריך באופן גס את הזמן שתזדקק לו לניתוח המקדים עצמו ולניסויים ראשונים פשוטים, קריאת התיעוד – אלו יאפשרו לך לתת אומדן מדויק לכל העבודה. מבחינת המתודולוגיה האג'ילית הפופולרית, אני מבקש מכם ליצור כרטיס ל"הערכת פרמטרי משימה", שעל בסיסו אוכל לתת הערכה מה ניתן להשיג במסגרת ה"ספרינט" ולתת הערכה מדויקת יותר לכל אחד. מְשִׁימָה.

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

מקור: www.habr.com