Què pot sortir malament amb Data Science? Recopilació de dades

Avui dia hi ha 100500 cursos de Data Science i fa temps que se sap que la majoria de diners en Data Science es poden guanyar amb els cursos de Data Science (per què cavar quan es poden vendre pales?). El principal desavantatge d'aquests cursos és que no tenen res a veure amb el treball real: ningú et donarà dades netes i processades en el format requerit. I quan deixes el curs i comences a resoldre un problema real, sorgeixen molts matisos.

Per tant, comencem una sèrie d'apunts "Què pot anar malament amb Data Science", basat en fets reals que em van passar a mi, als meus companys i companys. Analitzarem les tasques típiques de Data Science utilitzant exemples reals: com passa això realment. Comencem avui amb la tasca de recollida de dades.

I el primer amb què la gent ensopega quan comença a treballar amb dades reals és recollir aquestes dades que són més rellevants per a nosaltres. El missatge clau d'aquest article:

Subestimem sistemàticament el temps, els recursos i l'esforç necessaris per recollir, netejar i preparar dades.

I el més important, parlarem de què fer per evitar-ho.

Segons diverses estimacions, la neteja, la transformació, el processament de dades, l'enginyeria de funcions, etc. triguen entre un 80 i un 90% del temps i l'anàlisi entre un 10 i un 20%, mentre que gairebé tot el material educatiu se centra exclusivament en l'anàlisi.

Vegem un problema analític senzill en tres versions com a exemple típic i veiem quines són les “circumstàncies agreujants”.

I com a exemple, de nou, considerarem variacions similars de la tasca de recopilar dades i comparar comunitats per a:

1. Dos subreddits de Reddit
2. Dues seccions d'Habr
3. Dos grups d'Odnoklassniki

Enfocament condicional en teoria

Obriu el lloc i llegiu els exemples, si és clar, reserveu unes hores per a la lectura, unes quantes hores per al codi utilitzant els exemples i la depuració. Afegiu unes hores per a la recollida. Tireu unes hores en reserva (multiplicar per dos i afegir N hores).

Punt clau: les estimacions de temps es basen en suposicions i conjectures sobre quant de temps trigarà.

Cal començar l'anàlisi del temps estimant els paràmetres següents per al problema condicional descrit anteriorment:

• Quina és la mida de les dades i la quantitat que cal recollir-ne físicament (*vegeu a continuació*).
• Quin és el temps de recollida d'un disc i quant de temps has d'esperar per poder recollir el segon?
• Penseu en escriure codi que desi l'estat i comenci un reinici quan (no si) tot falla.
• Esbrineu si necessitem autorització i establiu l'hora per obtenir accés mitjançant l'API.
• Establiu el nombre d'errors en funció de la complexitat de les dades: avalueu una tasca específica: estructura, quantes transformacions, què i com extreure'ls.
• Corregiu errors de xarxa i problemes amb el comportament del projecte no estàndard.
• Avalueu si les funcions requerides es troben a la documentació i, si no, com i quant es necessita per a una solució alternativa.

El més important és que per estimar el temps -en realitat cal dedicar temps i esforços al "reconeixement en vigor"- només llavors la vostra planificació serà adequada. Per tant, per molt que us oblideu a dir "quant de temps es triga a recollir dades", compra-te una mica de temps per a una anàlisi preliminar i argumenta quant variarà el temps en funció dels paràmetres reals de la tasca.

I ara mostrarem exemples concrets on aquests paràmetres canviaran.

Punt clau: l'estimació es basa en una anàlisi dels factors clau que influeixen en l'abast i la complexitat del treball.

L'estimació basada en conjectures és un bon enfocament quan els elements funcionals són prou petits i no hi ha molts factors que puguin influir significativament en el disseny del problema. Però en el cas d'una sèrie de problemes de ciència de dades, aquests factors es tornen extremadament nombrosos i aquest enfocament esdevé inadequat.

Comparació de comunitats de Reddit

Comencem pel cas més senzill (com es veurà més endavant). En general, per ser completament honest, tenim un cas gairebé ideal, comprovem la nostra llista de verificació de complexitat:

