რა შეიძლება წარიმართოს მონაცემთა მეცნიერებაში? მონაცემთა შეგროვება

დღესდღეობით მონაცემთა მეცნიერების 100500 კურსია და უკვე დიდი ხანია ცნობილია, რომ მონაცემთა მეცნიერებაში ყველაზე მეტი ფულის შოვნა შესაძლებელია მონაცემთა მეცნიერების კურსებით (რატომ იჭრება, როცა ნიჩბების გაყიდვა შეგიძლია?). ამ კურსების მთავარი მინუსი არის ის, რომ მათ არავითარი კავშირი არ აქვთ რეალურ სამუშაოსთან: არავინ მოგცემთ სუფთა, დამუშავებულ მონაცემებს საჭირო ფორმატში. და როცა ტოვებ კურსს და იწყებ რეალური პრობლემის გადაჭრას, ჩნდება მრავალი ნიუანსი.

ამიტომ, ჩვენ ვიწყებთ ჩანაწერების სერიას „რა შეიძლება წარიმართოს მონაცემთა მეცნიერებაში“, ეფუძნება რეალურ მოვლენებს, რაც მოხდა ჩემთან, ჩემს ამხანაგებთან და კოლეგებთან. ჩვენ გავაანალიზებთ მონაცემთა მეცნიერების ტიპურ ამოცანებს რეალური მაგალითების გამოყენებით: როგორ ხდება ეს სინამდვილეში. დავიწყოთ დღეს მონაცემთა შეგროვების ამოცანებით.

და პირველი, რაზეც ადამიანები აბრკოლებენ, როდესაც ისინი რეალურ მონაცემებთან მუშაობას იწყებენ, რეალურად აგროვებენ ამ მონაცემებს, რომლებიც ჩვენთვის ყველაზე აქტუალურია. ამ სტატიის მთავარი მესიჯი:

ჩვენ სისტემატურად ვაფასებთ დროს, რესურსებსა და ძალისხმევას, რომელიც საჭიროა მონაცემთა შეგროვების, გაწმენდისა და მომზადებისთვის.

და რაც მთავარია, ჩვენ განვიხილავთ რა უნდა გავაკეთოთ ამის თავიდან ასაცილებლად.

სხვადასხვა შეფასებით, დასუფთავებას, ტრანსფორმაციას, მონაცემთა დამუშავებას, ფუნქციური ინჟინერიას და ა.შ. დრო 80-90%-ს იკავებს, ანალიზს კი 10-20%-ს, მაშინ როცა თითქმის ყველა სასწავლო მასალა ფოკუსირებულია ექსკლუზიურად ანალიზზე.

მოდით შევხედოთ მარტივ ანალიტიკურ პრობლემას სამი ვერსიით, როგორც ტიპიური მაგალითი და ვნახოთ, რა არის „დამამძიმებელი გარემოებები“.

მაგალითად, კვლავ განვიხილავთ მონაცემთა შეგროვებისა და თემების შედარების ამოცანის მსგავს ვარიაციებს:

1. Reddit-ის ორი ქვერედიტი
2. ჰაბრის ორი განყოფილება
3. ოდნოკლასნიკის ორი ჯგუფი

პირობითი მიდგომა თეორიაში

გახსენით საიტი და წაიკითხეთ მაგალითები, თუ ეს გასაგებია, გამოყავით რამდენიმე საათი წასაკითხად, რამდენიმე საათი კოდისთვის მაგალითების გამოყენებით და გამართვისთვის. დაამატეთ რამდენიმე საათი შეგროვებისთვის. ჩაყარეთ რამდენიმე საათი რეზერვში (გამრავლეთ ორზე და დაამატეთ N საათი).

საკვანძო წერტილი: დროის შეფასებები ეფუძნება ვარაუდებსა და გამოცნობებს იმის შესახებ, თუ რამდენ ხანს დასჭირდება.

