Системы потоковой обработки
Платформы, которые мы успели рассмотреть (MapReduce, Spark, GraphLab), в основном предназначены для выполнения пакетных вычислений. Их входные данные обычно представляют собой большие распределенные наборы данных, которые обрабатываются в течение нескольких часов и дают большой, полезный результат. Изначально такими платформами пользовались только специалисты по обработке и анализу данных и программисты, которые применяли их для выполнения конкретных больших запросов в ситуациях, допускающих большую задержку. Однако в связи с тем, что все больше предприятий начинают работать с большими данными, запросы данных стали оперативными, а допустимая задержка сократилась с часов до минут. Такие средства, как Pig, Hive, Shark и Spark SQL, позволяли многим выполнять сложные операции с собственными данными, обходясь без большого штата хорошо обученных программистов. Облачные технологии ускорили развитие этой тенденции, обеспечив эластичное предоставление вычислительных ресурсов на время выполнения оперативного запроса.
В ближайшее время требования к задержкам станут еще более строгими. Большие данные стали поступать в режиме реального времени и часто они полезны только в течение короткого периода времени. Например, поисковые системы требуют, чтобы оптимальные объявления подбирались в течение нескольких миллисекунд после каждого запроса. Веб-сайты социальных сетей отслеживают тенденции и популярные темы и хэштеги, а инструменты системного мониторинга выявляют сложные закономерности в разных компонентах крупных инфраструктур. Для сокращения задержки до необходимого уровня начал формироваться новый класс платформ потоковой обработки. Требования и ограничения таких платформ в корне отличаются от систем пакетной и интерактивной обработки, которые существовали ранее.
В результате появились системы потоковой обработки.
Потоковая обработка
Потоковая обработка означает применение последовательности операций к каждому элементу данных, который поступает из бесконечного источника входных данных. Такая последовательность операций обычно помещается в конвейер, так что между операциями возникают зависимости. В приложении обработки сведения о состоянии часто считываются из небольшого и быстрого источника данных и записываются в такой источник. Выходные данные конвейера потоковых операций также являются потоком данных. Их можно использовать для активации других приложений или помещать в буфер и хранить в стабильном хранилище. Ниже показана базовая концептуальная архитектура такой системы.
Рис. 6. Система потоковой обработки должна обрабатывать данные в потоке с отдельным конвейером для хранения при необходимости, который не лежит на "критическом пути"
Восемь правил потоковой обработки
Стоунбрейкер (Stonebraker) с соавт. описали восемь основных правил для систем потоковой обработки.
Правило 1. Сохранение перемещения данных
Платформа потоковой обработки в режиме реального времени должна иметь возможность обрабатывать сообщения в потоке, не сохраняя их на диск, чтобы избежать недопустимой задержки в критическом пути. Кроме того, такие системы должны быть активны (управляться событиями), а не пассивными (когда приложениям приходится запрашивать результаты для выявления интересующих их состояний).
Рис. 7. Система потоковой обработки должна обрабатывать данные в потоке с отдельным конвейером для хранения при необходимости, который не лежит на "критическом пути"
Правило 2. Потоки должны поддерживать запросы с помощью SQL
SQL — широко применяемый и привычный стандарт для запроса данных. При этом традиционный SQL работает с фиксированным объемом данных, когда на то, что запрос выполнен, указывает достижение конца таблицы. В сценариях потоковой передачи данные постоянно нарастают. Стоунбрейкер (Stonebraker) с соавт. говорят о необходимости языка StreamSQL, позволяющего определять объем запроса по временным скользящим окнам переменной длины. Окна можно определять, используя время, количество сообщений или любые другие произвольные параметры. Для объединения сообщений из нескольких потоков могут требоваться дополнительные операторы.
Рис. 8. StreamSQL должен обрабатывать подмножества данных и разрешать выражения связей в окнах
Правило 3. Обработка несовершенных потоков
В системах реального времени данные могут теряться, опаздывать или поступать не в том порядке. Система потоковой обработки не может ждать данные бесконечно, но при этом не быть достаточно гибкой для того, чтобы игнорировать или пропускать какие-то данные. Такие системы должны быть устойчивы к несовершенствам потоков. Этого позволяют добиться такие механизмы, как настраиваемое время ожидания и резервное время, в течение которого могут быть приняты запоздавшие данные.
Правило 4. Создание прогнозируемых результатов
Выходные данные любой системы потоковой обработки должны быть детерминированными и повторяемыми при воспроизведении того же потока. Этого особенно трудно добиться, когда система работает в нескольких параллельных потоках или когда сообщения поступают в неупорядоченном виде. Сообщения должны обрабатываться в порядке времени их отправления, независимо от времени прибытия. Это свойство также обеспечивает отказоустойчивость, поскольку позволяет воспроизводить потоки, в которых произошел сбой обработки.
Правило 5. Интеграция сохраненного состояния
Приложениям потоковой обработки часто приходится объединять настоящее с прошлым. Например, для рекомендации пользователю определенного объявления поисковая система должна объединить текущие сведения о поисковом запросе и текущее состояние рынка рекламы с информацией о прошлых переходах пользователя. Интеграция сохраненного состояния и потоковой передачи данных также обеспечивает бесперебойное переключение, при котором алгоритм можно протестировать на исторических данных, а затем, убедившись, что он работает нормально, переключить на динамический поток. Данные должны храниться в том же адресном пространстве, что и приложение (возможно, за счет применения внедренной базы данных), что позволяет использовать единый язык, работающий с хранимыми и потоками данных.
Правило 6. Обеспечение высокого уровня доступности
Системы потоковой обработки работают в режиме реального времени и часто не допускают восстановление с перезапуском. Такие системы должны разрешать горячее переключение на резервную или теневую копию, которую необходимо регулярно синхронизировать с основной базой данных. Целостность данных необходимо гарантировать в соответствии с правилом 4.
Правило 7. Поддержка секционирования и автоматического масштабирования
Распределенная обработка — это стандартная модель работы для всех таких крупных систем. Хорошая архитектура потоковой обработки должна не допускать блокировки и использовать современные многопоточные архитектуры. Кроме того, она должна иметь возможность самостоятельно увеличивать или уменьшать масштаб системы, добавляя или удаляя компьютеры при увеличении или уменьшении объема данных или в случае задержек или проблем с обработкой. Плюс она должна автоматически и прозрачно распределять нагрузки между доступными компьютерами. Конечный пользователь не должен решать ни одного из таких вопросов.
Правило 8. Убедитесь, что он может поддерживаться
Все компоненты системы должны быть рассчитаны на высокую производительность, так чтобы лишь минимальное число операций выходило за ее пределы. Систему необходимо проверить и протестировать, исходя из целевой рабочей нагрузки, убедиться в том, что целевые показатели по пропускной способности и задержки достигаются.
Эволюция систем потоковой обработки
Одной из первых систем потоковой обработки стала Aurora (2002), также разработанная Стоунбрейкером и др. в MIT и Brown University. Aurora решала проблему потоковой обработки как направленный ациклический граф (DAG).
Входные данные потока — это последовательность неограниченных кортежей (1,2,...,n) в динамике, которые передаются из вышестоящего объекта (старт) в нижестоящий (выходные данные). Все приложение можно построить, добавляя различные комбинации блоков обработки и рисуя связи между ними. Aurora — система с одним узлом, не выполнявшая многие требования к масштабируемости системы потоковой обработки. Для объединения различных узлов Aurora в единую сеть была создана новая версия этой системы под названием Aurora* (2003). В этой системе масштабируемость достигалась за счет секционирования различных стадий задания потоковой обработки между различными физическими узлами. Впоследствии появился также проект Medusa (2003), который добавил Aurora поддержку федерации и обеспечил совместную работу и обмен данными между несколькими пользователями.
Следующим дополнением к проекту Aurora стал Borealis (2005), который обеспечил высокий уровень доступности за счет активной репликации. Для обеспечения согласованности данных реплики тщательно синхронизировались.
Apache Storm (2011) — это обработчик потоковой обработки, разработанный X. Здесь узлы обработки (Bolts) могут подписываться на потоки из разных источников (spouts), тем самым обеспечивая простую модель вычислений подписчика. Storm гарантирует обработку сообщений независимо от сбоев на узлах и обеспечивает семантику единственной доставки, которая гарантирует, что данные не будут ни пропущены, не учтены больше одного раза. Yahoo! разработала аналогичную абонентскую систему под названием Apache S4 (2011). С расчетом на масштабируемость систему сделали симметричной в том смысле, что все узлы равны и никакого централизованного контроля нет. S4 не поддерживала динамическое добавление узлов в работающий кластер и удаление узлов из такого кластера. Еще одна многоканальная система в этой группе — Apache Samza (2013). Ее мы рассмотрим более подробно.
Storm, Samza и S4 следуют традиционной потоковой модели, которую можно описать как обработка записей по одной за раз. В этой модели операторы с отслеживанием состояния обрабатывают поступающие записи, изменяют внутреннее состояние в соответствии с новыми данными и выдают новые записи. Отказоустойчивость и восстановление осуществляются за счет репликации, либо путем создания нескольких копий элементов обработки, либо путем буферизации и сохранения резервных копий сообщений в вышестоящем источнике и их повторной отправки вниз в случае отказа. Кроме того, поскольку макет DAG со временем становится сложнее, обеспечить согласованность между разными путями непросто. Наконец, объединение этих платформ с пакетными системами — задача нетривиальная, и часто она выполняется с применением лямбда-архитектуры (см. ниже).
Другой подход к проектированию систем потоковой обработки предлагает Spark Streaming (2012) — систему "микропакетной обработки". Микропакетная обработка преобразует потоковые вычисления в набор чрезвычайно быстрых вычислений с задержками от сотен миллисекунд до нескольких секунд. Чем больше задержка, тем легче обеспечить отказоустойчивость и семантику единственной доставки для результатов каждого микропакета.
Выбор оптимальной платформы для использования в задаче зависит от ожидаемой задержки, отказоустойчивости и гарантии доставки сообщений, а также от уровня квалификации пользователей и предполагаемых затрат на разработку. В следующем уроке мы рассмотрим внутренние компоненты этих платформ более подробно, изучив Apache Samza.