ProHoster > Blogg > Administration > Vad kan gÄ fel med Data Science? Datasamling

Vad kan gÄ fel med Data Science? Datasamling

Vad kan gÄ fel med Data Science? Datasamling
Idag finns det 100500 kurser i Data Science, och det Àr lÀnge kÀnt att man kan tjÀna mest pengar pÄ Data Science genom kurser i Data Science (varför grÀva nÀr man kan sÀlja spadar?). Den största nackdelen med dessa kurser Àr att de inte har nÄgot att göra med verkligt arbete: ingen kommer att ge dig rena, bearbetade data i rÀtt format. Och nÀr du gÄr ut frÄn kurserna och börjar lösa en riktig uppgift, dyker det upp mÄnga nyanser.

DÀrför startar vi en serie artiklar "Vad kan gÄ fel med Data Science", baserade pÄ verkliga hÀndelser som har hÀnt mig, mina vÀnner och kollegor. Vi kommer att analysera typiska Data Science-uppgifter med verkliga exempel: hur det verkligen gÄr till. Vi börjar idag med uppgiftshantering av datasamling.

Och det första som folk snubblar över nÀr de börjar arbeta med verkliga data Àr just sjÀlva insamlingen av dessa relevanta data. Huvudbudskapet i den hÀr artikeln:

Vi underskattar systematiskt tid, resurser och insatser för insamling, rengöring och förberedelse av data.

Och viktigast av allt, vi kommer att diskutera vad man ska göra för att undvika detta.

Enligt olika uppskattningar tar rengöring, omvandling, databehandling, feature engineering osv 80-90% av tiden, medan analysen tar 10-20%, medan nÀstan allt studiematerial fokuserar enbart pÄ analys.

LÄt oss bryta ner ett enkelt analytiskt problem i tre varianter som ett typiskt exempel och se vilka 'försvÄrande omstÀndigheter' som kan förekomma.

Och som exempel kommer vi Äterigen att betrakta sÄdana variationer av datasamlingens uppgift och jÀmförelse av samhÀllen för:

  1. TvÄ subreddits pÄ Reddit
  2. TvÄ avsnitt pÄ Habré
  3. TvÄ grupper pÄ Odnoklassniki

Hypotetisk metod inom teorin

Öppna webbplatsen och lĂ€s exempel, om det Ă€r förstĂ„eligt, avsĂ€tta nĂ„gra timmar för lĂ€sning, nĂ„gra timmar för kod utifrĂ„n exemplen och felsökning. LĂ€gg till nĂ„gra timmar för insamling. LĂ€gg till nĂ„gra timmar som buffert (multiplicera med tvĂ„ och lĂ€gg till N timmar).

HuvudpoÀngen: tidsbedömningen baseras pÄ antaganden och gissningar om hur lÄng tid detta kommer att ta.

Analysen av tiden bör inledas med att bedöma följande parametrar för den hypotetiska uppgiften som beskrivits ovan:

  • Vad Ă€r datastorleken och hur mycket av den behöver samlas fysiskt (*se nedan*).
  • Hur lĂ„ng tid tar det att samla in en post och hur lĂ€nge mĂ„ste man vĂ€nta innan man kan samla in nĂ€sta.
  • Inkludera kodskrivning för att spara tillstĂ„nd och pĂ„börja omstart nĂ€r (inte om) allt kraschar.
  • Ta reda pĂ„ om vi behöver autentisering och inkludera tid för att fĂ„ Ă„tkomst via API.
  • Inkludera antalet fel som en funktion av datakomplexitet — bedöm detta utifrĂ„n den specifika uppgiften: struktur, hur mĂ„nga transformationer, vad och hur vi extraherar.
  • Inkludera nĂ€tverksfel och problem med oönskat beteende i projektet.
  • Bedöm om de nödvĂ€ndiga funktionerna finns i dokumentationen, och om de inte gör det, hur mycket som behövs för en workaround.

Det viktigaste Ă€r att för tidsbedömning — ni mĂ„ste verkligen avsĂ€tta tid och anstrĂ€ngningar för 'reconnaissance by combat' — endast dĂ„ blir er planering adekvat. SĂ„ oavsett hur mycket ni pressas att sĂ€ga 'hur lĂ€nge tar det att samla in data' — ge er tid för en föranalys och argumentera för hur mycket tiden kan variera beroende pĂ„ uppgiftens verkliga parametrar.

