ProHoster > Blogs > Administrācija > Kas datu zinātnē var noiet greizi? Datu vākÅ”ana

Kas datu zinātnē var noiet greizi? Datu vākÅ”ana

Kas datu zinātnē var noiet greizi? Datu vākÅ”ana
Mūsdienās ir 100500 XNUMX datu zinātnes kursu, un jau sen ir zināms, ka visvairāk naudas datu zinātnē var nopelnīt, izmantojot datu zinātnes kursus (kāpēc rakt, ja var pārdot lāpstas?). Šo kursu galvenais trūkums ir tas, ka tiem nav nekāda sakara ar reālu darbu: neviens jums neiedos tīrus, apstrādātus datus vajadzīgajā formātā. Un, kad jūs pametat kursu un sākat risināt reālu problēmu, parādās daudzas nianses.

Tāpēc mēs sākam piezÄ«mju sēriju ā€œKas var noiet greizi ar datu zinātniā€, pamatojoties uz patiesiem notikumiem, kas notika ar mani, maniem biedriem un kolēģiem. Mēs analizēsim tipiskus datu zinātnes uzdevumus, izmantojot reālus piemērus: kā tas patiesÄ«bā notiek. Sāksim Å”odien ar datu vākÅ”anas uzdevumu.

Un pirmais, uz ko cilvēki paklups, kad viņi sāk strādāt ar reāliem datiem, patiesÄ«bā ir Å”o mums visatbilstoŔāko datu apkopoÅ”ana. Å Ä« raksta galvenais vēstÄ«jums:

Mēs sistemātiski par zemu novērtējam laiku, resursus un pÅ«les, kas nepiecieÅ”amas datu apkopoÅ”anai, tÄ«rÄ«Å”anai un sagatavoÅ”anai.

Un pats galvenais, mēs apspriedīsim, ko darīt, lai to novērstu.

Pēc dažādām aplēsēm, tÄ«rÄ«Å”ana, transformācija, datu apstrāde, funkciju inženierija utt. aizņem 80-90% laika, bet analÄ«ze - 10-20%, savukārt gandrÄ«z visi mācÄ«bu materiāli ir vērsti tikai uz analÄ«zi.

ApskatÄ«sim vienkārÅ”u analÄ«tisko problēmu trÄ«s versijās kā tipisku piemēru un redzēsim, kas ir ā€œpastiprinoÅ”i apstākļiā€.

Kā piemēru mēs atkal apsvērsim lÄ«dzÄ«gas datu vākÅ”anas un kopienu salÄ«dzināŔanas uzdevuma variācijas:

  1. Divas Reddit apakŔreklāmas
  2. Divas sadaļas Habr
  3. Divas Odnoklassniki grupas

Nosacīta pieeja teorētiski

Atveriet vietni un izlasiet piemērus, ja tas ir skaidrs, atvēliet dažas stundas lasÄ«Å”anai, dažas stundas kodam, izmantojot piemērus un atkļūdoÅ”anu. Pievienojiet dažas stundas savākÅ”anai. Iemetiet dažas stundas rezervē (reiziniet ar divi un pievienojiet N stundas).

Galvenais punkts: laika aprēķini ir balstīti uz pieņēmumiem un minējumiem par to, cik ilgi tas prasīs.

Laika analÄ«ze ir jāsāk, novērtējot Ŕādus parametrus iepriekÅ” aprakstÄ«tajai nosacÄ«juma problēmai:

  • Kāds ir datu apjoms un cik daudz no tiem ir fiziski jāsavāc (*skat. zemāk*).
  • Kāds ir viena ieraksta vākÅ”anas laiks un cik ilgi jāgaida, lai varētu savākt otro?
  • Apsveriet iespēju rakstÄ«t kodu, kas saglabā stāvokli un sāk restartÄ“Å”anu, kad (ne ja) viss neizdodas.
  • Noskaidrojiet, vai mums ir nepiecieÅ”ama autorizācija, un iestatiet laiku piekļuves iegÅ«Å”anai, izmantojot API.
  • Iestatiet kļūdu skaitu kā datu sarežģītÄ«bas funkciju - novērtējiet konkrētam uzdevumam: struktÅ«ra, cik transformācijas, ko un kā iegÅ«t.
  • Labojiet tÄ«kla kļūdas un problēmas, kas saistÄ«tas ar nestandarta projekta darbÄ«bu.
  • Novērtējiet, vai dokumentācijā ir vajadzÄ«gās funkcijas, un, ja nē, tad kā un cik daudz ir nepiecieÅ”ams risinājums.

