Conceitos do servidor StreamInsight
Este tópico descreve a maneira como os dados são representados, operados, inseridos no servidor do StreamInsight e transferidos dele. Ele se destina a familiarizá-lo com os conceitos básicos associados ao processamento de eventos complexos no Microsoft StreamInsight. O tópico começa descrevendo as estruturas de dados e, depois, os componentes do servidor StreamInsight que processam ou atuam sobre os dados.
Fluxos
Todos os dados do StreamInsight são organizados em fluxos. Cada fluxo descreve uma coleção de dados potencialmente infinita que muda ao longo do tempo. Por exemplo, um fluxo de cotações da bolsa fornece o preço de diferentes ações em um câmbio pois elas mudam com o passar do tempo, e um fluxo de sensor de temperatura fornece valores de temperatura relatados pelo sensor com o passar do tempo.
Considere um cenário de monitoramento de energia em que a meta seja monitorar uma coleção de medidores de energia que meçam o consumo de energia de vários dispositivos. Periodicamente, esses medidores de energia transmitem dados que incluem seu respectivo consumo de energia em décimos de um watt e um carimbo de data/hora associado à leitura. A tabela a seguir mostra as leituras de 3 medidores de energia e assume que cada medidor emite uma leitura de energia por segundo.
Tempo |
MeterID |
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 |
Como essas informações podem ser representadas como valores que são alterados ao longo do tempo, os dados podem ser representados em um fluxo. Considerando os dados nesse fluxo, uma consulta a esse fluxo pode retornar o medidor com o valor de consumo mais alto ou mais baixo em determinado período, ou a consulta pode retornar uma lista dos 10 medidores com o maior consumo de energia ao longo do tempo.
Eventos
Os dados subjacentes representados no fluxo são empacotados em eventos. Um evento é a unidade básica de dados processados pelo servidor StreamInsight. Cada evento consiste nas seguintes partes:
Cabeçalho. Um cabeçalho de evento contém metadados que definem o tipo de evento e um ou mais carimbos de data/hora que definem o intervalo de tempo para o evento. Os carimbos de data/hora são baseados no aplicativo e fornecidos pela fonte de dados. A hora do sistema não é fornecida pelo servidor StreamInsight. Observe que os carimbos de data/hora usam o tipo de dados DateTimeOffset, que reconhece o fuso horário e se baseia em um relógio de 24 horas. O servidor StreamInsight normaliza todas as horas para o datetime UTC e verifica na entrada se o sinalizador de UTC está definido nos campos de carimbo de data/hora.
Carga. Uma estrutura de dados .NET que contém os dados associados ao evento. Os campos definidos na carga são definidos pelo usuário. Seus tipos são baseados no sistema do tipo .NET.
Os eventos no fluxo cujos carimbos de data/hora de aplicativo correspondem à sua ordem de chegada na consulta são chamados de "em ordem". Quando não for o caso, os eventos são chamados de "fora de ordem". O servidor StreamInsight garante que, se os eventos chegarem fora de ordem, a saída da consulta será igual, como se os eventos tivessem chegado em ordem, a menos que o gravador de consulta especifique explicitamente o contrário. Dentro de um fluxo, os padrões típicos de chegada de eventos são:
Uma taxa contínua, como registros de arquivos ou tabelas.
Uma taxa intermitente e aleatória, como os dados de um scanner de código de barras varejista.
Uma taxa intermitente com intermitências repentinas, como cliques da Web ou telemetria do tempo.
Cabeçalho do evento
O cabeçalho de um evento define o tipo de evento e as propriedades temporais do evento.
Tipo de evento
O tipo de evento indica se o evento é um evento novo no fluxo ou se está declarando a conclusão dos eventos existentes no fluxo. O StreamInsight dá suporte a dois tipos de evento: INSERT e CTI (incremento de tempo real).
O tipo de evento INSERT adiciona um evento com sua carga ao fluxo de eventos. Além da carga, o cabeçalho do evento INSERT identifica a hora de início e término do evento. O diagrama a seguir mostra o layout de um tipo de evento INSERT.
Cabeçalho |
Carga |
|---|---|
Tipo de evento ::= INSERT StartTime ::= DateTimeOffset EndTime ::= DateTimeOffset |
Campo 1 … Campo n como tipos CLR |
O tipo de evento CTI é um evento de pontuação especial que indica a conclusão dos eventos existentes no fluxo. A estrutura do evento CTI consiste em um único campo que fornece um carimbo de data/hora atual. Um evento CTI tem duas finalidades:
Primeiro, ele permite a uma consulta aceitar e processar eventos cujos carimbos de data/hora de aplicativo não correspondem à sua ordem de chegada na consulta. Quando um evento CTI é emitido, ele indica ao servidor StreamInsight que nenhum evento INSERT de entrada subsequente revisará o histórico de eventos antes do carimbo de data/hora do CTI. Ou seja, depois que um evento CTI tiver sido emitido, nenhum evento INSERT poderá ter uma hora de início anterior ao carimbo de data/hora do evento CTI. Essa indicação de "conclusão" de um fluxo de eventos habilita o servidor StreamInsight a divulgar os resultados de janelas ou de outros operadores de agregação que tenham estado acumulado, garantindo, assim, um fluxo de eventos eficiente no sistema.
A segunda finalidade de eventos CTI é manter a baixa latência da consulta. CTIs frequentes levarão a consulta a fornecer resultados em grande quantidade a uma frequência mais alta.
.gif "Observação importante") Importante |
|---|
Sem a presença de eventos CTI no fluxo de entrada, nenhuma saída será gerada na consulta. |
Para obter mais informações, consulte Tempo avançado do aplicativo.
O diagrama a seguir mostra o layout de um tipo de evento CTI.
Cabeçalho |
|---|
Tipo de evento ::= CTI StartTime ::= DateTimeOffset |
Modelos de evento
O modelo de evento define a forma do evento com base em suas características temporais. O StreamInsight dá suporte a três modelos de evento: intervalo, ponto e borda. Os eventos de intervalo podem ser vistos como o tipo mais genérico, do qual borda e ponto são casos especiais.
Intervalo
O modelo de evento de intervalo representa um evento cuja carga é válida para um determinado período. O modelo de evento de intervalo requer que as horas de início e de término do evento sejam fornecidas nos metadados do evento. Os eventos de intervalo só são válidos para esse intervalo de tempo específico. É importante observar que as horas de início são inclusivas, considerando que as horas de término são exclusivas em relação à validade da carga do evento.
O diagrama a seguir mostra o layout de um modelo de evento de intervalo.
Metadados |
Carga |
|---|---|
Tipo de evento ::= INSERT StartTime ::= DateTimeOffset EndTime ::= DateTimeOffset |
Campo 1 … Campo n como tipos CLR |
Exemplos de eventos de intervalo incluem a largura de um pulso eletrônico, a duração (validade) de um lance em leilão ou uma atividade de cotações da bolsa na qual o preço do lance pela ação é válido para um período específico. No exemplo de monitoramento de energia descrito acima, o fluxo de eventos do medidor de energia pode ser representado com os eventos de intervalo a seguir.
Tipo de evento |
Início |
Término |
Carga (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 |
Ponto
O modelo de evento de ponto representa uma ocorrência de evento a partir de um único ponto no tempo. O modelo de evento de ponto requer somente a hora de início do evento. O servidor do StreamInsight infere a hora de término válida adicionando uma marca de escala (a menor unidade de tempo no tipo de dados de tempo subjacente) à hora de início para definir o intervalo de tempo válido para o evento. Considerando que as horas de término de evento são exclusivas, os eventos de ponto só são válidos para o único instante da sua hora de início.
O diagrama a seguir mostra o layout de um modelo de evento de ponto.
Metadados |
Carga |
|---|---|
Tipo de evento ::= INSERT StartTime ::= DateTimeOffset |
Campo 1 … Campo n como tipos CLR |
Exemplos de eventos de ponto incluem uma leitura de medidor, a chegada de um email, um clique na Web pelo usuário, uma cotação da bolsa ou uma entrada no Log de Eventos do Windows. No exemplo de monitoramento de energia descrito acima, o fluxo de eventos do medidor de energia pode ser representado com os eventos de ponto a seguir. Observe que a hora de término é calculada como a hora de início mais 1 escala (t).
Tipo de evento |
Início |
Término |
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 |
Borda
Um modelo de evento de borda representa uma ocorrência de evento cuja carga é válida para um intervalo de tempo específico. No entanto, somente a hora de início é conhecida na chegada ao servidor StreamInsight. Portanto, a hora de término é definida para a hora máxima no futuro. A hora de término do evento é conhecida posteriormente e atualizada. O modelo de evento de borda contém duas propriedades: hora da ocorrência e um tipo de borda. Juntas, essas propriedades definem o ponto inicial ou final do evento de borda.
O diagrama a seguir mostra o layout de um modelo de evento de borda.
Metadados |
Carga |
|---|---|
Tipo de evento ::= INSERT Hora de borda:: = DateTimeOffset Tipo de borda ::= START | END |
Campo 1 … Campo n como tipos CLR |
Exemplos de eventos de borda são os processos do Windows, os eventos de rastreamento do ETW (Rastreamento de Eventos para Windows), uma sessão de usuário da Web ou a quantização de um sinal analógico. O intervalo de tempo válido da carga de um evento de borda é a diferença entre o carimbo de data/hora do evento Start e o carimbo de data/hora do evento End. No diagrama a seguir, note que o evento com um valor de carga 'c' não tem uma data de término conhecida nesse ponto no tempo.
Tipo de evento |
Tipo de borda |
Hora de início |
Hora de término |
Carga |
|---|---|---|---|---|
INSERT |
Início |
t0 |
DateTimeOffset.MaxValue |
a |
INSERT |
Término |
t0 |
t1 |
a |
INSERT |
Início |
t1 |
DateTimeOffset.MaxValue |
b |
INSERT |
Término |
t1 |
t3 |
b |
INSERT |
Início |
t3 |
DateTimeOffset.MaxValue |
c |
…e assim por diante |
A ilustração a seguir mostra a quantização de um sinal analógico com o uso de eventos de borda com base nas horas de início e término definidas na tabela acima. Esse sinal contínuo significa que, para cada novo valor, uma borda END e uma borda START devem ser enviadas. As bordas descritas na ilustração se referem ao evento da hora t1 até t3.
.gif "Ilustração de evento de borda")
Considerações sobre o desempenho relacionadas à escolha do modelo de evento
É importante escolher o modelo de evento certo para o seu problema. Por exemplo, se você tem eventos que duram por um período de tempo, e seu aplicativo tem a habilidade de determinar os horários de início e fim do evento, é melhor usar eventos de intervalo para modelar isto. Se você tiver um cenário em que não sabe o horário de fim de um evento na chegada do evento, modele-o como um evento pontual, altere seu tempo de vida para estender-se por um período de tempo e use a operação Recortar para modificar o tempo de vida quando o fim do evento for reconhecido. A outra alternativa é modelar estes eventos como eventos de borda.
Enquanto eventos de borda são um modelo de evento muito conveniente, existem algumas implicações de desempenho de que você deve estar ciente. Processar eventos de borda funciona melhor quando estes eventos chegam completamente ordenados, por exemplo, todas as bordas de início são ordenadas por hora de início e as bordas de fim são ordenadas por hora de término, e a sequência combinada de eventos também é ordenada por hora. Por exemplo, se você tiver uma sequência de eventos de borda como segue:
Tipo de evento |
Tipo de borda |
Hora de início |
Hora de término |
Carga |
INSERT |
Início |
1 |
DateTimeOffset.MaxValue |
a |
INSERT |
Término |
1 |
10 |
a |
INSERT |
Início |
3 |
DateTimeOffset.MaxValue |
b |
INSERT |
Término |
3 |
6 |
b |
INSERT |
Início |
5 |
DateTimeOffset.MaxValue |
c |
INSERT |
Término |
5 |
20 |
c |
Esta sequência está desordenada nos carimbos de data e hora (1, 10, 3, 6, 5, 20). Em vez de eventos de borda completamente ordenados - como em (1, 3, 5, 6, 10, 20) – estes terão um impacto de desempenho menor no processamento de consultas. É fácil habilitar este tipo de ordenação seguida pelo processamento. Divida o problema em duas consultas. A primeira consulta pode ser uma consulta vazia que recebe eventos de borda como entrada, ordena-os completamente e gera estes eventos de borda ordenados. A segunda consulta pode receber esta entrada e realizar a lógica principal. Observe que elas podem ser definidas como duas consultas separadas e então unidas usando composição de consulta dinâmica. Para obter mais informações, consulte Compondo consultas em tempo de execução.
Carga do evento
A carga de um evento é uma estrutura de dados .NET que contém os dados associados ao evento. Os campos na carga são definidos pelo usuário e seus tipos são baseados no sistema de tipos .NET. A maioria dos tipos escalares e elementares CLR têm suporte em campos de carga. Não há suporte para tipos aninhados.
Adaptadores
Os adaptadores convertem e entregam fluxos de eventos de entrada e saída de e para o servidor StreamInsight. O StreamInsight fornece um SDK de adaptador altamente flexível que permite compilar adaptadores para origens de eventos e dispositivos de saída (coletores) específicos de domínios. Adaptadores são implementados na linguagem de programação C# e armazenados como assemblies. As classes de adaptadores são criadas como modelos durante o tempo de design, registradas no servidor StreamInsight e instanciadas no servidor durante o tempo de execução como instâncias de adaptador.
Adaptadores de entrada
Uma instância de adaptador de entrada aceita fluxos de eventos de entrada de origens externas, tais como bancos de dados, arquivos, ticker feeds, portas de rede e assim por diante. O adaptador de entrada lê os eventos de entrada no formato em que eles são fornecidos e converte esses dados no formato de evento que é consumível pelo servidor StreamInsight.
Crie um adaptador de entrada para tratar as origens de eventos específicas da sua fonte de dados. Se a origem do evento só produz um único tipo de evento, o adaptador pode conter um tipo. Ou seja, ele pode ser implementado para emitir eventos de um tipo de evento específico. Em um adaptador com tipo, todas as instâncias do adaptador produzem o mesmo formato de carga fixa, em que o número de campos e seus tipos são conhecidos com antecedência. Exemplos desse tipo de evento incluem dados de feed de ação ou dados de sensor emitidos por um dispositivo específico. Se a origem do evento emite diferentes tipos em diferentes circunstâncias, ou seja, se os eventos podem conter diferentes formatos de carga ou o formato de carga pode não ser conhecido com antecedência, implemente um adaptador sem tipo. Com um adaptador sem tipo (genérico), o formato de carga do evento é fornecido ao adaptador como parte de uma especificação de configuração no momento de associação da consulta. Exemplos de tais fontes incluem arquivos CSV que contêm um número variado de campos em que o tipo de dado armazenado no arquivo não é conhecido até o momento de instanciação da consulta, ou um adaptador de tabelas do SQL Server em que os eventos produzidos dependem do esquema da tabela. É importante observar que, em tempo de execução, uma única instância de adaptador, seja com tipo ou sem tipo, sempre emite eventos de um tipo específico. Os adaptadores sem tipo fornecem uma implementação flexível para aceitar a especificação de tipo de evento no momento da associação da consulta, em vez de definir o tipo de evento no momento em que o adaptador é implementado.
Adaptadores de saída
Crie um adaptador de saída para receber os eventos processados pelo servidor StreamInsight, converter os eventos em um formato esperado pelo dispositivo de saída (coletor) e emitir os dados para esse dispositivo. O design e a criação de um adaptador de saída é similar ao design e a criação de um adaptador de entrada. Adaptadores de saída com tipo são criados em relação a uma carga do evento específica, enquanto adaptadores de saída sem tipo são fornecidos com o tipo de evento apenas em tempo de execução quando a consulta é criada com uma instância.
Para obter mais informações, consulte Criando adaptadores de entrada e saída. A API de adaptador principal fornece a flexibilidade máxima para implementar em qualquer origem de evento ou coletor de evento. Além disso, o StreamInsight oferece suporte a origens e coletores de eventos em um nível mais alto de abstração que implementam as interfaces IObservable ou IEnumerable. Para obter mais informações, consulte Usando origens de evento observáveis e enumeráveis, e coletores de eventos (StreamInsight).
Processando e analisando eventos
Com o StreamInsight, o processamento de eventos é organizado em consultas com base na lógica de consulta definida. Essas consultas levam um feed potencialmente infinito de dados de entrada de detecção de hora (registrados ou em tempo real), executam computação nos dados e geram o resultado de forma apropriada.
Modelos de consulta
Um modelo de consulta é a unidade fundamental de composição da consulta. É a estrutura que define a lógica comercial necessária para analisar e processar continuamente eventos enviados para o servidor StreamInsight do adaptador de entrada e gerar um fluxo de eventos que é consumido pelo adaptador de saída. Por exemplo, você pode avaliar os eventos de entrada de consumo de energia para obter o valor máximo ou mínimo em determinado período que exceda certos limites estabelecidos.
Os modelos de consulta podem ser gravados para executar unidades específicas de trabalho para depois serem compostos em modelos de consulta mais complexos. Os modelos de consulta são gravados em LINQ junto com a linguagem C#. LINQ é uma plataforma de linguagem que permite expressar computação declarativa sobre conjuntos de forma totalmente integrada à linguagem host. Isso permite que você combine o processamento declarativo de eventos com a flexibilidade de programação procedural na mesma plataforma de desenvolvimento, sem a preocupação de incompatibilidade de impedância entre esses dois paradigmas de programação.
O servidor StreamInsight fornece a seguinte funcionalidade para gravar consultas e análises expressivas:
Cálculos para introduzir propriedades de evento adicionais
Os casos de uso, como conversões de unidade, exigem a execução de cálculos sobre os eventos recebidos. Ao usar a operação de projeção no servidor StreamInsight, você pode adicionar mais campos à carga e executar cálculos sobre os campos no evento de entrada. Para obter mais informações, consulte Projeção.
Filtrando eventos
Em casos de uso, como notificações de alerta, você pode verificar se determinado campo de carga excede os limites operacionais da parte do equipamento que você está monitorando. Em geral, somente um subconjunto de eventos que apresentam certas características é relevante para esses casos de uso. Os eventos que não tenham essas características não precisam ser processados e podem ser descartados. A operação de filtragem permite expressar predicados boolianos sobre a carga do evento e descartar eventos não mais compatíveis com os predicados. Para obter mais informações, consulte Filtragem.
Agrupando eventos
Considere um fluxo de eventos que apresenta leituras de tempo de todos os seus sensores de tempo. Se todos os eventos forem fornecidos por um único fluxo de eventos, você poderá particionar os eventos de entrada com base no local do sensor ou na ID do sensor. O servidor StreamInsight fornece uma operação de agrupamento que permite particionar o fluxo de entrada com base nas propriedades do evento, como o local ou a ID e, depois, aplicar outras operações ou fragmentos de consultas completas a cada grupo separadamente. Para obter mais informações, consulte Agrupar e aplicar.
Janelas ao longo do tempo
O agrupamento de eventos ao longo do tempo é um conceito avançado que permite muitos cenários. Por exemplo, você pode verificar o número de falhas que ocorrem durante um período fixo de tempo e emitir um alarme se o limite for excedido. As janelas deslizantes e em saltos permitem que você defina janelas sobre os fluxos de eventos para executar esse tipo de análise. Para obter mais informações, consulte Usando janelas de eventos.
Agregação
Quando você não analisa cada evento individual, convém examinar os valores agregados, como médias, somas ou contagens. O servidor StreamInsight oferece agregações internas para sum, count, min, max e average que costumam operar em janelas de tempo. Para obter mais informações, consulte Agregações.
Identificando os candidatos TOP N
Um tipo especial de operação de agregação é necessário em casos em uso em que você deseja identificar os eventos de candidato com maior classificação de acordo com um critério de medição específico em um fluxo de eventos. As operações TopK permitem verificar isso com base em uma ordem estabelecida sobre os campos de evento no fluxo. Para obter mais informações, consulte TopK.
Efetuando a correspondência entre eventos de fluxos diferentes
Um caso de uso comum é a necessidade de argumentar sobre eventos recebidos de vários fluxos. Por exemplo, como as origens de eventos fornecem carimbos de data/hora em seus respectivos dados de evento, convém assegurar que você só efetue a correspondência de eventos em um fluxo com um evento no segundo fluxo se eles estiverem extremamente relacionados no tempo. Além disso, talvez haja restrições adicionais sobre os eventos para correspondência e sobre quando combiná-los. O servidor StreamInsight fornece uma operação de junção avançada que executa ambas as tarefas: primeiro, efetua a correspondência entre eventos de duas origens em caso de sobreposição de tempo; segundo, executa o predicado de junção especificado nos campos de carga. O resultado dessa correspondência contém as cargas do primeiro e do segundo evento. Para obter mais informações, consulte Junções.
Combinando eventos de fluxos diferentes em um único fluxo
Várias fontes de dados podem fornecer eventos do mesmo tipo que você pode querer alimentar na mesma consulta. A operação de união fornecida pelo servidor StreamInsight permite vários fluxos de entrada multiplex em um único fluxo de saída. Para obter mais informações, consulte Uniões.
Extensões definidas pelo usuário
A funcionalidade de consulta interna do servidor StreamInsight talvez não seja suficiente em todos os casos. Para permitir extensões específicas de domínio, as consultas do servidor StreamInsight podem chamar a funcionalidade definida pelo usuário, que é fornecida através de assemblies do .NET. Além de funções definidas pelo usuário, você pode definir e implementar agregações personalizadas ou operadores de consulta. Para obter mais informações, consulte Funções definidas pelo usuário e Agregações e operadores definidos pelo usuário.
Para obter mais informações, consulte Gravando modelos de consulta no LINQ. Para obter orientação detalhada sobre como escrever consultas LINQ para StreamInsight, consulte A Hitchhiker’s Guide to StreamInsight Queries (página em inglês).
Instâncias de consulta
A associação de um modelo de consulta a adaptadores de entrada e saída específicos registra uma instância de consulta no servidor StreamInsight. As consultas associadas podem ser iniciadas, paradas e gerenciadas no servidor StreamInsight. Depois de os dados serem entregues no servidor StreamInsight através de adaptadores de entrada, a computação poderá ser executada continuamente sobre os dados. Em outras palavras, à medida que os eventos individuais chegam ao servidor, esses eventos são processados por consultas constantes, que emitem eventos de saída em resposta à chegada de eventos de entrada. A ilustração a seguir mostra consultas e adaptadores do StreamInsight em tempo de execução. O servidor StreamInsight consome e processa o evento quando a instância do adaptador de entrada é associada a uma instância de uma consulta. Os dados processados serão então enviados por push à instância do adaptador de saída que está associado à mesma instância da consulta.
.gif "Ecossistema de consulta e adaptador")