Аннотация

Для приложений, в которых требуется обработка потоков данных большого объема в реальном времени, оказывается ограничительной традиционная инфраструктура обработки данных. Эти основанные на потоках приложения включают обработку потоков рыночных сообщение и поддержку электронных торгов на Уолл-стрит, монироринг сетей и инфраструктур, военное командование и управление. Кроме того, мы ожидаем, что вследствии развития микросенсорсной технологии все существенные материальные предметы на нашей планете будут оснащены сенсорами, сообщающими в реальном времени данные о состоянии предмета или его местоположении. Эта "сенсоризация" реального мира приведет к появлению новых приложений мониторинга и управления с требованиями обработки больших объемов данных с малыми задержками.

В настоящее время появляется несколько технологий - включая готовые к использованию процессоры обработки потоков, - направленных на решение проблем обработки объемных данных в реальном времени без потребности в написании специального кода. В то же время, некоторые существующие софтверные технологии, такие как СУБД, поддерживающие базы данных в основной памяти, (main memory DBMS) и процессоры правил (rule engine), могут быть также "перенацелены" на поддержку таких приложений.

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

В своей статье мы старались быть нейтральными по отношению к конкретным производителям, поэтому не упоминаем какие-либо конкретные коммерческие продукты.

1. Введение

На Уолл-стрит и других мировых биржах объемы электронных торгов возрастают экспоненциально. В потоках рыночных данных каждую секунду генерируются десятки тысяч сообщений. По оценки службы информации о ценах опционов (Options Price Reporting Authority, OPRA), агрегирующей все котировки и сделки, в 2005 г. пиковая скорость генерации сообщений составляла 122,000 сообщений в секунду, и эта скорость ежегодно удваивается [13]. Это существенное возрастание объемов потоков приводит к перегрузке или нарушению функционирования традиционных систем обработки потоков. Кроме того, в области электронных торгов неприемлема задержка даже на одну секунду, и максимальную выгоду приносят торговые операции, поддерживаемые программными средствами, которые наиболее быстро производят результаты. Этот факт обуславливает требования финансовых компаний к обработке очень больших объемов потоковых данных с очень низкой задержкой.

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

К большим переменам ведет развитие микросенсорных технологий. Хотя в настоящее время наибольшее внимание уделяется системам радиочастотной идентификации (Radio Frequency Identification, RFID), имеется множество других технологий, с различными уровнями цен, возможностями и зонами охвата (например, Mote [1] и Lojack [2]). Со временем это приведет к тому, все материально значимые предметы будут оснащены сенсорами, сообщающими в реальном времени об их местоположении и/или состоянии.

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

Со временем приложения основанного на сенсорах мониторинга придут и в невоенные области. Сенсорными устройствами будут снабжаться посетители развлекательных парков для управления аттракционами и предотвращения потерь детей. Более сложные системы "облегченного пропуска" будут поддерживать регулирование движения на автотрассах на основе учета трафика (на это имела воздействие работа с Linear Road Benchmark [5]), а также оптимизацию маршрутов автомашин в столичных районах. Обработка в реальном времени гигантских объемов данных, поступающих от существующих и появляющихся систем мониторинга, представляет основную проблему в области обработки потоков данных, и именно здесь потоковая обработка может принести наибольшую пользу.

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

В настоящее время для использования в этой области приложений перенацеливается несколько традиционных технологий системного программного обеспечения, таких как СУБД, управляющие базами данных в основной памяти, и процессоры правил. Кроме того, возник новый класс системного программного обеспечения - процессоры обработки потоков (Stream Processing Engines, например, Aurora [8], STREAM [4], TelegraphCQ [9]), - поддерживающего приложения потоковой обработки больших объемов данных с малыми задержками.

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

2. Восемь правил потоковой обработки

Правило 1: Сохраняйте данные движущимися

Чтобы достичь низкого уровня задержек, система должна быть в состоянии выполнять обработку сообщений, не прибегая к дорогостоящим операциям с внешней памятью. Операции с памятью существенно увеличивают задержки процесса (например, для фиксации записи в базе данных требуется запись на диск записи журнала). Для многих приложений обработки потоков выполнение такой времяемкой операции до обработки сообщения является неприемлемым и ненужным. Вместо этого, сообщения должны обрабатываться "в потоке", по мере их движения. На рис. 1 приведена архитектурная иллюстрация этой парадигмы сквозной обработки (traight-through processing).

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

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

Правило 2: Формулируйте запросы с использованием SQL на потоках (StreamSQL)

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

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

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

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

Рис. 2. Пример перемещаемого окна.

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

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

Второе требование состоит в поддержке высокоуровневого языка "StreamSQL" со встроенными ориентированными на потоки примитивами и операциями.

Правило 3: Справляться с дефектностью потоков (задержка, отсутствие и нарушение порядка данных)

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

