Re: [spain-scalability] Información inicializacion proyecto big data

29 views
Skip to first unread message

Angel Java Lopez

unread,
Dec 10, 2012, 12:43:29 PM12/10/12
to spain-scala...@googlegroups.com
Hola gente!

Tengo 0 experiencia en Hadoop, pero por lo que entendi, hay un punto a tener en cuenta: muchos proyectos Hadoop lo que hacen es TENER YA los datos en los nodos. Supongamos, podria implementar una busqueda de los datos que cumplen un criterio, y sumarlos, enviarlo a 10 nodos Hadoop, pero se prefiere que entonces esos 10 nodos YA tengan los datos a procesar. Es decir, lo que se reparte es el proceso, los datos YA estan de antemano en cada nodo.

Si tuviera que contar, digamos, las palabras de las obras completas de Shakespeare, repartiria ese texto en 10 nodos. Y cuando tuviera que contar la cantidad de veces que aparece "queen", enviaria ese nuevo "job" a los 10 nodos, y cada uno buscaria en la parte de la obra completa que le haya tocado tener localmente. Pero esos datos ya estan en los nodos, se repartieron alguna vez, pero ya no se reparten a los nodos con cada nuevo job/query.

Es asi? O tambien se usa: las obras completas estan en UNA base de datos Oracle, se envia el query/job a los 10 nodos, y cada nodo le pide a la base de datos: dame la parte de la obra que a mi me corresponda, o busca en las obras que me corresponden como nodo n la palabra "queen"? Creo que ahi se pierde un poco la ventaja de Hadoop, entre el cuello de botella de red llegando al servidor Oracle, y el trabajo que se le delega, es como que se pierde la ventaja Hadoop.

De nuevo pregunto, es asi?

En los casos en los que hay que procesar datos, digamos big data, el feed de tweeter, y demas, lo que vi es: hay un lugar que los recibe, los pone en una o varias colas, y hay varios nodos/servidores que van consultando de la(s) cola(s) y procesando, por ejemplo, usando Storm.

Nos leemos!

Angel "Java" Lopez
@ajlopez
gh:ajlopez

2012/12/7 rafael valenzuela moraleda <rav...@gmail.com>
Hola a todos,
Tengo unos cuantas preguntas sobre NoSQL y escalabilidad,estamos montando nuestro sistemas de NoSQL movemos aproximadamente unos 16 pentabyte por día,hacia nuestro Datawarehouse (usamos el modelo datavault) las bases de datos son Oracle y postgredb de origen, y el sistema lo vamos a montar en hadoop, cassandra y puede storm 
 
Les he intentado explicar algunas cosas como funciona hadoop y que no es igual hadoop , cassandra que Oracle. Pero quiero ver otras opiniones sobre ciertas preguntas que me han realizado.
  •  Como harías la migración del sistemas "clásicos" a el de nodos (hadoop y cassandra) ? Ahora usamos procesos ETL para el envió de los datos y en el flojo realizamos map-reduce , pero mis jefes "quieren guardar toda la información" una vez transformada en una base de datos.
  • ¿Qué tendrías en cuenta? ademas del numero de nodos para realizar el map-reduce
  • Beneficiós e incovenientes,
  • Control de información
  • Arquitectura
A ver si me podéis dar opiniones
Gracias 

Marc de Palol

unread,
Dec 10, 2012, 1:05:32 PM12/10/12
to spain-scala...@googlegroups.com
Buenas, contesto entre lineas. 

2012/12/7 rafael valenzuela moraleda <rav...@gmail.com>
Hola a todos,
Tengo unos cuantas preguntas sobre NoSQL y escalabilidad,estamos montando nuestro sistemas de NoSQL movemos aproximadamente unos 16 pentabyte por día,hacia nuestro Datawarehouse (usamos el modelo datavault) las bases de datos son Oracle y postgredb de origen, y el sistema lo vamos a montar en hadoop, cassandra y puede storm 
 
Les he intentado explicar algunas cosas como funciona hadoop y que no es igual hadoop , cassandra que Oracle. Pero quiero ver otras opiniones sobre ciertas preguntas que me han realizado.
  •  Como harías la migración del sistemas "clásicos" a el de nodos (hadoop y cassandra) ? Ahora usamos procesos ETL para el envió de los datos y en el flojo realizamos map-reduce , pero mis jefes "quieren guardar toda la información" una vez transformada en una base de datos.
