Mikä Data Sciencessä voi mennä vikaan? Tiedonkeruu

Nykyään tietotieteen kursseja on 100500 XNUMX ja on jo pitkään tiedetty, että tietotieteessä voi ansaita eniten rahaa datatieteen kursseilla (miksi kaivaa, kun voi myydä lapioita?). Näiden kurssien suurin haittapuoli on, että niillä ei ole mitään tekemistä todellisen työn kanssa: kukaan ei anna sinulle puhdasta, käsiteltyä dataa vaaditussa muodossa. Ja kun poistut kurssilta ja alat ratkaista todellista ongelmaa, esiin tulee monia vivahteita.

Siksi aloitamme muistiinpanosarjan "Mitä datatieteessä voi mennä pieleen", joka perustuu todellisiin minulle, tovereilleni ja kollegoilleni tapahtuneisiin tapahtumiin. Analysoimme tyypillisiä Data Science -tehtäviä oikeilla esimerkeillä: kuinka tämä todella tapahtuu. Aloitetaan tänään tiedonkeruutehtävällä.

Ja ensimmäinen asia, johon ihmiset kompastuvat, kun he alkavat työskennellä todellisen datan kanssa, on itse asiassa kerätä meille tärkeimpiä tietoja. Tämän artikkelin avainviesti:

Aliarvioimme järjestelmällisesti tiedon keräämiseen, puhdistamiseen ja valmisteluun tarvittavan ajan, resursseja ja vaivaa.

Ja mikä tärkeintä, keskustelemme siitä, mitä tehdä tämän estämiseksi.

Eri arvioiden mukaan puhdistus, muuntaminen, tietojenkäsittely, ominaisuussuunnittelu jne. vievät 80-90 % ajasta ja analysointi 10-20 %, kun taas lähes kaikki oppimateriaali keskittyy yksinomaan analyysiin.

Tarkastellaan yksinkertaista analyyttistä ongelmaa kolmessa versiossa tyypillisenä esimerkkinä ja katsotaan, mitä "raskauttavat olosuhteet" ovat.

Ja esimerkkinä, tarkastelemme jälleen samanlaisia ​​muunnelmia tietojen keräämisen ja yhteisöjen vertailun tehtävästä:

1. Kaksi Reddit-aliredditiä
2. Kaksi osaa Habr
3. Kaksi Odnoklassnikin ryhmää

Ehdollinen lähestymistapa teoriassa

Avaa sivusto ja lue esimerkit, jos se on selkeä, varaa muutama tunti lukemiseen, muutama tunti koodille esimerkkien ja virheenkorjauksen avulla. Lisää muutama tunti keräilyyn. Laita muutama tunti varaan (kerro kahdella ja lisää N tuntia).

Keskeinen kohta: Aika-arviot perustuvat oletuksiin ja arvauksiin siitä, kuinka kauan se kestää.

Aika-analyysi on aloitettava arvioimalla seuraavat parametrit edellä kuvatulle ehdolliselle ongelmalle:

• Mikä on tietojen koko ja kuinka paljon niistä on fyysisesti kerättävä (*katso alla*).
• Mikä on yhden levyn keräilyaika ja kuinka kauan sinun on odotettava, ennen kuin voit kerätä toisen?
• Harkitse koodin kirjoittamista, joka tallentaa tilan ja käynnistää uudelleenkäynnistyksen, kun (ei jos) kaikki epäonnistuu.
• Selvitä, tarvitsemmeko valtuutuksen ja aseta aika API:n kautta pääsyyn.
• Aseta virheiden määrä tietojen monimutkaisuuden funktiona - arvioi tietylle tehtävälle: rakenne, kuinka monta muunnosa, mitä ja miten purkaa.
• Korjaa verkkovirheet ja epätyypilliseen projektitoimintaan liittyvät ongelmat.
• Arvioi, ovatko tarvittavat toiminnot dokumentaatiossa ja jos eivät, niin miten ja kuinka paljon tarvitaan kiertotapaa varten.