В связи с этим одно из требований состоит в возможности установки тайм-аутов для индивидуальных вычислений. Например, рассмотрим простое бизнес-аналитическое приложение реального времени, которое вычисляет среднюю стоимость после последнего изменения цены для набора из 25 ценных бумаг. Требуется дождаться изменения цены каждой ценной бумаги и потом выдать среднюю стоимость. Однако предположим, что одна из ценных бумаг продается плохо, и ее стоимость не изменяется в течение следующих 10 минут. Это пример вычисления, которое должно блокироваться в ожидании входных данных, требуемых для его завершения. Такие входные данные могут своевременно поступить, а могут и не поступить. В действительности, если SEC (Security Exchange Commission - Комиссия по ценным бумагам) предпишет остановить торги для одной из ценных бумаг, то вычисление будет заблокировано навсегда. В системе реального времени допущение бесконечной блокировки программы никогда не является хорошей идеей. Поэтому любому вычислению, которое может блокироваться, должно быть разрешено устанавливать контрольный интервал времени, тайм-аут, после истечения которого вычисление будет возобновлено над частично доступными данными. В любой системе обработки данных реального времени должны иметься такие тайм-ауты для любой потенциально блокируемой операции.

Аналогичные проблемы возникают в связи с нарушением порядка данных. Обычно окно, определенное на основе времени, (например, [9:00 - 9:01]) должно закрываться при поступлении первого сообщения, значение временной метки которого больше значения верхней границы окна. Однако такое действие основывается на предположении, что данные поступают в порядке своих временных меток, что может быть и не так в данном случае. Для работы с данными, нарушающими порядок, должен обеспечиваться механизм, позволяющий окнам оставаться открытыми в течение дополнительного периода времени. Одно из решений этой проблемы, представленное в Aurora, основывается на понятии резерва времени (slack) [3].

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

Правило 4: Генерируйте предсказуемые результаты

Система потоковой обработки должна обрабатывать сообщения предсказуемым образом, чтобы обеспечивать детерминизм и повторяемость результатов обработки.

Например, рассмотрим два потока, один из которых содержит данные TICKS с полями

TICKS (stock_symbol, volume, price, time)

а другой поток (SPLITS) содержит сообщения о дроблении акций в формате

SPLITS (symbol, time, split_factor)

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

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

Четвертое требование состоит в том, что процессор обработки потоков должен гарантировать предсказуемые и повторяемые результаты.

Правило 5: Интегрируйте хранимые и потоковые данные

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

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

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

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

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

Правило 6: Гарантируйте безопасность и доступность данных

Для сохранения целостности критически важной информации и во избежание нарушений обработки в реальном времени система потоковой обработки должна основываться на решении с высоким уровнем доступности (high-availability, HA).

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

Поэтому наилучшим выбором для таких типов приложений является схема горячего резервирования и переключения в реальном времени "в стиле Tandem" [6], при использовании которой вторичная система часто синхронизует свое состояние с первичной системой и вступает в действие при выходе из строя первичной системы. Модель HA показана на рис. 3.

Шестое требование состоит в том, что приложения должны быть работоспособными и доступными, а данные - всегда целостными независимо от наличия сбоев.

Правило 7: Автоматически разделяйте и масштабируйте приложения

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

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

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

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

Правило 8: Мгновенно обрабатывайте и выдавайте результаты

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

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

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

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

3. Технологии системного программного обеспечения для потоковой обработки

3.1 Базовые архитектуры

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

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

  На рис. 4(i) проиллюстрирована базовая архитектура СУБД. Потоковые данные поступают в СУБД напрямую или через загружающее их приложение. Данными, поддерживаемыми СУБД, может манипулировать набор приложений. Клиент может использовать эти заранее построенные приложений, часто с параметрами, задаваемыми во время выполнения, а также может написать новые приложения на языках общего назначения, таких как C++ или Java, используя встраиваемые SQL-вызовы СУБД.

• Процессоры правил появились в начале 1970-х, когда в сообществе искусственного интеллекта были предложены системы PLANNER и Conniver. Позже более распространенным процессором был Prolog (1980-е), и имеется несколько более свежих примеров (например, OPS5 [7]). Процессор правил обычно принимает пары "условие/действие", выражаемые, как правило, в нотации "if-then", наблюдает за входным потоком на предмет выполнения условий и затем выполняет соответствующие действия. Другими словами, процессор правил приводит в исполнение набор правил, хранимых в базе правил.

  На рис. 4(ii) проиллюстрирована модель процессора правил для потоковой обработки. База правил обеспечивает долговременное хранение правил. Как только потоковые данные поступают в систему, они немедленно сопоставляются с существующими правилами. При обнаружении их соответствия условию правило, как говорится, "загорается". Соответствующее(ие) действие(я) затем может(гут) произвести сигналы/данные для внешних приложений и просто модифицировать состояние внутренних переменных, что может привести к "зажиганию" другого правила.

• Процессоры потоковой обработки (Stream Processing Engines, SPE) специально разрабатываются для работы с потоковыми данными и в последнее время привлекают внимание в качестве третьей альтернативы. Их базовая архитектура показана на рис. 4(iii).

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

Рис. 4. Базовые архитектуры (i) системы баз данных, (ii) процессора правил и (iii) процессора потоковой обработки

Далее мы произведем краткую оценку этих систем на основе требований, представленных в разд.2.