აუცილებელია დროის ანალიზის დაწყება ზემოთ აღწერილი პირობითი პრობლემის შემდეგი პარამეტრების შეფასებით:

• რა არის მონაცემების ზომა და რამდენი სჭირდება ფიზიკურად შეგროვებას (*იხილეთ ქვემოთ*).
• რა არის ერთი ჩანაწერის შეგროვების დრო და რამდენი ხანი უნდა დაელოდოთ მეორეს შეგროვებას?
• იფიქრეთ კოდის დაწერაზე, რომელიც ინახავს მდგომარეობას და იწყებს გადატვირთვას, როცა (არა თუ) ყველაფერი ვერ ხერხდება.
• გაარკვიეთ გვჭირდება თუ არა ავტორიზაცია და დააყენეთ დრო API-ით წვდომის მისაღებად.
• დააყენეთ შეცდომების რაოდენობა, როგორც მონაცემთა სირთულის ფუნქცია - შეაფასეთ კონკრეტული დავალება: სტრუქტურა, რამდენი ტრანსფორმაცია, რა და როგორ უნდა ამოიღოთ.
• შეასწორეთ ქსელის შეცდომები და პრობლემები პროექტის არასტანდარტული ქცევით.
• შეაფასეთ, არის თუ არა საჭირო ფუნქციები დოკუმენტაციაში და თუ არა, მაშინ როგორ და რამდენია საჭირო გამოსავლისთვის.

ყველაზე მნიშვნელოვანი ის არის, რომ დროის შესაფასებლად - რეალურად საჭიროა დრო და ძალისხმევა დახარჯოთ "ძალიან დაზვერვაზე" - მხოლოდ მაშინ იქნება თქვენი დაგეგმვა ადეკვატური. ამიტომ, რაც არ უნდა აიძულოთ თქვათ „რამდენი ხანი სჭირდება მონაცემების შეგროვებას“ - იყიდეთ გარკვეული დრო წინასწარი ანალიზისთვის და იმსჯელეთ იმაზე, თუ რამდენად განსხვავდება დრო პრობლემის რეალური პარამეტრების მიხედვით.

ახლა კი ჩვენ ვაჩვენებთ კონკრეტულ მაგალითებს, სადაც შეიცვლება ასეთი პარამეტრები.

საკვანძო წერტილი: შეფასება ეფუძნება ძირითადი ფაქტორების ანალიზს, რომლებიც გავლენას ახდენენ სამუშაოს მოცულობასა და სირთულეზე.

გამოცნობაზე დაფუძნებული შეფასება კარგი მიდგომაა, როდესაც ფუნქციური ელემენტები საკმარისად მცირეა და არ არის ბევრი ფაქტორი, რომელსაც შეუძლია მნიშვნელოვანი გავლენა მოახდინოს პრობლემის დიზაინზე. მაგრამ მონაცემთა მეცნიერების მთელი რიგი პრობლემების შემთხვევაში, ასეთი ფაქტორები ძალიან მრავალრიცხოვანი ხდება და ასეთი მიდგომა არაადეკვატური ხდება.

Reddit თემების შედარება

დავიწყოთ უმარტივესი შემთხვევით (როგორც მოგვიანებით ირკვევა). ზოგადად, გულწრფელად რომ ვთქვათ, ჩვენ გვაქვს თითქმის იდეალური შემთხვევა, მოდით გადავამოწმოთ ჩვენი სირთულის ჩამონათვალი:

• არსებობს სუფთა, ნათელი და დოკუმენტირებული API.
• ეს ძალიან მარტივია და რაც მთავარია, ჟეტონი მიიღება ავტომატურად.
• არსებობს პითონის შეფუთვა - უამრავი მაგალითით.
• საზოგადოება, რომელიც აანალიზებს და აგროვებს მონაცემებს reddit-ზე (თუნდაც YouTube-ის ვიდეოებზე, სადაც ახსნილია, როგორ გამოიყენოთ პითონის შეფუთვა) Მაგალითად.
• მეთოდები, რომლებიც გვჭირდება, სავარაუდოდ, არსებობს 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-ს ლიმიტები - ჩვენ იძულებულნი ვართ ავიღოთ მონაცემები პარტიაში (მოთხოვნებს შორის ძილი და ა.შ.).
• შეგროვების დრო - სრული ანალიზისა და შედარებისთვის, თქვენ მოგიწევთ მნიშვნელოვანი დრო გამოყოთ მხოლოდ ობობას subreddit-ის გასავლელად.
• ბოტი უნდა იმუშაოს სერვერზე - თქვენ არ შეგიძლიათ უბრალოდ გაუშვათ იგი თქვენს ლეპტოპზე, ჩადოთ ზურგჩანთაში და დაიწყოთ თქვენი საქმე. ასე რომ, ყველაფერი VPS-ზე გავატარე. სარეკლამო კოდი habrahabr10-ის გამოყენებით შეგიძლიათ დაზოგოთ ღირებულების კიდევ 10%.
• ზოგიერთი მონაცემის ფიზიკური მიუწვდომლობა (ისინი ხილულია ადმინისტრატორებისთვის ან ძალიან რთულია მათი შეგროვება) - ეს გასათვალისწინებელია; პრინციპში, ყველა მონაცემი არ შეიძლება შეგროვდეს ადეკვატურ დროში.
• ქსელის შეცდომები: ქსელში მუშაობა მტკივნეულია.
• ეს არის ცოცხალი რეალური მონაცემები - ის არასოდეს არის სუფთა.

რა თქმა უნდა, აუცილებელია ამ ნიუანსების განვითარებაში ჩართვა. კონკრეტული საათები/დღეები დამოკიდებულია განვითარების გამოცდილებაზე ან მსგავს ამოცანებზე მუშაობის გამოცდილებაზე, თუმცა, ჩვენ ვხედავთ, რომ აქ ამოცანა არის წმინდა საინჟინრო და არ საჭიროებს სხეულის დამატებით მოძრაობებს გადასაჭრელად - ყველაფერი შეიძლება ძალიან კარგად შეფასდეს, დაგეგმოს და შესრულდეს.

ჰაბრის მონაკვეთების შედარება

გადავიდეთ Habr-ის ძაფების და/ან მონაკვეთების შედარების უფრო საინტერესო და არატრივიალურ შემთხვევაზე.

მოდით გადავამოწმოთ ჩვენი სირთულის ჩამონათვალი - აქ, იმისათვის, რომ გაიგოთ თითოეული წერტილი, თქვენ მოგიწევთ ცოტათი ჩათხაროთ თავად დავალება და ექსპერიმენტი.

• თავდაპირველად ფიქრობთ, რომ არსებობს API, მაგრამ არ არის. დიახ, დიახ, Habr-ს აქვს API, მაგრამ ის უბრალოდ მიუწვდომელია მომხმარებლებისთვის (ან შესაძლოა ის საერთოდ არ მუშაობს).
• შემდეგ თქვენ უბრალოდ იწყებთ html-ის ანალიზს - „იმპორტის მოთხოვნები“, რა შეიძლება მოხდეს არასწორად?
• მაინც როგორ გავაანალიზო? უმარტივესი და ყველაზე ხშირად გამოყენებული მიდგომა არის პირადობის მოწმობების გამეორება, გაითვალისწინეთ, რომ ეს არ არის ყველაზე ეფექტური და მოუწევს სხვადასხვა შემთხვევის დამუშავება - აქ არის რეალური ID-ების სიმკვრივის მაგალითი ყველა არსებულს შორის.

  
  Აღებულია ამ სტატიები.

• 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 ანალიზთან ერთად iteration და ძიება ID-ით.
• ჰეტეროგენული სტრუქტურის დოკუმენტები.
• ბევრი ადგილია, სადაც კოდი ადვილად შეიძლება დაეცეს.
• აუცილებელია დაწეროს || კოდი.
• საჭირო დოკუმენტაცია, კოდის მაგალითები და/ან საზოგადოება აკლია.

