Çfarë mund të shkojë keq me Data Science? Mbledhja e të dhënave

Sot ka 100500 kurse të Shkencës së të Dhënave dhe dihet prej kohësh se më shumë para në Shkencën e të Dhënave mund të fitohen përmes kurseve të Shkencës së të Dhënave (pse të gërmoni kur mund të shesni lopata?). Disavantazhi kryesor i këtyre kurseve është se ato nuk kanë asnjë lidhje me punën reale: askush nuk do t'ju japë të dhëna të pastra, të përpunuara në formatin e kërkuar. Dhe kur largoheni nga kursi dhe filloni të zgjidhni një problem të vërtetë, shfaqen shumë nuanca.

Prandaj, po fillojmë një seri shënimesh “Çfarë mund të shkojë keq me Data Science”, bazuar në ngjarje reale që më kanë ndodhur mua, shokëve dhe kolegëve të mi. Ne do të analizojmë detyrat tipike të Shkencës së të Dhënave duke përdorur shembuj realë: si ndodh kjo në të vërtetë. Le të fillojmë sot me detyrën e mbledhjes së të dhënave.

Dhe gjëja e parë që njerëzit pengojnë kur fillojnë të punojnë me të dhëna reale është mbledhja e këtyre të dhënave që janë më të rëndësishme për ne. Mesazhi kryesor i këtij artikulli:

Ne nënvlerësojmë sistematikisht kohën, burimet dhe përpjekjet e nevojshme për të mbledhur, pastruar dhe përgatitur të dhëna.

Dhe më e rëndësishmja, ne do të diskutojmë se çfarë të bëjmë për ta parandaluar këtë.

Sipas vlerësimeve të ndryshme, pastrimi, transformimi, përpunimi i të dhënave, inxhinieria e veçorive etj. marrin 80-90% të kohës dhe analizat 10-20%, ndërsa pothuajse i gjithë materiali edukativ fokusohet ekskluzivisht në analizë.

Le të shohim një problem të thjeshtë analitik në tre versione si shembull tipik dhe të shohim se cilat janë “rrethanat rënduese”.

Dhe si shembull, përsëri, ne do të shqyrtojmë variacione të ngjashme të detyrës së mbledhjes së të dhënave dhe krahasimit të komuniteteve për:

1. Dy subreddit të Reddit
2. Dy seksione të Habrit
3. Dy grupe të Odnoklassniki

Qasja e kushtëzuar në teori

Hapni faqen dhe lexoni shembujt, nëse është e qartë, lini mënjanë disa orë për lexim, disa orë për kodin duke përdorur shembujt dhe korrigjimin e gabimeve. Shtoni disa orë për mbledhjen. Hidheni disa orë në rezervë (shumezoni me dy dhe shtoni N orë).

Pika kryesore: Vlerësimet e kohës bazohen në supozime dhe supozime për sa kohë do të zgjasë.

Është e nevojshme të fillohet analiza e kohës duke vlerësuar parametrat e mëposhtëm për problemin e kushtëzuar të përshkruar më sipër:

• Cila është madhësia e të dhënave dhe sa prej tyre duhet të mblidhen fizikisht (*shih më poshtë*).
• Sa është koha e grumbullimit për një rekord dhe sa kohë duhet të prisni përpara se të mund të mbledhni të dytin?
• Merrni parasysh të shkruani kodin që ruan gjendjen dhe fillon një rinisje kur (jo nëse) gjithçka dështon.
• Kuptoni nëse kemi nevojë për autorizim dhe caktoni kohën për marrjen e aksesit përmes API-së.
• Vendosni numrin e gabimeve në funksion të kompleksitetit të të dhënave - vlerësoni për një detyrë specifike: strukturën, sa transformime, çfarë dhe si të nxirren.
• Rregulloni gabimet e rrjetit dhe problemet me sjelljen jo standarde të projektit.
• Vlerësoni nëse funksionet e kërkuara janë në dokumentacion dhe nëse jo, atëherë si dhe sa nevojitet për një zgjidhje.

Gjëja më e rëndësishme është që për të vlerësuar kohën - në fakt duhet të shpenzoni kohë dhe përpjekje për "zbulimin në fuqi" - vetëm atëherë planifikimi juaj do të jetë adekuat. Prandaj, sado të shtyheni të thoni "sa kohë duhet për të mbledhur të dhëna" - blini pak kohë për një analizë paraprake dhe argumentoni se sa do të ndryshojë koha në varësi të parametrave realë të problemit.

