Это хорошее предложение, на первый взгляд. По сути, мы так и сделали, но вместо HDFS используем общий S3.
Данные загружаются конечными пользователями — примерно 30-50 ГБайт в день (объем увеличивается с ростом пользовательской базы). К текущему моменту у нас порядка 22 ТБайт исходных данных.
Кроме визуализации, описанной в статье, данные подвергаются другим видам преобразований для последующего анализа — на отдельных воркерах. Некоторые из этих преобразований задействуют GPU, другие — кастомные библиотеки из мира mass spectrometry. К текущему моменту у нас около 12 ТБайт частично преобразованных данных, использующихся для разных видов анализа. Они хранятся на S3, доступ к ним производится со своих узлов-воркеров в random access-режиме.
«Сырые» данные, которые мы храним, должны выдерживать проверку временем. Загрузив файлы сегодня, пользователь должен иметь возможность работать с ними и через пять лет. То есть, любые креши узлов HDFS, потенциально приводящие к потерям, для нас являются уязвимостью. Amazon S3, в свою очередь, дает гарантии безотказности (если не использовать reduced redundancy). Из дополнительных бесплатных плюшек — удобный и безопасный аплоад на S3 прямо с клиента (если интересно — могу описать в следующей статье).
Вдобавок, пользователи всегда могут попросить свои «сырые» данные назад — на download.
Поэтому мы вынуждены иметь централизованное хранилище для «сырых данных», подходящее для доступа из внешнего мира (download) и со всех инстансов-воркеров (random access, partial download). Это выходит дешевле, чем поддержка HDFS-кластера, имплементация доступа к данным на HDFS из внешнего мира и дополнительные расходы на резервное копирование в условиях постоянно пополняющегося набора файлов от конечных пользователей.
Кажется, я ответил на Ваш вопрос. Простите, если немного сумбурно — общий контекст приложения сложно описать в нескольких абзацах.
Да. Лично мне вообще очень нравится Apache Spark. Но алгоритм по обработке задачи содежит вызовы проприетарных библиотек заказчика, и потому плохо адаптируется под Spark.
Spark хорошо подходит для создания классификаторов данных; его мы начинаем использовать для других задач в пределах этого же проекта.
А Docker переживал свое раннее детство в момент имплементации решения (этот модуль появился два с небольшим года назад). Кроме того, EC2 и в данный момент немного легче с точки зрения maintenance, если остальная часть решения хостается на EC2.
Общего решения, к сожалению не существует. В зависимости от размера проекта (как по количеству кода, так и по количеству разработчиков) применимы разные подходы.
скорость (при использовании такой прослойки как equinox все операции взаимодействия между модулями приложения будут по определению медленнее, чем без использования такой прослойки. Насколько это замедляет приложение на практике сказать сложно — необходимо тестирование).
На практике использование только Equinox на производительности сказывается немного. Другое дело, что сам по себе Equinox особо удобно не поиспользуешь — слишком много кода для интеграции приходится писать. Частым вариантом является связка Equinox + Spring Dynamic Modules + Spring Framework. И вот здесь уже понятно, что работает это все довольно медленно. К сожалению, потому что концептуально все выглядит неплохо.
К примеру, говоря о JSF и Facelets: вполне легальным случаем использования является хранение параметризуемых частей XHTML-страниц в библиотеках. Это, конечно, не дает возможности полностью избежать копи-паста, но, тем не менее, существенно сокращает количество кода, повторяющегося из проекта в проект. Характерный пример — функциональность login/logout.
Ощущение, что это даже не более общее понятие. Это просто нечто другое:
http://en.wikipedia.org/wiki/Front-end#Computer_science
Но это, в общем, придирки... А за проделанную работу - респект.
Первая часть - собственно, "Хоббит", вторая - события, разделяющие "Хоббита" и "Властелина Колец": рождение Арагорна, помолвка Арагорна и Арвин, захват Дол-Гулдура войсками Светлого Совета и т.п.
Кроме указанных минусов — это действительно дороже. Минимум в два раза (посчитал на 1000 ГБ) — даже если использовать general storage, а не SSD.
Данные загружаются конечными пользователями — примерно 30-50 ГБайт в день (объем увеличивается с ростом пользовательской базы). К текущему моменту у нас порядка 22 ТБайт исходных данных.
Кроме визуализации, описанной в статье, данные подвергаются другим видам преобразований для последующего анализа — на отдельных воркерах. Некоторые из этих преобразований задействуют GPU, другие — кастомные библиотеки из мира mass spectrometry. К текущему моменту у нас около 12 ТБайт частично преобразованных данных, использующихся для разных видов анализа. Они хранятся на S3, доступ к ним производится со своих узлов-воркеров в random access-режиме.
«Сырые» данные, которые мы храним, должны выдерживать проверку временем. Загрузив файлы сегодня, пользователь должен иметь возможность работать с ними и через пять лет. То есть, любые креши узлов HDFS, потенциально приводящие к потерям, для нас являются уязвимостью. Amazon S3, в свою очередь, дает гарантии безотказности (если не использовать reduced redundancy). Из дополнительных бесплатных плюшек — удобный и безопасный аплоад на S3 прямо с клиента (если интересно — могу описать в следующей статье).
Вдобавок, пользователи всегда могут попросить свои «сырые» данные назад — на download.
Поэтому мы вынуждены иметь централизованное хранилище для «сырых данных», подходящее для доступа из внешнего мира (download) и со всех инстансов-воркеров (random access, partial download). Это выходит дешевле, чем поддержка HDFS-кластера, имплементация доступа к данным на HDFS из внешнего мира и дополнительные расходы на резервное копирование в условиях постоянно пополняющегося набора файлов от конечных пользователей.
Кажется, я ответил на Ваш вопрос. Простите, если немного сумбурно — общий контекст приложения сложно описать в нескольких абзацах.
Spark хорошо подходит для создания классификаторов данных; его мы начинаем использовать для других задач в пределах этого же проекта.
А Docker переживал свое раннее детство в момент имплементации решения (этот модуль появился два с небольшим года назад). Кроме того, EC2 и в данный момент немного легче с точки зрения maintenance, если остальная часть решения хостается на EC2.
На практике использование только Equinox на производительности сказывается немного. Другое дело, что сам по себе Equinox особо удобно не поиспользуешь — слишком много кода для интеграции приходится писать. Частым вариантом является связка Equinox + Spring Dynamic Modules + Spring Framework. И вот здесь уже понятно, что работает это все довольно медленно. К сожалению, потому что концептуально все выглядит неплохо.
К примеру, говоря о JSF и Facelets: вполне легальным случаем использования является хранение параметризуемых частей XHTML-страниц в библиотеках. Это, конечно, не дает возможности полностью избежать копи-паста, но, тем не менее, существенно сокращает количество кода, повторяющегося из проекта в проект. Характерный пример — функциональность login/logout.
http://en.wikipedia.org/wiki/Front-end#Computer_science
Но это, в общем, придирки... А за проделанную работу - респект.