Desde el punto de vista de almacenamiento del dato, tenemos soluciones para almacenamiento de tipos "batch", como es Sqoop, que lo que hace es conectar nuestras bases de datos MySQL, Oracle, etcétera, y volcar la información a nuestro "data lake" famoso. Existen soluciones "streaming" que lo que hacen es asegurarte que se van a ir obteniendo los datos a medida que se vayan generando de nuestra fuente, como son Flume y Storm, Flume en soluciones Cloudera, Storm en soluciones Hortonworks, aunque es verdad que Storm no se puede instalar en soluciones Cloudera también. Hay una cosa importante cuando se están generando los datos de manera "streaming", y es la organización, cuando llega un dato tenemos que saber que ese dato llega en ese momento, y antes de otro dato y después de otro dato, y asegurarnos de que ese dato no lo perdemos. Para ello, usamos un orquestador, que se denomina Kafka, que nos permite enganchar con Flume o con Storm para ir cogiendo el dato y de manera organizada almacenándolo, crea una ventana de tiempo y va ajustando esos tiempos para ir almacenando los datos. Otras soluciones que nos permiten también hacer procesamiento en tiempo real, no sólo obtener el dato, sino lo proceso en ese momento de manera muy rápida, es las soluciones que ofrece Spark con Spark Streaming y la solución Flink,, que es la competidora de Spark, que también tiene su solución Flink Streaming. Y, por último, Apex, que también está en incubadora y que también está ofreciendo una solución en "batch" y en "streaming" de procesamiento del dato. Promete mucho, aunque todavía está en incubadora. Desde el punto de vista en navegación de una manera visual, es decir, mediante la "web", tenemos el componente Hue, que es un componente que existe tanto en Cloudera como en Hortonworks, y una solución que se denomina Cloudera Navigator que, como su nombre indica, procede de la solución Cloudera. Desde el punto de vista de consulta de datos mediante consulta búsquedas, tenemos la solución Elastic, que ya habíamos hablado anteriormente, una solución muy parecida a Lucene que se llama Solr que, si bien antes no la usaba Cloudera, ahora ya la ha implantado Cloudera. Previamente, Cloudera tenía una que se llamaba Cloudera Search, que se ha demostrado que era menos potente que la solución Solr, de ahí que se implantara. Desde el punto de vista de seguridad, ofrecen soluciones diferentes, tanto Cloudera como Horton. Cloudera ofrece una solución Sentry que es una solución global de control, acceso y "gateway" para controlar el acceso a ese dato y, sin embargo, Horton tiene dos soluciones, tres soluciones en realidad, Knox, Ranger y Kerberos. Knox nos está asegurando la conectividad desde el punto de vista de red, Ranger, la accesibilidad al dato, y Kerberos, la seguridad del dato, es decir, encriptación del dato. Desde el punto de vista de qué es lo que está produciendo, qué es lo que está ocurriendo sobre cada una de las máquinas, cómo es el estado de las máquinas, si está apagada, si está encendida, si está hasta arriba, si no, si tiene mucha memoria usada, si no, se utilizan varias soluciones, en Horton, Ambari, en Cloudera, Cloudera Director. Tened en cuenta que Cloudera Director es una solución de pago, hay que pagar por tener esa solución, sino tenés que intentar, de alguna manera, configurar Ambari dentro de una distribución Cloudera. Y una cosa súper interesante es CloudBreak. CloudBreak, lo que nos va a permitir es controlar clusters de clusters, es decir, si yo tengo una solución Hadoop basada en Hortonworks y una solución Cloudera, ¿por qué no unificarlas en una sola visión que es la visión global de CloudBreak?, donde me va a decir cómo va a estar el estado del cluster de Cloudera y cómo está el estado del cluster Hortonworks. Desde el punto de vista de orquestación, como hemos dicho antes, Yam nos va a controlar qué procesos se están ejecutando, cuál es el estado de esos procesos, qué cola de procesos faltan, cuántos recursos se van a usar en nuestro sistema o infraestructura, y cuál es el estado futuro de nuestras máquinas. Es muy importante que Yarn tenga la visión de todos los recursos de nuestro sistema, porque si no tiene visión, no lo estamos usando. Yam es el que dice, "se puede usar" o "no se puede usar". Desde el punto de vista de flujo de trabajo, existe una solución Oozie que se utiliza también en sistemas de producción, que es como un "workflow" de trabajos, ejecuta esto, luego, esto, luego, esto y, luego, esto. No deja de ser un "script" que va ejecutando cada uno de los procesos, pero nos sirve muchísimo el hecho de poder tenerlo configurado en sistemas Big Data porque, de manera automática, se van a ejecutar esos procesos. Es verdad que como es una solución "scripting" es poco amigable, para ello inventaron una solución que se llama Nifi que es, mediante una interfaz gráfica, poder ir creando nodos, que van interconectados entre sí mediante flechitas que permite hacer ciertas operaciones, una detrás de otra. Si bien es muy intuitivo, no es válido para utilizar en producción, puesto que Nifi, que está basado en Java, es muy lento y muy pesado. Zookeeper, como hemos definido antes, es nuestro cuidador del zoo que lo que nos define es la alta disponibilidad de cada una de las aplicaciones de nuestra infraestructura Big Data. ¿Qué quiere decir eso? Nos asegura de alguna manera que, cuando queramos acceder a una aplicación o a un software de nuestra plataforma, ese va a responder porque Zookeeper se va a encargar de que responda, le va a dar palos hasta que responda, básicamente. Y luego, soluciones de gobernanza del dato, que bien habíamos hablado previamente. Existe la solución Atlas y existe la solución Falcon. Atlas tiene soporte tanto en Cloudera como en Hortonworks y Falcon sólo en Hortonworks. Por último, la parte de analítica, la parte más abierta de todas, donde más se ha desarrollado. Si bien es la que más se ha desarrollado, también es la que más abierta hemos dejado desde el punto de vista de futuro, porque cada día se crean nuevas tecnologías, cada día obtienes nuevas aplicaciones y cada día está de moda una aplicación u otra. Mahout es una solución que se ha quedado anticuada, aunque a día de hoy sigue existiendo, de "machine learning". ScikitLearn y Weka, otras soluciones de "machine learning" en Python o en Java que se han quedado un poco obsoletas también. Soluciones Deep Learning hay cientos, las más importantes, Theano, TensorFlow, Keras, etcétera, H2O, son soluciones para ejecución de algoritmos de "deep learning" o de redes neuronales. Spark ML es la librería de Spark que me permite ejecución de "machine learning" en distribuído, y es más amplia que la de Spark MLlib, es una solución que inventaron desde los orígenes de Spark con soluciones "machine learning" procesadas, pero cuatro algoritmos procesados de manera distribuida. Si tuviéramos que recomendar una librería en este caso, nos basaríamos siempre en Spark ML. H2O es una solución que no sólo tiene la parte del "deep learning", sino otros algoritmos también distribuidos como pueda ser Random Forest. Y, por último, MADLib que es una solución que está enganchada de manera directa con Pivotal, es una solución que pudieras ejecutar analítica mediante Python, mediante Java o mediante R, dentro de la propia SQL de consulta del dato. Y bien, hasta aquí, los componentes Big Data. Como veis, no hemos pasado por 704 aplicaciones, sino sólo por las más relevantes, más importantes y más usadas hoy en día en la actualidad. Queda por esperar lo que nos viene en el futuro. No obstante, es prometedor.
