Система управления потоками данных

Система управления потоками данных (DSMS) — это компьютерная программная система для управления непрерывными потоками данных . Это похоже на систему управления базами данных (СУБД), которая, однако, предназначена для статических данных в обычных базах данных . СУБД также предлагает гибкую обработку запросов, позволяющую выражать необходимую информацию с помощью запросов. Однако, в отличие от СУБД, DSMS выполняет непрерывный запрос , который не только выполняется один раз, но и устанавливается постоянно. Таким образом, запрос выполняется непрерывно, пока он не будет явно удален. Поскольку большинство DSMS управляются данными, непрерывный запрос дает новые результаты, пока в систему поступают новые данные. Эта базовая концепция аналогична комплексной обработке событий , поэтому обе технологии частично объединяются.

Принцип действия

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

Система управления базами данных (СУБД)	Система управления потоками данных (DSMS)
Постоянные данные (отношения)	Нестабильные потоки данных
Произвольный доступ	Последовательный доступ
Разовые запросы	Непрерывные запросы
(Теоретически) неограниченное вторичное хранилище	Ограниченная основная память
Имеет значение только текущее состояние	Учет порядка ввода
Относительно низкая частота обновления	Потенциально чрезвычайно высокая частота обновления
Небольшие или нулевые требования ко времени	Требования в режиме реального времени
Предполагает точные данные	Предполагает устаревшие/неточные данные
Планируемая обработка запросов	Поступление переменных данных и характеристики данных

Модели обработки и потоковой передачи

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

Синопсисы

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

Окна

Вместо использования синопсисов для сжатия характеристик целых потоков данных оконные методы просматривают только часть данных. Этот подход мотивирован идеей, что актуальными являются только самые последние данные. Поэтому окно непрерывно вырезает часть потока данных, например, последние десять элементов потока данных, и учитывает только эти элементы во время обработки. Существуют различные типы таких окон, например, скользящие окна, похожие на списки FIFO , или переворачивающиеся окна, которые вырезают непересекающиеся части. Кроме того, окна также могут быть разделены на окна, основанные на элементах, например, для рассмотрения последних десяти элементов, или на окна, основанные на времени, например, для рассмотрения последних десяти секунд данных. Существуют также разные подходы к реализации окон. Существуют, например, подходы, которые используют временные метки или временные интервалы для общесистемных окон или окон на основе буфера для каждого отдельного шага обработки. Обработку запросов скользящего окна также можно реализовать в параллельных процессорах за счет использования параллелизма между различными окнами и/или внутри каждого экстента окна. ^[1]

Обработка запросов

Поскольку прототипов много, стандартизированной архитектуры нет. Однако большинство DSMS основаны на обработке запросов в СУБД с использованием декларативных языков для выражения запросов, которые преобразуются в план операторов. Эти планы можно оптимизировать и реализовать. Обработка запроса часто состоит из следующих шагов.

Формулирование непрерывных запросов

Формулировка запросов в основном выполняется с использованием декларативных языков, таких как SQL в СУБД. Поскольку не существует стандартизированных языков запросов для выражения непрерывных запросов, существует множество языков и их вариаций. Однако большинство из них основаны на SQL , например язык непрерывных запросов (CQL), StreamSQL и ESP . Существуют также графические подходы, в которых каждый шаг обработки представляет собой блок, а поток обработки выражается стрелками между блоками.

Язык сильно зависит от модели обработки. Например, если для обработки используются окна, необходимо выразить определение окна. В StreamSQL запрос со скользящим окном для последних 10 элементов выглядит следующим образом:

SELECT AVG(price) FROM examplestream [SIZE 10 ADVANCE 1 TUPLES] WHERE value > 100.0

Этот поток непрерывно вычисляет среднее значение «цены» последних 10 кортежей, но учитывает только те кортежи, цены которых больше 100,0.

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

Оптимизация запросов

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

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

Преобразование запросов

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

Выполнение запросов

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

Примеры

