Cómo enriquecer el Big Data con la experiencia Cloud

Una vez decidido el tipo de Cloud que necesitamos para nuestro proyecto, hay algunas cosas a tener en cuenta cuando trabajamos con Big Data en un entorno on-premise o en un CPD.

Big Data on-premise

Es cierto que en la mayoría de los casos nos encontramos con la baja utilización del hardware y uno de los principales peligros del Big Data en plataforma on-premise es, justamente, ese bajo nivel de uso.

Cuando se hace la inversión en hardware se dimensiona para que funcione correctamente durante los próximos dos años y eso implica que, durante esos primeros meses y años, probablemente hay una infrautilización del hardware adquirido.

Otros de los inconvenientes que nos podemos encontrar son la carencia de multi-tenancy en muchos casos, la dificultad de los modelos de autoservicio, un alto nivel de OPEX, y por encima de todo, la carencia de los conocimientos necesarios de Big Data como para llegar a gestionar y obtener éxito de los proyectos que se desarrollen. De hecho, prácticamente el 60% de los proyectos de Big Data fracasan por empezar demasiado a lo grande en lugar de tratar de empezar poco a poco.

Ahora bien, según hemos podido comprobar en Cloudera, con la evaluación de pruebas de concepto, en cuanto trabajamos o combinamos Big Data con cloud, aparecen muchas ventajas.

Big Data en la nube

Comenzar una prueba de concepto en una cloud pública es muy rápido y el coste de adquisición es simplemente el pago por uso. Iniciar, por tanto, Big Data en un entorno de cloud pública requiere de una inversión en hardware muy baja o nula, además de ser sencillo.

La capacidad de procesamiento y la de entrada-salida son claves en el Big Data donde la velocidad es una ventaja muy grande. El hecho de poder personalizar lo que se requiera en cada momento en cuanto a CPU, memoria y almacenamiento te da la flexibilidad que necesitas para continuar con el proyecto sin perder tiempo y dinero.

No es necesario tener máquinas más grandes desde el minuto uno sino que es posible ir adaptando y creciendo de una forma elástica. ¡Uno de los mayores beneficios del Cloud! Además y gracias a la perfecta automatización de los servicios en Cloudera, el nivel de personalización es muy alto. Es decir, que podemos escalar tanto como el proyecto lo demande en cada momento. Estos clústers son capaces de crecer y decrecer de forma dinámica, de manera que podemos añadir nodos o quitar nodos según sea necesario.

Por último, hay que destacar los temas de accesibilidad y seguridad. Al final cuando te planteas trabajar en entorno Big Data sobre cloud, siempre piensas en que el Big Data nace con el concepto de que los nodos workers o los discos van a fallar en algún momento. La verdad es que, según la experiencia que tenemos en Big Data con Cloudera más Google Cloud, no falla nunca. De hecho, a veces puede llegar un mensaje diciendo «tu máquina se ha migrado a otra instancia» y sigue funcionando. Puede haber problemas de conexión con tu proveedor de red o similar, pero desde luego, las máquinas jamás fallan.

Como enriquecer una infraestructura de Cloud

En PUE hemos conseguido enriquecer la experiencia, optimizar la infraestructura y añadir elementos interesantes con la combinación de cloud pública con Cloudera más Google Cloud en la parte de Big Data.

Dentro de esa arquitectura de Cloudera tenemos toda la parte de almacenamiento, de integridad de los datos, de servicios unificados, de capacidad de análisis, de procesamiento, todo el stack completo de Hadoop con diferentes elementos para cubrir, prácticamente, cualquier caso de uso de los que hay hoy en día, tanto de las ETLs tradicionales como todo lo que tiene ver con machine learning, deep learning, inteligencia artificial y demás.

Infraestructura

Dentro de un entorno Big Data lo más habitual, cuando empiezas a desarrollar proyectos, es tener varios entornos: entornos de pruebas, de testing, de desarrollo, de aceptación, de pre-producción y de producción. Normalmente, el de aceptación o pre-producción suele ser una copia exacta de producción y los entornos de pruebas suelen ser más reducidos a la hora de hacer pruebas previas.

Aquí hay una pregunta interesante que nos tenemos que hacer, ¿por qué tienen que ser todas las máquinas y todos los nodos exactamente iguales o tener la misma utilización?

Google ofrece la posibilidad de trabajar con máquinas de tipo preemptible. Esto quiere decir que son máquinas que tienen un coste mucho más reducido y que tenemos el riesgo de perder en cualquier momento, sin tener una perdida real para la empresa. Hay que tener en cuenta que el Big Data está pensado para eso, para poder perder nodos en cualquier momento.

Esto nos da la posibilidad de crear una infraestructura de Cloudera de Big Data, donde tenemos el entorno de producción, el cual dejamos como está, y, luego, los entornos de test y de pre-producción. En estos, lo que hacemos es dividir entre los habituales masters, workers y nodos Edge. Trabajar en el caso de los workers con nodos primarios, o workers primarios, y workers secundarios.