ამ დავალების სავარაუდო დრო 3-5-ჯერ მეტი იქნება, ვიდრე Reddit-ის მონაცემების შეგროვებისთვის.

ოდნოკლასნიკის ჯგუფების შედარება

გადავიდეთ აღწერილ ტექნიკურად ყველაზე საინტერესო შემთხვევაზე. ჩემთვის საინტერესო იყო ზუსტად იმიტომ, რომ ერთი შეხედვით საკმაოდ ტრივიალური ჩანს, მაგრამ სულაც არ გამოდის - როგორც კი ჯოხს აჭერ.

დავიწყოთ ჩვენი სირთულის სიით და აღვნიშნოთ, რომ ბევრი მათგანი ბევრად უფრო რთული აღმოჩნდება, ვიდრე ერთი შეხედვით ჩანს:

• არსებობს API, მაგრამ მას თითქმის მთლიანად აკლია საჭირო ფუნქციები.
• გარკვეულ ფუნქციებზე თქვენ უნდა მოითხოვოთ წვდომა ფოსტით, ანუ წვდომის მინიჭება არ არის მყისიერი.
• ეს საშინლად არის დოკუმენტირებული (დაწყებული, რუსული და ინგლისური ტერმინები ყველგან არის შერეული და სრულიად არათანმიმდევრულად - ზოგჯერ უბრალოდ უნდა გამოიცნოთ რა უნდათ თქვენგან სადმე) და, უფრო მეტიც, დიზაინი არ არის შესაფერისი მონაცემების მისაღებად, მაგალითად. , ფუნქცია, რომელიც ჩვენ გვჭირდება.
• საჭიროებს სესიას დოკუმენტაციაში, მაგრამ რეალურად არ იყენებს მას - და არ არსებობს გზა, რომ გავიგოთ API რეჟიმის ყველა სირთულე, გარდა იმისა, რომ იფიქროთ და იმედოვნებთ, რომ რაღაც იმუშავებს.
• არ არსებობს მაგალითები და საზოგადოება; ინფორმაციის შეგროვების ერთადერთი მხარდაჭერის წერტილი მცირეა შესაფუთი პითონში (გამოყენების მრავალი მაგალითის გარეშე).
• სელენი, როგორც ჩანს, ყველაზე გამოსადეგი ვარიანტია, რადგან ბევრი საჭირო მონაცემი ჩაკეტილია.
  1) ანუ ავტორიზაცია ხდება ფიქტიური მომხმარებლის მეშვეობით (და რეგისტრაცია ხელით).

  2) თუმცა სელენით არ არსებობს გარანტიები სწორი და განმეორებადი მუშაობისთვის (ყოველ შემთხვევაში ok.ru-ს შემთხვევაში აუცილებლად).

  3) Ok.ru ვებსაიტი შეიცავს JavaScript შეცდომებს და ზოგჯერ უცნაურად და არათანმიმდევრულად იქცევა.

  4) თქვენ უნდა გააკეთოთ პაგინაცია, ჩატვირთოთ ელემენტები და ა.შ.

  5) API შეცდომებს, რომლებსაც wrapper უშვებს, უხერხულად უნდა დამუშავდეს, მაგალითად, ასე (ექსპერიმენტული კოდის ნაწილი):

  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) საბოლოო ჯამში, Selenium + API გამოიყურება როგორც ყველაზე რაციონალური ვარიანტი.

• აუცილებელია მდგომარეობის შენახვა და სისტემის გადატვირთვა, მრავალი შეცდომის დამუშავება, მათ შორის საიტის არათანმიმდევრული ქცევა - და ეს შეცდომები საკმაოდ ძნელი წარმოსადგენია (თუ არ დაწერთ პარსერებს პროფესიონალურად, რა თქმა უნდა).

