Проектирование сервиса для BigData processing

[baldr]

Всем привет! Давно я тут не показывался, но как стало нужно с кем-то умным посоветоваться - сразу вспомнил про наш старый добрый форум..

Суть проблемы: у меня есть клиент, для которого я в одиночку разрабатываю сервис. В целом идея мне понятна, но не хватает опыта работы с инструментами для BigData. Сейчас готов работающий прототип, который может что-то делать с не очень большими данными (1-2 Гб). Довольно много ограничений, которые, впрочем, решаются.
Мне необходима помощь в обсуждении архитектуры и рекомендации инструментов/технологий для следующей версии.

Общая идея сервиса - хранить различные DataSet для юзеров, давать возможность ими управлять - загружать новые, удалять, импортировать из разных источников, бэкапы-шмэкапы, импорт-экспорт..
Вторая фича - обработка этих датасетов. Некие определяемые юзерами процедуры для удобной обработки этих данных.

Для пользователя: грубо говоря - если вы Data Scientist и у вас есть некоторые массивы информации - от гигабайта до терабайта - вы хотите строить модели, анализировать информацию, строить графики и все такое. Вы не хотите поднимать свои фермы серверов и их обслуживать, настраивать базы данных и следить за ними. Вы знаете в каких-то пределах R или Python или Java или еще какие-то языки (хоть Fortran) и хотите использовать то, что вам удобно. Возможно у вас баннерная сеть и вы раз в час хотите получать сводную статистику о новых кликах и показывать ее на сайте, и тп..
Вы подписываетесь на удобный сервис, импортируете ваши данные или каким-то образом настраиваете авто-импорт, потом пишете т.наз. Transformation - одну или цепочку процедур для обработки этих данных с организацией промежуточных результатов, а потом запускаете это время от времени.

В принципе, похоже на Google BigQuery, только свое

Сейчас для первого раунда сделан прототип на базе AWS(EC2+S3)/Django+Celery/Python/MongoDB: юзер загружает данные, например, из CSV или JSON, они кладутся в MongoDB и там хранятся. Юзер имеет возможность написать функцию на Python, которая через определенный интерфейс принимает входные датасеты (Pandas или list/dict) и может делать что угодно с ними, а потом сохраняет обратно.
Функция в виде файла заружается в систему, там проверяется на безопасность операций. После этого юзер может ее запустить на выделенном сервере, который специально для этого поднимается на AWS.

Очевидные недостатки понятны (и обсуждены с клиентом, но как прототип для демо пока его это устраивает).

Датасет ограничен по размерам оперативной памятью для обработки. Если загрузка-выгрузка сделаны поточными и, в принципе, способны засосать довольно большой объем, то для обработки все закачивается в память одного сервера и необходимо что-то делать в этой области. Это было изначально сделано для удобства юзера и для безопасности - чтобы не передавать ему открытый курсор к живой базе. Но, видимо, придется для каждой сессии создавать отдельного юзера и давать доступ только к нужным датасетам, а потом ео прибивать. Это несложно. Тогда клиенты смогут обращаться непосредственно к базе и строить запросы там (что я пытался избежать изначально).

Для обработки очень хочется не завязываться на какую-то конкретную технологию, а дать юзеру выбор. Например, сейчас у меня только разрешен Python с кучей запрещенных модулей для использования. Но юзер может хотеть работать с R, Go или еще чем-то.
Как вариант я сейчас думаю о том чтобы запускать на сервере Docker-контейнер, а внутри разрешить все что угодно - хоть shell-скрипты. Подготовить несколько базовых image (python, R, Go, Java) и пусть пишут как хотят. Можно подотовить некую клиентскую API-библиотеку с базовыми функциями для core-сервиса (типа, getDataSet, saveDataSet, etc)

В целом еще много мелочей, которые хотелось бы предусмотреть, но основные проблемы сейчас - это обработка и хранение больших объемов данных. Причем подешевле. Мой стек разработки сейчас - в основном Python backend, то есть желательно близко к нему все делать.
Я с BigData практически не работал плотно. Сейчас смотрю на Hadoop, Apache Spark. Думаю о возможности сделать все на MongoDB или даже на файлах в S3 или взять AWS RDS и в нее все запихать. Возможно, стоит для разных данных использовать разные сервисы..