АВРОРА , ^[2] СтримБейс Системс, Инк.
Поток данных Хортонворкс
IBM-потоки
НИАГАРА Механизм запросов ^[3]
NiagaraST: система управления потоками исследовательских данных в Портлендском государственном университете
Odysseus , -фреймворк с открытым исходным кодом Java для систем управления потоками данных.
Конвейерная БД
PIPES. Архивировано 24 декабря 2016 г. в Wayback Machine , webMethods Business Events.
QStream
Обработка потока событий SAS
SQLstream
ТРАНСЛИРОВАТЬ ^[4]
СтримГлобус
СтримИнсайт
ТелеграфCQ ^[5]
Потоковый процессор WSO2

См. также

Ссылки

^ Де Маттейс, Тициано; Менкальи, Габриэле (25 марта 2016 г.). «Параллельные шаблоны для оконных операторов с отслеживанием состояния в потоках данных: алгоритмический скелетный подход» . Международный журнал параллельного программирования . 45 (2): 382–401. дои : 10.1007/s10766-016-0413-x . S2CID 255600 .
^ Абади; и др. Aurora: система управления потоками данных . SIGMOD 2003. CiteSeerX 10.1.1.67.8671 .
^ Цзяньцзюнь Чен; Дэвид Дж. ДеВитт; Фэн Тянь; Юань Ван (2000). «NiagaraCQ: масштабируемая система непрерывных запросов для баз данных Интернета» (PDF) . Кафедра компьютерных наук. Университет Висконсина-Мэдисона . СИГМОД . Проверено 21 ноября 2018 г.
^ Арасу, А. и др. ПОТОК: Стэнфордская система управления потоками данных. Технический отчет. 2004, Стэнфордская информационная лаборатория.
^ «Чандрасекаран, С. и др., «TelegraphCQ: непрерывная обработка потока данных для неопределенного мира». CIDR 2003» (PDF) . Архивировано из оригинала (PDF) 7 февраля 2014 года . Проверено 26 августа 2011 г.

Аггарвал, Чару К. (2007). Потоки данных: модели и алгоритмы . Нью-Йорк: Спрингер. ISBN 978-0-387-47534-9 .
Голаб, Лукаш; Озсу, М. Тамер (2010). Управление потоками данных . Ватерлоо, США: Морган и Клейпул. ISBN 978-1-608-45272-9 .

Внешние ссылки

Обработка потоков информации: от потока данных к обработке сложных событий - обзорная статья о потоках данных и системах обработки сложных событий
Потоковая обработка с помощью SQL . Введение в управление потоковыми данными с помощью SQL.

[1] Де Маттейс, Тициано; Менкальи, Габриэле (25 марта 2016 г.). «Параллельные шаблоны для оконных операторов с отслеживанием состояния в потоках данных: алгоритмический скелетный подход» . Международный журнал параллельного программирования . 45 (2): 382–401. дои : 10.1007/s10766-016-0413-x . S2CID 255600 .

[aurora-2] Абади; и др. Aurora: система управления потоками данных . SIGMOD 2003. CiteSeerX 10.1.1.67.8671 .

[niagaracq-3] Цзяньцзюнь Чен; Дэвид Дж. ДеВитт; Фэн Тянь; Юань Ван (2000). «NiagaraCQ: масштабируемая система непрерывных запросов для баз данных Интернета» (PDF) . Кафедра компьютерных наук. Университет Висконсина-Мэдисона . СИГМОД . Проверено 21 ноября 2018 г.

[StandfordStream-4] Арасу, А. и др. ПОТОК: Стэнфордская система управления потоками данных. Технический отчет. 2004, Стэнфордская информационная лаборатория.

[telegraphcq-5] «Чандрасекаран, С. и др., «TelegraphCQ: непрерывная обработка потока данных для неопределенного мира». CIDR 2003» (PDF) . Архивировано из оригинала (PDF) 7 февраля 2014 года . Проверено 26 августа 2011 г.

[1]

[2]

[3]

[4]

[5]