Što može poći po zlu sa Data Science? Prikupljanje podataka

Danas postoji 100500 XNUMX tečajeva Data Science i odavno je poznato da se najviše novaca u Data Scienceu može zaraditi putem tečajeva Data Science (zašto kopati kad možete prodavati lopate?). Glavni nedostatak ovih tečajeva je što nemaju nikakve veze sa stvarnim radom: nitko vam neće dati čiste, obrađene podatke u potrebnom formatu. A kada napustite tečaj i počnete rješavati pravi problem, pojavljuju se mnoge nijanse.

Stoga započinjemo seriju bilješki “Što može poći po zlu s Data Scienceom”, temeljenu na stvarnim događajima koji su se dogodili meni, mojim suborcima i kolegama. Analizirat ćemo tipične zadatke Data Science koristeći stvarne primjere: kako se to zapravo događa. Počnimo danas sa zadatkom prikupljanja podataka.

I prva stvar o koju se ljudi spotaknu kada počnu raditi sa stvarnim podacima zapravo je prikupljanje ovih podataka koji su nama najrelevantniji. Ključna poruka ovog članka:

Sustavno podcjenjujemo vrijeme, resurse i trud potrebne za prikupljanje, čišćenje i pripremu podataka.

I što je najvažnije, razgovarat ćemo o tome što učiniti da to spriječimo.

Prema različitim procjenama, čišćenje, transformacija, obrada podataka, inženjering značajki itd. zauzimaju 80-90% vremena, a analiza 10-20%, dok se gotovo sav obrazovni materijal fokusira isključivo na analizu.

Pogledajmo jednostavan analitički problem u tri verzije kao tipičan primjer i vidimo što su to “otegotne okolnosti”.

Kao primjer, ponovno ćemo razmotriti slične varijacije zadatka prikupljanja podataka i usporedbe zajednica za:

1. Dva Reddit subreddita
2. Dva odjeljka Habr
3. Dvije grupe Odnoklassniki

Uvjetni pristup u teoriji

Otvorite stranicu i pročitajte primjere, ako je jasno, odvojite nekoliko sati za čitanje, nekoliko sati za kod koristeći primjere i otklanjanje pogrešaka. Dodajte nekoliko sati za prikupljanje. Ubacite nekoliko sati u rezervu (pomnožite s dva i dodajte N sati).

Ključna točka: Procjene vremena temelje se na pretpostavkama i nagađanjima o tome koliko će trajati.

Vremensku analizu potrebno je započeti procjenom sljedećih parametara za gore opisani uvjetni problem:

• Kolika je veličina podataka i koliko ih je potrebno fizički prikupiti (*vidi dolje*).
• Koje je vrijeme preuzimanja za jednu ploču i koliko dugo morate čekati prije nego što možete preuzeti drugu?
• Razmislite o pisanju koda koji sprema stanje i pokreće ponovno pokretanje kada (ne ako) sve ne uspije.
• Odredite trebamo li autorizaciju i odredite vrijeme za dobivanje pristupa putem API-ja.
• Postavite broj pogrešaka kao funkciju složenosti podataka - procijenite za određeni zadatak: strukturu, koliko transformacija, što i kako ekstrahirati.
• Ispravite mrežne pogreške i probleme s nestandardnim ponašanjem projekta.
• Procijenite jesu li potrebne funkcije u dokumentaciji, a ako ne, kako i koliko je potrebno za zaobilazno rješenje.

Najvažnije je da za procjenu vremena - zapravo morate potrošiti vrijeme i trud na "izviđanje na snazi" - tek tada će vaše planiranje biti adekvatno. Stoga, bez obzira na to koliko vas tjeraju da kažete "koliko dugo traje prikupljanje podataka" - kupite si malo vremena za preliminarnu analizu i argumentirajte koliko će vrijeme varirati ovisno o stvarnim parametrima problema.

A sada ćemo pokazati konkretne primjere gdje će se takvi parametri promijeniti.

Ključna točka: Procjena se temelji na analizi ključnih čimbenika koji utječu na opseg i složenost posla.

Procjena temeljena na pretpostavci dobar je pristup kada su funkcionalni elementi dovoljno mali i nema mnogo čimbenika koji mogu značajno utjecati na dizajn problema. Ali u slučaju brojnih problema znanosti o podacima, takvi faktori postaju izuzetno brojni i takav pristup postaje neadekvatan.

Usporedba Reddit zajednica

Počnimo s najjednostavnijim slučajem (kao što će se kasnije pokazati). Općenito, da budemo potpuno iskreni, imamo gotovo idealan slučaj, provjerimo naš kontrolni popis složenosti:

