ProHoster > Blog > administrasie > Wat kan verkeerd gaan met Data Science? Data-insameling

Wat kan verkeerd gaan met Data Science? Data-insameling

Wat kan verkeerd gaan met Data Science? Data-insameling
Vandag is daar 100500 XNUMX Data Science-kursusse en dit is lank reeds bekend dat die meeste geld in Data Science deur Data Science-kursusse verdien kan word (hoekom grawe as jy grawe kan verkoop?). Die grootste nadeel van hierdie kursusse is dat dit niks met werklike werk te doen het nie: niemand sal vir jou skoon, verwerkte data in die vereiste formaat gee nie. En wanneer jy die kursus verlaat en 'n werklike probleem begin oplos, kom baie nuanses na vore.

Daarom begin ons 'n reeks notas "Wat kan verkeerd gaan met Data Science", gebaseer op werklike gebeure wat met my, my kamerade en kollegas gebeur het. Ons sal tipiese Data Science-take analiseer deur werklike voorbeelde te gebruik: hoe dit werklik gebeur. Kom ons begin vandag met die data-insamelingstaak.

En die eerste ding waaroor mense struikel wanneer hulle met regte data begin werk, is eintlik om hierdie data in te samel wat vir ons die meeste relevant is. Die sleutelboodskap van hierdie artikel:

Ons onderskat stelselmatig die tyd, hulpbronne en moeite wat nodig is om data in te samel, skoon te maak en voor te berei.

En die belangrikste, ons sal bespreek wat om te doen om dit te voorkom.

Volgens verskeie skattings neem skoonmaak, transformasie, dataverwerking, kenmerk-ingenieurswese, ens. 80-90% van die tyd, en ontleding 10-20%, terwyl byna alle opvoedkundige materiaal uitsluitlik op analise fokus.

Kom ons kyk na 'n eenvoudige analitiese probleem in drie weergawes as 'n tipiese voorbeeld en kyk wat “verswarende omstandighede” is.

En as 'n voorbeeld, weer, sal ons soortgelyke variasies van die taak van die insameling van data en die vergelyking van gemeenskappe oorweeg vir:

  1. Twee Reddit-subreddits
  2. Twee afdelings van Habr
  3. Twee groepe Odnoklassniki

Voorwaardelike benadering in teorie

Maak die webwerf oop en lees die voorbeelde, as dit duidelik is, sit 'n paar uur opsy vir lees, 'n paar uur vir die kode deur die voorbeelde en ontfouting te gebruik. Voeg 'n paar uur by vir versameling. Gooi 'n paar uur in reserwe (vermenigvuldig met twee en voeg N uur by).

Sleutelpunt: Tydskattings is gebaseer op aannames en raaiwerk oor hoe lank dit sal neem.

Dit is nodig om die tydanalise te begin deur die volgende parameters vir die voorwaardelike probleem hierbo beskryf te skat:

  • Wat is die grootte van die data en hoeveel daarvan moet fisies ingesamel word (*sien hieronder*).
  • Wat is die afhaaltyd vir een rekord en hoe lank moet jy wag voordat jy die tweede kan afhaal?
  • Oorweeg om kode te skryf wat die staat red en 'n herbegin begin wanneer (nie as) alles misluk nie.
  • Bepaal of ons magtiging benodig en stel die tyd in om toegang via die API te verkry.
  • Stel die aantal foute as 'n funksie van datakompleksiteit - evalueer vir 'n spesifieke taak: struktuur, hoeveel transformasies, wat en hoe om te onttrek.
  • Los netwerkfoute en probleme met nie-standaard projekgedrag op.
  • Evalueer of die vereiste funksies in die dokumentasie is en indien nie, dan hoe en hoeveel nodig is vir 'n oplossing.

Die belangrikste is dat om tyd te skat - jy moet eintlik tyd en moeite spandeer aan "verkenning van krag" - eers dan sal jou beplanning voldoende wees. Daarom, maak nie saak hoeveel jy gedruk word om te sê "hoe lank neem dit om data in te samel" - koop vir jouself tyd vir 'n voorlopige ontleding en argumenteer met hoeveel die tyd sal wissel na gelang van die werklike parameters van die probleem.