Me encontré con un caso similar y la verdad es que no hay una solución fácil. Se trata de mover los datos simplemente, pero tendrás que hacer los números y ver cuandos días vas a tardar en mover los datos de vuestro warehouse existente al cluster de hadoop. Si teneis que mover petabytes creo que lo más práctico va a ser poner una conexión dedicada o algo asi. 

De todos modos, si ya tenéis la información en el cluster de Hadoop lo que haría es instalar Hive (os va a dar una visión de tablas relacionales sobre estos datos). Supongo que esto es lo que quieren tus jefes no? una BBDD relacional encima de hadoop? 
  • ¿Qué tendrías en cuenta? ademas del numero de nodos para realizar el map-reduce
Bueno, esto es una pregunta muy amplia. Hay que tener en cuenta muchas cosas, pero lo que veo una vez y otra es el problema de espacio. Los problemas vienen por falta de espacio en el clúster (más que las máquinas no sean lo suficiente potentes como para procesar los datos rápidamente). Ten en cuenta que es importante que las máquinas tengan muchos discos duros, que no sean caros (porque se van a estropear).  
  • Beneficiós e incovenientes,
Aquí otra pregunta amplia :) y sobretodo depende de lo que estáis haciendo con los datos. La verdad es que sin saberlo no te puedo decir mucho, lo que si es que con hadoop es relativamente fácil implementar programas que saquen más información de lo que podrías sacar con SQL. También tienes herramientas como PIG que sirven para facilitar la escritura de jobs y demás. Seguro que otra gente de la lista te puede dar más detalles. 

Para mi el principal beneficio de usar Cassandra/Hadoop como almacenamiento de datos es que te da una muy buena tolerancia a fallos y una muy buena escalabilidad horizontal. Si necesitas más potencia pones más máquinas commodity. 
  • Control de información
No se exactamente a qué te refieres? Si te refieres a permisos/seguridad vas a ver que Hadoop no está muy avanzado en esto. Siempre se ha tenido la idea que el cluster de Hadoop va a ser interno. Aún así se que se ha trabajado bastante en añadir Kerberos. Luego tiene un sistema de permisos de usuarios muy muy simples, pero te pueden servir. Siento no poder ayudar más en este punto.  
  • Arquitectura
La arquitectura dependerá muchísimo de lo que estés intentando hacer. Las típicas arquitecturas de Hadoop/Nosql para data warehousing que he visto son más o menos: 

1) Introducir datos en el cluster mediante scripts (o ahora mismo, apache flume).
2) En caso de que trabajes con Hadoop + cassandra, introducir los datos directamente a Cassandra. 

3) Tener un scheduler o una serie de scripts que dia a dia agreguen información y en definitiva la traten. 

4) Guardar los datos tratados en Cassandra/HDFS, borrar los datos temporales, en caso de que haya y generar las "vistas" o lo que serían los datos que tienen que estar MÁS accesibles. Por ejemplo, imagínate que tienes el siguiente worklfow: 
  - Coges los datos de hoy. 
  - Coges los datos anteriores. 
  - Realizas unas operaciones. 
  - Guardas el resultado de las operaciones en una tabla de Cassandra para que vuestra web (o lo que sea) los pueda leer bien. 
  - Agregas los datos de hoy con los de ayer y "sobrescribes" los anteriores porque los vas a necesitar mañana. 

Espero que haya sido claro. 

En caso de la agregación de datos, ten en cuenta que Hadoop es un sistema de batch, hay mucha gente que complementa la fuerza bruta batch de Hadoop con jobs diarios por ejemplo y luego sobre estos resultados aplica Storm para calcular los intervalos más pequeños. Otro ejemplo: 

- Necesitas los datos actualizados "real time": 
  - Cada dia coges los datos que has recibido hoy y los machacas con Hadoop. 
  - Con storm agregas los datos real time con los datos de Hadoop. 
  - Al finalizar el dia Hadoop vuelve a recalcular los datos y haces que Storm coja como base lo que ha hecho Hadoop.  

A ver si me podéis dar opiniones
Gracias 

Espero que todo se haya entendido medianamente bien, no dudes en reclamar aclaraciones o "ampliaciones". 

Un saludo!
Reply all
Reply to author
Forward
0 new messages