Comments 24
Очень занятно, спасибо. Первый русский доклад на эту тему.
Меня только одно интересует: почему парадигма называется MapReduce, если с функциями высшего порядка (map и, соответственно, reduce/fold) она не имеет почти ничего общего?
Меня только одно интересует: почему парадигма называется MapReduce, если с функциями высшего порядка (map и, соответственно, reduce/fold) она не имеет почти ничего общего?
А субъективно — не очень интересно, переливание всё одного и того же, что рассказывал Google еще лет 5 назад. Таких докладов, в том числе на русском языке, сильно более одного. Ни разу не хочу обидеть Владимира, но совершенно поверхностно и обзорно — совсем ничего нового, всё это можно прочитать, опять же, чуть ли не на морде wiki.apache.org/hadoop/ или услышать в десятках других докладов.
Я думаю, что доклад был ориентирован не на на тех, кто «в теме», а на новичков. Отсюда и переливание.
более специальный и узкий доклад был бы актуален для более узкой аудитории
поэтому специфика обычно попадает на серею вопросов-ответов после доклада
в данную статью я вопросы-ответы не включал, ибо итак много букаффф :)
поэтому специфика обычно попадает на серею вопросов-ответов после доклада
в данную статью я вопросы-ответы не включал, ибо итак много букаффф :)
А относительно слов «map» и «reduce» — этими словами обозначается достаточно много разных терминов; одно из значений (по-моему, как раз в плане лямбда-исчисления) — вполне точно соответствует применяемым механизмам.
Из лямбда-исчисления (в общих чертах) map / fold:
map(f, ...) — принимает Х списков, возвращает 1 список с примененной функцией f на каждый элемент каждого списка.
fold(f, start, l) — принимает один список, свертывает его по функции f. Так же часто передается стартовое значение.
Только вместо списков в ф-циях может быть много чего.
MapReduce:
Map — принимает всего два элемента — key / value. Возвращает промежуточное значение.
Reduce — принимает key / values. Свертывает все промежуточные значения для ключа key.
Разве не так?
map(f, ...) — принимает Х списков, возвращает 1 список с примененной функцией f на каждый элемент каждого списка.
fold(f, start, l) — принимает один список, свертывает его по функции f. Так же часто передается стартовое значение.
Только вместо списков в ф-циях может быть много чего.
MapReduce:
Map — принимает всего два элемента — key / value. Возвращает промежуточное значение.
Reduce — принимает key / values. Свертывает все промежуточные значения для ключа key.
Разве не так?
Про MapReduce вы что-то перемудрили. В *самых* общих чертах так:
Для MapReduce единственное, что изменяется — уточняется, что:
- map(f, c) — принимает функцию f и коллекцию c; возвращает коллекцию, образованную путем применения функции f к каждому элементу коллекции c
- reduce(f, c) — принимает функцию f и коллекцию c; возвращает объект (в общем случае — сложный объект), образованный через свертку коллекции c функцией f
Для MapReduce единственное, что изменяется — уточняется, что:
- для map — входная коллекция состоит из пар (key, value), причем и key, и value могут быть сколько угодно сложным объектом; на выходе каждый элемент входной коллекции порождает произвольно количество выходных пар (key, value) — причем формат выходных key и value может абсолютно никак не зависеть от формата входных
- между map и reduce будет происходить сортировка, группировка и partitioning
- для reduce — входная коллекция будет представлять собой срез всего потока данных из map, построенный каким-то образом — как правило, с единым значением key; функция применяется к элементам такой коллекции, коллекция, опять же, состоит из (key, value) пар, на выходе может быть произвольное количество агрегатов, опять же, в произвольном формате (key, value)
Да оно связанно весьма косвенно.
1. Например Map обычно это функция. А в данном случае на один вход может быть несколько выходов или нуль.
2. Reduce тоже не совсем обычный потому что он схлопывает данные, а тоже может возвращать произвольное число пар, reduce он только потому что фреймворк подает на вход сгруппированные данные.
Но все же название ассоциативное и понятно, как морская свинка.
1. Например Map обычно это функция. А в данном случае на один вход может быть несколько выходов или нуль.
2. Reduce тоже не совсем обычный потому что он схлопывает данные, а тоже может возвращать произвольное число пар, reduce он только потому что фреймворк подает на вход сгруппированные данные.
Но все же название ассоциативное и понятно, как морская свинка.
Впервые вижу отзыв о HBase как о нестабильном продукте… Вы контактировали с разработчиками? Что они говорят на ваши проблемы?
Доклад на самом деле немного устарел — Hadoop и Hbase движутся 7-мильными шагами, особенно после истории с Yahoo. А раньше у Hbase с надежностью действительно были проблемы. Замечу, что Facebook недавно выбрал его, а не Cassandra, где большой акцент как раз — на надежность и отказоустойчивость.
У меня вопрос — кто знает, как сейчас у Hadoop сейчас решает проблему выхода из строя NameNode?
У меня вопрос — кто знает, как сейчас у Hadoop сейчас решает проблему выхода из строя NameNode?
Кстати, интересует удобство работы HBase с языками отличными от Java. Я так понял если работать через Thift, то не все возможности доступны? Например фильтры я так и не нашел как использовать.
Ни в коем случае не принижаю достоинства автора статьи, HBase, MapReduce и прочих модных техник, но может не надо наезжать на мускул, если не умеете его готовить?
Специально посмотрел сейчас статистику по одному из своих серверов, на котором крутится мускул с базой около 0.8 Тб. Так вот, сервер обрабатывает в среднем 1.27к запросов в секунду, что на два порядка лучше заявленных 18 миллисекунд. За ~сутки сервером принято 130 Гб, отправлено 510 Гб. Железо как в статье — один Xeon с 8 гб озу.
Не скажу что это само собой получилось, тут специфическая структура базы и специфический конфиг мускула, но тем не менее… Зато все плюшки SQL… ну, почти все =) некоторые запросы конечно на такой базе не выполнятся никогда.
Специально посмотрел сейчас статистику по одному из своих серверов, на котором крутится мускул с базой около 0.8 Тб. Так вот, сервер обрабатывает в среднем 1.27к запросов в секунду, что на два порядка лучше заявленных 18 миллисекунд. За ~сутки сервером принято 130 Гб, отправлено 510 Гб. Железо как в статье — один Xeon с 8 гб озу.
Не скажу что это само собой получилось, тут специфическая структура базы и специфический конфиг мускула, но тем не менее… Зато все плюшки SQL… ну, почти все =) некоторые запросы конечно на такой базе не выполнятся никогда.
А что там за данные и что за access pattern?
Может, там как раз тот один процент данных висит в памяти и отдается круглые сутки. Так хоть пусть на диске 80 Тб будет, лишь бы сетки хватило.
Может, там как раз тот один процент данных висит в памяти и отдается круглые сутки. Так хоть пусть на диске 80 Тб будет, лишь бы сетки хватило.
Я так понял, что за 18 мс производится 300 чтений, что даст в идеале 300 * (1000 / 18) = 16,(6)К запросов в секунду.
Просто на вашем мускуле не выполняются такие запросы, которые бы его положили. На хадупе считают обычно тяжелые аггрегирующие запросы, котороые бы на вашем сервере не влезли бы просто в память. Не нужно сравнивать мускуль и хадуп — они для совершенно разных задач.
А «Большой андронный коллайдер» — это место где Android'ы кидают друг в друга? :)
компания google придумала парадигму Map-Reduce
Мда…
Ага, на сессии Q&A были в основном не специфичные вопросы, а какие то ехидные наезды на Apache Foundation, XML и ынтырпрайз, крупность компании докладчика и так далее.
Интересующимся темой советую посмотреть видео тренинги по технологиям Hadoop и смежным от компании Cloudera — www.cloudera.com/resources/?media=Video
интересно, но даже незнаю где это может мне пригодиться, если я не крутой инженер нагруженных систем…
Sign up to leave a comment.
Apache Hadoop (Доклад Владимира Климонтовича на ADD-2010)