Введение 4
2 Постановка задачи 6
3 Обзор литературы и аналогов 7
4 Архитектура системы 12
4.1 Архитектура кластера 12
4.2 Архитектура системы на одном сервере 14
5 Сценарии восстановления системы 16
6 Программная реализация 18
7 Заключение 23
Список литературы 24
A Программный код 28
B Инструкция по запуску 46
B.1 Запуск на одной машине 46
B.2 Запуск на кластере 48
В современном мире появляется все больше и больше данных. Начиная со сбора метрик на интернет сайтах для анализа активности пользователей, улучшения дизайна или функциональности и заканчивая данными, получаемыми из сенсоров, GPS сигналов телефонов и так далее [1, 2]. Такой быстрый рост данных порождает различные проблемы, например, как анализировать эти данные [2]. Обычно данные хранятся в источниках, таких как реляционные и нереляционные базы данных. Как правило, аналитические запросы влияют на скорость работы БД, поскольку создают избыточную нагрузку, вследствие чего требуется переместить данные в аналитическое хранилище, прежде чем как-то взаимодействовать с ними [3].
В результате, появляется необходимость в инструменте, способном получать из источника, например, нереляционной базы данных, информацию, трансформировать ее в формат, соответствующий бизнес-требованиям, не нарушая правила конфиденциальности, и затем выгружать в виде файла в хранилище [4]. Такая последовательность действий называется ETL процессом — Extract, Transform, Load, в переводе — “извлечение, преобразование и загрузка”. В целом, процессы ETL позволяют автоматизировать операцию выбора, сбора и обработки данных из хранилища данных, а также производить выходные данные в наилучшем формате для последующей обработки или для задач бизнеса [5, 10].
При этом необходимо, чтобы инструменты по извлечению, преобразованию и загрузке данных могли выполнять свою задачу быстро и надежно. Это приводит к таким понятиям как: отказоустойчивость, “хотя бы один раз” (“at least once”) семантика доставки данных и масштабируемость.
Под отказоустойчивостью предполагается, что приложение является устойчивым к сбоям. Под сбоем понимается отклонение в выполнении одной компонентой системы предназначенных ей задач [6]. Добиться полной отказоустойчивости невозможно, тем не менее вероятность сбоя можно снизить с помощью правильного проектирования механизмов устойчивости к сбоям [6].
Может возникнуть ситуация, когда одна машина выгружает данные, например, какие-либо сообщения, но происходит сбой. В таких случаях система может обеспечивать “хотя бы один раз”, “как максимум один раз”, “ровно один раз” семантики доставки данных [7].
Увеличение нагрузки на систему или ограниченность данных, проходящих через обработку системой, приводит к понятию масштабируемости. Масштабируемость — это способность системы справляться с увеличенной нагрузкой [6]. Один из способов обеспечения масштабируемости является виртуализация, то есть абстрагирование от аппаратной реализации [8].
Итак, процесс выгрузки из источника данных, преобразование этих данных, загрузка в хранилище вместе с обеспечением “хотя бы один раз” семантики доставки, отказоустойчивости и масштабируемости является актуальной задачей в современном мире больших данных
В результате проделанной работы было разработано приложение по многопоточной пакетной выгрузке данных из хранилища MongoDB в распределенное аналитическое хранилище HDFS или в облачное хранилище Amazon S3 с выполнением требований:
— “хотя бы один раз” семантика доставки данных;
— отказоустойчивость;
— автоматическое масштабирование;
— фиксация версии системы в случае изменений конфигураций.
Данная система, находящаяся в открытом доступе, в поставленной задаче является уникальной и обходит аналогичные продукты по одному или более критериям.