Och nu kommer vi att visa konkreta exempel dÀr sÄdana parametrar kommer att variera.

Nyckelpunkten: bedömningen baseras pÄ analys av de huvudsakliga faktorer som pÄverkar omfattningen och komplexiteten av arbetet.

En gissningsbaserad bedömning Àr en bra metod nÀr de funktionella elementen Àr tillrÀckligt smÄ och det inte finns sÄ mÄnga faktorer som kan pÄverka uppgiftens struktur avsevÀrt. Men i fallet med vissa Data Science-uppgifter blir dessa faktorer extremt mÄnga och en sÄdan metod blir otillrÀcklig.

JÀmförelse av Reddit-gemenskaper

LĂ„t oss börja med det enklaste fallet (som senare visar sig vara fallet). Ärligt talat, nĂ€r vi ser pĂ„ det sĂ„ har vi nĂ€stan ett perfekt fall som vi ska kontrollera vĂ„r svĂ„righetschecklista med:

  • Det finns ett ordnat, tydligt och vĂ€ldokumenterat API.
  • Mycket enkelt och framför allt fĂ„r vi automatiskt en token.
  • Det finns python wrapper — med massor av exempel.
  • Gemenskapen som sysslar med analys och insamling av data pĂ„ Reddit (inklusive YouTube-videor som förklarar hur man anvĂ€nder python wrapper) hĂ€r Ă€r ett exempel.
  • De metoder vi behöver finns troligen i API:et. Dessutom ser koden kompakt och ren ut, nedan Ă€r ett exempel pĂ„ en funktion som samlar in kommentarer pĂ„ ett inlĂ€gg.

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

Taget frÄn denna en samling anvÀndbara verktyg för inslagning.

Trots att vi har det bÀsta scenariot hÀr, Àr det ÀndÄ viktigt att ta hÀnsyn till ett antal viktiga faktorer frÄn verkliga livet:

  • API-grĂ€nser — vi mĂ„ste hĂ€mta data i batcher (pausa mellan förfrĂ„gningarna osv.).
  • Insamlingstiden — för en fullstĂ€ndig analys och jĂ€mförelse mĂ„ste vi avsĂ€tta betydande tid för att bara lĂ„ta spindeln gĂ„ igenom subreddit.
  • Boten mĂ„ste köras pĂ„ en server — du kan inte bara starta den pĂ„ din bĂ€rbara dator, stoppa den i vĂ€skan och Ă„ka ivĂ€g. DĂ€rför körde jag allt pĂ„ en VPS. Med rabattkoden habrahabr10 kan du spara ytterligare 10% pĂ„ kostnaden.
  • Fysisk otillgĂ€nglighet av vissa data (de Ă€r synliga för administratörer eller Ă€r för svĂ„ra att samla in) — detta mĂ„ste beaktas, inte alla data kan i princip samlas in pĂ„ rimlig tid.
  • NĂ€tverksfel: arbete med nĂ€tverk Ă€r smĂ€rtsamt.
  • Detta Ă€r riktiga levande data — de Ă€r aldrig rena.

SjĂ€lvklart mĂ„ste man ta hĂ€nsyn till de angivna nuanserna i utvecklingen. De specifika timmarna/dagarna beror pĂ„ utvecklingserfarenhet eller erfarenhet av liknande uppgifter, men vi ser att uppgiften hĂ€r Ă€r uteslutande ingenjörsmĂ€ssig och inte krĂ€ver nĂ„gra ytterligare Ă„tgĂ€rder för att lösa — allt kan bedömas, beskrivas och göras mycket bra.

JÀmförelse av Habr-sektioner

Vi gÄr vidare till ett mer intressant och icke trivialt fall av jÀmförelse mellan flöden och/eller Habr-sektioner.

