Комментарии 18
Изобрели CouchDB?
0
CouchDB применяется немного для других целей, настолько повысить скорость вычислений она не позволит. Однако похожие решения есть у многих, но нам выгоднее иметь свое, так как для решения наших задач с нужным KPI требуется очень тесная интеграция всех компонентов. Добиться этого путем комбинации сторонних законченных решений крайне трудно. К тому же это не позволило бы нам повторно использовать наработанный код.
+5
> Сначала обработка логов запускалась раз в сутки, для чего очень хорошо подходила технология распределенных вычислений MapReduce.
У вас в конце предложения ссылка ведёт на этот же топик:) Поправьте, пожалуйста.
У вас в конце предложения ссылка ведёт на этот же топик:) Поправьте, пожалуйста.
0
У storm есть фатальный недостаток :)
А если серьезно, то storm же не позволит сохранить тонны map-reduce кода.
А если серьезно, то storm же не позволит сохранить тонны map-reduce кода.
+3
Про storm, dremel, impala и прочие подобные решения можно повторить практически все то же, что сказано в этом комментарии. В нашем случае это был оптимальный вариант. А про открытие технологии говорить пока слишком рано.
+1
impala и dremel — это не совсем про то, это скорее попытка сильно ускорить обычный mapreduce методом запихивания всего чего можно в память, кэширования и прочих оптимизаций. Настоящей реалтаймовости на большом потоке запросов они все равно не дадут.
+2
Настоящая риалтаймовость для write intensive задач недостижима без кэширования и предагрегации. Фактически, описанное решение, это интеллектуальная инвалидация кэша промежуточных результатов MapReduce задачи при поступлении новых данных. Сам же MapReduce никто не отменял, хотя бы и по кэшу плюс изменения. Так что, глобально, это туда же, куда и Impala.
0
мне бы очень хотелось чтобы у яндекса появились Search tools, как у гугла, особенно полезна возможность искать по времени. за неделю, за месяц, за год.
+1
Так вроде бы же есть возможность искать и по времени и по прочим параметрам: yandex.ru/search/advanced
+4
Было бы интересно, если бы смогли подробнее остановиться на тех проблемах, которые решались после разработки изначального прототипа.
+2
У Яндекса очень специфические задачи и хорошие программисты и пилить свой hadoop и impala вполне можно, но… все кто поменьше пользуются opensource и там жизнь бурлит.
Даже если у Яндекса выделено 100 программистов только под MapReduce фрэймворк, есть шанс что проекты из экосистемы hadoop все равно обойдут разработку Яндекса по качеству, скорости, удобству. Даже в таких мелочах как документированность и наличие обученных спецов на рынке: любой может развернуть себе hadoop и играться, а вот с фрэймворком Яндекса — не уверен что порог вхождения такой низкий.
Я к чему — в мечтах вместо того чтобы делать 5 разных mapreduce фрэймворков, было бы круто если бы все навалились на hadoop ) Хотя я конечно понимаю, что у Яндекса свои задачи, и даже если эти задачи выполняются на своем решении на 30% лучше по железу, то в масштабах это уже существенная экономия
Даже если у Яндекса выделено 100 программистов только под MapReduce фрэймворк, есть шанс что проекты из экосистемы hadoop все равно обойдут разработку Яндекса по качеству, скорости, удобству. Даже в таких мелочах как документированность и наличие обученных спецов на рынке: любой может развернуть себе hadoop и играться, а вот с фрэймворком Яндекса — не уверен что порог вхождения такой низкий.
Я к чему — в мечтах вместо того чтобы делать 5 разных mapreduce фрэймворков, было бы круто если бы все навалились на hadoop ) Хотя я конечно понимаю, что у Яндекса свои задачи, и даже если эти задачи выполняются на своем решении на 30% лучше по железу, то в масштабах это уже существенная экономия
+4
Не совсем понятно, чем достигается RealTime преимущество? Написано про реализацию отдельных мест системы, но ничего про MapReduce, каким образом существующий MapReduce код обрабатывает только часть данных, изменение которого затронуто (как определяется).
+4
Риалтаймовость обеспечивается тем, что весь набор данных держится в памяти со строгой привязкой к машине по ключу. При этом данные для reduce-операций подкапливаются, что позволяет запускать этот шаг не на каждый входящий сигнал. Результаты reduce-операций дедуплицируются, чтобы не страдали последующие шаги. Кроме того, мы стараемся максимально уменьшать диапазон данных, затрагиваемых изменениями. Сейчас движемся в сторону полноценного инкрементального подхода с применением комбинаторов. Весь новый код пишется уже с учетом этого фактора, но необходимость в поддержке старого кода остается.
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Технология Real Time MapReduce в Яндексе. Как ускорить что-то очень большое