3.2 Насколько они отвечают требованиям?

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

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

Язык SQL разрабатывался для работы с хранимыми данными конечного объема, и поэтому требуется его расширить для работы с потенциально неограниченными потоками данных. SQL/Temporal все еще находится в младенческом состоянии, и в реализациях SQL поставщиками СУБД поддерживаются только рудиментарные средства оконных операций (т.е. сортировка и агрегация). Языки правил также нуждаются в аналогичных расширениях, чтобы они могли выражать условия во времени. Более того, в языках правил требуется введение понятия агрегирования, распространенной операции во многих потоковых приложениях. Следовательно, SPE поддерживают SQL-стиль обработки потоков, а СУБД и процессоры правил - не поддерживают.

В процессорах правил и SPE можно закодировать операции, которые могут блокироваться. Потому в любой реализации этих систем нужно поддерживать тайм-ауты. В решении СУБД приложения должны явно определять свое поведение опроса для имитации эффектов тайм-аутов и получения частичных данных. С другой стороны, в системе триггеров СУБД отсутствует очевидный способ установки тайм-аутов. Аналогичные проблемы для СУБД порождает и работа с данными, поступающими не в требуемом порядке. В целом, работать с дефектными потоками гораздо проще при применении процессоров правил и SPE, чем СУБД.

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

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

В отличие от этого, процессор правил может эффективно поддерживать данные движущимися, но у него имеются проблемы с сохранением состояния. Причина состоит в том, что в процессоре правил для хранения используются локальные переменные, и отсутствует простой способ запроса данных из локальных переменных. Чтобы справляться с большими объемами данных о состоянии, нужно каким-то образом пересадить встроенную СУБД в процессор правил. В этом случае станет необходимо переключиться с парадигмы локальных переменных на парадигму СУБД, что совсем неестественно. Следовательно, процессор правил плохо подходит для хранения существенных объемов информации о состоянии. С другой стороны, SPE должен обладать возможностью поддержки бесшовной интеграции потоковых и хранимых данных с помощью простого переключения области видимости команд StreamSQL с реального потока на хранимую таблицу.

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

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

3.3 Результаты в табличной форме

В таблице 1 мы подводим итоги приведенного обсуждения. Каждый элемент таблицы содержит одно из четырех значений:

• Да: Архитектура естественным образом поддерживает данное требование.
• Нет: Архитектура не поддерживает данное требование.
• Возможно: Архитектура может поддерживать данное требование. Требуется спрашивать у поставщиков конкретных продуктов.
• Затруднительно: Архитектура может поддерживать данное требование, но это затруднительно, поскольку требуются нетривиальные модификации. Требуется спрашивать у поставщиков конкретных продуктов.

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

4. ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ

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

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

Литература

[1] Crossbow Technology Inc., 2005. http://www.xbow.com/.
[2] Lojack.com, 2005. http://www.lojack.com/.
[3] D. Abadi, D. Carney, U. Cetintemel, M. Cherniack, C. Convey, S. Lee, M. Stonebraker, N. Tatbul, and S. Zdonik. Aurora: A New Model and Architecture for Data Stream Management. VLDB Journal, 2003.
[4] A. Arasu, B. Babcock, S. Babu, M. Datar, K. Ito, I. Nizhizawa, J. Rosenstein, and J. Widom. STREAM: The Stanford Stream Data Manager. In ACM SIGMOD Conference, June 2003.
[5] A. Arasu, M. Cherniack, E. Galvez, D. Maier, A. Maskey, E. Ryvkina, M. Stonebraker, and R. Tibbetts. Linear Road: A Benchmark for Stream Data Management Systems. In Very Large Data Bases (VLDB) Conference, Toronto, CA, 2004.
[6] J. Barlett, J. Gray, and B. Horst. Fault tolerance in Tandem computer systems. Tandem Computers TR 86.2., 1986.
[7] L. Brownston, R. Farrell, E. Kant, and N. Martin, Programming Expert Systems in OPS5: Addison-Wesley, 1985.
[8] D. Carney, U. Cetintemel, M. Cherniack, C. Convey, S. Lee, G. Seidman, M. Stonebraker, N. Tatbul, and S. Zdonik. Monitoring Streams: A New Class of Data Management Applications. In proceedings of the 28th International Conference on Very Large Data Bases (VLDB'02), Hong Kong, China, 2002.
[9] S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M. Hellerstein, W. Hong, S. Krishnamurthy, S. R. Madden, V. Raman, F. Reiss, and M. A. Shah. TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. In Proc. of the 1st CIDR Conference, Asilomar, CA, 2003.
[10] E. F. Codd. Does your DBMS run by the rules? ComputerWorld, October 21, 1985.
[11] E. F. Codd. Is your DBMS really relational? Computerworld, October 14, 1985.
[12] E. F. Codd. Providing OLAP to User-Analysts: An IT Mandate. Codd and Associates, Technical Report 1993.
[13] J. P. Corrigan. OPRA Traffic Projections for 2005 and 2006. Technical Report, Options Price Reporting Authority, Aug, 2005. http://www.opradata.com/specs/projections_2005_2006.pdf.