En nou sal ons spesifieke voorbeelde demonstreer waar sulke parameters sal verander.

Sleutelpunt: Die skatting is gebaseer op 'n ontleding van sleutelfaktore wat die omvang en kompleksiteit van die werk beïnvloed.

Raai-gebaseerde skatting is 'n goeie benadering wanneer die funksionele elemente klein genoeg is en daar nie baie faktore is wat die ontwerp van die probleem noemenswaardig kan beïnvloed nie. Maar in die geval van 'n aantal Data Science-probleme, word sulke faktore uiters talryk en so 'n benadering word onvoldoende.

Vergelyking van Reddit-gemeenskappe

Kom ons begin met die eenvoudigste geval (soos dit later blyk). Oor die algemeen, om heeltemal eerlik te wees, het ons 'n byna ideale geval, kom ons kyk na ons kompleksiteitkontrolelys:

  • Daar is 'n netjiese, duidelike en gedokumenteerde API.
  • Dit is uiters eenvoudig en die belangrikste is dat 'n teken outomaties verkry word.
  • Daar is luislang-omhulsel - met baie voorbeelde.
  • 'n Gemeenskap wat data op reddit ontleed en insamel (selfs vir YouTube-video's wat verduidelik hoe om luislang-omhulsel te gebruik) Byvoorbeeld.
  • Die metodes wat ons benodig, bestaan ​​heel waarskynlik in die API. Boonop lyk die kode kompak en skoon, hieronder is 'n voorbeeld van 'n funksie wat opmerkings op 'n plasing insamel.

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

Geneem vanaf hierdie 'n seleksie van gerieflike hulpmiddels vir wikkel.

Ten spyte van die feit dat dit die beste geval is, is dit steeds die moeite werd om 'n aantal belangrike faktore uit die werklike lewe in ag te neem:

  • API-limiete - ons word gedwing om data in groepe te neem (slaap tussen versoeke, ens.).
  • Versamelingstyd - vir 'n volledige ontleding en vergelyking, sal jy aansienlike tyd moet opsy sit net vir die spinnekop om deur die subreddit te loop.
  • Die bot moet op 'n bediener loop - jy kan dit nie net op jou skootrekenaar laat loop, dit in jou rugsak sit en aangaan met jou besigheid nie. So ek het alles op 'n VPS gehardloop. Deur die promosiekode habrahabr10 te gebruik, kan jy nog 10% van die koste bespaar.
  • Die fisiese ontoeganklikheid van sommige data (dit is sigbaar vir administrateurs of is te moeilik om te versamel) - dit moet in ag geneem word; in beginsel kan nie alle data betyds ingesamel word nie.
  • Netwerkfoute: Netwerk is 'n pyn.
  • Dit is lewende regte data - dit is nooit suiwer nie.

Natuurlik is dit nodig om hierdie nuanses in die ontwikkeling in te sluit. Spesifieke ure/dae hang af van ontwikkelingservaring of ondervinding om aan soortgelyke take te werk, maar ons sien dat hier die taak suiwer ingenieurswese is en nie bykomende liggaamsbewegings vereis om op te los nie - alles kan baie goed geassesseer, geskeduleer en gedoen word.

Vergelyking van Habr-afdelings

Kom ons gaan oor na 'n meer interessante en nie-triviale geval van vergelyking van drade en/of gedeeltes van Habr.

