Kio povas misfunkcii kun Datuma Scienco? Kolekto de datumoj

Hodiaŭ ekzistas 100500 XNUMX Kursoj pri Datuma Scienco kaj delonge oni scias, ke la plej granda parto de mono en Data Science povas esti gajnita per Data Science-kursoj (kial fosi kiam oni povas vendi ŝovelilojn?). La ĉefa malavantaĝo de ĉi tiuj kursoj estas, ke ili havas nenion komunan kun reala laboro: neniu donos al vi purajn, prilaboritajn datumojn en la bezonata formato. Kaj kiam vi forlasas la kurson kaj komencas solvi veran problemon, aperas multaj nuancoj.

Tial ni komencas serion da notoj "Kio povas misfunkcii kun Data Science", bazitaj sur realaj eventoj, kiuj okazis al mi, miaj kamaradoj kaj kolegoj. Ni analizos tipajn Datumsciencajn taskojn uzante realajn ekzemplojn: kiel tio efektive okazas. Ni komencu hodiaŭ kun la tasko de kolekto de datumoj.

Kaj la unua afero, kiun homoj stumblas kiam ili komencas labori kun realaj datumoj, estas efektive kolekti ĉi tiujn datumojn, kiuj plej gravas por ni. La esenca mesaĝo de ĉi tiu artikolo:

Ni sisteme subtaksas la tempon, rimedojn kaj penon necesajn por kolekti, purigi kaj prepari datumojn.

Kaj plej grave, ni diskutos, kion fari por malhelpi ĉi tion.

Laŭ diversaj taksoj, purigado, transformo, datumtraktado, trajto-inĝenierado ktp okupas 80-90% de la tempo, kaj analizo 10-20%, dum preskaŭ ĉiuj edukaj materialoj temigas ekskluzive analizon.

Ni rigardu simplan analizan problemon en tri versioj kiel tipan ekzemplon kaj vidu, kio estas "pligravaj cirkonstancoj".

Kaj kiel ekzemplo, denove, ni konsideros similajn variojn de la tasko kolekti datumojn kaj kompari komunumojn por:

1. Du Reddit-subredoj
2. Du sekcioj de Habr
3. Du grupoj de Odnoklassniki

Kondiĉa aliro en teorio

Malfermu la retejon kaj legu la ekzemplojn, se ĝi estas klara, rezervu kelkajn horojn por legado, kelkajn horojn por la kodo uzante la ekzemplojn kaj elpurigado. Aldonu kelkajn horojn por kolekto. Enĵetu kelkajn horojn en rezervo (obligu per du kaj aldonu N horojn).

Ŝlosila Punkto: Tempaj taksoj baziĝas sur supozoj kaj divenoj pri kiom da tempo ĝi daŭros.

Necesas komenci la tempan analizon taksante la sekvajn parametrojn por la kondiĉa problemo priskribita supre:

• Kio estas la grandeco de la datumoj kaj kiom da ĝi devas esti fizike kolektita (*vidu sube*).
• Kio estas la kolekta tempo por unu disko kaj kiom da tempo vi devas atendi antaŭ ol vi povas kolekti la duan?
• Konsideru skribi kodon, kiu savas la staton kaj komencas rekomencon kiam (ne se) ĉio malsukcesas.
• Eltrovu ĉu ni bezonas rajtigon kaj fiksu la tempon por akiri aliron per la API.
• Fiksu la nombron da eraroj kiel funkcion de datuma komplekseco - taksu por specifa tasko: strukturo, kiom da transformoj, kion kaj kiel ĉerpi.
• Ripari retajn erarojn kaj problemojn kun ne-norma projekto-konduto.
• Taksi ĉu la postulataj funkcioj estas en la dokumentado kaj se ne, tiam kiel kaj kiom necesas por solvo.