Vi kommer att kontrollera vĂ„r svĂ„righetschecklista — hĂ€r, för att förstĂ„ varje punkt, mĂ„ste man redan experimentera med sjĂ€lva uppgiften och göra tester.

  • Först tror du att det finns ett API, men det gör det inte. Ja, Habr har ett API, men det Ă€r bara inte tillgĂ€ngligt för anvĂ€ndare (eller kanske fungerar det inte alls).
  • Sedan börjar du helt enkelt att parsa html — "import requests", vad kan gĂ„ fel?
  • Hur parsar man överhuvudtaget? Det enklaste och mest anvĂ€nda tillvĂ€gagĂ„ngssĂ€ttet Ă€r att iterera över ID, vi noterar att det inte Ă€r det mest effektiva och vi kommer att behöva hantera olika fall — hĂ€r Ă€r ett exempel pĂ„ densiteten av verkliga ID bland alla som finns.

    Vad kan gÄ fel med Data Science? Datasamling
    Taget frÄn denna artiklar.

  • RĂ„data som Ă€r insvept i HTML över nĂ€tverket Ă€r en plĂ„ga. Till exempel, om du vill samla in och spara artikels poĂ€ng: du har extraherat poĂ€ng frĂ„n HTML och beslutat att spara det som ett nummer för vidare behandling: 

    1) int(score) ger ett fel: eftersom det pĂ„ HabrĂ© Ă€r minus, som i strĂ€ngen "–5" — det Ă€r ett kort bindestreck, inte minus tecken (överraskande, eller hur?), sĂ„ vid nĂ„got tillfĂ€lle fick man vĂ€cka upp parsern med en sĂ„dan hemsk fix.

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

    Det kan hÀnda att det inte alls finns nÄgra datum, plus eller minus (som vi ser ovan i funktionen check_date, och sÄdant har hÀnt).

    2) Oskyddade specialtecken — de kommer, sĂ„ man mĂ„ste vara beredd.

    3) Strukturen förÀndras beroende pÄ typen av inlÀgg.

    4) Gamla inlÀgg kan ha **konstig struktur**.

  • I grunden mĂ„ste felhantering och vad som kan eller inte kan hĂ€nda hanteras, och man kan inte förutsĂ€ga vad som kommer att gĂ„ fel och hur strukturen kan se ut, man fĂ„r helt enkelt försöka och ta hĂ€nsyn till de fel som parsers ger.
  • Sen inser du att du behöver parsa i flera trĂ„dar, annars tar det över 30 timmar att parsa i en enda trĂ„d (detta Ă€r rent exekveringstid för en fungerande entrĂ„dsparser som sover och inte hamnar under nĂ„gra bannlysningar). I denna artikeln ledde det vid nĂ„got tillfĂ€lle till ett sĂ„dant schema:

Vad kan gÄ fel med Data Science? Datasamling

HÀr Àr checklistan över svÄrigheterna:

  • Arbeta med nĂ€tverket och parsa HTML med iteration och ID-överskrift.
  • Dokument med heterogen struktur.
  • MĂ„nga stĂ€llen dĂ€r koden lĂ€tt kan falla.
  • Det Ă€r nödvĂ€ndigt att skriva || kod.
  • Det saknas nödvĂ€ndig dokumentation, kodexempel och/eller samhĂ€lle.

Den tidsmÀssiga bedömningen för denna uppgift kommer att vara 3-5 gÄnger större Àn för att samla in data frÄn Reddit.

JÀmförelse av grupper i Odnoklassniki

LĂ„t oss gĂ„ vidare till det mest tekniskt intressanta fallet bland de som beskrivs. För mig var det intressant just för att det vid första anblick verkar ganska trivialt, men sĂ„ Ă€r det verkligen inte — sĂ„ fort du petar pĂ„ det med en pinne.

