Hvað getur farið úrskeiðis við Data Science? Gagnasafn

Í dag eru 100500 gagnafræðinámskeið og það hefur lengi verið vitað að mesta peningana í gagnafræði er hægt að afla með gagnafræðinámskeiðum (af hverju að grafa þegar hægt er að selja skóflur?). Helsti ókosturinn við þessi námskeið er að þau hafa ekkert með raunverulega vinnu að gera: enginn mun gefa þér hrein, unnin gögn á tilskildu sniði. Og þegar þú yfirgefur námskeiðið og byrjar að leysa raunverulegt vandamál koma mörg blæbrigði í ljós.

Þess vegna erum við að hefja röð athugasemda „Hvað getur farið úrskeiðis við Data Science“, byggðar á raunverulegum atburðum sem áttu sér stað fyrir mig, félaga mína og samstarfsfélaga. Við munum greina dæmigerð gagnafræðiverkefni með því að nota raunveruleg dæmi: hvernig þetta gerist í raun og veru. Byrjum í dag á gagnaöflunarverkefninu.

Og það fyrsta sem fólk rekst á þegar það byrjar að vinna með raunveruleg gögn er í raun að safna þessum gögnum sem skipta okkur mestu máli. Lykilboðskapur þessarar greinar:

Við vanmetum kerfisbundið þann tíma, fjármagn og fyrirhöfn sem þarf til að safna, hreinsa og undirbúa gögn.

Og síðast en ekki síst, við munum ræða hvað á að gera til að koma í veg fyrir þetta.

Samkvæmt ýmsum áætlunum tekur hreinsun, umbreyting, gagnavinnsla, eiginleikatækni o.fl. 80-90% af tímanum og greining 10-20% á meðan nánast allt fræðsluefni beinist eingöngu að greiningu.

Skoðum einfalt greiningarvandamál í þremur útgáfum sem dæmigerð dæmi og sjáum hvað „versnandi aðstæður“ eru.

Og sem dæmi, aftur, munum við íhuga svipuð afbrigði af því verkefni að safna gögnum og bera saman samfélög fyrir:

1. Tvær Reddit subreddits
2. Tveir hlutar Habr
3. Tveir hópar af Odnoklassniki

Skilyrt nálgun í orði

Opnaðu síðuna og lestu dæmin, ef það er skýrt skaltu taka nokkrar klukkustundir til hliðar til að lesa, nokkrar klukkustundir fyrir kóðann með því að nota dæmin og villuleit. Bættu við nokkrum klukkustundum fyrir söfnun. Henda í nokkrar klukkustundir í varasjóð (margfaldaðu með tveimur og bættu við N klukkustundum).

Lykilatriði: Tímaáætlanir eru byggðar á forsendum og getgátum um hversu langan tíma það mun taka.

Nauðsynlegt er að hefja tímagreininguna með því að áætla eftirfarandi færibreytur fyrir skilyrta vandamálið sem lýst er hér að ofan:

• Hver er stærð gagna og hversu miklu af þeim þarf að safna líkamlega (*sjá hér að neðan*).
• Hver er söfnunartíminn fyrir eina plötu og hversu lengi þarf að bíða áður en hægt er að safna þeirri seinni?
• Íhugaðu að skrifa kóða sem vistar ástandið og byrjar endurræsingu þegar (ekki ef) allt mistekst.
• Finndu út hvort við þurfum heimild og stilltu tímann til að fá aðgang í gegnum API.
• Stilltu fjölda villna sem fall af flækjustig gagna - metið fyrir tiltekið verkefni: uppbyggingu, hversu margar umbreytingar, hvað og hvernig á að draga út.
• Lagaðu netvillur og vandamál með óhefðbundna verkefnahegðun.
• Metið hvort nauðsynlegar aðgerðir séu í skjölunum og ef ekki, þá hvernig og hversu mikið þarf til lausnar.

Það mikilvægasta er að til að áætla tíma - þú þarft í raun að eyða tíma og fyrirhöfn í "könnun í gildi" - aðeins þá verður skipulagning þín fullnægjandi. Þess vegna, sama hversu mikið þú ert ýtt til að segja "hversu langan tíma tekur það að safna gögnum" - keyptu þér smá tíma fyrir bráðabirgðagreiningu og rökstuddu hversu mikið tíminn mun vera mismunandi eftir raunverulegum breytum vandamálsins.

Og nú munum við sýna fram á sérstök dæmi þar sem slíkar breytur munu breytast.

Lykilatriði: Matið byggir á greiningu á lykilþáttum sem hafa áhrif á umfang og flókið starf.

Ágiskunarmiðað mat er góð nálgun þegar virkniþættirnir eru nógu litlir og það eru ekki margir þættir sem geta haft veruleg áhrif á hönnun vandamálsins. En þegar um er að ræða fjölda gagnavísindavandamála verða slíkir þættir mjög margir og slík nálgun verður ófullnægjandi.

Samanburður á Reddit samfélögum

Við skulum byrja á einfaldasta málinu (eins og það kemur í ljós síðar). Almennt séð, til að vera alveg heiðarlegur, höfum við næstum tilvalið mál, við skulum athuga flókið gátlistann okkar:

• Það er snyrtilegur, skýr og skjalfestur API.
• Það er ákaflega einfalt og síðast en ekki síst, auðkenni fæst sjálfkrafa.
• Það er python umbúðir - með fullt af dæmum.
• Samfélag sem greinir og safnar gögnum á reddit (jafnvel á YouTube myndbönd sem útskýra hvernig á að nota python umbúðir) Til dæmis.
• Aðferðirnar sem við þurfum líklegast eru til í API. Þar að auki lítur kóðinn út fyrir að vera nettur og hreinn, hér að neðan er dæmi um aðgerð sem safnar athugasemdum við færslu.

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()

Tekið frá þetta úrval af þægilegum tólum til að pakka inn.

Þrátt fyrir þá staðreynd að þetta er besta tilfellið er samt þess virði að taka tillit til fjölda mikilvægra þátta frá raunveruleikanum:

• API takmörk - við neyðumst til að taka gögn í lotum (sofa á milli beiðna osfrv.).
• Söfnunartími - til að fá fullkomna greiningu og samanburð, verður þú að taka verulegan tíma til hliðar bara fyrir köngulóna til að ganga í gegnum subreddit.
• Botninn verður að keyra á netþjóni - þú getur ekki bara keyrt hann á fartölvunni þinni, sett hann í bakpokann þinn og haldið áfram að vinna. Svo ég keyrði allt á VPS. Með því að nota kynningarkóðann habrahabr10 geturðu sparað 10% til viðbótar af kostnaðinum.
• Líkamlegt óaðgengi sumra gagna (þau eru sýnileg stjórnendum eða of erfitt er að safna) - þetta verður að taka með í reikninginn; í grundvallaratriðum er ekki hægt að safna öllum gögnum í hæfilegum tíma.
• Netvillur: Netkerfi er sársauki.
• Þetta eru lifandi raunveruleg gögn - þau eru aldrei hrein.

Auðvitað er nauðsynlegt að taka þessi blæbrigði inn í þróunina. Sérstakir tímar/dagar eru háðir þróunarreynslu eða reynslu af því að vinna að svipuðum verkefnum, hins vegar sjáum við að hér er verkefnið eingöngu verkfræðilegt og krefst ekki frekari líkamshreyfinga til að leysa - allt er hægt að meta, skipuleggja og gera mjög vel.

Samanburður á Habr köflum

Við skulum halda áfram að áhugaverðara og ekki léttvægara dæmi um að bera saman þræði og/eða hluta af Habr.

Við skulum athuga flókið gátlistann okkar - hér, til að skilja hvert atriði, verður þú að grafa aðeins ofan í verkefnið sjálft og gera tilraunir.