La plej grava afero estas, ke por taksi tempon – oni ja devas elspezi tempon kaj penon pri “rekono en forto” – nur tiam via planado estos adekvata. Sekve, kiom ajn vi estas puŝita diri "kiom da tempo necesas por kolekti datumojn" - aĉetu al vi iom da tempo por prepara analizo kaj argumentu, kiom la tempo varios depende de la realaj parametroj de la tasko.

Kaj nun ni montros specifajn ekzemplojn, kie tiaj parametroj ŝanĝiĝos.

Ŝlosila Punkto: La takso baziĝas sur analizo de ŝlosilaj faktoroj influantaj la amplekson kaj kompleksecon de la laboro.

Diven-bazita takso estas bona aliro kiam la funkciaj elementoj estas sufiĉe malgrandaj kaj ekzistas ne multaj faktoroj kiuj povas signife influi la dezajnon de la problemo. Sed en la kazo de kelkaj Datumscienco-problemoj, tiaj faktoroj iĝas ekstreme multaj kaj tia aliro fariĝas neadekvata.

Komparo de Reddit-komunumoj

Ni komencu per la plej simpla kazo (kiel ĝi rezultas poste). Ĝenerale, por esti tute honesta, ni havas preskaŭ idealan kazon, ni kontrolu nian kompleksecliston:

• Estas neta, klara kaj dokumentita API.
• Ĝi estas ekstreme simpla kaj plej grave, ĵetono akiras aŭtomate.
• Ekzistas python envolvaĵo - kun multaj ekzemploj.
• Komunumo, kiu analizas kaj kolektas datumojn pri reddit (eĉ al YouTube-videoj klarigante kiel uzi python-envolvaĵon) Ekzemple.
• La metodoj kiujn ni bezonas plej verŝajne ekzistas en la API. Plie, la kodo aspektas kompakta kaj pura, sube estas ekzemplo de funkcio, kiu kolektas komentojn pri afiŝo.

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

Prenita de ĉi tio elekto de oportunaj utilecoj por envolvi.

Malgraŭ la fakto, ke ĉi tiu estas la plej bona kazo, ĝi ankoraŭ valoras konsideri kelkajn gravajn faktorojn de la reala vivo:

• API-limoj - ni estas devigitaj preni datumojn en aroj (dormo inter petoj, ktp.).
• Kolekta tempo - por kompleta analizo kaj komparo, vi devos flankenmeti signifan tempon nur por ke la araneo trairu la subredon.
• La bot devas funkcii per servilo—vi ne povas simple ruli ĝin sur via tekkomputilo, meti ĝin en vian tornistron kaj fari vian komercon. Do mi prizorgis ĉion per VPS. Uzante la reklamkodon habrahabr10 vi povas ŝpari alian 10% de la kosto.
• La fizika nealirebleco de iuj datumoj (ili estas videblaj por administrantoj aŭ estas tro malfacile kolekteblaj) - tio devas esti konsiderata; principe, ne ĉiuj datumoj povas esti kolektitaj en taŭga tempo.
• Retaj eraroj: Retigado estas doloro.
• Ĉi tio estas vivantaj realaj datumoj - ĝi neniam estas pura.

Kompreneble, estas necese inkluzivi ĉi tiujn nuancojn en la evoluo. Specifaj horoj/tagoj dependas de disvolva sperto aŭ sperto laboranta pri similaj taskoj, tamen ni vidas, ke ĉi tie la tasko estas pure inĝenieristiko kaj ne postulas pliajn korpaj movojn por solvi - ĉio estas tre bone taksata, planita kaj farita.

Komparo de Habr-sekcioj

Ni transiru al pli interesa kaj ne bagatela kazo de komparado de fadenoj kaj/aŭ sekcioj de Habr.

Ni kontrolu nian kompleksecliston - ĉi tie, por kompreni ĉiun punkton, vi devos iom fosi la taskon mem kaj eksperimenti.

