Conceptos de servidor de StreamInsight
En este tema se describe la manera en que los datos se representan en el servidor de StreamInsight, cómo se realizan operaciones con ellos, y cómo se insertan y extraen de este servidor. Este tema se ha diseñado para que conozca los conceptos básicos asociados al procesamiento de eventos complejos de Microsoft StreamInsight. Empieza con la descripción de estructuras de datos y continúa con la descripción de componentes del servidor de StreamInsight que operan con los datos o los procesan.
Flujos
Todos los datos de StreamInsight se organizan en flujos. Cada flujo describe una colección de datos que cambia con el tiempo y que potencialmente no tiene fin. Por ejemplo, un flujo del tablero de cotizaciones proporciona el precio de diferentes acciones en un mercado a medida que cambian con el tiempo y un flujo de sensor de temperatura proporciona los valores de temperatura que proporciona el sensor a medida que pasa el tiempo.
Imagine una situación de supervisión de energía en que el objetivo sea supervisar una serie de medidores de energía que miden el consumo energético de varios dispositivos. Periódicamente, los medidores de energía transmiten datos con el consumo energético en décimas de vatio y una marca de tiempo asociada de la lectura. En la siguiente tabla se muestran las lecturas de tres medidores de energía y se asume que cada uno emite una lectura de la energía por segundo.
Hora |
Identificador del medidor |
Consumo |
|---|---|---|
2009-07-27 10:27:23 |
1 |
100 |
2009-07-27 10:27:24 |
1 |
200 |
2009-07-27 10:27:51 |
2 |
300 |
2009-07-27 10:28:52 |
2 |
100 |
2009-07-27 10:27:23 |
3 |
200 |
Puesto que esta información se puede representar como valores que cambian en el tiempo, los datos se pueden representar en una secuencia. A partir de los datos de este flujo, una consulta realizada en él podría devolver el medidor con los valores de consumo más alto o más bajo en un período de tiempo determinado. También podría devolver la lista de los 10 medidores con más consumo energético a lo largo del tiempo.
Eventos
Los datos subyacentes representados en el flujo se empaquetan en eventos. Un evento es la unidad básica de datos procesada por el servidor de StreamInsight. Cada evento consta de las siguientes partes:
Encabezado. Un encabezado de evento contiene metadatos que definen el tipo de evento y una o varias marcas de tiempo que definen el intervalo de tiempo para el evento. Las marcas de tiempo se basan en la aplicación, y las proporciona el origen de datos en lugar de ser una hora del sistema proporcionada por el servidor de StreamInsight. Tenga en cuenta que las marcas de tiempo utilizan el tipo de datos DateTimeOffset, que reconoce la zona horaria y utiliza el reloj de 24 horas. El servidor de StreamInsight normaliza todas las horas a la fecha y hora UTC, y comprueba en la entrada que los campos de marca de tiempo tienen establecida la marca de hora UTC.
Carga. Es una estructura de datos .NET que incluye los datos asociados al evento. Los campos definidos en la carga son definidos por el usuario. Sus tipos se basan en el sistema de tipos .NET.
Si las marcas de tiempo de aplicación de los eventos del flujo corresponden a su orden de llegada en la consulta, se dice que los eventos están "en orden". Si no es este el caso, se dice que los eventos llegan "desordenados". El servidor de StreamInsight garantiza que si los eventos llegan desordenados, la salida de la consulta es la misma que si llegaran en orden, a menos que el creador de la consulta especifique explícitamente lo contrario. Dentro de una secuencia, los modelos de llegada de eventos típicos son:
Una tasa regular, por ejemplo registros de archivos o tablas.
Una tasa intermitente y aleatoria, por ejemplo datos de un escáner de códigos de barras comercial.
Una tasa intermitente con aumentos repentinos, por ejemplo los clics en páginas web o datos climatológicos.
Encabezado de evento
El encabezado de un evento define el tipo de evento y las propiedades temporales del evento.
Tipo de evento
El tipo de evento indica si el evento es un evento nuevo en la secuencia o si está declarando la integridad de los eventos existentes en la secuencia. StreamInsight admite dos tipos de evento: INSERT y CTI (incremento de tiempo actual).
El tipo de evento INSERT agrega un evento con su carga útil a la secuencia de eventos. Además de la carga útil, el encabezado del evento INSERT identifica la hora de inicio y de finalización del evento. El siguiente diagrama muestra el diseño de un tipo de evento INSERT.
Encabezado |
Payload |
|---|---|
Tipo de evento ::= INSERT StartTime ::= DateTimeOffset EndTime ::= DateTimeOffset |
Campo 1 … Field n como tipos CLR |
El tipo de evento CTI es un evento de puntuación especial que indica la integridad de los eventos existentes en la secuencia. La estructura del evento CTI consta de un campo único que proporciona una marca de tiempo actual. Un evento CTI cumple dos fines:
En primer lugar, habilita una consulta para aceptar y procesar eventos cuyas marcas de tiempo de aplicación no corresponden a su orden de llegada a la consulta. Cuando se emite un evento CTI, indica al servidor de StreamInsight que ningún evento INSERT de entrada subsiguiente modificará el historial de eventos previo a la marca de tiempo de CTI. Es decir, una vez emitido un evento CTI, ningún evento INSERT puede tener una hora de inicio anterior a la marca de tiempo del evento CTI. Esta indicación de "integridad" de un flujo de eventos permite que el servidor de StreamInsight libere los resultados de los operadores de ventana u otros operadores de agregación con estado acumulado, garantizando así que los eventos fluyen de forma eficaz por el sistema.
El segundo propósito de los eventos CTI consiste en mantener la latencia baja de la consulta. Los CTI frecuentes harán que la consulta bombee los resultados con una frecuencia mayor.
.gif "Nota importante") Importante |
|---|
Sin la presencia de eventos CTI en el flujo de entrada, la consulta no generará ninguna salida. |
Para obtener más información, vea Adelantar tiempo de aplicación.
El siguiente diagrama muestra el diseño de un tipo de evento CTI.
Encabezado |
|---|
Tipo de evento ::= CTI StartTime ::= DateTimeOffset |
Modelos de evento
El modelo de evento define la forma del evento en función de sus características temporales. StreamInsight admite tres modelos de evento: de punto, de intervalo y perimetral. Los eventos de intervalo son el tipo más genérico, del que los eventos perimetrales y de punto son casos especiales.
Intervalo
El modelo de evento de intervalo representa un evento cuya carga útil es válida para un periodo de tiempo determinado. El modelo de evento de intervalo requiere que la hora de inicio y la hora de finalización del evento se proporcionen en los metadatos del evento. Los eventos de intervalo solo son válidos para este intervalo de tiempo concreto. Es importante tener en cuenta que las horas de inicio son inclusivas, mientras que las horas de finalización son exclusivas con respecto a la validez de la carga útil del evento.
El siguiente diagrama muestra el diseño de un modelo de evento de intervalo.
Metadatos |
Payload |
|---|---|
Tipo de evento ::= INSERT StartTime ::= DateTimeOffset EndTime ::= DateTimeOffset |
Campo 1 … Field n como tipos CLR |
Se pueden citar como ejemplos de eventos de intervalo el ancho de un pulso electrónico, la duración (validez) de la puja de una subasta o la actividad de un tablero de cotizaciones en que el precio de la oferta para las acciones es válido para un periodo de tiempo concreto. En el ejemplo de supervisión de energía descrito anteriormente, la secuencia de eventos del medidor de energía se puede representar con los siguientes eventos de intervalo.
Tipo de evento |
Inicio |
Finalización |
Carga útil (consumo) |
|---|---|---|---|
INSERT |
2009-07-15 09:13:33.317 |
2009-07-15 09:14:09.270 |
100 |
INSERT |
2009-07-15 09:14:09.270 |
2009-07-15 09:14:22.255 |
200 |
INSERT |
2009-07-15 09:14:22.255 |
2009-07-15 09:15:04.987 |
100 |
Punto
El modelo de evento de punto representa la instancia de un evento en un punto único en el tiempo. El modelo de evento de punto solo necesita la hora de inicio del evento. El servidor de StreamInsight deduce la hora de finalización válida agregando un tic (unidad de tiempo más pequeña en el tipo de datos de tiempo subyacente) a la hora de inicio para establecer el intervalo de tiempo válido para el evento. Si se tiene en cuenta que las horas de finalización de evento son exclusivas, los eventos de punto solo son válidos para el momento único de su hora de inicio.
El siguiente diagrama muestra el diseño de un modelo de evento de punto.
Metadatos |
Payload |
|---|---|
Tipo de evento ::= INSERT StartTime ::= DateTimeOffset |
Campo 1 … Field n como tipos CLR |
Son ejemplos de evento de punto una lectura de contador, la llegada de un mensaje de correo electrónico, el clic de un usuario de Internet, una marca de cotizaciones o una entrada en el registro de eventos de Windows. En el ejemplo de supervisión de energía descrito anteriormente, la secuencia de eventos del medidor de energía se puede representar con los siguientes eventos de punto. Observe que la hora de finalización se calcula como la hora de inicio más 1 tic (t).
Tipo de evento |
Inicio |
Finalización |
Carga (consumo) |
|---|---|---|---|
INSERT |
2009-07-15 09:13:33.317 |
2009-07-15 09:13:33.317 + t |
100 |
INSERT |
2009-07-15 09:14:09.270 |
2009-07-15 09:14:09.270 + t |
200 |
INSERT |
2009-07-15 09:14:22.255 |
2009-07-15 09:14:22.255 + t |
100 |
Perimetral
El modelo de evento perimetral representa una repetición de evento cuya carga es válida para un intervalo de tiempo determinado; sin embargo, solo se conoce la hora de inicio en la llegada al servidor de StreamInsight, por lo que la hora de finalización se establece en la hora máxima en el futuro. La hora de finalización del evento se conoce más adelante y se actualiza. El modelo de evento perimetral contiene dos propiedades: hora de repetición y un tipo perimetral. Estas dos propiedades juntas definen el punto de inicio o de finalización del evento perimetral.
El siguiente diagrama muestra el diseño de un modelo de evento perimetral.
Metadatos |
Payload |
|---|---|
Tipo de evento ::= INSERT Edge time ::= DateTimeOffset Edge type ::= START | END |
Campo 1 … Field n como tipos CLR |
Son ejemplos de estos eventos los procesos de Windows, los eventos de seguimiento de Seguimiento de eventos para Windows (ETW), una sesión de usuario de web o la cuantificación de una señal analógica. El intervalo de tiempo válido para la carga de un evento perimetral es la diferencia entre la marca de tiempo del evento START y la marca de tiempo del evento END. En el siguiente diagrama, observe que el evento con un valor de carga 'c' no tiene una fecha de finalización conocida en este momento.
Tipo de evento |
Tipo perimetral |
Hora de inicio |
Hora de finalización |
Carga |
|---|---|---|---|---|
INSERT |
Inicio |
t0 |
DateTimeOffset.MaxValue |
a |
INSERT |
Finalización |
t0 |
t1 |
a |
INSERT |
Inicio |
t1 |
DateTimeOffset.MaxValue |
b |
INSERT |
Finalización |
t1 |
t3 |
b |
INSERT |
Inicio |
t3 |
DateTimeOffset.MaxValue |
c |
… etc. |
La siguiente ilustración muestra la cuantificación de una señal analógica mediante eventos perimetrales basados en las horas de inicio y finalización definidas en la tabla anterior. Este tipo de señal continua implica que, para cada nuevo valor, se deben enviar los bordes END y START. Los perímetros descritos en la ilustración hacen referencia al evento de la hora t1 a t3.
.gif "Ilustración de evento perimetral")
Consideraciones sobre rendimiento en la elección de modelo de evento
Es importante elegir el modelo de evento apropiado para su problema. Por ejemplo, si tiene eventos que duran un período de tiempo y la aplicación tiene capacidad para determinar las horas de inicio y finalización del evento, es preferible usar eventos de intervalo para la modelación. Si tiene un escenario en el que no conoce la hora de finalización de un evento en la llegada de eventos, puede considerar la opción de modelarlo como un evento de punto, alterar su duración de modo que se extienda en un período de tiempo y, por último, usar la operación de ajuste para modificar la duración cuando se reconozca la finalización del evento. La otra alternativa es modelar estos eventos como eventos perimetrales.
Aunque los eventos perimetrales son un modelo de evento muy práctico, hay un par de consecuencias relacionadas con el rendimiento que debe conocer. El procesamiento de eventos perimetrales funciona mejor cuando estos eventos llegan totalmente en orden, es decir, todos los perímetros iniciales están ordenados por hora de inicio y los perímetros finales lo están por hora de finalización, y el flujo combinado de eventos también está ordenado por hora. Por ejemplo, si tiene la siguiente secuencia de eventos perimetrales:
Tipo de evento |
Tipo perimetral |
Hora de inicio |
Hora de finalización |
Carga |
INSERT |
Inicio |
1 |
DateTimeOffset.MaxValue |
a |
INSERT |
Finalización |
1 |
10 |
a |
INSERT |
Inicio |
3 |
DateTimeOffset.MaxValue |
b |
INSERT |
Finalización |
3 |
6 |
b |
INSERT |
Inicio |
5 |
DateTimeOffset.MaxValue |
c |
INSERT |
Finalización |
5 |
20 |
c |
Esta secuencia no está ordenada por marcas de tiempo (1, 10, 3, 6, 5, 20). Si los eventos perimetrales estuvieran totalmente en orden, como por ejemplo (1, 3, 5, 6, 10, 20), el impacto sobre el rendimiento sería menor en el procesamiento de la consulta. La habilitación de una ordenación de este tipo seguida del procesamiento se consigue fácilmente. Basta con dividir el problema en dos consultas. La primera consulta puede ser una consulta vacía que reciba eventos perimetrales como entrada, los ordene totalmente y genere como salida estos eventos perimetrales ordenados. La segunda consulta puede tomar esta entrada y realizar la lógica principal. Tenga en cuenta que debe definir estas dos consultas como consultas independientes y combinarlas después mediante la creación de consultas dinámicas. Para obtener más información, vea Crear consultas en tiempo de ejecución.
Carga de evento
La carga de un evento es una estructura de datos .NET que contiene los datos asociados al evento. Los campos de la carga son definidos por el usuario y sus tipos se basan en el sistema de tipos .NET. En los campos de carga se admiten la mayoría de los tipos elementales y escalares de CLR. No se permiten tipos anidados.
Adaptadores
Los adaptadores transforman y entregan flujos de eventos de entrada y de salida hacia y desde el servidor de StreamInsight. StreamInsight proporciona un SDK de adaptadores muy flexible que permite crear adaptadores para orígenes del evento y dispositivos de salida (receptores) específicos del dominio. Los adaptadores se implementan en el lenguaje de programación C# y se almacenan como ensamblados. Las clases de adaptadores se crean como plantillas durante el tiempo de diseño, se registran en el servidor de StreamInsight y sus instancias se crean en el servidor durante el tiempo de ejecución como instancias de adaptador.
Adaptadores de entrada
Una instancia de un adaptador de entrada acepta flujos de eventos de entrada procedentes de orígenes externos como bases de datos, archivos, fuentes de tableros de cotizaciones, puertos de red, sensores, etc. El adaptador de entrada lee los eventos de entrada en el formato en que se proporcionan y transforma estos datos en un formato de evento compatible con el servidor de StreamInsight.
Debe crear un adaptador de entrada para administrar los orígenes de eventos concretos para el origen de datos. Si el origen de eventos solo genera un único tipo de evento, el adaptador puede tener tipo. Es decir, se puede implementar para emitir eventos de un tipo de evento determinado. Con un adaptador con tipo, todas las instancias del adaptador crean el mismo formato de carga fijo, en el que se conoce de antemano el número de campos y sus tipos. Son ejemplos de este tipo de eventos los datos de fuentes de símbolo del valor o datos de sensor emitidos por un dispositivo concreto. Si el origen de eventos emite tipos distintos en función de las circunstancias, es decir, si los eventos pueden contener formatos de carga diferentes o no se puede conocer el formato de carga de antemano, debe implementar un adaptador sin tipo. Con un adaptador sin tipo (genérico), el formato de carga de evento se proporciona al adaptador como parte de una especificación de configuración en el tiempo de enlace de consultas. Son ejemplos de dichos orígenes los archivos CSV que contienen un número variable de campos y en los que el tipo de los datos almacenados en el archivo no se conoce hasta el momento de creación de instancias de consulta, o los adaptadores para tablas de SQL Server en los que los eventos generados dependen del esquema de la tabla. Es importante tener en cuenta que, en tiempo de ejecución, una instancia de un adaptador única, con o sin tipo, siempre emite eventos de un tipo específico. Los adaptadores sin tipo proporcionan una implementación flexible para aceptar la especificación de tipo de evento en el momento de enlace de consulta, en lugar de definir el tipo de evento en el momento de la implementación del adaptador.
Adaptadores de salida
Debe crear un adaptador de salida para recibir los eventos procesados por el servidor de StreamInsight, transformarlos en un formato compatible con el dispositivo de salida (receptor), y emitirlos a ese dispositivo. El diseño y creación de un adaptador de salida son parecidos al diseño y creación de un adaptador de entrada. Los adaptadores de salida con tipo se diseñan con respecto a una carga de evento específica, en tanto que los adaptadores de salida sin tipo solamente reciben el tipo de evento en tiempo de ejecución, cuando se crean instancias de la consulta.
Para obtener más información, vea Crear adaptadores de entrada y de salida. La API de adaptador básica proporciona la máxima flexibilidad para la implementación con respecto a cualquier origen o receptor del evento. Además, StreamInsight admite orígenes y receptores de eventos en un nivel de abstracción superior de implementación de las interfaces IObservable o IEnumerable. Para obtener más información, vea Usar orígenes y receptores de eventos observables y enumerables (StreamInsight).
Procesar y analizar eventos
Con StreamInsight, el procesamiento de eventos se organiza en consultas basadas en la lógica de consulta que usted defina. Estas consultas pueden aceptar una cantidad potencialmente infinita de datos de entrada dependientes del tiempo (registrado o tiempo real), realizan cálculos en los datos y generan el resultado de una manera adecuada.
Plantillas de consulta
Una plantilla de consulta es la unidad fundamental en la escritura de consultas. Es la estructura que define la lógica de negocios necesaria para analizar y procesar continuamente los eventos enviados al servidor de StreamInsight desde el adaptador de entrada, y generar un flujo de eventos que se utiliza en el adaptador de salida. Por ejemplo, podría desear evaluar los eventos de consumo energético de entrada para obtener los valores máximo o mínimo en un periodo de tiempo determinado y que superen ciertos umbrales establecidos.
Las plantillas de consulta se pueden escribir para realizar unidades de trabajo concretas y, a continuación, se pueden usar para crear plantillas de consulta más complejas. Las plantillas de consulta se escriben en LINQ combinado con el lenguaje C#. LINQ es una plataforma de lenguaje que permite expresar cálculos declarativos con conjuntos de una manera que se integra totalmente en el lenguaje del host. Así, el procesamiento declarativo de eventos se une a la flexibilidad de la programación de procedimientos en la misma plataforma de desarrollo, sin el problema de una disparidad de impedancia entre estos dos paradigmas de programación.
El servidor de StreamInsight proporciona la siguiente funcionalidad para escribir consultas y análisis expresivos:
Cálculos para introducir propiedades de evento adicionales
Casos de uso como conversiones de unidades exigen realizar cálculos con los eventos que se reciben. El uso de la operación de proyección en el servidor de StreamInsight permite agregar campos adicionales a la carga y realizar cálculos con los campos del evento de entrada. Para obtener más información, vea Proyección.
Filtrar eventos
En casos de uso como las notificaciones de alerta, se podría comprobar si un campo de carga determinado supera los umbrales operativos del equipo que se está supervisando. En general, solo un subconjunto de eventos que cumplen ciertas características es pertinente para estos casos de uso. No es necesario procesar los eventos que no tienen estas características y se pueden descartar. La operación de filtrado permite expresar predicados booleano en la carga útil del evento y descartar los eventos que no cumplen los predicados. Para obtener más información, vea Filtrar.
Agrupar eventos
Imagine que dispone de una secuencia de eventos que proporciona lecturas de la temperatura de todos los sensores de temperatura. Si todos los eventos se proporcionan a través de un único flujo de eventos, podría ser útil dividir los eventos de entrada en función de la ubicación del sensor o el identificador del sensor. El servidor de StreamInsight proporciona una operación de agrupación que permite dividir el flujo de entrada en función de propiedades de evento como la ubicación o el identificador y, a continuación, aplicar otras operaciones o completar fragmentos de consulta en cada de grupo por separado. Para obtener más información, vea Agrupar y aplicar.
Ventanas el tiempo
La agrupación de eventos en el tiempo es un concepto eficaz que ofrece muchas opciones. Por ejemplo, puede ser útil comprobar el número de errores que se producen durante un periodo fijo de tiempo y generar una alarma si superan un umbral. Las ventanas de salto y deslizantes permiten definir ventanas en las secuencias de eventos para realizar este tipo de análisis. Para obtener más información, vea Utilizar ventanas de eventos.
Agregación
Si no interesa cada evento independiente, puede desearse examinar valores agregados como promedios, sumas o recuentos. El servidor de StreamInsight proporciona agregaciones integradas para las operaciones sum, count, min, max y average, que se suelen aplicar a las ventanas de tiempo. Para obtener más información, vea Agregaciones.
Identificar el número N superior de candidatos
Se necesita un tipo especial de operación de agregación en los casos donde se desean identificar los eventos candidatos con el rango más alto según una métrica concreta en un flujo de eventos. Las operaciones de TopK permiten identificarlos en función de un orden que se establece en los campos de evento del flujo. Para obtener más información, vea TopK.
Comparar eventos de distintas secuencias
Un caso de uso común es la necesidad de analizar eventos recibidos de varias secuencias. Por ejemplo, puesto que los orígenes de evento proporcionan marcas de tiempo en los datos de los eventos, puede desear asegurarse de que solo compara los eventos de una secuencia con un evento de una segunda secuencia si son cercanos en el tiempo. Además, puede tener restricciones adicionales sobre qué eventos comparar y cuándo compararlos. El servidor de StreamInsight proporciona una eficaz operación de combinación que realiza ambas tareas: primero, compara eventos de los dos orígenes si se superponen en el tiempo y segundo, ejecuta el predicado de combinación especificado en los campos de carga. El resultado de este tipo de comparación contiene las cargas de los eventos primero y segundo. Para obtener más información, vea Combinaciones.
Unir eventos de distintas secuencias para crear uno solo
Varios orígenes de datos pueden proporcionar eventos del mismo tipo que se podría desear incluir en la misma consulta. La operación de unión que proporciona el servidor de StreamInsight permite multiplexar varios flujos de entrada en un único flujo de salida. Para obtener más información, vea Uniones.
Extensiones definidas por el usuario
Es posible que la funcionalidad de consultas integrada del servidor de StreamInsight no resulte suficiente en todos los casos. Para admitir las extensiones específicas de dominio, las consultas del servidor de StreamInsight pueden invocar funcionalidad definida por el usuario que se proporciona a través de ensamblados .NET. Además de las funciones definidas por el usuario, puede definir e implementar agregaciones u operadores de consulta personalizados. Para obtener más información, vea Funciones definidas por el usuario y Agregados y operadores definidos por el usuario.
Para obtener más información, vea Escribir plantillas de consulta en LINQ. Para obtener instrucciones detalladas sobre cómo se escriben consultas LINQ en StreamInsight, vea la guía de un autoestopista para consultas en StreamInsight.
Instancias de consulta
El enlace de una plantilla de consulta con adaptadores de entrada y de salida concretos registra una instancia de consulta en el servidor de StreamInsight. En el servidor de StreamInsight se pueden iniciar, detener y administrar consultas enlazadas. Una vez introducidos los datos en el servidor de StreamInsight a través de los adaptadores de entrada, se pueden realizar cálculos con los datos de forma continua. Dicho de otro modo, cuando llegan al servidor eventos individuales, las consultas permanentes los procesan y emiten eventos de salida en respuesta a la llegada de eventos de entrada. La siguiente ilustración muestra los adaptadores y las consultas deStreamInsight en tiempo de ejecución. El servidor de StreamInsight utiliza y procesa el evento cuando la instancia del adaptador de entrada se enlaza a una instancia de una consulta. A continuación, los datos procesados se insertan en la instancia del adaptador de salida que está enlazado a la misma instancia de la consulta.
.gif "Ecosistema de consultas y adaptadores")