Tärkeintä on, että arvioidaksesi aikaa - sinun täytyy itse asiassa käyttää aikaa ja vaivaa "tiedusteluvoimassa" - vain silloin suunnitelmasi on riittävä. Siksi riippumatta siitä, kuinka paljon sinua pakotetaan sanomaan "kuinka kauan tiedon kerääminen kestää" - varaa itsellesi aikaa alustavaan analyysiin ja väittele, kuinka paljon aika vaihtelee ongelman todellisten parametrien mukaan.

Ja nyt esittelemme erityisiä esimerkkejä, joissa tällaiset parametrit muuttuvat.

Keskeinen kohta: Arvio perustuu työn laajuuteen ja monimutkaisuuteen vaikuttavien keskeisten tekijöiden analyysiin.

Arvauspohjainen estimointi on hyvä lähestymistapa, kun toiminnalliset elementit ovat riittävän pieniä ja ongelman suunnitteluun merkittävästi vaikuttavia tekijöitä ei ole paljon. Mutta useiden datatieteen ongelmien tapauksessa tällaisia ​​tekijöitä tulee erittäin lukuisiksi ja tällaisesta lähestymistavasta tulee riittämätön.

Reddit-yhteisöjen vertailu

Aloitetaan yksinkertaisimmasta tapauksesta (kuten myöhemmin käy ilmi). Yleisesti ottaen, ollakseni täysin rehellinen, meillä on melkein ihanteellinen tapaus, katsotaanpa monimutkaisuuden tarkistuslistaamme:

• Siellä on siisti, selkeä ja dokumentoitu API.
• Se on erittäin yksinkertaista, ja mikä tärkeintä, tunnus hankitaan automaattisesti.
• On python-kääre - paljon esimerkkejä.
• Yhteisö, joka analysoi ja kerää tietoja redditistä (jopa YouTube-videoihin, joissa selitetään python-kääreen käyttöä) tässä on esimerkki.
• Tarvittavat menetelmät ovat todennäköisesti olemassa API:ssa. Lisäksi koodi näyttää kompaktilta ja puhtaalta, alla on esimerkki toiminnosta, joka kerää kommentteja viestiin.

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

Otettu tämä valikoima käteviä apuvälineitä käärimiseen.

Huolimatta siitä, että tämä on paras tapaus, on silti syytä ottaa huomioon useita tärkeitä tekijöitä tosielämästä:

• API-rajoitukset - meidän on pakko ottaa tietoja erissä (nukkuminen pyyntöjen välillä jne.).
• Keräysaika – täydellistä analyysiä ja vertailua varten sinun on varattava paljon aikaa vain hämähäkin kävelemiseen subredditin läpi.
• Botin on toimittava palvelimella – et voi vain käyttää sitä kannettavassa tietokoneessa, laittaa sitä reppuun ja jatkaa liiketoimintaasi. Joten suoritin kaiken VPS:llä. Käyttämällä tarjouskoodia habrahabr10 voit säästää vielä 10% kustannuksista.
• Joidenkin tietojen fyysinen saavuttamattomuus (ne näkyvät ylläpitäjille tai niitä on liian vaikea kerätä) - tämä on otettava huomioon, sillä kaikkia tietoja ei periaatteessa voida kerätä riittävän ajoissa.
• Verkkovirheet: Verkko on tuskaa.
• Tämä on elävää todellista dataa – se ei ole koskaan puhdasta.

Tietysti nämä vivahteet on otettava mukaan kehitykseen. Tietyt tunnit/päivät riippuvat kehityskokemuksesta tai vastaavien tehtävien työkokemuksesta, mutta näemme, että tässä tehtävä on puhtaasti insinöörityötä eikä vaadi ylimääräisiä kehon liikkeitä ratkaistakseen - kaikki voidaan arvioida, ajoittaa ja tehdä erittäin hyvin.

Habr-osien vertailu

Siirrytäänpä mielenkiintoisempaan ja ei-triviaaliseen tapaukseen, jossa verrataan Habrin säiettä ja/tai osia.

Tarkastellaan monimutkaisuuden tarkistuslistaamme - tässä jokaisen kohdan ymmärtämiseksi sinun on kaivettava hieman itse tehtävää ja kokeiltava.

