Ngayon ay may 100500 na kursong Data Science at matagal nang alam na ang pinakamaraming pera sa Data Science ay maaaring kitain sa pamamagitan ng mga kursong Data Science (bakit maghukay kung maaari kang magbenta ng mga pala?). Ang pangunahing kawalan ng mga kursong ito ay wala silang kinalaman sa totoong trabaho: walang magbibigay sa iyo ng malinis, naprosesong data sa kinakailangang format. At kapag umalis ka sa kurso at nagsimulang malutas ang isang tunay na problema, maraming mga nuances ang lumitaw.
Samakatuwid, nagsisimula kami ng isang serye ng mga tala na "Ano ang maaaring magkamali sa Data Science", batay sa mga totoong kaganapan na nangyari sa akin, sa aking mga kasama at kasamahan. Susuriin namin ang mga karaniwang gawain sa Data Science gamit ang mga totoong halimbawa: kung paano ito aktwal na nangyayari. Magsimula tayo ngayon sa gawaing pangongolekta ng datos.
At ang unang bagay na natitisod ang mga tao kapag nagsimula silang magtrabaho gamit ang totoong data ay ang aktwal na pagkolekta ng data na ito na pinakanauugnay sa amin. Ang pangunahing mensahe ng artikulong ito:
Sistematikong minamaliit namin ang oras, mapagkukunan, at pagsisikap na kinakailangan upang mangolekta, maglinis, at maghanda ng data.
At higit sa lahat, pag-uusapan natin kung ano ang dapat gawin para maiwasan ito.
Ayon sa iba't ibang mga pagtatantya, ang paglilinis, pagbabago, pagproseso ng data, feature engineering, atbp. ay tumatagal ng 80-90% ng oras, at pagsusuri ng 10-20%, habang halos lahat ng materyal na pang-edukasyon ay nakatuon lamang sa pagsusuri.
Tingnan natin ang isang simpleng analytical na problema sa tatlong bersyon bilang isang tipikal na halimbawa at tingnan kung ano ang "nagpapalubha ng mga pangyayari".
At bilang isang halimbawa, muli, isasaalang-alang namin ang mga katulad na pagkakaiba-iba ng gawain ng pagkolekta ng data at paghahambing ng mga komunidad para sa:
- Dalawang Reddit subreddits
- Dalawang seksyon ng Habr
- Dalawang grupo ng Odnoklassniki
Kondisyonal na diskarte sa teorya
Buksan ang site at basahin ang mga halimbawa, kung malinaw ito, maglaan ng ilang oras para sa pagbabasa, ilang oras para sa code gamit ang mga halimbawa at pag-debug. Magdagdag ng ilang oras para sa koleksyon. Magtapon ng ilang oras sa reserba (multiply sa dalawa at magdagdag ng N oras).
Pangunahing Punto: Ang mga pagtatantya ng oras ay batay sa mga pagpapalagay at hula tungkol sa kung gaano ito katagal.
Kinakailangang simulan ang pagsusuri ng oras sa pamamagitan ng pagtantya sa mga sumusunod na parameter para sa kondisyong problema na inilarawan sa itaas:
- Ano ang laki ng data at kung gaano karami ang kailangang pisikal na kolektahin (*tingnan sa ibaba*).
- Ano ang oras ng koleksyon para sa isang tala at gaano katagal ang kailangan mong maghintay bago mo makolekta ang pangalawa?
- Isaalang-alang ang pagsusulat ng code na nagse-save sa estado at magsisimula ng pag-restart kapag (hindi kung) nabigo ang lahat.
- Alamin kung kailangan namin ng pahintulot at itakda ang oras para makakuha ng access sa pamamagitan ng API.
- Itakda ang bilang ng mga error bilang isang function ng pagiging kumplikado ng data - suriin para sa isang partikular na gawain: istraktura, kung gaano karaming mga pagbabagong-anyo, kung ano at kung paano i-extract.
- Ayusin ang mga error sa network at mga problema sa hindi karaniwang gawi ng proyekto.
- Tayahin kung ang mga kinakailangang function ay nasa dokumentasyon at kung hindi, kung gayon kung paano at kung magkano ang kailangan para sa isang solusyon.
Ang pinakamahalagang bagay ay upang matantya ang oras - talagang kailangan mong gumugol ng oras at pagsisikap sa "reconnaissance in force" - pagkatapos lamang ay magiging sapat ang iyong pagpaplano. Samakatuwid, kahit gaano ka itinulak na sabihin ang "gaano katagal upang mangolekta ng data" - bilhin ang iyong sarili ng ilang oras para sa isang paunang pagsusuri at magtaltalan kung magkano ang oras ay mag-iiba depende sa tunay na mga parameter ng gawain.
At ngayon ay magpapakita kami ng mga partikular na halimbawa kung saan magbabago ang mga naturang parameter.
Pangunahing Punto: Ang pagtatantya ay batay sa pagsusuri ng mga pangunahing salik na nakakaimpluwensya sa saklaw at pagiging kumplikado ng gawain.
Ang pagtatantya na batay sa hula ay isang mahusay na diskarte kapag ang mga functional na elemento ay sapat na maliit at walang maraming mga kadahilanan na maaaring makabuluhang makaimpluwensya sa disenyo ng problema. Ngunit sa kaso ng isang bilang ng mga problema sa Data Science, ang mga naturang salik ay nagiging lubhang marami at ang gayong paraan ay nagiging hindi sapat.
Paghahambing ng mga komunidad ng Reddit
Magsimula tayo sa pinakasimpleng kaso (tulad ng lumalabas sa ibang pagkakataon). Sa pangkalahatan, upang maging ganap na tapat, mayroon kaming halos perpektong kaso, tingnan natin ang aming checklist ng pagiging kumplikado:
- Mayroong maayos, malinaw at dokumentadong API.
- Ito ay napaka-simple at ang pinakamahalaga, ang isang token ay awtomatikong nakukuha.
- Mayroon - na may maraming mga halimbawa.
- Isang komunidad na nagsusuri at nangongolekta ng data sa reddit (kahit sa mga video sa YouTube na nagpapaliwanag kung paano gumamit ng python wrapper) .
- Ang mga pamamaraan na kailangan namin ay malamang na umiiral sa API. Bukod dito, mukhang compact at malinis ang code, sa ibaba ay isang halimbawa ng isang function na nangongolekta ng mga komento sa isang post.
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()
Kinuha mula sa isang seleksyon ng mga maginhawang kagamitan para sa pambalot.
Sa kabila ng katotohanan na ito ang pinakamahusay na kaso, sulit pa ring isaalang-alang ang ilang mahahalagang salik mula sa totoong buhay:
- Mga limitasyon ng API - napipilitan kaming kumuha ng data sa mga batch (sleep between requests, etc.).
- Oras ng pagkolekta - para sa kumpletong pagsusuri at paghahambing, kakailanganin mong maglaan ng makabuluhang oras para lang sa spider na makalakad sa subreddit.
- Dapat tumakbo ang bot sa isang serverβhindi mo ito mapapatakbo sa iyong laptop, ilagay ito sa iyong backpack, at gawin ang iyong negosyo. Kaya pinatakbo ko ang lahat sa isang VPS. Gamit ang code na pang-promosyon habrahabr10 maaari kang makatipid ng isa pang 10% ng gastos.
- Ang pisikal na hindi naa-access ng ilang data (nakikita sila ng mga administrador o napakahirap kolektahin) - dapat itong isaalang-alang; sa prinsipyo, hindi lahat ng data ay maaaring kolektahin sa sapat na oras.
- Mga error sa network: Masakit ang networking.
- Ito ay buhay na totoong data - ito ay hindi kailanman dalisay.
Siyempre, kinakailangang isama ang mga nuances na ito sa pag-unlad. Ang mga partikular na oras/araw ay nakasalalay sa karanasan sa pag-unlad o karanasan sa pagtatrabaho sa mga katulad na gawain, gayunpaman, nakikita natin na dito ang gawain ay puro engineering at hindi nangangailangan ng karagdagang mga paggalaw ng katawan upang malutas - lahat ay maaaring masuri nang mabuti, naka-iskedyul at tapos na.
Paghahambing ng mga seksyon ng Habr
Lumipat tayo sa isang mas kawili-wili at hindi maliit na kaso ng paghahambing ng mga thread at/o mga seksyon ng Habr.
Suriin natin ang aming checklist ng pagiging kumplikado - dito, upang maunawaan ang bawat punto, kakailanganin mong maghukay ng kaunti sa mismong gawain at mag-eksperimento.
- Sa una ay iniisip mong mayroong isang API, ngunit wala. Oo, oo, may API ang Habr, ngunit hindi lang ito naa-access ng mga user (o marahil ay hindi ito gumagana).
- Pagkatapos ay sisimulan mo lang ang pag-parse ng html - "mga kahilingan sa pag-import", ano ang maaaring magkamali?
- Paano pa rin mag-parse? Ang pinakasimple at pinakamadalas na ginagamit na diskarte ay ang pag-ulit sa mga ID, tandaan na hindi ito ang pinaka-epektibo at kakailanganing pangasiwaan ang iba't ibang mga kaso - narito ang isang halimbawa ng density ng mga tunay na ID sa lahat ng mga umiiral na.
Kinuha mula sa artikulo. - Ang hilaw na data na nakabalot sa HTML sa itaas ng web ay masakit. Halimbawa, gusto mong kolektahin at i-save ang rating ng isang artikulo: pinunit mo ang marka sa html at nagpasyang i-save ito bilang numero para sa karagdagang pagproseso:
1) int(score) ay nagtatapon ng isang error: dahil sa HabrΓ© mayroong isang minus, tulad ng, halimbawa, sa linyang "β5" - ito ay isang en dash, hindi isang minus sign (nang hindi inaasahan, tama?), kaya sa ilang punto kailangan kong buhayin ang parser sa napakahirap na pag-aayos.
try: score_txt = post.find(class_="score").text.replace(u"β","-").replace(u"+","+") score = int(score_txt) if check_date(date): post_score += scoreMaaaring walang petsa, plus at minus sa lahat (tulad ng nakikita natin sa itaas sa check_date function, nangyari ito).
2) Unescaped espesyal na mga character - sila ay darating, kailangan mong maging handa.
3) Ang istraktura ay nagbabago depende sa uri ng post.
4) Maaaring may **kakaibang istraktura ang mga lumang post.
- Mahalaga, ang paghawak ng error at kung ano ang maaaring mangyari o hindi maaaring mangyari ay kailangang pangasiwaan at hindi mo mahuhulaan kung ano ang magiging mali at kung paano pa ang istraktura at kung ano ang mahuhulog kung saan - kailangan mo lamang na subukan at isaalang-alang ang mga error na ibinabato ng parser.
- Pagkatapos ay napagtanto mo na kailangan mong mag-parse sa ilang mga thread, kung hindi, ang pag-parse sa isa ay aabutin ng 30+ oras (ito ay pulos oras ng pagpapatupad ng isang gumagana nang single-threaded parser, na natutulog at hindi nahuhulog sa ilalim ng anumang mga pagbabawal). SA artikulo, humantong ito sa isang punto sa isang katulad na pamamaraan:
Kabuuang checklist ayon sa pagiging kumplikado:
- Paggawa gamit ang network at pag-parse ng html na may pag-ulit at paghahanap sa pamamagitan ng ID.
- Mga dokumento ng heterogenous na istraktura.
- Mayroong maraming mga lugar kung saan ang code ay madaling mahulog.
- Kailangang magsulat || code.
- Ang kinakailangang dokumentasyon, mga halimbawa ng code, at/o komunidad ay nawawala.
Ang tinantyang oras para sa gawaing ito ay magiging 3-5 beses na mas mataas kaysa sa pagkolekta ng data mula sa Reddit.
Paghahambing ng mga pangkat ng Odnoklassniki
Lumipat tayo sa pinaka-teknikal na kawili-wiling kaso na inilarawan. Para sa akin, ito ay tiyak na kawili-wili dahil sa unang sulyap, ito ay mukhang walang halaga, ngunit hindi ito magiging ganoon talaga - sa sandaling sundutin mo ito ng isang stick.
Magsimula tayo sa aming checklist ng kahirapan at tandaan na marami sa kanila ang magiging mas mahirap kaysa sa una nilang tinitingnan:
- Mayroong isang API, ngunit halos wala itong mga kinakailangang function.
- Sa ilang mga function kailangan mong humiling ng access sa pamamagitan ng koreo, iyon ay, ang pagbibigay ng access ay hindi kaagad.
- Ito ay napakalubha na dokumentado (upang magsimula, ang mga terminong Ruso at Ingles ay pinaghalo sa lahat ng dako, at ganap na hindi pare-pareho - kung minsan kailangan mo lang hulaan kung ano ang gusto nila mula sa iyo sa isang lugar) at, bukod dito, ang disenyo ay hindi angkop para sa pagkuha ng data, halimbawa , .
- Nangangailangan ng session sa dokumentasyon, ngunit hindi ito aktwal na ginagamit - at walang paraan upang maunawaan ang lahat ng mga intricacies ng mga API mode maliban sa pag-ikot at umaasang may gagana.
- Walang mga halimbawa at walang komunidad; ang tanging punto ng suporta sa pagkolekta ng impormasyon ay maliit sa Python (nang walang maraming halimbawa ng paggamit).
- Ang selenium ay tila ang pinaka-magagamit na opsyon, dahil marami sa mga kinakailangang data ang naka-lock.
1) Ibig sabihin, ang awtorisasyon ay nagaganap sa pamamagitan ng isang gawa-gawang gumagamit (at pagpaparehistro sa pamamagitan ng kamay).2) Gayunpaman, sa Selenium walang mga garantiya para sa tama at paulit-ulit na trabaho (hindi bababa sa kaso ng ok.ru para sigurado).
3) Ang website ng Ok.ru ay naglalaman ng mga error sa JavaScript at kung minsan ay kumikilos nang kakaiba at hindi pare-pareho.
4) Kailangan mong gawin ang pagination, paglo-load ng mga elemento, atbp...
5) Ang mga error sa API na ibinibigay ng wrapper ay kailangang pangasiwaan nang awkward, halimbawa, tulad nito (isang piraso ng pang-eksperimentong code):
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_commentsAng paborito kong pagkakamali ay:
OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: β¦)β)6) Sa huli, ang Selenium + API ay mukhang ang pinaka makatwirang opsyon.
- Kinakailangan na i-save ang estado at i-restart ang system, hawakan ang maraming mga error, kabilang ang hindi pantay na pag-uugali ng site - at ang mga error na ito ay medyo mahirap isipin (maliban kung sumulat ka ng mga parser nang propesyonal, siyempre).
Ang pagtatantya ng kondisyonal na oras para sa gawaing ito ay magiging 3-5 beses na mas mataas kaysa sa pagkolekta ng data mula kay Habr. Sa kabila ng katotohanan na sa kaso ng Habr ay gumagamit kami ng frontal na diskarte sa pag-parse ng HTML, at sa kaso ng OK maaari kaming magtrabaho kasama ang API sa mga kritikal na lugar.
Natuklasan
Gaano man kalaki ang kailangan mong tantiyahin ang mga deadline na "on the spot" (pinaplano namin ngayon!) ng isang napakaraming module ng pipeline sa pagpoproseso ng data, ang oras ng pagpapatupad ay halos hindi posible na matantya kahit na husay nang hindi sinusuri ang mga parameter ng gawain.
Sa isang bahagyang mas pilosopikal na tala, ang maliksi na mga diskarte sa pagtatantya ay gumagana nang maayos para sa mga gawain sa engineering, ngunit ang mga problema na mas eksperimental at, sa isang kahulugan, "malikhain" at eksploratoryo, ibig sabihin, hindi gaanong mahuhulaan, ay may mga kahirapan, tulad ng sa mga halimbawa ng mga katulad na paksa , na ating tinalakay dito.
Siyempre, ang pagkolekta ng data ay isang pangunahing halimbawa lamang - ito ay karaniwang isang hindi kapani-paniwalang simple at teknikal na hindi kumplikadong gawain, at ang diyablo ay madalas sa mga detalye. At ito ay tiyak sa gawaing ito na maaari naming ipakita ang buong hanay ng mga posibleng opsyon para sa kung ano ang maaaring magkamali at kung gaano katagal ang trabaho.
Kung susulyapan mo ang mga katangian ng gawain nang walang karagdagang mga eksperimento, magkatulad ang Reddit at OK: mayroong isang API, isang python wrapper, ngunit sa esensya, ang pagkakaiba ay napakalaki. Sa paghusga sa mga parameter na ito, ang mga pars ni Habr ay mukhang mas kumplikado kaysa sa OK - ngunit sa pagsasagawa ito ay lubos na kabaligtaran, at ito mismo ang matutuklasan sa pamamagitan ng pagsasagawa ng mga simpleng eksperimento upang pag-aralan ang mga parameter ng problema.
Sa aking karanasan, ang pinakaepektibong diskarte ay ang halos tantiyahin ang oras na kakailanganin mo para sa paunang pagsusuri mismo at mga simpleng unang eksperimento, pagbabasa ng dokumentasyon - ang mga ito ay magbibigay-daan sa iyo na magbigay ng tumpak na pagtatantya para sa buong trabaho. Sa mga tuntunin ng sikat na agile methodology, hinihiling ko sa iyo na lumikha ng isang tiket para sa "pagtantya ng mga parameter ng gawain", kung saan maaari akong magbigay ng isang pagtatasa kung ano ang maaaring magawa sa loob ng "sprint" at magbigay ng isang mas tumpak na pagtatantya para sa bawat gawain.
Samakatuwid, ang pinakaepektibong argumento ay tila isa na magpapakita sa isang "hindi teknikal" na espesyalista kung gaano karaming oras at mga mapagkukunan ang mag-iiba depende sa mga parameter na hindi pa natatasa.
Pinagmulan: www.habr.com