blog del equipo de tecnología de 11870.com

Importaciones masivas de datos

La reciente importación de los sitios de la web de Turismo Castilla-La Mancha parece que ha generado cierto interés por saber cómo lo hemos hecho. Como imaginaréis, nadie se ha sentado a meter uno por uno los sitios; no somos tan malas personas, y además sabemos XML ;). Lo que hicimos fue crear un XML Schema que nos sirviese de formato de datos intermedio, de manera que los datos a importar tenían una forma predecible y podían ser importados sin más en nuestra base de datos.

¿Sin más? Bueno, en realidad la complejidad no está en obtener los datos, sino en evitar introducir duplicados en nuestra base de datos, es decir, en no crear de nuevo un sitio que ya tenemos. Identificar un duplicado es ya de por sí bastante difícil cuando los datos no siguen un formato estricto, pero además nos encontramos con otro problema, al que hemos bautizado «los multiduplicados». Estos aparecen cuando varios sitios de la fuente externa son identificados como duplicados de un mismo sitio de 11870.com. Suele pasar con sitios que son, por ejemplo, hostal y restaurante, y que según qué criterio se tome se pueden considerar como dos sitios diferentes o como uno. Nosotros hemos intentado arreglar esto, buscando minimizar los errores, pero si veis algo raro raro, hacédnoslo saber :)

Total, que entre cargar el XML, detectar duplicados, arreglar multiduplicados y finalmente realizar la importación propiamente dicha, hay un montón de cosas que hay que hacer. Para poder explicar mejor todo este baile, nos vamos a ayudar de un dibujillo.

Cadena de procesos de la importación

En el dibujo se ven las diferentes fases del proceso, que os contamos a continuación.

Carga del XML

Posiblemente la más sencilla de todas. Se lee el XML que vamos a importar, se transforma a un formato de datos un poco más manejable desde dentro de las aplicaciones y se almacena en una base de datos intermedia. Y ya tenemos los datos listos para la siguiente fase.

Detección de duplicados

En esta fase intentamos, para cada registro que se va a importar, detectar si ya tenemos guardado en 11870.com un sitio equivalente. Identificar un duplicado es bastante más difícil de lo que parece: ¿son el mismo sitio el Restaurante Casa Paco y el Hostal Rte. Casa Paco? ¿«avenida de Chiquitistán nº 7» es la misma dirección que «Avda. de Chiquitistan num. 7»? A un ordenador le cuesta mucho responder este tipo de preguntas.

Para no enrollarnos mucho, sólo diremos que la búsqueda de duplicados se basa en un sistema de «votación» en el que un conjunto de funciones comparan los datos que tenemos de los registros que pensamos que pueden ser duplicados (tras una búsqueda inicial muy laxa de «registros sospechosos»). Por cada función de comparación que se aplica, se obtienen dos valores, que vienen a significar «cuánto creo que son duplicados» y «cuánto creo que no lo son». Aunque parezca mentira, no son valores complementarios, porque cierto tipo de comparación puede tener mucho peso para la detección (teléfonos iguales) y poco para el descarte (direcciones no exactamente iguales letra por letra, pero parecidas en algo).

Cuando se tienen los valores de la votación de esas funciones, se combinan con diferentes pesos, y finalmente se decide si el registro es duplicado o nuevo. En algunos casos esto no es posible determinar de manera automática, por lo que esos registros pasan a una validación manual.

Detección de multiduplicados

En esta fase se buscan los registros que se han asignado como duplicados del mismo sitio de 11870.com, y se intenta resolver el conflicto, generalmente eligiendo al que más se parece al sitio. En esta fase todavía estamos profundizando, porque nos gustaría tomar automáticamente decisiones más «inteligentes». Esperemos poder aplicar ideas interesantes en breve :)

Importación de los datos

Por último, se importan los datos propiamente dichos, creándose los sitios nuevos o fusionándose con los existentes según el caso. Además, se añaden a las secciones apropiadas del usuario, y se categorizan si se dispone de suficiente información.

Epílogo: hacer que parezca fácil

Y todo este lío es precisamente para que los contenidos importados encajen con el resto, que os sean útiles y que parezca que todo ha sido fácil. Creednos, no lo ha sido, pero merece la pena :)


4 comentarios

rssComments RSS transmitTrackBack Identifier URI


Importar datos de forma masiva es una tarea difícil e interesante. Me llama la atención la parte en la que comentáis lo del sistema de «votación». Por lo que explicáis, no debe ser fácil crear el conjunto de funciones que se encargan de comparar los registros que a priori se cree que pueden ser duplicados.

Y sí, así leído parece muy fácil xDDDDDDD. Además, tenéis razón en lo de que merece la pena :D.

¡Buen trabajo chicos!.

Comentario by Antonio Fabregat on junio 1, 2009 9:12 pm


¡Qué rápido se cuentan siempre este tipo de procesos!

Comentario by alf on junio 2, 2009 9:20 am


Doy fe de ello que no es una tarea fácil. Nosotros usamos Jasper ETL. Las cargas las hacemos mediante un csv (aunque acepta cualquier formato de entrada) y tenemos que añadir nueva entrada o mejorar la que exista según proceda a nuestra bbdd. La decisión es muy básica, depende de unos registros que hemos considerado claves e identificadores de un sitio inequívocamente (cif, teléfono..) con los riesgos que se nos cuelen 2 veces el =, eso sí con la tipificación y la normalización de direcciones que tenemos, no nos cuelan 2 veces la misma calle ni jartos de vino :=). Enhorabuena, es interensantísimo todo lo que estáis haciendo.

Comentario by Per on junio 2, 2009 10:19 am


Me ha parecido genial el sistema de votación. Destaca lo importante que es elegir un algoritmo correcto, y en última instancia, una abstracción eficiente… Enhorabuena.

Comentario by Introspectre on junio 2, 2009 12:17 pm

addDeja un comentario