GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Azure Data Lake


Como parte de la Solución de Big Data ofrecida por Microsoft en Azure, tenemos Azure Data Lake Store (como solución de almacenamiento infinito, cifrado, compatible con HDFS, e integrado en Azure AD) y Azure Data Lake Analytics (como solución de procesamiento masivo en paralelo), dos soluciones ofrecidas en formato Software as a Service (SaaS), que gracias a la potencia y riqueza del Lenguaje U-SQL (incluyendo su integración con C#, la utilización de los catálogos U-SQL de Analytics, y su integración con Visual Studio), nos permitirán realizar cualquier cosa que nos propongamos, de una forma rápida y sencilla. Hay producto.

Antes de comenzar con este artículo, quería comentar que se trata de un resumen de lo que he aprendido en las últimas semanas sobre Azure Data Lake Storage, Azure Data Lake Analytic, y el lenguaje U-SQL. Un esfuerzo que he realizado principalmente gracias al curso gratuito de EDX DAT223.1x - Processing Big Data with Azure Data Lake Analytics. Así que, si te parece interesante, aprovecha y registrarte en dicho curso. El curso está genial, está formado principalmente por videos y ejercicios de laboratorio, y va bastante al grano (se hace bastante rápido). Un recurso de gran ayuda, y muy muy recomendable. Dicho esto, comenzamos.

Azure Data Lake Store

Azure Data Lake Store es un proveedor de almacenamiento, algo similar a una Cuenta de Almacenamiento (Storage Account) de Azure, que nos ofrece un almacenamiento cifrado práticamente infinito, donde almacenar billones de archivos, y donde un sólo archivo puede tener un tamaño superior a un petabyte. Además, se integra con Azure AD para la autenticación y control de acceso.

Azure Data Lake Store es un sistema de archivos de Apache Hadoop compatible con HDFS (Hadoop Distributed File System), que podemos utilizar directamente desde Azure Data Lake Analytics, y también desde Hadoop (disponible con el clúster de HDInsight) mediante las API de REST compatibles con WebHDFS.

Todo almacenamiento de Azure Data Lake Store se identifica con una dirección (URI) como la siguiente, que definiremos durante el aprovisionamiento del mismo: adl://guillesql.azuredatalakestore.net

Azure Data Lake Analytics

Azure Data Lake Analytics ofrece una infrastructura para el procesamiento de trabajos (Jobs) en paralelo bajo demanda, escalable y de alto rendimiento, en modalidad de pago por uso (Software as a Service), que nos permitirá (entre otras cosas) explotar la información almacenada en nuestro Azure Data Lake Store utilizando Jobs U-SQL.

Aunque Azure Data Lake Analytics está especialmente optimizado para trabajar con Azure Data Lake, también puede funcionar con Azure Blob Storage y Azure SQL Database.

Todo esto está muy bien, pero para realmente poder entender qué nos permite hacer, tenemos que conocer U-SQL, ya no sólo el lenguaje en sí y su integración con C# (que eleva su potencia al máximo exponente), sino también los Catálogos U-SQL, que nos permitirán crear tablas, vistas, funciones, etc., directamente en Analytics, incluso tablas vinculadas a tablas de Azure SQL Database. Vamos a comentarlo.

El Lenguaje U-SQL

U-SQL es un lenguaje sencillo con una sintaxis muy parecida al T-SQL de SQL Server, que permite escribir código (Trabajos o Jobs que ejecutaremos habitualmente dentro de Data Lake Analytics) y paralelizarlo automáticamente a la escala que necesitemos. Esta es una de sus principales ventajas, ya que hay un gran público que ya conoce el T-SQL y esto lo hace muy accesible. No obstante, U-SQL incluye varias diferencias con T-SQL, como ser susceptible de mayúsculas y minúscula (case sensitive), la posibilidad de utilizar directamente algunas características del C# (ej: tipos de datos, operadores de comparación, etc.), y el uso de Extractores para leer información de orígenes de datos como ficheros de texto.

En el siguiente pantallazo, vemos el ejemplo de un Job U-SQL, capaz de leer un conjunto de ficheros almacenados en una carpeta de Azure Data Lake Store, procesar su contenido generando una información agregada, que finalmente escribe en un fichero CSV sobre otra carpeta de Azure Data Lake Store.

Otro detalle, es que podemos escribir y ejecutar nuestros Jobs de U-SQL tanto desde el Azure Portal como desde Visual Studio (ej: usando la plantilla de proyecto de Visual Studio DataLake). En este sentido, una ventaja que nos ofrece Visual Studio es poder ejecutar código U-SQL en local (sin Azure), lo cual puede ser de gran utilidad para aprendizaje, depurar código, etc., aunque con Visual Studio también podemos ejecutar código U-SQL directamente en Azure. Ah, y recuerda, que Visual Studio 2017 Community es gratis (bueno, bajo ciertas condiciones de uso).

U-SQL Catalogs

Dentro de Azure Data Lake Analytics podemos crear bases de datos y todo tipo de objetos como esquemas, tablas, vistas, table valued function (TVF, algo así como vistas parametrizadas), procedures, etc, de forma similar a como haríamos en SQL Server, pero utilizando código U-SQL que podemos ejecutar directamente desde un Job de Analytics. De hecho, Analytics se entrega de serie con una base de datos, la master, pero podemos crearnos nuevas bases de datos y personalizarlas conforme a nuestras necesidades.

Podemos incluso crear tablas vinculadas o externas, es decir, tablas que no existen realmente en Analytics, pero a las que accedemos como si lo fueran, siendo realmente referencias a tablas que existen realmente Azure SQL Database, Azure SQL Data Warehouse, o en un SQL Server. Un poco el concepto tradicional de Linked Servers en SQL Server.

El siguiente pantallazo del Data Explorer de Analytics, quizás nos ayude a ver todo esto de una forma más fácil y gráfica. A modo de ejemplo, la tabla dbo.BuildVersion_local es una tabla externa (CREATE EXTERNAL TABLE) que referencia a una tabla dbo.BuildVersion existente en una base de datos de Azure SQL Database, mientras que la tabla iis.log es una tabla creada directamente en Analytics (CREATE TABLE).

C# y U-SQL: Inline, Code Behind, y Assemblies

U-SQL utiliza directamente al lenguaje C#. Los tipos de datos que vamos a utilizar son los de C# (por ejemplo cuando creamos tablas dentro de nuestros catálogos de U-SQL), lo cual tiene sus implicaciones. De este modo, cuando realizamos una consulta U-SQL podemos utilizar las funciones/métodos nativos de dichos tipos de datos, como sería el caso de ToLower() para pasar un String a minúsculas, pero además también podemos invocar directamente a funciones nativas de C#. Ambos casos los podemos ver en el siguiente pantallazo a modo de ejemplo. Esta técnica se denomina inline, y es la forma más sencilla que tenemos de utilizar código C# dentro de un Script U-SQL.

¿Y si necesitamos algo más complicado (implementar y utilizar nuestras propias funciones)? Entonces podemos crear nuestro propio código, para invocarlo directamente de U-SQL, algo que podemos conseguir utilizando dos técnicas: Code Behind y Assemblies.

Si utilizamos Visual Studio para escribir nuestro Script U-SQL, podemos utilizar el fichero de Code Behind (como se hacía antaño, por ejemplo, con las páginas aspx), con su namespace, clases y funciones. De este modo, podríamos crear una clase estática con una función estática que poder utilizar directamente desde nuestro Script U-SQL. Esto por debajo, creará una DLL que desplegará como un Assembly temporal que se eliminará al finalizar la ejecución del Script/Job U-SQL. Sin embargo, todo esto se realizará de forma transparente para nosotros, facilitándonos bastante las cosas. El inconveniente de esta técnica, es que el código C# que hemos escrito, sólo está disponible para el Script U-SQL específico que estábamos escribiendo, es decir, no sería reutilizable por otros Scripts U-SQL.

Si necesitamos crear código C# que podamos utilizar desde diferentes Scripts U-SQL, o incluso desde Procedures, Funciones, etc., de nuestros catálogos U-SQL, podemos crear Assemblies con Visual Studio y registrarlos en una base de datos de nuestro catálogo U-SQL, para de este modo poder utilizarlos una y otra vez incluso desde diferentes orígenes. En este caso, utilizaríamos un Proyecto de tipo Class Library (For U-SQL Application). Una vez registrado nuestro Assembly en nuestro catálogo U-SQL, podemos cerrar Visual Studio, y ejecutar Scripts U-SQL utilizando nuestras nuevas funciones que acabamos de desplegar, como si fueran una más (bueno, casi, tendremos que utilizar REFERENCE ASSEMBLY para referenciar el Assembly que deseamos utilizar antes de invocar cualquier de sus clases, pero por lo demás, no tiene mayor misterio).

Arquitectura de los Job U-SQL

Cuando ejecutamos un Job U-SQL, Azure Data Lake Analytics necesita reservar (allocate) una o más Unidades de Procesamiento (conceptualmente es como si fueran los Nodos o Servidores de un Cluster, aunque no es exactamente así), algo que elegiremos al ejecutar nuestro Job U-SQL, y en función de su valor, tendremos una mayor (o menor) capacidad de procesamiento así como también se repercutirá un mayor (o menor) coste. El hecho de utilizar múltiples Unidades de Procesamiento, no sólo nos aportará una mayor capacidad de proceso, sino que además nos permitirá la paralelización en la ejecución de nuestro trabajo.

Analytics dividirá el Job en diferentes Fases, cada una de las cuales estará formada por diferentes Vértices,  los cuales no son más que unidades de trabajo que se ejecutarán en las Unidades de Procesamiento que tengamos reservadas para la ejecución de nuestro Job U-SQL.

En el siguiente pantallazo podemos ver el log de ejecución de un sencillo Job U-SQL, que incluye dos fases, una con 2 vértices y la otra con sólo 1. En este caso, no tendría sentido utilizar múltiples Unidades de Procesamiento. Otra cosa sería, si tuviésemos más fases, con muchos más vértices, lo que nos permitiría paralelizar y minimizar el tiempo de ejecución, eso sí, aumentando el coste (recordemos: pago por uso).

No obstante, al ejecutar nuestros Scripts U-SQL desde Visual Studio, nos será un poco más fácil poder detectar si estamos sobredimensionando su ejecución (es decir, utilizando más Unidades de Procesamiento de las que podemos aprovechar) utilizando la pestaña Diagnostics, tal y como se muestra en la siguiente pantalla (en este caso, tenemos 4 Unidades de Procesamiento que no estamos utilizando, por lo que en cierto modo estamos tirando dinero). Aquí tendremos que jugar un poco, para encontrar el equilibrio perfecto entre rendimiento y coste, para cada Script U-SQL.

Si hacemos click en el enlace que pone 4 AU(s), accederemos a otro diálogo, donde encontraremos el Modelador de uso de AU (AU Usage Modeler), que nos será una herramienta de gran utilidad para analizar en qué medida estamos despilfarrando costes y recursos, y así poder dimensionar mejor las Unidades de Procesamiento de nuestro Script U-SQL.

Hasta aquí llega este artículo, en el cual he intentado resumir un poco las principales características y posibilidades de Azure Data Lake Storage, Azure Data Lake Analytis, y del lenguaje U-SQL. A mi personalmente, me ha encantado conocerlo, y he disfrutado como un enano pudiendo probarlo lo poco que he podido hasta el momento. Espero poder meterle mucha más mano en los próximos meses.

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.

 


[Fecha del Artículo (UTC): 05/02/2018]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Febrero de 2018 (6)
Enero de 2018 (1)
Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas