Основные понятия сервера служб StreamInsight

В этом разделе описывается способ представления данных, обработки данных, передачи данных на сервер StreamInsight и с сервера StreamInsight. Раздел знакомит читателя с основными понятиями, связанными с обработкой сложных событий в Microsoft StreamInsight. Раздел начинается с описания структур данных, а затем описываются компоненты сервера StreamInsight, которые работают с данными.

Потоки

Все данные в StreamInsight имеют вид потоков. Каждый поток описывает потенциально бесконечный набор данных, изменяющихся со временем. Например, поток биржевых котировок содержит цены различных акций на бирже, изменяющиеся со временем, а поток датчика температуры содержит значения температуры, передаваемые датчиком с течением времени.

Рассмотрим сценарий наблюдения за энергопотреблением, где нужно следить за показаниями набора ваттметров, которые измеряют энергию, потребляемую различными устройствами. Эти ваттметры передают данные, к которым относится энергопотребление в десятых долях ватта и отметка времени для момента считывания показания. В следующей таблице представлены показания трех ваттметров в предположении, что каждый ваттметр передает данные об энергопотреблении раз в секунду.

Время

MeterID

Потребление

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

Поскольку эти данные можно представить в виде значений, изменяющихся с течением времени, данные можно передавать в потоковой форме. По данным из этого потока запрос может вернуть датчик с максимальным или минимальным значением потребления за указанный период времени или список десяти датчиков с максимальным энергопотреблением за некоторый период времени.

События

Базовые данные, представленные в потоке, распределяются по событиям. Событие представляет собой базовую единицу данных, обрабатываемую сервером StreamInsight. Каждое событие состоит из следующих частей.

  • Заголовок. Заголовок события содержит метаданные, определяющие тип события, и одну или несколько отметок времени, которые определяют интервал времени для события. Отметки времени зависят от приложения и передаются источником данных, в отличие от системного времени, которое передается сервером StreamInsight. Учтите, что в отметках времени используется тип данных DateTimeOffset, который учитывает часовые пояса и основан на 24-часовом формате времени. Сервер StreamInsight приводит все значения времени к формату UTC и проверяет, что в полях отметок времени для входных данных установлен флаг UTC.

  • Полезные данные. Структура данных .NET, которая содержит данные, связанные с событием. Поля полезных данных определяются пользователем. Их типы основаны на системе типов .NET.

События в потоке, отметки времени приложения которых соответствуют порядку их прибытия в запрос, называются «упорядоченными». В противном случаю считается, что события поступают «неупорядоченно». В случае неупорядоченного поступления событий сервер StreamInsight гарантирует, что результат запроса будет таким же, как и в случае упорядоченного поступления, если автор запроса явно не укажет другое правило. В пределах потока события обычно прибывают следующим образом.

  • С постоянной скоростью, например записи из файлов или таблиц.

  • Периодически, с непостоянной скоростью, например данные от сканера штрихкодов в магазине.

  • С непостоянной скоростью и непредсказуемыми всплесками, например щелчки мышью на веб-сайте или показания телеметрии погодных условий.

Заголовок события

В заголовке события определяется тип события и временные свойства события.

Тип события

Тип события показывает, является событие новым в потоке или объявляет о завершении существующих событий в потоке. StreamInsight поддерживает два типа событий: событие INSERT и событие CTI (увеличение текущего времени).

Событие типа INSERT добавляет событие с полезными данными в поток событий. Помимо полезных данных, заголовок события INSERT определяет начальное и конечное время для события. На следующей диаграмме показан макет события типа INSERT.

Заголовок

Полезные данные

Тип события ::= INSERT

StartTime ::= DateTimeOffset

EndTime ::= DateTimeOffset

Поле 1 … поле n с типами CLR

Событие типа CTI специально подтверждает завершенность существующих событий в потоке. Структура события CTI состоит из одного поля, содержащего текущую отметку времени. Событие CTI выполняет две функции.

  1. Во-первых, оно позволяет запросу принимать и обрабатывать события, отметки времени которых не соответствуют порядку их прибытия в запрос. Созданное событие CTI сообщает серверу StreamInsight, что ни одно из последующих входящих событий INSERT не изменит журнал событий, сформированный до отметки времени CTI. Это значит, что после отправки события CTI ни одно событие INSERT не может иметь время начала раньше, чем отметка времени события CTI. Такое указание на завершенность потока событий позволяет серверу StreamInsight освободить накопленные результаты оконных функций и других агрегатных операторов, что обеспечивает эффективное движение событий по системе.

  2. Во-вторых, события CTI обеспечивают низкую задержку запроса. Частое создание событий CTI повышает частоту передачи результатов из запроса.

