Algunas ideas de adopción de Infraestructuras basadas en Hadoop a mediano plazo

Hadoop es complejo de explicar, la idea base es que un tipo de base de datos que labura muy bien datos complejos, estructurados, pero que no encajan muy bien tablas.

Ver:
http://dataminingcafe.blogspot.com.ar/2011/11/hadoop-que-es-como-funciona-y-que-puede.html


Además Hadoop se banca muy pero muy bien el que una aplicación requiera mucho poder de cálculo y trabaje sobre mucha cantidad de datos crudos. Del artículo:

"..En las finanzas, si quiere hacer evaluación de carteras y análisis de riesgo precisos, puede construir modelos sofisticados que son difíciles de meter en un motor de base de datos. Pero Hadoop puede manejarlo. En el comercio minorista en línea, si quiere dar mejores respuestas a las búsquedas de sus clientes de modo que sean más propensos a comprar lo que  usted le muestra."


Jugo Extra
Pero hay más...podés montar Hadoop en servers baratos (porque es un sistema distribuído), servers de bajo costo, podés meter Hadoop en todo un rack de servers baratos a hacer cálculos y ejecutar tareas que comparativamente, para poder trabajarlas con bases de datos clásicas (y su esquema de implementación típico), te costaría muchísimo en hardware. Eso es porque cada máquina que se agrega a un ambiente Hadoop suma su poder de cálculo al resto. No importa si tenés una base de datos en un server con 4 procesadores y 256 GB de ram, comparativamente una aplicación Hadoop puede conseguir mucho mayor poder de cálculo de su hardware por mucho menor costo.

Si se pierde un server (se quema, etc.), Hadoop sigue funcionando, comprás otro server, lo conectás al ambiente Hadoop, y voilá, volvemos a tener el server perdido.

De hecho...muchas implementaciones de Hadoop están basadas en hardware muy simple, muy cerca de ser PCs de escritorio muy potentes (buena RAM, mucho procesador), pero todo extremadamente barato..ya que cada "server" no tiene prácticamente nada de redundancia (un solo disco o un espejo a lo sumo, una sola fuente, un solo procesador, etc. etc.). La redundancia es lo que vuelve caros a los servers.

Las garantías que hace falta para un server de nivel empresarial típico, no hacen faltan para un nodo-server Hadoop, porque si se pierde el server, es muy barato de reemplazar, y si perdés alguno (o varios), tu base de datos no deja de funcionar.

[El software de base de datos clásico tiene un issue con esa capacidad de clustering de procesamiento masivo de Hadoop basado en hardware muy barato: no tiene esta característica. 

Si querés que una base de datos clásica sume poder de cálculo con cada server que se integre a un cluster, es muy probable que estemos hablando de comprar licencias de algun producto comercial y además tengamos que adquirir hardware de servidores especializado.]


Aplicaciones
Dicho todo eso, ¿donde están las aplicaciones Hadoop para sacarle partido a esta tecnología?

O sea, un clásico ABM basado en GUI web debería poder ser bastante fácil de montar con un backend Hadoop verdad? De hecho, la web de Yahoo tiene varios componentes que funcionan directamente sobre Hadoop como backend (exactamente al estilo "LAMP", pero sin Mysql).

Noticias: todavía no hay una presencia masiva de apps fáciles de montar sobre Hadoop.

Pero si Hadoop puede hacer cosas como "..si quiere dar mejores respuestas a las búsquedas de sus clientes de modo que sean más propensos a comprar lo que  usted le muestra", eventualmente las apps opensource van a empezar a aparecer, tal como sucedio con los CMS y luego los frameworks PHP para Mysql (y ambos tardaron sus buenos años en aparecer).

Por ahora si querés ver algo "volando" en Hadoop (y aprovechar la tremenda bajada de costos en hardware y la subida en poder de cálculo y alta disponibilidad automática y barata), vas a tener que programarlo vos.

No quiere decir que no podamos aprender a montar un Hadoop hoy mismo, eventualmente algun CRM, ERP o algun soft por el estilo va a aparecer y nos veremos instalandolo sobre Hadoop tal cual hoy instalamos algun Wordpress para la intranet en nuestra organización.


TCO?
Por ahora el TCO sigue del lado de las bases de datos relacionales, sin embargo, Hadoop y software similar tiene la ventaja a futuro: 

