I dag er der 100500 Data Science kurser og det har længe været kendt, at der kan tjenes flest penge i Data Science gennem Data Science kurser (hvorfor grave når man kan sælge skovle?). Den største ulempe ved disse kurser er, at de ikke har noget at gøre med rigtigt arbejde: ingen vil give dig rene, behandlede data i det krævede format. Og når du forlader kurset og begynder at løse et reelt problem, dukker der mange nuancer op.
Derfor starter vi en række noter "Hvad kan gå galt med Data Science", baseret på virkelige hændelser, der skete for mig, mine kammerater og kolleger. Vi vil analysere typiske Data Science-opgaver ved hjælp af rigtige eksempler: hvordan dette rent faktisk sker. Lad os starte i dag med dataindsamlingsopgaven.
Og det første folk falder over, når de begynder at arbejde med rigtige data, er faktisk at indsamle disse data, der er mest relevante for os. Nøglebudskabet i denne artikel:
Vi undervurderer systematisk den tid, de ressourcer og den indsats, der kræves for at indsamle, rense og forberede data.
Og vigtigst af alt vil vi diskutere, hvad vi skal gøre for at forhindre dette.
Ifølge forskellige skøn tager rengøring, transformation, databehandling, feature engineering osv. 80-90% af tiden, og analyse 10-20%, mens næsten alt undervisningsmateriale udelukkende fokuserer på analyse.
Lad os se på et simpelt analytisk problem i tre versioner som et typisk eksempel og se, hvad "skærpende omstændigheder" er.
Og som et eksempel vil vi igen overveje lignende variationer af opgaven med at indsamle data og sammenligne fællesskaber for:
- To Reddit-subreddits
- To afsnit af Habr
- To grupper af Odnoklassniki
Betinget tilgang i teorien
Åbn siden og læs eksemplerne, hvis det er tydeligt, afsæt et par timer til læsning, et par timer til koden ved hjælp af eksemplerne og fejlretning. Tilføj et par timer til afhentning. Smid et par timer i reserve (gang med to og tilføj N timer).
Nøglepunkt: Tidsestimater er baseret på antagelser og gætværk om, hvor lang tid det vil tage.
Det er nødvendigt at begynde tidsanalysen ved at estimere følgende parametre for det betingede problem beskrevet ovenfor:
- Hvad er størrelsen af dataene, og hvor meget af det skal indsamles fysisk (*se nedenfor*).
- Hvad er afhentningstiden for den ene plade, og hvor længe skal du vente, før du kan afhente den anden?
- Overvej at skrive kode, der gemmer tilstanden og starter en genstart, når (ikke hvis) alt fejler.
- Find ud af, om vi har brug for autorisation, og indstil tidspunktet for at få adgang via API'en.
- Indstil antallet af fejl som funktion af datakompleksitet - evaluer for en specifik opgave: struktur, hvor mange transformationer, hvad og hvordan udtræk.
- Ret netværksfejl og problemer med ikke-standard projektadfærd.
- Vurder, om de påkrævede funktioner er i dokumentationen, og hvis ikke, hvordan og hvor meget der skal bruges til en løsning.
Det vigtigste er, at for at estimere tid - du skal faktisk bruge tid og kræfter på "rekognoscering i kraft" - først da vil din planlægning være tilstrækkelig. Derfor, uanset hvor meget du bliver presset til at sige "hvor lang tid tager det at indsamle data" - køb dig selv lidt tid til en foreløbig analyse og argumenter med, hvor meget tiden vil variere afhængigt af de reelle parametre for opgaven.
Og nu vil vi demonstrere specifikke eksempler, hvor sådanne parametre vil ændre sig.
Nøglepunkt: Estimatet er baseret på en analyse af nøglefaktorer, der har indflydelse på arbejdets omfang og kompleksitet.
Gætbaseret estimering er en god tilgang, når de funktionelle elementer er små nok, og der ikke er mange faktorer, der i væsentlig grad kan påvirke udformningen af problemet. Men i tilfælde af en række Data Science-problemer bliver sådanne faktorer ekstremt talrige, og en sådan tilgang bliver utilstrækkelig.
Sammenligning af Reddit-fællesskaber
Lad os starte med den enkleste sag (som det viser sig senere). Generelt, for at være helt ærlig, har vi en næsten ideel sag, lad os tjekke vores kompleksitetstjekliste:
- Der er en pæn, overskuelig og dokumenteret API.
- Det er ekstremt enkelt, og vigtigst af alt opnås et token automatisk.
- Der er - med masser af eksempler.
- Et fællesskab, der analyserer og indsamler data på reddit (selv til YouTube-videoer, der forklarer, hvordan man bruger python-indpakning) .
- De metoder, vi har brug for, findes højst sandsynligt i API'et. Desuden ser koden kompakt og ren ud, herunder er et eksempel på en funktion, der samler kommentarer på et indlæg.
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()
Taget fra et udvalg af praktiske værktøjer til indpakning.
På trods af at dette er det bedste tilfælde, er det stadig værd at tage højde for en række vigtige faktorer fra det virkelige liv:
- API-grænser - vi er tvunget til at tage data i batches (søvn mellem anmodninger osv.).
- Indsamlingstid - for en komplet analyse og sammenligning skal du afsætte betydelig tid, bare for edderkoppen at gå gennem subreddit.
- Botten skal køre på en server – du kan ikke bare køre den på din bærbare computer, lægge den i din rygsæk og gå i gang med din virksomhed. Så jeg kørte alt på en VPS. Ved at bruge kampagnekoden habrahabr10 kan du spare yderligere 10 % af prisen.
- Den fysiske utilgængelighed af nogle data (de er synlige for administratorer eller er for svære at indsamle) - dette skal tages i betragtning; i princippet kan ikke alle data indsamles i tide.
- Netværksfejl: Netværk er en smerte.
- Dette er levende reelle data - det er aldrig rent.
Det er selvfølgelig nødvendigt at inddrage disse nuancer i udviklingen. Specifikke timer/dage afhænger af udviklingserfaring eller erfaring med at arbejde med lignende opgaver, dog ser vi, at her er opgaven rent ingeniørmæssig og ikke kræver yderligere kropsbevægelser at løse - alt kan meget godt vurderes, planlægges og udføres.
Sammenligning af Habr sektioner
Lad os gå videre til et mere interessant og ikke-trivielt tilfælde af sammenligning af tråde og/eller dele af Habr.
Lad os tjekke vores kompleksitetstjekliste - her skal du, for at forstå hvert punkt, grave lidt i selve opgaven og eksperimentere.
- Først tror du, at der er en API, men det er der ikke. Ja, ja, Habr har en API, men den er bare ikke tilgængelig for brugere (eller måske virker den slet ikke).
- Så begynder du bare at parse html - "importanmodninger", hvad kunne gå galt?
- Hvordan parser man alligevel? Den enkleste og mest brugte tilgang er at iterere over ID'er, bemærk at det ikke er den mest effektive og vil skulle håndtere forskellige sager - her er et eksempel på tætheden af rigtige ID'er blandt alle eksisterende.
Taget fra artikel. - Rådata pakket ind i HTML oven på nettet er en smerte. For eksempel vil du indsamle og gemme vurderingen af en artikel: du rev scoret ud af html'en og besluttede at gemme det som et tal til videre behandling:
1) int(score) kaster en fejl: da der på Habré er et minus, som for eksempel i linjen “–5” - dette er en bindestreg, ikke et minustegn (uventet, vel?), så kl. på et tidspunkt var jeg nødt til at rejse parseren til live med sådan en frygtelig løsning.
try: score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+") score = int(score_txt) if check_date(date): post_score += scoreDer er muligvis ingen dato, plusser og minusser overhovedet (som vi ser ovenfor i check_date-funktionen, skete dette).
2) Uundgåede specialkarakterer - de kommer, du skal være forberedt.
3) Strukturen ændres afhængigt af postens type.
4) Gamle indlæg kan have en **underlig struktur**.
- I bund og grund skal fejlhåndtering og hvad der kan ske eller ikke sker, håndteres, og du kan ikke med sikkerhed forudsige, hvad der vil gå galt, og hvordan strukturen ellers kan være, og hvad der vil falde af hvor - du skal bare prøve at tage hensyn til de fejl, som parseren kaster.
- Så indser du, at du skal parse i flere tråde, ellers vil parsing i én så tage 30+ timer (dette er rent udførelsestiden for en allerede fungerende enkelt-trådet parser, som sover og ikke falder ind under nogen forbud). I artikel, førte dette på et tidspunkt til en lignende ordning:
Samlet tjekliste efter kompleksitet:
- Arbejde med netværket og html-parsing med iteration og søgning efter ID.
- Dokumenter med heterogen struktur.
- Der er mange steder, hvor koden nemt kan falde.
- Det er nødvendigt at skrive || kode.
- Den nødvendige dokumentation, kodeeksempler og/eller fællesskab mangler.
Den estimerede tid for denne opgave vil være 3-5 gange højere end for indsamling af data fra Reddit.
Sammenligning af Odnoklassniki-grupper
Lad os gå videre til den mest teknisk interessante sag beskrevet. For mig var det interessant, netop fordi det ved første øjekast ser ret trivielt ud, men det viser sig slet ikke at være sådan - så snart du stikker en pind i det.
Lad os starte med vores sværhedstjekliste og bemærke, at mange af dem vil vise sig at være meget sværere, end de ser ud til først:
- Der er en API, men den mangler næsten fuldstændig de nødvendige funktioner.
- Til visse funktioner skal du anmode om adgang via post, det vil sige, at der ikke gives adgang øjeblikkeligt.
- Det er frygtelig dokumenteret (til at begynde med er russiske og engelske termer blandet sammen overalt, og fuldstændig inkonsekvent - nogle gange skal du bare gætte, hvad de vil have dig et eller andet sted) og desuden er designet ikke egnet til at indhente data f.eks. , .
- Kræver en session i dokumentationen, men bruger den faktisk ikke - og der er ingen måde at forstå alle forviklingerne i API-tilstandene på udover at søge rundt og håbe på, at noget vil virke.
- Der er ingen eksempler og intet fællesskab; det eneste støttepunkt ved indsamling af information er et lille i Python (uden mange eksempler på brug).
- Selen ser ud til at være den mest brugbare mulighed, da mange af de nødvendige data er låst.
1) Det vil sige, at autorisation sker gennem en fiktiv bruger (og registrering i hånden).2) Men med Selenium er der ingen garantier for korrekt og gentageligt arbejde (i hvert fald i tilfælde af ok.ru helt sikkert).
3) Ok.ru-webstedet indeholder JavaScript-fejl og opfører sig nogle gange mærkeligt og inkonsekvent.
4) Du skal lave paginering, indlæse elementer osv...
5) API-fejl, som indpakningen giver, skal håndteres akavet, for eksempel sådan her (et stykke eksperimentel kode):
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_commentsMin yndlingsfejl var:
OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)6) I sidste ende ser Selenium + API ud som den mest rationelle mulighed.
- Det er nødvendigt at gemme tilstanden og genstarte systemet, håndtere mange fejl, inklusive inkonsekvent adfærd på webstedet - og disse fejl er ret svære at forestille sig (medmindre du skriver parsere professionelt, selvfølgelig).
Det betingede tidsestimat for denne opgave vil være 3-5 gange højere end for indsamling af data fra Habr. På trods af at vi i tilfældet Habr bruger en frontal tilgang med HTML-parsing, og i tilfældet OK kan vi arbejde med API'en på kritiske steder.
Fund
Uanset hvor meget du skal estimere deadlines "på stedet" (vi planlægger i dag!) for et omfangsrigt databehandlingspipeline-modul, er eksekveringstiden næsten aldrig mulig at estimere selv kvalitativt uden at analysere opgaveparametrene.
På en lidt mere filosofisk bemærkning fungerer agile estimeringsstrategier godt til ingeniøropgaver, men problemer, der er mere eksperimenterende og på en måde "kreative" og udforskende, dvs. mindre forudsigelige, har vanskeligheder, som i eksemplerne på lignende emner, som vi har diskuteret her.
Dataindsamling er selvfølgelig bare et glimrende eksempel – det er som regel en utrolig enkel og teknisk ukompliceret opgave, og djævelen sidder ofte i detaljerne. Og det er netop på denne opgave, at vi kan vise hele rækken af mulige muligheder for, hvad der kan gå galt, og præcis hvor lang tid arbejdet kan tage.
Hvis du ser på opgavens egenskaber uden yderligere eksperimenter, så ligner Reddit og OK: der er en API, en python-indpakning, men i det væsentlige er forskellen enorm. At dømme efter disse parametre ser Habrs pars mere kompliceret ud end OK – men i praksis er det stik modsat, og det er netop det, man kan finde ud af ved at udføre simple eksperimenter for at analysere parametrene for problemet.
Efter min erfaring er den mest effektive tilgang groft at estimere den tid, du skal bruge til selve den foreløbige analyse og enkle første eksperimenter, ved at læse dokumentationen - disse vil give dig et præcist estimat for hele arbejdet. I forhold til den populære agile metodik beder jeg dig oprette en billet til "estimering af opgaveparametre", på baggrund af hvilken jeg kan give en vurdering af, hvad der kan opnås indenfor "sprintet" og give et mere præcist estimat for hver opgave.
Derfor synes det mest effektive argument at være et, der ville vise en "ikke-teknisk" specialist, hvor meget tid og ressourcer vil variere afhængigt af parametre, der endnu ikke skal vurderes.
Kilde: www.habr.com