Dhe tani do të demonstrojmë shembuj specifikë ku parametra të tillë do të ndryshojnë.

Pika kryesore: Vlerësimi bazohet në një analizë të faktorëve kryesorë që ndikojnë në shtrirjen dhe kompleksitetin e punës.

Vlerësimi i bazuar në hamendje është një qasje e mirë kur elementët funksionalë janë mjaft të vegjël dhe nuk ka shumë faktorë që mund të ndikojnë ndjeshëm në hartimin e problemit. Por në rastin e një numri problemesh të Shkencës së të Dhënave, faktorë të tillë bëhen jashtëzakonisht të shumtë dhe një qasje e tillë bëhet e papërshtatshme.

Krahasimi i komuniteteve Reddit

Le të fillojmë me rastin më të thjeshtë (siç rezulton më vonë). Në përgjithësi, për të qenë plotësisht i sinqertë, ne kemi një rast pothuajse ideal, le të kontrollojmë listën tonë të kontrollit të kompleksitetit:

• Ekziston një API e pastër, e qartë dhe e dokumentuar.
• Është jashtëzakonisht e thjeshtë dhe më e rëndësishmja, një shenjë merret automatikisht.
• Ka mbështjellës pitoni - me shumë shembuj.
• Një komunitet që analizon dhe mbledh të dhëna në reddit (madje edhe në videot e YouTube që shpjegojnë se si të përdoret mbështjellësi python) Për shembull.
• Metodat që na duhen ka shumë të ngjarë të ekzistojnë në API. Për më tepër, kodi duket kompakt dhe i pastër, më poshtë është një shembull i një funksioni që mbledh komente në një postim.

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

Marre nga kjo një përzgjedhje e shërbimeve të përshtatshme për mbështjellje.

Përkundër faktit se ky është rasti më i mirë, ia vlen të merren parasysh një sërë faktorësh të rëndësishëm nga jeta reale:

• Kufijtë e API - ne jemi të detyruar të marrim të dhëna në grupe (gjumë midis kërkesave, etj.).
• Koha e grumbullimit - për një analizë dhe krahasim të plotë, do t'ju duhet të lini mënjanë kohë të konsiderueshme vetëm që merimanga të ecë nëpër subreddit.
• Bot-i duhet të funksionojë në një server - nuk mund ta përdorni vetëm në laptop, ta vendosni në çantën e shpinës dhe të vazhdoni biznesin tuaj. Kështu që unë ekzekutova gjithçka në një VPS. Duke përdorur kodin promocional habrahabr10 mund të kurseni edhe 10% të kostos.
• Paarritshmëria fizike e disa të dhënave (ato janë të dukshme për administratorët ose janë shumë të vështira për t'u mbledhur) - kjo duhet të merret parasysh; në parim, jo ​​të gjitha të dhënat mund të mblidhen në kohën e duhur.
• Gabimet e rrjetit: Rrjeti është një dhimbje.
• Këto janë të dhëna reale të gjalla - nuk janë kurrë të pastra.

Sigurisht, është e nevojshme të përfshihen këto nuanca në zhvillim. Orët/ditë specifike varen nga përvoja e zhvillimit ose përvoja duke punuar në detyra të ngjashme, megjithatë, ne shohim se këtu detyra është thjesht inxhinierike dhe nuk kërkon lëvizje shtesë të trupit për t'u zgjidhur - gjithçka mund të vlerësohet, planifikohet dhe bëhet shumë mirë.

Krahasimi i seksioneve të Habrit

Le të kalojmë në një rast më interesant dhe jo të parëndësishëm të krahasimit të temave dhe/ose seksioneve të Habrit.

Le të kontrollojmë listën tonë të kontrollit të kompleksitetit - këtu, për të kuptuar secilën pikë, do t'ju duhet të gërmoni pak në vetë detyrën dhe të eksperimentoni.

• Në fillim ju mendoni se ka një API, por nuk ka. Po, po, Habr ka një API, por thjesht nuk është i arritshëm për përdoruesit (ose ndoshta nuk funksionon fare).
• Atëherë thjesht filloni të analizoni html - "kërkesat e importit", çfarë mund të shkojë keq?
• Si të analizohet gjithsesi? Qasja më e thjeshtë dhe më e përdorur është përsëritja mbi ID-të, vini re se nuk është më efikasja dhe do të duhet të trajtojë raste të ndryshme - këtu është një shembull i densitetit të ID-ve reale midis të gjitha atyre ekzistuese.

  
  Marre nga kjo artikull.

• Të dhënat e papërpunuara të mbështjella në HTML në krye të uebit janë një dhimbje. Për shembull, ju dëshironi të grumbulloni dhe ruani vlerësimin e një artikulli: ju hoqët rezultatin nga html dhe vendosët ta ruani atë si një numër për përpunim të mëtejshëm: 

  1) int(rezultati) hedh një gabim: pasi në Habré ka një minus, si, për shembull, në rreshtin "–5" - kjo është një vizë en, jo një shenjë minus (papritur, apo jo?), kështu që në në një moment më duhej ta ringjallja analizuesin me një rregullim kaq të tmerrshëm.

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

  Mund të mos ketë fare datë, pluse dhe minuse (siç e shohim më lart në funksionin check_date, kjo ndodhi).

  2) Karaktere speciale të pashpëtuara - ata do të vijnë, ju duhet të përgatiteni.

  3) Struktura ndryshon në varësi të llojit të postës.

  4) Postimet e vjetra mund të kenë një **strukturë të çuditshme**.