* Los sets de datos a procesar van a ser cada vez más masivos, y el hardware de servidores no baja sus precios (veanlo año a año), de hecho con nuevas tecnologías de redundancia incorporadas cada vez más a menudo, aumenta de costo respecto a años anteriores (más costo por mayor redundancia, pero no implica que el server vaya a ser soportado más tiempo de lo habitual: 2 a 5 años máximos).

* El software nosql como Hadoop no tiene costos de licenciamiento, da lo mismo si tenemos un solo server (poco práctico), o 150 servers Hadoop. Ahora tomen su base de datos comercial típica y vean cuanto les costaría montar un cluster de 150 bases de datos. Y que tal si hace falta montar 1500 nodos?

* Poder sumar y restar nodos a voluntad tiene aplicaciones prácticas reales, mucho más allá de la redundancia de datos. Los nodos pueden sumar capacidad temporalmente, vía implementaciones en nube (privada o pública), y luego escalar hacia atrás cuando ya no haga falta esa capacidad de procesamiento.

* HDFS (el filesystem distribuído de Hadoop), se puede utilizar como storage hiper-resiliente. El CERN lo usa así para almacenar la información que luego consumiran un par de decenas de aplicaciones Hadoop (alrededor del mundo).

(es un lujo la explicación, vean las preguntas de la mitad de la entrevista)
http://letsfollowthewhiterabbit.blogspot.com.ar/2012/12/free-software-at-cern-or-how-did-foss.html

* Si se implementa un backend sobre Hadoop, y debido a que no es una base SQL "completa", y ello implicara un alto costo en consumo de recursos (más disco, memoria, procesador, etc.), ello podría ser incluso aceptable a un alto "costo" , debido a que el TCO se inclina a favor de Hadoop porque una base datos tradicional tendría mayor TCO.

Por ejemplo: Montar Hadoop en 10 servers de AR$ 7000 vs. montar un solo server de base de datos de AR$ 70.000.

Si se pierde el server de AR$ 70.000, nos quedamos sin base de datos, es decir, en realidad necesitamos otro server de AR$ 70.000, así que el costo real es de AR$ 140.000. En cambio, la probabilidad de fallo de un sistema con 8 servers es menor (dado una adecuada arquitectura en la integración de todos los servers al cluster Hadoop), igualmente se puede comprar y tener en standby, apagados, al menos dos servers para ir tenerlos de reemplazo. Las compras futuras de sostenimiento de la infraestructura se pueden espaciar en el tiempo, disminuyendo el capital inmobilizado, que en el otro caso serían los AR$ 70.000 del server DB de "backup" (secundario en el cluster en realidad), que va a estar sirviendo, tal vez solo como instancia de solo lectura de la DB principal (que podría obtener todo el poder de procesamiento que necesita para funcionar de un solo server de AR$ 70.000, aunque no podamos prescindir de tener 2 servers).

En el caso de gastar los AR$ 140.000 directamente en 14 servers para Hadoop, el cluster se beneficia del total de la capacidad de procesamiento que prácticamente de seguro va ser bastante superior a la capacidad de procesamiento de un solo server de AR$ 70.000. Según los valores nominales de capacidades de cálculo por procesador y en relación con la capacidad de cálculo típica de un server de AR$ 70.000.

La resiliencia de un esquema de 14 servidores vs. lo mismo en 2, está muy a favor de Hadoop también.

etc. etc. Hay varias posibilidades más favorables a Hadoop y varios casos no favorables a una implementación tan resiliente y barata (que la app tenga un backend Oracle, y no pueda funcionar con nada más, y listo, chau Hadoop). 

Para apps nuevas, no debería haber mayores problemas que ir absorbiendo lentamente el impacto de la curva de aprendizaje (salir de LAMP y entrar a Hadoop no sale gratis para una organización, en recursos a consumir). Al momento en que se popularicen aplicaciones opensource, esa curva de aprendizaje se va a suavizar un poco (tal vez solo dejando en manos del developer algun framework para trabajar sobre un front-end que se relaciona con Hadoop desde un nivel muy alto).


Conclusiones
La idea general es que al menos al momento, las circunstancias técnicas indican un futuro prometedor para Hadoop y sistemas similares (tal vez esté ahí una de las respuestas a su crecimiento exponencial en implementaciones en los últimos años).