ამ ამოცანის პირობითი დროის შეფასება იქნება 3-5-ჯერ მეტი, ვიდრე Habr-დან მონაცემების შეგროვებისთვის. მიუხედავად იმისა, რომ Habr-ის შემთხვევაში ჩვენ ვიყენებთ ფრონტალურ მიდგომას HTML პარსინგით, ხოლო OK-ის შემთხვევაში შეგვიძლია ვიმუშაოთ API-ით კრიტიკულ ადგილებში.

დასკვნები

რამდენიც არ უნდა დაგჭირდეთ მონაცემთა დამუშავების მილსადენის მოცულობითი მოდულის „ადგილზე“ (ჩვენ ვგეგმავთ დღეს!) ვადების შეფასებას, შესრულების დროის შეფასება, თუნდაც ხარისხობრივად, ამოცანის პარამეტრების გაანალიზების გარეშე თითქმის შეუძლებელია.

ოდნავ უფრო ფილოსოფიური თვალსაზრისით, სწრაფი შეფასების სტრატეგიები კარგად მუშაობს საინჟინრო ამოცანებისთვის, მაგრამ პრობლემები, რომლებიც უფრო ექსპერიმენტული და, გარკვეული გაგებით, „კრეატიული“ და საძიებოა, ანუ ნაკლებად პროგნოზირებადია, აქვთ სირთულეები, როგორც მსგავსი თემების მაგალითებში. რომელიც აქ განვიხილეთ.

რა თქმა უნდა, მონაცემთა შეგროვება მხოლოდ მთავარი მაგალითია - ეს ჩვეულებრივ წარმოუდგენლად მარტივი და ტექნიკურად გაურთულებელი ამოცანაა და ეშმაკი ხშირად არის დეტალებში. და სწორედ ამ ამოცანზე შეგვიძლია ვაჩვენოთ შესაძლო ვარიანტების მთელი სპექტრი, თუ რა შეიძლება არასწორედ წარიმართოს და ზუსტად რამდენ ხანს შეიძლება დასჭირდეს სამუშაო.

თუ დავაკვირდებით დავალების მახასიათებლებს დამატებითი ექსპერიმენტების გარეშე, მაშინ Reddit და OK ჰგავს ერთმანეთს: არის API, პითონის შეფუთვა, მაგრამ არსებითად, განსხვავება უზარმაზარია. ამ პარამეტრებით თუ ვიმსჯელებთ, ჰაბრის პარსი უფრო რთულად გამოიყურება, ვიდრე OK - მაგრამ პრაქტიკაში ეს სრულიად საპირისპიროა და ეს არის ზუსტად ის, რის გარკვევაც შესაძლებელია მარტივი ექსპერიმენტების ჩატარებით პრობლემის პარამეტრების გასაანალიზებლად.

ჩემი გამოცდილებით, ყველაზე ეფექტური მიდგომა არის უხეშად შეაფასოთ დრო, რომელიც დაგჭირდებათ წინასწარი ანალიზისთვის და მარტივი პირველი ექსპერიმენტებისთვის, დოკუმენტაციის წაკითხვისთვის - ეს საშუალებას მოგცემთ ზუსტი შეფასება მისცეთ მთელი სამუშაოსთვის. პოპულარული სწრაფი მეთოდოლოგიის თვალსაზრისით, გთხოვთ, შექმნათ ბილეთი „დავალების პარამეტრების შეფასებისთვის“, რომლის საფუძველზეც შემიძლია შევაფასო, თუ რა შეიძლება გაკეთდეს „სპრინტის“ ფარგლებში და უფრო ზუსტი შეფასება მივცე თითოეულისთვის. დავალება.

აქედან გამომდინარე, ყველაზე ეფექტური არგუმენტი, როგორც ჩანს, არის ის, რომელიც აჩვენებს "არატექნიკურ" სპეციალისტს, თუ რამდენი დრო და რესურსი იქნება განსხვავებული იმ პარამეტრების მიხედვით, რომლებიც ჯერ კიდევ არ არის შეფასებული.

წყარო: www.habr.com