Este documento describe cómo usar Hadoop para construir un buscador vertical escalable. Explica que Hadoop permite reprocesar periódicamente todos los datos de los feeds para actualizar el índice de búsqueda de forma más eficiente que hacer actualizaciones individuales. Describe la arquitectura propuesta que incluye módulos para obtener los feeds, procesarlos, indexarlos en Solr y reconciliar cambios entre ejecuciones.
5. Arquitectura “obvia”
Lo primero que llega a la cabeza
Feed
Existe?
Ha cambiado?
Inserta/actualiza Base de Datos
Descargar y
Procesar
Inserta/actualiza
Indice Search Page
Lucene/Solr
6. 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
7. 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
10. “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
11. Hadoop
“The Apache Hadoop
software library is a
framework that allows for
the distributed processing
of large data sets across
clusters of computers using
a simple programming
model”
De la página de Hadoop
12. Sistema de Ficheros
§ Sistema de ficheros distribuido (HDFS)
• Bloques grandes: 64 Mb
• Tolerante a Fallos (replicación)
• Habitualmente ristras de pares [clave,
valor]
13. 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
15. 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
17. 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
18. 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
19. 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]*
20. 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
21. 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.
22. Indexer
Solr en producción
Despliegue
en
Reducer Task caliente
Indice - Shard 1
Indice - Shard 1
Servidor Web
Despliegue
Reducer Task en
caliente
Indice - Shard 2
Indice - Shard 2
Reducer Task
Despliegue
Servidor Web
en
caliente
Indice - Shard 3
Indice - Shard 3
23. 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
24. 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
25. 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
26. 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.
27. 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
28. 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.