• Postoji uredan, jasan i dokumentiran API.
• Vrlo je jednostavno i što je najvažnije, token se dobiva automatski.
• Tu je python omot - s puno primjera.
• Zajednica koja analizira i prikuplja podatke na redditu (čak i do YouTube videa koji objašnjavaju kako koristiti python wrapper) Na primjer.
• Metode koje trebamo najvjerojatnije postoje u API-ju. Štoviše, kod izgleda kompaktno i čisto, ispod je primjer funkcije koja prikuplja komentare na post.

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

Preuzeto iz ovo izbor prikladnih uslužnih programa za omatanje.

Unatoč činjenici da je ovo najbolji slučaj, ipak vrijedi uzeti u obzir niz važnih čimbenika iz stvarnog života:

• Ograničenja API-ja - prisiljeni smo uzimati podatke u serijama (spavanje između zahtjeva itd.).
• Vrijeme prikupljanja - za potpunu analizu i usporedbu, morat ćete odvojiti dosta vremena samo da pauk prošeće subredditom.
• Bot mora raditi na poslužitelju — ne možete ga samo pokrenuti na prijenosnom računalu, staviti u ruksak i nastaviti svojim poslom. Pa sam sve pokrenuo na VPS-u. Korištenjem promotivnog koda habrahabr10 možete uštedjeti još 10% troškova.
• Fizička nedostupnost nekih podataka (vidljivi su administratorima ili ih je preteško prikupiti) - o tome se mora voditi računa, u principu se svi podaci ne mogu prikupiti u odgovarajućem vremenu.
• Mrežne pogreške: umrežavanje je bol.
• Ovo su živi stvarni podaci - nikad nisu čisti.

Naravno, potrebno je uključiti ove nijanse u razvoj. Određeni sati/dani ovise o iskustvu u razvoju ili iskustvu rada na sličnim zadacima, međutim, vidimo da je ovdje zadatak čisto inženjerski i ne zahtijeva dodatne pokrete tijela za rješavanje - sve se može vrlo dobro procijeniti, rasporediti i obaviti.

Usporedba odjeljaka Habr

Prijeđimo na zanimljiviji i netrivijalni slučaj usporedbe niti i/ili odjeljaka Habra.

Provjerimo našu kontrolnu listu složenosti - ovdje, da biste razumjeli svaku točku, morat ćete se malo udubiti u sam zadatak i eksperimentirati.

• Isprva mislite da postoji API, ali ne postoji. Da, da, Habr ima API, ali jednostavno nije dostupan korisnicima (ili možda uopće ne radi).
• Zatim samo počnete analizirati html - "zahtjevi za uvoz", što bi moglo poći po zlu?
• Kako uopće analizirati? Najjednostavniji i najčešće korišteni pristup je iteracija preko ID-ova, imajte na umu da to nije najučinkovitije i morat će obrađivati ​​različite slučajeve - ovdje je primjer gustoće stvarnih ID-ova među svim postojećim.

  
  Preuzeto iz ovo članak.

• Neobrađeni podaci umotani u HTML na vrhu weba su bol. Na primjer, želite prikupiti i spremiti ocjenu članka: otrgnuli ste rezultat iz html-a i odlučili ga spremiti kao broj za daljnju obradu: 

  1) int(score) daje pogrešku: budući da na Habréu postoji minus, kao, na primjer, u retku “–5” - ovo je crtica, a ne znak minus (neočekivano, zar ne?), tako da na u jednom sam trenutku morao oživjeti parser s tako užasnim popravkom.

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

  Možda uopće nema datuma, pluseva i minusa (kao što vidimo gore u funkciji check_date, to se dogodilo).

  2) Neizbjegnuti posebni znakovi - doći će, morate biti spremni.

  3) Struktura se mijenja ovisno o vrsti radnog mjesta.

  4) Stari postovi mogu imati **čudnu strukturu**.

• U suštini, rukovanje pogreškama i ono što se može ili ne mora dogoditi morat će se riješiti i ne možete sa sigurnošću predvidjeti što će poći po zlu i kakva bi inače struktura mogla biti i što će gdje otpasti - samo ćete morati pokušati i uzeti u obzir pogreške koje analizirač izbacuje.
• Tada shvatite da morate parsirati u nekoliko niti, inače će parsiranje u jednoj trajati 30+ sati (ovo je čisto vrijeme izvršenja već radnog jednonitnog parsera, koji spava i ne potpada pod nikakve zabrane). U ovo članak, to je u nekom trenutku dovelo do slične sheme:

Ukupni kontrolni popis prema složenosti:

• Rad s mrežom i html parsiranje s iteracijom i pretraživanjem po ID-u.
• Dokumenti heterogene strukture.
• Postoje mnoga mjesta gdje šifra može lako pasti.
• Potrebno je napisati || kodirati.
• Nedostaje potrebna dokumentacija, primjeri koda i/ili zajednica.