• Hi ha una API nítida, clara i documentada.
• És extremadament senzill i, el més important, s'obté un testimoni automàticament.
• Hi embolcall de pitó - amb molts exemples.
• Una comunitat que analitza i recopila dades a reddit (fins i tot a vídeos de YouTube que expliquen com utilitzar l'embolcall de Python) Per exemple.
• Els mètodes que necessitem probablement existeixen a l'API. A més, el codi sembla compacte i net, a continuació es mostra un exemple d'una funció que recull comentaris en una publicació.

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

Agafat de això una selecció d'utilitats convenients per embolicar.

Tot i que aquest és el millor cas, val la pena tenir en compte una sèrie de factors importants de la vida real:

• Límits de l'API: ens veiem obligats a prendre dades per lots (repòs entre sol·licituds, etc.).
• Temps de recollida: per a una anàlisi i comparació completes, haureu de reservar un temps important només perquè l'aranya camini pel subreddit.
• El bot s'ha d'executar en un servidor; no només podeu executar-lo al vostre ordinador portàtil, posar-lo a la motxilla i fer el vostre negoci. Així que ho vaig executar tot en un VPS. Amb el codi promocional habrahabr10 pots estalviar un 10% més del cost.
• La inaccessibilitat física d'algunes dades (són visibles per als administradors o són massa difícils de recollir) - això s'ha de tenir en compte; en principi, no totes les dades es poden recollir en el temps adequat.
• Errors de xarxa: la xarxa és un dolor.
• Això són dades reals vives, mai són pures.

Per descomptat, cal incloure aquests matisos en el desenvolupament. Les hores/dies específiques depenen de l'experiència de desenvolupament o de l'experiència treballant en tasques similars, però, veiem que aquí la tasca és purament d'enginyeria i no requereix moviments corporals addicionals per resoldre - tot es pot avaluar, programar i fer molt bé.

Comparació de seccions Habr

Passem a un cas més interessant i no trivial de comparació de fils i/o seccions d'Habr.

Revisem la nostra llista de comprovació de complexitat: aquí, per entendre cada punt, haureu d'aprofundir una mica en la tasca i experimentar.

• Al principi penseu que hi ha una API, però no n'hi ha. Sí, sí, Habr té una API, però simplement no és accessible per als usuaris (o potser no funciona en absolut).
• Aleshores comenceu a analitzar html: "sol·licituds d'importació", què podria sortir malament?
• Com analitzar de totes maneres? L'enfocament més senzill i utilitzat amb més freqüència és iterar sobre les identificacions, tingueu en compte que no és la més eficient i haurà de gestionar casos diferents; aquí teniu un exemple de la densitat d'identificacions reals entre tots els existents.

  
  Agafat de això articles

• Les dades en brut embolicades en HTML a la part superior del web són un dolor. Per exemple, voleu recollir i desar la qualificació d'un article: heu tret la puntuació de l'html i heu decidit desar-la com a número per a un processament posterior: 

  1) int(puntuació) llança un error: ja que a Habré hi ha un menys, com, per exemple, a la línia "–5": aquest és un guió en, no un signe menys (inesperadament, oi?), així que a En algun moment vaig haver de donar vida a l'analitzador amb una solució tan terrible.

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

  És possible que no hi hagi data, avantatges i inconvenients en absolut (com veiem més amunt a la funció check_date, això va passar).

  2) Personatges especials sense escapar: vindran, cal que estigueu preparat.

  3) L'estructura canvia en funció del tipus de publicació.

  4) Les publicacions antigues poden tenir una **estructura estranya**.