Kom ons kyk na ons kompleksiteitskontrolelys - hier, om elke punt te verstaan, sal jy 'n bietjie in die taak self moet delf en eksperimenteer.

  • Aanvanklik dink jy daar is 'n API, maar daar is nie. Ja, ja, Habr het 'n API, maar dit is net nie toeganklik vir gebruikers nie (of dalk werk dit glad nie).
  • Dan begin jy net html ontleed - "invoerversoeke", wat kan verkeerd gaan?
  • Hoe om in elk geval te ontleed? Die eenvoudigste en mees gebruikte benadering is om oor ID's te herhaal, let daarop dat dit nie die doeltreffendste is nie en verskillende gevalle sal moet hanteer - hier is 'n voorbeeld van die digtheid van werklike ID's onder alle bestaandes.

    Wat kan verkeerd gaan met Data Science? Data-insameling
    Geneem vanaf hierdie artikel.

  • Rou data toegedraai in HTML bo-op die web is 'n pyn. Byvoorbeeld, jy wil die gradering van 'n artikel versamel en stoor: jy het die telling uit die html geskeur en besluit om dit as 'n nommer te stoor vir verdere verwerking: 

    1) int(telling) gooi 'n fout: aangesien daar op Habré 'n minus is, soos byvoorbeeld in die reël "–5" - dit is 'n en streep, nie 'n minusteken nie (onverwags, reg?), dus by een of ander tyd moes ek die ontleder lewendig maak met so 'n verskriklike oplossing.

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

    Daar is dalk glad geen datum, pluspunte en minusse nie (soos ons hierbo in die check_date-funksie sien, het dit gebeur).

    2) Onontsnapte spesiale karakters - hulle sal kom, jy moet voorbereid wees.

    3) Die struktuur verander na gelang van die tipe pos.

    4) Ou plasings kan 'n **vreemde struktuur** hê.

  • In wese sal fouthantering en wat dalk of nie mag gebeur nie hanteer moet word en jy kan nie met sekerheid voorspel wat verkeerd gaan loop en hoe anders die struktuur kan wees en wat waar sal afval nie - jy sal maar moet probeer in ag neem die foute wat die ontleder gooi.
  • Dan besef jy dat jy in verskeie drade moet ontleed, anders sal die ontleed in een dan 30+ uur neem (dit is suiwer die uitvoeringstyd van 'n reeds werkende enkeldraadontleder, wat slaap en nie onder enige verbod val nie). IN hierdie artikel, het dit op 'n sekere punt gelei tot 'n soortgelyke skema:

Wat kan verkeerd gaan met Data Science? Data-insameling

Totale kontrolelys volgens kompleksiteit:

  • Werk met die netwerk en html-ontleding met iterasie en soek volgens ID.
  • Dokumente van heterogene struktuur.
  • Daar is baie plekke waar die kode maklik kan val.
  • Dit is nodig om || te skryf kode.
  • Die nodige dokumentasie, kodevoorbeelde en/of gemeenskap ontbreek.

Die geskatte tyd vir hierdie taak sal 3-5 keer hoër wees as vir die insameling van data van Reddit.

Vergelyking van Odnoklassniki-groepe

Kom ons gaan aan na die mees tegnies interessante geval wat beskryf is. Vir my was dit interessant juis omdat dit met die eerste oogopslag nogal triviaal lyk, maar dit blyk glad nie so te wees nie - sodra jy 'n stokkie daarvoor steek.

Kom ons begin met ons moeilikheidskontrolelys en let daarop dat baie van hulle baie moeiliker sal wees as wat hulle aanvanklik lyk:

  • Daar is 'n API, maar dit het amper nie die nodige funksies nie.
  • Vir sekere funksies moet jy toegang per pos versoek, dit wil sê, die toekenning van toegang is nie onmiddellik nie.
  • Dit is verskriklik gedokumenteer (om mee te begin is Russiese en Engelse terme oral deurmekaar, en heeltemal inkonsekwent - soms moet jy net raai wat hulle iewers van jou wil hê) en boonop is die ontwerp nie geskik om data te bekom nie, bv. , die funksie wat ons nodig het.
  • Vereis 'n sessie in die dokumentasie, maar gebruik dit nie eintlik nie - en daar is geen manier om al die ingewikkeldhede van die API-modusse te verstaan ​​nie, behalwe om rond te kyk en te hoop iets sal werk.
  • Daar is geen voorbeelde en geen gemeenskap nie; die enigste punt van ondersteuning in die insameling van inligting is 'n klein wrapper in Python (sonder baie voorbeelde van gebruik).
  • Selenium blyk die mees werkbare opsie te wees, aangesien baie van die nodige data toegesluit is.
    1) Dit wil sê, magtiging geskied deur middel van 'n fiktiewe gebruiker (en registrasie per hand).

    2) Met Selenium is daar egter geen waarborge vir korrekte en herhaalbare werk nie (ten minste in die geval van ok.ru vir seker).

    3) Die Ok.ru-webwerf bevat JavaScript-foute en tree soms vreemd en inkonsekwent op.

    4) Jy moet paginering doen, elemente laai, ens.

    5) API-foute wat die omhulsel gee, sal ongemaklik hanteer moet word, byvoorbeeld, so ('n stukkie eksperimentele 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

    My gunsteling fout was:

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

    6) Uiteindelik lyk Selenium + API na die mees rasionele opsie.

  • Dit is nodig om die staat te stoor en die stelsel te herbegin, baie foute te hanteer, insluitend inkonsekwente gedrag van die webwerf - en hierdie foute is nogal moeilik om voor te stel (tensy jy natuurlik ontleders professioneel skryf).