• Í fyrstu heldurðu að það sé API, en það er það ekki. Já, já, Habr er með API, en það er bara ekki aðgengilegt notendum (eða kannski virkar það alls ekki).
• Þá byrjarðu bara að þátta html - "innflutningsbeiðnir", hvað gæti farið úrskeiðis?
• Hvernig á að flokka samt? Einfaldasta og oftast notuð aðferðin er að endurtaka yfir auðkenni, athugaðu að það er ekki það skilvirkasta og mun þurfa að takast á við mismunandi tilvik - hér er dæmi um þéttleika raunverulegra auðkenna meðal allra þeirra sem fyrir eru.

  
  Tekið frá þetta greinar.

• Hrá gögn vafin inn í HTML ofan á vefinn er sársauki. Til dæmis, þú vilt safna og vista einkunn greinar: þú reifaðir stigið úr HTML og ákvaðst að vista það sem númer til frekari vinnslu: 

  1) int(score) kastar villu: þar sem á Habré er mínus, eins og til dæmis í línunni “–5” - þetta er en strik, ekki mínusmerki (óvænt, ekki satt?), svo kl. einhvern tíma þurfti ég að vekja parserinn til lífsins með svona hræðilegri lagfæringu.

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

  Það kann að vera engin dagsetning, plús- og mínusar yfirleitt (eins og við sjáum hér að ofan í check_date aðgerðinni, þetta gerðist).

  2) Ósloppnir sérstafir - þeir munu koma, þú þarft að vera tilbúinn.

  3) Uppbyggingin breytist eftir tegund pósts.

  4) Gamlir póstar geta verið með **furðulega uppbyggingu**.

• Í meginatriðum þarf að meðhöndla villumeðhöndlun og það sem gæti gerst eða gæti ekki gerst og þú getur ekki sagt fyrir um með vissu hvað mun fara úrskeiðis og hvernig annað uppbyggingin gæti verið og hvað mun falla af hvar - þú verður bara að reyna að taka tillit til villurnar sem þátttakandinn kastar.
• Þá áttarðu þig á því að þú þarft að parsa í nokkra þræði, annars tekur þáttun í einum 30+ klukkustundir (þetta er eingöngu keyrslutími einsþræðis parser sem er þegar í gangi, sem sefur og fellur ekki undir nein bann). IN þetta grein, leiddi þetta á einhverjum tímapunkti til svipaðs kerfis:

Heildargátlisti eftir flækjum:

• Vinna með netið og HTML þáttun með endurtekningu og leit eftir auðkenni.
• Skjöl um ólíka uppbyggingu.
• Það eru margir staðir þar sem kóðinn getur auðveldlega fallið.
• Það er nauðsynlegt að skrifa || kóða.
• Nauðsynleg skjöl, kóðadæmi og/eða samfélag vantar.

Áætlaður tími fyrir þetta verkefni verður 3-5 sinnum lengri en fyrir gagnasöfnun frá Reddit.

Samanburður á Odnoklassniki hópum

Við skulum halda áfram að tæknilega áhugaverðasta málinu sem lýst er. Fyrir mig var það áhugavert einmitt vegna þess að við fyrstu sýn lítur það frekar léttvægt út, en það reynist alls ekki vera þannig - um leið og þú stingur priki í það.

Við skulum byrja á gátlistanum okkar um erfiðleika og athuga að margir þeirra munu reynast mun erfiðari en þeir líta út í fyrstu:

• Það er API, en það skortir næstum alveg nauðsynlegar aðgerðir.
• Að tilteknum aðgerðum þarftu að biðja um aðgang með pósti, það er að veita aðgang er ekki samstundis.
• Það er hræðilega skjalfest (til að byrja með blandast rússneskum og enskum hugtökum alls staðar saman, og algjörlega ósamræmi - stundum þarftu bara að giska á hvað þeir vilja frá þér einhvers staðar) og þar að auki hentar hönnunin ekki til að afla gagna, td. , aðgerðina sem við þurfum.
• Krefst lotu í skjölunum, en notar það í raun og veru - og það er engin leið til að skilja allar ranghala API stillingarnar nema að pæla í og ​​vona að eitthvað virki.
• Það eru engin dæmi og ekkert samfélag; eini stuðningurinn við upplýsingasöfnun er lítill umbúðir í Python (án margra dæma um notkun).
• Selen virðist vera hagkvæmasti kosturinn þar sem mörg nauðsynleg gögn eru læst.
  1) Þ.e. heimild fer fram í gegnum gervi notanda (og skráning í höndunum).

  2) Hins vegar, með Selen, eru engar tryggingar fyrir réttri og endurtekinni vinnu (að minnsta kosti ef um er að ræða ok.ru fyrir víst).

  3) Ok.ru vefsíðan inniheldur JavaScript villur og hegðar sér stundum undarlega og ósamræmi.

  4) Þú þarft að gera síðuskipun, hlaða þætti osfrv...

  5) API villur sem umbúðirnar gefa upp verður að meðhöndla óþægilega, til dæmis, svona (stykki af tilraunakóða):

  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
  

  Uppáhalds mistökin mín voru:

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

  6) Að lokum lítur Selen + API út eins og skynsamlegasti kosturinn.

• Nauðsynlegt er að vista ástandið og endurræsa kerfið, meðhöndla margar villur, þar á meðal ósamkvæma hegðun síðunnar - og þessar villur er frekar erfitt að ímynda sér (nema þú skrifar þátttakendur faglega, auðvitað).

Skilyrt tímaáætlun fyrir þetta verkefni verður 3-5 sinnum hærri en fyrir gagnasöfnun frá Habr. Þrátt fyrir þá staðreynd að í tilviki Habr notum við framhliða nálgun með HTML þáttun, og í tilfelli OK getum við unnið með API á mikilvægum stöðum.

Niðurstöður

Sama hversu mikið þú þarft til að áætla fresti "á staðnum" (við erum að skipuleggja í dag!) fyrir umfangsmikla gagnavinnslu leiðslueiningu, framkvæmdartímann er nánast aldrei hægt að áætla, jafnvel eigindlega án þess að greina verkfærin.

Á örlítið heimspekilegri nótum, liprar matsaðferðir virka vel fyrir verkfræðileg verkefni, en vandamál sem eru meira tilraunaverkefni og í vissum skilningi „skapandi“ og rannsakandi, þ.e. minna fyrirsjáanleg, eiga í erfiðleikum, eins og í dæmum um svipað efni, sem við höfum rætt hér.

Auðvitað er gagnasöfnun bara gott dæmi - þetta er yfirleitt ótrúlega einfalt og tæknilega flókið verkefni og djöfullinn er oft í smáatriðunum. Og það er einmitt í þessu verkefni sem við getum sýnt alla möguleika á því hvað getur farið úrskeiðis og nákvæmlega hversu langan tíma verkið getur tekið.

Ef þú lítur á eiginleika verkefnisins án frekari tilrauna, þá líta Reddit og OK svipað út: það er API, python umbúðir, en í raun er munurinn gríðarlegur. Miðað við þessar færibreytur lítur pars Habr út fyrir að vera flóknari en í lagi - en í reynd er það alveg hið gagnstæða, og það er einmitt það sem hægt er að finna út með því að gera einfaldar tilraunir til að greina færibreytur vandamálsins.

Mín reynsla er sú að árangursríkasta aðferðin er að áætla gróflega þann tíma sem þú þarft fyrir frumgreininguna sjálfa og einfaldar fyrstu tilraunir, að lesa skjölin - þetta gerir þér kleift að gefa nákvæma áætlun fyrir allt verkið. Hvað varðar hina vinsælu lipra aðferðafræði, bið ég þig um að búa til miða til að „áætla verkfærisbreytur“, á grundvelli þess get ég gefið mat á því sem hægt er að ná í „sprettinum“ og gefa nákvæmara mat fyrir hvern. verkefni.

Þess vegna virðist áhrifaríkasta röksemdin vera sú sem myndi sýna „ótæknilegum“ sérfræðingi hversu mikill tími og fjármagn er mismunandi eftir breytum sem enn á eftir að meta.

Heimild: www.habr.com