Што можа пайсці не так з Data Science? Збор дадзеных

Сёння існуе 100500 курсаў па Data Science і даўно вядома, што больш за ўсё грошай у Data Science можна зарабіць менавіта курсамі па Data Science (навошта капаць, калі можна прадаваць рыдлёўкі?). Асноўны мінус гэтых курсаў у тым, што яны не маюць нічога агульнага з рэальнай працай: ніхто не дасць вам чыстыя, апрацаваныя даныя ў патрэбным фармаце. І калі вы выходзіце з курсаў і пачынаеце вырашаць сапраўдную задачу – усплывае шмат нюансаў.

Таму мы пачынаем серыю нататак "Што можа пайсці не так з Data Science", заснаваных на рэальных падзеях якія здарыліся са мной, маімі таварышамі і калегамі. Будзем разбіраць на рэальных прыкладах тыповыя задачы па Data Science: як гэта насамрэч адбываецца. Пачнём сёння з задачы збору даных.

І першае аб чым спатыкаюцца людзі, пачаўшы працаваць з рэальнымі дадзенымі - гэта ўласна збор гэтых самых рэлевантных нам дадзеных. Ключавы пасыл гэтага артыкула:

Мы сістэматычна недаацэньваем час, рэсурсы і намаганні на збор, ачыстку і падрыхтоўку даных.

А галоўнае, абмяркуем, што рабіць, каб гэтага не дапусціць.

Па розных ацэнках, ачыстка, трансфармацыя, data processing, feature engineering і тд займаюць 80-90% часу, а аналіз 10-20%, у той час як практычна ўвесь навучальны матэрыял факусуюць выключна на аналізе.

Давайце разбяром як тыповы прыклад простую аналітычную задачу ў трох варыянтах і ўбачым, якімі бываюць «абцяжваючыя акалічнасці».

І для прыкладу зноў жа, мы разгледзім падобныя варыяцыі задачы збору дадзеных і параўнання супольнасцяў для:

1. Двух сабрэдытаў Reddit
2. Двух раздзелаў Хабра
3. Двух груп Аднакласнікаў

Умоўны падыход у тэорыі

Адкрыць сайт і пачытаць прыклады, калі зразумела, закласці некалькі гадзін на чытанне, некалькі гадзін на код па прыкладах і адладку. Дадаць некалькі гадзін на збор. Накінуць некалькі гадзін пра запас (памножыць на дзве і дадаць N гадзін).

Ключавы момант: часавая ацэнка заснавана на здагадках і здагадках аб тым, колькі гэта зойме часу.

Пачаць аналіз часу неабходна з адзнакі наступных параметраў для ўмоўнай задачы, апісанай вышэй:

• Які памер дадзеных і колькі яго трэба фізічна збіраць (*гл ніжэй*).
• Які час збору аднаго запісу і колькі трэба чакаць, перш чым можна сабраць другі.
• Закласці напісанне кода які захоўвае стан і пачаткоўца рэстарт, калі (а не калі) усё зваліцца.
• Разабрацца, ці патрэбная нам аўтарызацыя і закласці час атрымання доступу па API.
• Закласці колькасць памылак, як функцыю складанасці дадзеных - ацаніць па канкрэтнай задачы: структура, колькі пераўтварэнняў, што і як экстрактым.
• Закласці памылкі сеткі і праблемы з нестандартнымі паводзінамі праекту.
• Ацаніць, калі патрэбныя функцыі ў дакументацыі і калі не, то як і колькі трэба для a workaround.

Самае важнае, што для ацэнкі часу - вам фактычна неабходна выдаткаваць час і намаганні для "разведкі боем" - толькі тады ваша планаванне будзе адэкватным. Таму як бы вас не пушылі сказаць "а колькі часу трэба для збору дадзеных" - выбіце сабе часу на папярэдні аналіз і аргументуйце тым наколькі час будзе вар'іравацца ў залежнасці ад рэальных параметраў задачы.

