Vad kan gå fel med Data Science? Datainsamling

Idag finns det 100500 XNUMX Data Science-kurser och det har länge varit känt att mest pengar inom Data Science kan tjänas genom Data Science-kurser (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 ren, bearbetad data i det format som krävs. Och när du lämnar kursen och börjar lösa ett verkligt problem kommer många nyanser fram.

Därför startar vi en serie anteckningar "Vad kan gå fel med Data Science", baserade på verkliga händelser som hände mig, mina kamrater och kollegor. Vi kommer att analysera typiska datavetenskapliga uppgifter med hjälp av verkliga exempel: hur detta faktiskt händer. Låt oss börja idag med uppgiften att samla in uppgifter.

Och det första som folk snubblar över när de börjar arbeta med riktig data är att faktiskt samla in denna data som är mest relevant för oss. Huvudbudskapet i denna artikel:

Vi underskattar systematiskt den tid, resurser och ansträngning som krävs för att samla in, rensa och förbereda data.

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

Enligt olika uppskattningar tar städning, transformation, databearbetning, funktionsteknik etc. 80-90% av tiden och analys 10-20%, medan nästan allt utbildningsmaterial enbart fokuserar på analys.

Låt oss titta på ett enkelt analytiskt problem i tre versioner som ett typiskt exempel och se vad "försvårande omständigheter" är.

Och som ett exempel, återigen, kommer vi att överväga liknande varianter av uppgiften att samla in data och jämföra gemenskaper för:

1. Två Reddit-subreddits
2. Två avdelningar av Habr
3. Två grupper av Odnoklassniki

Betingat förhållningssätt i teorin

Öppna sidan och läs exemplen, om det är tydligt, avsätt några timmar för läsning, några timmar för koden med hjälp av exemplen och felsökning. Lägg till några timmar för insamling. Kasta in några timmar i reserv (multiplicera med två och lägg till N timmar).

Nyckelpunkt: Tidsuppskattningar baseras på antaganden och gissningar om hur lång tid det kommer att ta.

Det är nödvändigt att börja tidsanalysen genom att uppskatta följande parametrar för det villkorliga problemet som beskrivs ovan:

• Vad är storleken på data och hur mycket av den behöver samlas in fysiskt (*se nedan*).
• Vad är hämttiden för en skiva och hur länge måste du vänta innan du kan hämta den andra?
• Överväg att skriva kod som sparar tillståndet och startar en omstart när (inte om) allt misslyckas.
• Ta reda på om vi behöver auktorisering och ställ in tiden för att få åtkomst via API:et.
• Ställ in antalet fel som en funktion av datakomplexitet - utvärdera för en specifik uppgift: struktur, hur många transformationer, vad och hur man extraherar.
• Åtgärda nätverksfel och problem med icke-standardiserat projektbeteende.
• Bedöm om de nödvändiga funktionerna finns i dokumentationen och om inte, hur och hur mycket som behövs för en lösning.

Det viktigaste är att för att uppskatta tid - du behöver faktiskt lägga tid och kraft på "rekognosering i kraft" - först då kommer din planering att vara tillräcklig. Därför, oavsett hur mycket du pressas att säga "hur lång tid tar det att samla in data" - köp dig lite tid för en preliminär analys och argumentera med hur mycket tiden kommer att variera beroende på de verkliga parametrarna för problemet.

Och nu kommer vi att visa specifika exempel där sådana parametrar kommer att ändras.

Nyckelpunkt: Uppskattningen baseras på en analys av nyckelfaktorer som påverkar arbetets omfattning och komplexitet.

Gissningsbaserad uppskattning är ett bra tillvägagångssätt när de funktionella elementen är tillräckligt små och det inte finns många faktorer som nämnvärt kan påverka utformningen av problemet. Men i fallet med ett antal Data Science-problem blir sådana faktorer extremt många och ett sådant tillvägagångssätt blir otillräckligt.

Jämförelse av Reddit-gemenskaper

Låt oss börja med det enklaste fallet (som det visar sig senare). I allmänhet, för att vara helt ärlig, har vi ett nästan perfekt fall, låt oss kolla vår komplexitetschecklista:

• Det finns ett snyggt, tydligt och dokumenterat API.
• Det är extremt enkelt och viktigast av allt, en token erhålls automatiskt.
• Det finns pytonomslag – med massor av exempel.
• En community som analyserar och samlar in data på reddit (även till YouTube-videor som förklarar hur man använder python-wrapper) Till exempel.
• De metoder vi behöver finns med största sannolikhet i API:t. 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()

Tagen från detta ett urval av praktiska verktyg för inpackning.

Trots att detta är det bästa fallet är det fortfarande värt att ta hänsyn till ett antal viktiga faktorer från det verkliga livet:

• API-gränser - vi är tvungna att ta data i omgångar (vila mellan förfrågningar etc.).
• Insamlingstid - för en fullständig analys och jämförelse måste du avsätta betydande tid bara för spindeln att gå igenom subreddit.
• Boten måste köras på en server – du kan inte bara köra den på din bärbara dator, lägga den i ryggsäcken och ägna dig åt ditt företag. Så jag körde allt på en VPS. Genom att använda kampanjkoden habrahabr10 kan du spara ytterligare 10 % av kostnaden.
• Den fysiska otillgängligheten för vissa uppgifter (de är synliga för administratörer eller är för svåra att samla in) - detta måste beaktas, i princip kan inte all data samlas in i tillräcklig tid.
• Nätverksfel: Nätverk är jobbigt.
• Det här är levande verklig data - den är aldrig ren.

Naturligtvis är det nödvändigt att ta med dessa nyanser i utvecklingen. Specifika timmar/dagar beror på utvecklingserfarenhet eller erfarenhet av att arbeta med liknande uppgifter, dock ser vi att här är uppgiften rent teknisk och kräver inga ytterligare kroppsrörelser att lösa – allt kan mycket väl bedömas, schemaläggas och göras.

Jämförelse av Habr-sektioner

Låt oss gå vidare till ett mer intressant och icke-trivialt fall där man jämför trådar och/eller delar av Habr.

Låt oss kolla vår komplexitetschecklista - här, för att förstå varje punkt, måste du gräva lite i själva uppgiften och experimentera.

• Först tror du att det finns ett API, men det finns det inte. Ja, ja, Habr har ett API, men det är helt enkelt inte tillgängligt för användare (eller kanske det inte fungerar alls).
• Sedan börjar du bara analysera html - "importförfrågningar", vad kan gå fel?
• Hur analyserar man ändå? Det enklaste och mest använda tillvägagångssättet är att iterera över ID:n, observera att det inte är det mest effektiva och kommer att behöva hantera olika fall - här är ett exempel på tätheten av riktiga ID:n bland alla befintliga.

  
  Tagen från detta artikeln.

• Rådata insvept i HTML ovanpå webben är jobbigt. Du vill till exempel samla in och spara betyget för en artikel: du tog bort poängen ur HTML-koden och bestämde dig för att spara den som ett nummer för vidare bearbetning: 

  1) int(score) ger ett fel: eftersom det på Habré finns ett minus, som t.ex. på raden “–5” - detta är ett streck, inte ett minustecken (oväntat, eller hur?), så vid någon gång var jag tvungen att väcka parsern till liv med en sådan fruktansvärd 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 kanske inte finns något datum, plus och minus alls (som vi ser ovan i check_date-funktionen hände detta).

  2) Oundrymda specialtecken - de kommer, du måste vara förberedd.

  3) Strukturen ändras beroende på typ av inlägg.

  4) Gamla inlägg kan ha en **konstig struktur**.