Pats galvenais, lai novērtētu laiku - patiesÄ«bā ir jātērē laiks un pÅ«les "izlÅ«koÅ”anai spēkā" - tikai tad jÅ«su plānoÅ”ana bÅ«s adekvāta. Tāpēc neatkarÄ«gi no tā, cik ļoti jÅ«s tiekat mudināts pateikt ā€œcik ilgs laiks nepiecieÅ”ams datu apkopoÅ”anaiā€ - atvēliet sev laiku iepriekŔējai analÄ«zei un argumentējiet, cik daudz laiks mainÄ«sies atkarÄ«bā no uzdevuma reālajiem parametriem.

Un tagad mēs demonstrēsim konkrētus piemērus, kur Ŕādi parametri mainÄ«sies.

Galvenais punkts: aplēse ir balstīta uz galveno faktoru analīzi, kas ietekmē darba apjomu un sarežģītību.

Uz minējumiem balstÄ«ta aplēse ir laba pieeja, ja funkcionālie elementi ir pietiekami mazi un nav daudz faktoru, kas varētu bÅ«tiski ietekmēt problēmas izstrādi. Taču vairāku datu zinātnes problēmu gadÄ«jumā Ŕādu faktoru kļūst ārkārtÄ«gi daudz, un Ŕāda pieeja kļūst neadekvāta.

Reddit kopienu salīdzinājums

Sāksim ar vienkārŔāko gadÄ«jumu (kā vēlāk izrādÄ«sies). Kopumā, godÄ«gi sakot, mums ir gandrÄ«z ideāls gadÄ«jums, pārbaudÄ«sim mÅ«su sarežģītÄ«bas kontrolsarakstu:

  • Ir glÄ«ta, skaidra un dokumentēta API.
  • Tas ir ļoti vienkārÅ”i, un pats galvenais, marÄ·ieris tiek iegÅ«ts automātiski.
  • Ir python iesaiņojums - ar daudziem piemēriem.
  • Kopiena, kas analizē un apkopo datus par reddit (pat YouTube videoklipiem, kuros paskaidrots, kā izmantot python iesaiņojumu) Piemēram.
  • Mums nepiecieÅ”amās metodes, visticamāk, pastāv API. Turklāt kods izskatās kompakts un tÄ«rs, zemāk ir funkcijas piemērs, kas apkopo komentārus par ziņu.

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

Paņemts no Å”is ērtas palÄ«gierÄ«ces iesaiņoÅ”anai.

Neskatoties uz to, ka Å”is ir labākais gadÄ«jums, tomēr ir vērts ņemt vērā vairākus svarÄ«gus faktorus no reālās dzÄ«ves:

  • API ierobežojumi - esam spiesti ņemt datus pa partijām (miegs starp pieprasÄ«jumiem utt.).
  • SavākÅ”anas laiks ā€” pilnÄ«gai analÄ«zei un salÄ«dzināŔanai jums bÅ«s jāatlicina ievērojams laiks, lai zirneklis varētu iziet cauri subreddit.
  • Botam ir jādarbojas serverÄ« ā€” jÅ«s nevarat to vienkārÅ”i palaist klēpjdatorā, ievietot to mugursomā un turpināt savu biznesu. Tāpēc es visu palaidu VPS. Izmantojot reklāmas kodu habrahabr10, jÅ«s varat ietaupÄ«t vēl 10% no izmaksām.
  • AtseviŔķu datu fiziskā nepieejamÄ«ba (tie ir redzami administratoriem vai ir pārāk grÅ«ti apkopojami) - tas ir jāņem vērā, principā visus datus nevar savākt adekvātā laikā.
  • TÄ«kla kļūdas: tÄ«kla izveide ir sāpÄ«ga.
  • Tie ir dzÄ«vi reāli dati ā€” tie nekad nav tÄ«ri.

Protams, Ŕīs nianses ir nepiecieÅ”ams iekļaut izstrādē. Konkrētas stundas/dienas ir atkarÄ«gas no izstrādes pieredzes vai pieredzes, strādājot pie lÄ«dzÄ«giem uzdevumiem, tomēr redzam, ka Å”eit uzdevums ir tÄ«ri inženiertehnisks un tā risināŔanai nav nepiecieÅ”amas papildus Ä·ermeņa kustÄ«bas ā€“ visu var ļoti labi novērtēt, ieplānot un paveikt.

Habr sekciju salīdzinājums

Pāriesim pie interesantāka un netriviālāka gadījuma, kad tiek salīdzināti Habr pavedieni un/vai sadaļas.