Los workers primarios tendrían el mismo sentido tradicional, es decir, un nodo que aporta almacenamiento a la infraestructura de HDFS, de Big Data, y nodos.

Los de tipo secundario son solamente nodos que aportan capacidad de procesamiento y que los gestionamos como instancias de tipo preemptible, es decir, no aportan al almacenamiento; solamente aportan capacidad de procesamiento. Además, todos los desarrollos y todas las aplicaciones que ponemos en marcha sobre un clúster de Cloudera son aplicaciones que tienen tolerancia al fallo y alta disponibilidad. Lo que queremos destacar es la reducción del coste en los secondary workers, donde podemos trabajar con instancias de tipo preemptible y que sabemos que podemos perder en cualquier momento pero cuesta hasta un 80% menos que el de una instancia normal, lo cual nos permite ajustar mucho más el presupuesto del proyecto.

Entonces, cuando se produce el evento del preempt lo que hacemos es controlar cuando sucede ese evento de apagado. Es decir, nos quitan la máquina, esto genera un evento que, en realidad, lo que hace es mediante un script enviar a Pub/Sub” que es un broker de servicios donde tenemos un topic, que es donde se envían estos estos mensajes diciendo «Oye, esta máquina se apaga». Con lo que, recibimos el evento y luego mediante una función ligera o cloud function, la cual tenemos a la escucha dentro de ese Pub/Sub que sabe que se ha parado la máquina, vemos que tenemos un nodo menos. Es decir, en todo momento, aunque nos quiten la máquina, sabemos que la máquina se “ha quitado de en medio”.

En esta situación, podemos tomar la medida que creamos más conveniente, incluso, volver a intentar levantar la máquina de nuevo. Si hay recursos suficientes, estará disponible y si no los hay, pues habremos perdido un nodo, pero podemos controlar la parada y volver a dar la orden de empezar a trabajar de nuevo. En algunos casos, la parte de la infraestructura del software que hay por encima, Cloudera en este caso, no detecta que ha perdido un nodo lo que hace que todo siga funcionando correctamente sin pérdida de valor.

Almacenamiento

Dentro de un clúster de Cloudera, tenemos HDFS (Hadoop Distributed File System), para propósito general, tenemos KUDU para operaciones más al estilo de base de datos relacionales, donde podemos insertar, borrar, eliminar datos en una base de datos SQL, y HBASE, que sería el no SQL de Hadoop.

Lo que enriquece la parte de almacenamiento, gracias tanto a Google como Cloudera, es utilizar conjuntamente HDFS y GCS mediante el Google Cloud Storage, es decir, utilizar GCS para almacenamiento adicional de la infraestructura Big Data. Con HDFS toda la información que guardo está pensada para que los datos se guarden por triplicado, para evitar que cuando pierda un disco o pierda un nodo, el almacenamiento aportado por ese nodo me suponga una pérdida de datos.

Si almacena por triplicado los costes aumentan, pero si uso Google Cloud Storage me permite poder reducir la capacidad de HDFS para utilizar GCS donde pago por cada giga que tenga almacenado. Es decir, ahí ya no necesito un HDFS por triplicado, sólo pagar los gigas necesarios en GCS para el respaldo de datos de mi disco principal. También existe la posibilidad de encriptado o cifrado que me proporciona Cloudera, es decir, los datos que van sobre la HDFS van a estar cifrados.

Proceso, análisis y servicio de los datos

En una distribución de Big Data tenemos elementos como Spark, para procesamiento Spark Streaming, procesamiento en tiempo real, Impala para servir datos a modo de base de datos, SolR para realizar búsquedas y Kafka como bus de integración de servicios.

En Cloudera, sobre esa base estándar lo que podemos hacer es incrementar diferentes funcionalidades, como por ejemplo, a la hora de crear nuevos modelos de machine learning o con una de las de las APIS que funciona de maravilla de Google, que es la API del Cloud Vision, referente a la computer vision o la visión del computador.

Realizar este tipo de integraciones con las herramientas tradicionales era muy complejo, pero en un entorno cloud, teniendo unos datos en mi cluster de Big Data, puedo utilizar las APIs que me proporciona Google para procesar masivamente, por ejemplo, las imágenes que necesito, según el ejemplo que hemos comentado anteriormente de Cloud Vision y siguiente con el modelo de pago por uso. Es decir, sólo pago por las imágenes que necesito procesar lo que nos ahorra mucho tiempo y dinero, ya que no tengo que desarrollar algo específico para el reconocimiento de imágenes.

Big Data y Cloud

Lo que está claro es que la integración de estos dos mundos es cada vez mayor por los beneficios que ambos reportan a los proyectos. Big Data y Cloud se combinan extraordinariamente para sacar lo mejor de cada uno de ellos. Además, el modelo de pago por uso y la capacidad de procesamiento cloud nos ayuda a que nuestros proyectos se desarrollen mucho más rápido con un menor coste, ya que no necesitamos desarrollos a medida desde cero y en muchos casos podemos utilizar APIs de terceros. Una gran solución que se aplica cada día más en las grandes y medianas empresas.