Kaj gre lahko narobe s podatkovno znanostjo? Zbiranje podatkov

Danes je na voljo 100500 tečajev podatkovne znanosti in že dolgo je znano, da je največ denarja v podatkovni znanosti mogoče zaslužiti s tečaji podatkovne znanosti (zakaj bi kopali, ko pa lahko prodajate lopate?). Glavna pomanjkljivost teh tečajev je, da nimajo nobene zveze z resničnim delom: nihče vam ne bo dal čistih, obdelanih podatkov v zahtevani obliki. In ko zapustite tečaj in začnete reševati pravi problem, se pojavijo številne nianse.

Zato začenjamo serijo zapiskov »Kaj gre lahko narobe s podatkovno znanostjo«, ki temelji na resničnih dogodkih, ki so se zgodili meni, mojim tovarišem in kolegom. Na resničnih primerih bomo analizirali tipične naloge Data Science: kako se to dejansko zgodi. Začnimo danes z nalogo zbiranja podatkov.

In prva stvar, ob katero se ljudje spotaknejo, ko začnejo delati z resničnimi podatki, je dejansko zbiranje teh podatkov, ki so za nas najpomembnejši. Ključno sporočilo tega članka:

Sistematično podcenjujemo čas, vire in trud, potrebne za zbiranje, čiščenje in pripravo podatkov.

In kar je najpomembnejše, razpravljali bomo o tem, kaj storiti, da to preprečimo.

Po različnih ocenah čiščenje, preoblikovanje, obdelava podatkov, inženiring funkcij itd. vzamejo 80-90 % časa, analiza pa 10-20 %, medtem ko se skoraj vse izobraževalno gradivo osredotoča izključno na analizo.

Oglejmo si na tipičnem primeru preprost analitični problem v treh različicah in poglejmo, kaj so »oteževalne okoliščine«.

In kot primer bomo spet razmislili o podobnih različicah naloge zbiranja podatkov in primerjave skupnosti za:

1. Dva podredita Reddit
2. Dva razdelka Habr
3. Dve skupini Odnoklassniki

Pogojni pristop v teoriji

Odprite spletno mesto in preberite primere, če so jasni, namenite nekaj ur za branje, nekaj ur za kodo z uporabo primerov in odpravljanje napak. Dodajte nekaj ur za zbiranje. V rezervo vrzite nekaj ur (pomnožite z dve in dodajte N ur).

Ključna točka: Ocene časa temeljijo na predpostavkah in ugibanjih o tem, kako dolgo bo trajalo.

Časovno analizo je potrebno začeti z oceno naslednjih parametrov za zgoraj opisan pogojni problem:

• Kakšna je velikost podatkov in koliko jih je treba fizično zbrati (*glejte spodaj*).
• Kakšen je čas zbiranja ene plošče in koliko časa morate čakati, preden lahko prevzamete drugo?
• Razmislite o pisanju kode, ki shrani stanje in začne vnovični zagon, ko (ne če) vse odpove.
• Ugotovimo, ali potrebujemo avtorizacijo in nastavimo čas za pridobitev dostopa preko API-ja.
• Število napak nastavite kot funkcijo kompleksnosti podatkov - ocenite za določeno nalogo: strukturo, koliko transformacij, kaj in kako ekstrahirati.
• Odpravite omrežne napake in težave z nestandardnim vedenjem projekta.
• Ocenite, ali so zahtevane funkcije v dokumentaciji in če ne, kako in koliko je potrebno za rešitev.

Najpomembneje pa je, da bo za oceno časa - dejansko morate porabiti čas in trud za "izvidovanje v sili" - le tako vaše načrtovanje ustrezno. Torej, ne glede na to, koliko vas sili, da rečete "kako dolgo traja zbiranje podatkov" - kupite si nekaj časa za predhodno analizo in argumentirajte, koliko se bo čas razlikoval glede na dejanske parametre problema.

In zdaj bomo pokazali konkretne primere, kjer se bodo takšni parametri spremenili.

Ključna točka: Predračun temelji na analizi ključnih dejavnikov, ki vplivajo na obseg in zahtevnost dela.

Ocenjevanje na podlagi ugibanja je dober pristop, kadar so funkcionalni elementi dovolj majhni in ni veliko dejavnikov, ki bi lahko bistveno vplivali na zasnovo problema. Toda v primeru številnih problemov podatkovne znanosti postane takih dejavnikov izjemno veliko in takšen pristop postane neustrezen.

Primerjava skupnosti Reddit

Začnimo z najpreprostejšim primerom (kot se izkaže kasneje). Na splošno, če smo popolnoma iskreni, imamo skoraj idealen primer, preverimo naš kontrolni seznam zapletenosti:

• Obstaja urejen, jasen in dokumentiran API.
• Je izjemno preprosto in kar je najpomembneje, žeton se pridobi samodejno.
• Obstaja ovoj za python - z veliko primeri.
• Skupnost, ki analizira in zbira podatke na redditu (tudi do videoposnetkov v YouTubu, ki pojasnjujejo, kako uporabljati python wrapper) Na primer.
• Metode, ki jih potrebujemo, najverjetneje obstajajo v API-ju. Poleg tega je koda videti kompaktna in čista, spodaj je primer funkcije, ki zbira komentarje na objavo.

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

Odvzet od to izbor priročnih pripomočkov za zavijanje.

Kljub temu, da je to najboljši primer, je še vedno vredno upoštevati številne pomembne dejavnike iz resničnega življenja:

• Omejitve API-ja - podatke smo prisiljeni jemati v paketih (mirovanje med zahtevami itd.).
• Čas zbiranja – za popolno analizo in primerjavo boste morali nameniti veliko časa samo za sprehod pajka skozi subreddit.
• Bot mora delovati na strežniku – ne morete ga kar zagnati na prenosnem računalniku, ga dati v nahrbtnik in se lotiti svojega posla. Tako sem vse izvajal na VPS. Z uporabo promocijske kode habrahabr10 lahko prihranite še 10% stroškov.
• Fizična nedostopnost nekaterih podatkov (so vidni skrbnikom ali pa jih je pretežko zbrati) – to je treba upoštevati, saj vseh podatkov načeloma ni mogoče zbrati pravočasno.
• Omrežne napake: Omrežje je težava.
• To so živi resnični podatki - nikoli niso čisti.

Seveda je treba te nianse vključiti v razvoj. Določene ure/dnevi so odvisni od razvojnih izkušenj ali izkušenj pri delu na podobnih nalogah, vendar vidimo, da je tukaj naloga čisto inženirska in ne zahteva dodatnih telesnih gibov za reševanje - vse je mogoče zelo dobro oceniti, načrtovati in narediti.

Primerjava odsekov Habr

Pojdimo na bolj zanimiv in netrivialen primer primerjave niti in/ali odsekov Habra.

Oglejmo si naš kontrolni seznam zapletenosti - tukaj se boste morali, da bi razumeli vsako točko, malo poglobiti v samo nalogo in eksperimentirati.

• Sprva mislite, da obstaja API, vendar ga ni. Da, da, Habr ima API, vendar preprosto ni dostopen uporabnikom (ali pa morda sploh ne deluje).
• Potem šele začnete razčlenjevati html - "uvozne zahteve", kaj bi lahko šlo narobe?
• Kako sploh razčleniti? Najenostavnejši in najpogosteje uporabljen pristop je ponavljanje ID-jev, upoštevajte, da ni najučinkovitejši in bo moral obravnavati različne primere - tukaj je primer gostote pravih ID-jev med vsemi obstoječimi.

  
  Odvzet od to člankov.

• Neobdelani podatki, zaviti v HTML na vrhu spleta, so bolečina. Na primer, želite zbrati in shraniti oceno članka: rezultat ste iztrgali iz html-ja in se odločili, da ga shranite kot številko za nadaljnjo obdelavo: 

  1) int(score) vrže napako: ker je na Habréju minus, kot je na primer v vrstici »–5« - to je pomišljaj, ne znak minus (nepričakovano, kajne?), torej pri na neki točki sem moral oživiti razčlenjevalnik s tako groznim popravkom.

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

  Morda sploh ni datuma, plusov in minusov (kot vidimo zgoraj v funkciji check_date, se je to zgodilo).

  2) Neubežni posebni znaki - prišli bodo, morate biti pripravljeni.

  3) Struktura se spreminja glede na vrsto objave.

  4) Stare objave imajo lahko **čudno strukturo**.

• V bistvu bo treba obravnavati napake in kaj se lahko ali ne sme zgoditi, in ne morete z gotovostjo predvideti, kaj bo šlo narobe in kakšna je lahko drugačna struktura ter kaj bo kje padlo – samo poskusiti boste morali in upoštevati napake, ki jih vrže razčlenjevalnik.
• Potem ugotoviš, da moraš parsirati v več nitih, sicer bo parsiranje v eni potem trajalo 30+ ur (to je čisto čas izvajanja že delujočega enonitnega parserja, ki spi in ne spada pod nobene prepovedi). IN to članka, je to na neki točki vodilo do podobne sheme:

Skupni kontrolni seznam po zahtevnosti:

• Delo z omrežjem in razčlenjevanje html s ponavljanjem in iskanjem po ID-ju.
• Dokumenti heterogene strukture.
• Obstaja veliko mest, kjer lahko koda zlahka pade.
• Treba je napisati || Koda.
• Potrebna dokumentacija, primeri kode in/ali skupnost manjkajo.

Predvideni čas za to nalogo bo 3-5-krat večji kot za zbiranje podatkov iz Reddita.

