Почему потоки в Orleans?
Существует уже широкий спектр технологий, позволяющих создавать системы потоковой обработки. К ним относятся системы для безопасного хранения потоковых данных (например, Центров событий и Kafka) и систем для выражения вычислительных операций через потоковые данные (например, Azure Stream Analytics, Apache Storm и Apache Spark Streaming). Это отличные системы, которые позволяют создавать эффективные конвейеры обработки потока данных.
Ограничения существующих систем
Однако эти системы не подходят для точного вычисления свободной формы через потоковые данные. Вычислительные системы потоковой передачи, упоминание выше, позволяют указать единый граф потока данных операций, которые применяются одинаково ко всем элементам потока. Это мощная модель, когда данные являются универсальными, и вы хотите выразить тот же набор операций преобразования, фильтрации или агрегирования по этим данным. Но существуют и другие варианты использования, в которых необходимо выразить принципиально разные операции над различными элементами данных. И в некоторых из них в рамках этой обработки иногда требуется выполнить внешний вызов, например вызвать некоторый произвольный REST API. Подсистемы обработки потоков потока данных либо не поддерживают эти сценарии, поддерживают их в ограниченном и ограниченном порядке, либо неэффективны в их поддержке. Это связано с тем, что они по сути оптимизированы для большого объема аналогичных элементов, и обычно ограничены с точки зрения экспрессивности, обработки. OrleansПотоки использовать эти другие сценарии.
Мотивация
Все началось с запросов от Orleans пользователей для поддержки возврата последовательности элементов из вызова метода зерна. Как вы можете себе представить, это был только чаевые айсберга. Они нуждались гораздо больше, чем это.
Типичный сценарий для Orleans Потоки заключается в том, что у вас есть потоки для каждого пользователя, и вы хотите выполнить различные обработки для каждого пользователя в контексте отдельного пользователя. У нас могут быть миллионы пользователей, но некоторые из них заинтересованы в погоде и могут подписаться на оповещения о погоде для определенного места, в то время как некоторые заинтересованы в спортивных мероприятиях; кто-то другой отслеживает состояние определенного полета. Для обработки этих событий требуется другая логика, но вы не хотите запускать два независимых экземпляра потоковой обработки. Некоторые пользователи заинтересованы только в определенной акции и только в том случае, если применяется определенное внешнее условие, условие, которое может не обязательно быть частью потоковых данных (и поэтому необходимо проверка динамически во время выполнения в процессе обработки).
Пользователи изменяют свои интересы все время, поэтому их подписки на определенные потоки событий приходят и идут динамически, поэтому топология потоковой передачи меняется динамически и быстро. Поверх этого логика обработки на пользователя развивается и изменяется динамически на основе состояния пользователя и внешних событий. Внешние события могут изменять логику обработки для конкретного пользователя. Например, в системе обнаружения обмана игр, когда новый способ обмана обнаруживает логику обработки, необходимо обновить с помощью нового правила, чтобы обнаружить это новое нарушение. Это необходимо сделать, конечно, без нарушения текущего конвейера обработки. Подсистемы обработки потоков потоков массовых потоков данных не были созданы для поддержки таких сценариев.
Это почти не говорит о том, что такая система должна работать на нескольких сетевых компьютерах, а не на одном узле. Таким образом, логика обработки должна быть распределена масштабируемым и эластичным способом между кластером серверов.
Новые требования
Мы определили 4 основных требования к нашей системе потоковой обработки, которая позволит ему использовать приведенные выше сценарии.
- Гибкая логика потоковой обработки
- Поддержка высокодинамовых топологий
- Детализированная степень детализации потока
- Распределение
Гибкая логика потоковой обработки
Мы хотим, чтобы система поддерживала различные способы выражения логики потоковой обработки. Существующие системы, которые мы упоминание выше, требуют от разработчика написания декларативного графа вычислений потока данных, обычно следуя функциональному стилю программирования. Это ограничивает экспрессивность и гибкость логики обработки. Orleans потоки равнодушны к выражению логики обработки. Его можно выразить как поток данных (например, с помощью реактивных расширений (Rx) в .NET); в качестве функциональной программы; как декларативный запрос; или в общей императивной логике. Логика может быть отслеживанием состояния или без отслеживания состояния, может иметь побочные эффекты и может активировать внешние действия. Все силы переходит к разработчику.
Поддержка динамических топологий
Мы хотим, чтобы система позволяла динамически развивающимся топологиям. Существующие системы, которые мы упоминание выше, обычно ограничены только статическими топологиями, фиксированными во время развертывания и не могут развиваться во время выполнения. В следующем примере выражения потока данных все хорошо и просто, пока не потребуется изменить его.
Stream.GroupBy(x=> x.key).Extract(x=>x.field).Select(x=>x+2).AverageWindow(x, 5sec).Where(x=>x > 0.8) *
Измените пороговое условие в фильтре Where , добавьте инструкцию или добавьте Select другую ветвь в граф потока данных и создайте новый выходной поток. В существующих системах это невозможно без разрыва всей топологии и перезапуска потока данных с нуля. Практически эти системы будут проверка назначить существующие вычисления и смогут перезапуститься с последней проверка точки. Тем не менее, такой перезапуск является разрушительным и дорогостоящим для веб-службы, которая создает результаты в режиме реального времени. Такой перезапуск становится особенно непрактичным, когда речь идет о большом количестве таких выражений, выполняемых с аналогичными , но разными (на пользователях, на устройстве и т. д.) и которые постоянно изменяются.
Мы хотим, чтобы система позволяла развивать граф потоковой обработки во время выполнения, добавляя новые ссылки или узлы в граф вычислений или изменяя логику обработки в вычислительных узлах.
Детализация детализированного потока
В существующих системах наименьшая единица абстракции обычно представляет собой весь поток (топология). Однако во многих наших целевых сценариях требуется отдельный узел или ссылка в топологии, чтобы быть логической сущностью самостоятельно. Таким образом, каждая сущность может быть потенциально управляемой независимо. Например, в топологии большого потока, состоящей из нескольких ссылок, разные каналы могут иметь разные характеристики и могут быть реализованы по разным физическим транспортам. Некоторые ссылки могут переходить по сокетам TCP, а другие — по надежным очередям. Различные ссылки могут иметь разные гарантии доставки. Разные узлы могут иметь разные стратегии проверка назначения, а логика обработки может быть выражена в разных моделях или даже на разных языках. Такая гибкость обычно невозможна в существующих системах.
Единица абстракции и гибкости аналогичен сравнению soA (ориентированных на обслуживание архитектур) и субъектов. Системы субъектов обеспечивают большую гибкость, так как каждый субъект, по сути, является независимо управляемой "крошечной службой". Аналогичным образом, мы хотим, чтобы система потоковой передачи позволяла обеспечить такой точный контроль.
Распределение
И, конечно, наша система должна иметь все свойства "хорошей распределенной системы". Это включает в себя:
- Масштабируемость — поддерживает большое количество потоков и вычислительных элементов.
- Эластичность — позволяет добавлять и удалять ресурсы для увеличения и сжатия на основе нагрузки.
- Надежность — устойчивость к сбоям
- Эффективность — эффективное использование базовых ресурсов
- Скорость реагирования — включение сценариев практически в режиме реального времени.
Это были требования, которые мы имели в виду для создания Orleans потоковой передачи.
Уточнение: Orleans в настоящее время не поддерживает прямое написание декларативных выражений потока данных, как показано в приведенном выше примере. Текущие Orleans API потоковой передачи являются более низкими стандартными блоками, как описано здесь. Предоставление декларативных выражений потока данных является нашей будущей целью.
