После нескольких статей про MapReduce нам показалось необходимым еще раз отойти в сторону и поговорить про инфраструктуру, которая поможет облегчить построение решения MapReduce. Мы, по-прежнему, говорим про InterSystems Caché, и, по-прежнему, пытаемся построить MapReduce систему на базе имеющихся в системе подручных материалов.
На определенном этапе написания системы, типа MapReduce, встает задача удобного вызова удаленных методов и процедур (например, посылка управляющих сообщений с контроллера на сторону управляемых узлов). В среде Caché есть несколько простых, но не очень удобных методов достичь этой цели, тогда как хочется бы получить именно удобный.
В первой (достаточно капитанской) части этой серии мы рассказали про базовые концепции MapReduce почему это плохо, почему это неизбежно, и как с этим жить в других средах разработки (если вы не про Си++ или Java). Во второй части мы-таки начали рассказывать про базовые классы реализации MapReduce на Caché ObjectScript, введя абстрактные интерфейсы и их первичные реализации.
Сегодня пришел наш день! – мы покажем первый пример собранный в парадигме MapReduce, да, он будет странный и не самый эффективный, и совсем не распределенный, но вполне MapReduce.
В предыдущей части серии мы (в 100500й раз) попытались рассказать про основные приемы и стадии подхода Google MapReduce, должен признаться, что первая часть была намерено "капитанской", чтобы дать знать о MapReduce целевой аудитории последующих статей. Мы не успели показать ни строчки того, как всё это мы собираемся реализовывать в Caché ObjectScript. И про это наша рассказ сегодня (и в последующие дни).
Напомним первоначальный посыл нашего мини-проекта: вы всё еще планируем реализовать MapReduce алгоритм используя те подручные средства, что есть в Caché ObjectScript. При создании интерфейсов, мы попытаемся придерживаться того API, что мы описали в предыдущей статье про оригинальную реализацию Google MapReduce, любые девиации будут озвучены соответствующе.
Если Вы последние 10 лет провели на удаленном острове, без интернета и в отрыве от цивилизации, то специально для Вас мы попытаемся еще раз рассказать про концепцию MapReduce. Введение будет небольшим, в объеме достаточном, для реализации концепции MapReduce в среде InterSystems Caché. Если же Вы не сильно далеко удалялись последние 10 лет, то сразу переходите ко 2ой части, где мы создаем основы инфраструктуры.
[@tsafin — Обладателя премии ТьюрингаМайкла Стоунбрейкера представлять не надо, он и его студенты из Беркли и MIT создали, по ощущениям, большую часть реляционных и нереляционных баз данных за последние пару десятилетий. Ingres и Postgres, C-Store и Vertica, H-Store и VoltDB – вот лишь малая часть проектов и фирм, на который Майкл и его студенты повлияли напрямую, а ведь еще есть множество форков и деривативов…
Т.о. когда он критикует что-то, будь то NoSQL или Hadoop, то индустрии стоит, как минимум, прислушаться, а лучше попытаться измениться.
Мне показалось интересной его точка зрения на Hadoop, высказанная в статьях 2012 и 2014 года, и было интересно проследить развитие точки зрения «классика» за такой короткий промежуток времени.
Первую статью «Possible Hadoop Trajectories», опубликованную в «Comunications of ACM» http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext, Стоунбрейкер написал в мае 2012 года в соавторстве с Джереми Кепнером (Jeremy Kepner), который в тот момент работал как старший технический персонал в MIT, и как исследователь в MIT Mathematics Department и MIT Computer Science and AI Lab. Эта статья, написанная в соавторстве, кажется более дерзкой и задорной, по сравнению со второй, написанной уже им самим двумя годами позже (да и, чего уж там, первая статья написана IMHO в лучшем стиле), но я публикую их в связке, т.к. контекст за прошедшие пару лет сильно изменился, и было бы нечестно по отношению к экосистеме Hadoop/HDFS оставлять это незамеченным.
Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка«Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.
Введение
Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.
InterSystems никогда раньше не проводила хакатонов. Школы собирали каждый год, тренировали, разбивали на команды, делали задания, различной продолжительности, но так это не называли. Но время идет. Не хотелось в очередной раз повторять одно и тоже. Хотелось чего-то нового.
Хакатонов, тех же.
Если уж мы собираем полсотни высокопрофессиональных программистов Caché почему бы не попытаться, разбив их на команды, создать нечто новое? Не все, скорее всего, согласятся участвовать и захотят программировать ночи напролет, но даже и малая часть, всего две-три команды вполне могут создать что-то стоящее. Даже если в итоге получится всего пара, но осмысленных проектов, то будем считать эксперимент успешным. (И забегая вперед, мы можем с удовлетворением констатировать, что получили больше чем «пару» достойных проектов)