Важное примечаниеВажно!

Без событий CTI во входном потоке запрос не будет создавать выходные данные.

Дополнительные сведения см. в разделе Обработка времени приложения.

На следующей диаграмме показан макет события типа CTI.

Заголовок

Event kind ::= CTI

StartTime ::= DateTimeOffset

Модели событий

Модель события определяет форму события в зависимости от временных характеристик. StreamInsight поддерживает три модели события: интервальную, точечную и граничную. Интервальные события представляют собой универсальный тип, а граничные и точечные — это особые случаи.

Интервальная

Модель интервального события представляет событие, полезные данные которого действительны в течение заданного периода времени. В модели интервальных событий необходимо, чтобы в метаданных события указывались и начальное, и конечное время события. Интервальные события допустимы только в рамках определенного интервала времени. Важно отметить, что время начала включается в промежуток времени, определяющий допустимость полезных данных события, тогда как время окончания в него не включается.

На следующей диаграмме показан макет модели интервального события.

Метаданные

Полезные данные

Тип события ::= INSERT

StartTime ::= DateTimeOffset

EndTime ::= DateTimeOffset

Поле 1 … поле n с типами CLR

Примерами интервальных событий служат ширина электронного импульса, продолжительность (срок действия) ставки на аукционе или операция биржевых котировок, в которой цена покупателя акции действует в течение определенного периода времени. В описанном выше примере наблюдения за энергопотреблением потока события ваттметров можно представить с помощью следующих интервальных событий.

Тип события

Начало

Конец

Полезные данные (потребление)

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

Точка

Модель точечных событий представляет экземпляр события в отдельный момент времени. В модели точечных событий необходимо только начальное время для события. Сервер StreamInsight выводит допустимое конечное время, добавляя такт (минимальную единицу времени в базовом типе данных времени) к начальному времени, чтобы получить допустимый интервал времени для события. Учитывая, что время окончания события не включается в рассматриваемый промежуток времени, точечные события действительны только на момент своего времени начала.

На следующей диаграмме показан макет модели точечных событий.

Метаданные

Полезные данные

Тип события ::= INSERT

StartTime ::= DateTimeOffset

Поле 1 … поле n с типами CLR

Примерами точечных событий служат считывание показаний датчиков, получение электронной почты, щелчок пользователя в веб-интерфейсе, сигнал биржевых котировок или запись в журнале событий Windows. В описанном выше примере наблюдения за энергопотреблением потока события ваттметров можно представить с помощью следующих точечных событий. Заметьте, что конечное время вычисляется как начальное время плюс 1 такт (t).

Тип события

Начало

Окончание

Полезные данные (потребление)

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

Ребро

Граничная модель события представляет экземпляр события, для которого полезные данные допустимы в течение заданного интервала времени. При этом на момент прибытия на сервер StreamInsight известно только начальное время, поэтому конечное время устанавливается на максимально отдаленное время в будущем. Фактическое конечное время события становится известно и обновляется позже. Граничная модель событий содержит два свойства: время события и тип границы. Эти свойства в совокупности определяют начальную или конечную точку граничного события. 

На следующей диаграмме показан макет граничной модели события.

Метаданные

Полезные данные

Тип события ::= INSERT

Время границы ::= DateTimeOffset

Тип границы ::= START | END

Поле 1 … поле n с типами CLR

Примерами граничных событий служат процессы Windows, события трассировки из средства отслеживания событий для Windows, сеанс веб-пользователя и дискретизация аналогового сигнала. Допустимый интервал времени для полезных данных граничного события представляет разность между отметкой времени события Start и отметкой времени события End. Обратите внимание, что на следующей диаграмме для события со значением полезных данных «c» конечная дата неизвестна на данный момент времени.

Тип события

Тип границы

Start Time

End Time

Payload

INSERT

Start

t0

DateTimeOffset.MaxValue

a

INSERT

