Comments 4
Какой суммарный объём исходных данных? Не будет ли эффективнее (в вашем случае — дешевле) работать самопальный MR, быстро считающий нужные цифры на машинах с данными (скажем, можно использовать тот же HDFS, но данные обрабатывать демоном, который постоянно запущен и запускает подсчёт по http запросу), и с recude фазой на вашем бэкэнде?
Это хорошее предложение, на первый взгляд. По сути, мы так и сделали, но вместо 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 из внешнего мира и дополнительные расходы на резервное копирование в условиях постоянно пополняющегося набора файлов от конечных пользователей.
Кажется, я ответил на Ваш вопрос. Простите, если немного сумбурно — общий контекст приложения сложно описать в нескольких абзацах.
Данные загружаются конечными пользователями — примерно 30-50 ГБайт в день (объем увеличивается с ростом пользовательской базы). К текущему моменту у нас порядка 22 ТБайт исходных данных.
Кроме визуализации, описанной в статье, данные подвергаются другим видам преобразований для последующего анализа — на отдельных воркерах. Некоторые из этих преобразований задействуют GPU, другие — кастомные библиотеки из мира mass spectrometry. К текущему моменту у нас около 12 ТБайт частично преобразованных данных, использующихся для разных видов анализа. Они хранятся на S3, доступ к ним производится со своих узлов-воркеров в random access-режиме.
«Сырые» данные, которые мы храним, должны выдерживать проверку временем. Загрузив файлы сегодня, пользователь должен иметь возможность работать с ними и через пять лет. То есть, любые креши узлов HDFS, потенциально приводящие к потерям, для нас являются уязвимостью. Amazon S3, в свою очередь, дает гарантии безотказности (если не использовать reduced redundancy). Из дополнительных бесплатных плюшек — удобный и безопасный аплоад на S3 прямо с клиента (если интересно — могу описать в следующей статье).
Вдобавок, пользователи всегда могут попросить свои «сырые» данные назад — на download.
Поэтому мы вынуждены иметь централизованное хранилище для «сырых данных», подходящее для доступа из внешнего мира (download) и со всех инстансов-воркеров (random access, partial download). Это выходит дешевле, чем поддержка HDFS-кластера, имплементация доступа к данным на HDFS из внешнего мира и дополнительные расходы на резервное копирование в условиях постоянно пополняющегося набора файлов от конечных пользователей.
Кажется, я ответил на Ваш вопрос. Простите, если немного сумбурно — общий контекст приложения сложно описать в нескольких абзацах.
Да, я в целом понял. Единственный момент — я не предлагал HDFS или нечто подобное вместо S3, скорее иметь штук 10 воркеров, на каждом по 1.2ТБ активных данных, и на них уже считать. Обменять стоимость 10 инстансов на стоимость прокачки данных через S3. Минусы сразу видны: эти 10 воркеров будет существенно сложнее сворачивать в часы наименьшей нагрузки, ну и вообще больше кода писать. Из плюсов — можно получить буст по скорости реакции. Ну и потенциально может быть экономия денег, но надо крайне внимательно считать.
С плюсами такого решения согласен полностью.
Кроме указанных минусов — это действительно дороже. Минимум в два раза (посчитал на 1000 ГБ) — даже если использовать general storage, а не SSD.
Кроме указанных минусов — это действительно дороже. Минимум в два раза (посчитал на 1000 ГБ) — даже если использовать general storage, а не SSD.
Sign up to leave a comment.
Реал-тайм процессинг данных в AWS Cloud. Часть 2