PārbaudÄ«sim mÅ«su sarežģītÄ«bas kontrolsarakstu - Å”eit, lai saprastu katru punktu, jums bÅ«s nedaudz jāiedziļinās paŔā uzdevumā un jāeksperimentē.

  • Sākumā jÅ«s domājat, ka ir API, bet tā nav. Jā, jā, Habr ir API, taču tas vienkārÅ”i nav pieejams lietotājiem (vai varbÅ«t tas vispār nedarbojas).
  • Tad jÅ«s vienkārÅ”i sākat parsēt html ā€” ā€œimportÄ“Å”anas pieprasÄ«jumusā€, kas varētu noiet greizi?
  • Kā tomēr parsēt? VienkārŔākā un visbiežāk izmantotā pieeja ir atkārtot ID, ņemiet vērā, ka tas nav visefektÄ«vākais un bÅ«s jārisina dažādi gadÄ«jumi - Å”eit ir piemērs reālo ID blÄ«vumam starp visiem esoÅ”ajiem.

    Kas datu zinātnē var noiet greizi? Datu vākÅ”ana
    Paņemts no Å”is raksti.

  • Neapstrādāti dati, kas ietÄ«ti HTML formātā tÄ«mekļa augÅ”pusē, ir sāpÄ«gi. Piemēram, jÅ«s vēlaties apkopot un saglabāt raksta vērtējumu: jÅ«s izplēsāt rezultātu no html un nolēmāt to saglabāt kā numuru turpmākai apstrādei: 

    1) int(score) rada kļūdu: tā kā uz HabrĆ© ir mÄ«nuss, kā, piemēram, rindā ā€œā€“5ā€ - Ŕī ir domuzÄ«me, nevis mÄ«nusa zÄ«me (negaidÄ«ti, vai ne?), tāpēc plkst. kaut kad man nācās atdzÄ«vināt parsētāju ar tik Å”ausmÄ«gu labojumu.

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

    Var nebÅ«t datuma, plusi un mÄ«nusi (kā mēs redzam iepriekÅ” funkcijā check_date, tas notika).

    2) Speciālie varoņi bez atkāpÅ”anās ā€“ tie atnāks, jums jābÅ«t gatavam.

    3) Struktūra mainās atkarībā no amata veida.

    4) Vecām ziņām var būt **dīvaina struktūra**.

  • BÅ«tÄ«bā bÅ«s jārisina kļūdu apstrāde un tas, kas var notikt un kas var nenotikt, un jÅ«s nevarat droÅ”i paredzēt, kas noies greizi un kā vēl var bÅ«t struktÅ«ra un kas kur nokritÄ«s - jums bÅ«s tikai jāmēģina un jārēķinās kļūdas, ko parsētājs izmet.
  • Tad saproti, ka jāparsē vairākos pavedienos, pretējā gadÄ«jumā parsÄ“Å”ana vienā tad prasÄ«s 30+ stundas (tas ir tÄ«ri jau strādājoÅ”a viena pavediena parsētāja izpildes laiks, kurÅ” guļ un uz to neattiecas nekādi aizliegumi). IN Å”is rakstu, tas kādā brÄ«dÄ« noveda pie lÄ«dzÄ«gas shēmas:

Kas datu zinātnē var noiet greizi? Datu vākÅ”ana

Kopējais kontrolsaraksts pēc sarežģītības:

  • Darbs ar tÄ«klu un html parsÄ“Å”ana ar iterāciju un meklÄ“Å”anu pēc ID.
  • NeviendabÄ«gas struktÅ«ras dokumenti.
  • Ir daudzas vietas, kur kods var viegli nokrist.
  • Jāraksta || kodu.
  • TrÅ«kst nepiecieÅ”amās dokumentācijas, kodu piemēru un/vai kopienas.

Paredzamais laiks Ŕim uzdevumam būs 3-5 reizes lielāks nekā datu vākŔanai no Reddit.

Odnoklassniki grupu salīdzinājums

Pāriesim pie tehniski interesantākā aprakstÄ«tā gadÄ«juma. Man tas bija interesanti tieÅ”i ar to, ka no pirmā acu uzmetiena tas izskatās diezgan triviāli, bet tas tā nemaz nav - tiklÄ«dz tu iedur ar kociņu.

