Паттерны архитектуры ПО в инженерии данных
Философия дизайна, стоящая за потрясающими технологиями больших данных
Что делает технологии больших данных масштабируемыми, доступными, устойчивыми к ошибкам, производительными, надежными и т.д.? Скорее всего, ответ на данный вопрос спрятан в архитектуре технологий больших данных. Без серьезной философии проектирования разработка удивительных технологий, которые так легко обрабатывают данные в таком масштабе, была бы сложной задачей. Итак, давайте посмотрим на архитектуры популярных технологий обработки данных. В большинстве случаев бизнес-решения принимаются на основе данных. В результате инженерия данных имеет решающее значение и выполняется с использованием технологий, перечисленных ниже.
- Apache Hadoop
- Apache Spark
- Apache Hive
- Presto
- Apache Kafka
- Apache Airflow
- Бессерверные вычисления (функционируют, как сервис, например, AWS Lambda)
- Tableau или Grafana или другие технологии визуализации данных
Все эти технологии широко применяются в индустрии. Обработка больших данных осуществляется в следующих трех различных режимах.
- Пакетная обработка, при которой фрагменты данных подходящего размера обрабатываются с определенной периодичностью
- Режим реального времени, когда данные обрабатываются, как только они поступают в систему.
- Гибридный режим, комбинация 2 подходов.
Некоторые продукты обработки данных дают результаты один раз в день, их можно создавать с помощью пакетного подхода. Другим могут потребоваться результаты в реальном времени или почти в реальном времени, например, поиск 10 лучших хэштегов каждые 10 минут в Твиттере.
В результате изучения технологий больших данных, перечисленных выше, было замечено, что они разрабатываются с учетом 3 подходов к обработке данных и шаблонов доступа к данным, которые в основном представляют собой SQL, API и визуализацию. Можно сказать, что эти технологии данных основаны на философии дизайна. Эта философия проектирования привела к разработке различных архитектурных шаблонов в технологиях данных, которые кратко описаны ниже.
- Многоуровневая архитектура
- Актор-реактор архитектура
- Микроядро или архитектура плагинов
- Архитектура микросервисов
- Архитектура, управляемая событиями
Давайте изучим каждую из этих архитектур и постараемся найти ответ на наш вопрос.
Многоуровневая архитектура
В данном случае технология разделена на несколько уровней , где каждый уровень выполняет определенную роль в технологии/ПО, а коммуникация идет от одного уровня к другому. Как правило, присутствует более 2 уровней, как показано на диаграмме ниже.
Как показано на диаграмме, пользователи взаимодействуют с уровнем пользовательского интерфейса, инструкции из уровня пользовательского интерфейса передаются на прикладной уровень, где применяются бизнес-правила. Затем прикладной уровень обращается к уровню хранения данных для чтения/записи/обновления/удаления данных. И коммуникация идет в обратном порядке, чтобы ответить пользователю. Структура MVC (Model-View-Controller) основана на подходе многоуровневой архитектуры.
Преимуществами этого паттерна являются простота и разделение проблем между уровнями, но тесная связь уровней, масштабируемость и количество уровней представляют собой определенную опасность.
Пример: Apache Hive
Пользователь отправляет запрос Hive через уровень запросов (или пользовательский интерфейс — уровень 1), затем запрос попадает на уровень обработки (уровень 2), где создаются задания MapReduce, уровень MapReduce связывается со слоем данных (например, HDFS — уровень 3) для получения данных, а затем выполняются вычисления и передаются обратно пользователю.
Пример: Tableau
Он также построен по принципам многоуровневой архитектуры. У него есть уровни пользовательского интерфейса, обработки данных и коннекторов данных.
Кластерная архитектура
В первую очередь стоит отметить, что в данном случае речь идет именно о паттерне, а не о классически воспринимаемом физическом кластере из нескольких машин. Данный паттерн работает, как машина, у которой есть мастер (Actor) и сегменты (Reactor). Мастер отвечает за принятие решения, сегмента – за его исполнение. Как правило, мастер представлен в единственном числе, сегментов может быть несколько. Проще говоря, мастер - командир , а сегменты – исполнители команд.
В данном паттерне мастер делегирует задачи. Плюсами является масштабируемость и производительность, однако это порождает такую проблему, как Единая точка отказа (SPoF). Согласно SPoF, в случае если, мастер терпит неудачу, провален весь процесс.
Пример: Apache Spark
Spark спрограммирован с помощью кластерной архитектуры. Узел драйвера - мастер , рабочие узлы - сегменты. Рабочие узлы задействованы для выполнения задания, отправленного драйверу пользователем.
Пример: Hadoop Distributed File System (HDFS)
HDFS – это также пример кластерной архитектуры. Процесс драйвера является мастером, а наборы данных- сегментами. Здесь очень хотелось бы отметить одну важную особенность - вторичный узел, который задействован в случае сбоя первичного узла. Таким образом, у HDFS есть защита от SPoF . Вторичный узел обеспечивает устойчивость к ошибкам.
Микроядро или архитектура плагинов
Микроядро или архитектура плагинов – это паттерн, где основная функциональность отделена от плагинов. Этот паттерн можно сравнить с процессом приготовления пиццы. Основа пиццы (или тесто для пиццы) обычно готовится отдельно и хранится в готовом состоянии, поскольку это ключевой компонент пиццы. Дополнительные слои, топпинги добавляются в соответствии с пожеланиями клиента. В микроядре или архитектуре плагинов, основа (или мироядро) – основной компонет, а плагины добавляются пользователями с целью внедрить необходимую функциональность. Необходимо особо отметить тот факт, что микроядро должно быть маленьким, то есть минималистом, и поставляться с соответствующей базовой функциональностью, а также возможностью совместной работы и координации с любым из плагинов.
Архитектура плагинов упрощает разработку, усовершенствование и поставку программного обеспечения, поскольку ядро и плагины могут разрабатываться и поставляться независимо друг от друга. Проблема этого паттерна заключается в чрезмерном использовании плагинов. Если используется большое количество плагинов, программное обеспечение становится достаточно ресурсоемким.
Пример: Apache Spark
Apache Spark является хорошим примером архитектуры плагинов. Основа Spark – микроядро, а Spark SQL, Spark Streaming, GraphX и Spark ML lib – плагины, которые задействуют основу.
Пример: Docker
Docker также может быть отнесен к архитектуре плагинов. Разработчики создают приложение, используя базовый образ, а затем добавляют дополнительные требования для разработки конечного продукта.
Архитектура микросервисов
Данный паттерн — это еще один архитектурный стиль, в котором технология/продукт/приложение/программное обеспечение разрабатываются с применением набора сервисов, которые меньше по размеру, соединены в свободном порядке, независимы и поддерживаются по отдельности. Продукт/программное обеспечение можно разделить на микросервисы, основанные на различных атрибутах, например возможностях или функциях, доменов или поддоменов и т. д.
На очень высоком уровне, на веб-сайте электронной коммерции одна служба может управлять страницей поиска, вторая - страницей продукта, третья может выполнять действия, связанные с оформлением заказа, а четвертая может использоваться для аутентификации пользователя. И каждый из сервисов высокого уровня может быть дополнительно разделен на микросервисы, которые отвечают за набор действий на этих сервисах. Существует множество преимуществ создания микросервисов, например:
- Меньшая кодовая база
- Простота разработки и управления
- Гибкость
- Независимость
- Меньшие потребности в ресурсах
- Масштабируемость
- Доступность
- Разъединенность
Взаимодействие микросервисов в основном осуществляется с использованием программного интерфейса программирования (API), т. е. на основе HTTP(S) и REST. Проблемы микросервисов: а) взаимодействие микросервисов б) управление микросервисами, когда их количество растет. Паттерн может быть представлен следующим образом.
- Cервис оплаты не зависит от сервиса аутентификации.
- В Amazon сервис рекомендаций по продуктам должен быть независимым от службы, проверяющей доставку по почтовому индексу. И это, возможно, два отдельных (микро)сервиса.
- В Netflix служба видеоаналитики не зависит от службы потокового видео. И то, и другое важно для бизнеса Netflix.
Команды инженеров данных посатвляют информацию бизнесу и другим пользователям. Информация сфокусирована на путешественниках, бизнес-транзакциях и т. д. Данные вводятся в систему с помощью соответсвующих микросервисов, а затем обрабатываются с помощью микросервисов для предоставления информации. Функция как сервис (FaaS) также используется для разработки микросервисов, которые освещены в следующем разделе.
Архитектура, управляемая событиями
Из самого названия следует, что в данном паттерне событие/действие/сообщение является центральной частью парадигмы. Ключевые составляющие части паттерна следующие:
- Эмитент - это тот, кто инициирует событие, выполняет какое-либо действие или передает сообщение. Эмитента также называют продюсером или издателем.
- Канал является проводником или хранилищем сообщений. Канал также называется сервером, брокером или маршрутизатором. Канал также имеет возможность сохранять события.
- Потребитель — это читатель сообщений или процессор. Потребитель имеет и другие названия: приемник, подписчик.
Когда покупатели совершают покупки на веб-сайте или в мобильном приложении, они выполняют некоторые действия, такие как поиск продукта, просмотр продукта, покупка продукта и т. д. Эти действия также называются действиями, совершаемыми покупателями. Эти действия или события передаются бизнесу \ через API. Таким образом, компания является потребителем событий. Упрощенная архитектура выглядит следующим образом:
Преимущества этого архитектурного шаблона включают: а) разделение, б) масштабируемость, в) гибкость, г) оптимизация затрат, поскольку в данном случае все происходит по требованию, д) доступность и е) производительность. Однако слабая связь и асинхронное поведение делают этот архитектурный шаблон несогласованным, трудным для тестирования и обслуживания. Данный архитектурный шаблон лучше всего подходит, когда продюсеры не ждут потребителей. Как только продюсеры отправляют сообщение, они считают, что сообщение обязательно достигнет потребителя в какой-то определенный момент времени. Сегодня существует множество технологий, которые следуют этой парадигме.
Пример: RabbitMQ
Это технология, основанная на очереди, когда продюсеры отправляют сообщения в очередь, которую затем читают потребители. Как только сообщение прочитано потребителем, оно удаляется из очереди.
Пример: Apache Kafka
Apache Kafka — хорошо известный проект в составе проектов Apache. В отличие от системы, основанной на очередях, Apache Kafka представляет собой систему, основанную на журналах, что означает, что как только сообщение поступает в брокер, оно сохраняется в соответствии с политикой хранения. также является отличным примером обработки онлайн-платежей с использованием Apache Kafka.
Пример: безсерверные вычисления или функция как услуга (например, AWS Lambda, облачные функции Google, функции Microsoft Azure).
FaaS также хорошо вписывается в архитектурный шаблон, управляемый событиями. Первый миф, который необходимо развеять, заключается в том, что отсутствие серверов не означает, что вычислительные ресурсы обходятся без серверов. Сервера есть, но по запросу. В соответствии с безсерверной обработкой, как только событие необходимо обработать, приложение или функция включаются для выполнения обработки и закрываются после ее завершения.
С помощью этого исследования можно сделать вывод о том, что при планировании, разработке или совершенствовании платформы данных или аналогичного продукта используемая технология данных определяется ожиданиями клиентов (почему?), вводом данных (что?), обработкой данных ( как?) и доступом к данным (где?). Технологические факторы, такие как связность, масштабируемость, доступность, отказоустойчивость, производительность, надежность и возможность самовосстановления также имеют жизненно важное значение при создании фантастических платформ данных и продуктов.