• Essencialment, s'haurà de gestionar la gestió d'errors i el que pot passar o no, i no podeu predir amb certesa què sortirà malament i de quina altra manera pot ser l'estructura i què caurà on; només haureu d'intentar tenir en compte. els errors que llança l'analitzador.
• Aleshores us adoneu que heu d'analitzar diversos fils, en cas contrari, l'anàlisi en un trigarà més de 30 hores (és només el temps d'execució d'un analitzador d'un sol fil que ja funciona, que dorm i no està prohibit). EN això article, això va conduir en algun moment a un esquema similar:

Llista de verificació total per complexitat:

• Treball amb la xarxa i anàlisi html amb iteració i cerca per ID.
• Documents d'estructura heterogènia.
• Hi ha molts llocs on el codi pot caure fàcilment.
• Cal escriure || codi.
• Falta la documentació necessària, els exemples de codi i/o la comunitat.

El temps estimat per a aquesta tasca serà de 3 a 5 vegades més gran que per a la recollida de dades de Reddit.

Comparació dels grups d'Odnoklassniki

Passem al cas descrit tècnicament més interessant. Per a mi, va ser interessant precisament perquè a primer cop d'ull sembla bastant trivial, però no és així en absolut, tan bon punt hi poses un pal.

Comencem amb la nostra llista de comprovació de dificultats i tingueu en compte que molts d'ells seran molt més difícils del que semblen a primera vista:

• Hi ha una API, però gairebé no té les funcions necessàries.
• A determinades funcions cal sol·licitar l'accés per correu, és a dir, la concessió de l'accés no és instantània.
• Està terriblement documentat (per començar, els termes rus i anglès es barregen a tot arreu i de manera totalment inconsistent, de vegades només cal endevinar què volen de tu en algun lloc) i, a més, el disseny no és adequat per obtenir dades, per exemple. , la funció que necessitem.
• Requereix una sessió a la documentació, però en realitat no l'utilitza, i no hi ha manera d'entendre totes les complexitats dels modes de l'API a part de mirar i esperar que alguna cosa funcioni.
• No hi ha exemples ni comunitat; l'únic punt de suport per recopilar informació és un petit embolcall en Python (sense molts exemples d'ús).
• El seleni sembla ser l'opció més viable, ja que moltes de les dades necessàries estan bloquejades.
  1) És a dir, l'autorització es realitza mitjançant un usuari fictici (i el registre manual).

  2) Tanmateix, amb Selenium no hi ha garanties per a un treball correcte i repetible (almenys en el cas d'ok.ru segur).

  3) El lloc web d'Ok.ru conté errors de JavaScript i de vegades es comporta de manera estranya i inconsistent.

  4) Cal fer paginació, carregar elements, etc...

  5) Els errors de l'API que dóna l'embolcall s'hauran de manejar de manera incòmode, per exemple, com aquest (un tros de codi experimental):

  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
  

  El meu error preferit va ser:

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

  6) En definitiva, Selenium + API sembla l'opció més racional.

• Cal desar l'estat i reiniciar el sistema, gestionar molts errors, inclòs el comportament inconsistent del lloc, i aquests errors són bastant difícils d'imaginar (tret que escriviu analitzadors professionalment, és clar).

El temps estimat condicional per a aquesta tasca serà de 3 a 5 vegades més gran que per a la recollida de dades d'Habr. Tot i que en el cas d'Habr fem servir un enfocament frontal amb anàlisi HTML, i en el cas d'OK podem treballar amb l'API en llocs crítics.

Troballes

Per molt que us demani estimar els terminis "al moment" (estem planejant avui!) d'un voluminós mòdul de processament de dades, gairebé mai es pot estimar el temps d'execució, ni tan sols qualitativament, sense analitzar els paràmetres de la tasca.

En una nota una mica més filosòfica, les estratègies d'estimació àgil funcionen bé per a tasques d'enginyeria, però els problemes que són més experimentals i, en certa manera, "creativs" i exploratoris, és a dir, menys previsibles, tenen dificultats, com en els exemples de temes similars , que hem comentat aquí.

Per descomptat, la recollida de dades és només un bon exemple: sol ser una tasca increïblement senzilla i tècnicament poc complicada, i el diable sovint està en els detalls. I és precisament en aquesta tasca on podem mostrar tot el ventall d'opcions possibles sobre què pot sortir malament i quant de temps pot trigar exactament el treball.

Si mireu les característiques de la tasca sense experiments addicionals, Reddit i OK semblen semblants: hi ha una API, un embolcall de Python, però en essència, la diferència és enorme. A jutjar per aquests paràmetres, el paràmetre de Habr sembla més complicat que OK, però a la pràctica és tot el contrari, i això és exactament el que es pot esbrinar fent experiments senzills per analitzar els paràmetres del problema.

Segons la meva experiència, l'enfocament més eficaç és estimar aproximadament el temps que necessitareu per a l'anàlisi preliminar i els primers experiments senzills, llegint la documentació; això us permetrà donar una estimació precisa de tot el treball. Pel que fa a la popular metodologia àgil, us demano que creeu un tiquet per "estimar els paràmetres de la tasca", sobre la base del qual puc fer una avaluació del que es pot aconseguir dins de l'"sprint" i donar una estimació més precisa per a cadascun. tasca.

Per tant, l'argument més eficaç sembla ser aquell que mostraria a un especialista “no tècnic” quant de temps i recursos variaran en funció dels paràmetres que encara s'han d'avaluar.

Font: www.habr.com