Procijenjeno vrijeme za ovaj zadatak bit će 3-5 puta veće nego za prikupljanje podataka s Reddita.

Usporedba grupa Odnoklassniki

Prijeđimo na tehnički najzanimljiviji opisani slučaj. Meni je to bilo zanimljivo upravo zato što na prvi pogled izgleda sasvim trivijalno, ali uopće ne ispada tako – čim ga bocnete štapom.

Započnimo s našim kontrolnim popisom poteškoća i primijetimo da će se mnogi od njih pokazati mnogo težima nego što se isprva čini:

• Postoji API, ali mu gotovo u potpunosti nedostaju potrebne funkcije.
• Za pojedine funkcije potrebno je zatražiti pristup mailom, odnosno odobravanje pristupa nije trenutno.
• Strašno je dokumentiran (za početak, posvuda se miješaju ruski i engleski izrazi, i to potpuno nedosljedno - ponekad samo trebate pogoditi što od vas negdje žele) i, štoviše, dizajn nije pogodan za dobivanje podataka, npr. , funkcija koja nam je potrebna.
• Zahtijeva sesiju u dokumentaciji, ali je zapravo ne koristi - i nema načina da se razumiju sve zamršenosti API modova osim čeprkanja i nade da će nešto raditi.
• Nema primjera i zajednice, jedina točka oslonca u prikupljanju informacija je mala omot u Pythonu (bez mnogo primjera korištenja).
• Čini se da je selen najizvedivija opcija, budući da su mnogi potrebni podaci zaključani.
  1) Odnosno, autorizacija se odvija preko fiktivnog korisnika (i ručna registracija).

  2) Međutim, sa Seleniumom nema jamstava za ispravan i ponovljiv rad (barem u slučaju ok.ru sigurno).

  3) Web stranica Ok.ru sadrži JavaScript pogreške i ponekad se ponaša čudno i nedosljedno.

  4) Morate napraviti paginaciju, učitavanje elemenata, itd...

  5) API pogreške koje omot daje morat će se nezgodno postupati, na primjer, ovako (dio eksperimentalnog koda):

  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
  

  Moja omiljena greška je bila:

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

  6) U konačnici, Selenium + API izgleda kao najracionalnija opcija.

• Potrebno je spasiti stanje i ponovno pokrenuti sustav, obraditi mnoge pogreške, uključujući nedosljedno ponašanje stranice - a te je pogreške prilično teško zamisliti (osim ako profesionalno pišete parsere, naravno).

Uvjetna procjena vremena za ovaj zadatak bit će 3-5 puta veća nego za prikupljanje podataka s Habra. Unatoč tome što u slučaju Habra koristimo frontalni pristup s HTML parsiranjem, au slučaju OK-a možemo raditi s API-jem na kritičnim mjestima.

Zaključci

Bez obzira na to koliko se od vas zahtijeva procjena rokova „na licu mjesta“ (mi planiramo danas!) voluminoznog cjevovodnog modula za obradu podataka, vrijeme izvršenja gotovo nikada nije moguće procijeniti čak ni kvalitativno bez analize parametara zadatka.

S malo više filozofske strane, agilne strategije procjenjivanja dobro funkcioniraju za inženjerske zadatke, ali problemi koji su više eksperimentalni i, u određenom smislu, "kreativni" i istraživački, tj. manje predvidljivi, imaju poteškoća, kao u primjerima sličnih tema, o kojima smo ovdje raspravljali.

Naravno, prikupljanje podataka samo je ogledni primjer – obično je to nevjerojatno jednostavan i tehnički nekompliciran zadatak, a vrag se često krije u detaljima. I upravo na tom zadatku možemo pokazati cijeli niz mogućih opcija što može poći po zlu i koliko točno posao može trajati.

Ako pogledate karakteristike zadatka bez dodatnih eksperimenata, tada Reddit i OK izgledaju slično: postoji API, python wrapper, ali u biti razlika je ogromna. Sudeći po ovim parametrima, Habrov pars izgleda više komplicirano nego OK – ali u praksi je upravo suprotno, a upravo to se može saznati provođenjem jednostavnih eksperimenata za analizu parametara problema.

Po mom iskustvu, najučinkovitiji pristup je gruba procjena vremena koje će vam trebati za samu preliminarnu analizu i jednostavne prve pokuse, čitanje dokumentacije - to će vam omogućiti da date točnu procjenu za cijeli rad. U smislu popularne agilne metodologije, molim vas da kreirate tiket za “procjenu parametara zadatka” na temelju kojeg mogu dati procjenu što se može postići unutar “sprinta” i dati točniju procjenu za svaki zadatak.

Stoga se čini da je najučinkovitiji argument onaj koji bi "netehničkom" stručnjaku pokazao koliko će vremena i resursa varirati ovisno o parametrima koje tek treba procijeniti.

Izvor: www.habr.com