• Komence vi pensas, ke ekzistas API, sed ne ekzistas. Jes, jes, Habr havas API, sed ĝi simple ne estas alirebla por uzantoj (aŭ eble ĝi tute ne funkcias).
• Tiam vi nur komencas analizi html - "import-petoj", kio povus misfunkcii?
• Kiel analizi ĉiuokaze? La plej simpla kaj plej ofte uzata aliro estas ripetadi super identigiloj, rimarku, ke ĝi ne estas la plej efika kaj devos trakti malsamajn kazojn - jen ekzemplo de la denseco de realaj identigiloj inter ĉiuj ekzistantaj.

  
  Prenita de ĉi tio artikoloj.

• Krudaj datumoj envolvitaj en HTML sur la reto estas dolora. Ekzemple, vi volas kolekti kaj konservi la takson de artikolo: vi elŝiris la poentaron el la html kaj decidis konservi ĝin kiel nombro por plua prilaborado: 

  1) int(poentaro) ĵetas eraron: ĉar ĉe Habré estas minuso, kiel ekzemple en la linio “–5” - tio estas en streketo, ne minus-signo (neatendite, ĉu ne?), do ĉe iun punkton mi devis revivigi la analizilon per tia terura riparo.

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

  Eble ne ekzistas dato, plusoj kaj minusoj entute (kiel ni vidas supre en la funkcio check_date, tio okazis).

  2) Neeskapitaj specialaj karakteroj - ili venos, vi devas esti preta.

  3) La strukturo ŝanĝiĝas laŭ la tipo de afiŝo.

  4) Malnovaj afiŝoj povas havi **strangan strukturon**.

• Esence, erartraktado kaj kio povas aŭ ne okazos devos esti pritraktitaj kaj vi ne povas antaŭdiri certe kio misfunkcios kaj kiel alie la strukturo povas esti kaj kio defalos kie - vi nur devos provi konsideri. la eraroj kiujn la analizanto ĵetas.
• Tiam vi rimarkas, ke vi devas analizi en pluraj fadenoj, alie analizado en unu tiam daŭros 30+ horojn (ĉi tio estas nur la ekzekuttempo de jam funkcianta unufadena analizilo, kiu dormas kaj ne falas sub iujn malpermesojn). EN ĉi tio artikolo, tio kondukis iam al simila skemo:

Totala kontrola listo laŭ komplekseco:

• Laborante kun la reto kaj html-analizo kun ripeto kaj serĉo per ID.
• Dokumentoj de heterogena strukturo.
• Estas multaj lokoj kie la kodo povas facile fali.
• Necesas skribi || kodo.
• La necesa dokumentaro, kodaj ekzemploj kaj/aŭ komunumo mankas.

La laŭtaksa tempo por ĉi tiu tasko estos 3-5 fojojn pli alta ol por kolekti datumojn de Reddit.

Komparo de Odnoklassniki-grupoj

Ni transiru al la plej teknike interesa kazo priskribita. Por mi, ĝi estis interese ĝuste ĉar unuavide, ĝi aspektas sufiĉe bagatela, sed ĝi tute ne rezultas esti tiel - tuj kiam vi pikas bastonon al ĝi.

Ni komencu per nia malfacila kontrolo kaj notu, ke multaj el ili estos multe pli malfacilaj ol ili unue aspektas:

• Estas API, sed al ĝi preskaŭ tute mankas la necesaj funkcioj.
• Al iuj funkcioj vi devas peti aliron per poŝto, tio estas, ke la aliro ne estas tuja.
• Ĝi estas terure dokumentita (komence, rusaj kaj anglaj terminoj estas ĉie miksitaj, kaj tute malkonsekvence - foje oni nur bezonas diveni, kion ili volas de vi ie) kaj, krome, la dezajno ne taŭgas por akiri datumojn, ekzemple. , la funkcio kiun ni bezonas.
• Postulas kunsidon en la dokumentado, sed ne efektive uzas ĝin - kaj ne ekzistas maniero kompreni ĉiujn komplikaĵojn de la API-reĝimoj krom piki kaj esperi ke io funkcios.
• Ekzistas neniuj ekzemploj kaj neniu komunumo; la nura punkto de subteno en kolektado de informoj estas malgranda envolvilo en Python (sen multaj ekzemploj de uzo).
• Seleno ŝajnas esti la plej realigebla opcio, ĉar multaj el la necesaj datumoj estas ŝlositaj.
  1) Tio estas, rajtigo okazas per fikcia uzanto (kaj registrado permane).

  2) Tamen ĉe Selenio ne ekzistas garantioj por ĝusta kaj ripetebla laboro (almenaŭ en la kazo de ok.ru certe).

  3) La retejo Ok.ru enhavas JavaScript-erarojn kaj foje kondutas strange kaj malkonsekvence.

  4) Vi devas fari paĝigon, ŝarĝi elementojn, ktp...

  5) API-eraroj, kiujn donas la envolvaĵo, devos esti mallerte traktitaj, ekzemple, tiel (peco de eksperimenta kodo):

  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
  

  Mia plej ŝatata eraro estis:

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

  6) Finfine, Selenium + API aspektas kiel la plej racia opcio.

• Necesas konservi la staton kaj rekomenci la sistemon, trakti multajn erarojn, inkluzive de malkonsekvenca konduto de la retejo - kaj ĉi tiuj eraroj estas sufiĉe malfacile imagi (krom se vi skribas analizistojn profesie, kompreneble).

La kondiĉa tempotakso por ĉi tiu tasko estos 3-5 fojojn pli alta ol por kolektado de datumoj de Habr. Malgraŭ tio, ke en la kazo de Habr ni uzas frontan aliron kun HTML-analizo, kaj en la kazo de OK ni povas labori kun la API en kritikaj lokoj.

trovoj

Kiom ajn vi estas postulata por taksi la limdatojn "surloke" (ni planas hodiaŭ!) de volumena datuma pritrakta duktomodulo, la ekzekuttempo preskaŭ neniam eblas taksi eĉ kvalite sen analizi la taskoparametrojn.

En iom pli filozofia noto, lertaj taksadstrategioj funkcias bone por inĝenieraj taskoj, sed problemoj kiuj estas pli eksperimentaj kaj, iusence, "kreivaj" kaj esploraj, t.e., malpli antaŭvideblaj, havas malfacilaĵojn, kiel en la ekzemploj de similaj temoj , pri kiuj ni diskutis ĉi tie.

Kompreneble, datumkolektado estas nur ĉefa ekzemplo - ĝi estas kutime nekredeble simpla kaj teknike nekomplika tasko, kaj la diablo ofte estas en la detaloj. Kaj ĝuste pri ĉi tiu tasko ni povas montri la tutan gamon da eblaj opcioj por kio povas misfunkcii kaj ĝuste kiom longe la laboro povas daŭri.

Se vi rigardas la trajtojn de la tasko sen pliaj eksperimentoj, tiam Reddit kaj OK aspektas similaj: ekzistas API, python-envolvilo, sed esence, la diferenco estas grandega. Juĝante laŭ ĉi tiuj parametroj, la pars de Habr aspektas pli komplika ol OK - sed praktike ĝi estas tute male, kaj ĝuste ĉi tio povas esti eksciita per simplaj eksperimentoj por analizi la parametrojn de la problemo.

Laŭ mia sperto, la plej efika aliro estas proksimume taksi la tempon, kiun vi bezonos por la prepara analizo mem kaj simplaj unuaj eksperimentoj, legante la dokumentadon - ĉi tiuj permesos al vi doni precizan takson por la tuta laboro. Koncerne al la populara lerta metodaro, mi petas vin krei bileton por "taksado de taskaj parametroj", surbaze de kiu mi povas doni takson pri tio, kio povas esti plenumita ene de la "sprint" kaj doni pli precizan takson por ĉiu. tasko.

Tial, la plej efika argumento ŝajnas esti tiu, kiu montrus al "ne-teknika" specialisto kiom da tempo kaj rimedoj varios depende de parametroj, kiuj ankoraŭ devas esti taksitaj.

fonto: www.habr.com