Hive es un datawarehouse que ayuda a acceder (leer, escribir y borrar) a información almacenada en Hadoop. Hadoop utiliza como sistema de almacenamiento HDFS. En el caso concreto de HDInsight, Microsoft ha reemplazado el almacenamiento HDFS por almacenamiento Windows Azure Blob Storage (WASB). En esta publicación, hemos visto de forma cómo reemplaza HDInsight el almacenamiento de HDFS por WASB.  Una de las “quejas” que suele tener la comunidad de Hadoop respecto al almacenamiento HDFS es la complejidad de su administración. Viendo la filosofía que propone Microsoft en Azure con la virtualización del almacenamiento, es muy práctico delegar en Microsoft para la gestión eficiente del almacenamiento. Considera que en tus proyectos de Big-Data, el almacenamiento será una ubicación donde se irán colocando los archivos objeto de análisis. Más información sobre los razonamientos de Microsoft al respecto lo puedes encontrar aquí.

En esta publicación vamos a realizar lo siguiente:

  • Cargaremos un archivo de datos (no muy grande) en nuestro Cluster de HDInsight en Azure. En nuestro caso es un archivo de registro de visitas a IIS; la información es aleatoria generada con herramientas ad-hoc para ello.
  • Estudiaremos el formato del archivo para encontrar un patron/modelo/estructura para los datos almacenados.
  • Con ese patrón crearemos una tabla en Hive para consultar los datos.
  • Comprobaremos que podemos consultar los datos.
  • Ejecutaremos algunas consultas HiveQL sobre la tabla y veremos qué relación tiene con Map&Reduce.

Carga de datos a WASB

Para subir archivos a Hadoop, hay diferentes métodos: utilizar PowerShell y sus cmd-lets, utilizar la API de .NET y Hadop, o utilizar las instrucciones de línea de comando de Hadoop. Para este caso, vamos a ver cómo se sube un archivo con los cmd-lets de PowerShell. Necesitas conocer la siguiente información:

  • Nombre de la subscripción de Azure
  • StorageAccount en Azure
  • Nombre del contenedor donde se almacenará el archivo
  • la Key de la cuenta
  • Los archivos que deseas subir
  • El “directorio” destino donde quieres subirlo

El siguiente Script de Powershell te servirá:

$subscriptionName = "<CUENTA>"
$storageAccountName = "<CUENTA_STORAGE>"
$containerName = "<CONTENEDOR>"
$storageaccountkey = "KEY MUY LARGA"
$path = "C:SampleW3CGenerated"
$destinationPath="w3c/"

$pathOriginal = [System.IO.Directory]::GetCurrentDirectory()

# Create the storage context object
$destContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $storageaccountkey

cd $path
$archivos= get-childitem $path | select Name
foreach ($s in $archivos)
{
    $destinationFile = $destinationPath + $s.Name
    Write-Output ("Uploading file: " + $destinationFile + " ...")
    Set-AzureStorageBlobContent -File $s.Name -Container $containerName -Blob $destinationFile -context $destContext
}
cd $pathOriginal

 

y te aparecerá algo como lo siguiente:

SubidaArchivosPS_thumb_1_7D2887E5

al finalizar el proceso podrás comprobar si los archivos están, con herramientas como Azure Explorer, con scripts de PowerShell o con las herramientas de línea de comando de Hadoop:

hadoopdfsls_thumb_1_7D2887E5

donde puedes comprobar que en el directorio w3c tenemos los 10 archivos subidos.

Conociendo el formato del archivo

Si piensas en aplicaciones con información estructurada, seguramente este punto piensas que debería ir antes de la carga de los datos. La filosofía que se suele seguir en estos procesos de Big-Data donde la estructura de la información puede ser muy diversa, primero se suele cargar el dato, y luego se busca/analiza la estructura de la información para poder consultarla. Más adelante veremos como hay casos en los que antes de cargar la información te encargas de definir su modelo cuasi-estructurado, por lo que el análisis de la estructura de los datos bien podrá hacerse antes o después de cargar los datos.

Abriendo uno de los archivos, podemos ver que tiene 3 lineas de cabecera, y el resto de líneas registros de log de IIS 6.

La cuarta línea representa el nombre de las columnas de lo que sería una “tabla”.

El resto de líneas son datos.

#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2013-05-03 17:05:50
#Fields: date time 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(User-Agent) cs(Referrer)
2013-05-03 17:05:50 192.168.1.42 - 192.168.1.1 80 POST /UserService - 200 287357 18913 9554 Mozilla/5.0+(Windows;+U;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) -
2013-05-03 17:05:50 192.168.1.42 - 192.168.1.1 80 GET /Default.aspx - 200 51930 1961 6583 Mozilla/5.0+(Windows;+U;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) -

