Pablo Brenner & Sergio Fogel Blog

Los que me siguen en twitter habran visto que las ultimas 2 semanas estuve por USA con un roadshow de Bigdata y Hadoop que organizamos con Globant, me parecio interesante escribir algo sobre el tema, asi que aca va algo, obviamente es muy por arriba, mis disculpas a los que ya saben y busquen algo mas profundo.

Empecemos con una definicion del problema/oportunidad:

La cantidad de datos que se estan acumulando dia a dia crece de una forma impresionante, cada vez tenemos mas y mas gente subiendo datos a internet y redes privadas, y para colmo muchos de esos datos son imagenes y videos.
Solo para tener una idea, youtube dice estar subiendo 24 horas de video cada ………………….. segundo

Adicionalmente esos datos son no-estructurados, los suben individuos, con poca informacion adicional. Segun McKinsey estos datos no-estructurados estan creciendo a una tasa de 72% anual.

A esto hay que sumarle los datos que estan siendo generados por infinidad de sensores y automatismos, lo que en la jerga se esta llamando el: «internet of things», en resumen, nos estamos inundadndo en datos….. help!!!!

Atras de todos estos datos se esconde mucha informacion, util para tomar decisiones, personalizar la experiencia del usuario, mejorar la atencion, etc. (Oportunidad!!!!)

El problema es que las tecnologias  no estan prontas para lidiar con esa cantidad de datos, y aunque lo estuvieran, mover tantos datos a traves de la red no es practico, y ahi es donde viene el «eureka» (inicialmente de la gente de Google): «Y si mantenemos esos datos distribuidos por el mundo en servidores baratos y en vez de mover los datos distribuimos los programas para que actuen localmente?».

Esa es la filosofia atras de MapReduce o de Hadoop (la version opensource iniciada por Yahoo):

1. En vez de tener pocos servidores  grandes, utilicemos cientos/miles (o millones) de pequenos servidores distribuidos por el mundo

2. En vez de hacer backups, mantengamos n replicas distribuidas en x servidores

3. En vez de procesar los datos desde un lugar central, distribuyamos los programas hacia esos servidores, y que corran en paralelo (Map) y consolidemos los resultados (Reduce).

A modo de ejemplo, digamos que quiero contar cuantas veces aparece cada palabra en un conjunto de documentos:

– Subo los docs al cluster (digamos 50 servidores en Amazon)

– Escribo un programita java (map) que cuenta palabras en un doc, y saca duplets (palabra, numero de apariciones)

– Mando el programa a ejecutarse en los 50 servidores

– hago otro programa  que consolide resultados (reduce)

Como pueden ver, si tengo muchos datos y quiero bajar el tiempo de procesamiento a la mitad, lo unico que tengo que hacer es duplicar el numero de servidores, algo que no es tan simple con otras arquitecturas.

El tema no es dificil, pero exige pensar y diseñar los programas de software pensando de otra forma, en terminos de Map y Reduce, o en español simple  como paralelizar los tasks para que sea facil de escalar.

Aca va un link a un articulo de techcrunch sobre el tema