• I huvudsak måste felhantering och vad som kan hända eller inte hända hanteras och du kan inte säkert förutse vad som kommer att gå fel och hur annars strukturen kan vara och vad som kommer att falla av var - du måste bara försöka ta hänsyn till felen som analyseraren kastar.
• Då inser du att du behöver tolka i flera trådar, annars tar parsning i en 30+ timmar (detta är rent exekveringstiden för en redan fungerande enkeltrådad parser, som sover och inte faller under några förbud). I detta artikel, ledde detta någon gång till ett liknande schema:

Total checklista efter komplexitet:

• Arbeta med nätverket och html-tolka med iteration och sökning med ID.
• Dokument av heterogen struktur.
• Det finns många ställen där koden lätt kan falla.
• Det är nödvändigt att skriva || koda.
• Nödvändig dokumentation, kodexempel och/eller community saknas.

Den beräknade tiden för denna uppgift kommer att vara 3-5 gånger högre än för att samla in data från Reddit.

Jämförelse av Odnoklassniki-grupper

Låt oss gå vidare till det mest tekniskt intressanta fallet som beskrivs. För mig var det intressant just för att det vid första anblicken ser ganska trivialt ut, men det visar sig inte alls vara så - så fort du sticker en pinne i det.

Låt oss börja med vår checklista för svårigheter och notera att många av dem kommer att visa sig vara mycket svårare än de först ser ut:

• Det finns ett API, men det saknar nästan helt de nödvändiga funktionerna.
• Till vissa funktioner behöver du begära åtkomst via e-post, det vill säga beviljandet av åtkomst sker inte omedelbart.
• Det är fruktansvärt dokumenterat (till att börja med blandas ryska och engelska termer ihop överallt, och helt inkonsekvent - ibland behöver du bara gissa vad de vill ha av dig någonstans) och dessutom är designen inte lämplig för att skaffa data t.ex. , den funktion vi behöver.
• Kräver en session i dokumentationen, men använder den faktiskt inte – och det finns inget sätt att förstå alla krångligheterna i API-lägena annat än att leta runt och hoppas att något kommer att fungera.
• Det finns inga exempel och ingen gemenskap, den enda stödpunkten för att samla in information är en liten omslag i Python (utan många exempel på användning).
• Selen verkar vara det mest fungerande alternativet, eftersom många av de nödvändiga uppgifterna är låsta.
  1) Dvs auktorisering sker genom en fiktiv användare (och registrering för hand).

  2) Men med Selenium finns det inga garantier för korrekt och repeterbart arbete (åtminstone i fallet med ok.ru säkert).

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

  4) Du måste göra paginering, ladda element, etc...

  5) API-fel som omslaget ger kommer att behöva hanteras besvärligt, till exempel så här (en bit 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
  

  Mitt favoritfel var:

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

  6) I slutändan ser Selenium + API ut som det mest rationella alternativet.

• Det är nödvändigt att spara tillståndet och starta om systemet, hantera många fel, inklusive inkonsekvent beteende på webbplatsen - och dessa fel är ganska svåra att föreställa sig (såvida du inte skriver tolkar professionellt, förstås).

Den villkorade tidsuppskattningen för denna uppgift kommer att vara 3-5 gånger högre än för insamling av data från Habr. Trots att vi i fallet med Habr använder ett frontalt tillvägagångssätt med HTML-parsning, och i fallet med OK kan vi arbeta med API:t på kritiska platser.

Resultat

Oavsett hur mycket du krävs för att uppskatta deadlines "på plats" (vi planerar idag!) för en voluminös databearbetningspipelinemodul, är exekveringstiden nästan aldrig möjlig att uppskatta ens kvalitativt utan att analysera uppgiftens parametrar.

På ett lite mer filosofiskt sätt fungerar smidiga uppskattningsstrategier bra för ingenjörsuppgifter, men problem som är mer experimentella och på sätt och vis "kreativa" och utforskande, d.v.s. mindre förutsägbara, har svårigheter, som i exemplen på liknande ämnen , som vi har diskuterat här.

Datainsamling är förstås bara ett praktexempel – det är oftast en otroligt enkel och tekniskt okomplicerad uppgift, och djävulen sitter ofta i detaljerna. Och det är just på denna uppgift som vi kan visa hela skalan av möjliga alternativ för vad som kan gå fel och exakt hur lång tid arbetet kan ta.

Om du tittar på egenskaperna hos uppgiften utan ytterligare experiment, så ser Reddit och OK lika ut: det finns ett API, ett pythonomslag, men i huvudsak är skillnaden enorm. Av dessa parametrar att döma ser Habrs pars mer komplicerad ut än OK – men i praktiken är det helt tvärtom, och det är precis vad man kan ta reda på genom att genomföra enkla experiment för att analysera parametrarna för problemet.

Enligt min erfarenhet är det mest effektiva tillvägagångssättet att grovt uppskatta den tid du behöver för själva den preliminära analysen och enkla första experiment, genom att läsa dokumentationen - dessa gör att du kan ge en korrekt uppskattning för hela arbetet. När det gäller den populära agila metoden ber jag dig att skapa en biljett för "uppskattning av uppgiftsparametrar", på basis av vilken jag kan ge en bedömning av vad som kan åstadkommas inom "sprinten" och ge en mer exakt uppskattning för varje uppgift.

Därför verkar det mest effektiva argumentet vara ett som skulle visa en "icke-teknisk" specialist hur mycket tid och resurser kommer att variera beroende på parametrar som ännu inte har bedömts.

Källa: will.com