[MÚSICA] [MÚSICA] Comenzamos analizando cada uno de los componentes o aplicaciones que nos ofrecen las soluciones BigData. Para empezar, como hemos comentado anteriormente, el ecosistema Hadoop ofrece una serie de aplicaciones por defecto, soluciones como pueda ser HDFS. Existen otras aplicaciones, podemos ver en el gráfico una serie de símbolos o iconos que nos representan esas aplicaciones, como podrán ser el símbolo de la aplicación de Hive, el símbolo de la aplicación de Flume, Sqoop, etcétera. Vamos a ir a verlos de manera organizada. En primer lugar, todo lo que tiene que ver con almacenamiento de datos. Bien, tenemos el componente Hive, que nos permite almacenar los datos de manera estructurada, lo que nos permite no solo es almacenarlo de manera estructurada, sino también incluso consultar de manera estructurada, cuando digo estructurada me refiero a SQL, el tradicional lenguaje SQL CLK, asterisco, front, bla, bla. Esto es muy sencillo para gente que viene de anteriores versiones de Business Intelligence o incluso de soluciones Oracle, MySQL, etcétera, puesto que para ellos no supone un cambio desde el punto de vista de desarrollo, pero en realidad, por detrás está funcionando un sistema BigData con sistemas distribuidos, almacenamiento, replicación, etcétera. Frente a Hive, tenemos soluciones como Accumulo, una situación que también es compatible con Cloudera y con Hortonworks. Podemos observar cómo en la transparencia indico una C o una H, que lo que quiere decir es si es compatible o no es compatible, y si se da soporte o no en cada una de las dos distribuciones más importantes, cuando pone C solamente o H solamente, es que solo dan soporte en ese tipo de distribuciones. Bien, Accumulo en este caso es una solución tan potente como Hive, pero menos usada que Hive, que ofrece también acceso de una manera sencilla a los datos sin necesidad de tener muchos conocimientos en los sistemas distribuidos. Frente a Accumulo o Hive, ofrecemos soluciones no SQL, HBase es una solución no SQL que viene incluso previa a la creación de Hive, que lo que permite es almacenar los datos de una manera sencilla como clave-valor. No tiene ninguna complicación, yo almaceno con una clave un determinado valor, y ese valor puede tener la forma que queramos, un dato, una imagen, un vídeo, lo que queramos. HCatalog es básicamente un catálogo que nos permite controlar todas las bases de datos de una manera unificada. Es muy potente porque nos permite acceder de una manera muy sencilla a distintos sistemas o aplicaciones de almacenamiento de base de datos distribuidas como puede ser Hive y HBase a la vez, y HAWQ, HAWQ es una solución pivotal, de ahí viene la P, entre paréntesis, es una solución muy parecida a Hive, pero con un pequeño detalle, y es que tiene la posibilidad de poder ejecutar en memoria. Es muy parecido a lo que vamos a ver más adelante, que se llama Impala, una solución de Cloudera. También otro potencial de HAWQ en este caso, es que nos permite ejecutar código DR dentro de la propia consulta SQL, a lo cual nos permite generar incluso analítica a la vez que acceso al dato. Bien, desde el punto de vista de acceso al dato, de obtención del dato, existen distintas soluciones, HiveSQL, os podéis imaginar, que es la parte de Hive de consulta SQL, también con soporte a Cloudera y a Hortonworks. Impala es una solución de Cloudera que permite acceder optimizando la consulta, usando la memoria, hablamos de memoria individual de cada nodo, que a su vez, si se tuviera una memoria distribuida compartida, podría usarse a la vez. Bien, es una solución muy potente, y hasta hace bien poco, era la solución más óptima que existía en soluciones BigData, hasta que salió otro concepto, otra aplicación que se llama Spark. Pig es una solución basada en scripting, es acceso de manera scripting, no tiene más que una consulta muy parecida al resto de scripts de acceso a dato, si bien esos accesos se parecen mucho a la estructura de una SQL, difiere en algunos aspectos, para lo cual, si una persona no sabe ejecutar bien un script en Pig, nuestra recomendación es siempre utilizar con Pig otra aplicación que se llama Tez. ¿Qué es lo que hace Tez? Coge la consulta hecha en Pig, la analiza y la optimiza, la reorganiza, la complica y la modifica para que sea una ejecución de la más óptima posible. Podemos ver el ejemplo donde una consulta donde aparentemente sabemos cómo se hace, Tez se da cuenta de que la consulta no es óptima, la modifica, la cambia para que sea óptima y el tiempo de ejecución sea la menor posible, es una solución muy práctica cuando queremos utilizar soluciones Pig cada vez. SparkSQL. Si tenemos solución Spark, que vamos a ver más adelante, lo que nos va a permitir SparkSQL es acceder a los datos en memoria utilizando SQL, es una solución súper potente cuando queremos utilizar soluciones Spark, que veremos más adelante, y Kite es otra solución muy parecida a SQL que está todavía en incubación por parte de Apache, pero que you dan soporte tanto Cloudera como Hortonworks. A continuación, vamos a ver los componentes no SQL de almacenamiento no estructurado. Si bien you habíamos hablado de una solución que era HBase, una solución bastante antigua y más bien poco usada, existen otras soluciones bastante más orientadas a la necesidad de la ejecución o del análisis. Bien, en primer lugar, vamos a Cassandra, una solución basada en consulta por clave-valor, una solución muy rápida y muy usada hoy en día, que tiene soporte en Cloudera y en Hortonworks. Por otro lado, la solución MongoDB, que la utilizan muchas aplicaciones web, soluciones basadas en almacenamiento de datos por documentos o JSON, una solución que si bien la escalabilidad no es muy buena, en realidad MongoDB ha sido muy usado y es muy famoso. Soluciones tipo REDIS de clave-valor, donde lo más importante de REDIS es el rendimiento y la rapidez en la que se obtiene un dato. En muchas ocasiones se utiliza REDIS como base de datos tipo caché, ¿qué quiere decir eso? Para no tener que acceder continuamente a un dato que estamos accediendo, lo más fácil es coger ese dato, llevarlo a una solución tipo REDIS, y tenerlo en REDIS para que el acceso al dato sea lo más rápido posible, no tener que consultar sobre la base de datos original, que pueda ser un Hive, sino que directamente podamos consultar sobre esa REDIS y obtener unos tiempos de respuesta muy rápidos. Neo4J. Neo4J ofrece soluciones orientada en grafos. Muchas veces los datos tienen relaciones entre sí, y a mí lo que me interesa es poder navegar por esas relaciones, para eso se inventaron las bases de datos de tipo grafo. Neo4J es una de las soluciones más potentes y más adaptadas para este tipo de problemáticas. GraphX es la solución que está ofreciendo Spark para ofrecer base de datos de tipo grafos. Es una solución igual de buena que Neo4J, y encima está totalmente cogida por soluciones Apache. CouchDB es una solución bastante potente, y está ideada para tener soluciones de caché y soluciones de almacenamiento a largo tiempo. Lo bueno de CouchDB es que está pensado para dispositivos IET, ¿qué quiere decir eso? Muchas veces los dispositivos IET pierden la conectividad, y no pueden transmitir los datos a una base de datos global, para ello se instalan pequeñas instancias de bases de datos de CouchDB, que vayan almacenando los datos, y que automáticamente, sin necesidad de nada, se sincronizarán con la base de datos global cuando se tenga conectividad, y, mientras tanto, tienen un almacenamiento local que está totalmente sincronizado, you digo, cuando se vuelve a tener la conectividad. Elastic. Elastic es una solución de almacenamiento, indexación y búsqueda de datos de tipo documental, almacena los datos por palabras, indexa los datos por palabra, y lo importante en este caso es poder hacer consultas de una manera muy rápida. No solo tiene proceso de almacenamiento y consulta, sino que también tiene pequeñas aplicaciones que permiten procesar el texto, como poder hacerle matización, nombres propios, ese tipo de soluciones. Lo importante de Elastic es que no solo tiene una solución de indexación sino también tiene una solución de visualización, una que se llama Kibana, una solución de análisis de logs, que es muy potente, y que es una solución completa, que si bien no están ofreciendo Cloudera y Hortonworks de manera directa, sí que tienen conexión directa con ellos. Y Kudu, una solución totalmente nueva, está en incubación a día de hoy, una solución de Apache, que demuestra que puede ser muchísimo más rápida en almacenar y en obtener el dato que cualquiera de las otras soluciones, está por ver a día de hoy todavía porque está en incubación. [MÚSICA] [MÚSICA]