В общем, хотелось бы получить консультацию у людей, чуть более хорошо разбирающихся в этой области. Для серьезных консультаций я даже готов потом немного заплатить, но пока хочется собрать мнения.

[RXL]

Думаю надо исходить из того, что представляют из себя данные и диапазон масштабов объема этих данных.

[baldr]

Данные могут быть чем угодно. Юзеры приходят разные. У кого-то плоская таблица из Excel со статистикой матчей, а у кого-то - json-файл на 3 Гб (ну пусть XML например) с логами от станка.
В ближайшее время заказчик ОК если будут поддерживаться датасеты до 2-10 Гб, но я хочу чтобы была возможность масштабироваться не переписывая каждый раз половину всего сервиса.
В большинстве случаев при обработке будут одновременно обрабатываться несколько датасетов (join например).

[Aether]

Вот, например, человек работает в прогнозе погоды, каждый день с разных мест поступают данные, причём большого объёма. Правильно ли я понимаю: пользователь должен иметь возможность контролировать доступ к ним и иметь стандартные API для разных языков, чтобы иметь возможность самостоятельно подключаться к БД, отключаться, делать запросы...

Стандартная БД не нравится, так как потенциальный пользователь не умеет или не хочет её администрировать?

Кто будет обрабатывать данные? Например, те же погодные данные интерполировать и рендерить, чтобы получилась карта? Гонять такой трафик от клиента к серверу и обратно? Или запускать пользовательский скрипт обработки на сервере?

[baldr]

Aether, спасибо, пример с погодой хороший.
Я разовью тему немного:
* 3 раза в день надо запускать процедуры для импорта новых данных из разных источников
* раз в день все новые данные агрегируются, чистятся от мусора и складываются в общую таблицу
* запускается X независимых скриптов для обработки по областям, например (рендеринг областных и местных карт погоды)
* после этого склеиваются в одну карту покрупнее (на страну)
* результаты отправляются по почте всем кому интересно
* запускается анализ аномалий (экстремальные температуры, грозы, наводнения)
* запускается тренировка модели на предсказание погоды
* строится прогноз на 1-5 дней

Смысл в том, что все данные обрабатываются на серверах. Юзер может, конечно, скачать весь датасет себе, но идея именно в предоставлении вычислительных мощностей.
Юзер пишет скрипты на тех ЯП, которые он знает и которые ему удобны, загружает их на сервер, а там они запускаются и все считают. (В зависимости от времени работы мы можем ему выставлять счет)
Вначале я пытался расчитывать также и на глупых юзеров, не умеющих программировать и пытался просто на страничке приделать визуальный SQL-like query builder, но это оказалось слишком большим упрощением.

В этом примере с прогнозом погоды - это, конечно, слишком сложная задача - самые большие вычислительные системы используются для моделирования погоды и мы на такое не замахиваемся. Однако, другой мой проект, в котором я работаю, занимается как раз предсказанием урожая по спутниковым снимкам.

[Aether]

Я приведу три примера, с которыми сталкивался и проблемы с ними:
1) Рендеринг 3D графики, сам пользовался LightWave и в случае фото качества некоторые сцены считаются неделю, а то и две. Соответственно, было бы неплохо, скинуть исходники на сервер, заплатить разумную сумму - это выгодно, особенно, если обсчёт будет быстрым.
Проблема: движок рендеринга не бесплатен, поэтому как быть в случаях таких задач? Нельзя же покупать к серверу всё имеющееся на рынке ПО? Есть, конечно, и бесплатные движки, но:
1.1 Предоставлять для пользователя просто вычислительные возможности - это нечто вроде VPS, а там сам пусть ставит что хочет - юридической ответственности никакой со стороны арендодателя.
1.2 Организовывать такую услугу, как одну из стандартных на базе такого-то бесплатного движка, и объявлять об этом.

2) Расчёт прочности методом конечных элементов: NASTRAN, ANSYS, Лира, SCAD.
Смысл тот же, и та же проблема - скрипт написать может и пользователь, но ПО для обсчёта будет платным.

