Sot Ă«shtĂ« 100500 kurse pĂ«r Data Science dhe Ă«shtĂ« e njohur se mĂ« shumĂ« para nĂ« Data Science mund tĂ« fitohen pikĂ«risht nga kurset e Data Science (pse tĂ« gĂ«rmosh, kur mund tĂ« shesĂ«sh lopata?). Minus i madh 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 dĂ«shiruar. Dhe kur dilni nga kurset dhe filloni tĂ« zgjidhni njĂ« problem tĂ« vĂ«rtetĂ« â dalin nĂ« pah shumĂ« nuanca.
Prandaj fillojmĂ« njĂ« seri shĂ«nimesh "ĂfarĂ« mund tĂ« shkojĂ« keq me Data Science", tĂ« bazuara nĂ« ngjarje reale qĂ« mĂ« kanĂ« ndodhur mua, shokĂ«ve dhe kolegĂ«ve tĂ« mi. Do shqyrtojmĂ« me raste reale detyrat tipike tĂ« Data Science: si ndodh nĂ« tĂ« vĂ«rtetĂ«. TĂ« fillojmĂ« sot me problemin e mbledhjes sĂ« tĂ« dhĂ«nave.
Dhe e para nĂ« tĂ« cilĂ«n presidentĂ«t hasin, filluan tĂ« punojnĂ« me tĂ« dhĂ«na reale â Ă«shtĂ« pikĂ«risht mbledhja e kĂ«tyre tĂ« dhĂ«nave qĂ« na interesojnĂ«. Mesazhi kryesor i kĂ«tij artikulli:
Ne sistematikisht nënvlerësojmë kohën, burimet dhe përpjekjet për mbledhjen, pastrimin dhe përgatitjen e të dhënave.
Dhe më kryesorja, do diskutojmë se çfarë të bëjmë që të mos e lejojmë këtë.
Sipas vlerësimeve të ndryshme, pastrimi, transformimi, përpunimi i të dhënave, inxhinieria e veçorive etj. zënë 80-90% të kohës, dhe analiza 10-20%, ndërsa praktiksht i gjithë materiali mësimor përqendrohet ekskluzivisht në analizë.
Le të shqyrtojmë si një shembull tipik një detyrë analitike të thjeshtë në tri variante dhe të shohim se çfarë janë "rrethanat njollosëse".
Dhe për shembull po ashtu, ne do të shqyrtojmë variacione të tilla të detyrës së mbledhjes së të dhënave dhe krahasimit të komuniteteve për:
- Dy subreddite në Reddit
- Dy seksione në Habr
- Dy grupe në Odnoklassniki
Qasja kondicionale në teori
Hapni faqen dhe lexoni shembuj, nëse është e qartë, planifikoni disa orë për leximin, disa orë për kodin sipas shembujve dhe debug. Shtoni disa orë për mbledhjen. Shtoni disa orë për rezervë (shumoni me dy dhe shtoni N orë).
Pika kryesore: vlerësimi temporal bazohet në supozime dhe hamendje se sa do të zgjasë.
Të filloni analizën e kohës është e nevojshme që të bëni vlerësimin e parametrave të mëposhtëm për detyrën e kushtezuar, të përshkruar më lart:
- Cila është madhësia e të dhënave dhe sa prej saj nevojitet fizikisht për t'u mbledhur (*shih më poshtë*).
- Cili është koha e mbledhjes së një regjistrimi dhe sa duhet të prisni para se të mund të mbledhni të dytën.
- Të krijoni një kod që ruan gjendjen dhe fillon rinisjen, kur (e jo nëse) gjithçka dështon.
- Të kuptojmë nëse na nevojitet autentifikimi dhe të parashikojmë kohën për të marrë qasje përmes API.
- TĂ« parashikojmĂ« numrin e gabimeve si funksion tĂ« kompleksitetit tĂ« tĂ« dhĂ«nave â tĂ« vlerĂ«sojmĂ« pĂ«r njĂ« detyrĂ« tĂ« caktuar: struktura, sa transformime, çfarĂ« dhe si e nxjerrim.
- Të parashikojmë gabimet e rrjetit dhe problemet me sjellje jostandarde të projektit.
- Të vlerësojmë nëse funksionet e nevojshme janë në dokumentacion dhe nëse jo, atëherë si dhe sa është e nevojshme për një zgjidhje alternative.
MĂ« e rĂ«ndĂ«sishmja, pĂ«r tĂ« vlerĂ«suar kohĂ«n â ju faktikisht duhet tĂ« shpenzoni kohĂ« dhe pĂ«rpjekje pĂ«r "zhbllokimin e situatĂ«s" â vetĂ«m atĂ«herĂ« planifikimi juaj do tĂ« jetĂ« adekuat. Pra, pavarĂ«sisht se si ju pĂ«rpiqen tĂ« thonĂ« "sa kohĂ« nevojitet pĂ«r mbledhjen e tĂ« dhĂ«nave" â merrni kohĂ« pĂ«r njĂ« analizĂ« paraprake dhe argumentoni se sa kohĂ« do tĂ« variĂ«ren nĂ« varĂ«si tĂ« parametrave realĂ« tĂ« detyrĂ«s.
Dhe tani do të ilustrojmë shembuj konkretë, ku këta parametra do të ndryshojnë.
Pika kyçe: vlerësimi bazohet në analizën e faktorëve kyç që ndikojnë në sasinë dhe kompleksitetin e punës.
VlerĂ«simi, i bazuar nĂ« supozime â Ă«shtĂ« njĂ« qasje e mirĂ« kur elementĂ«t funksionalĂ« janĂ« mjaft tĂ« vegjĂ«l dhe nuk ka shumĂ« faktorĂ« qĂ« mund tĂ« ndikojnĂ« dukshĂ«m nĂ« strukturĂ«n e detyrĂ«s. Por nĂ« rastin e njĂ« sĂ«rĂ« detyrash nĂ« ShkencĂ«n e tĂ« DhĂ«nave, kĂ«ta faktorĂ« bĂ«hen jashtĂ«zakonisht tĂ« shumtĂ« dhe kjo qasje bĂ«het e papĂ«rshtatshme.
Krahasimi i komuniteteve në Reddit
Të fillojmë me rastin më të thjeshtë (siç do të rezultojë më vonë). Në të vërtetë, nëse jemi të sinqertë, kemi përpara një rast praktikisht ideal, le të kontrollojmë listën tonë të kontrollit për kompleksitetin:
- Ka një API të qartë, të kuptueshme dhe të dokumentuar.
- Shumë e thjeshtë dhe më e rëndësishmja fitohet automatikisht një token.
- Ka â me njĂ« mori shembujsh.
- Komuniteti që merret me analizën dhe mbledhjen e të dhënave në Reddit (përfshirë deri në video në YouTube që shpjegojnë se si të përdorni python wrapper) .
- Metodat që na duhen ndoshta ekzistojnë në API. Për më tepër, kodi duket kompakt dhe i pastër, më poshtë është një shembull i funksionit që mbledh komentet për postimin.
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()
Marrë nga përmbledhja e mjeteve të përshtatshme për paketimin.
Megjithëse kemi rastin më të mirë përpara nesh, megjithatë është e nevojshme të merret parasysh një sërë faktorësh të rëndësishëm nga jeta reale:
- KufijtĂ« e API-sĂ« â jemi tĂ« detyruar tĂ« marrim tĂ« dhĂ«nat nĂ« grupe (tĂ« presim midis kĂ«rkesave, etj.).
- Koha e mbledhjes â pĂ«r njĂ« analizĂ« tĂ« plotĂ« dhe krahasim, do tĂ« duhen rĂ«ndĂ«sisht kohĂ« vetĂ«m pĂ«r kĂ«rkuesi pĂ«r tĂ« kaluar nĂ«pĂ«r subredit.
- RobotĂ«t duhet tĂ« funksionojnĂ« nĂ« server â nuk mund ta filloni thjesht nĂ« laptop, ta vendosni nĂ« çantĂ« dhe tĂ« shkoni pĂ«r biznes. Prandaj, unĂ« kam filluar gjithçka nĂ« VPS. Me kodin e zbritjes habrahabr10 mund tĂ« kurseni edhe 10% tĂ« çmimit.
- PamundĂ«sia fizike pĂ«r tĂ« aksesuar disa tĂ« dhĂ«na (ato janĂ« tĂ« dukshme pĂ«r administratoret ose janĂ« shumĂ« tĂ« vĂ«shtira pĂ«r t'u mbledhur) â duhet ta marrim parasysh, jo tĂ« gjitha tĂ« dhĂ«nat mund tĂ« mblidhen brenda njĂ« kohe tĂ« arsyeshme.
- Gabimet e punës në rrjet: punimi me rrjetin është e dhimbshme.
- KĂ«to janĂ« tĂ« dhĂ«na reale â ato nuk janĂ« kurrĂ« tĂ« pastra.
Sigurisht, Ă«shtĂ« e nevojshme tĂ« merret parasysh kĂ«to nuanca nĂ« zhvillim. OrĂ«t/ditat e sakta varen nga pĂ«rvoja e zhvillimit ose pĂ«rvoja e punĂ«s me detyra tĂ« ngjashme, megjithatĂ« ne shohim se kĂ«tu detyra Ă«shtĂ« ekskluzivisht inxhinierike dhe nuk kĂ«rkon lĂ«vizje tĂ« tjera shtesĂ« pĂ«r zgjidhje â gjithçka mund tĂ« vlerĂ«sohet, tĂ« pĂ«rshkruhet dhe tĂ« bĂ«het shumĂ« mirĂ«.
Krahasimi i seksioneve të Habrës
Kaloim në një rast më interesant dhe jo trivial, duke krahasuar rrjedhat dhe/ose seksionet e Habrës.
Le tĂ« kontrollojmĂ« listĂ«n tonĂ« tĂ« komplikiave â kĂ«tu, pĂ«r tĂ« kuptuar çdo pikĂ«, do tĂ« duhet tĂ« eksperimentoni pak me detyrĂ«n dhe tĂ« provoni.
- Fillimisht mendoni se ka një API, por nuk ka. Po, Habra ka API, por ai nuk është në dispozicion për përdoruesit (ndoshta as nuk funksionon).
- Pastaj thjesht filloni tĂ« parse html â «import requests», çfarĂ« mund tĂ« shkojĂ« keq?
- Dhe si mund tĂ« parse? Qasja mĂ« e thjeshtĂ« dhe e pĂ«rdorur shpesh Ă«shtĂ« tĂ« iteroni mbi ID, do tĂ« theksojmĂ« se nuk Ă«shtĂ« metoda mĂ« efektive dhe do tĂ« duhen tĂ« pĂ«rpunohen raste tĂ« ndryshme â pĂ«r shembull, densiteti i ID-ve reale nĂ« mesin e tĂ« gjithĂ« atyre qĂ« ekzistojnĂ«.
MarrĂ« nga artikuj. - TĂ« dhĂ«nat e papĂ«rpunuara, tĂ« mbĂ«shtjella nĂ« HTML sipĂ«r rrjetit â janĂ« njĂ« dhimbje. PĂ«r shembull, dĂ«shironi tĂ« mbledhni dhe ruani vlerĂ«simin e artikullit: e nxorrĂ«t score nga html dhe vendosĂ«t ta ruani si numĂ«r pĂ«r pĂ«rpunim tĂ« mĂ«tejshĂ«m:Â
1) int(score) shkakton njĂ« gabim: pasi nĂ« Habra minus, si nĂ« rreshtin "â5" â Ă«shtĂ« njĂ« lidhĂ«se e shkurtĂ«r, jo njĂ« shenjĂ« minusi (papritur, apo jo?), prandaj nĂ« njĂ« moment duhej ta ngrihnim parser-in nĂ« jetĂ« me njĂ« fikso tĂ« tillĂ« tĂ« tmerrshĂ«m.
provoni: score_txt = post.find(class_="score").text.replace(u"â","-").replace(u"+","+") score = int(score_txt) nĂ«se kontrolloni datĂ«n (date): post_score += scoreDatat, pluset dhe minuset mund tĂ« mos ekzistojnĂ« fare (siç e shohim mĂ« lart nĂ« funksionin check_date, dhe kĂ«shtu ka ndodhur).
2) Simbolet speciale tĂ« paekranuara â ato do tĂ« vijnĂ«, duhet tĂ« jeni gati.
3) Strukturat ndryshojnë varësisht nga lloji i postit.
4) Postet e vjetra mund të kenë **strukturë të çuditshme**.
- NĂ« thelb, procesi i pĂ«rpunimit tĂ« gabimeve dhe çfarĂ« mund ose s'mund tĂ« ndodhĂ« do tĂ« duhet tĂ« pĂ«rballeni dhe nuk mund tĂ« parashikohet me siguri se çfarĂ« do tĂ« shkojĂ« keq dhe si mund tĂ« jetĂ« ndryshe struktura dhe se çfarĂ« do tĂ« bjerĂ« â ndoshta do t'ju duhet tĂ« provoni dhe tĂ« merrni parasysh gabimet qĂ« jep parser-i.
- Më pas kuptoni se duhet të parse në disa rrjedha në të kundërt, procesi në një të vetme do të zgjasë 30+ orë (ky është thjesht koha e ekzekutimit të parser-it të vetëm që fle dhe nuk bie nën asnjë ndalese). Në artikull, kjo solli një moment të ngjashëm në skemën e tillë:
Kështu, lista e kontrollit për vështirësinë:
- Puna me rrjetin dhe parse HTML me iterim dhe kalim sipas ID.
- Dokumentet kanë strukturë të heterogjene.
- Ka shumë vende ku kodi mund të dështojë lehtësisht.
- Nevojitet të shkruhet || kodi.
- Mungojnë dokumentacioni i nevojshëm, shembujt e kodit dhe\/ose komuniteti.
Vlerësimi kushtetues i kohës për këtë detyrë do të jetë 3-5 herë më i lartë, sesa për mbledhjen e të dhënave nga Reddit.
Krahasimi i grupeve në Odnoklassniki
TĂ« kalojmĂ« nĂ« rastin mĂ« teknologjikisht tĂ« interesant pĂ«rveç atyre qĂ« janĂ« pĂ«rmendur. PĂ«r mua, ai ishte interesant pikĂ«risht pĂ«r faktin se nĂ« dukje duket mjaft trivial, por nuk Ă«shtĂ« krejtĂ«sisht i tillĂ« â sapo tĂ« bĂ«ni njĂ« prekje nĂ« tĂ«.
Do të fillojmë me listën tonë të kontrollit për vështirësinë dhe do të theksojmë se shumë nga ato do të rezultojnë më të komplikuara se si duken në fillim:
- API ekziston, por i mungojnë pothuajse të gjitha funksionet e nevojshme.
- Për disa funksione duhet të kërkoni akses me email, domethënë dhënia e aksesit nuk është e menjëhershme.
- Dokumentimi Ă«shtĂ« jashtĂ«zakonisht i dobĂ«t (tĂ« fillojmĂ« me faktin se terma rusĂ« dhe anglishte pĂ«rzihen kudo, nĂ« njĂ« mĂ«nyrĂ« krejtĂ«sisht tĂ« paparashikueshme â ndonjĂ«herĂ« duhet thjesht tĂ« gjesh se çfarĂ« po kĂ«rkohet prej teje diku) .
- KĂ«rkon seancĂ« nĂ« dokumentacion, ndĂ«rsa nĂ« praktikĂ« nuk e pĂ«rdor atĂ« â dhe nuk ka asnjĂ« mĂ«nyrĂ« pĂ«r tĂ« kuptuar tĂ« gjitha nuancat e modĂ«s sĂ« API, pĂ«rveç tĂ« provohet dhe shpresohet qĂ« diçka do tĂ« funksionojĂ«.
- Mungojnë shembuj dhe komuniteti, pika e vetme e mbështetjes për mbledhjen e informacionit është një në Python (pa shumë shembuj përdorimi).
- Mënyra më funksionale duket të jetë Selenium, pasi shumë të dhëna të nevojshme janë nën mbrojtje.
1) Pra, ndodh autorizimi përmes një përdoruesi të rremë (dhe regjistrimi manual).2) Megjithatë, me Selenium nuk ka garantira për funksionimin e saktë dhe të përsëritshëm (sigurisht në rastin me ok.ru).
3) Site Ok.ru përmban gabime JavaScript dhe ndonjëherë sillet çuditshëm dhe pa një qëndrim të qartë.
4) Duhet të merremi me paginimin, ngarkimin e elementeve, etj...
5) Gabimet e API që jep wrapper-it do të duhet të përpunohen në mënyrë të përpiktë, për shembull, kështu (një copë kod eksperimental):
def get_comments(args, context, discussions): pause = 1 if args.extract_comments: all_comments = set() #ka kuptim të mbani gjurmët e diskutimeve të përpunuara tashmë për diskutim në tqdm(discussions): përpiqem: comments = get_comments_from_discussion_via_api(context, discussion) përjashto odnoklassniki.api.OdnoklassnikiError si e: nëse "NOT_FOUND" në str(e): comments = set() tjetër: print(e) bp() kaloni all_comments |= comments time.sleep(pause) return all_commentsGabimi im i preferuar ishte:
OdnoklassnikiError("Gabim(kodi: 'None', pĂ«rshkrimi: 'gabim HTTP', metoda: 'discussions.getComments', parametra: âŠ)")6) NĂ« fund, mundĂ«sia Selenium + API duket tĂ« jetĂ« mundĂ«sia mĂ« e arsyeshme.
- Nevoja pĂ«r ruajtjen e gjendjes dhe rikthimin e sistemit, pĂ«rpunimi i shumĂ« gabimeve, pĂ«rfshirĂ« sjelljen e paqĂ«ndrueshme tĂ« site-it â pĂ«r mĂ« tepĂ«r, kĂ«to gabime janĂ« mjaft tĂ« vĂ«shtira pĂ«r t'u imagjinuar (nĂ«se nuk jeni profesionist nĂ« shkruarjen e parserĂ«ve, natyrisht).
Vlerësimi i kushtëzuar i kohës për këtë detyrë do të jetë nga 3-5 herë më i lartë se sa për mbledhjen e të dhënave nga Habra. Pavarësisht se në rastin e Habra ne përdorim një qasje ballore me parsing të HTML-së, në rastin e OK ne mund të punojmë me API në vendet kritike.
PĂ«rfundimet
Pavarësisht se si mund të kërkohet vlerësimi i afateve "në vend" (ne kemi planifikim sot!), volumi i modulit të harduerit të procesit të të dhënave është praktikisht e pamundur të vlerësohet cilësisht pa analizuar parametrat e projektit.
Nëse flasim pak më filozofikisht, strategjitë e vlerësimit në agile i përshtaten mirë detyrave inxhinierike, por me detyra më eksperimentale dhe, në një farë mënyre, "kreative" dhe kërkuese, pra, më pak të parashikueshme, lindin vështirësi, si në shembujt që analizuam këtu.
Sigurisht, mbledhja e tĂ« dhĂ«nave Ă«shtĂ« njĂ« shembull ilustrativ â zakonisht kjo detyrĂ« duket jashtĂ«zakonisht e lehtĂ« dhe teknikisht jo e komplikuar, dhe pikĂ«risht nĂ« detaje kĂ«tu shpesh fshihet djalli. Dhe pikĂ«risht nĂ« kĂ«tĂ« detyrĂ« Ă«shtĂ« e mundur tĂ« tregohet e gjithĂ« spektri i mundĂ«sive se çfarĂ« mund tĂ« shkojĂ« keq dhe sa shumĂ« mund tĂ« zgjatet puna.
NĂ«se shikoni njĂ« herĂ« pĂ«r tĂ« parĂ« karakteristikat e detyrĂ«s pa eksperimente tĂ« tjera, Reddit dhe OK duken tĂ« ngjashme: janĂ« me API, py wrapper, por nĂ« thelb, ndryshimi Ă«shtĂ« gjigand. NĂ«se gjykohet sipas kĂ«tyre parametrave, parser-i i HabrĂ«s duket mĂ« i komplikuar se OK â ndĂ«rsa nĂ« praktikĂ« Ă«shtĂ« krejtĂ«sisht e kundĂ«rta dhe pikĂ«risht kĂ«tĂ« mund ta zbulojmĂ« duke kryer eksperimente tĂ« thjeshta pĂ«r analizĂ«n e parametrave tĂ« detyrĂ«s.
Nga pĂ«rvoja ime, qasja mĂ« efektive Ă«shtĂ« njĂ« vlerĂ«sim i pĂ«rafĂ«rt i kohĂ«s qĂ« do t'ju nevojitet pĂ«r analizĂ«n preliminare dhe eksperimentet e para tĂ« thjeshta, leximi i dokumentacionit â ato do t'ju lejojnĂ« tĂ« jepni njĂ« vlerĂ«sim tĂ« saktĂ« pĂ«r tĂ« gjithĂ« punĂ«n. Me terma tĂ« metodologjisĂ« popullore agile â kĂ«rkoj tĂ« krijohet njĂ« biletĂ« pĂ«r "vlerĂ«simin e parametrave tĂ« detyrĂ«s", mbi bazĂ«n e sĂ« cilĂ«s mund tĂ« jap njĂ« vlerĂ«sim pĂ«r atĂ« qĂ« Ă«shtĂ« e mundur tĂ« realizohet brenda "sprintit" dhe tĂ« jap njĂ« vlerĂ«sim mĂ« tĂ« saktĂ« pĂ«r secilĂ«n detyrĂ«.
Prandaj duket se argumenti më efektiv është ai që do të tregonte "specialistit jo teknik" sa shumë do të variojë koha dhe burimet në varësi të parametrave që ende duhet të vlerësohen.
Burimi: habr.com
