Представьте себе фреймворк общего назначения для распределенного исполнения приложений со следующими статистическими показателями*:


* Статистические данные за 2011 год.

А теперь представьте, что это не Hadoop.

О том, что это за фреймворк, о идеях и концепциях, заложенных в его основу и о том, почему этот фреймворк даже более инновационный (субъективно), чем Hadoop, речь пойдет ниже.

Объем данных, генерируемый и собираемый современными научно-исследовательским центрами, финансовыми институтами, социальными сетями, уже привычно измеряется петабайтами. Так в дата-центрах Facebook хранится уже более 15 млрд. изображений, нью-йоркская фондовая биржа NYSE создает и реплицирует ежедневно около 1 Тб данных, Большой адронный коллайдер получает около 1 Пб данных в секунду.

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

Платформа Hadoop, которая, в принципе, успешно решает проблему Big Data для полу- и неструктурированных данных, в своем «чистом» виде предъявляет значительные требования как к квалификации администраторов Hadoop-кластера, так и к первоначальным финансовым затратам на аппаратное обеспечение такого кластера.

В такой ситуации симбиоз облачных технологий и платформы Hadoop все чаще представляется как крайне перспективный способ решения проблемы «Больших данных», имеющий крайне невысокий уровень входа (квалификация + затраты на запуск).

Если ты ИТшник, то нельзя просто так взять и выйти на работу 2-го января: пересмотреть 3-ий сезон битвы экстрасенсов или запись программы «Гордон» на НТВ (дело умственных способностей вкуса).
Нельзя потому, что у других сотрудников обязательно будут для тебя подарки: у секретарши закончился кофе, у МП — закончились дедлайны, а у администратора баз данных — амнезия память.
Оказалось, что инженеры из команды Hadoop тоже любят побаловать друг друга новогодними сюрпризами.

2008

2 января. Упуская подробное описание эмоционально-психологического состояния лиц, участвующих в описанных ниже событиях, сразу перейду к факту: поставлен таск MAPREDUCE-279 «Map-Reduce 2.0». Оставив шутки про число, обращу внимание, что до 1-ой стабильной версии Hadoop остается чуть менее 4 лет.

За это время проект Hadoop пройдет эволюцию из маленького инновационного снежка, запущенного в 2005, в большой снежный com ком, надвигающийся на ИТ, в 2012.
Ниже мы предпримем попытку разобраться, какое же значение январский таск MAPREDUCE-279 играл (и, уверен, еще сыграет в 2013) в эволюции платформы Hadoop.

Так случилось, что первый посмотренный мною фильм с упоминанием слова «суперкомпьютер» был Терминатор. Но, как ни странно, моя (тогда еще) не сформировавшаяся психика не посчитала скайнет мировым злом, списав агрессивное поведение первого в мире ИИ на недостаточное покрытие юнит тестами.

На тот момент у меня был ZX Spectrum (чьих 128 Kb явно не хватало на запуск чего-то похожего на ИИ) и много (думаю лет 10) свободного времени. Благодаря последнему факту, я благополучно дождался эры виртуализации. Можно было снять хоть 10K VPS, установить между ними канал связи и начинать создавать ИИ. Но мне хотелось заниматься программированием, а не администрированием/конфигурацией grid-системы, и я разумно начал ждать, когда вычислительные ресурсы начнут предоставляться как сервис.

Моей радости не было конца, когда появились облачные сервисы. Но радость длилась недолго: стало понятно, что пока прямые коммуникации между отдельными вычислительными инстансами – это фантастика код, который нужно писать самому (то есть с большой вероятностью он работать не будет). Попереживав пару лет по этому поводу, я (мы все) дождался Hadoop, сначала «on-premises», а потом и эластичного «on-demand». Но и там, как оказалось, не всё так эластично гладко