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:

SELECTTOP5_thumb_4A26C91E

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í:

SELECTTOP52_thumb_4A26C91E

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…

 

Eladio Rincón

Eladio Rincón is professionally focused on SQL Server databases. He is an MVP on SQL Server since 2003, and his area of expertise is resolution of performance and scalability issues for OLTP based systems. His professional career revolves on SQL Server mentoring, consulting, and training projects. He believes that mixing training and mentoring projects is the best approach to help the clients to get the most from SQL Server. With other mentors of SolidQ he has developed a tuning methodology applied in most of the SQL Server consulting projects.