Несолько слов о том, когда Hadoop не применим

1. Задача
• Прием, сохранение и аналитика массивов
бинарных данных;
• Размер записи 300-500k;
• Требуемая производительность – 1000 qps
• Допустимая latency – 2-3s

2. Решение в прототипе
1. Реляционная СУБД (MySQL, хотя лучше PostgreSQL) с репликацией
2. Сервис очередей RabbitMQ или ZeroMQ
3. Аналитика запускается асинхронно.
4. Как прототип хорошо, но не масштабируется

3. Тестовая среда для Hadoop Jobs
1. HBase на 8 узлах
2. Запись принимается с клиента и сохраняется в HBase
3. Аналитика запускается как Hadoop Job
4. Результат сохраняется и отсылается клиенту
5. http://stackoverflow.com/questions/16260535/streaming-data-access-and-latency-in-hadoop-applications/
For latency, I can say that the completion time is always more than 30 sec, even if you are working withKB's of data. I
don't totally know why it is so long but this time is initializations, e.g creating job, determination that which part of
data is going to be processed by which worker, and so on.
So, if you are going to be working on small amount of data that is less than GB's, then don't go for hadoop, just use
your pc. Hadoop is only good for big data

4. Тестовая среда для Hadoop Jobs

5. Тестовая среда БЕЗ Hadoop Jobs
1. HBase на 8 узлах
2. Запись принимается с клиента
3. Аналитика сразу натравливается на запись, прямо на фронтенд сервере
4. Результат и запись сохраняются
5. Клиенту отсылается ответ

6. Тестовая среда БЕЗ Hadoop Jobs

7. Выводы
1. Hadoop Job хорош для крутой аналитики на Big Data
2. Когда аналитика достаточно быстра, а данных не петабайты Hadoop оказывается
невыгоден
3. Наша оценка применимости Hadoop – десятки секунд обработки на десятках узлов
хранилища с сотнями Гигабайт на каждом.
4. Если у вас этого нет – надо тщательно подумать

8. Спасибо!
Сергей Житинский
Git in Sky
CEO
sergey@gitinsky.ru
gitinsky.ru
facebook.com/gitinsky