En estos momentos debemos tomar una decisión: Qué hacer con esas 4 primeras líneas! En algún momento tendrán que desaparecer porque no son datos; es información de metadata. En mi caso concreto, he decidido eliminar esas líneas de los archivos, porque generan “suciedad” de cara al análisis puro de datos. Otra opción es dejarlos como están y hacer transformación/limpieza de esos datos desde Hive como veremos en otra publicación.

Creación de tabla externa

Conocido el esquema, utilizaremos la siguiente instrucción para crear la tabla:

CREATE EXTERNAL TABLE datos (
 logdate_ string,
 logtime string,
 c_ip string,
 cs_username string,
 s_ip string,
 s_port string,
 cs_method string,
 cs_uri_stem string,
 cs_uri_query string,
 sc_status int,
 sc_bytes int,
 cs_bytes int,
 time_taken int,
 cs_agent string, 
 cs_Referrer string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
LOCATION '/w3c';

En este caso decidimos crear una tabla EXTERNA porque es el mecanismo que hemos decidido para interpretar los datos de Hadoop desde Hive. Más adelante veremos algunas diferencias con tablas REALES.

Se utiliza la palabra clave ROW FORMAT para especificar cual es el carácter de “salto de campo”; analizando el archivo origen, hemos visto que entre cada columna había un espacio en blanco.

Por defecto, Hive interpreta que el salto de fila (row) es el retorno de carro. La versión de Microsoft de momento no soporta tener otros saltos de row diferentes, aunque Apache Hadoop permite implementar esa granularidad a nivel por ejemplo de archivo completo. Puede parecer una limitación, pero no lo es tanto considerando que se puede utilizar serialización/deserialización de objetos con JSON o AVRO.

Para crear la tabla, desde Hive ejecutaremos el código anterior:

createexternaltablehive_thumb_2A777E2D

 

y podemos ejecutar la instrucción DESC de DESCRIBE para obtener lo siguiente:

hive> desc datos;
OK
logdate_                string                  None
logtime                 string                  None
c_ip                    string                  None
cs_username             string                  None
s_ip                    string                  None
s_port                  string                  None
cs_method               string                  None
cs_uri_stem             string                  None
cs_uri_query            string                  None
sc_status               int                     None
sc_bytes                int                     None
cs_bytes                int                     None
time_taken              int                     None
cs_agent                string                  None
cs_referrer             string                  None
Time taken: 0.473 seconds, Fetched: 15 row(s)

También se puede utilizar la instrucción DESC FORMATTED <NOMBRE_TABLA> para tener información más detallada de la tabla:

hive> desc formatted datos;
OK
# col_name              data_type               comment

logdate_                string                  None
logtime                 string                  None
c_ip                    string                  None
cs_username             string                  None
s_ip                    string                  None
s_port                  string                  None
cs_method               string                  None
cs_uri_stem             string                  None
cs_uri_query            string                  None
sc_status               int                     None
sc_bytes                int                     None
cs_bytes                int                     None
time_taken              int                     None
cs_agent                string                  None
cs_referrer             string                  None

# Detailed Table Information
Database:               visitas_web
Owner:                  sqlremoto
CreateTime:             Wed Oct 30 17:34:09 GMT 2013
LastAccessTime:         UNKNOWN
Protect Mode:           None
Retention:              0
Location:               wasb://<storage>@<contenedor>.blob.core.windows.net/w3c
Table Type:             EXTERNAL_TABLE
Table Parameters:
        EXTERNAL                TRUE
        transient_lastDdlTime   1383154449

# Storage Information
SerDe Library:          org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
InputFormat:            org.apache.hadoop.mapred.TextInputFormat
OutputFormat:           org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
Compressed:             No
Num Buckets:            -1
Bucket Columns:         []
Sort Columns:           []
Storage Desc Params:
        field.delim
        serialization.format
Time taken: 0.536 seconds, Fetched: 42 row(s)

 

Trabajar con tablas externas es muy cómodo porque los datos estarán disponibles tan pronto como “suba” el archivo al “repositorio” de WASB. Por otra parte, si quieres borrar la tabla – EXTERNApuedes borrarla sin miedo a que los archivos se borren. Esto es diferente a las tablas normales! Más adelante veremos implicaciones con los tipos de datos, conversiones, etc.

 

Referencias

Ref1: http://www.windowsazure.com/en-us/manage/services/hdinsight/howto-blob-store/?fb=es-es

Ref2: http://msdn.microsoft.com/en-us/library/jj152841.aspx

Ref3: http://www.windowsazure.com/en-us/manage/services/hdinsight/howto-upload-data-to-hdinsight/?fb=es-es#commandline

Ref4: https://connect.microsoft.com/BusinessPlatform/Feedback

Ref5: https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL

 

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.