І зараз мы прадэманструем канкрэтныя прыклады, дзе такія параметры і будуць мяняцца.

Ключавы момант: ацэнка заснавана на аналізе ключавых фактараў, якія ўплываюць на аб'ём і складанасць працы.

Ацэнка, заснаваная на здагадках – гэта добры падыход, калі функцыянальныя элементы дастаткова невялікія і не так шмат фактараў, якія могуць істотна паўплываць на структуру задачы. Але ў выпадку шэрагу задач Data Science такіх фактараў становіцца вельмі шмат і падобны падыход становіцца неадэкватным.

Параўнанне супольнасцяў Reddit

Пачнём з самага простага выпадку (як потым апынецца). Наогул, калі зусім сапраўды, перад намі практычна ідэальны выпадак, праверым наш чэкліст складанасці:

• Маецца акуратны, зразумелы і дакументаваны API.
• Вельмі проста і галоўнае аўтаматычна атрымліваецца токен.
• Ёсць абгортка python - з кучай прыкладаў.
• Супольнасць якая займаецца аналізам і зборам дадзеных на рэддзіце (аж да youtube ролікаў якія тлумачаць, як выкарыстоўваць python wrapper) вось напрыклад.
• Патрэбныя нам метады хутчэй за ўсё існуюць у 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, але яго няма. Так-так, у Хабра ёсць API, але толькі ён недаступны для карыстачоў (а можа і зусім не працуе).
• Потым проста пачынаеце парсіць html - "import requests", што можа пайсці не так?
• А як наогул парсіць? Самы просты і часта выкарыстоўваецца падыход - ітэраваць па ID, адзначым, што не самы эфектыўны і прыйдзецца апрацоўваць розныя выпадкі - вось для прыкладу шчыльнасць рэальных ID сярод усіх існуючых.

  
  Узята з гэтай артыкулы.

• Волкія дадзеныя, загорнутыя ў HTML па-над сеткай - гэта боль. Напрыклад, вы хочаце сабраць і захаваць рэйтынг артыкула: выдралі score з html і вырашылі захаваць яго як лік для далейшай апрацоўкі: 

  1) int(score) кідае памылку: бо на Хабры мінус, як, напрыклад у радку "–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+ гадзін (гэта чыста час выканання ўжо працоўнага аднаструменнага парсера, які спіць і не пападае ні пад якія баны). У гэтай артыкуле, гэта прывяло ў нейкі момант да падобнай схемы:

Разам чэкліст па складанасці:

• Праца з сеткай і парсам html з ітэрацыяй і пераборам па ID.
• Дакументы неаднароднай структуры.
• Шмат месцаў, дзе код можа лёгка ўпасці.
• Неабходна пісаць || код.
• Адсутнічае патрэбная дакументацыя, прыклады кода і/або супольнасць.

Умоўная ацэнка часу для дадзенай задачы будзе ў 3-5 разоў вышэй, чым для збору дадзеных з Рэдзіта.

Параўнанне груп Аднакласнікаў

Пяройдзем да самага тэхнічна цікавага выпадку з апісаных. Для мяне ён быў цікавы менавіта тым, што на першы погляд, ён выглядае дастаткова трывіяльным, але зусім такім не аказваецца - як толькі вы ткнеце ў яго палачкай.

Пачне з нашага чэкіста складанасці і адзначым, што многія з іх апынуцца куды складаней, чым выглядаюць спачатку:

• API ёсць, але ў ім амаль поўнасцю адсутнічаюць патрэбныя функцыі.
• Да вызначаных функцый трэба прасіць доступ па пошце, гэта значыць выдача доступу не імгненная.
• Ён жудасна дакументаваны (пачнем з таго, што ўсюды мяшаюцца рускія і ангельскія тэрміны, прычым абсалютна непаслядоўна - часам вам трэба проста адгадаць, што ад вас дзесьці жадаюць) і, больш за тое, не падыходзіць па дызайне для атрымання дадзеных, напрыклад, патрэбнай нам функцыі.
• Патрабуе сесіі ў дакументацыі, а на справе яе не выкарыстоўвае - і няма ніякага спосабу разабрацца ва ўсіх тонкасцях рэжымаў API, акрамя як тыкацца і спадзявацца, што нешта будзе працаваць.
• Адсутнічаюць прыклады і супольнасць, адзіны пункт апоры ў зборы інфармацыі - невялікі абгортка на пітоне (без вялікай колькасці прыкладаў выкарыстання).
• Найбольш працоўным варыянтаў выглядае Selenium, бо шматлікія патрэбныя дадзеныя пад замкам.
  1) Гэта значыць ідзе аўтарызацыя праз фіктыўнага карыстальніка (і рэгістрацыя ручкамі).

  2) Аднак c Selenium ніякіх гарантый па карэктнай і паўтаранай працы (па меншай у выпадку з ok.ru сапраўды).

  3) Сайт Ок.ру змяшчае памылкі 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 разоў вышэй, чым для збору дадзеных з Хабра. Нягледзячы на ​​тое, што ў выпадку з Хабрам мы выкарыстоўваем лабавы падыход з парсам HTML, а ў выпадку з ОК мы можам у крытычных месцах працаваць з API.

Высновы

Як бы з вас не патрабавалі адзнаку тэрмінаў "на месцы" (у нас жа сёння планаванне!) аб'ёмнага модуля пайплана апрацоўкі дадзеных, час выканання практычна ніколі немагчыма ацаніць нават якасна без аналізу параметраў задачы.

Калі казаць крыху больш па-філасофску, то стратэгіі ацэнкі ў agile нядрэнна падыходзяць для інжынерных задач, але з задачамі больш эксперыментальнымі і, у некаторым сэнсе, «творчымі» і даследчымі, г.зн., менш прадказальнымі, узнікаюць цяжкасці, як у прыкладах падобных тэм , што мы разабралі тут.

Вядома, збор дадзеных з'яўляецца проста яркім ілюстрацыйным прыкладам - ​​звычайна гэта задача здаецца неверагодна простай і тэхнічна нескладанай, і менавіта ў дэталях тут часцей за ўсё і тоіцца д'ябал. І менавіта на гэтай задачы атрымоўваецца паказаць увесь спектр магчымых варыянтаў таго, што можа пайсці не так і наколькі менавіта можа зацягнуцца праца.

Калі прабегчыся краем вока па характарыстыках задачы без дадатковых эксперыментаў, то Reddit і ОК выглядаюць падобна: ёсць API, python wrapper, але ў сутнасці, розніца велізарная. Калі меркаваць па гэтых параметрах, то парс Хабра выглядае складаней, чым ОК - а на практыцы гэта зусім наадварот і менавіта гэта можна высветліць, правёўшы простыя эксперыменты па аналізе параметраў задачы.

Па маім досведзе найболей эфектыўным падыходам з'яўляецца прыкладная адзнака часу, якая вам запатрабуецца на сам папярэдні аналіз і простыя першыя эксперыменты, чытанне дакументацыі - яны вось і дазволяць вам даць дакладную адзнаку для ўсёй працы. У тэрмінах папулярнай метадалогіі agile – я прашу завесці мне тыкет пад "адзнаку параметраў задачы", на аснове якога я магу даць адзнаку таго, што магчыма выканаць у рамках "спрынту" і даць больш дакладную адзнаку па кожнай задачы.

Таму найбольш эфектыўным, здаецца аргумент, які б паказаў "нетэхнічнаму" спецыялісту, як моцна будзе вар'іравацца час і рэсурсы ў залежнасці ад параметраў, якія яшчэ трэба ацаніць.

Крыніца: habr.com