End

t0

t1

a

INSERT

Start

t1

DateTimeOffset.MaxValue

b

INSERT

End

t1

t3

b

INSERT

Start

t3

DateTimeOffset.MaxValue

c

...и так далее

На следующем рисунке показана дискретизация аналогового сигнала с помощью граничных событий с использованием начального и конечного времени, определенного в таблице выше. Такой непрерывный сигнал означает, что для каждого нового значения необходимо отправлять границу END и границу START. Границы, представленные на рисунке, относятся к событию со временем от t1 до t3.

Иллюстрация граничного события Edge

Вопросы производительности, определяющие выбор модели обработки событий

При решении проблемы выбор правильной модели обработки событий имеет первостепенное значение. Например, если имеются события, жизненный цикл которых составляет определенный период времени, а в приложении имеются функции, которые можно использовать для определения времени начала и окончания событий, рекомендуется использовать модель интервальных событий. Если же на момент прибытия события время окончания события не удается определить, можно смоделировать это событие как точечное и задать для времени существования события определенное значение. Затем после определения длительности события можно воспользоваться операцией обрезки событий для задания уже известного значения. В качестве альтернативы для таких событий можно воспользоваться моделью граничных событий.

Хотя модель граничных событий очень удобна в использовании, необходимо помнить об определенных аспектах этой модели, связанных с производительностью. Модель граничных событий является наилучшим выбором для событий, прибытие которых полностью упорядочено: начальные границы и конечные границы упорядочиваются соответственно по времени начала и окончания событий, а объединенная последовательность событий также упорядочивается по времени. В качестве примера рассмотрим следующую последовательность граничных событий.

Event Kind

Edge Type

Start Time

End Time

Payload

INSERT

Start

1

DateTimeOffset.MaxValue

a

INSERT

End

1

10

a

INSERT

Start

3

DateTimeOffset.MaxValue

b

INSERT

End

3

6

b

INSERT

Start

5

DateTimeOffset.MaxValue

c

INSERT

End

5

20

c

Эта последовательность не упорядочена по отметкам времени (1, 10, 3, 6, 5, 20). Если же граничные события полностью упорядочены (1, 3, 5, 6, 10, 20), это меньше повлияет на производительность обработки запросов. Упорядочение, после которого выполняется обработка, можно легко реализовать. Разделите задачу на два запроса. Первым запросом может быть пустой запрос, получающий граничные события в качестве входных, после чего они полностью упорядочиваются и запрос возвращает эти упорядоченные граничные события. Второй запрос может принимать эти входные события и выполнить основную логику. Следует отметить, что необходимо определить два отдельных запроса, которые потом следует объединить с помощью динамического запроса. Дополнительные сведения см. в разделе Составление запросов во время выполнения.

Полезные данные события

Полезные данные события представляют структуру данных .NET, которая содержит данные, связанные с событием. Поля полезных данных определяются пользователем, а их типы основаны на системе типов .NET. Для полей полезных данных поддерживается большинство скалярных и элементарных типов CLR. Вложенные типы не поддерживаются.

Адаптеры

Адаптеры преобразуют и доставляют потоки входящих и исходящих событий на сервер StreamInsight. StreamInsight предоставляет пакет SDK для разработки адаптеров, который обеспечивает гибкие возможности построения адаптеров для источников событий и выходных устройств (приемников) в соответствии с условиями домена. Адаптеры реализуются на языке программирования C# и хранятся в виде сборок. Классы адаптеров создаются в виде шаблонов во время разработки и регистрируются на сервере StreamInsight, а во время выполнения на сервере создаются экземпляры адаптеров.

Входные адаптеры

Экземпляр входного адаптера принимает входящие потоки событий из внешних источников, таких как базы данных, файлы, каналы биржевых котировок, сетевые порты, датчики и т. п. Входной адаптер считывает входящие события в формате, в котором они передаются, и преобразует эти данные в формат событий, который обрабатывается сервером StreamInsight.

