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

Danas postoji 100500 kurseva nauke o podacima i odavno je poznato da se najviše novca u nauci o podacima može zaraditi kroz kurseve nauke o podacima (zašto kopati kada možete prodati lopate?). Glavni nedostatak ovih kurseva je što nemaju nikakve veze sa stvarnim radom: niko vam neće dati čiste, obrađene podatke u potrebnom formatu. A kada napustite kurs i počnete rješavati pravi problem, pojavljuju se mnoge nijanse.

Stoga počinjemo seriju bilješki „Šta može poći po zlu sa Data Science“, zasnovanih na stvarnim događajima koji su se desili meni, mojim drugovima i kolegama. Analiziraćemo tipične zadatke nauke o podacima koristeći stvarne primere: kako se to zapravo dešava. Počnimo danas sa zadatkom prikupljanja podataka.

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

Sistematski potcjenjujemo vrijeme, resurse i trud koji su potrebni za prikupljanje, čišćenje i pripremu podataka.

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

Prema različitim procjenama, čišćenje, transformacija, obrada podataka, inžinjering karakteristika itd. oduzimaju 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 šta su „otežavajuće okolnosti“.

I kao primjer, opet ćemo razmotriti slične varijacije zadatka prikupljanja podataka i poređenja zajednica za:

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

Uslovni pristup u teoriji

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

Ključna tačka: Procjene vremena su zasnovane na pretpostavkama i nagađanjima o tome koliko će vremena trajati.

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

• Kolika je veličina podataka i koliko ih treba fizički prikupiti (*pogledajte dolje*).
• Koje je vrijeme prikupljanja za jednu ploču i koliko dugo morate čekati prije nego što preuzmete drugu?
• Razmislite o pisanju koda koji čuva stanje i pokreće ponovno pokretanje kada (ne ako) sve ne uspije.
• Utvrdite da li nam je potrebna autorizacija i postavite vrijeme za dobijanje pristupa putem API-ja.
• Postavite broj grešaka kao funkciju složenosti podataka - procijenite za određeni zadatak: strukturu, koliko transformacija, šta i kako izdvojiti.
• Popravite mrežne greške i probleme s nestandardnim ponašanjem projekta.
• Procijenite da li su potrebne funkcije u dokumentaciji, a ako ne, onda kako i koliko je potrebno za zaobilazno rješenje.

Najvažnije je da za procjenu vremena – zapravo treba utrošiti vrijeme i trud na “izviđanje u sili” – tek tada će vaše planiranje biti adekvatno. Stoga, bez obzira na to koliko vas tjeraju da kažete „koliko je potrebno za 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 tačka: Procjena se zasniva na analizi ključnih faktora koji utiču na obim i složenost posla.

Procjena na temelju nagađanja je dobar pristup kada su funkcionalni elementi dovoljno mali i nema mnogo faktora koji mogu značajno utjecati na dizajn problema. Ali u slučaju brojnih problema nauke o podacima, takvi faktori postaju izuzetno brojni i takav pristup postaje neadekvatan.

Poređenje Reddit zajednica

Počnimo s najjednostavnijim slučajem (kako se kasnije ispostavilo). Općenito, da budemo potpuno iskreni, imamo gotovo idealan slučaj, provjerimo našu kontrolnu listu složenosti:

• Postoji uredan, jasan i dokumentovan API.
• Izuzetno je jednostavno i što je najvažnije, token se dobija automatski.
• Postoje python omotač - sa puno primjera.
• Zajednica koja analizira i prikuplja podatke na Redditu (čak i na YouTube video zapisima koji objašnjavaju kako koristiti python omot) Na primjer.
• Metode koje su nam potrebne najvjerovatnije postoje u API-ju. Štoviše, kod izgleda kompaktno i čisto, ispod je primjer funkcije koja prikuplja komentare na objavu.

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

Uzeto od ovo izbor praktičnih alata za umotavanje.

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

• API ograničenja - primorani smo da preuzimamo podatke u serijama (spavanje između zahtjeva, itd.).
• Vrijeme prikupljanja - za potpunu analizu i poređenje, morat ćete izdvojiti značajno vrijeme samo da pauk prošeta kroz subreddit.
• Bot mora raditi na serveru – ne možete ga samo pokrenuti na laptopu, staviti ga u ranac i krenuti svojim poslom. Tako da sam sve pokrenuo na VPS-u. Koristeći promotivni kod habrahabr10 možete uštedjeti još 10% cijene.
• Fizička nedostupnost nekih podataka (vidljivi su administratorima ili ih je previše teško prikupiti) – to se mora uzeti u obzir; u principu, svi podaci se ne mogu prikupiti u odgovarajućem roku.
• Mrežne greške: Umrežavanje je bol.
• Ovo su živi stvarni podaci - nikada nisu čisti.

Naravno, potrebno je uključiti ove nijanse u razvoj. Konkretni sati/dani ovise o razvojnom iskustvu 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, zakazati i uraditi.

Poređenje Habrovih sekcija

Pređimo na zanimljiviji i netrivijalni slučaj poređenja niti i/ili sekcija Habra.

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

• U početku mislite da postoji API, ali ne postoji. Da, da, Habr ima API, ali jednostavno nije dostupan korisnicima (ili možda uopće ne radi).
• Onda samo počnete da analizirate html - "zahtjevi za uvoz", što bi moglo poći po zlu?
• Kako raščlaniti? Najjednostavniji i najčešće korišćeni pristup je iteracija preko ID-ova, imajte na umu da nije najefikasniji i da će morati da obrađuje različite slučajeve - evo primera gustine stvarnih ID-ova među svim postojećim.

  
  Uzeto od ovo članci.