Sāksim ar mÅ«su grÅ«tÄ«bu kontrolsarakstu un ņemiet vērā, ka daudzas no tām izrādÄ«sies daudz grÅ«tākas, nekā sākotnēji Ŕķiet:

  • Ir API, taču tai gandrÄ«z pilnÄ«bā trÅ«kst nepiecieÅ”amo funkciju.
  • Noteiktām funkcijām piekļuve ir jāpieprasa pa pastu, tas ir, piekļuves pieŔķirÅ”ana nenotiek acumirklÄ«.
  • Tas ir Å”ausmÄ«gi dokumentēts (sākumā krievu un angļu termini ir sajaukti visur, un pilnÄ«gi nekonsekventi - dažreiz vajag tikai uzminēt, ko viņi no jums kaut kur vēlas) un turklāt dizains nav piemērots datu iegÅ«Å”anai, piemēram, , mums nepiecieÅ”amā funkcija.
  • NepiecieÅ”ama sesija dokumentācijā, taču tā faktiski netiek izmantota ā€” un nav iespējams saprast visas API režīmu sarežģītÄ«bas, izņemot Ä·eksÄ«Å”anos un cerÄ“Å”anu, ka kaut kas izdosies.
  • Nav piemēru un kopienas, vienÄ«gais atbalsta punkts informācijas vākÅ”anā ir neliels iesaiņojums Python valodā (bez daudziem lietoÅ”anas piemēriem).
  • Å Ä·iet, ka selēns ir vispiemērotākā iespēja, jo daudzi nepiecieÅ”amie dati ir bloķēti.
    1) Tas ir, autorizācija notiek ar fiktīva lietotāja starpniecību (un reģistrācija ar roku).

    2) Tomēr ar Selēnu nav garantijas pareizam un atkārtojamam darbam (vismaz ok.ru gadījumā noteikti).

    3) Vietne Ok.ru satur JavaScript kļūdas un dažkārt uzvedas dīvaini un nekonsekventi.

    4) Jums jāveic lappuÅ”u maiņa, elementu ielāde utt.

    5) API kļūdas, ko sniedz iesaiņojums, bÅ«s jārÄ«kojas neveikli, piemēram, Ŕādi (eksperimentāla koda gabals):

    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

    Mana mīļākā kļūda bija:

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

    6) Galu galā Selēns + API izskatās kā racionālākā iespēja.

  • Ir nepiecieÅ”ams saglabāt stāvokli un restartēt sistēmu, apstrādāt daudzas kļūdas, tostarp vietnes nekonsekventu uzvedÄ«bu - un Ŕīs kļūdas ir diezgan grÅ«ti iedomāties (ja vien jÅ«s, protams, nerakstat parsētājus).

NosacÄ«tais laika novērtējums Å”im uzdevumam bÅ«s 3-5 reizes lielāks nekā datu vākÅ”anai no Habr. Neskatoties uz to, ka Habr gadÄ«jumā mēs izmantojam frontālo pieeju ar HTML parsÄ“Å”anu, bet OK gadÄ«jumā mēs varam strādāt ar API kritiskās vietās.

Atzinumi

Lai arÄ« cik daudz prasÄ«tu apjomÄ«ga datu apstrādes konveijera moduļa ā€œuz vietasā€ (Å”odien plānojam!) termiņu aplēsi, izpildes laiku gandrÄ«z nekad nav iespējams pat kvalitatÄ«vi novērtēt bez uzdevuma parametru analÄ«zes.

Nedaudz filozofiskāk runājot, veiklās aplēses stratēģijas labi darbojas inženiertehniskos uzdevumos, taču problēmas, kas ir vairāk eksperimentālas un savā ziņā ā€œradoŔākasā€ un pētnieciskas, t.i., mazāk paredzamas, rada grÅ«tÄ«bas, kā tas ir lÄ«dzÄ«gu tēmu piemēros. ko mēs Å”eit apspriedām.

Protams, datu vākÅ”ana ir tikai spilgts piemērs ā€“ tas parasti ir neticami vienkārÅ”s un tehniski nesarežģīts uzdevums, un velns bieži vien slēpjas detaļās. Un tieÅ”i Å”ajā uzdevumā mēs varam parādÄ«t visu iespējamo variantu klāstu, kas var noiet greizi un cik ilgi darbs var aizņemt.

Ja paskatās uz uzdevuma Ä«paŔībām bez papildu eksperimentiem, tad Reddit un OK izskatās lÄ«dzÄ«gi: ir API, python wrapper, bet bÅ«tÄ«bā atŔķirÄ«ba ir milzÄ«ga. Spriežot pēc Å”iem parametriem, Hābra pars izskatās sarežģītāks par OK, taču praksē tas ir gluži pretēji, un tieÅ”i to var noskaidrot, veicot vienkārÅ”us eksperimentus, lai analizētu problēmas parametrus.

Mana pieredze liecina, ka visefektÄ«vākā pieeja ir aptuveni aprēķināt laiku, kas jums bÅ«s nepiecieÅ”ams paÅ”ai provizoriskajai analÄ«zei un vienkārÅ”iem pirmajiem eksperimentiem, izlasot dokumentāciju - tas ļaus jums precÄ«zi novērtēt visu darbu. Runājot par populāro veiklo metodiku, aicinu izveidot ā€œuzdevuma parametru novērtÄ“Å”anasā€ biļeti, uz kuras pamata varu sniegt vērtējumu par ā€œsprintaā€ ietvaros paveicamo un sniegt precÄ«zāku tāmi katram. uzdevums.

Tāpēc visefektÄ«vākais Ŕķiet arguments, kas ā€œnetehniskamā€ speciālistam parādÄ«tu, cik daudz laika un resursu mainÄ«sies atkarÄ«bā no vēl jānovērtējamiem parametriem.

Kas datu zinātnē var noiet greizi? Datu vākÅ”ana

Avots: www.habr.com

Pievieno komentāru