Што може да тргне наопаку со Data Science? Собирање на податоци

Денес има 100500 курсеви за Data Science и одамна е познато дека најмногу пари во Data Science може да се заработи преку курсевите за Data Science (зошто да се копа кога може да се продаваат лопати?). Главниот недостаток на овие курсеви е што тие немаат никаква врска со вистинската работа: никој нема да ви даде чисти, обработени податоци во бараниот формат. И кога ќе го напуштите курсот и ќе започнете да решавате вистински проблем, се појавуваат многу нијанси.

Затоа, започнуваме серија белешки „Што може да тргне наопаку со Data Science“, засновани на вистински настани што ми се случија мене, моите другари и колеги. Ќе ги анализираме типичните задачи на Data Science користејќи вистински примери: како тоа всушност се случува. Да почнеме денес со задачата за собирање податоци.

И првото нешто на што луѓето се сопнуваат кога почнуваат да работат со вистински податоци е всушност собирањето на овие податоци што се најрелевантни за нас. Клучната порака на овој напис:

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

И што е најважно, ќе разговараме што да правиме за да го спречиме ова.

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

Ајде да погледнеме едноставен аналитички проблем во три верзии како типичен пример и да видиме што се „отежнувачки околности“.

И како пример, повторно, ќе разгледаме слични варијации на задачата за собирање податоци и споредување на заедниците за:

1. Две подредити на Редит
2. Два дела од Хабр
3. Две групи на Однокласници

Условниот пристап во теорија

Отворете ја страницата и прочитајте ги примерите, ако е јасно, одвојте неколку часа за читање, неколку часа за кодот користејќи ги примерите и дебагирање. Додадете неколку часа за собирање. Фрлете неколку часа во резерва (помножете се со два и додадете N часа).

Клучна точка: Временските проценки се засноваат на претпоставки и нагаѓања за тоа колку долго ќе потрае.

Потребно е да се започне временската анализа со проценка на следните параметри за условниот проблем опишан погоре:

• Која е големината на податоците и колку од нив треба физички да се соберат (*види подолу*).
• Колку е времето за собирање на една плоча и колку долго треба да чекате пред да го соберете вториот?
• Размислете за пишување код кој ја зачувува состојбата и започнува рестартирање кога (не ако) сè не успее.
• Дознајте дали ни треба овластување и поставете го времето за добивање пристап преку API.
• Поставете го бројот на грешки како функција на сложеноста на податоците - проценете за одредена задача: структура, колку трансформации, што и како да се извлече.
• Поправете ги мрежните грешки и проблемите со нестандардното однесување на проектот.
• Проценете дали потребните функции се во документацијата и ако не, тогаш како и колку е потребно за заобиколување.

Најважно е дека за да се процени времето - всушност треба да потрошите време и труд на „извидување во сила“ - само тогаш вашето планирање ќе биде соодветно. Затоа, без разлика колку ќе ве туркаат да кажете „колку време е потребно за да се соберат податоци“ - купете си малку време за прелиминарна анализа и расправајте се за тоа колку времето ќе варира во зависност од вистинските параметри на проблемот.

И сега ќе покажеме конкретни примери каде таквите параметри ќе се променат.

Клучна точка: Проценката се заснова на анализа на клучните фактори кои влијаат на обемот и сложеноста на работата.

Проценката заснована на погодување е добар пристап кога функционалните елементи се доволно мали и нема многу фактори кои можат значително да влијаат на дизајнот на проблемот. Но, во случај на голем број проблеми на Data Science, таквите фактори стануваат исклучително многубројни и таквиот пристап станува несоодветен.

Споредба на заедниците на Редит

Да почнеме со наједноставниот случај (како што се испоставува подоцна). Во принцип, да бидеме целосно искрени, имаме речиси идеален случај, ајде да ја провериме нашата листа за проверка на сложеноста:

• Постои уредно, јасно и документирано 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 - „барања за увоз“, што може да тргне наопаку?
• Како да се анализира во секој случај? Наједноставниот и најчесто користен пристап е повторување преку ИД, имајте во предвид дека не е најефикасен и ќе мора да се справи со различни случаи - еве пример за густината на вистинските лични карти меѓу сите постоечки.

  
  Земено од ова статии.

• Необработените податоци завиткани во 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+ часа (ова е чисто време на извршување на веќе работен парсер со една нишка, кој спие и не потпаѓа под никакви забрани). ВО ова статија, ова доведе во одреден момент до слична шема:

Вкупна листа за проверка по сложеност:

• Работа со мрежата и html парсирање со повторување и пребарување по ID.
• Документи за хетерогена структура.
• Има многу места каде кодот лесно може да падне.
• Потребно е да се напише || код.
• Недостасува потребната документација, примери на код и/или заедница.

Проценетото време за оваа задача ќе биде 3-5 пати поголемо отколку за собирање податоци од Reddit.

Споредба на Однокласнички групи

Да преминеме на технички најинтересниот опишан случај. За мене тоа беше интересно токму затоа што на прв поглед изгледа прилично тривијално, но воопшто не испаѓа така - штом ѕиркаш со стап.

Да почнеме со нашата листа за проверка на тешкотии и да забележиме дека многу од нив ќе испаднат многу потешки отколку што изгледаат на почетокот:

• Постои 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 користиме фронтален пристап со парсирање на HTML, а во случај на ОК можеме да работиме со API на критични места.

Наоди

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

На малку пофилозофска нота, агилните стратегии за проценување работат добро за инженерски задачи, но проблемите кои се повеќе експериментални и, во извесна смисла, „креативни“ и истражувачки, т.е. помалку предвидливи, имаат тешкотии, како во примерите на слични теми . за што разговаравме овде.

Се разбира, собирањето податоци е само одличен пример - тоа е обично неверојатно едноставна и технички некомплицирана задача, а ѓаволот често е во деталите. И токму на оваа задача можеме да го прикажеме целиот опсег на можни опции за тоа што може да тргне наопаку и колку точно може да трае работата.

Ако погледнете во карактеристиките на задачата без дополнителни експерименти, тогаш Reddit и OK изгледаат слично: има API, обвивка за питон, но во суштина, разликата е огромна. Судејќи според овие параметри, парсот на Хабр изгледа покомплициран отколку во ред - но во пракса е сосема спротивно, а токму тоа може да се дознае со спроведување едноставни експерименти за анализа на параметрите на проблемот.

Според моето искуство, најефективниот пристап е грубо да се процени времето што ќе ви треба за самата прелиминарна анализа и едноставните први експерименти, читајќи ја документацијата - тие ќе ви овозможат да дадете точна проценка за целата работа. Во однос на популарната агилна методологија, ве замолувам да креирате билет за „проценка на параметрите на задачата“, врз основа на кој можам да дадам проценка за тоа што може да се постигне во рамките на „спринтот“ и да дадам попрецизна проценка за секој задача.

Затоа, се чини дека најефективниот аргумент е оној што ќе му покаже на „нетехничкиот“ специјалист колку време и ресурси ќе варираат во зависност од параметрите што допрва треба да се проценат.

Извор: www.habr.com