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.<\/p>\n\n\n\n
Es cierto que en la mayor\u00eda de los casos nos encontramos con la baja utilizaci\u00f3n del hardware y uno de los principales peligros del Big Data en plataforma on-premise es, justamente, ese bajo nivel de uso.<\/p>\n\n\n\n
Cuando se hace la inversi\u00f3n en hardware se dimensiona para que funcione correctamente durante los pr\u00f3ximos dos a\u00f1os y eso implica que, durante esos primeros meses y a\u00f1os, probablemente hay una infrautilizaci\u00f3n del hardware adquirido.<\/p>\n\n\n\n
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 \u00e9xito de los proyectos que se desarrollen. De hecho, pr\u00e1cticamente el 60% de los proyectos de Big Data fracasan por empezar demasiado a lo grande en lugar de tratar de empezar poco a poco.<\/p>\n\n\n\n
Ahora bien, seg\u00fan hemos podido comprobar en Cloudera, con la evaluaci\u00f3n de pruebas de concepto, en cuanto trabajamos o combinamos Big Data con cloud, aparecen muchas ventajas.<\/p>\n\n\n\n
Comenzar una prueba de concepto en una cloud p\u00fablica es muy r\u00e1pido y el coste de adquisici\u00f3n es simplemente el pago por uso. Iniciar, por tanto, Big Data en un entorno de cloud p\u00fablica requiere de una inversi\u00f3n en hardware muy baja o nula, adem\u00e1s de ser sencillo.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
No es necesario tener m\u00e1quinas m\u00e1s grandes desde el minuto uno sino que es posible ir adaptando y creciendo de una forma el\u00e1stica. \u00a1Uno de los mayores beneficios del Cloud! Adem\u00e1s y gracias a la perfecta automatizaci\u00f3n de los servicios en Cloudera, el nivel de personalizaci\u00f3n es muy alto. Es decir, que podemos escalar tanto como el proyecto lo demande en cada momento. Estos cl\u00fasters son capaces de crecer y decrecer de forma din\u00e1mica, de manera que podemos a\u00f1adir nodos o quitar nodos seg\u00fan sea necesario.<\/p>\n\n\n\n
Por \u00faltimo, 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\u00fan momento. La verdad es que, seg\u00fan la experiencia que tenemos en Big Data con Cloudera m\u00e1s Google Cloud, no falla nunca. De hecho, a veces puede llegar un mensaje diciendo \u00abtu m\u00e1quina se ha migrado a otra instancia\u00bb y sigue funcionando. Puede haber problemas de conexi\u00f3n con tu proveedor de red o similar, pero desde luego, las m\u00e1quinas jam\u00e1s fallan.<\/strong><\/p>\n\n\n\n En PUE hemos conseguido enriquecer la experiencia, optimizar la infraestructura y a\u00f1adir elementos interesantes con la combinaci\u00f3n de cloud p\u00fablica con Cloudera m\u00e1s Google Cloud en la parte de Big Data.<\/p>\n\n\n\n Dentro de esa arquitectura de Cloudera tenemos toda la parte de almacenamiento, de integridad de los datos, de servicios unificados, de capacidad de an\u00e1lisis, de procesamiento, todo el stack completo de Hadoop con diferentes elementos para cubrir, pr\u00e1cticamente, cualquier caso de uso de los que hay hoy en d\u00eda, tanto de las ETLs tradicionales como todo lo que tiene ver con machine learning, deep learning, inteligencia artificial y dem\u00e1s.<\/p>\n\n\n\n Dentro de un entorno Big Data lo m\u00e1s habitual, cuando empiezas a desarrollar proyectos, es tener varios entornos: entornos de pruebas, de testing, de desarrollo, de aceptaci\u00f3n, de pre-producci\u00f3n y de producci\u00f3n. Normalmente, el de aceptaci\u00f3n o pre-producci\u00f3n suele ser una copia exacta de producci\u00f3n y los entornos de pruebas suelen ser m\u00e1s reducidos a la hora de hacer pruebas previas.<\/p>\n\n\n\n Aqu\u00ed hay una pregunta interesante que nos tenemos que hacer, \u00bfpor qu\u00e9 tienen que ser todas las m\u00e1quinas y todos los nodos exactamente iguales o tener la misma utilizaci\u00f3n?<\/p>\n\n\n\n Google ofrece la posibilidad de trabajar con m\u00e1quinas de tipo preemptible. Esto quiere decir que son m\u00e1quinas que tienen un coste mucho m\u00e1s 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\u00e1 pensado para eso, para poder perder nodos en cualquier momento.<\/p>\n\n\n\n Esto nos da la posibilidad de crear una infraestructura de Cloudera de Big Data, donde tenemos el entorno de producci\u00f3n, el cual dejamos como est\u00e1, y, luego, los entornos de test y de pre-producci\u00f3n. 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.<\/p>\n\n\n\n Los workers primarios tendr\u00edan el mismo sentido tradicional, es decir, un nodo que aporta almacenamiento a la infraestructura de HDFS, de Big Data, y nodos.<\/p>\n\n\n\n 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\u00e1s, todos los desarrollos y todas las aplicaciones que ponemos en marcha sobre un cl\u00faster de Cloudera son aplicaciones que tienen tolerancia al fallo y alta disponibilidad. Lo que queremos destacar es la reducci\u00f3n 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\u00e1s el presupuesto del proyecto.<\/p>\n\n\n\n Entonces, cuando se produce el evento del preempt lo que hacemos es controlar cuando sucede ese evento de apagado.\u00a0 Es decir, nos quitan la m\u00e1quina, esto genera un evento que, en realidad, lo que hace es mediante un script enviar a Pub\/Sub\u201d que es un broker de servicios donde tenemos un topic, que es donde se env\u00edan estos estos mensajes diciendo \u00abOye, esta m\u00e1quina se apaga\u00bb. Con lo que, recibimos el evento y luego mediante una funci\u00f3n ligera o cloud function, la cual tenemos a la escucha dentro de ese Pub\/Sub que sabe que se ha parado la m\u00e1quina, vemos que tenemos un nodo menos. Es decir, en todo momento, aunque nos quiten la m\u00e1quina, sabemos que la m\u00e1quina se \u201cha quitado de en medio\u201d.<\/p>\n\n\n\n En esta situaci\u00f3n, podemos tomar la medida que creamos m\u00e1s conveniente, incluso, volver a intentar levantar la m\u00e1quina de nuevo. Si hay recursos suficientes, estar\u00e1 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\u00e9rdida de valor.<\/p>\n\n\n\n Dentro de un cl\u00faster de Cloudera, tenemos HDFS (Hadoop Distributed File System), para prop\u00f3sito general, tenemos KUDU para operaciones m\u00e1s al estilo de base de datos relacionales, donde podemos insertar, borrar, eliminar datos en una base de datos SQL, y HBASE, que ser\u00eda el no SQL de Hadoop.<\/p>\n\n\n\n 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\u00f3n que guardo est\u00e1 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\u00e9rdida de datos.<\/p>\n\n\n\n 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\u00ed ya no necesito un HDFS por triplicado, s\u00f3lo pagar los gigas necesarios en GCS para el respaldo de datos de mi disco principal. Tambi\u00e9n existe la posibilidad de encriptado o cifrado que me proporciona Cloudera, es decir, los datos que van sobre la HDFS van a estar cifrados.<\/p>\n\n\n\n En una distribuci\u00f3n 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\u00fasquedas y Kafka como bus de integraci\u00f3n de servicios.<\/p>\n\n\n\n En Cloudera, sobre esa base est\u00e1ndar 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\u00f3n del computador.<\/p>\n\n\n\n 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\u00e1genes que necesito, seg\u00fan el ejemplo que hemos comentado anteriormente de Cloud Vision y siguiente con el modelo de pago por uso. Es decir, s\u00f3lo pago por las im\u00e1genes que necesito procesar lo que nos ahorra mucho tiempo y dinero, ya que no tengo que desarrollar algo espec\u00edfico para el reconocimiento de im\u00e1genes.<\/p>\n\n\n\n Lo que est\u00e1 claro es que la integraci\u00f3n 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\u00e1s, el modelo de pago por uso y la capacidad de procesamiento cloud nos ayuda a que nuestros proyectos se desarrollen mucho m\u00e1s r\u00e1pido 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\u00f3n que se aplica cada d\u00eda m\u00e1s en las grandes y medianas empresas.<\/p>\n\n\n\n Big Data y Cloud frente a los nuevos paradigmas provocados por el COVID-19<\/a><\/p>\n\n\n\n Nuestros servicios<\/a><\/p>\n\n\n\nComo enriquecer una infraestructura de Cloud<\/strong><\/h4>\n\n\n\n
Infraestructura<\/h4>\n\n\n\n
Almacenamiento<\/h4>\n\n\n\n
Proceso, an\u00e1lisis y servicio de los datos<\/strong><\/h4>\n\n\n\n
Big Data y Cloud<\/strong><\/h4>\n\n\n\n
Links de inter\u00e9s<\/h4>\n\n\n\n