Buscador vertical escalable con Hadoop
Upcoming SlideShare
Loading in...5
×
 

Buscador vertical escalable con Hadoop

on

  • 2,236 views

 

Statistics

Views

Total Views
2,236
Views on SlideShare
1,566
Embed Views
670

Actions

Likes
1
Downloads
22
Comments
0

4 Embeds 670

http://www.datasalt.es 596
http://www.datasalt.com 72
http://www.datasalt.co.uk 1
http://feeds.feedburner.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Buscador vertical escalable con Hadoop Buscador vertical escalable con Hadoop Presentation Transcript

  • Caso práctico con Hadoop: Unbuscador vertical escalable Iván de Prado Alonso, Cofundador de Datasalt Twitter: @ivanprado
  • Contenidos §  El problema §  La solución obvia §  Cuando la solución obvia falla… §  … Hadoop viene al rescate §  Ventajas y Desventajas §  Mejoras
  • ¿Qué es un buscador vertical? Proveedor 1 Buscador Vertical Feed ue das BúsqProveedor 2 Búsq ueda ed s Fe
  • Algunos de ellos
  • Arquitectura “obvia” Lo primero que llega a la cabeza Feed Existe? Ha cambiado? Inserta/actualiza Base de DatosDescargar y Procesar Inserta/actualiza Indice Search Page Lucene/Solr
  • Funcionamiento §  Descarga del feed §  Para cada registro en el feed •  Comprobar si ya lo tenemos en la BD •  Si ya existe y ha cambiado, actualizar ª la BD ª El índice •  Si no existe, insertar en ª la BD ª el índice
  • Funcionamiento (II) §  La BD proporciona •  Un sistema para comprobar la existencia o no de un registro (evitar duplicados) •  Gestión de los datos vía SQL §  Lucene/Solr proporciona •  Alta velocidad de búsqueda •  Búsquedas por campos estructurados •  Búsquedas textuales •  Faceting
  • Pero si todo va bien… Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed FeedFeed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed Feed FeedFeed Feed Feed Feed Feed
  • Atasco Monumental
  • “Swiss army knife of the 21st century” Media Guardian Innovation Awards http://www.guardian.co.uk/technology/2011/mar/25/media-guardian-innovation-awards-apache-hadoop
  • Hadoop “The Apache Hadoop software library is a framework that allows forthe distributed processing of large data sets acrossclusters of computers using a simple programming model” De la página de Hadoop
  • Sistema de Ficheros §  Sistema de ficheros distribuido (HDFS) •  Bloques grandes: 64 Mb •  Tolerante a Fallos (replicación) •  Habitualmente ristras de pares [clave, valor]
  • MapReduce §  Dos funciones (Map y Reduce) •  Map(k, v) : [z,w]* •  Reduce(k, v*) : [z, w]* §  Ejemplo: contar palabras •  Map([documento, null]) -> [palabra, 1]* •  Reduce(palabra, 1*) -> [palabra, total] §  MapReduce y SQL •  SELECT palabra, count(*) GROUP BY palabra §  Ejecución distribuida en un cluster con escalabilidad horizontal
  • Vale, mola mucho, pero…¿cómo soluciona esto mi problema?
  • Y es que… § Hadoop no es una DB § Hadoop “aparentemente” sólo procesa datos § Hadoop no permite “lookups” Hadoop supone un cambio de paradigma que cuesta asimilar
  • Arquitectura
  • Filosofía §  Reprocesarlo todo siempre. ¡TODO! §  ¿Por qué? •  Más tolerante a fallos •  Más flexible •  Más eficiente. Ej: ª  Con un HD de 7200 RPM –  Random IOPS – 100 –  Lectura secuencial – 40 MB/s –  Tamaño de registro: 5 Kb ª  … con que un 1,25% de los registros cambien, es más rápido reescribirlo todo que hacer accesos aleatorios de actualización. –  100 MB, 20.000 registros »  Lectura secuencial: 2,5 sg »  Lectura aleatoria: 200 sg
  • Fetcher Se descarga los feeds y los almacena en el HDFS §  MapReduce •  Input: [feed_url, null]* Reducer Task •  Mapper: identidad •  Reducer(feed_url, Reducer Task null*) HDFS ª  Descargar el feed y Reducer Task subirlo a un directorio en el HDFS
  • Processor Parsea los feeds, los convierte en documentos y los deduplica §  MapReduce •  Input: [ruta_feed, null]* •  Map(ruta_feed, null) : [id, documento]* ª Parsea el feed y lo convierte en una serie de documentos •  Reducer(id, [documento]*): [id, documento] ª Recibe una lista de documentos y se queda con el más reciente (deduplicación) ª Necesidad de un identificador único global (idProveedor + idInterno) •  Output: [id, documento]*
  • Processor (II) §  Posible problema: •  Feeds de tamaño muy grande ª No escala, pues no se puede dividir el trabajo §  Solución •  Escribir un InputFormat que sea capaz de dividir cada feed en cachos procesables más pequeños
  • Serialización §  Writables •  Serialización nativa de Hadoop •  De muy bajo nivel •  Tipos básicos: IntWritable, Text, etc. §  Otras •  Thrift, Avro, Protostuff •  Compatibilidad hacia atrás.
  • Indexer Solr en producción Despliegue enReducer Task caliente Indice - Shard 1 Indice - Shard 1 Servidor Web DespliegueReducer Task en caliente Indice - Shard 2 Indice - Shard 2Reducer Task Despliegue Servidor Web en caliente Indice - Shard 3 Indice - Shard 3
  • Indexer (II) §  SOLR-1301 •  https://issues.apache.org/jira/browse/SOLR-1301 •  SolrOutputFormat •  1 índice por cada reducer •  Se usa el Partitioner para controlar dónde colocar cada documento §  Otra opción •  Escribir tu propio código de indexación ª  Creando un nuevo output format ª  Indexado a nivel de reducer. En cada llamada al reducer: –  Abres un índice –  Escribes todos los registros recibidos –  Cierras el índice
  • Búsqueda y Particionado §  Posible particionado •  Horizontal ª Las búsquedas implican todos los shards •  Vertical: por tipo de anuncio, país, etc. ª Las búsquedas se pueden restringir al shard implicado §  Solr para servir los índices. Posibilidades ª Solr no federado –  En caso de particionamiento vertical ª Distributed Solr ª Solr Cloud
  • Reconciliado Reconciliado Siguientes Del Fetcher pasos Documentos reconciliados Fichero de la última ejecución§  ¿Cómo registrar cambios? •  Cambios en el precio, características, etc §  Reconciliando. •  MapReduce: ª  Input: [id, documento]* –  De la anterior ejecución –  De la ejecución actual ª  Map: identidad ª  Reduce(id, [documento]*) : [id, documento] –  Te llegan todos los documentos con el mismo ID –  Comparas los registros nuevos con los viejos –  Almacenas en el nuevo objeto la información relevante (ej, si ha subido o bajado el precio) –  Emites un solo documento. §  Esto es el patrón más parecido a una BD que se puede ver en Hadoop
  • Ventajas de la arquitectura §  Escala horizontalmente •  Si se programa adecuadamente §  Alta tolerancia a fallos y bugs •  Siempre se reprocesa todo §  Flexible •  Por su alto desacople, es fácil hacer grandes cambios §  Alto desacople •  Los índices son la única interacción entre los servidores web y el back-end •  Los servidores web pueden continuar funcionando aún en el caso de que el back-end esté roto.
  • Desventajas §  Procesamiento por Lotes (batch oriented) •  No es real-time ni “near” real-time •  Ciclos de actualización de horas §  Paradigma de programación completamente diferente •  Alta curva de aprendizaje
  • Mejoras §  Sistema para las imágenes §  Detección difusa de duplicados §  Plasam: •  Combinación de esta arquitectura con un sistema que actúe como by-pass para proveer actualizaciones “near real-time” ª  Implementando un by-pass sobre los Solrs ª  Sistema para mantener la coherencia de los datos –  Sin saltos hacia atrás en el tiempo •  Combina las ventajas de esta arquitectura, pero le dota de real-time •  En Datasalt tenemos un prototipo que realiza esta función.
  • Gracias Ivan de Prado, ivan@datasalt.com @ivanprado