Mis võib Data Science'iga valesti minna? Andmete kogumine

Tänapäeval on olemas 100500 Data Science'i kursust ja on ammu teada, et enim raha saab teenida just Data Science'i kursustega (miks kaevata, kui saab labidaid müüa?). Nende kursuste peamine miinus on see, et need ei oma mitte midagi pistmist reaalse tööga: keegi ei anna teile katkematuid, töödeldud andmeid vajaliku formaadina. Ja kui te kursustega lõpetate ja hakkate lahendama tõelist probleemi, selguvad palju nüansse.

Seetõttu alustame märkmike seeriat "Mis võib Data Science'iga valesti minna", mis on põhinenud minu, minu sõprade ja kolleegide tegelikel juhtumitel. Vaatame reaalseid näiteid tüüpilistest Data Science'i ülesannetest: kuidas see tegelikult käib. Alustame täna andmete kogumise ülesandega.

Ja esimene asi, millele inimesed, kes hakkavad töötama reaalsete andmetega, takerduvad, on selle samade meie jaoks asjakohaste andmete kogumine. Selle artikli peamine sõnum:

Me alahindame süsteemselt aega, ressursse ja pingutusi andmete kogumiseks, puhastamiseks ja ettevalmistamiseks.

Ja kõige tähtsam, arutame, mida teha, et seda vältida.

Erinevate hinnangute kohaselt kulub andmete puhastamisele, töötlemisele, omaduste inseneerimisele jne 80-90% ajast, samas kui analüüsile vaid 10-20%, kuigi praktiliselt kogu õppeaine keskendub ainult analüüsile.

Vaatame, kuidas tüüpiline lihtne analüüs ülesanne käib kolmes variandis ja näeme, millised võivad olla "leebed asjaolud".

Ja näiteks vaatame taas sarnaseid andmete kogumise ülesande variatsioone ja võrreldes kogukondi:

1. Kahest Redditi subreddidist
2. Kahest Habra osast
3. Kahest Klassikaaslaste grupist

Teoreetiline lähenemine

Ava veebileht ja loe näiteid, kui on selge, pane paar tundi lugemiseks, paar tundi koodi näidetele ja tõrkeotsingule. Lisa paar tundi kogumisele. Lisa paar tundi varuks (korda kahel ja lisa N tundi).

Peamine punkt: ajahinnang põhineb oletustel ja arvamistel selle kohta, kui kaua see aega võtab.

Aja analüüsi alustamiseks on vajalik hinnata järgmisi parameetreid tingimuslikuks ülesandeks, nagu eespool kirjeldatud:

• Mis on andmete maht ja kui palju tuleb füüsiliselt koguda (*vt allpool*).
• Kui kaua võtab ühe salvestuse kogumine ja kui kaua tuleb oodata, enne kui saab koguda teise.
• Koodide kirjutamise kinnitamine, mis salvestab oleku ja alustab uuesti, kui (ja mitte kui) kõik kukub.
• Selgitada välja, kas meil on vaja autentimist ja hõlmata API-juurdepääsu saamise aega.
• Logige veateateid andmete keerukuse funktsioonina - hinnake konkreetse ülesande alusel: struktuur, mitu muundurit, mida ja kuidas ekstrakteerime.
• Hinnake võrgu vigu ja probleemid projekti ebatavalise käitumise tõttu.
• Hinnake, kas vajalikud funktsioonid on dokumentatsioonis olemas ja kui ei, siis kui palju ja milliseid lahendusi on vaja.

Oluline on see, et aja hindamiseks peate tegelikult kulutama aega ja vaeva «lahingu uurimiseks» - ainult siis on teie planeerimine adekvaatne. Seetõttu, kui teid surutakse ütlema «kui palju aega on vaja andmete kogumiseks» - leidke aega esialgseks analüüsiks ja argumenteerige, et aeg varieerub sõltuvalt ülesande tegelikest parameetritest.

Ja nüüd näitame konkreetseid näiteid, kus sellised parameetrid muudavad.

Oluline punkt: hindamine põhineb võtmetegurite analüüsil, mis mõjutavad töö mahtu ja keerukust.

Hindamine, mis põhineb oletustel - see on hea lähenemine, kui funktsionaalsed elemendid on piisavalt väikesed ja tegureid, mis võivad ülesande struktuuri olulisel määral mõjutada, ei ole liiga palju. Kuid paljude Data Science'i ülesannete puhul muutub selliseid tegureid äärmiselt palju ja selline lähenemine muutub ebapiisavaks.

Redditi kogukondade võrdlemine

Alustame kõige lihtsama juhtumiga (kuidas hiljem selgub). Üldiselt, kui olla täiesti aus, on meie ees praktiliselt ideaalne juhtum, kontrollime meie keerukuse kontrollnimekirja:

• On olemas korras, arusaadav ja dokumenteeritud API.
• E ääretult lihtne ja peamine, et token saadakse automaatselt.
• Jah python wrapper — palju näidiseid.
• Kogukond, mis tegeleb andmete analüüsi ja kogumisega Redditis (kuni YouTube'i videoteni, mis selgitavad, kuidas kasutada python wrapper'it) näiteks siin.
• Meie vajalikud meetodid tõenäoliselt eksisteerivad API-s. Veelgi enam, kood näeb välja kompaktne ja puhas, allpool on näide funktsioonist, mis kogub postituste kommentaare.

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