3) Электронные аэродинамические трубы...

В общем-то, тут БД и особо не нужна, просто нужно ограниченное пространство в файловой системе сервера... Но, отличие Вашей системы от VPS, возможно, заключается в точном учёте вычислительных работ. При этом, учёт должен быть точным. Также в чём измерять вычислительную работу: в Вт электроэнергии с учётом тарифа или в млрд. инструкций?

[baldr]

Aether, спасибо за идеи. Это все, конечно, можно предусмотреть. И как раз проблем с этим я пока не вижу. Есть спрос - прикрутим движки. В крайнем случае дадим возможность загружать свои бинарники - и запускай что хочешь в контейнере.

Но мне нужны советы именно по BigData - я сейчас занят именно этой проблемой. Как предоставить юзеру наиболее простой доступ к, скажем, 100 Гб датасету? Где хранить такие данные для, скажем, 100 пользователей?
Ставить ли Hadoop+HDFS, использовать ли AWS EMR? Или будет ли смысл хранить все на S3 в виде файлов и при необходимости заливать в Mongo/RDS? Есть у нас кто-нибудь кто работал с такими технологиями?

Я, правда, помню что традиционно тут тусовались люди с опытом в Win32API и ниже.. Но, возможно, кто-то еще забредает?

[RXL]

Я зачем про данные спрашиваю... Судя по всему, это списки чего-либо. Списки можно резать, обрабатывать частями и склеивать. Например, для агрегации можно использовать БД, а можно применить external sorting и тогда обойтись без базы, также сортированные данные можно еще раз порезать и обрабатывать на разных процессорах или машинах.

[baldr]

RXL, да, в целом, конечно, можно. Вообще, скорее всего, лучше будет сделать поддержку разных движков для хранения данных. Что-то в виде файлов хранить просто, а, например, JSON-структуры в той же Mongo..
Про обрабатывать на разных процессорах/машинах - мне бы хотелось упростить эти вещи для "пользователей". Если они умеют программировать на R, то не факт что они очень интересуются тем как на несколько серверов отправить какие-то данные.
Это я и пытался решить, предоставляя им данные в виде pandas dataset - грубо говоря у тебя есть какая-то переменная с массивом твоих данных (матрица 1Mx1M элементов) и ты знаешь как ее перемножить или проредить на Python, но не хочешь задумываться о том сколько у тебя там ядер процессора, какая у них разрядность и как данные ходят по сети..

В принципе, как я потом выяснил у клиента, потенциальные юзеры знают что такое MapReduce, но требовать от них чтоб они сами писали какие-то фреймворки - за что тогда деньги-то брать?
Опять же юзер юзеру рознь..

Даже если данные хранятся как файлы или в базе или на разных нодах - я хочу предоставить наиболее простой способ их обрабатывать.

[Aether]

Как предоставить юзеру наиболее простой доступ к, скажем, 100 Гб датасету?

Где хранить такие данные для, скажем, 100 пользователей?

Как к диску, который пользователь привык видеть каждый день, то есть без БД.

Вот, это зависит от того, что Вы продаёте.

Если Вы продаёте место на сервере, то поставьте туда RAID и самые доступные SATA диски - 10Тб не так уж и много - скорость обработки будет низкая... На определённом этапе, скорость расчёта упрётся в планку скорости работы дисков. Это классическая аренда сервера, продали тариф 4ГГц х 10Тб HDD и всё.

Если Вы продаёте вычислительную работу при высокой мощности, то ситуация другая, возможно, имеет смысл создать планировщик задач, чтобы скрипты разных пользователей выполнялись в разное время - освободить ресурсы для монопольного по сути исполнения. Памяти же можно поставить много, если не ошибаюсь, то до 144Гб допускается, сейчас может быть и больше. Значит, обрабатывая скрипт система может скопировать туда данные из RAID целиком, и начать процесс обработки, потом записать на диск результат и высвободить память для следующей задачи. Кстати, БД здесь будет лишней задачей, тоже тормозящей процесс.

[baldr]