Die voorwaardelike tydskatting vir hierdie taak sal 3-5 keer hoër wees as vir die insameling van data van Habr. Ten spyte van die feit dat ons in die geval van Habr 'n frontale benadering met HTML-ontleding gebruik, en in die geval van OK kan ons op kritieke plekke met die API werk.

Bevindinge

Maak nie saak hoeveel daar van jou verwag word om die spertye "op die plek" (ons beplan vandag!) van 'n lywige dataverwerking pyplynmodule te skat, die uitvoeringstyd is amper nooit moontlik om selfs kwalitatief te skat sonder om die taakparameters te ontleed nie.

Op 'n effens meer filosofiese noot werk ratse skattingstrategieë goed vir ingenieurstake, maar probleme wat meer eksperimenteel en in 'n sekere sin "kreatief" en verkennend is, dit wil sê minder voorspelbaar, het probleme, soos in die voorbeelde van soortgelyke onderwerpe, wat ons hier bespreek het.

Data-insameling is natuurlik net 'n uitstekende voorbeeld - dit is gewoonlik 'n ongelooflike eenvoudige en tegnies ongekompliseerde taak, en die duiwel is dikwels in die besonderhede. En dit is juis op hierdie taak dat ons die hele reeks moontlike opsies kan wys vir wat kan verkeerd loop en presies hoe lank die werk kan neem.

As jy kyk na die kenmerke van die taak sonder bykomende eksperimente, dan lyk Reddit en OK soortgelyk: daar is 'n API, 'n luislang-omhulsel, maar in wese is die verskil groot. Te oordeel aan hierdie parameters, lyk Habr se pars meer ingewikkeld as OK - maar in die praktyk is dit heeltemal die teenoorgestelde, en dit is presies wat uitgevind kan word deur eenvoudige eksperimente uit te voer om die parameters van die probleem te ontleed.

Volgens my ervaring is die mees doeltreffende benadering om rofweg die tyd te skat wat u benodig vir die voorlopige ontleding self en eenvoudige eerste eksperimente, deur die dokumentasie te lees - dit sal u toelaat om 'n akkurate skatting vir die hele werk te gee. In terme van die gewilde ratse metodologie, vra ek u om 'n kaartjie te skep vir "beraming van taakparameters", op grond waarvan ek 'n assessering kan gee van wat binne die "sprint" bereik kan word en 'n meer akkurate skatting vir elke taak.

Daarom blyk die mees doeltreffende argument een te wees wat 'n "nie-tegniese" spesialis sal wys hoeveel tyd en hulpbronne sal wissel na gelang van parameters wat nog geassesseer moet word.

Wat kan verkeerd gaan met Data Science? Data-insameling

Bron: will.com

Voeg 'n opmerking