Que pode saír mal con Data Science? Recollida de datos

Hoxe hai 100500 cursos de Data Science e hai tempo que se sabe que a maior parte do diñeiro en Data Science pódese gañar a través dos cursos de Data Science (por que cavar cando podes vender palas?). A principal desvantaxe destes cursos é que non teñen nada que ver co traballo real: ninguén che dará datos limpos e procesados ​​no formato necesario. E cando abandonas o curso e comezas a resolver un problema real, xorden moitos matices.

Por iso, comezamos unha serie de notas "Que pode saír mal con Data Science", baseadas en feitos reais que me sucederon a min, aos meus compañeiros e compañeiras. Analizaremos as tarefas típicas de Data Science usando exemplos reais: como isto ocorre realmente. Comezamos hoxe coa tarefa de recollida de datos.

E o primeiro co que a xente tropeza cando comeza a traballar con datos reais é recoller estes datos que son máis relevantes para nós. A mensaxe clave deste artigo:

Subestimamos sistemáticamente o tempo, os recursos e o esforzo necesarios para recoller, limpar e preparar datos.

E o máis importante, discutiremos que facer para evitar isto.

Segundo varias estimacións, a limpeza, a transformación, o procesamento de datos, a enxeñería de características, etc. levan un 80-90% do tempo e a análise un 10-20%, mentres que case todo o material educativo céntrase exclusivamente na análise.

Vexamos un problema analítico sinxelo en tres versións como exemplo típico e vexamos cales son as “circunstancias agravantes”.

E como exemplo, de novo, consideraremos variacións similares na tarefa de recoller datos e comparar comunidades para:

1. Dous subreddits de Reddit
2. Dúas seccións de Habr
3. Dous grupos de Odnoklassniki

Aproximación condicional en teoría

Abre o sitio e le os exemplos, se está claro, reserva unhas horas para ler, unhas horas para o código usando os exemplos e a depuración. Engade unhas horas para a recollida. Botar unhas horas en reserva (multiplicar por dous e engadir N horas).

Punto clave: as estimacións de tempo baséanse en suposicións e suposicións sobre canto tempo levará.

É necesario comezar a análise do tempo estimando os seguintes parámetros para o problema condicional descrito anteriormente:

• Cal é o tamaño dos datos e cantos hai que recoller fisicamente (*ver máis abaixo*).
• Cal é o tempo de recollida dun disco e canto tempo tes que esperar para poder recoller o segundo?
• Considere escribir código que garde o estado e inicie un reinicio cando (non se) todo falla.
• Descubra se necesitamos autorización e establece o momento para obter acceso a través da API.
• Establece o número de erros en función da complexidade dos datos: avalía para unha tarefa específica: estrutura, cantas transformacións, que e como extraer.
• Corrixir erros de rede e problemas co comportamento do proxecto non estándar.
• Avalía se as funcións requiridas están na documentación e, se non, como e canto se necesita para unha solución alternativa.

O máis importante é que para estimar o tempo -de feito é preciso dedicar tempo e esforzo ao "recoñecemento en vigor"- só entón a súa planificación será adecuada. Polo tanto, por moito que se lle empurra a dicir "canto tempo leva recoller datos": cómpre tempo para unha análise preliminar e argumente canto variará o tempo dependendo dos parámetros reais do problema.

E agora imos demostrar exemplos específicos onde tales parámetros cambiarán.

Punto clave: a estimación baséase nunha análise de factores clave que inflúen no alcance e complexidade do traballo.

A estimación baseada en suposicións é un bo enfoque cando os elementos funcionais son o suficientemente pequenos e non hai moitos factores que poidan influír significativamente no deseño do problema. Pero no caso dunha serie de problemas de Data Science, tales factores fanse extremadamente numerosos e tal enfoque vólvese inadecuado.

Comparación de comunidades de Reddit

Comecemos polo caso máis sinxelo (como se verá máis tarde). En xeral, para ser completamente honesto, temos un caso case ideal, comprobemos a nosa lista de verificación de complexidade:

• Hai unha API ordenada, clara e documentada.
• É moi sinxelo e o máis importante é que un token obtén automaticamente.
• Ten envoltorio de pitón - con moitos exemplos.
• Unha comunidade que analiza e recolle datos en reddit (mesmo para vídeos de YouTube que explican como usar o envoltorio de Python) Por exemplo.
• Os métodos que necesitamos probablemente existan na API. Ademais, o código parece compacto e limpo, a continuación móstrase un exemplo dunha función que recolle comentarios nunha publicación.

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

Tomado de isto unha selección de utilidades convenientes para envolver.

A pesar de que este é o mellor caso, aínda paga a pena ter en conta unha serie de factores importantes da vida real:

• Límites da API: vémonos obrigados a tomar datos por lotes (suspensión entre solicitudes, etc.).
• Tempo de recollida: para unha análise e comparación completas, terás que reservar un tempo significativo só para que a araña atravese o subreddit.
• O bot debe executarse nun servidor; non podes executalo no teu portátil, metelo na mochila e facer o teu negocio. Entón, executei todo nun VPS. Usando o código promocional habrahabr10 podes aforrar outro 10% do custo.
• A inaccesibilidade física dalgúns datos (son visibles para os administradores ou son demasiado difíciles de recoller): hai que telo en conta; en principio, non todos os datos poden recollerse no tempo adecuado.
• Erros de rede: a rede é unha dor.
• Estes son datos reais vivos; nunca son puros.

Por suposto, é necesario incluír estes matices no desenvolvemento. As horas/días específicos dependen da experiencia de desenvolvemento ou da experiencia traballando en tarefas similares, non obstante, vemos que aquí a tarefa é puramente de enxeñería e non require movementos corporais adicionais para resolver - todo pódese avaliar, programar e facer moi ben.

Comparación de seccións Habr

Pasemos a un caso máis interesante e non trivial de comparar fíos e/ou seccións de Habr.

Vexamos a nosa lista de verificación de complexidade: aquí, para comprender cada punto, terás que afondar un pouco na tarefa e experimentar.

• Ao principio pensas que hai unha API, pero non a hai. Si, si, Habr ten unha API, pero simplemente non é accesible para os usuarios (ou quizais non funcione en absoluto).
• Entón comeza a analizar html - "solicitudes de importación", que podería saír mal?
• Como analizar de todos os xeitos? O enfoque máis sinxelo e usado con frecuencia é iterar sobre os ID, teña en conta que non é o máis eficiente e terá que xestionar diferentes casos: aquí tes un exemplo da densidade de ID reais entre todos os existentes.

  
  Tomado de isto artigos.

• Os datos en bruto envoltos en HTML na parte superior da web son unha dor. Por exemplo, quere recoller e gardar a clasificación dun artigo: arrincou a puntuación do html e decidiu gardala como número para procesala posteriormente: 

  1) int(puntuación) lanza un erro: xa que en Habré hai un menos, como, por exemplo, na liña "–5" - este é un guión en, non un signo menos (inesperadamente, non?), así que en nalgún momento tiven que dar vida ao analizador cunha solución 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
  

  Pode que non haxa data, máis e menos (como vemos arriba na función check_date, isto ocorreu).

  2) Personaxes especiais sen escapar: virán, debes estar preparado.

  3) A estrutura cambia en función do tipo de posto.

  4) As publicacións antigas poden ter unha **estrutura estraña**.

• Esencialmente, o manexo de erros e o que pode ocorrer ou non terá que ser tratado e non pode predecir con certeza o que vai fallar e de que outra forma pode ser a estrutura e o que caerá onde; só terá que tentar ter en conta. os erros que arroxa o analizador.
• Entón dáse conta de que cómpre analizar en varios fíos, se non, a análise nun levará máis de 30 horas (este é puramente o tempo de execución dun analizador de fío único que xa funciona, que dorme e non está prohibido). EN isto artigo, isto levou nalgún momento a un esquema similar:

Lista de verificación total por complexidade:

• Traballar coa rede e análise html con iteración e busca por ID.
• Documentos de estrutura heteroxénea.
• Hai moitos lugares onde o código pode caer facilmente.
• É necesario escribir || código.
• Falta a documentación necesaria, exemplos de código e/ou comunidade.

O tempo estimado para esta tarefa será 3-5 veces maior que para a recollida de datos de Reddit.

Comparación dos grupos de Odnoklassniki

Pasemos ao caso técnicamente máis interesante descrito. Para min, foi interesante precisamente porque, a primeira vista, parece bastante trivial, pero non resulta ser así, tan pronto como lle metes un pau.

