Hace algunas semanas tuve la oportunidad de participar en la creación de un curso sobre Modern DataWarehouse con Azure, y de esta forma pude trastear un poco con tecnologías con las que no trabajo a diario. En concreto estuve jugando un poco con Event Hubs y Stream Analytics, y en esta entrada intentaré contar un poco mi experiencia. Cabe destacar que se trata de una visita guiada por los servicios, y que no entro en detalles de optimización, costes y demás. De todas formas os dejaré enlaces a otros posts de compañeros que tratan cuestiones más avanzadas a mayor detalle, por lo que creo que este post puede ser un buen punto de partida.
El escenario es el siguiente:
- Script de PowerShell para simular eventos en tiempo real: Simularemos un sensor de temperatura que envía el valor cada N segundos a través de un POST a Event Hub.
- Event Hub Namespace y Event Hub: El script en PowerShell realizará el POST contra un Event Hub que declararemos en el portal de Azure.
- Stream Analytics: Con un job de Stream Analytics escucharemos los eventos que estén encolados en nuestro Event Hub (Input). En este punto veremos algunas de las opciones de salidas (Outputs) en las que podremos escribir la información obtenida en tiempo real y transformada (o no) en la Query escrita en en el job.
Enviando eventos desde PowerShell
El script no es otra cosa que un bucle infinito que simula un supuesto dispositivo, genera valores de temperatura de forma aleatoria y los envía (muy original, ¿eh?). El como enviar estos mensajes lo podéis comprobar en MDSN en la documentación de la API REST de Event Hub. Básicamente generamos un SAS Token (shared access signature) y hacemos POST en bucle con el cuerpo del mensaje.
# Load the System.Web assembly to enable UrlEncode
[Reflection.Assembly]::LoadFile( `
'C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\System.Web.dll')`
| out-null
$method = "POST"
$URI = "https://YoutEventHubNamespace.servicebus.windows.net/youreventhub/messages"
$encodedURI = [System.Web.HttpUtility]::UrlEncode($URI)
$keyname = "name_of_your_policy"
$key = "key_generated_on_your_policy"
$startDate = [datetime]”01/01/1970 00:00”
$hour = New-TimeSpan -Hours 1
# Calculate expiry value one hour ahead
$sinceEpoch = NEW-TIMESPAN –Start $startDate –End ((Get-Date) + $hour)
$expiry = [Math]::Floor([decimal]($sinceEpoch.TotalSeconds + 3600))
# Create the signature
$stringToSign = $encodedURI + "`n" + $expiry
$hmacsha = New-Object System.Security.Cryptography.HMACSHA256
$hmacsha.key = [Text.Encoding]::ASCII.GetBytes($key)
$signature = $hmacsha.ComputeHash([Text.Encoding]::ASCII.GetBytes($stringToSign))
$signature = [System.Web.HttpUtility]::UrlEncode([Convert]::ToBase64String($signature))
# API headers
$headers = @{
"Authorization"="SharedAccessSignature sr=" + $encodedURI + "&sig=" + $signature + "&se=" + $expiry + "&skn=" + $keyname;
"Content-Type"="application/atom+xml;type=entry;charset=utf-8";
"Content-Length" = "132"
}
while (1 -eq 1)
{
$temperature = Get-Random -Minimum 25 -Maximum 49
$date = Get-Date -Format "yyyy/MM/dd"
$timeH = Get-Date -Format "HH"
$timeM = Get-Date -Format "mm"
$timeS = Get-Date -Format "ss"
# create Request Body
$body = "{'DeviceId':'dev-02', 'Temperature':" + $temperature + ", 'Date':'" +$date + "' , 'Hour':'" + $timeH +"' , 'Minute':'" + $timeM+"' , 'Second':'" + $timeS + "' , 'MinT' : 15, 'MaxT': 50}"
$body
# execute the Azure REST API
Invoke-RestMethod -Uri $URI -Method $method -Headers $headers -Body $body
Start-Sleep -s 5
}
Creando Event Hubs Namespace y Event Hub
Event Hubs es un servicio de ingesta de datos en tiempo real totalmente administrado, de fácil puesta en marcha, confiable y escalable. Permite hacer streaming de millones de eventos por segundo desde multitud de orígenes para crear pipelines de datos dinámicos.
Desde el portal de Azure creamos un grupo de recursos (o utilizamos el que tengamos), y dentro de este, un Event Hub Namespace.
Dentro del Namespace creamos una instancia de Event Hub. Estamos usando Basic como Pricing Tier, por lo tanto no podemos configurar la opción de Message Retention. Partition Count lo mantenemos al mínimo posible de dos, ya que a efectos de este experimento no precisamos más. Podrás encontrar más información sobre particiones en este enlace, pero básicamente el número de particiones en un event hub se relaciona directamente con el número de consumidores concurrentes que se espera tener.
Dentro de la instancia de Event Hub debemos crear una Shared Access Policy. Cada namesapce de Event Hubs y cada instancia de Event Hubs tiene una política de autorización de acceso compartido compuesta de reglas. La política en el nivel del namespace se aplica a todas las entidades dentro de este, independientemente de su configuración de política individual. Para cada regla de política de autorización, se deben configurar tres cosas: nombre, scope y derechos. El nombre es un nombre único en ese ámbito. El scope es el URI del recurso en cuestión. Para un namespace de Event Hubs, el ámbito es el nombre de dominio completo (FQDN), de la forma https: // <yournamespace> .servicebus.windows.net /.
Los derechos provistos por la regla de política pueden ser una combinación de:
Send: otorga el derecho de enviar mensajes a la entidad.
Listen: otorga el derecho de escuchar o recibir a la entidad.
Manage: otorga el derecho de administrar la topología del namespace, incluida la creación y eliminación de entidades.
Con lo anterior, y adaptando el script en Powershell con nuestros valores (URI, keyname y key), estamos en condiciones de enviar eventos y poder comprobar como efectivamente están siendo escuchados, y encolados en nuestro event hub. Si se está siguiendo este ejemplo puede comprobarse en la monitorización o en la opción Process Data, en donde podremos realizar queries en algo parecido a T-SQL. Entraremos en esto mas adelante con Stream Analytics.
Creando un Job de Stream Analytics desde el portal de Azure
En nuestro grupo de recursos creamos un job de stream analytics, dejamos streaming units al mínimo, tal y como viene por defecto. Las streaming units (SUs) representan los recursos que se asignan para ejecutar un job de Stream Analytics. Cuanto mayor sea el número de SUs, más recursos de CPU y memoria se asignan para dicho job. Esta capacidad nos permite centrarnos en la lógica de la consulta y abstrae la necesidad de administrar el hardware. En este sentido os dejo enlace al post sobre escalado y particionamiento de Carmina Bernabeu.
A la hora de crear un job de ASA debemos definir tres cosas, Input, Query y Output. Tal y como sugieren las palabras en ingles, hablamos de una entrada de datos, una query que producirá un subconjunto de los datos de entrada, agregados o no, y una salida como resultado de la query. Veamos las tres partes.
A fecha de hoy tenemos tres opciones para la entrada, Event Hub, IoT Hub o Blob storage. Vamos a utilizar el Event Hub que definimos anteriormente, completando los datos de la suscripción, namespace, event hub y policy a utilizar. También debemos indicar el formato, mantenemos JSON (puede comprobarse en el cuerpo del mensaje que estamos enviando desde Powershell). La única codificación posible a día de hoy es UTF-8, y por ultimo debemos indicar si el stream viene comprimido (Gzip o deflate) o no.
Ahora veamos el Output. Tenemos varias opciones, en mi caso he podido probar Blob Storage y Power BI. En el caso de Blob Storage hice una prueba rápida en la que volcaba los streams en un JSON en una cuenta de almacenamiento creada previamente, pero me pareció mas vistoso usar PBI para visualizar los datos en tiempo real, y también como algo complementario al post de mi compañero Chema Pérez.
Debemos contar con una cuenta de Power BI y deberemos autorizar la conexión entre Azure y PBI, nos pedirá iniciar sesión en el servicio.
Debemos configurar nombre del dataset, tabla y seleccionar la forma de autentificación. Respecto a Power BI, indicar el workspace en el que queremos que este disponible el dataset.
Con una entrada y una salida definidas podemos trabajar sobre la query. Básicamente lo que veremos en la siguiente imagen es un SELECT * INTO, donde la tabla sobre la que se hace la select es nuestro Input y la tabla en la que se escribe es nuestro output. En este editor podremos probar la query siempre y cuando existan datos en el Input, por ejemplo, en el momento de realizar la captura que se ve a continuación, no existen datos en mi event hub puesto que no ejecuto el script de Powershell desde hace más tiempo que el máximo tiempo de retención de mensajes del event hub, por lo tanto no podríamos previsualizar el resultado.
Para ampliar en la composición de queries en Stream Analytics echa un vistazo a la referencia de Microsoft y en concreto a las funciones de ventana que son de especial utilidad para trabajar con datos en tiempo real. También te recomiendo que eches un vistazo a la serie de entradas de Carmina Bernabeu.
Visualizando los datos en tiempo real en Power BI
Tenemos nuestro Event Hub listo para encolar mensajes, un job de Stream Analytics escuchando lo que pasa en el event hub y redireccionandolo a un output en forma de dataset de Power BI. Es hora de conectarnos al portal de Power BI y explotar el dataset en cuestión. Entramos al portal de Power BI y al Workspace seleccionado cuando creamos el output de ASA, aquí podremos comprobar que ahora disponemos de un nuevo dataset, el definido en el propio job de ASA.
Una nota al margen. Desde el portal de Power BI tenemos la opción de crear un streming dataset (podéis echar un ojo a la entrada de Chema Pérez). Pero si intentamos utilizar Stream Analytics, a día de hoy, nos topamos con que aún no esta disponible esta capacidad desde el portal de PBI.
Continuamos con el ejemplo. Creamos un nuevo dashboard y dentro añadimos un Tile, y seleccionamos Custom Streaming Data, le damos a Next y debería aparecernos el dataset que definimos en el output del job de ASA.
Seleccionamos el dataset, en este momento nos aparecerán las siguientes opciones de visualización para el streaming dataset.
Lo demás ya es configurar las visualizaciones que toque, y montar el dashboard. A continuación el resultado.
Y esto es todo por hoy. Hemos enviado eventos a un Event Hub utilizando Powershell, hemos leído y procesado dichos eventos con Stream Analytics y finalmente hemos consumido el datset generado desde Power BI en un nuevo dashboard.
A lo largo del post hay una serie de enlaces a documentación de referencia que puede resultar de utilidad, así como a posts de compañeros estrechamente relacionados a este. Gracias por vuestra atención y hasta la próxima. Si te ha resultado interesante y quieres estar al día de nuestros contenidos gratuitos y novedades.
¡No olvides suscribirte a nuestra newsletter o visitar nuestro blog para más artículos relacionados con Power BI y Azure!