Aether, это решение слишком "в лоб".
Конечно, можно посмотреть, что сервер с 256Гб памяти и 64 ядрами стоит примерно $3.5/час (AWS     m4.16xlarge). Но это может быть слишком дорого для большинства задач когда достаточно из 100Гб сырых данных тремя запросами выбрать три строчки.
Базы данных для того и придуманы, чтобы обрабатывать данные более эффективно.

[Aether]

Как сказать, тут считать нужно, гонять на рендеринге неделю давайте посчитаем по порядку: 250 Вт * 5 * 24 = 30кВтч умножим на 5 р/кВтч = 150р + амортизация 5дней * 30000р / 720дней = 208р. Ладно, пренебрегаем, получается, около 358р. Ваш сервер имеет мощность по меньшей мере в 32 раза больше, значит, это займёт 5 * 24 / 32 = 3,75ч при стоимости 3,5$/ч (213р) = 798,75р. То есть, из соображений экономии средств выглядит не впечатляюще, хотя так быть не должно - мощный центр должен быть более экономичным. С другой стороны, время-деньги, если прибавить стоимость рабочего времени, то в общем, я бы согласился на 3,5$/час, но, чтобы быстро.

100Гб сырых данных на три запроса у Вашего сервера употребят несколько микросекунд, стало быть стоимость запроса будет копеечная. Что скрипт, что движок БД - будут в целом потреблять на поиск этих трёх строк одинаковое число ресурсов, однако, если искать не 3, а 3G строчек каждую секунду в ходе обсчёта, то БД сильно изменит баланс не в свою пользу.

Мне интересно вот что: дело-то с экономикой связано. Вот сколько стоит, скажем 1Тб в выражении HDD, и сколько в выражении RAM? Хороший экономический анализ расставит точки над i. Я всё-таки думаю, HDD проиграет, так как для достижения высокой скорости их объединять придётся несколько, плюс запас на надёжность. SSD - это вообще не вариант, так как ресурс в таком режиме пролетит быстро. И, самое важное, это энергопотребление. Память может быть не самая скоростная - но даже она быстрее HDD.

Помечтаю.) Мне, как пользователю, было бы шикарно: кликаешь мышкой на иконку приложения, а там меню: Запустить от имени администратора, а ниже: запустить на скоростном сервере. На нём в свою очередь счёт, если он кончается, то результаты можно забрать только заплатив остаток, но обсчёт в SolidWorks Cosmos - секунды, и я уже не жду сутки - двое, а либо переделываю тут же конструктив, либо несу на производство.

[baldr]

Aether, с точки зрения электричества, да еще в рублях - это как считать полосы на зебрах в Африке через веб-камеру.
https://calculator.s3.amazonaws.com/index.html - вот, можно посчитать тут примерно затраты если хочется точно. Но это все равно будет с погрешностью в 100% - слишком много там факторов.
И занимает это не секунды.

100Гб сырых данных на три запроса у Вашего сервера употребят несколько микросекунд

Вот тут вообще совсем не факт. Как раз это тоже может занять до часа (а то и больше) даже на самой мощной базе.

Вот сколько стоит, скажем 1Тб в выражении HDD, и сколько в выражении RAM?
...
SSD - это вообще не вариант, так как ресурс в таком режиме пролетит быстро.

https://www.digitalocean.com/pricing/#storage: SSD Block Storage pricing: $0.10/GB per month - то есть $100/mo за терабайт. Но, опять же, терабайт - это не так уж и много, а $100 - это не так уж и мало за хранение.
Впрочем, на AWS S3, вроде как, $22 будет это стоить, но там свои минусы.
Опять же, это все оторванные от реальных задач цифры. Хранить данные можно для разных целей. Но, если, например, мы используем этот терабайт для хранения работающей базы, то он используется одним образом, а если архивы - другим. Для базы нужна и избыточность (причем от 2х, а желательно 5х) и более высокие требования к доступности. На том же S3 ее не будешь хранить, а для кластера с дупликацией и репликацией - нужно в разы больше чем сам размер данных. Так что это все абстрактные подсчеты.

Повторюсь - я сейчас не выбираю стоимость хранения и обработки, мне нужно решить вопрос с архитектурой, а хостинг будет выбираться уже исходя из этого.