Vi börjar med vÄr svÄrighetschecklista och noterar att mÄnga av dem kommer att visa sig vara mycket svÄrare Àn de verkar i början:

  • API finns, men nĂ€stan helt saknar de nödvĂ€ndiga funktionerna.
  • Vissa funktioner mĂ„ste begĂ€ras Ă„tkomst till via e-post, sĂ„ tilldelningen av Ă„tkomst Ă€r inte omedelbar.
  • Det Ă€r fruktansvĂ€rt dokumenterat (för att börja med, blandas ryska och engelska termer överallt, och det görs helt inkonsekvent — ibland mĂ„ste du helt enkelt gissa vad de vill ha frĂ„n dig nĂ„gonstans) och dessutom passar det inte designmĂ€ssigt för att hĂ€mta data, till exempel den funktion vi behöver.
  • Det krĂ€ver session i dokumentationen, men i praktiken anvĂ€nder det inte detta — och det finns inget sĂ€tt att förstĂ„ alla detaljer i API-lĂ€gena, förutom att pröva sig fram och hoppas att nĂ„got fungerar.
  • Det finns inga exempel eller community, den enda stödpunkten för att samla information Ă€r en liten wrapper i Python (utan ett stort antal exempel pĂ„ anvĂ€ndning).
  • Det mest fungerande alternativet verkar vara Selenium, eftersom mĂ„nga av de nödvĂ€ndiga uppgifterna Ă€r lĂ„sta.
    1) Det vill sÀga att autentisering sker genom en skenbar anvÀndare (och registrering för hand).

    2) Men med Selenium finns det inga garantier för korrekt och repeterbar funktion (i alla fall i fallet med ok.ru definitivt).

    3) Ok.ru-webbplatsen innehÄller JavaScript-fel och beter sig ibland konstigt och inkonsekvent.

    4) Man mÄste hantera paginering, laddning av element osv ...

    5) API-fel som wrapper ger mÄste hanteras pÄ ett hackigt sÀtt, till exempel sÄ hÀr (ett avsnitt av experimentell kod):

    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

    Min favoritfel var:

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

    6) I slutÀndan verkar kombinationen av Selenium + API vara det mest rationella alternativet.

  • Det krĂ€vs bevarande av tillstĂ„nd och omstart av systemet, hantering av mĂ„nga fel, inklusive inkonsekvent beteende frĂ„n webbplatsen — dessutom Ă€r dessa fel ganska svĂ„ra att förestĂ€lla sig (om du inte professionellt skriver parsers, förstĂ„s).

Den uppskattade tiden för denna uppgift kommer att vara 3-5 gÄnger lÀngre Àn för att samla in data frÄn Habr. Trots att vi i fallet med Habr anvÀnder en rak approach med HTML-parsing, kan vi i kritiska lÀgen arbeta med API i fallet med OK.

Slutsatser

Oavsett hur mycket ni kanske blir ombedda att ge en tidsuppskattning "pÄ plats" (vi har ju planering idag!) för det omfattande databehandlingsmodulen, Àr det praktiskt taget aldrig möjligt att bedöma utförandet kvalitativt utan en analys av uppgiftsparametrarna.

Om man pratar lite mer filosofiskt, sÄ passar strategier för bedömningar inom agile bra för ingenjörsuppgifter, men med uppgifter som Àr mer experimentella och pÄ nÄgot sÀtt "kreativa" och forskande, det vill sÀga mindre förutsÀgbara, uppstÄr svÄrigheter, liknande de exempel vi diskuterat hÀr.

SjĂ€lvklart Ă€r datainsamling en tydlig illustrativ exempel — vanligtvis verkar det vara en otroligt enkel och tekniskt okomplicerad uppgift, och just i detaljerna hĂ€r döljer sig ofta djĂ€vulen. Och just pĂ„ detta uppdrag kan man visa hela spektrumet av möjliga alternativ pĂ„ vad som kan gĂ„ fel och hur mycket arbetet kan dra ut pĂ„ tiden.

Om man snabbt kollar pĂ„ uppgiftens egenskaper utan ytterligare experiment, sĂ„ ser Reddit och OK liknande ut: det finns API, python wrapper, men i sjĂ€lva verket Ă€r skillnaden enorm. Om man bedömer utifrĂ„n dessa parametrar, sĂ„ verkar parsing av Habr vara mer komplicerat Ă€n OK — men i praktiken Ă€r det precis tvĂ€rtom och det kan man avgöra genom att utföra enkla experiment för att analysera uppgiftens parametrar.

UtifrĂ„n min erfarenhet Ă€r den mest effektiva metoden att göra en ungefĂ€rlig tidsuppskattning för den inledande analysen och de första experimenten, lĂ€sningen av dokumentationen — det Ă€r dessa som gör att du kan ge en exakt uppskattning för hela arbetet. I termer av den populĂ€ra agile-metodologin — jag ber om att fĂ„ ett Ă€rende under "bedömning av uppgiftens parametrar", baserat pĂ„ vilket jag kan ge en uppskattning av vad som kan genomföras inom ramen för "sprinten" och ge en mer exakt bedömning för varje uppgift.

DÀrför verkar det mest effektiva argumentet vara att förklara för en "icke-teknisk" specialist hur mycket tid och resurser som kan variera beroende pÄ parametrarna som fortfarande ska bedömas.

Vad kan gÄ fel med Data Science? Datasamling

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster