En publicaciones anteriores hemos creado la BBDD de Hive para almacenar datos, y hemos cargado datos en HDInsight (HDI) además de crear la tabla externa que hace referencia a los archivos cargados.Recapitulando información de la Introducción a Hive, debemos recordar que el objetivo que se persigue con Hive es:
- Utilizar un lenguaje parecido al SQL tradicional (HiveSQ).
- Mediante este lenguaje ejecutar trabajos Map&Reduce sobre el data almacenado.
A continuación vamos a ejecutar consultas con la herramienta de línea de comando y analizaremos el comportamiento.
Consulta simple: SELECT * FROM <tabla> vs SELECT <columnas> FROM <tabla>
Antes de ejecutar la consulta debería refrescar los conceptos básicos de MapReduce. Cuando Hive recibe una petición HiveQL, esta petición la convierte en una aplicación M&R; desde este punto de vista, la orquestación de M&R es transparente para el desarrollador de consultas HiveQL. Para contextualizar este post, haremos consultas contra la tabla w3c ubicada en la base de datos w3c. El esquema de la tabla es el siguiente:
hive> desc w3c;
logdate string from deserializer
logtime string from deserializer
c_ip string from deserializer
cs_username string from deserializer
s_ip string from deserializer
s_port string from deserializer
cs_method string from deserializer
cs_uri_stem string from deserializer
cs_uri_query string from deserializer
sc_status int from deserializer
sc_bytes int from deserializer
cs_bytes int from deserializer
time_taken int from deserializer
cs_agent string from deserializer
cs_referrer string from deserializer
p_logdate string None
# Partition Information
p_logdate string None
Si has trabajado con logs de IIS te resultará familiar el esquema; los datos de esta tabla proceden de datos de IIS y resultan auto-descriptivos los nombres como logdate, logtime, s_ip, cs_usri_query, etc.
No le de importancia a la parte “from deserializer” porque trataremos el tema en otras publicaciones.
En primer lugar ejecutaremos un SELECT * sobre la tabla pero limitando el conjunto de fijas a devolver con la clausula LIMIT n:
SELECT * FROM w3c LIMIT 5;
Obteniendo el siguiente resultado:
Si tienes algo de experiencia con M&R y has ejecutado consultas HiveQL anteriormente, te llamará la atención que no aparece nada relacionado con M&R.
Ejecutemos la siguiente consulta:
SELECT logdate, logtime, c_ip ,cs_username, s_ip, s_port, cs_method, cs_uri_stem, cs_uri_query, sc_status, sc_bytes, cs_bytes, time_taken, cs_agent, cs_referrer, p_logdate FROM w3c LIMIT 5;
Comprobarás que se lanza un trabajo de M&R parecido a como se muestra aquí:
Pensemos un poco en qué hace el motor de HiveQL. Le pedimos una lista de columnas concretas, que requieren de un trabajo MAP que lea el contenido de los archivos asociados a la tabla, para devolver las 5 primeras filas que encuentre; de esas 5 primeras filas que encuentre tendrá que devolver las columnas especificadas en la SELECT. Comparando esta consulta con la anterior, sintácticamente representan lo mismo; sin embargo la primera consulta es mucho más rápida porque no necesita ejecutar el proceso MAP. Podríamos decir que estamos ante un caso en que el SELECT * es más eficiente que solicitar los nombre de TODAS las columnas de la tabla 🙂 No saques fuera de contexto la frase anterior, porque en la práctica no será un caso habitual. Casi siempre se necesitará de un proceso MAP…