• Sirovi podaci umotani u HTML na vrhu weba su muka. Na primjer, želite prikupiti i sačuvati ocjenu članka: istrgali ste rezultat iz html-a i odlučili da ga sačuvate kao broj za dalju obradu: 

  1) int(score) daje grešku: pošto na Habré-u postoji minus, kao, na primjer, u redu “–5” - ovo je crtica, a ne znak minus (neočekivano, zar ne?), tako da na u jednom trenutku sam morao oživiti parser sa tako strašnim 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) Posebni znakovi bez bijega - oni će doći, morate biti spremni.

  3) Struktura se mijenja ovisno o vrsti posta.

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

• U suštini, rukovanje greškama i ono što se može ili ne mora dogoditi morat će se rješavati i ne možete sa sigurnošću predvidjeti šta će poći po zlu i kako drugačije struktura može biti i šta će gdje otpasti - samo ćete morati pokušati i uzeti u obzir greške koje parser baca.
• Tada shvatite da trebate raščlaniti u nekoliko niti, inače će raščlanjivanje u jednoj tada trajati više od 30 sati (ovo je čisto vrijeme izvršenja već funkcionalnog jednonitnog parsera, koji spava i ne potpada pod zabranu). IN ovo članak, ovo je u nekom trenutku dovelo do slične šeme:

Ukupna kontrolna lista po složenosti:

• Rad sa mrežom i html parsing sa iteracijom i pretraživanjem po ID-u.
• Dokumenti heterogene strukture.
• Postoji mnogo mjesta gdje kod lako može pasti.
• Potrebno je napisati || kod.
• Nedostaju potrebna dokumentacija, primjeri koda i/ili zajednica.

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

Poređenje grupa Odnoklassniki

Prijeđimo na tehnički najzanimljiviji opisani slučaj. Meni je to bilo interesantno upravo zato što na prvi pogled izgleda sasvim trivijalno, ali nikako ne ispada da je tako - čim zabodeš štapom u njega.

Počnimo s našom kontrolnom listom poteškoća i imajte na umu da će se mnoge od njih pokazati mnogo težima nego što izgledaju na prvi pogled:

• Postoji API, ali mu gotovo u potpunosti nedostaju potrebne funkcije.
• Za određene funkcije potrebno je zatražiti pristup poštom, odnosno odobravanje pristupa nije trenutno.
• Užasno je dokumentiran (za početak, ruski i engleski termini su posvuda pomiješani, i to potpuno nedosljedno - ponekad samo treba negdje pogoditi šta žele od vas) i, osim toga, dizajn nije pogodan za dobijanje podataka, npr. , funkcija koja nam je potrebna.
• Zahtijeva sesiju u dokumentaciji, ali je zapravo ne koristi - i ne postoji način da se razumiju sve zamršenosti API modova, osim švrljanja okolo i nade da će nešto raditi.
• Nema primjera i zajednice, jedina tačka oslonca u prikupljanju informacija je mala omotač u Pythonu (bez mnogo primjera upotrebe).
• Čini se da je selen najizvodljivija opcija, budući da su mnogi potrebni podaci zaključani.
  1) Odnosno, autorizacija se odvija preko fiktivnog korisnika (i registracija ručno).

  2) Međutim, sa Selenom ne postoje garancije za ispravan i ponovljiv rad (barem u slučaju ok.ru sigurno).

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

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

  5) API greške koje daje omotač morat će se nespretno rukovati, na primjer, ovako (komad 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) Na kraju, Selen + API izgleda kao najracionalnija opcija.

• Potrebno je sačuvati stanje i restartovati sistem, obraditi mnoge greške, uključujući i nekonzistentno ponašanje sajta - a te greške je prilično teško zamisliti (osim ako ne pišete parsere profesionalno, naravno).

Uvjetna procjena vremena za ovaj zadatak bit će 3-5 puta veća nego za prikupljanje podataka iz Habra. Uprkos činjenici da u slučaju Habra koristimo frontalni pristup sa HTML raščlanjivanjem, au slučaju OK možemo raditi sa API-jem na kritičnim mjestima.

nalazi

Bez obzira koliko se od vas traži da procijenite rokove „na licu mjesta“ (planiramo danas!) obimnog modula za obradu podataka, vrijeme izvršenja gotovo nikada nije moguće ni kvalitativno procijeniti bez analize parametara zadatka.

Nešto filozofskije rečeno, strategije agilnog procenjivanja dobro funkcionišu za inženjerske zadatke, ali problemi koji su više eksperimentalni i, u izvesnom smislu, „kreativniji“ i istraživački, odnosno manje predvidljivi, imaju poteškoća, kao u primerima sličnih tema, o čemu smo ovde raspravljali.

Naravno, prikupljanje podataka je samo najbolji primjer – obično je to nevjerojatno jednostavan i tehnički nekompliciran zadatak, a đavo je često u detaljima. I upravo na ovom zadatku možemo pokazati čitav niz mogućih opcija šta može poći po zlu i koliko dugo posao može trajati.

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

Po mom iskustvu, najefikasniji pristup je da grubo procijenite vrijeme koje će vam trebati za samu preliminarnu analizu i jednostavne prve eksperimente, čitajući dokumentaciju - to će vam omogućiti da date tačnu procjenu za cijeli posao. U smislu popularne agilne metodologije, molim vas da kreirate kartu za „procjenu parametara zadatka“, na osnovu koje mogu dati procjenu šta se može postići u okviru „sprinta“ i dati tačniju procjenu za svaki zadatak.

Stoga se čini da je najefikasniji argument onaj koji bi pokazao “netehničkom” stručnjaku koliko će vremena i resursa varirati u zavisnosti od parametara koji tek treba da se procijene.

izvor: www.habr.com