Comecemos coa nosa lista de verificación de dificultades e teña en conta que moitos deles resultarán moito máis difíciles do que parecen ao principio:

• Hai unha API, pero carece case por completo das funcións necesarias.
• Para determinadas funcións cómpre solicitar o acceso por correo, é dicir, a concesión do acceso non é instantánea.
• Está terriblemente documentado (para comezar, os termos ruso e inglés mestúranse en todas partes e de forma completamente inconsistente - ás veces só tes que adiviñar o que queren de ti nalgún lugar) e, ademais, o deseño non é axeitado para obter datos, por exemplo , a función que necesitamos.
• Require unha sesión na documentación, pero en realidade non a usa, e non hai forma de comprender todas as complejidades dos modos da API que non sexa mirar e esperar que algo funcione.
• Non hai exemplos nin comunidade; o único punto de apoio para recoller información é un pequeno envoltorio en Python (sen moitos exemplos de uso).
• O selenio parece ser a opción máis viable, xa que moitos dos datos necesarios están bloqueados.
  1) É dicir, a autorización realízase a través dun usuario ficticio (e rexistro manual).

  2) Non obstante, con Selenium non hai garantías para un traballo correcto e repetible (polo menos no caso de ok.ru seguro).

  3) O sitio web de Ok.ru contén erros de JavaScript e ás veces compórtase de forma estraña e inconsistente.

  4) Debes facer paxinación, cargar elementos, etc...

  5) Os erros da API que dá o envoltorio terán que ser tratados de forma torpe, por exemplo, así (unha peza de código 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
  

  O meu erro favorito foi:

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

  6) En definitiva, Selenium + API parece a opción máis racional.

• É necesario gardar o estado e reiniciar o sistema, xestionar moitos erros, incluído o comportamento inconsistente do sitio, e estes erros son bastante difíciles de imaxinar (a menos que escribas analizadores profesionalmente, claro).

A estimación de tempo condicional para esta tarefa será 3-5 veces maior que para a recollida de datos de Habr. A pesar de que no caso de Habr utilizamos un enfoque frontal con análise HTML, e no caso de OK podemos traballar coa API en lugares críticos.

Descubrimentos

Por moito que teña que estimar os prazos "in situ" (estamos a planificar hoxe!) dun voluminoso módulo de pipeline de procesamento de datos, case nunca é posible estimar o tempo de execución nin sequera cualitativamente sen analizar os parámetros da tarefa.

Nunha nota un pouco máis filosófica, as estratexias de estimación áxil funcionan ben para tarefas de enxeñaría, pero problemas que son máis experimentais e, en certo sentido, "creativos" e exploratorios, é dicir, menos previsibles, teñen dificultades, como nos exemplos de temas similares , que aquí comentamos.

Por suposto, a recollida de datos é só un excelente exemplo: adoita ser unha tarefa incriblemente sinxela e tecnicamente sen complicacións, e o demo adoita estar nos detalles. E é precisamente nesta tarefa onde podemos mostrar toda a gama de opcións posibles para o que pode saír mal e exactamente canto tempo pode levar o traballo.

Se miras as características da tarefa sen experimentos adicionais, entón Reddit e OK parecen similares: hai unha API, un envoltorio de Python, pero en esencia, a diferenza é enorme. A xulgar por estes parámetros, o pars de Habr parece máis complicado que OK, pero na práctica é todo o contrario, e isto é exactamente o que se pode descubrir realizando experimentos sinxelos para analizar os parámetros do problema.

Segundo a miña experiencia, o enfoque máis eficaz é estimar aproximadamente o tempo que necesitará para a análise preliminar en si e os primeiros experimentos sinxelos, lendo a documentación, estes permitirán dar unha estimación precisa de todo o traballo. En canto á popular metodoloxía áxil, pídoche que crees un ticket para "estimar os parámetros da tarefa", en base ao cal podo facer unha valoración do que se pode lograr dentro do "sprint" e dar unha estimación máis precisa para cada un. tarefa.

Polo tanto, o argumento máis eficaz parece ser aquel que mostraría a un especialista "non técnico" canto tempo e recursos variarán en función dos parámetros que aínda non se avalian.

Fonte: www.habr.com