Входной адаптер создается для обработки определенных источников событий для источника данных. Если источник событий создает события только одного типа, то адаптер может быть типизированным. Это значит, что адаптер можно реализовать для передачи только одного определенного типа событий. Все экземпляры типизированного адаптера создают полезные данные в одинаковом фиксированном формате, а их типы известны заранее. Примерами таких событий являются данные канала биржевых котировок или показания датчика, передаваемые определенным устройством. Если источник событий в различных условиях передает различные типы данных, то есть события могут содержать полезные данные разного формата либо формат полезных данных не известен заранее, то следует реализовать нетипизированный адаптер. В случае нетипизированного (универсального) адаптера формат полезных данных события передается в составе спецификации конфигурации адаптеру во время привязки запроса. Примерами таких источников служат CSV-файлы, содержащие переменное количество полей, когда тип данных, хранящихся в файле, не известен до момента создания запроса, или адаптер для таблиц SQL Server, где создаваемые события зависят от схемы таблицы. Важно заметить, что во время выполнения одиночный экземпляр адаптер (и типизированного, и нетипизированного) всегда передает события одного определенного типа. Гибкая реализация нетипизированных адаптеров позволяет принимать спецификацию типов событий во время привязки запроса, а не определять тип событий во время реализации адаптера.

Выходные адаптеры

Выходной адаптер создается для получения событий, обработанных сервером StreamInsight, преобразования их в формат, ожидаемый выходным устройством (приемником), и передачи данных в это устройство. Проектирование и создание выходного адаптера выполняются аналогично проектированию и созданию входного адаптера. Типизированные выходные адаптеры предназначены для определенных полезных данных событий, а нетипизированные выходные адаптеры получают тип событий только во время выполнения, когда создается экземпляр запроса.

Дополнительные сведения см. в разделе Создание входных и выходных адаптеров. API основного адаптера обеспечивает максимальный уровень гибкости при реализации с использованием любого источника или приемника событий. Также StreamInsight поддерживает источники и приемники событий на более высоком уровне абстракции, когда реализуются интерфейсы IObservable и IEnumerable. Дополнительные сведения см. в разделе Использование наблюдаемых и перечисляемых источников и приемников событий (StreamInsight).

Обработка и анализ событий

В StreamInsight обработка событий выполняется различными запросами в зависимости от определяемой разработчиком логики запросов. Эти запросы принимают потенциально неограниченный поток входных данных с заданной временной структурой (из журнала или в реальном времени), выполняют с данными определенные вычисления и выводят результат подходящим способом.

Шаблоны запроса

Шаблон запроса является базовой единицей для составления запросов. Это структура, в которой определяется бизнес-логика, необходимая для постоянного анализа и обработки событий, отправляемых на сервер StreamInsight из входного адаптера, и создания потока событий, принимаемого выходным адаптером. Например, может понадобиться обработать входящие события энергопотребления с целью определения максимальных или минимальных значений за заданный период времени, которые превышают установленные пороговые значения.

Можно создавать шаблоны запросов, выполняющие определенные порции работы, а затем составлять на их основе более сложные шаблоны запросов. Шаблоны запросов пишутся на языке LINQ в сочетании с языком C#. Языковая платформа LINQ позволяет в декларативной форме определять вычисления с наборами данных с полной интеграцией в базовый язык. Это дает возможность сочетать на одной платформе разработки декларативную обработку событий с гибкостью процедурного программирования и не заботиться о проблемах согласования этих двух принципов программирования.

