Comments 45
Если не пользуешься яндекс сервисами, то всё это тебя не коснётся?
За что минусуете «други»?
За вопрос без ответа?
За вопрос без ответа?
За глупость, вероятно. Ваша первая реплика звучала так, что вы всеми силами надеетесь избежать «прикосновения» описанных в статье технологий. Если так — то, да, насколько мне известно, из упомянутых проектов только ClickHouse доступен вне Яндекса. Кстати, вопрос к автору: YT не будет Open Source?
И вот за эту вашу ненависть вас и минусуют. Яндекс, на самом деле, интересные вещи делает, что есть хорошо, поэтому несколько странно видеть столь яростный комментарий.
И вот за эту вашу ненависть вас и минусуют. Яндекс, на самом деле, интересные вещи делает, что есть хорошо, поэтому несколько странно видеть столь яростный комментарий.
Кстати, вопрос к автору: YT не будет Open Source?
Сейчас мы всерьез изучаем такую возможность, но пока сложно сказать с полной определенностью.
Чтобы выкладка в open source имела смысл, нужно не просто выполнить некоторую разовую работу по подготовке кодовой базы и написанию подробной документации, но и быть готовыми поддерживать и развивать сообщество вокруг данной технологии. Это, в свою очередь, требует постоянных ненулевых усилий со стороны компании в целом и нашей команды в частности.
Конечно, если мы решимся на такой шаг, то об этом обязательно будет отдельный анонс.
Да, меня отчасти, пугают обновления по сотне мегабайтов ОС которым постоянно не
хватает места в системе до доустановки.
хватает места в системе до доустановки.
А при чём тут Яндекс?
Сам в раздумьях прочтя следующую новость по поддержке российских IT компаний
и перестройки информационной структуры только ли в Москве.
http://www.bloomberg.com/news/articles/2016-09-27/moscow-drops-microsoft-outlook-as-putin-urges-self-sufficiency
P.S. Или Вы думаете, что это само собой проиcходит?
и перестройки информационной структуры только ли в Москве.
http://www.bloomberg.com/news/articles/2016-09-27/moscow-drops-microsoft-outlook-as-putin-urges-self-sufficiency
P.S. Или Вы думаете, что это само собой проиcходит?
Сервисами Яндекса пользуется весь мир. Даже Гугл и Фейсбук. Например, сервисом по подготовке кадров.Но ты же даже этим сервисом не пользуешься.
Примерно такой ответ и ожидалось услышать.
Сорри, если кто то слишком обострённо воспринял данный вопрос.
Даже домашняя Ubuntu обновляется через яндекс сервера :)
P.S. Поисковик яндекса, к слову, не впечатляет и никогда не впечатлял.
И сегодня, как ни удивительно, дали флаер (жёлтый) в супер-маркете на бесплатную первую поездку на яндекс такси.
Кто бы мог ожидать что в яндекс и так разнопланово работает.
P.P.S. Минуса подтверждают выводы статьи https://habrahabr.ru/company/mosigra/blog/310670/
по «отминусовке» первых комментариев. :)
Сорри, если кто то слишком обострённо воспринял данный вопрос.
Даже домашняя Ubuntu обновляется через яндекс сервера :)
P.S. Поисковик яндекса, к слову, не впечатляет и никогда не впечатлял.
И сегодня, как ни удивительно, дали флаер (жёлтый) в супер-маркете на бесплатную первую поездку на яндекс такси.
Кто бы мог ожидать что в яндекс и так разнопланово работает.
P.P.S. Минуса подтверждают выводы статьи https://habrahabr.ru/company/mosigra/blog/310670/
по «отминусовке» первых комментариев. :)
Даже для общего развития слабая лекция! (по языкам программироания)
https://www.youtube.com/watch?v=Hozqp7P6cJs
, но в неязыковой части лекции (2-я половина вопросов) познавательный момент присутствует.
P.S. Лектор от Яндекса.
https://www.youtube.com/watch?v=Hozqp7P6cJs
, но в неязыковой части лекции (2-я половина вопросов) познавательный момент присутствует.
P.S. Лектор от Яндекса.
UFO just landed and posted this here
Почему-то все чаще начинают писать о map reduce. Интересно, а что вы думаете о высказывании старшего вице-президента по инфраструктуре google о том, что они больше не используют map reduce?
Источник цитаты: http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/
По их словам, map reduce не справляется с обработкой действительно больших данных.
“We don’t really use MapReduce anymore,” Hölzle said in his keynote presentation at the Google I/O conference in San Francisco Wednesday. The company stopped using the system “years ago.”
Источник цитаты: http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/
По их словам, map reduce не справляется с обработкой действительно больших данных.
UFO just landed and posted this here
Привет!
Следует уточнить, фраза «We don't really use MapReduce anymore» не означает, что «map reduce не справляется с обработкой действительно больших данных».
MapReduce интересен, в первую очередь, как масштабируемая модель вычислений, позволяющая скрыть для многих приложений технические вопросы распределенных вычислений (эффективная параллелизация, отказоустойчивость, и т. д.). На практике оказывается, что чистая имплементация MapReduce неудобна по ряду причин. Например, чистый интерфейс MapReduce лишен часто используемых операций типа Join. Также, например, для ad-hoc вычислений (ad-hoc аналитики) при работе с MapReduce требуется написать некоторый приличный объем boilerplate кода, иногда превышающий объем кода по существу задачи. Наконец, в рамках модели вычислений MapReduce не затрагивается вопрос интеграции с KV-хранилищами, получившими существенное распространение с момента публикации оригинальной статьи.
Для обхода данных ограничений были разработаны разные инструменты и фреймворки. По ссылке, что вы привели, речь идет как раз об одном из таких фреймворков — Cloud Dataflow. Фразу «We don’t really use MapReduce anymore» следует более точно перевести как «Мы не используем MapReduce-модель для большинства задач».
Из кулуарных разговоров с коллегами из Google следует, что в большой корпорации есть несколько используемых систем обработки данных, в том числе и MapReduce, и Dataflow, и другие. Для многих задач и в Google, и в Яндексе используются более высокоуровневые инструменты, чем MapReduce, предоставляющие пользователям более удобную модель вычислений.
Следует уточнить, фраза «We don't really use MapReduce anymore» не означает, что «map reduce не справляется с обработкой действительно больших данных».
MapReduce интересен, в первую очередь, как масштабируемая модель вычислений, позволяющая скрыть для многих приложений технические вопросы распределенных вычислений (эффективная параллелизация, отказоустойчивость, и т. д.). На практике оказывается, что чистая имплементация MapReduce неудобна по ряду причин. Например, чистый интерфейс MapReduce лишен часто используемых операций типа Join. Также, например, для ad-hoc вычислений (ad-hoc аналитики) при работе с MapReduce требуется написать некоторый приличный объем boilerplate кода, иногда превышающий объем кода по существу задачи. Наконец, в рамках модели вычислений MapReduce не затрагивается вопрос интеграции с KV-хранилищами, получившими существенное распространение с момента публикации оригинальной статьи.
Для обхода данных ограничений были разработаны разные инструменты и фреймворки. По ссылке, что вы привели, речь идет как раз об одном из таких фреймворков — Cloud Dataflow. Фразу «We don’t really use MapReduce anymore» следует более точно перевести как «Мы не используем MapReduce-модель для большинства задач».
Из кулуарных разговоров с коллегами из Google следует, что в большой корпорации есть несколько используемых систем обработки данных, в том числе и MapReduce, и Dataflow, и другие. Для многих задач и в Google, и в Яндексе используются более высокоуровневые инструменты, чем MapReduce, предоставляющие пользователям более удобную модель вычислений.
Следует уточнить, фраза «We don't really use MapReduce anymore» не означает, что «map reduce не справляется с обработкой действительно больших данных».
Не означает. Об этом другой абзац:
The technology is unable to handle the amounts of data Google wants to analyze these days, however.
Я прекрасно понимаю, что MapReduce не отомрет так быстро и они продолжают его использовать. У меня создалось впечатление, что они не считают MapReduce перспективной и универсальной технологией для big data.
We don’t really use MapReduce anymore
Не знаю точно, но подозреваю, что это стоит интерпретировать это как "we don't really use MapReduce directly". Возможно, люди перестали писать Map-Reduce джобы руками, так как это утомительно, и перешли на более высокоуровневые интерфейсы, которые используют Map-Reduce под капотом, анализируя граф потоков данных и компилируя его в цепочку Map-Reduce операций. Этот подход, например, описан в статье "FlumeJava: Easy, Efficient Data-Parallel Pipelines".
Вы не могли расписать чуть подробнее, почему выбрали для обработки данных именно MapReduce за основу, вместо того чтобы взять за основу подход Apache Spark?
Здесь стандартный tradeoff.
MapReduce дает оптимальный с точки зрения IO способ обработки больших объемов данных, но ценой значительной латентности (минуты, часы). Stream processing дает возможность сократить латентность до секунд, но заметно дороже в плане IO и CPU и зачастую требует менять сам алгоритм.
У нас есть много задач, где приходится обрабатывать (а не просто хранить) петабайты данных. Для них использование stream processing неоправданно.
Там, где латентность важна, мы применяем иные приемы (см. хотя бы довольно древнюю публикацию https://habrahabr.ru/company/yandex/blog/189362/). В том же YT мы последнее время как раз развиваем тему KV-хранилищ и очередей данных, без которых потоковая обработка невозможна.
MapReduce дает оптимальный с точки зрения IO способ обработки больших объемов данных, но ценой значительной латентности (минуты, часы). Stream processing дает возможность сократить латентность до секунд, но заметно дороже в плане IO и CPU и зачастую требует менять сам алгоритм.
У нас есть много задач, где приходится обрабатывать (а не просто хранить) петабайты данных. Для них использование stream processing неоправданно.
Там, где латентность важна, мы применяем иные приемы (см. хотя бы довольно древнюю публикацию https://habrahabr.ru/company/yandex/blog/189362/). В том же YT мы последнее время как раз развиваем тему KV-хранилищ и очередей данных, без которых потоковая обработка невозможна.
MapReduce дает оптимальный с точки зрения IO способ обработки больших объемов данных, но ценой значительной латентности (минуты, часы). Stream processing дает возможность сократить латентность до секунд, но заметно дороже в плане IO и CPU и зачастую требует менять сам алгоритм..
Построить сложный алгоритм обработки на MapReduce куда сложнее чем сделать аналогичный при подходе Spark. К тому же не соглашусь что это будет дороже в плане IO и CPU, как раз IO удастся сократить за счет того что часть операций будут выполняться в памяти. А CPU будет в среднем один и тот же.
Может конечно мне не хватает понимания принципов работы вашего MapReduce, поправьте если ошибаюсь.
Отсутствие промежуточной материализации — это конечно плюс, но если working set вычисления помещается в память, то хороший storage layer под MapReduce-системой и так разместит его в памяти (либо автоматически засчет кешей, либо по явному заказу). А вот когда нужно отсортировать петабайт, грубо говоря, то непонятно, чем тут Spark поможет.
IO сильно зависит от того, какой storage под stream processing pipeline мы берем. Для большинства известных мне практических задач, где stream processing вообще имеет смысл, понадобятся KV-хранилища и персистентные очереди, а они дороже, чем простой blob storage вида GFS/HDFS.
Про сложность написания невозможно судить в отрыве от задач. Тем более, что выражать свои мысли совсем не обязательно в MapReduce-терминах, есть и более высокоуровневые средства для описания вычислений (в т.ч. и в Яндексе).
Интерес к Spark и прочим обобщениям совершенно естественен и понятен, и определенную нишу они уже заняли. Но переносить на них большинство тяжелых процессов не осмысленно. Да и сама реализация (если говорить о Spark) еще очень далека до идеала, по крайней мере такие выводы можно сделать из кулуарного общения с теми, кто ее реально применяет.
IO сильно зависит от того, какой storage под stream processing pipeline мы берем. Для большинства известных мне практических задач, где stream processing вообще имеет смысл, понадобятся KV-хранилища и персистентные очереди, а они дороже, чем простой blob storage вида GFS/HDFS.
Про сложность написания невозможно судить в отрыве от задач. Тем более, что выражать свои мысли совсем не обязательно в MapReduce-терминах, есть и более высокоуровневые средства для описания вычислений (в т.ч. и в Яндексе).
Интерес к Spark и прочим обобщениям совершенно естественен и понятен, и определенную нишу они уже заняли. Но переносить на них большинство тяжелых процессов не осмысленно. Да и сама реализация (если говорить о Spark) еще очень далека до идеала, по крайней мере такие выводы можно сделать из кулуарного общения с теми, кто ее реально применяет.
Отсутствие промежуточной материализации — это конечно плюс, но если working set вычисления помещается в память, то хороший storage layer под MapReduce-системой и так разместит его в памяти
Это при условии хорошего storage layer. Хотя в оригинальном MapReduce все равно каждая операция персистится на диск и причем только в hdfs со всем оверхедом. В Spark операции могут выполняется в памяти либо, если не помещаются, то локально записываться на диск как есть с минимальными издержками.
А вот когда нужно отсортировать петабайт, грубо говоря, то непонятно, чем тут Spark поможет.
Но тут уже смотря какая задача. Если только отсортировать то да. А вот если еще с этим петабайтом нужно много всего сделать (отфильтровать, найти только нужное, изменить как-нибудь, что мне кажется более распространенной задачей) то тут уже Spark может весьма помочь.
Про сложность написания невозможно судить в отрыве от задач. Тем более, что выражать свои мысли совсем не обязательно в MapReduce-терминах, есть и более высокоуровневые средства для описания вычислений (в т.ч. и в Яндексе).
Если сравнивать MapReduce из Hadoop и Spark, то тут для любой задачи куда проще написать на Spark.
Да и сама реализация (если говорить о Spark) еще очень далека до идеала, по крайней мере такие выводы можно сделать из кулуарного общения с теми, кто ее реально применяет.
У нас в компании активно используется Spark, и им полностью довольны. До этого как раз было решение на «классическом Hadoop»
Опять же все мои утверждения по поводу MapReduce могут быть неприменимы к вашей реализации. Поэтому мне и интересно как он у вас устроен внутри.
Это при условии хорошего storage layer. Хотя в оригинальном MapReduce все равно каждая операция персистится на диск и причем только в hdfs со всем оверхедом. В Spark операции могут выполняется в памяти либо, если не помещаются, то локально записываться на диск как есть с минимальными издержками.
Все верно :) Именно поэтому мы работаем над тем, чтобы таких недостатков у нас не было, в т.ч. была возможность выбирать storage media для данных, включая память.
Но тут уже смотря какая задача. Если только отсортировать то да. А вот если еще с этим петабайтом нужно много всего сделать (отфильтровать, найти только нужное, изменить как-нибудь, что мне кажется более распространенной задачей) то тут уже Spark может весьма помочь.
Типично большие объемы сортируются для того, чтобы затем можно было дешево сделать join (reduce) с переменной правой частью. Поэтому материализация результата сортировки неизбежна.
Но это, конечно, частные свойства задач, а они у каждого свои.
У нас в компании активно используется Spark, и им полностью довольны. До этого как раз было решение на «классическом Hadoop»
А какого порядка размеры кластеров, если не секрет?
Опять же по опыту общения с коллегами из других компаний: запустить Spark на 100 машинах действительно не представляет труда, но вот отмасштабировать его на несколько тысяч, да еще и обеспечить изоляцию между пользователям и гарантировать им хоть что-то, по их словам, пока практически невозможно.
А какого порядка размеры кластеров, если не секрет?
Опять же по опыту общения с коллегами из других компаний: запустить Spark на 100 машинах действительно не представляет труда, но вот отмасштабировать его на несколько тысяч, да еще и обеспечить изоляцию между пользователям и гарантировать им хоть что-то, по их словам, пока практически невозможно.
Сотни серверов. Возможно тут Вы и правы, что при масштабировании до нескольких тысяч серверов появляются такие проблемы. Хотя если не рассматривать изоляцию пользователей то может все будет не так уж и плохо…
Поэтому мне и интересно как он у вас устроен внутри.
На часть вопросов, при желании, можно будет получить ответ 15 октября :)
А вот когда нужно отсортировать петабайт, грубо говоря, то непонятно, чем тут Spark поможет.Spark поможет отсортировать петабайт быстрее. Вы, наверное, путаете Spark и Spark Streaming.
Где-то есть версия этой статьи на английском?
Как знакомо. Мы в свое время тоже написали свой велосипед MapReduce вместо использования существующих инструментов (Hadoop, зачатки Spark).
Сейчас же я считаю, что это было ошибкой и лучше бы мы использовали Spark и тратили время на его доработку (и помощь сообществу).
Сейчас же я считаю, что это было ошибкой и лучше бы мы использовали Spark и тратили время на его доработку (и помощь сообществу).
UFO just landed and posted this here
Если при использовании обычной тройной репликации для хранения объема X необходимо потратить еще 2X под дополнительные реплики, то при использовании подходящих erasure-кодов этот оверхед снижается до X/2
Хотел спросить, вот при обычной тройной репликации допустим выход из строя двух серверов из трех без потери данных. Я правильно понимаю, что метод применяемый в яндексе допускает выход из строя всего лишь одного сервера из трех?
Нет. При использовании кодирования Рида-Соломона у данных нет никаких «реплик» в обычном понимании. Блоб режется на 6 частей (data parts), для них вычисляется еще 3 части (parity parts), после чего эти 9 частей раскладываются по 9 разным дискам. Любых 6 из этих 9 достаточно, чтобы восстановить все целиком. Так что для того, чтобы потерять данные, необходимо лишиться не менее 4 дисков за раз.
Sign up to leave a comment.
YT: зачем Яндексу своя MapReduce-система и как она устроена