Primerjava skupin Odnoklassniki

Preidimo na tehnično najbolj zanimiv opisani primer. Zame je bilo zanimivo ravno zato, ker je na prvi pogled videti precej trivialno, a se sploh ne izkaže za tako - takoj ko vanj pobodeš palico.

Začnimo z našim kontrolnim seznamom težavnosti in upoštevajte, da se bo veliko izkazalo za veliko težje, kot je videti na prvi pogled:

• Obstaja API, vendar skoraj popolnoma nima potrebnih funkcij.
• Za nekatere funkcije morate zahtevati dostop po pošti, kar pomeni, da odobritev dostopa ni takojšnja.
• Je strašno dokumentiran (za začetek se povsod mešajo ruski in angleški izrazi, in to popolnoma nedosledno - včasih je treba le uganiti, kaj od tebe nekje hočejo) in poleg tega dizajn ni primeren za pridobivanje podatkov, npr. , funkcijo, ki jo potrebujemo.
• Zahteva sejo v dokumentaciji, vendar je dejansko ne uporablja - in ni mogoče razumeti vseh zapletenosti načinov API, razen brskanja in upanja, da bo nekaj delovalo.
• Ni primerov in skupnosti, edina opora pri zbiranju informacij je majhna ovoj v Pythonu (brez veliko primerov uporabe).
• Selen se zdi najbolj izvedljiva možnost, saj je veliko potrebnih podatkov zaklenjenih.
  1) To pomeni, da avtorizacija poteka prek fiktivnega uporabnika (in ročna registracija).

  2) Vendar pri Seleniumu ni zagotovil za pravilno in ponovljivo delo (vsaj v primeru ok.ru zagotovo).

  3) Spletno mesto Ok.ru vsebuje napake JavaScript in se včasih obnaša nenavadno in nedosledno.

  4) Morate narediti paginacijo, nalaganje elementov itd.

  5) Napake API-ja, ki jih daje ovoj, bo treba obravnavati nerodno, na primer takole (del eksperimentalne 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
  

  Moja najljubša napaka je bila:

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

  6) Konec koncev je Selenium + API videti kot najbolj racionalna možnost.

• Treba je shraniti stanje in znova zagnati sistem, obravnavati številne napake, vključno z nekonsistentnim vedenjem spletnega mesta - in te napake si je precej težko predstavljati (razen če razčlenjevalnike pišete profesionalno, seveda).

Pogojna ocena časa za to nalogo bo 3-5 krat višja kot za zbiranje podatkov iz Habra. Kljub temu, da v primeru Habra uporabljamo frontalni pristop z razčlenjevanjem HTML, v primeru OK pa lahko na kritičnih mestih delamo z API-jem.

Ugotovitve

Ne glede na to, koliko se od vas zahteva, da ocenite roke "na kraju samem" (načrtujemo danes!) obsežnega cevovodnega modula za obdelavo podatkov, časa izvedbe skoraj nikoli ni mogoče oceniti niti kvalitativno brez analize parametrov naloge.

Nekoliko bolj filozofsko gledano, agilne strategije ocenjevanja dobro delujejo pri inženirskih nalogah, vendar imajo problemi, ki so bolj eksperimentalni in v nekem smislu »ustvarjalni« in raziskovalni, tj. manj predvidljivi, težave, kot v primerih podobnih tem, o katerih smo razpravljali tukaj.

Seveda je zbiranje podatkov samo vzorčni primer – običajno gre za neverjetno preprosto in tehnično nezapleteno opravilo, hudič pa se pogosto skriva v podrobnostih. In prav na tej nalogi lahko pokažemo vso paleto možnih možnosti, kaj gre lahko narobe in koliko časa natančno lahko delo traja.

Če pogledate značilnosti naloge brez dodatnih poskusov, potem sta Reddit in OK videti podobna: obstaja API, python ovoj, vendar je v bistvu razlika velika. Sodeč po teh parametrih je Habrov pars videti bolj zapleten kot OK - v praksi pa je ravno nasprotno in prav to je mogoče ugotoviti z izvajanjem preprostih poskusov za analizo parametrov problema.

Po mojih izkušnjah je najučinkovitejši pristop približna ocena časa, ki ga boste potrebovali za samo predhodno analizo in enostavne prve poskuse, branje dokumentacije – to vam bo omogočilo natančno oceno celotnega dela. V smislu priljubljene agilne metodologije vas prosim, da ustvarite vstopnico za “ocenjevanje parametrov naloge”, na podlagi katere lahko podam oceno, kaj je mogoče doseči v “šprintu” in podam natančnejšo oceno za vsako. naloga.

Zato se zdi najučinkovitejši argument tisti, ki bi »netehničnemu« specialistu pokazal, koliko časa in virov se bo razlikovalo glede na parametre, ki jih je treba še oceniti.

Vir: www.habr.com