Hva kan gå galt med Data Science? Datainnsamling

I dag er det 100500 XNUMX Data Science-kurs og det har lenge vært kjent at mest penger i Data Science kan tjenes gjennom Data Science-kurs (hvorfor grave når man kan selge spader?). Den største ulempen med disse kursene er at de ikke har noe med ekte arbeid å gjøre: ingen vil gi deg rene, behandlede data i det nødvendige formatet. Og når du forlater kurset og begynner å løse et reelt problem, dukker det opp mange nyanser.

Derfor starter vi en serie notater "Hva kan gå galt med Data Science", basert på virkelige hendelser som skjedde med meg, mine kamerater og kolleger. Vi vil analysere typiske datavitenskapelige oppgaver ved å bruke virkelige eksempler: hvordan dette faktisk skjer. La oss starte i dag med datainnsamlingsoppgaven.

Og det første folk snubler over når de begynner å jobbe med ekte data, er faktisk å samle inn disse dataene som er mest relevante for oss. Hovedbudskapet i denne artikkelen:

Vi undervurderer systematisk tiden, ressursene og innsatsen som kreves for å samle inn, rense og forberede data.

Og viktigst av alt, vi vil diskutere hva vi skal gjøre for å forhindre dette.

I følge ulike estimater tar rengjøring, transformasjon, databehandling, funksjonsteknikk osv. 80-90% av tiden, og analyse 10-20%, mens nesten alt undervisningsmateriell fokuserer utelukkende på analyse.

La oss se på et enkelt analytisk problem i tre versjoner som et typisk eksempel og se hva "skjerpende omstendigheter" er.

Og som et eksempel, igjen, vil vi vurdere lignende varianter av oppgaven med å samle inn data og sammenligne fellesskap for:

1. To Reddit-subreddits
2. To deler av Habr
3. To grupper av Odnoklassniki

Betinget tilnærming i teorien

Åpne nettstedet og les eksemplene, hvis det er tydelig, sett av noen timer til lesing, noen timer til koden ved å bruke eksemplene og feilsøking. Legg til noen timer for innsamling. Kast inn noen timer i reserve (gang med to og legg til N timer).

Nøkkelpunkt: Tidsestimater er basert på antakelser og gjetting om hvor lang tid det vil ta.

Det er nødvendig å starte tidsanalysen ved å estimere følgende parametere for det betingede problemet beskrevet ovenfor:

• Hva er størrelsen på dataene og hvor mye av dem som må samles inn fysisk (*se nedenfor*).
• Hva er hentetiden for den ene posten og hvor lenge må du vente før du kan hente den andre?
• Vurder å skrive kode som lagrer tilstanden og starter en omstart når (ikke hvis) alt feiler.
• Finn ut om vi trenger autorisasjon og angi tidspunktet for å få tilgang via API.
• Angi antall feil som en funksjon av datakompleksitet - vurder for en spesifikk oppgave: struktur, hvor mange transformasjoner, hva og hvordan du skal trekke ut.
• Rett opp nettverksfeil og problemer med ikke-standard prosjektatferd.
• Vurder om de nødvendige funksjonene er i dokumentasjonen, og hvis ikke, hvordan og hvor mye som trengs for en løsning.

Det viktigste er at for å anslå tid - du må faktisk bruke tid og krefter på "rekognosering i kraft" - først da vil planleggingen din være tilstrekkelig. Derfor, uansett hvor mye du blir presset til å si "hvor lang tid tar det å samle inn data" - kjøp deg litt tid for en foreløpig analyse og argumenter med hvor mye tiden vil variere avhengig av de virkelige parameterne for problemet.

Og nå vil vi demonstrere spesifikke eksempler der slike parametere vil endre seg.

Nøkkelpunkt: Estimatet er basert på en analyse av nøkkelfaktorer som påvirker omfanget og kompleksiteten til arbeidet.

Gjetningsbasert estimering er en god tilnærming når de funksjonelle elementene er små nok og det ikke er mange faktorer som i vesentlig grad kan påvirke utformingen av problemet. Men i tilfellet med en rekke Data Science-problemer, blir slike faktorer ekstremt mange og en slik tilnærming blir utilstrekkelig.

Sammenligning av Reddit-samfunn

La oss starte med det enkleste tilfellet (som det viser seg senere). Generelt, for å være helt ærlig, har vi en nesten ideell sak, la oss sjekke kompleksitetssjekklisten vår:

• Det er et ryddig, oversiktlig og dokumentert API.
• Det er ekstremt enkelt og viktigst av alt, et token oppnås automatisk.
• Det er pytonomslag - med mange eksempler.
• Et fellesskap som analyserer og samler inn data på reddit (selv til YouTube-videoer som forklarer hvordan du bruker python wrapper) For eksempel.
• Metodene vi trenger finnes mest sannsynlig i API. Dessuten ser koden kompakt og ren ut, nedenfor er et eksempel på en funksjon som samler kommentarer på et innlegg.

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

Tatt fra dette et utvalg praktiske verktøy for innpakning.

Til tross for at dette er det beste tilfellet, er det fortsatt verdt å ta hensyn til en rekke viktige faktorer fra det virkelige liv:

• API-grenser - vi er tvunget til å ta data i batcher (dvale mellom forespørsler osv.).
• Innsamlingstid - for en fullstendig analyse og sammenligning, må du sette av betydelig tid bare for edderkoppen å gå gjennom subredditen.
• Boten må kjøres på en server – du kan ikke bare kjøre den på den bærbare datamaskinen, legge den i ryggsekken og gå i gang med virksomheten din. Så jeg kjørte alt på en VPS. Ved å bruke kampanjekoden habrahabr10 kan du spare ytterligere 10 % av kostnadene.
• Den fysiske utilgjengeligheten til enkelte data (de er synlige for administratorer eller er for vanskelige å samle inn) - dette må i prinsippet tas i betraktning, ikke alle data kan samles inn i tilstrekkelig tid.
• Nettverksfeil: Nettverk er en smerte.
• Dette er levende ekte data - det er aldri rent.

Selvfølgelig er det nødvendig å inkludere disse nyansene i utviklingen. Spesifikke timer/dager avhenger av utviklingserfaring eller erfaring med å jobbe med lignende oppgaver, men vi ser at her er oppgaven rent ingeniørmessig og krever ikke ytterligere kroppsbevegelser å løse - alt kan være veldig godt vurdert, planlagt og gjort.

Sammenligning av Habr-seksjoner

La oss gå videre til et mer interessant og ikke-trivielt tilfelle av å sammenligne tråder og/eller deler av Habr.

La oss sjekke kompleksitetssjekklisten vår - her, for å forstå hvert punkt, må du grave litt i selve oppgaven og eksperimentere.

• Først tror du det er et API, men det er det ikke. Ja, ja, Habr har et API, men det er bare ikke tilgjengelig for brukere (eller kanskje det ikke fungerer i det hele tatt).
• Så begynner du bare å analysere html - "importforespørsler", hva kan gå galt?
• Hvordan analysere likevel? Den enkleste og mest brukte tilnærmingen er å iterere over IDer, merk at det ikke er den mest effektive og vil måtte håndtere forskjellige saker - her er et eksempel på tettheten av ekte IDer blant alle eksisterende.

  
  Tatt fra dette artikkelen.

• Rådata pakket inn i HTML på toppen av nettet er en smerte. For eksempel vil du samle og lagre vurderingen av en artikkel: du rev ​​poengsummen ut av html-en og bestemte deg for å lagre den som et tall for videre behandling: 

  1) int(score) kaster en feil: siden på Habré er det et minus, som for eksempel på linjen "–5" - dette er en strek, ikke et minustegn (uventet, ikke sant?), så kl. på et tidspunkt måtte jeg vekke parseren til live med en så forferdelig løsning.

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

  Det er kanskje ingen dato, plusser og minuser i det hele tatt (som vi ser ovenfor i check_date-funksjonen, skjedde dette).

  2) Uunngåede spesialtegn - de kommer, du må være forberedt.

  3) Strukturen endres avhengig av type post.

  4) Gamle innlegg kan ha en **rar struktur**.

• I hovedsak vil feilhåndtering og hva som kan skje eller ikke skje må håndteres, og du kan ikke forutsi sikkert hva som vil gå galt og hvordan ellers strukturen kan være og hva som vil falle av hvor - du må bare prøve å ta hensyn feilene som parseren kaster.
• Da skjønner du at du må parse i flere tråder, ellers vil parsing i én ta 30+ timer (dette er rent utførelsestiden til en allerede fungerende entråds parser, som sover og ikke faller inn under noen forbud). I dette artikkel førte dette på et tidspunkt til et lignende opplegg:

Total sjekkliste etter kompleksitet:

• Arbeide med nettverket og html-parsing med iterasjon og søk etter ID.
• Dokumenter med heterogen struktur.
• Det er mange steder hvor koden lett kan falle.
• Det er nødvendig å skrive || kode.
• Nødvendig dokumentasjon, kodeeksempler og/eller fellesskap mangler.

Den estimerte tiden for denne oppgaven vil være 3-5 ganger høyere enn for å samle inn data fra Reddit.

Sammenligning av Odnoklassniki-grupper

La oss gå videre til den mest teknisk interessante saken beskrevet. For meg var det interessant nettopp fordi det ved første øyekast ser ganske trivielt ut, men det viser seg ikke å være sånn i det hele tatt - så snart du stikker en pinne i det.

La oss starte med vanskelighetssjekklisten vår og merke oss at mange av dem vil vise seg å være mye vanskeligere enn de ser ut til å begynne med:

• Det finnes en API, men den mangler nesten helt de nødvendige funksjonene.
• Til visse funksjoner må du be om tilgang via post, det vil si at tilgangen ikke gis øyeblikkelig.
• Det er fryktelig dokumentert (til å begynne med er russiske og engelske termer blandet sammen overalt, og helt inkonsekvent - noen ganger trenger du bare å gjette hva de vil ha fra deg et sted), og dessuten er ikke designet egnet for å innhente data, for eksempel , funksjonen vi trenger.
• Krever en økt i dokumentasjonen, men bruker den faktisk ikke – og det er ingen måte å forstå alle forviklingene i API-modusene annet enn å rote rundt og håpe at noe vil fungere.
• Det er ingen eksempler og ingen fellesskap det eneste støttepunktet for å samle informasjon er et lite wrapper i Python (uten mange eksempler på bruk).
• Selen ser ut til å være det mest brukbare alternativet, siden mange av de nødvendige dataene er låst.
  1) Det vil si at autorisasjon skjer gjennom en fiktiv bruker (og registrering for hånd).

  2) Men med Selenium er det ingen garantier for korrekt og repeterbart arbeid (i hvert fall i tilfelle ok.ru helt sikkert).

  3) Ok.ru-nettstedet inneholder JavaScript-feil og oppfører seg noen ganger rart og inkonsekvent.

  4) Du må gjøre paginering, laste inn elementer osv...

  5) API-feil som innpakningen gir, må håndteres vanskelig, for eksempel slik (et stykke eksperimentell kode):

  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
  

  Min favorittfeil var:

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

  6) Til syvende og sist ser Selenium + API ut som det mest rasjonelle alternativet.

• Det er nødvendig å lagre tilstanden og starte systemet på nytt, håndtere mange feil, inkludert inkonsekvent oppførsel på nettstedet - og disse feilene er ganske vanskelige å forestille seg (med mindre du skriver parsere profesjonelt, selvfølgelig).

Det betingede tidsestimatet for denne oppgaven vil være 3-5 ganger høyere enn for innsamling av data fra Habr. Til tross for at vi i tilfelle av Habr bruker en frontal tilnærming med HTML-parsing, og i tilfelle OK kan vi jobbe med API på kritiske steder.

Funn

Uansett hvor mye du er pålagt å estimere tidsfristene "på stedet" (vi planlegger i dag!) for en voluminøs databehandlingspipeline-modul, er utførelsestiden nesten aldri mulig å estimere selv kvalitativt uten å analysere oppgaveparametrene.

På et litt mer filosofisk notat fungerer smidige estimeringsstrategier godt for ingeniøroppgaver, men problemer som er mer eksperimentelle og på en måte "kreative" og utforskende, dvs. mindre forutsigbare, har vanskeligheter, som i eksemplene på lignende emner, som vi har diskutert her.

Datainnsamling er selvfølgelig bare et godt eksempel – det er vanligvis en utrolig enkel og teknisk ukomplisert oppgave, og djevelen sitter ofte i detaljene. Og det er nettopp på denne oppgaven vi kan vise hele spekteret av mulige alternativer for hva som kan gå galt og nøyaktig hvor lang tid arbeidet kan ta.

Hvis du ser på egenskapene til oppgaven uten ytterligere eksperimenter, ser Reddit og OK like ut: det er en API, en python-innpakning, men i hovedsak er forskjellen enorm. Etter disse parameterne å dømme ser Habrs pars mer komplisert ut enn OK – men i praksis er det helt motsatt, og det er nettopp dette man kan finne ut ved å utføre enkle eksperimenter for å analysere parameterne til problemet.

Etter min erfaring er den mest effektive tilnærmingen å grovt estimere tiden du trenger for selve den foreløpige analysen og enkle første eksperimenter, lese dokumentasjonen - disse vil tillate deg å gi et nøyaktig estimat for hele arbeidet. Når det gjelder den populære smidige metodikken, ber jeg deg lage en billett for "estimering av oppgaveparametere", på grunnlag av denne kan jeg gi en vurdering av hva som kan oppnås innenfor "sprinten" og gi et mer nøyaktig estimat for hver oppgave.

Derfor ser det mest effektive argumentet ut til å være et som vil vise en "ikke-teknisk" spesialist hvor mye tid og ressurser som vil variere avhengig av parametere som ennå ikke har blitt vurdert.

Kilde: www.habr.com