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