En esta sesión vamos a hablar de Apache Impala. Vamos a hacer una pequeña introducción a cuál es su uso, y un pequeño ejemplo de por qué puede ser interesante en uno de nuestros proyectos. Apache Impala es un proyecto dentro del ecosistema de Hadoop MapReduce, y está diseñado para optimizar la latencia de las consultas. No es tanto un motor para escalar grandes consultas sobre grandes conjuntos de datos sí sobre intentar optimizar el ancho de banda de un clúster, sino más bien intenta ser un motor cuyas respuestas, la latencia de la respuesta sea muy corta. Es decir, cada pregunta que le hagamos a la base de datos, vamos a tener una respuesta en pocos segundos. Está totalmente integrada en el ecosistema Hadoop y el entorno de trabajo se realiza mediante consultas con lenguaje SQL. En ese sentido, Impala proporciona, aporta un flujo de datos diferenciado del resto del entorno que es, primero, cargar los datos en memoria y permanecen en la memoria de los servidores durante toda la fase de consulta, de forma que podamos realizar una gran parte de los análisis accediendo a memoria principal. Esto tiene un cierto impacto en los requerimientos del sistema para utilizar Impala. Lo primero es que los datos, la mayor parte del conjunto de datos sobre el cual queremos hacer consultas, tiene que estar en memoria principal. Eso, ¿qué quiere decir? Que, de entrada, necesitamos utilizar servidores de datos con un tamaño de memoria principal superior al típico, el que encontramos en los servidores MapReduce, que suelen ser sistemas sencillos de sobremesa, que no difieren mucho de los que tenemos en sobremesa. Por lo tanto, lo primero es el impacto que tiene en la memoria principal de los sistemas y, lo segundo, que aquí se relaja la tolerancia a los errores. Es decir, si tenemos una consulta de Impala que falla, esa consulta se pierde, no tenemos manera de recuperar la consulta lanzada. Por lo tanto, es necesario, o es conveniente, o se extrae el mayor rendimiento de Impala, cuando utilizamos consultas rápidas. Por lo tanto, el coste de perder una consulta o de no tener resultado es pequeño, comparado al coste que tenemos de volver a lanzar. Si estamos hablando de que estamos lanzando series de consultas de pocos segundos, el coste de perderlas supone una penalización pequeña. La arquitectura de Impala, básicamente, está dividida en tres grandes bloques o tres grandes elementos. El primero son los "daemon", los procesos de servicio que están vivos en cada uno de los nodos del "cluster" y que permiten transferir las consultas a cada servidor. Luego tenemos un componente que gestiona la salud de estos servidores, que es el "statestore", y luego, un servicio de un catálogo que permite gestionar las consultas y los cambios de las consultas SQL a cada uno de los nodos del "cluster". El entorno de programación también está basado en procesos de servicio que se están ejecutando siempre, con lo cual minimizamos el tiempo de arranque de Impala en nuestros servidores, pero la penalización es que consume memoria durante todo el tiempo en que Impala se está utilizando y, aun incluso no lo estemos utilizando, necesitamos reservar recursos de memoria para estos servicios. Otra ventaja que tiene Impala es que tiene un motor de consultas propio optimizado en lenguaje C++ y también, que utilizamos el compilador LLVM para optimizar, tanto las consultas como los procesos de servicio, con lo cual tenemos un rendimiento superior al de otros entornos de trabajo. Como ejemplo, proponemos un pequeño o una pequeña típica consulta de SQL donde seleccionamos un par de atributos, donde estamos trabajando con dos tablas que se fusionan, se hace un "join" de dos tablas, y estamos eligiendo aquellos elementos que tengan un identificador en común en los atributos comunes en dos tablas. Es interesante este ejemplo puesto que nos permite ver cómo una consulta tan sencilla como esa está optimizada dentro de Impala. Y para eso vamos a hablar de la operación "Broadcast join" que permite mejorar el rendimiento cuando tenemos que hacer un "merge", una unión entre dos conjuntos de datos. Impala toma primero el conjunto de menor tamaño y crea una estructura en memoria principal de cada uno de los nodos con esa estructura, una copia completa de esa información en forma de tabla "hash". En el siguiente paso es que cada "daemon" de cada servicio, cada proceso de servicio de Impala, lee de forma secuencial de los datos locales de cada servidor de HDFS que hay por debajo, y los va comparando con la memoria, con la estructura que tiene en memoria principal de forma que sólo evalúa aquellos datos, aquellos atributos que hayan coincidido con la versión previa en memoria principal. Ahora vamos a ver un ejemplo de cómo funciona internamente esa consulta. Primero, teníamos dos tablas, estamos interesados en dos atributos y aquí el "join" se hace entre una tabla gigante y una tabla mini, una tabla con un tamaño mucho más pequeño. Impala está encargada de analizar cuál de las dos es el conjunto de datos más pequeño y, automáticamente, el motor es el que se encarga de crear esa estructura en memoria. Por lo tanto, ese filtrado se realiza el tiempo de ejecución y no es hasta entonces cuando Impala conoce los datos, su tamaño y sus características para decidir cuál de los dos va a optimizar. Por lo tanto, la tabla que tiene menos valores de identificación distintos es la que se guarda en memoria, y la otra es la que está, por ejemplo, esta pequeña es la que se crea en la tabla "hash" en memoria principal donde se almacenan estos valores. La otra tabla, la tabla más gigante, lo que se hace es ir leyendo bloque en bloque desde HDFS local y se va procesando contra la tabla en memoria, la tabla "hash". De forma que sólo aquellos identificadores que coincidan, que hagan un "match" en estas tabla "hash" serán procesados analizando el resto de los atributos. De esa forma, aquellos datos que no aparezcan en la tabla mayor, simplemente serán filtrados, no serán procesados. Como conclusiones, tenemos que saber cuándo usar Impala, en qué contextos de proyectos Impala nos va a ayudar, nos va a favorecer el trabajo. Lo primero que tenemos que decir es que aquellos proyectos donde las consultas en NSQL, nos importe mucho la latencia de estas consultas, debemos pensar si Impala y sus características son apropiadas para nuestro proyecto puesto que es la mejor herramienta para reducir esa latencia y está orientada a ese buen rendimiento. El segundo caso es un sistema que tenga capacidad, necesitamos que se realicen muchas consultas de forma concurrente, es decir, muchas consultas pequeñas en tiempo corto pero que tenemos un gran número a realizar en un determinado tiempo. Si tenemos ese tipo de requerimientos, Impala puede ser una herramienta que nos puede favorecer. Otro ejemplo, para finalizar, es el caso de que estemos trabajando en un entorno con múltiples usuarios que quieren acceder al mismo repositorio de datos para realizar pequeñas consultas que todas ellas deben realizarse de forma concurrente. En ese caso, Impala también es una buena herramienta puesto que va a permitir ese análisis utilizando los datos que están almacenados en memoria.
