Llegamos a ustedes gracias a:



Reportajes y análisis

Big data, grandes retos

Hadoop en la empresa

[07/08/2015] A medida que trabajo con clientes empresariales más grandes, han surgido algunos temas de Hadoop. Uno muy común es que la mayoría de las empresas parecen estar tratando de evitar el dolor que experimentaron con el apogeo de JavaEE, SOA, y .Net, así como el terrible momento en que cada departamento tenía que tener su propio portal.

Para que eso acabe, están tratando de centralizar Hadoop, del mismo modo en que muchas empresas tratan de hacerlo con RDBMS o el almacenamiento. Aunque no usaría Hadoop para lo mismo que utiliza RDBMS, Hadoop tiene muchas ventajas sobre RDBMS en términos de manejabilidad. El paradigma de la fila de tiendas RDBMS (es decir, Oracle) tiene límites inherentes de escalabilidad, así que cuando se intenta crear una gran instancia o clúster RAC para servir a todos, no termina sirviendo a ninguno. Con Hadoop, tiene más capacidad para reunir los recursos informáticos y repartirlos.

Por desgracia, las herramientas de gestión e implementación de Hadoop siguen estando lejos de ser perfectas. A pesar de la mala reputación de Oracle, pude instalarlo a mano en minutos. La instalación de un clúster Hadoop, que no hace más que decir "hola mundo", tomará por lo menos varias horas. A continuación, cuando inicia el manejo de cientos o miles de nodos, encontrará que las herramientas son un poco escasas.

Las empresas están utilizando herramientas DevOps como Chef, Puppet, y Salt para crear soluciones manejables de Hadoop. Ellas se enfrentan a muchos desafíos en el camino hacia la centralización de Hadoop:

* Hadoop no es una cosa: Hadoop es una palabra que usamos para referirnos a "lo relacionado a big data" como Spark, MapReduce, Hive, HBase, y así sucesivamente. Hay una gran cantidad de piezas.

* Diversas cargas de trabajo: No solo necesita potencialmente equilibrar una carga de trabajo de Hive contra una carga de Spark, pero algunas cargas de trabajo son más constantes y sostenidas que otras.

* Partición: YARN es más o menos una versión clusterwide del planificador de procesos y el sistema de gestión de colas que usted toma por sentado en el sistema operativo de la computadora, teléfono o tableta que está utilizando en este momento. Le puede pedir que haga cosas, y las equilibra contra las otras acciones que está haciendo, y luego distribuye el trabajo de acuerdo a ello. Obviamente, esto es esencial. Pero existe la ley del más fuerte -y quién es usted menudo determina cuántos recursos obtiene. Además, los trabajos de streaming y trabajos por lotes pueden necesitar diferentes niveles de servicio. Es posible que no tenga más remedio que implementar dos o más clusters de Hadoop, que necesitará administrar por separado. Peor aún, ¿qué sucede cuando las cargas de trabajo son cíclicas?

* Prioridades: Aunque su organización puede querer aprovisionar un clúster Spark de mil nodos, esto no significa que tiene el derecho a mil nodos. ¿Puede realmente obtener los recursos que necesita?

Por un lado, muchas organizaciones han desplegado Hadoop con éxito. Por otro lado, si esto huele a la construcción de sus propias PaaS con herramientas DevOps, su nariz está funcionando correctamente. Usted no tiene muchas opciones todavía. Las soluciones están llegando, pero ninguna aun resuelve realmente los problemas de despliegue y mantenimiento de Hadoop en una organización grande:

* Ambari: Este proyecto Apache es una maravilla y una cosa asombrosa cuando funciona. Cada versión se pone mejor y gestiona más nodos. Pero Ambari no es para aprovisionar más máquinas virtuales y hace un mejor trabajo en el aprovisionamiento que en el reaprovisionamiento o reconfiguración. Ambari probablemente no es una solución a largo plazo para el aprovisionamiento de los grandes entornos con diversas cargas de trabajo.

* Slider: Slider permite que las aplicaciones que no son de YARN sean gestionadas por YARN. Muchos proyectos de Hadoop en Apache realmente son controlados o patrocinados por uno de los principales proveedores. En este caso, el patrocinador es Hortonworks, por lo que vale la pena ver la hoja de ruta de Hortonworks en busca de Slider. Una de las novedades más interesantes es la posibilidad de implementar aplicaciones Dockerized a través de YARN en base a su carga de trabajo. Aun no lo he visto en la producción, sin embargo, es muy prometedor.

* Kubernetes: Admito ser parcial con kubernetes porque no puedo deletrearlo. Kubernetes es una manera de poner en común los recursos informáticos al estilo Google. Nos acerca un paso más a una sensación PaaS en Hadoop. Puedo ver un futuro potencial cuando se utiliza OpenShift, Kubernetes, Slider, YARN, y Docker juntos para gestionar un grupo diverso de recursos. Cloudera contrató a un ejecutivo de Google con esto en su currículum.

* Mesos: Mesos tiene cierta superposición con Kubernetes, pero compite directamente con YARN o más exactamente YARN/Slider. La mejor manera de entender la diferencia es que YARN es más como la programación tradicional. Si programa un proceso frentea recursos que YARN tiene a su disposición en el clúster. Mesos tiene una solicitud de aplicación, Mesos hace una oferta, y el proceso puede "rechazar" esa oferta y esperar una mejor, algo así como las citas. Si realmente desea entender esto en detalle, MapR tiene un buen tutorial (aunque posiblemente las conclusiones sean un poco sesgadas). Por último, hay un híbrido YARN/Mesos llamada Myriad. El ciclo como novedad se ha quemado un poco rápido para Mesos.

¿Qué tal si se opta por un proveedor de Hadoop en la nube pública? Bueno, hay algunas respuestas a esa pregunta. Por un lado, a una cierta escala, dejará de creer las afirmaciones de que Amazon es más barato que tener su propio equipo interno de TI manteniendo las cosas. Dos, muchas empresas tienen creencias (reales o imaginarias) alrededor de la seguridad y la regulación de los datos que les impiden irse a la nube. Tercero, subir grandes conjuntos de datos puede no ser práctico, basado en la cantidad de ancho de banda que puede comprar y el tiempo que se necesita para ser procesados/subidos. Por último, muchos de los mismos retos (especialmente alrededor de diversas cargas de trabajo) persisten en la nube.

Después de que desaparezca la guerra del programador y el tono estridente de las múltiples soluciones en el mercado se atenúe, con el tiempo tendremos eventualmente una solución llave en mano para hacer frente a múltiples cargas de trabajo, servicios diversos y diferentes casos de uso de tal forma que aprovisione los componentes de la infraestructura y servicio en demanda.

Por ahora, espere una gran cantidad de secuencias de comandos y recetas personalizadas. Las organizaciones que hacen uso a gran escala de esta tecnología simplemente no pueden esperar para comenzar la centralización. El costo de la construcción y el mantenimiento de clusters dispares sobrepasa el costo de la construcción de o el despliegue de tecnología inmadura personalizada.

Andrew C. Oliver es presidente y fundador de Data Mammoth (antes Open Software Integrators), una empresa de consultoría de datos basada en Durham, Carolina del Norte