• Në thelb, trajtimi i gabimeve dhe çfarë mund ose nuk mund të ndodhë do të duhet të trajtohet dhe nuk mund të parashikoni me siguri se çfarë do të shkojë keq dhe si tjetër mund të jetë struktura dhe çfarë do të bjerë ku - thjesht do të duhet të përpiqeni dhe të merrni parasysh gabimet që hedh analizuesi.
• Pastaj kupton se duhet të analizosh në disa fije, përndryshe analizimi në një do të zgjasë më shumë se 30 orë (kjo është thjesht koha e ekzekutimit të një analizuesi me një fije tashmë që funksionon, i cili fle dhe nuk bie nën asnjë ndalim). NË kjo artikull, kjo çoi në një moment në një skemë të ngjashme:

Lista kontrolluese totale sipas kompleksitetit:

• Puna me rrjetin dhe analiza html me përsëritje dhe kërkim sipas ID.
• Dokumentet e strukturës heterogjene.
• Ka shumë vende ku kodi mund të bjerë lehtësisht.
• Është e nevojshme të shkruhet || kodi.
• Mungojnë dokumentacioni i nevojshëm, shembuj kodesh dhe/ose komunitet.

Koha e parashikuar për këtë detyrë do të jetë 3-5 herë më e lartë se sa për mbledhjen e të dhënave nga Reddit.

Krahasimi i grupeve Odnoklassniki

Le të kalojmë në rastin më interesant teknikisht të përshkruar. Për mua, ishte interesante pikërisht sepse në shikim të parë, duket mjaft e parëndësishme, por nuk rezulton të jetë aspak kështu - sapo t'i thuash një shkop.

Le të fillojmë me listën tonë të kontrollit të vështirësive dhe të vërejmë se shumë prej tyre do të rezultojnë të jenë shumë më të vështira sesa duken në fillim:

• Ekziston një API, por pothuajse plotësisht i mungojnë funksionet e nevojshme.
• Për disa funksione ju duhet të kërkoni akses me postë, domethënë, dhënia e aksesit nuk është e menjëhershme.
• Është tmerrësisht e dokumentuar (për të filluar, termat rusisht dhe anglisht janë të përziera kudo, dhe plotësisht në mënyrë të paqëndrueshme - ndonjëherë ju thjesht duhet të merrni me mend se çfarë duan nga ju diku) dhe, për më tepër, dizajni nuk është i përshtatshëm për marrjen e të dhënave, për shembull , funksionin që na nevojitet.
• Kërkon një seancë në dokumentacion, por në fakt nuk e përdor atë - dhe nuk ka asnjë mënyrë për të kuptuar të gjitha ndërlikimet e mënyrave të API-së, përveçse të vërshosh dhe të shpresosh se diçka do të funksionojë.
• Nuk ka shembuj dhe asnjë komunitet; e vetmja pikë e mbështetjes në mbledhjen e informacionit është e vogël mbështjellës në Python (pa shumë shembuj përdorimi).
• Seleni duket të jetë opsioni më i zbatueshëm, pasi shumë nga të dhënat e nevojshme janë të bllokuara.
  1) Domethënë, autorizimi bëhet përmes një përdoruesi fiktiv (dhe regjistrimi me dorë).

  2) Sidoqoftë, me Selenium nuk ka garanci për punë korrekte dhe të përsëritshme (të paktën në rastin e ok.ru me siguri).

  3) Faqja e internetit Ok.ru përmban gabime JavaScript dhe ndonjëherë sillet në mënyrë të çuditshme dhe jokonsistente.

  4) Duhet të bëni faqezim, ngarkim të elementeve, etj...

  5) Gabimet e API që jep mbështjellësi do të duhet të trajtohen në mënyrë të vështirë, për shembull, si kjo (një pjesë e kodit eksperimental):

  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
  

  Gabimi im i preferuar ishte:

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

  6) Në fund të fundit, Selenium + API duket si opsioni më racional.

• Shtë e nevojshme të ruani gjendjen dhe të rindizni sistemin, të trajtoni shumë gabime, duke përfshirë sjelljen jokonsistente të faqes - dhe këto gabime janë mjaft të vështira për t'u imagjinuar (përveç nëse shkruani analizues profesionalisht, natyrisht).

Vlerësimi i kohës së kushtëzuar për këtë detyrë do të jetë 3-5 herë më i lartë se sa për mbledhjen e të dhënave nga Habr. Pavarësisht se në rastin e Habr ne përdorim një qasje frontale me analizë HTML, dhe në rastin e OK mund të punojmë me API në vende kritike.

Gjetjet

Pavarësisht se sa ju kërkohet të vlerësoni afatet "në vend" (ne po planifikojmë sot!) të një moduli voluminoz të tubacionit të përpunimit të të dhënave, koha e ekzekutimit nuk është pothuajse kurrë e mundur të vlerësohet edhe në mënyrë cilësore pa analizuar parametrat e detyrës.

Në një këndvështrim pak më filozofik, strategjitë e shkathëta të vlerësimit funksionojnë mirë për detyrat inxhinierike, por problemet që janë më eksperimentale dhe, në një farë kuptimi, "kreative" dhe eksploruese, d.m.th., më pak të parashikueshme, kanë vështirësi, si në shembujt e temave të ngjashme. që kemi diskutuar këtu.

Sigurisht, mbledhja e të dhënave është vetëm një shembull kryesor - zakonisht është një detyrë tepër e thjeshtë dhe teknikisht e pakomplikuar, dhe djalli është shpesh në detaje. Dhe është pikërisht në këtë detyrë që ne mund të tregojmë të gjithë gamën e opsioneve të mundshme për atë që mund të shkojë keq dhe saktësisht sa kohë mund të zgjasë puna.

Nëse shikoni karakteristikat e detyrës pa eksperimente shtesë, atëherë Reddit dhe OK duken të ngjashme: ekziston një API, një mbështjellës python, por në thelb, ndryshimi është i madh. Duke gjykuar nga këto parametra, parsi i Habrit duket më i ndërlikuar se në rregull - por në praktikë është krejt e kundërta, dhe kjo është pikërisht ajo që mund të zbulohet duke kryer eksperimente të thjeshta për të analizuar parametrat e problemit.

Në përvojën time, qasja më efektive është të vlerësoni përafërsisht kohën që ju nevojitet për vetë analizën paraprake dhe eksperimentet e para të thjeshta, duke lexuar dokumentacionin - këto do t'ju lejojnë të jepni një vlerësim të saktë për të gjithë punën. Për sa i përket metodologjisë së shkathët popullore, ju kërkoj të krijoni një biletë për "vlerësimin e parametrave të detyrës", në bazë të së cilës unë mund të jap një vlerësim të asaj që mund të arrihet brenda "sprintit" dhe të jap një vlerësim më të saktë për secilin. detyrë.

Prandaj, argumenti më efektiv duket të jetë ai që do t'i tregonte një specialisti "jo teknik" se sa kohë dhe burime do të ndryshojnë në varësi të parametrave që ende duhet të vlerësohen.

Burimi: www.habr.com