• Aluksi luulet, että API on olemassa, mutta sitä ei ole. Kyllä, kyllä, Habrilla on API, mutta se ei vain ole käyttäjien käytettävissä (tai ehkä se ei toimi ollenkaan).
• Sitten aloitat vain jäsentämään html:ää - "tuontipyynnöt", mikä voisi mennä pieleen?
• Miten muuten jäsentää? Yksinkertaisin ja yleisimmin käytetty tapa on iteroida tunnuksia. Huomaa, että se ei ole tehokkain ja sen täytyy käsitellä erilaisia ​​​​tapauksia - tässä on esimerkki todellisten tunnusten tiheydestä kaikkien olemassa olevien joukossa.

  
  Otettu tämä artikkeli.

• HTML:ään kääritty raakadata verkon päällä on tuskaa. Haluat esimerkiksi kerätä ja tallentaa artikkelin arvion: repit pisteet html:stä ja päätit tallentaa sen numerona jatkokäsittelyä varten: 

  1) int(score) antaa virheen: koska Habréssa on miinus, kuten esimerkiksi rivillä "–5" - tämä on en-viiva, ei miinusmerkki (odottamatta, eikö?), joten Jossain vaiheessa minun piti herättää jäsentäjä henkiin niin kauhealla korjauksella.

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

  Päivämäärää, plussia ja miinuksia ei ehkä ole ollenkaan (kuten näemme yllä check_date-funktiossa, tämä tapahtui).

  2) Erikoishahmot ilman pakottamista - ne tulevat, sinun on oltava valmis.

  3) Rakenne muuttuu viran tyypin mukaan.

  4) Vanhoilla viesteillä voi olla **outo rakenne**.

• Pohjimmiltaan virheiden käsittely ja se, mitä voi tapahtua tai ei, on käsiteltävä, eikä varmuudella voi ennustaa, mikä menee pieleen ja miten muuten rakenne voi olla ja mikä putoaa mistä - täytyy vain yrittää ottaa huomioon jäsentimen heittämät virheet.
• Sitten ymmärrät, että sinun täytyy jäsentää useissa säikeissä, muuten jäsentäminen yhdessä kestää yli 30 tuntia (tämä on puhtaasti jo toimivan yksisäikeisen jäsentimen suoritusaika, joka nukkuu eikä kuulu minkään kiellon alle). SISÄÄN tämä artikkeli, tämä johti jossain vaiheessa samanlaiseen suunnitelmaan:

Kokonaistarkistuslista monimutkaisuuden mukaan:

• Työskentely verkon kanssa ja html-jäsennys iteraatiolla ja haulla tunnuksella.
• Heterogeenisen rakenteen dokumentit.
• On monia paikkoja, joissa koodi voi helposti pudota.
• On tarpeen kirjoittaa || koodi.
• Tarvittava dokumentaatio, koodiesimerkit ja/tai yhteisö puuttuu.

Tämän tehtävän arvioitu aika on 3–5 kertaa pidempi kuin tietojen keräämiseen Redditistä.

Odnoklassniki-ryhmien vertailu

Siirrytään teknisesti mielenkiintoisimpaan kuvattuun tapaukseen. Minulle se oli kiinnostavaa juuri siksi, että ensisilmäyksellä se näyttää melko triviaalilta, mutta se ei ole sitä ollenkaan - heti kun siihen pistää kepillä.

Aloitetaan vaikeusasteen tarkistuslistallamme ja huomaa, että monet niistä osoittautuvat paljon vaikeammiksi kuin aluksi näyttävät:

• API on olemassa, mutta siitä puuttuu melkein kokonaan tarvittavat toiminnot.
• Tiettyihin toimintoihin pääsyä on pyydettävä postitse, eli käyttöoikeuden myöntäminen ei ole välitöntä.
• Se on hirveän dokumentoitu (alkuun venäläiset ja englanninkieliset termit ovat sekaisin kaikkialla ja täysin epäjohdonmukaisesti - joskus sinun on vain arvattava, mitä he haluavat sinulta jostain) ja lisäksi suunnittelu ei sovellu tietojen hankkimiseen esim. , tarvitsemamme toiminto.
• Edellyttää istuntoa dokumentaatiossa, mutta ei itse asiassa käytä sitä - eikä ole mitään muuta tapaa ymmärtää API-tilojen kaikkia hienouksia kuin näpäyttäminen ja toivominen, että jokin toimii.
• Esimerkkejä ei ole, eikä yhteisöä ole, ainoa tukipiste tiedon keräämisessä on pieni kääre Pythonissa (ilman monia käyttöesimerkkejä).
• Seleeni näyttää olevan toimivin vaihtoehto, koska monet tarvittavat tiedot ovat lukittuina.
  1) Toisin sanoen valtuutus tapahtuu kuvitteellisen käyttäjän kautta (ja rekisteröityminen käsin).

  2) Seleenin kanssa ei kuitenkaan ole takuita oikeasta ja toistettavasta työstä (ainakaan ok.ru:n tapauksessa varmasti).

  3) Ok.ru-verkkosivusto sisältää JavaScript-virheitä ja joskus käyttäytyy oudosti ja epäjohdonmukaisesti.

  4) Sinun täytyy tehdä sivutus, ladata elementtejä jne...

  5) Käärien antamia API-virheitä on käsiteltävä hankalesti, esimerkiksi näin (pala kokeellista koodia):

  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
  

  Lempivirheeni oli:

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

  6) Lopulta Selenium + API näyttää rationaalisimmalta vaihtoehdolta.

• On tarpeen tallentaa tila ja käynnistää järjestelmä uudelleen, käsitellä monia virheitä, mukaan lukien sivuston epäjohdonmukainen käyttäytyminen - ja näitä virheitä on melko vaikea kuvitella (ellet tietysti kirjoita jäsentimiä ammattimaisesti).

Tämän tehtävän ehdollinen aikaarvio on 3-5 kertaa suurempi kuin Habr. Huolimatta siitä, että Habrin tapauksessa käytämme frontaalista lähestymistapaa HTML-jäsentämisessä, ja OK:n tapauksessa voimme työskennellä API:n kanssa kriittisissä paikoissa.

Tulokset

Riippumatta siitä, kuinka paljon vaaditaan suuren tietojenkäsittelyputkimoduulin määräaikojen arvioimista "paikan päällä" (suunnittelemme tänään!), toteutusaikaa ei ole lähes koskaan mahdollista arvioida edes laadullisesti ilman tehtäväparametreja.

Hieman filosofisemmin sanottuna ketterät estimointistrategiat toimivat hyvin suunnittelutehtävissä, mutta ongelmissa, jotka ovat enemmän kokeellisia ja tietyssä mielessä "luovia" ja tutkivia eli vähemmän ennustettavia, on vaikeuksia, kuten vastaavien aiheiden esimerkeissä. joista olemme täällä keskustelleet.

Tiedonkeruu on tietysti vain hyvä esimerkki - se on yleensä uskomattoman yksinkertainen ja teknisesti mutkaton tehtävä, ja paholainen on usein yksityiskohdissa. Ja juuri tässä tehtävässä voimme näyttää kaikki mahdolliset vaihtoehdot, mikä voi mennä pieleen ja kuinka kauan työ voi kestää.

Jos katsot tehtävän ominaisuuksia ilman lisäkokeita, Reddit ja OK näyttävät samanlaisilta: on API, python-kääre, mutta pohjimmiltaan ero on valtava. Näistä parametreistä päätellen Habrin pars näyttää monimutkaisemmalta kuin OK - mutta käytännössä se on aivan päinvastoin, ja juuri tämä voidaan selvittää tekemällä yksinkertaisia ​​​​kokeita ongelman parametrien analysoimiseksi.

Kokemukseni mukaan tehokkain tapa on arvioida karkeasti aika, jonka tarvitset itse alustavaan analyysiin ja yksinkertaisiin ensimmäisiin kokeisiin, luemalla dokumentaatio - näiden avulla voit antaa tarkan arvion koko työstä. Suositun ketterän metodologian osalta pyydän teitä luomaan lipun "tehtävän parametrien arviointiin", jonka perusteella voin antaa arvion siitä, mitä "sprintissä" voidaan saavuttaa ja antaa tarkemman arvion jokaisesta. tehtävä.

Siksi tehokkain argumentti näyttää olevan argumentti, joka osoittaisi "ei-tekniselle" asiantuntijalle, kuinka paljon aikaa ja resursseja vaihtelee parametrien mukaan, joita ei ole vielä arvioitu.

Lähde: will.com