Сервер StreamInsight предоставляет следующие функции для написания выражений запросов и аналитики.

  • Вычисления для образования дополнительных свойств событий

    В таких ситуациях, как преобразование единиц, требуется выполнять вычисления с получаемыми событиями. С помощью операции проекции на сервере StreamInsight можно добавлять в полезные данные дополнительные поля и выполнять вычисления с полями входного события. Дополнительные сведения см. в разделе Проекция.

  • Фильтрация событий

    Для таких задач, как уведомление о предупреждениях, может понадобиться проверять, превышает ли определенное поле полезных данных заданные операционной системой пороговые значения для наблюдения за компонентом оборудования. Обычно в таких случаях важным является только подмножество событий, имеющих определенные характеристики. События с другими характеристиками не нужно обрабатывать, и их можно пропустить. Операция фильтрации позволяет задавать логические предикаты для полезных данных событий и пропускать события, не удовлетворяющие этим предикатам. Дополнительные сведения см. в разделе Фильтрация.

  • Группирование событий

    Рассмотрим поток событий, который передает показания со всех датчиков температуры. Если все события передаются в одном потоке, то может понадобиться секционировать входящие события в зависимости от расположения датчика или идентификатора датчика. Сервер StreamInsight поддерживает операцию группирования, которая позволяет секционировать входящий поток в зависимости от свойств событий, таких как расположение или идентификатор, а затем применять другие операции или завершенные фрагменты запросов отдельно к каждой группе. Дополнительные сведения см. в разделе Группирование и применение

  • Окна времени

    Принцип группирования событий по времени дает широкие возможности в различных сценариях. Например, может понадобиться проверять количество сбоев, произошедших за фиксированный период времени, и создавать аварийный сигнал, если это количество превышает пороговое значение. Для выполнения такого анализа можно определять окна переключения и скользящие окна для потоков событий. Дополнительные сведения см. в разделе Использование окон событий.

  • Статистическая обработка

    Если отдельные события не представляют интереса, можно работать с агрегатными значениями, такими как средние значения, суммы или количества элементов. Сервер StreamInsight поддерживает встроенные агрегаты sum, count, min, max и average, которые обычно работают с временными окнами. Дополнительные сведения см. в разделе Агрегаты.

  • Определение первых N кандидатов

    В случаях, когда нужно определить события-кандидаты, имеющие максимальный ранг по определенной метрике в потоке событий, требуется специальный тип агрегатной операции. Операции TopK позволяют проверить наличие важных параметров в зависимости от порядка, заданного для полей событий в потоке. Дополнительные сведения см. в разделе TopK.

  • Сопоставление событий из различных потоков

    Довольно распространены случаи, когда события получаются из нескольких потоков. Например, если источники события снабжают данные событий отметками времени, может понадобиться обеспечить сопоставление событий из одного потока с событиями из другого потока только в случае, если они близко связаны по времени. Кроме того, могут действовать дополнительные ограничения на характеристики сопоставляемых событий и время сопоставления. Сервер StreamInsight поддерживает мощную операцию соединения, которая выполняет обе задачи: во-первых, она сопоставляет события из двух источников, если эти события имеют перекрывающиеся значения времени, а во-вторых, она выполняет предикат соединения, указанный в полях полезных данных. Результат такого сопоставления содержит полезные данные и из первого, и из второго события. Дополнительные сведения см. в разделе Соединения.

  • Объединение событий из различных потоков в один

    Несколько источников данных могут отправлять события одного типа, которые может понадобиться передать в один запрос. Операция объединения, предоставляемая сервером StreamInsight, позволяет формировать единый выходной поток из нескольких входных потоков. Дополнительные сведения см. в разделе Объединения.

  • Определяемые пользователем расширения

    В ряде случаев возможностей по работе с запросами, встроенных в сервер StreamInsight, может оказаться недостаточно. Для поддержки расширений, обусловленных требованиями домена, запросы на сервере StreamInsight могут вызывать определяемые пользователем функции, предоставляемые в сборках .NET. Помимо определяемых пользователем функций, можно определять и реализовывать нестандартные статистические выражения и операторы запроса. Дополнительные сведения см. в разделах Определяемые пользователем функции и Определяемые пользователем статистические функции и операторы.

Дополнительные сведения см. в разделе Написание шаблонов запроса на языке LINQ. Подробные рекомендации по написанию запросов LINQ для StreamInsight см. в разделе Автостопом по запросам StreamInsight.

Экземпляры запросов

В процессе привязки шаблона запроса к определенному входному и выходному адаптеру на сервере StreamInsight регистрируется экземпляр запроса. Для привязанных запросов на сервере StreamInsight доступен запуск, остановка и управление. После доставки на сервер StreamInsight через входные адаптеры с данными можно выполнять постоянные вычисления. Иными словами, отдельные события поступают на сервер обработки сложных событий и обрабатываются постоянными запросами, которые передают выходные события в ответ на прибытие входных событий. На следующем рисунке показаны запросы и адаптеры StreamInsight во время выполнения. Сервер StreamInsight получает и обрабатывает событие, когда экземпляр входного адаптера привязывается к экземпляру запроса. Затем обработанные данные передаются в экземпляр выходного адаптера, который привязан к тому же экземпляру запроса.

Экосистема запросов и адаптера

См. также

Основные понятия

Архитектура сервера служб StreamInsight

Законченный пример StreamInsight