Võetud selle mugavuste utiliitide valik.

Kuigi meil on parim võimalik olukord, tuleb siiski arvesse võtta mitmeid olulisi tegureid reaalsest elust:

• API piirangud — oleme sunnitud andmeid partiide kaupa võtma (ootama päringute vahel jne).
• Kogumise aeg — põhjalikuks analüüsiks ja võrdlemiseks peab arvestama märkimisväärset aega, et ämblik saaks alajaotuse läbi vaadata.
• Pott peab töötama serveris — te ei saa seda lihtsalt sülearvutisse käivitada, seljakotti panna ja asju ajama minna. Seetõttu jooksutasin kõik VPS-is. Kasutades kupongi habrahabr10, saate säästa veel 10% hinnast.
• Mõnede andmete füüsiline kättesaamatus (need on nähtavad administraatoritele või liiga keerulised koguda) — seda tuleb arvesse võtta, mitte kõik andmed ei pruugi normaalse ajaga kergesti kätte saada.
• Võrgutöö vead: töötamine võrgus — see on piin.
• Need on elavad tõelised andmed — need ei ole kunagi puhtad.

Muidugi tuleb arvesse võtta näidatud nüansse arendusse. Konkreetne tundide/päevade arv sõltub arenduse kogemusest või sarnaste ülesannete täitmise kogemusest, kuid me näeme, et see ülesanne on rangelt inseneritehniline ega nõua täiendavaid pingutusi lahendamiseks — kõike saab väga hästi hinnata, üles kirjutada ja teha.

Habrasektsioonide võrdlemine

Liigume edasi huvitavama ja mittetriviaalsete juhudeni, võrreldes vooge ja/või Habrasektsioone.

Kontrollime meie keerukuse kontrollnimekirja — siin, et mõista iga punkti, tuleb veidi katsetada ülesande ja eksperimenteerida.

• Esmalt arvate, et API on olemas, aga seda ei ole. Jah, Habril on API, kuid see ei ole kasutajatele juurdepääsetav (võib-olla ei tööta isegi üldse).
• Siis hakkate lihtsalt html-i parseerima — "import requests", mis võib valesti minna?
• Ja kuidas tegelikult parseerida? Lihtsaim ja kõige sagedamini kasutatav lähenemine on ID-de kaupa iteratsioon, olgu öeldud, et see ei ole kõige tõhusam ja tuleb töödelda erinevaid juhtumeid — siin on näiteks tõeliste ID-de tihedus kõigi olemasolevate seas.

  
  Võetud selle artiklist.

• Toorand andmed, mis on HTML-i sisse mähitud üle võrgu, on tõeline peavalu. Näiteks, kui soovite koguda ja salvestada artikli ratingit: lõikate skoori HTML-ist välja ja otsustate selle edasise töötlemise jaoks numbrina salvestada. 

  1) int(score) viskab vea: kuna Habr's on miinus, nagu näiteks reas "–5" — see on lühike sidekriips, mitte miinuse märk (ootamatu, eks?), seega pidin mingil hetkel parseri ellu äratama sellise õudse fikseerimisega.

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

  Kuupäevade, plusside ja miinuste olemasolu võib üldse puududa (nagu me näeme üleval funktsioonis check_date ja selliseid juhtumeid on olnud).

  2) Escapetumatud erimärgid — need tulevad, peab olema valmis.

  3) Struktuur muutub sõltuvalt postituse tüübist.

  4) Vanad postitused võivad olla **veidra struktuuriga**.

• Sisuliselt tuleb veateate käsitlemine ja see, mis võib või ei pruugi juhtuda, läbi mõelda; ei saa kindlalt ennustada, mis läheb valesti ja milline struktuur veel on ning kus midagi võib laguneda — tuleb lihtsalt proovida ja arvestada parsinud veaolukordadega.
• Siis mõistate, et tuleb lõimida mitme protsessi, vastasel juhul kulub ühe protsessiga parsimiseks üle 30 tunni (see on puhtalt tööaja jälgimisega seotud üheprotsessilise parsingu aeg, mis magab ja ei satu allapoole mingeid banne). selle artiklis viis see mingil hetkel sellise skeemini:

Kokkuvõtteks keerukuse kontrollnimekiri:

• Töö võrgu ja HTML-i parseerimisega, ID-de kaupa iteratsioon ja läbimine.
• Dokumendid on heterogeense struktuuriga.
• Palju kohti, kus kood võib kergesti kokku kukkuda.
• On vajalik kirjutada || kood.
• Puuduvad vajalikud dokumendid, koodinäited ja/või kogukond.

Konditsionaalne ajahinnang selle ülesande jaoks on 3-5 korda suurem kui andmete kogumine Redditist.

Võrdlus klassikaaslaste gruppidega.

Liigume edasi huvitavamate tehniliste juhtumitega, mis on loetletud. Minu jaoks oli see huvitav just seetõttu, et esmapilgul näeb see välja piisavalt triviaalne, kuid see pole sugugi nii — niipea, kui te sellesse pulga torkate.

Alustame meie keerukuse kontrollnimekirjast ja märkige, et paljud neist osutub oluliselt keerulisemaks, kui nad alguses näivad:

• API on olemas, kuid selles puuduvad peaaegu täielikult vajalikud funktsioonid.
• Teatud funktsioonide jaoks tuleb ligipääsu küsida e-posti teel, see tähendab, et ligipääsu andmine ei ole kohene.
• See dokumentatsioon on kohutav (alustame sellest, et segunevad vene ja ingliskeelsed terminid, täiesti ebajärjekindlalt — mõnikord tuleb lihtsalt arvata, mida teilt kuskil soovitakse) ja veelgi enam, see ei sobi andmete saamiseks, näiteks vajaliku funktsiooni.
• Nõuab dokumentatsioonis seanssi, kuid tegelikkuses ei kasuta seda — ja puudub igasugune võimalus kõiki API režiimide nüansse mõista, välja arvatud klõpsamine ja lootmine, et midagi töötab.
• Puuduvad näidised ja kogukond, ainus tugikoht teabe kogumiseks on väike wrapper Pythonis (ilma paljude kasutusnäidisteta).
• Töötav variant tundub olevat Selenium, kuna paljud vajalikud andmed on lukustuse all.
  1) See tähendab, et autentimine toimub vale kasutaja kaudu (ja registreerimine käsitsi).

  2) Siiski, Seleniumi kasutamisel puuduvad garantiid korrektseks ja korduvaks tööks (seda vähemalt ok.ru puhul kindlasti).

  3) OК.ru leht sisaldab JavaScripti vigu ja käitub mõnikord kummaliselt ja ebajärjekindlalt.

  4) Tuleb tegeleda lehekülgede jagamisega, elementide laadimisega jne ...

  5) API vead, mis wrapper tagastab, tuleb võimalikult painlikult töödelda, näiteks nii (katkend eksperimentaalsest koodist):

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #mõistlik on jälgida juba töödeldud arutelusid
          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
  

  Minu lemmikviga oli:

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

  6) Lõppkokkuvõttes tundub variant Selenium + API olema kõige mõistlikum valik.

• On vajalik oleku säilitamine ja süsteemi taaskäivitamine, paljude vigade töötlemine, sealhulgas saidi ebajärjekindel käitumine — need vead on üsna keerulised ette kujutada (kui te peaksite professionaalselt kirjutama parsi, muidugi).

Selle ülesande ajakulu hinnang on 3-5 korda kõrgem kui andmete kogumine Habrist. Kuigi Habriga, kasutatakse mehaanilist lähenemist HTML-i päringutele, siis OК puhul saame kriitilistes kohtades töötada API-ga.

Järeldused

Kuidas te ei peaks hindama „kohapeal” (täna on ju planeerimine!) mahuka andmetöötlusprotsessi pipelaini, on täitmise aeg praktiliselt kunagi isegi kvaliteetselt hindamiseks võimalik, ilma ülesande parameetrite analüüsita.

Kui rääkida natuke filosoofilisemalt, siis agiilsed hindamistrateegiad sobivad hästi inseneriteemade jaoks, kuid katsetavates ja teatud mõttes „loomingulistes” ja uurimuslikes ülesannetes, st vähem ennustatavates, tekivad raskused, nagu näites, mida oleme siin käsitlenud.

Muidugi, andmete kogumine on lihtsalt erksaks illustratiivseks näiteks — tavaliselt tundub see ülesanne uskumatult lihtne ja tehniliselt keeruline ning just detailides peitub tihti kurat. Ja just selle ülesandega saame näidata kogu spektrit võimalike variantide kohta, mis võib valesti minna ja kui kaua töö täpselt venida võib.

Kui pilk visata ülesande omadustele ilma täiendavate katseteta, siis Reddit ja OK paistavad sarnased: on API, Python wrapper, kuid sisuliselt on erinevus tohutu. Kui hinnata nende parameetrite põhjal, siis Hubberi kraapimine tundub keerulisem kui OK — kuid praktikas on see hoopis vastupidi ja just seda saab selgeks teha, kui läbi viia lihtsad eksperimendid ülesande parameetrite analüüsimiseks.

Minu kogemuste kohaselt on kõige tõhusam lähenemine umbkaudne ajahindamine, mis on vajalik eelanalüüsi ja lihtsate esialgsete katsete, dokumentatsiooni lugemise jaoks — just need võimaldavad teil anda täpset hinnangut kogu töö jaoks. Populaarse agiilse metoodika mõistetena — palun avage mulle pilet „ülesande parameetrite hindamiseks”, mille põhjal saan anda hinnangu sellele, mida on võimalik teha „sprinti” raames, ja anda täpsema hinnangu iga ülesande kohta.

Seetõttu näib kõige tõhusam olevat argumendina näidata „mitte tehnilisele” spetsialistile, kui palju varieerub aeg ja ressursid vastavalt parameetritele, mida tuleb veel hinnata.

Allikas: habr.com