Какво може да се обърка с Data Science? Събиране на данни

Днес има 100500 XNUMX курса по Data Science и отдавна е известно, че най-много пари в Data Science могат да бъдат спечелени чрез курсове по Data Science (защо да копаете, когато можете да продавате лопати?). Основният недостатък на тези курсове е, че нямат нищо общо с реалната работа: никой няма да ви даде чисти, обработени данни в необходимия формат. И когато излезете от курса и започнете да решавате реален проблем, се появяват много нюанси.

Затова започваме поредица от бележки „Какво може да се обърка с Data Science“, базирани на реални събития, които се случиха с мен, моите другари и колеги. Ще анализираме типичните задачи на Data Science, като използваме реални примери: как това всъщност се случва. Нека започнем днес със задачата за събиране на данни.

И първото нещо, в което хората се спъват, когато започнат да работят с реални данни, всъщност е събирането на тези данни, които са най-подходящи за нас. Основното послание на тази статия:

Ние систематично подценяваме времето, ресурсите и усилията, необходими за събиране, почистване и подготовка на данни.

И най-важното, ще обсъдим какво да направим, за да предотвратим това.

Според различни оценки почистването, трансформацията, обработката на данни, инженерингът на функции и т.н. отнемат 80-90% от времето, а анализът 10-20%, докато почти всички учебни материали се фокусират изключително върху анализа.

Нека да разгледаме един прост аналитичен проблем в три версии като типичен пример и да видим какво представляват „утежняващите обстоятелства“.

И като пример, отново ще разгледаме подобни варианти на задачата за събиране на данни и сравняване на общности за:

1. Две подредити в Reddit
2. Два раздела на Habr
3. Две групи Odnoklassniki

Условен подход в теорията

Отворете сайта и прочетете примерите, ако е ясно, отделете няколко часа за четене, няколко часа за кода с помощта на примерите и отстраняване на грешки. Добавете няколко часа за събиране. Добавете няколко часа в резерв (умножете по две и добавете N часа).

Ключов момент: Прогнозите за време се основават на предположения и догадки за това колко време ще отнеме.

Необходимо е да започнем анализа на времето, като оценим следните параметри за условния проблем, описан по-горе:

• Какъв е размерът на данните и колко от тях трябва да бъдат физически събрани (*вижте по-долу*).
• Какво е времето за събиране на един запис и колко време трябва да чакате, преди да можете да вземете втория?
• Помислете за писане на код, който запазва състоянието и започва рестартиране, когато (не ако) всичко се провали.
• Разберете дали имаме нужда от оторизация и задайте времето за получаване на достъп чрез API.
• Задайте броя на грешките като функция на сложността на данните - оценете за конкретна задача: структура, колко трансформации, какво и как да извлечете.
• Коригирайте мрежови грешки и проблеми с нестандартно поведение на проекта.
• Оценете дали необходимите функции са в документацията и ако не, тогава как и колко са необходими за заобиколно решение.

Най-важното е, че за да прецените времето - всъщност трябва да отделите време и усилия за "разузнаване в сила" - само тогава планирането ви ще бъде адекватно. Ето защо, колкото и да ви карат да казвате „колко време отнема събирането на данни“ – отделете си малко време за предварителен анализ и аргументирайте колко ще варира времето в зависимост от реалните параметри на проблема.

И сега ще демонстрираме конкретни примери, при които такива параметри ще се променят.

Ключова точка: Оценката се основава на анализ на ключови фактори, влияещи върху обхвата и сложността на работата.

Оценката на базата на предположения е добър подход, когато функционалните елементи са достатъчно малки и няма много фактори, които могат значително да повлияят на дизайна на проблема. Но в случай на редица проблеми на Data Science, такива фактори стават изключително много и такъв подход става неадекватен.

Сравнение на Reddit общности

Нека започнем с най-простия случай (както се оказва по-късно). Като цяло, за да бъдем напълно честни, имаме почти идеален случай, нека проверим нашия списък за сложност:

• Има чист, ясен и документиран API.
• Това е изключително просто и най-важното е, че токенът се получава автоматично.
• Има python обвивка - с много примери.
• Общност, която анализира и събира данни в reddit (дори до видеоклипове в YouTube, обясняващи как да използвате обвивката на 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 - ние сме принудени да вземаме данни на партиди (заспиване между заявките и т.н.).
• Време за събиране - за пълен анализ и сравнение ще трябва да отделите значително време само за паяка да премине през subreddit.
• Ботът трябва да работи на сървър – не можете просто да го стартирате на вашия лаптоп, да го поставите в раницата си и да се занимавате с бизнеса си. Така че пуснах всичко на VPS. Използвайки промоционалния код habrahabr10 можете да спестите още 10% от цената.
• Физическата недостъпност на някои данни (те са видими за администраторите или са твърде трудни за събиране) - това трябва да се има предвид, по принцип не всички данни могат да бъдат събрани навреме.
• Мрежови грешки: Работата в мрежа е болка.
• Това са живи реални данни - никога не са чисти.

Разбира се, е необходимо да се включат тези нюанси в разработката. Конкретните часове/дни зависят от опита в разработката или опита в работата по подобни задачи, но виждаме, че тук задачата е чисто инженерна и не изисква допълнителни движения на тялото за решаване - всичко може да бъде много добре оценено, планирано и изпълнено.

Сравнение на секциите на Habr

Нека да преминем към по-интересен и нетривиален случай на сравняване на теми и/или раздели на Habr.

Нека проверим нашия списък за сложност - тук, за да разберете всяка точка, ще трябва да се заровите малко в самата задача и да експериментирате.

• Първоначално си мислите, че има API, но няма. Да, да, Habr има API, но той просто не е достъпен за потребителите (или може би изобщо не работи).
• След това просто започвате да анализирате html - „заявки за импортиране“, какво може да се обърка?
• Как да анализирам все пак? Най-простият и най-често използван подход е итерация на идентификатори, имайте предвид, че той не е най-ефективният и ще трябва да обработва различни случаи - ето пример за плътността на реалните идентификатори сред всички съществуващи.

  
  Взето от това статия.

• Необработените данни, обвити в HTML върху мрежата, са болка. Например, искате да съберете и запазите оценката на статия: извадихте резултата от html и решихте да го запазите като число за по-нататъшна обработка: 

  1) int(score) хвърля грешка: тъй като на Habré има минус, като например в реда „–5“ - това е крайно тире, а не знак минус (неочаквано, нали?), така че при в някакъв момент трябваше да съживя синтактичния анализатор с такава ужасна корекция.

  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) При Selenium обаче няма гаранции за правилна и повторяема работа (поне в случая на 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) В крайна сметка Selenium + API изглежда като най-рационалната опция.

• Необходимо е да запазите състоянието и да рестартирате системата, да се справите с много грешки, включително непоследователно поведение на сайта - и тези грешки са доста трудни за представяне (освен ако не пишете професионално анализатори, разбира се).

Условната оценка на времето за тази задача ще бъде 3-5 пъти по-висока, отколкото за събиране на данни от Habr. Въпреки факта, че в случая на Habr използваме фронтален подход с HTML анализ, а в случая на OK можем да работим с API на критични места.

Данни

Колкото и да се изисква да оцените крайните срокове „на място“ (планираме днес!) на обемен тръбопроводен модул за обработка на данни, времето за изпълнение почти никога не е възможно да се оцени дори качествено, без да се анализират параметрите на задачата.

От малко по-философска гледна точка, стратегиите за гъвкаво оценяване работят добре за инженерни задачи, но проблеми, които са по-експериментални и, в известен смисъл, „творчески“ и проучвателни, т.е. по-малко предвидими, имат трудности, както в примерите за подобни теми, които сме обсъждали тук.

Разбира се, събирането на данни е само отличен пример - обикновено това е невероятно проста и технически неусложнена задача и дяволът често е в детайлите. И точно по тази задача можем да покажем цялата гама от възможни варианти какво може да се обърка и колко точно време може да отнеме работата.

Ако погледнете характеристиките на задачата без допълнителни експерименти, тогава Reddit и OK изглеждат сходни: има API, обвивка на питон, но по същество разликата е огромна. Съдейки по тези параметри, анализите на Habr изглеждат по-сложни от ОК - но на практика е точно обратното и точно това може да се установи чрез провеждане на прости експерименти за анализиране на параметрите на проблема.

Според моя опит най-ефективният подход е груба оценка на времето, което ще ви е необходимо за самия предварителен анализ и прости първи експерименти, четене на документацията - те ще ви позволят да дадете точна оценка за цялата работа. От гледна точка на популярната agile методология, моля ви да създадете билет за „оценка на параметрите на задачата“, на базата на който да дам оценка какво може да се постигне в рамките на „спринта“ и да дам по-точна оценка за всеки задача.

Следователно най-ефективният аргумент изглежда е този, който би показал на „нетехнически“ специалист колко време и ресурси ще варират в зависимост от параметрите, които тепърва ще бъдат оценени.

Източник: www.habr.com