Escola Politècnica Superior Memòria del Treball de Fi de Grau
HabScraper: herramienta automatizada para la extracción de datos con web scraping
Nicole Vicente Stenhouse Grau d’Enginyeria Informàtica
Any acadèmic 2017-18
DNI de l’alumne: 43219210
Treball tutelat per Isaac Lera Castro
Departament de Matemàtiques i Informàtica
S'autoritza la Universitat a incloure aquest treball en el Repositori Institucional per a la seva consulta en accés obert i difusió en línia, amb finalitats exclusivament acadèmiques i d'investigació
Autor Tutor
Sí No Sí No
X X
Í NDICE GENERAL
Índice general i
Resumen iii
1 Introducción 1
2 Introducción al web scraping 3
2.1 Fundamentos del web scraping . . . 3
2.2 Funcionamiento y técnicas comunes . . . 3
2.3 Herramientas . . . 6
2.4 Aplicaciones de la extracción de datos . . . 6
2.5 Consideraciones legales y éticas . . . 7
3 La herramienta HabScraper 9 3.1 Contexto . . . 9
3.2 Objetivo y requisitos . . . 10
3.3 Diseño de la arquitectura . . . 11
3.3.1 Módulo scraper . . . 12
3.3.2 Módulo de API . . . 13
3.3.3 Módulo de Almacenamiento . . . 13
3.3.4 Módulo de Control . . . 13
4 Implementación de la herramienta HabScraper 15 4.1 Módulo de Almacenamiento . . . 15
4.1.1 Modelo de clases . . . 15
4.1.2 Tareas post-extracción . . . 17
4.1.3 Acceso y exportación de los datos . . . 19
4.2 Módulo de API . . . 20
4.2.1 Recursos de Almacenamiento . . . 20
4.2.2 Recursos de Notificación . . . 21
4.3 Módulo scraper . . . 22
4.3.1 Spider . . . 23
4.3.2 Selectores . . . 24
4.3.3 Pipelines . . . 24
4.3.4 Middlewares . . . 25
4.4 Módulo de Control . . . 26
4.4.1 Flujo de ejecución . . . 28
ii ÍNDICE GENERAL
4.4.2 Tareas periódicas . . . 30
5 Pruebas de ejecución de HabScraper 33
6 Conclusiones 37
Bibliografía 39
R ESUMEN
Grandes volúmenes de datos se generan y difunden a diario por usuarios, entidades o aplicaciones a través de la red. Este volumen masivo deBig Datase distribuye por millones de sitios web donde está disponible para un diverso número de aplicaciones.
Los motores de búsqueda proporcionan un mecanismo simple de acceso a estos datos.
El acceso a esta información a través de los motores de búsqueda requiere que el usua- rio dedique parte de su tiempo para los procesos de consulta, selección y descarga. Es decir, en primer lugar, el usuario debe escribir en el buscador su consulta. El motor de búsqueda le ofrece una serie de resultados que contienen información relacionada con dicha consulta. Posteriormente, el usuario debe seleccionar el link al sitio web que le resulte más acertado. Una vez seleccionado el sitio web, el usuario navega por sus pági- nas en búsqueda de la información referente a su consulta inicial. Pero considérese un escenario donde un investigador de mercado desea analizar una serie de páginas web para obtener datos de contacto de posibles futuros usuarios de una plataforma o donde una empresa está interesada en explorar la web para obtener comentarios relacionados con los productos o servicios de la compañía. Enviar consultas de manera manual para obtener estos datos puede resultar complicado, una solución automatizada podría ser más efectiva.
Como solución a la problemática expuesta anteriormente se presentaHabScraper.
HabScraperes una herramienta cuya finalidad es la extracción automatizada de datos de contacto de manera masiva que aparecen en distintos sitios web de forma pública y accesible, con la mínima intervención posible. Este proyecto se centra en describir el diseño, funcionamiento e implementación de la herramienta.
C
APÍTULO1
I NTRODUCCIÓN
A lo largo de los años, Internet se ha convertido en una fuente a la cual recurrir pa- ra cubrir numerosas necesidades de información. Podría decirse que Internet se ha transformado en una gran fuente de datos procedentes de muchos ámbitos diferentes.
Dichos datos aparecen de manera pública y accesible a través de múltiples sitios web y pueden ser usados para una amplia variedad de fines. Para obtener los datos que necesita, un usuario envía una consulta a un motor de búsqueda y examina los tres o cuatro enlaces principales que satisfacen sus interses. Sin embargo, como se comenta anteriormente, en un ámbito empresarial donde se requiere la extracción de un mayor volumen de datos, el enfoque manual no es escalable.
HabScraperse implementa en una empresa dedicada al desarrollo de una aplica- ción web. El propósito de dicha web es conectar a personas con la necesidad de algún servicio en su hogar (i.e. reformas, construcción, mudanzas, limpieza...) con empresas y profesionales del sector. Debido a la creciente demanda de usuarios que requieren trabajos o servicios, surge la necesidad de aumentar el número de profesionales de- dicados a cubrir las demandas de trabajo. Considerando la cantidad de directorios de empresas que existen en Internet, se contempla la posibilidad de extraer datos de contacto de profesionales que aparecen en estas páginas web con el fin de adquirir futuras empresas que cubran las crecientes demandas de trabajo.
La opción más acertada para poder extraer datos de sitios web de forma masiva es el uso de unweb scraper(1). Unweb scraperes una aplicación automatizada que se utiliza para extraer datos de páginas web específicas.
Surge, por tanto, la idea de desarrollar unweb scrapercuyo objetivo principal es extraer datos de contacto de directorios de empresas que serán utilizados para la obtención de registros de nuevas empresas y profesionales. En base al objetivo surgen una serie de requisitos:
1. extraerdatos de contacto de directorios web de empresas.
2. procesar los datos de contacto con el fin de modelar futuras empresas de la plataforma.
1. INTRODUCCIÓN
3. importarlos datos a la base de datos de producción, creando registros reales de profesionales.
Con la exposición de los requisitos se observa que no se trata solamente de una extracción de datos de contacto, si no que además, los datos deben adquirir el formato de un registro de empresa. Por este motivo, la herramientaHabScraper, no se dedica únicamente a la obtención de datos de contacto, si no que dispone de tareas de proce- samiento de los datos obtenidos para su posterior importación a la base de datos de producción.
El documento está organizado de la siguiente forma. El capítulo 2 se dedica a ha- cer una pequeña introducción alweb scrapingpara situar al lector en el ámbito de la extracción de datos. El capítulo 3 se centra en introducir la herramientaHabScraper exponiendo los objetivos que persigue y el diseño de su arquitectura. El capítulo 4 pro- porciona los detalles de implementación de cada módulo que compone la herramienta.
El documento conlcuye con una sección que recoge las conclusiones más importantes extraídas en el desarrollo deHabScraper.
C
APÍTULO2
I NTRODUCCIÓN AL WEB SCRAPING
2.1 Fundamentos del web scraping
Elweb scrapinges una técnica destinada a la extracción de datos de múltilples páginas web. Posteriormente, los datos pueden ser almacenados en una base de datos para un uso determinado. La mayoría de datos que aparecen en las páginas web solamente pueden visualizarse a través de navegadores. No existe la posibilidad de copiar o guardar los datos para un uso personal. La única manera de llevar a cabo esta práctica es de manera manual, lo cual, puede implicar mucho tiempo y esfuerzo para recoger grandes cantidades de datos. Elweb scraping automatiza este proceso, en lugar de recoger los datos de manera manual, la aplicación deweb scrapingrealiza la misma tarea en mucho menor tiempo.
2.2 Funcionamiento y técnicas comunes
El objetivo de unweb scraperes extraer contenidos de una manera sistemática y au- tomatizda con lo que posibilita la extracción de un gran volumen de datos. Unweb scraperimita las acciones y el acceso a los datos llevado a cabo por un usuario humano a través de la web y extrae los contenidos relevantes (2).
Por lo general unweb scraperestá formado por dos componentes principales: la navegación por los enlces de una página, lo que se conoce comoweb crawler, y la extracción de datos las páginas accedidas.
Web Crawler
Unweb crawler, también conocido comospider o araña web es un bot de Internet que inspecciona las páginas web de forma metódica y automatizada. Elweb crawler navega por la página web, normalmente, usando algoritmos recursivos. Se trata de una aplicaciónmulti-thread, es decir, el proceso de descarga de las páginas asociadas a las URLs obtenidas se realiza de manera concurrente. Al ser una aplicaciónmulti-thread
2. INTRODUCCIÓN AL WEB SCRAPING
necesita un planificador oschedulerencargado de repartir el tiempo disponible entre todos los procesos que están listos para su ejecución. La Figura 2.1 expone de manera gráfica el funcionamiento de unweb crawler. En primer lugar, comienza visitando una lista de URLs, indentifica los hiperenlaces que aparecen en las páginas y los añade a una cola oqueuede URLs a visitar, de manera recurrente, de acuerdo a un determinado conjunto de reglas. Elweb crawlerempieza descargando, a través deldownloaderuna serie de direcciones iniciales que le son propocionadas, analiza las páginas y busca enlaces a páginas nuevas añadiendolas a la cola. Posteriormente, descarga estas nuevas páginas, analiza sus enlaces y así sucesivamente.
Figura 2.1: Arquitectura de un web crawler
Extractor de datos
El extractor de datos extrae la información deseada de la página web. Debe tenerse en cuenta que la página cuenta con la estructura propia de HTML y que la información necesaria puede estar envuelta en tags y distintos elementos semánticos. Para poder obtener la información específica se usan los selectores.
El primer paso de la extracción es la inspección por parte del usuario de la página web. Normalmente, se realiza a través de la herramienta de inspección propocionada por el navegador. Una vez se localiza la información deseada, se comprueba si su es- tructura HTML sigue algún patrón común con la cual poder extraer todos los objetos comunes de la página web. Tras identificar el patrón, se extraen los datos a través de selectores tales comoXPathoCSS Selectors. En último lugar, se almacenan los datos en el formato requerido por el usuario. La Figura 2.2 muestra el proceso habitual de inspección del HTML de un elemento deseado con el fin de extraer patrones comunes que aplicar a través de selectores.
En ocasiones, las páginas pueden cargar elementos de su contenido de manera dinámica, es decir, a través de peticiones adicionales que se accionan con la interacción del usuario. En la Figura 2.3 se ilustra un ejemplo de este caso. Para obtener el teléfono de una ficha de contacto del sitio webhttps://www.domestiko.com/, el usuario debe
2.2. Funcionamiento y técnicas comunes
Figura 2.2: Inspección HTML
(a) Inspección elemento dinámico
(b) Inspección URL de petición
Figura 2.3: Extracción de datos con contenido dinámico
clicar sobre el enlaceVer teléfono. Si se quiere obtener esta información a través de unweb scraper la situación se complica ligeramente respecto a la extracción de un elemento generado de manera estática. En el caso dehttps://www.domestiko.com/, la persona encargada de desarollar elweb crawlerdebe fijarse en la petición que se realiza tras clicar sobre el enlace, esta suele seguir un patrón relacionado con el contenido estático del elemento. Un vez obtiene la URL a la que se realiza la peticióne la incluye en el listado de URLs. Posteriormente, la respuesta de la petición será tratada del mismo modo que el contenido estático.
El funcionamiento de unweb scraperse puede resumir a través de un proceso de tres pasos:
1. Se establece la conexión con el sitio web a analizar a través del protocolo HTTP.
El sitio web de destino adapta su interacción tras identificar al sujeto que quiere
2. INTRODUCCIÓN AL WEB SCRAPING
acceder a sus datos. Dicha restricción se lleva a cabo por medio del archivo robots.txtque se encuentra en la raíz del sitio web e indica que partes excluir a los rastreadores de los motores de búsqueda. Si elweb scraperintenta violar las restricciones puede ocasionar sanciones como la inclusión a una lista negra o el aviso al proveedor de internet.
2. En el paso siguiente, se obtiene el documento relevante y se extrae el contenido por medio de librerias de análisis de HTML, expresiones regulares, lógica de programación o mediante técnicas más complejas demachine learning(3).
3. El último paso implica convertir los datos extraídos a un formato adecuado para su futura exportación, como por ejemplo, JSON o CSV.
2.3 Herramientas
Existen varias herramientas, frameworks y APIs tanto comerciales como código abierto que pueden ser utilizadas. La implementación de unweb scraperpuede llevarse a cabo por medio de librerías de lenguajes de programación o con el uso de frameworks. Todos estos recursos utilizan una gran variedad de técnicas para la extracción de datos. Uno de los enfoques más populares es aprovechar y explotar la estructuración que ofrece el modeloDOMpara páginas HTML.
Se pueden desarrollarweb scrapersusando lenguajes de programación populares como Java, Python o Perl incorporando librerías externas. Dichas librerías incluyen dos componentes. Por un lado un componente que proporciona el soporte necesario para HTTP, como la autenticación, control de historial, control de cookies y certificados SSL. Por otro lado un segundo componente que proporciona soporte paraparsear, por ejemplo a través de XPath o aprovechando la estructura semántica del HTML.
Sin embargo, las librerías que incorporan los lenguajes de programación tienen ciertas desventajas. En primer lugar es necesario importarlas para tener acceso al sitio web. En segundo lugar, debe configurarse un componente encargado de parsear los contenidos de dicha web para extraer los datos relevantes. Estas desventajas pueden subsanarse con el uso deframeworks. Scrapy (4), escrito en Python, es elframework más popular deweb scrapingy el utilizado en la implementación de la herramienta HabScraper.
2.4 Aplicaciones de la extracción de datos
Elweb scraping ofrece un enfoque efectivo para la extracción de datos y su uso en una gran variedad de aplicaciones. Tradicionalmente un analistad de cualquier sector invertiría horas de esfuerzo manual en la recogida y organización de datos para su posterior análisis. La extracción automatizada mejora el tiempo, el coste y implica menor esfuerzo humano. Las aplicaciones de extracción de datos pueden encontrarse principalmente en las empresas o en las esferas de la web social. A continuación, se mencionan algunas de las aplicaciones más comunes donde se refleja su potencial.
2.5. Consideraciones legales y éticas
• A través de la recogida de datos procedente defeedback, comentarios o quejas de los usuarios las empresas pueden monitorizar sentimientos o influir en opiniones (5).
• Ampliar en gran medida la cantidad de datos disponibles para investigaciones, adoptando una escala a nivel mundial en contraposición a la recogida de una pequeña muestra de la población (6).
• Las empresas pueden colocar estratégicamente anuncios en sitios web de acuer- do a las necesidades del usuario final, información extraída de los contenidos y contexto en el que se mueve. La plataformaAdSensede Google utiliza esta técnica (6).
• Competencia de mercado mediante la extracción de datos permitiendo moni- torizar y controlar las actividades de los competidores, como pueden ser sus promociones actuales, actividad en redes sociales o estrategias de marketing con el fin de obtener una ventaja competitiva en un sector determinado (5).
• Ampliar la red de potenciales clientes de un producto a través de la extracción de datos de contacto utilizados en campañas de marketing o publicidad. Esta ténica recibe el nombre decontact scraping(5).
• Facilitar a los medios de comunicación la agregación de contenido mediante la extracción de noticias o tendencias globales que aparecen en la web con el fin de asegurar una posición líder en la comunicación de información (5).
2.5 Consideraciones legales y éticas
Al hablar deweb scrapingdeben tenerse en consideración una serie aspectos legales y éticos. En primer lugar, debe tenerse en cuenta que la técnica deweb scrapingpara la estracción de datos no es un derecho, si no un privilegio proporcionado por los sitios web que almacenan tales datos. Las personas que aplican dichas técnicas deben conocer y estar familiarizadas con las leyes vigentes y la seguridad cibernética aplicada a sus actividades. Por este motivo, es responsabilidad de la persona que implementa unweb scrapercumplir con lo términos de uso especificados por el sitio web del que desea extraer los datos.
Es importante saber que en España el web scraping es legal (7). De hecho, el pro- blema principal no está en la extracción de datos si no en el uso que se le pueden dar a dichos datos. Existen aspectos, no necesariamente gobernados por leyes explícitas si no por conductas morales o éticas. Es responsabilidad del usuario asegurarse de que se respeta la frecuenta de las restricciones de acceso para evitar sobrecargar los recursos de un servidor mediante el cual se sustenta un determinado sitio web. La automatización de procesos, así como las herramientas que tienen un conjunto de pe- ticiones concurrentes pueden representar una carga sobre los recursos de un sitio web, aspecto que lleva a imponer restricciones o mecanismos de prevención. Muchos sitios web incluyen el acceso restringido a determinadas páginas que debe ser considerado a la hora de implementar unspider, al contario el sitio web tiene el pleno derecho de
2. INTRODUCCIÓN AL WEB SCRAPING
bloquear a estas herramientas automatizadas. Es aconsejable respetar los términos y condiciones de acceso con el fin de evitar bloqueos temporales.
C
APÍTULO3
L A HERRAMIENTA H AB S CRAPER
3.1 Contexto
Como se comenta en el capítulo 1,HabScraperse desarrolla con el propósito de extraer datos de contactos de directorios web de manera masiva para ampliar el número de empresas y profesionales de una plataforma web.
Existen una variedad de herramientas dedicadas a la extracción de datos ya im- plementadas. Estas herramientas solo requieren que el usuario indique las URLs de las cuales quiere extraer los datos y de manera autómatica realizan la extracción. Para mayor comodiad incluyen una interfaz gráfica para que el usuario pueda configurar los ajustes de una determinada extracción o para exportar el fichero con los resultados finales. Algunos ejemplos de aplicaciones de web scraping sonImport.io,Mozendao Dexi.io.
Se podría haber apostado por el uso de una de estas aplicaciones pero comporta una serie de desventajas. En primer lugar, adquirir una de estas herramientas con un plan básico de funcionalidades supone un coste muy elevado y suelen incluir limitaciones de uso diarias. Por otro lado, como se cita en el requisito 2, los datos recogidos deben ser procesados, ya que en su importación crearán registros de empresas sobre la base de producción. Por este motivo, las funcionalidades que ofrecen estas aplicaciones no son suficientes para el objetivo que se persigue.
Se plantea, por tanto, que aspectos positivos puede conllevar la implementación de una herramienta propia. Surgen una serie de ventajas:
• No implica un coste elevado ya que se trata de una implementación propia.
• Permite incluir todas las funcionalidades que se requieran para el procesamiento de datos.
• Proporciona una base de datos propia a la que poder realizar las consultas ne- cesarias, a diferencia de una herramienta ya implementada, la cual solamente ofrece la exportación de un fichero con los datos extraídos.
3. LA HERRAMIENTAHABSCRAPER
• Permite la creación de varios usuarios, pudiendo diferenciar roles y tareas.
• Su uso diario es ilimitado.
En base a estas ventajas se decide optar por la implementación de unweb scra- per propio que no se encarga únicamente de la extracción de datos si no también del posterior tratamientos de estos con el fin de importarlos a la base de datos de producción.
3.2 Objetivo y requisitos
El objetivo principal deHabScraperes, por tanto, la extracción masiva de datos de contacto y su posterior almacenamiento. Tras la recogida masiva de datos, se quieren poder importar a la base de datos de producción creando registros de empresa reales, etiquetadas comopreimport, es decir, no aparecen públicamente en la web si no que se tratan de usuarios potenciales cuya finalidad es convertir en clientes. Las empresas usuarias de la plataforma tienen asociadas una categoría y localización específica guardadas en la base de datos de producción. Por este motivo, el dato de contacto a importar debe estar clasificado correctamente como una empresa con una categoría y localización geográfica determinada y acorde con la base de datos de producción. La figura 3.1 ilustra las fases por las que pasa un dato de contacto enHabScraper.
Figura 3.1: Fases de la extracción de un dato de contacto
La idea de implementar una herramienta deweb scrapingsurge por tanto, de la ne- cesidad de una extracción de un gran volumen de datos de contacto. La mayor ventaja que nos ofrece la elección de unweb scraperpara la extracción de datos es su equilibrio
3.3. Diseño de la arquitectura
en tiempo y coste. A través de una única implementación para un determinado sitio web podemos explorar todos sus enlaces con el fin de obtener la máxima cantidad de datos de contacto posibles.
Dadas las ventajas que supone optar por un web scraper y en base a los requisitos a alto nivel mencionados en el capítulo 1 se establecen una serie de requisitos más específicos para la implementación:
1. Para el primer requisito 1, la extracción de datos de contacto de directorios web, se requiere el uso del frameworkScrapy. El framework facilita la implementa- ción deSpiders. UnSpideres una clase que define como se rastrea una página web concreta, es decir, como navegar a través de sus enlaces y como realizar la extracción de datos.
2. Como se menciona en el requisito 2, es necesario el procesamiento de los datos tras la recogida. Esto implica el mapeo de categoría y localización obtenidas en cada dato de contacto con la correspondencia en la base de datos de producción.
3. El procesamiento de datos también conlleva su filtrado, con el fin de obtener so- lamente la información que se requiere, limpiando si es necesario, la información extraída.
4. Para satisfacer el requisito 3, es necesario el almacenamiento de los datos de contacto en una base de datos propia para la herramienta, accesible en todo momento y disponible para la exportación. La implementación se lleva a cabo a través del frameworkDjango(8) el cual ofrece un modelo de clases y el uso de un ORM para hacer consultas sobre la base de datos. Por otro lado,Django ofrece un framework de API llamadoTastypie(9), mediante el cual es posible crear interfaces para poder acceder y modificar los datos.
5. Con el fin de sacar la máxima utilidad se quiere reaprovechar la implementación de losspiders para la obtención de nuevos datos tras un periodo de tiempo coherente.
6. Finalmente, se desea poder automatizar los procesos de manera que las tareas que desempeñan los objetivos mencionados anteriormente se realicen una des- pués de otra de manera continua. De este modo, se evita la intervención de usuarios, se gana tiempo y se reducen costes.
3.3 Diseño de la arquitectura
Como consecuencia de los requisitos obtenidos para el diseño de la herramienta, la implementación no se centra exclusivamente en el desarrollo de unspider para la extracción de datos. La herramienta debe pasar por las fases que se mencionan a continuación.
• Obtener: El primer paso del proceso es la obtención de datos por medio de la extracción de los elementos del sitio web que consideramos relevantes. El objetivo principal es la recogida de datos con cualquier tipo de información de contacto.
3. LA HERRAMIENTAHABSCRAPER
• Procesar: Al obtener un dato de contacto queremos poder procesarlo, es decir, transformar el dato crudo en un objeto de valor para su posterior almacenamien- to.
• Almacenar: Una vez recibido un objeto de valor está listo para su almacenamiento con el fin de ser utilizado en un futuro. Cada resultado está asociado a una determinada ejecución, de esta manera puede medirse la efectividad de una extracción de datos en particular.
• Controlar: Finalmente, debe controlarse y supervisarse de manera automática el estado en el que se encuentran los datos con el fin automatizar el ciclo entre todas las fases.
Figura 3.2: Arquitectura HabScraper
En la figura 3.2 vemos ilustrados los tres módulos principales que componen la estructura deHabScrapery sus relaciones. Cada uno de ellos se encarga de una funcio- nalidad concreta relacionada con la fase en la que se encuentran los datos. Sin entrar en detalles de implementación, a continuación, se expone brevemente la funcionalidad de cada uno de ellos y el flujo que siguen los datos a través de cada uno de los módulos.
3.3.1 Módulo scraper
Satisface el requisito 1, la extracción de datos de contacto de los sitios web. Está com- puesto por un conjunto despiders. Losspidersimplementan técnicas de extracción de elementos sobre el HTML descargado por las páginas inspeccionadas. Por tanto,
3.3. Diseño de la arquitectura
incluye tanto las funciones necesarias para navegar y descargar el contenido de los enlaces de la página web, así como las encargadas de parsearlo.
3.3.2 Módulo de API
Es el nexo de unión entre el módulo scraper y el módulo de amacenamiento. Se encarga de procesar y enviar los datos al módulo de almacenamiento creando los objetos necesarios. Su finalidad principal es servir de punto de comunicación de cualquier tipo de información que deba ser mostrada o almacenada. A su vez, dispone de recursos encargados de avisar de la finalización de las tareas permitiendo de este modo la ejecución automatizada de la herramienta.
3.3.3 Módulo de Almacenamiento
Es el encargado de almacenar los resultados obtenidos en cada ejecución en una base de datos para su posterior uso. Además de los resultados almacena la ejecución a la que cada uno pertenece y elspiderque ha sido ejecutada para su recolección. Como hemos comentado al definir los objetivos de la herramienta, los datos de contacto debe establecerse una correspondencia entre las categorías y localizaciones obtenidas y las existentes en la base de datos de producción. Dicha correspondencia se almacena en este módulo.
3.3.4 Módulo de Control
Se encarga de la automatización de la herramienta. Se ocupa del lanzamiento automá- tico de las tareas de procesamiento y de su supervisión, así como de proveer de datos nuevos de forma continua a través del relanzamiento despidersya existentes.
C
APÍTULO4
I MPLEMENTACIÓN DE L A HERRAMIENTA
H AB S CRAPER
En el capítulo 3, se expone el diseño de la arquitectura de la herramienta. Ésta se com- pone de una serie módulos relacionados, cada uno con sus funcionalidad y própositos determinados. Este capítulo se centra en describir la estructura y funcionamiento interno de cada uno de los módulos así como su implementación.
4.1 Módulo de Almacenamiento
El módulo de almacenamiento es el encargado de almacenar todos los datos de contac- to, recogidos en las páginas web seleccionadas, en una base de datos común y accesible.
Sin embargo, antes de ser almacenados, los datos deben ser procesados. Por este motivo, el módulo de almacenamiento está compuesto por un modelo de clases que repre- sentan los objetos almacenados y las relaciones entre ellos, y además un conjunto de tareas específicas que se encargan de tratar los resultados obtenidos con el fin de crear nuevos o modificar los existentes.
4.1.1 Modelo de clases
La estructura de este módulo está compuesto por una serie de clases que implementan las tablas del modelo de datos y sus relaciones. Para la implementación de este módulo se usa el frameworkDjango, implementado enPython, el cual sigue un patrón de arquitectura Modelo-Vista-Controlador. En este patrón los datos de la herramienta, la interfaz y la lógica de control se dividen en tres componentes distintos.
• Modelo: que contiene una representación de los datos que maneja el sistema, su lógica de negocio y sus mecanismos de persistencia
• Vista: o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos de interacción con éste.
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
• Controlador: que actúa como intermediario entre el Modelo y la Vista, gestio- nando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.
El módulo de almacenamiento es elModelodel patrón MVC ya que se encarga de acceder a la capa de almacenamiento de los datos y de definir la funcionalidad del sistema. Los tres modelos o clases principales pueden verse en la Figura 4.1 y se describen a continuación.
Spider
La claseSpiderrepresenta al spider o crawler que se implementa para extraer datos de una determinada página. Está compuesto por los siguientes atributos:
• name: el nombre de la página web de la que extrae datos el spider.
• country: el país al que pertenece la página web. Muchos sitios web, disponibles en varios países, mantienen la misma estructura de elementos en su HTML por lo que puede heredarse la implementación de un spider común, con algunas ligeras modificaciones si es necesario.
• x_days: indica cada cuántos días volver a ejecutar de manera automática el spider.
SpiderRun
La claseSpiderRunrepresenta la ejecución de unSpiderconcreto. Cada ejecución tendrá sus propio estado y resultados. Sus atributos son:
• spider: indica el spider al que pertenece la ejecución.
• started_on: fecha y hora en la que comienza la ejecución.
• finished_on: fecha y hora en la que finaliza la ejecución.
• job_id: id único que identifica la ejecución.
Figura 4.1: Modelo de clases módulo almacenamiento
4.1. Módulo de Almacenamiento
SpiderResult
La clase SpiderResult representa un resultado determinado de la ejecución de un Spider. Sus atributos son:
• spider_run: indica la ejecución de un spider al que pertece el resultado.
• data: almacena en formato JSON los datos de contacto extraídos de la página web con el spider. Los datos más comunes son el nombre, teléfono, email, página web, categoría y código postal.
SpiderRunStatus
Con el objetivo de automatizar las tareas de procesamiento de los datos, explicadas a continuación, es necesario saber en que estado se encuentra la ejecución de un determinadoSpider. La claseSpiderRunStatusrepresenta el estado actual de un SpiderRun. Los cuatro tipos de estados que puede tomar la ejecución de una tarea son:
running,pending,cancelled,finished. Los atributos de la clase son los siguientes:
• parser_run: indica la ejecución a la que referencia el estado.
• crawl: indica el estado de la ejecución del crawler o spider.
• load_locations, load_categories, map_categories, horatio: indican el estado de la tarea.
4.1.2 Tareas post-extracción
Con el fin de procesar los datos obtenidos, adaptarlos a la base de datos de producción de la empresa o ampliar información que no se ha podido recoger en una primera iteración, se ejecutan cuatro cuando elSpiderfinaliza su ejecución, son las denomina- das tareas post-extracción. En la figura 4.2 se representan gráficamente la estructura y tareas de este módulo.
Las tareas post-extracción pueden dividirse en dos tipo según su propósito. Por un lado estan las tareas dedicadas al satisfacer el requisito 2, es decir, las encargadas de mapear la categoría y localización obtenidas con las correspondientes en la base de datos de producción. Dichas tareas son las llamadas tareas de mapeo. Por otro lado, existen las tareas cuyo propósito es el de maximizar la extracción de resultados de una página a través de los datos recogidos por elspider, se denominan tareas de maximización.
Tareas de mapeo
Cada una de las empresas obtenidas creará un registro real de producción en su im- portación, es por este motivo que los datos de categoría y localización parseados en el contacto deben concordar con las categorías y localizaciones existentes en la base de datos de producción. Las tres tareas encargadas de llevar acabo esta clasificación son las siguientes:
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
Figura 4.2: Estructura Módulo Almacenamiento
• load_locations: se encarga de procesar todas las localizaciones extraídas por unSpider. Para ello, realiza consultas a la API de producción con la ciudad, provincia o zip de cadaSpiderResult, y crea un objeto nuevoParsedLocation con los datos de localización equivalentes en producción. Finalmente, en el mo- mento en que se desea importar los datos, se mapean los campos de localización delSpiderResultcon losParsedLocationrelacionados con elSpider.
• load_categories: del mismo modo que la tarea anterior,load_categories procesa todas la categorías extraídas por unSpidercon el fin de obtener su equivalencia en producción. En su ejecución analiza el valor de la categoría almacenada en campodata delSpiderResulty si no existe ningún objeto ParsedCategorycon en ese valor para eseSpider, lo crea.
• map_categories: la diferencia entreload_locationsyload_categorieses que, en la primera, no se realiza ninguna consulta API para obtener la correspon- diente categoría. El objetoParsedCategoryse crea con la categoría parseada por elSpiderque se inserta en el campovaluede la clase. Posteriormente de manera manual el campohab_subcategoryes rellenado por personas que co- nocen el mapeo real de cada término. Esta tarea manual es la que se conoce en la herramienta comomap_categories. A pesar de la intervención manual, existe una función que permite acelerar este proceso.Autocategorizebus- ca si una categoría ha sido mapeada anteriormente, si es así se mantiene el ParsedCategory.
Tareas de maximización
Las tareas de maximización se encargan de generar nuevos resultados a partir de los datos obtenidos en la ejecución de unSpider. La única tarea perteneciente a este grupo eshoratio.
• horatio: analizando los datos obtenidos en losSpiderResultse vio que en mu- chas ocasiones losSpiderextraen páginas web de contacto de una determinada
4.1. Módulo de Almacenamiento
empresa. Las páginas web de contacto pueden incluir información que no se encuentra en un directio web.Horationo es más que unSpidergenérico que se aplica a todas las webs de contacto extraídas en cadaSpiderResult. ElSpider realiza una búsqueda, en particular de emails asociados al contacto, mediante la aplicación de una expresión regular. La búsqueda se realiza solamente a un primer nivel, es decir, no se navega por enlaces que se encuentren en la página principal. De esta manera, se completa la información extraída en una primera iteración.
4.1.3 Acceso y exportación de los datos
Una vez se extraen los datos a través de losspiderslos resultados deben poder ser con- sultados para evaluar si son correctos o determinar la cantidad de elementos extraídos.
Django, el framework utilizado para la implementación del módulo de almacenamiento, proporciona la generación de una interfaz administrativa genérica para poder acceder a los datos. La interfaz administrativa deDjangose encarga de leer los metadatos de las clases o modelos y de proporcionar una interfaz mediante la cual los usuarios pueden acceder y manejar el contenido recogido. Existen dos tipos de usuarios que tienen acceso a la interfaz administrativa.
Usuarios
La herramienta puede ser utilizada por dos tipos de usuarios, cuyos permisos se asignan en función de la tarea que desempeñan dentro de la aplicación.Djangoproporciona un modeloUserpara crear usuarios. Los usuarios pueden pertenecer a grupos. Los grupos se implementan a través de la claseGroup, también proporcionada por el framework.
Cada grupo tiene sus propios permisos, a continuación los dos grupos de la herramienta HabScraper.
• Losmapeadoresson los encargados de editar los objetosParsedCategoryobte- nidos rellenando el campohab_subcategorypor el equivalente en la base de datos de producción. No pueden visualizar otros datos de contacto, solamente tienen permisos de lectura y edición sobre las categorías.
• Losadministradoresse encargan de supervisar la ejecución de unSpidery de las tareas de post-extraccion que se aplican sobre los resultados. Por otro la- do, son responsables de exportar los resultados obtenidos para posteriormente importarlos a la base de datos de producción.
Exportación de resultados
Los datos extraídos se exportan en formato.csva través una tarea que ejecuta el adminis- trador desde el panel de administración. La ejecución de dicha tarea puede explicarse en dos pasos:
• En primer lugar, se obtienen todos los objetosParsedCategoryy losParsedLocation y se mapea el contenido con cada resultado equivalente en el campodatade un objetoSpiderResult, creando así la correspondencia.
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
• Posteriormente, se filtran los datos recogidos a través de la claseCSVMappery junto con el mapeo de la categoría y localización se escribe cada resultado como una línea del CSV. La claseCSVMapperse encarga de filtrar los datos. Especifica como se deben denominar los campos de cada uno de los datos de contacto que recoge elSpiderpara que el mapeo y correspondiente escritura en el CSV sean correctos. A su vez, implementa una serie decleanerso limpiadores que se encargan de depurar y filtrar posibles errores en los datos de contacto. Un ejemplo es la clasePhoneCleanerque se encarga de localizar espacios o caractéres no deseados y de validar el formato respecto el país al que corresponde el teléfono de contacto de cada resultado.
4.2 Módulo de API
Tal y como se muestra en la figura 3.2, el módulo de API actúa como nexo entre el resto de módulos. Se trata de una interfaz REST implementada con el framework para API de DjangollamadoTastypie. Sus funcionalidades principales son:
• Guardar en elmódulo de almacenamientocada uno de los resultados extraídos por unSpideren una ejecución determinada.
• Indicar la finalización de ciertas tareas a modo de notificación.
Para realizar estas funcionalidades la API hace uso de recursos. En términos de una arquitectura REST, un recurso es una colleción de datos similares y para un fin común.
Estos datos pueden ser por ejemplo una tabla de una base de datos, una colección de varios recursos o un formato similar de almacenamiento de datos. Debido a las dos funcionalidades distinguidas tenemos dos tipos diferenciados de recursos.
4.2.1 Recursos de Almacenamiento
Una de las ventajas del uso deTastyPiees la existencia de un tipo de recurso llamado ModelResource. Estos recursos son específicos para los modelos o clases existentes en elMódulo de Almacenamiento, aspecto que reduce la complejidad de su implemen- tación. El propio framework almacena las urls de routing específicas para el acceso a cada recurso, siguen el formato/api/v1/nombre_recurso?atributos.
SpiderResource
Es el recurso destinado a la obtención, creación y modificación de un objeto de clase Spider. Podemos filtrar los resultados por medio de los atributos propios de la clase:
nameycountry.
SpiderRunResource
Es el recurso destinado a la obtención, creación y modificación de un objeto de clase SpiderRun. Podemos filtrar los resultados por medio de los atributos propios de la claseSpider.
4.2. Módulo de API
SpiderResultResource
Es el recurso destinado a la obtención, creación y modificación de un objeto de clase SpiderResult. Podemos filtrar los resultados por medio de los atributos propios de la claseSpiderRun.
SpiderRunStatusResource
Es el recurso destinado a la obtención, creación y modificación de un objeto de clase SpiderRunStatus. Podemos filtrar los resultados por medio de los atributos propios de la claseSpiderRun.
Es el recurso fundamental para la automatización de todos los procesos ya que nos permite saber en que se estado se encuentra cada tarea y poder proceder con la ejecución de otra siguiente.
Existe otro tipo de recurso que no entra propiamente en esta categoría ya que no deriva de un modelo o clase delMódulo de Almacenamientopero si utiliza información almacenada en una de las clases, es elSourceUrlResource.
SourceUrlResource
Dentro del campo de datosdatade la claseSpiderResultse guarda elsource_url. Este dato indica la página de la que proviene un determinado resultado de contacto. El recursoSourceUrlResourcedevuelve todos lossource_urlasociados a unSpider. La finalidad de este recurso es evitar el acceso a urls que ya han sido examinadas anteriormente reduciendo el tiempo de rastreo del spider.
4.2.2 Recursos de Notificación
En una primera iteración de la herramienta, cuando los encargados de mapear las categorías terminaban su tarea, debían avisar al administrador para que pudiera conti- nuar con la ejecución de las tareas restantes. De la misma manera, el admistrador de la herramienta debía supervisar de manera continua la finalización de todas las tareas para poder finalmente exportar el csv con los datos de contacto a importar en la base de datos de producción.
Con el fin de agilizar y mejorar el proceso, se decide implementar un sistema de notificaciones vía email cuya emisión se efectúa por medio de los recursos de notifica- ción.
CrawlFinishedResource
Una vez finalizada la ejecución de unSpiderse realiza una llamada a este recurso. El recurso se encarga de modificar el estado por el correspondienteSpiderRunStatusy de enviar un email a los usuarios administradores para que puedan proceder con la ejecución o supervisión de las tareas.
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
MapCategoriesReadyResource
Mediante la modificación del panel genérico de administración proporcionado por Django, se incluye un botón que permite a los mapeadores de categorías indicar la finali- zación de su tarea. El botón realiza una llamada al recursoMapCategoriesReadyResource que cambia el estado delSpidery envía un email a los usuarios administradores.
4.3 Módulo scraper
El módulo scraper es el dedicado puramente a la extracción de los datos de las páginas web. Sigue el funcionamiento propio de unweb scrapertal y como se expone en el capítulo 2.1. Su implementación se basa en el uso deScrapyun popular framework de web scraping. Los componentes que conforman en el módulo scraper se implementan a través de los componentes propios de la arquitectura deScrapy.
Figura 4.3: Arquitectura de Scrapy
En la figura 4.3 puede verse la arquitectura deScrapyque es la base del funcio- namiento del módulo scraper. A continuación, se expone el flujo de los datos en la arquitectura:
1. ElEngineo motor, se encarga de controlar el flujo de datos y de lanzar eventos cuando ocurren determinadas acciones. En primer lugar, elEngineobtiene las peticiones iniciales que indica elSpider.
2. ElEngineregistra las peticiones en elSchedulero planificador y solicita las si- guientes peticiones a analizar. ElSchedulero planificador se encarga de recibir peticiones delEngine y de encolarlas. Posteriormente las solicita, también al Enginepara procesarlas.
4.3. Módulo scraper
3. ElSchedulerdevuelve las peticiones siguientes alEngine.
4. ElEngineenvía las peticiones alDownloaderpreviamente pasando por losMidd- lewares. ElDownloaderse encarga de obtener las páginas web y enviarlas al Enginepara que puedan ser procesadas posteriormente por elSpider.
5. ElEngine recibe las respuestas delDownloader y las envía alSpiderpara su procesamiento.
6. ElEngineenvía los elementos procesados a losPipelines. Posteriormente, envía las peticiones procesadas alSchedulery solicita las siguientes posibles peticiones a analizar.
7. El proceso se itera desde el primer paso hasta que no quedan más peticiones en elScheduler.
Los componentes mencionados anteriormente son módulos comunes en la arqui- tectura deScrapy. Algunos de ellos se utilizan para definir el funcionamiento propio de la aplicación mediante la implementación de su comportamiento, son los mencionados en las siguientes secciones.
4.3.1 Spider
UnSpideres una clase deScrapyque define como se rastrea un determinado sitio web, incluyendo como llevar a cabo la navegación a través de los links y como extraer datos de contacto estructurados de las páginas. El ciclo de unSpidersuele ser el siguiente:
1. Comienza generando las peticiones iniciales para rastrear las primeras URLs y especifica una función decallbackque se llamará tras obtener las respuestas a dichas solicitudes. Las primeras peticiones se realizan llamando a la función start_requests()que genera unaRequestpor cada una de las URLs especifi- cadas enstart_urlsy una llamada a la función de callbackparse().
2. La función de callback es la encargada de parsear la web y extraer los datos de contacto o devolver otro objeto del tipoRequestpara continuar con el rastreo de enlaces a un nivel inferior. La extracción del contenido se realiza típicamente con el uso de Selectores y se almacena en un diccionario dePython.
3. Finalmente, el diccionario devuelto por la función se procesará mediante API para su almacenamiento en la base de datos.
La claseSpidercontiene unos elementos comunes a incluir en cada implementa- ción, son los siguientes:
• name: un string que define el nombre del spider. Debe ser único ya que indica comoScrapyencuenta e instancia el spider. Como práctica habitual en la herra- mienta, el nombre se elige en función del dominio que se quiere parsear con un prefijo que indica el país al que corresponde dicho dominio, por ejemplo si se quiere crear un spider parahttps://www.paginasamarillas.es/ su nombre sería es_paginasamarillas.
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
• allowed_domains: una lista opcional de strings que contiene los dominios que el spider puede rastrear. Las peticiones a URLs que no entren en este rango de dominios serán ignoradas.
• start_urls: una lista de URLs por las que el spider inicia el rastreo, es decir, las primeras respuestas se obtendrán de las páginas incluídas en dicha lista. Las peticiones siguiente se generarán a raíz de los datos obtenidos en las URLs iniciales.
• custom_settings: un diccionario de ajustes que puede ser sobreescito para un determinado spider para sustituir los ajustes genéricos del proyecto. Entre los ajustes se puede modificar la concurrencia de las peticiones con la constante CONCURRENT_REQUESTSo el número de elementos a procesar en paralelo con CONCURRENT_ITEMS. Alterar estos valores puede ayudar a optimizar el tiempo de ejecución de un spider o, en su defecto, a evitar una sobrecarga de peticiones a un sitio web.
• parse: es la función de callback principal desde la que se procesan las respuestas a las peticiones. Debe devolver un iterable deRequestso diccionario de datos de contacto extraídos.
4.3.2 Selectores
La tarea principal de un spider es la extracción de datos del código fuente de HTML.
Existen varias librerías que pueden usarse, comoBeautifulSoupolmxl. En la herra- mienta se utilizan los selectores que facilita el propio framework,XPathyCSS Selector.
Se llaman selectores porque seleccionan ciertas partes del HTML.
• XPath: es un lenguaje que permite construir expresiones que recorren y procesan un documento XML.XPathpermite buscar y seleccionar teniendo en cuenta la estructura jerárquica del XML.
• CSS selector: se emplean para buscar o seleccionar elementos HTML a través de su estructura semántica. Los hay de varios tipos según el contenido que se quiere seleccionar y su especificación.
4.3.3 Pipelines
Los pipelines deScrapyson los encargados de procesar los elementos una vez se han extraído a través de losspiders. En el caso deHabScraper, constituyen una de las bases de la herramienta puesto que actúan de nexo entre el Módulo Scraper y el Módulo de API. Cada vez que un spider extrae un elemento, este se envía a unpipelinepara su procesamiento a través de varias funciones. El framework permite la implementación de pipelines propios y personalizados, HabScraper cuenta con dos fundamentales.
HttpPipeline
Es labase de todo el ciclo de extracción y posterior almacenamiento de los datosrea- lizado por un Spider. Sus funciones y el orden de ejecución explican la fase de obtención
4.3. Módulo scraper
de datos de la herramienta.
En un primer lugar, tras iniciar la ejecución del spider, se llama al métodoopen_spider():
• Realiza una consulta para obtener elSpideral que se está ejecutando y poder almacenar su ejecución y correspondientes resultados. La consulta se realiza me- diante el recurso de Spider de la API/api/v1/spider/?name=nombre_spider. Si no se obtiene unSpideren la respuesta, efectúa un POST al mismo recurso para crear uno nuevo.
• Tras obtener elSpidercrea un objeto nuevoSpiderRuna través del recurso /api/v1/run/spider=spider_resource_uri.
• Por último asigna un estado a la ejecución, es decir, crea un objeto de la clase SpiderRunStatusa través del recurso
/api/v1/status/spider_run=spider_run_resource_uri. Por defecto, cuan- do se crea el objeto SpiderRunStatus, todos los campos que identifican las tareas están en estadopendingmenos la tarea que hace referencia a la ejecución del spider, la tareacrawl, que tiene un estado igual arunning.
Posteriormente, se llama al método process_item() cada vez que se procesa un elemento o dato de contacto:
• La función crea un objeto de la claseSpiderResultasociado a la ejecución del
spider mediante el recurso/api/v1/result/spider_run=spider_run_resource_uri. DuplicateItemPipeline
Evita que en la ejecución de un Spider se almacenen items que ya han sido almacenados en esa misma ejecución. El pipeline guarda una lista que denominaids_seendonde se encuentran todos los ids explorados desde el inicio de la ejecución hasta el momento actual. El datosource_urlde cada resultado es utilizado como id. Si en el momento de procesar un resultado susource_urlse encuentra dentro de la listaids_seenlanza la excepciónDropItemignorando el elemento.
4.3.4 Middlewares
Los middlewares deScrapyson un mecanismo de procesamiento que permiten imple- mentar una funcionalidad personalizada para procesar las respuestas que se envían a un Spider, así como las solicitudes y elementos que genera un Spider.
JumpVisitedSourceUrlMiddleware
Un objetivo de la herramienta es poder reejecutar los spiders existentes, en intervalos de tiempo seleccionados, para poder tener siempre datos nuevos disponibles sin la necesidad de implementar nuevos spiders.
En una primera iteración se observó que la gran mayoría de resultados que se obtenian en las repeticiones ya estaban almacenadas por otra ejecución anterior del mismo spider. Se lograban extraer resultados pero a un coste de tiempo demasiado
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
elevado para la cantidad de datos nuevos extraídos. Surge, entonces, la idea de evitar el procesamiento de URLs ya visitadas en anteriores ejecuciones, estas URLs están almacenadas en el camposource_urlde cada dato.
En primer lugar el middleware obtiene todas las urls visitadas por un spider median-
te el recurso personalizado del Módulo de API,/api/v1/source_url?spider_name=nombre_spider. Posteriormente, comprueba que cada petición que se procesa no esté dentro de la lista
de urls visitadas en anteriores ejecuciones. Si la petición ya se ha realizado en ejecucio- nes anteriores, lanza una excepciónIgnoreRequestcon el fin de evitar visitar la URL de nuevo.
4.4 Módulo de Control
En las secciones anteriores se han presentado los módulos principales de la herramien- ta. Los encargados de obtener (módulo scraper), procesar (módulo de API) y almacenar (módulo de almacenamiento) los datos de contacto. No obstante, en la figura 3.2, se muestra otro módulo que se ocupa de supervisar el flujo del resto de módulos, es el módulo de control.
La implementación del módulo de control surge en una iteración posterior de la herramienta. En las primeras versiones del proyecto, la ejecución y el estado de las tareas de post-extracción y la exportación de los datos extraídos, debía ser efectuado y supervisado por el administrador de la herramienta de manera prácticamente cons- tante, impidiendo de esta modo un flujo ininterrumpido de datos disponibles. Para paliar esta situación y con el objetivo de satisfacer los requisitos 5 y 6 surge la idea de automatizar todo el ciclode la aplicación. Se establecen una serie de requisitos para este propósito:
• Automatización del ciclo de ejecución de tareas. El objetivo es ejecutar de manera automática, es decir, sin intervención manual, una tarea tras la finalización de la anterior.
• Evitar la supervisión continua del estado de las tareas y de posibles errores o fallos de ejecución.
• Disponer de datos de contacto nuevos de manera continua sin la implementación de nuevos spiders, es decir, aprovechar los que se han ejecutado en ocasiones anteriores.
El módulo de control es el encargado de permitir el flujo automatizado, controlar posibles errores de las tareas y relanzar los spiders con el fin de disponer de nuevos y continuos registros. Para su implementación se incluye una cola de tareas asíncronas llamadaCelery, junto con la aplicaciónScrapydespecialmente preparada paraScrapy.
Celery
Celery (10) es una aplicación que permite crear tareas de trabajo asíncronas gestiona- das por un gestor de colas y está basada en el envío de mensajes de manera distribuida.
Se focaliza en operaciones en tiempo real pero también soporta la calendarización de tareas, es decir, puede lanzar tareas que se tengan que ejecutar en un momento
4.4. Módulo de Control
determinado o de manera periódica. Las unidades de ejecución, llamadastasks o tareas, se ejecutan de manera concurrente en uno o más nodos de trabajo. Las princi- pales tareas deHabScraperse mencionan en la sección 4.1.2, son:load_categories, load_locationsyhoratio. La tareamap_categories, al ser manual, no tiene cabida en la cola de trabajos.
El módulo de control engloba las tres tareas principales en una sola tarea,execute_tasks() que se encarga de la ejecución y supervisión de todo el conjunto. La función crea un
grupo de tareas que son ejecutadas en paralelo a través de la clasegroup()deCelery.
tasks = group(
load_categories(), load_locations(), horatio()
)
Al conjunto de tareas se le aplica un ejecución asíncrona mediante la funciónapply_async(). Una vez añadidas todas las tareas a la cola se espera a que estas acaben a través de la funciónjoin(). Si ocurre algún error lanza una excepción que permite notificar a cerca del fallo evitando, de este modo, la supervisión continua.
tasks_execution = tasks.apply_async() try:
tasks_execution.join() except Exception:
notify_error()
Una vez finalizadas las tareas continúa la ejecución, modificando los estados y envian- do las notificaciones necesarias.
Celerypermite el lanzamiento de tareas periódicas a través de subeat_schedule.
En la herramienta se configura unbeat_schedulecon dos tareas principalesreexecute_spiders yreload_failed_tasks.
Scrapyd
Scrapyd(11) es una aplicación para desplegar y ejecutar spiders deScrapy. Permite subir o desplegar proyectos y controlar la ejecución de losspidersmediante una API. A continuación se describe como lograr estas dos acciones.
• Desplegar el proyecto:Scrapydproporciona un comando simple con el que subir todos los spiders para su posterior ejecución, este esscrapyd-deploy.
• Ejecutar un spider: se realiza un POST a la URL del recurso API deScrapydcon el nombre del proyecto y el nombre del spider. Por ejemplo si se quiere ejecutar el
spideres_paginasamarillasla URL seráhttp://localhost:6800/schedule.json -d project=hab_scraper -d spider=es_paginasamarillas.
En laHabScraperse encapsula la llamada en una tarea denominadascrapyd_crawl que ejecuta los siguientes instrucciones:
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
1. Para evitar la sobrecarga, se comprueba si el número despidersejecutándose es menor a la constanteMAX_CRAWLING. Para obtener losspideren ejecución se realiza una llamada ahttp://localhost:6800/listjobs.jsony se filtra la respuesta por los que tengan un estadorunning.
2. Se jecuta la petición a el recurso/schedule.jsonmencionada anteriormente.
Esta llamada asigna un valor a la variableSCRAPY_JOBalmacenada en el archivo de ajustes deScrapycon eljob_idactual de la ejecución.
Cuando comienza el spider y se ejecuta la funciónopen_spider()del pipeline HttpPipeline, se añade el valor de la variable SCRAPY_JOBal campo job_iddel SpiderRun. De este modo se mapea elSpiderRundel módulo de almacenamiento con el spider enScrapydpermitiendo el control de su ejecución.
4.4.1 Flujo de ejecución
El flujo automatizado de las tareas pasa por la ejecución de una serie de funciones que se encargan de cambiar los estados, enviar notificaciones y lanzar las tareas post- extracción para finalmente poder proceder con la exportación de los datos. A continua- ción, se expone paso por paso el flujo automatizado del módulo de control.
Ejecución del Spider
Figura 4.4: Ejecución del spider
La figura 4.4 ilustra el primer paso del ciclo. El flujo comienza con la ejecución de un spider a través de la funciónscrapy_crawl(). Cuando se quiere ejecutar un spider por primera vez se debe lanzar el comandorun_spider_crawl. Una vez un spider ya se ha lanzado anteriormente y está almacenado como unSpideren el Módulo de Alma- cenamiento, puede seleccionarse desde la interfaz de administración para su ejecución.
Se le asigna el estado de la ejecución de la tareaParserRunStatusel valor corres- pondiente, en este caso,crawl=running. Si en algún momento falla la tarea, cambiará el valor del estado porcrawl=cancelled. El administrador de la aplicación puede
4.4. Módulo de Control
consultar en todo momento los estados de las tareas accediendo al panel de adminis- tración y seleccionando el objetoParserRunStatusde una determinada ejecución.
Ejecución de load_categories, load_locations y horatio
Figura 4.5: Ejecución de load_categories, load_locations y horatio
La figura 4.5 representa el flujo tras la finalización delspider. Elspiderfinaliza con la ejecución de la funciónclose_spider()delHttpPipeline. En dicha función se realiza un POST al recursoCrawlFinishResourcede la API. A través del recurso se setea el estado de la ejecución del spidercrawl=finishedy se ejecutan las tareas de procesamiento a través de la funciónexecute_tasks(). El recurso también se encarga de notificar por email a los administradores de la finalización del spider y el inicio de las tareas.
Si alguna de las tareas falla en su ejecución su estado se asgina el valorcancelled y se notifica vía email al administrador.
Finalización de las tareas
La figura 4.6 ilustra el último paso en el ciclo de automatización. Tras la ejecución de todas las tareas se comprueba si el spider ha obtenido categorías nuevas a través de la funciónhas_new_categories(). La función obtiene todas las ParsedCategory asociadas alSpider. Posteriormente, extrae la fecha y hora de inicio delSpiderRun y comprueba a través del campo created_onsi se ha creado algun objeto nuevo ParsedCategoryentre la fecha y hora extraídas y la actual.
Si hay nuevas categorías se notifica a losmapeadorespara que comiencen su tarea ma- nualmap_categories. La tarea la realizan a través de la interfaz gráfica de administra- ción. Esta misma interfaz provee de un botón mediante el cual pueden notificar de la fi- nalización de su tarea. El botón hace un POST al recursoMapCategoriesReadyResource
4. IMPLEMENTACIÓN DE LA HERRAMIENTAHABSCRAPER
Figura 4.6: Finalización de las tareas
que se encarga de notificar vía email al administrador de la finalización de todas las tareas y que, por tanto, puede proceder con la exportación del CSV.
4.4.2 Tareas periódicas
Con el fin decontrolar posibles errores de las tareas y relanzar los spiders con el fin de disponer de nuevos y continuos registrosel Módulo de Control implementa dos tareas periódicas:reload_orphan_spider()yload_respiders(). Estas dos tareas son incluidas en elbeat_scheduleproporcionado porCeleryy a cada una de ellas se le asigna un intervalo de repetición. Elbeat_schedulese ilustra en la figura 4.7.
Figura 4.7: Tareas delbeat_schedule
reexecute_spiders
La tareaload_respidersse encarga de relanzar los spider existentes para obtener nuevos resultados. La claseSpiderdispone del campox_daysque indica cada cuantos
4.4. Módulo de Control
días debe relanzarse el spider. La tarea está registrada en elbeat_scheduley tiene una periodicidad de 60 minutos.
Para relanzar unSpider, en primer lugar, obtiene la última ejecución de suSpiderRun. Posteriormente, consultado el campofinished_on, comprueba si el intervalo de tiem- po entre el valor consultado y la fecha actual es igual o mayor que el valor del campo x_days. De ser así ejecuta elSpidera través de la funciónscrapyd_crawl.
reload_failed_tasks
La tareareload_failed_tasksse encarga de detectar todas las tareas que se en- cuentran en estadocancelledy de su reejecución. Se ejecuta en un intervalo de 10 minutos.
En primer lugar obtiene todos losSpiderRunStatusque tengan alguna tarea cam- po con valorcancelled, filtra por elSpiderRunal que pertenece y relanza la tarea. Si el resto de tareas están listas, es decir, si elSpiderRunStatustiene todos sus campos con valorfinishedse sigue la misma ejecución que en el flujo normal. En caso contrario se lanzan las otras tareas fallidas.
C
APÍTULO5
P RUEBAS DE EJECUCIÓN DE H AB S CRAPER
La herramientaHabScraperes una aplicación de usuario que combina la interacción a través de comandos ejecutados en una terminal con el uso de la interfaz de adminis- tración. Dicha interfaz ha sido utilizada para mostrar de manera gráfica el uso de la herramienta así como el resultado de las acciones que se ejecutan. A continuación, se ilustra el flujo de ejecución de la extracción de datos de una página web y la posterior exportación de resultados.
1. Ejecución delSpider. El primer paso es el lanzamiento delSpider. La primera vez que se lanza elSpiderdebe hacerse a través del comandorun_spider_crawl pasando como parámetro el nombre delspider. Una vez se haya ejecutado el spiderya existirá un objetoSpiderdel módulo de almacenamiento, por tanto, su ejecución podrá efectuarse a través de la interfaz de administración. En este caso particular se quieren extraer datos del sitio webhttp://empresite.eleconomista.es/
(a) A través del terminal.
(b) Desde el panel administración.
Figura 5.1: Ejecución de un spider.
5. PRUEBAS DE EJECUCIÓN DEHABSCRAPER
por lo que se ha implementado elspideres_eleconomista. En la figura 5.1 se ven los dos maneras de ejecutar dichospider.
En la figura 5.2 se muestra el panel de ejecución de de losspidersenScrapyd. A través de los logs puede verse el flujo de extracción de los datos. Los logs muestran como el spider está navegando a través de los enlaces a través del outputCrawled (200) <GET ...>. Posteriomente, se muestra como el spider realiza un POST a la API para crear un nuevo resultadoPOST /api/v1/result/. Por último el spider imprime el output que indica que se ha extraído el elemento de la URL analizada.
Desde el panel de administración, como muestra la figura 5.2 puede consultarse el estado en el que se encuentra la ejecución así como los resultados extraídos hasta el momento. Como elspider se está ejecutando la tareacrawlestá en estadorunning.
(a) Datos de la ejecución del Spider
(b) Resultado extraído de la ejecución del Spider
(c) Estado de la ejecución del Spider
Figura 5.2: Estado del Spider.
2. Ejecución tareas post-extracción. Cuando elspiderfinaliza su ejecución se mo- difica elSpiderRunStatusasociado alSpider. Como se ilustra en la figura 5.3, la tareacrawlha finalizado y se han ejecutado las posteriores tareas. Las tareasload_categoriesyload_locationshan finalizado su ejecución pero horatiotodavía se está ejecutando.
Figura 5.3: Estado de las tareas.
3. Mapeo de categorías. Tras la finalización de todas las tareas post-extracción, se envía una notificación email a los usuariosmapeadorespara que realicen el mapeo de categorías de losParsedCategoryde unSpider. En el email les aparece un enlace que les dirige exactamente al panel de modificación, el que se muestra en la figura 5.4. Una vez losmapeadoresfinalizan su tarea clican en
"LISTO PARA IMPORTAR", acción mediante la cual se notifica al administrador que elSpiderestá listo para su exportación.
(a) Parsed Categories de un Spider.
(b) Mapeo de Parsed Category con ca- tegoría real.
(c) Listo para la importación.
Figura 5.4: Fases mapeo de categoría.
4. Exportación de los datos. Por último, una vez el administrador recibe el email de notificación que le indica que el mapeo de categorías está listo, procede con la exportación en formato CSV de los datos con el fin de importarlos en la base de datos de producción. En la figura 5.5 se muestra como realiza el administrador dicha exportación.
Figura 5.5: Exportarción de datos.
El archivo exportado con los datos se importa posteriormente a la base de datos de producción creando un registro de empresa. En la figura 5.6 pueden verse los resultados exportados en formato csv. A través de la exportación se puede evaluar
5. PRUEBAS DE EJECUCIÓN DEHABSCRAPER
la calidad de extracción de un determinadospider. Interesan resultados que contengan muchas webs de contacto ya que a través de horatio podrán extraerse más resultados relacionados. Por otra lado, es muy favorable que tengan email ya que supone un canal directo con la empresa sin ningún coste. Por último, si no tiene ninguno de los datos anteriores conviene que tenga un teléfono de contacto mediante el cual localizar a la empresa para poder ofrecerle los servicios de la compañia.
Figura 5.6: Resultados exportados en csv.
