Верно, надежность выше. Но и минусы тоже есть: больше расход CPU при записи и восстановлении данных, невозможность балансировать нагрузку между репликами (их нет). Тем не менее, большая часть архивных данных у нас хранится именно так.
Нет. При использовании кодирования Рида-Соломона у данных нет никаких «реплик» в обычном понимании. Блоб режется на 6 частей (data parts), для них вычисляется еще 3 части (parity parts), после чего эти 9 частей раскладываются по 9 разным дискам. Любых 6 из этих 9 достаточно, чтобы восстановить все целиком. Так что для того, чтобы потерять данные, необходимо лишиться не менее 4 дисков за раз.
Про масштабирование могу лишь пересказывать с чужих слов, к сожалению.
Изоляция для нас критично важна, т.к. иначе нельзя совмещать разнотипную нагрузку и полностью утилизировать весьма недешевое железо. И это фактически бесконечный путь, тут мы еще очень далеки от полного решения проблемы.
Это при условии хорошего storage layer. Хотя в оригинальном MapReduce все равно каждая операция персистится на диск и причем только в hdfs со всем оверхедом. В Spark операции могут выполняется в памяти либо, если не помещаются, то локально записываться на диск как есть с минимальными издержками.
Все верно :) Именно поэтому мы работаем над тем, чтобы таких недостатков у нас не было, в т.ч. была возможность выбирать storage media для данных, включая память.
Но тут уже смотря какая задача. Если только отсортировать то да. А вот если еще с этим петабайтом нужно много всего сделать (отфильтровать, найти только нужное, изменить как-нибудь, что мне кажется более распространенной задачей) то тут уже Spark может весьма помочь.
Типично большие объемы сортируются для того, чтобы затем можно было дешево сделать join (reduce) с переменной правой частью. Поэтому материализация результата сортировки неизбежна.
Но это, конечно, частные свойства задач, а они у каждого свои.
У нас в компании активно используется Spark, и им полностью довольны. До этого как раз было решение на «классическом Hadoop»
А какого порядка размеры кластеров, если не секрет?
Опять же по опыту общения с коллегами из других компаний: запустить Spark на 100 машинах действительно не представляет труда, но вот отмасштабировать его на несколько тысяч, да еще и обеспечить изоляцию между пользователям и гарантировать им хоть что-то, по их словам, пока практически невозможно.
Отсутствие промежуточной материализации — это конечно плюс, но если working set вычисления помещается в память, то хороший storage layer под MapReduce-системой и так разместит его в памяти (либо автоматически засчет кешей, либо по явному заказу). А вот когда нужно отсортировать петабайт, грубо говоря, то непонятно, чем тут Spark поможет.
IO сильно зависит от того, какой storage под stream processing pipeline мы берем. Для большинства известных мне практических задач, где stream processing вообще имеет смысл, понадобятся KV-хранилища и персистентные очереди, а они дороже, чем простой blob storage вида GFS/HDFS.
Про сложность написания невозможно судить в отрыве от задач. Тем более, что выражать свои мысли совсем не обязательно в MapReduce-терминах, есть и более высокоуровневые средства для описания вычислений (в т.ч. и в Яндексе).
Интерес к Spark и прочим обобщениям совершенно естественен и понятен, и определенную нишу они уже заняли. Но переносить на них большинство тяжелых процессов не осмысленно. Да и сама реализация (если говорить о Spark) еще очень далека до идеала, по крайней мере такие выводы можно сделать из кулуарного общения с теми, кто ее реально применяет.
MapReduce дает оптимальный с точки зрения IO способ обработки больших объемов данных, но ценой значительной латентности (минуты, часы). Stream processing дает возможность сократить латентность до секунд, но заметно дороже в плане IO и CPU и зачастую требует менять сам алгоритм.
У нас есть много задач, где приходится обрабатывать (а не просто хранить) петабайты данных. Для них использование stream processing неоправданно.
Там, где латентность важна, мы применяем иные приемы (см. хотя бы довольно древнюю публикацию https://habrahabr.ru/company/yandex/blog/189362/). В том же YT мы последнее время как раз развиваем тему KV-хранилищ и очередей данных, без которых потоковая обработка невозможна.
Прошлая реализация была постепенно заменена на YT. Выкладывать ее в open source мы не планируем, т.к. это будет мертвый проект. Если и тратить усилия в данном направлении, то полезнее выложить YT.
Сейчас мы всерьез изучаем такую возможность, но пока сложно сказать с полной определенностью.
Чтобы выкладка в open source имела смысл, нужно не просто выполнить некоторую разовую работу по подготовке кодовой базы и написанию подробной документации, но и быть готовыми поддерживать и развивать сообщество вокруг данной технологии. Это, в свою очередь, требует постоянных ненулевых усилий со стороны компании в целом и нашей команды в частности.
Конечно, если мы решимся на такой шаг, то об этом обязательно будет отдельный анонс.
Изоляция для нас критично важна, т.к. иначе нельзя совмещать разнотипную нагрузку и полностью утилизировать весьма недешевое железо. И это фактически бесконечный путь, тут мы еще очень далеки от полного решения проблемы.
На часть вопросов, при желании, можно будет получить ответ 15 октября :)
Все верно :) Именно поэтому мы работаем над тем, чтобы таких недостатков у нас не было, в т.ч. была возможность выбирать storage media для данных, включая память.
Типично большие объемы сортируются для того, чтобы затем можно было дешево сделать join (reduce) с переменной правой частью. Поэтому материализация результата сортировки неизбежна.
Но это, конечно, частные свойства задач, а они у каждого свои.
А какого порядка размеры кластеров, если не секрет?
Опять же по опыту общения с коллегами из других компаний: запустить Spark на 100 машинах действительно не представляет труда, но вот отмасштабировать его на несколько тысяч, да еще и обеспечить изоляцию между пользователям и гарантировать им хоть что-то, по их словам, пока практически невозможно.
IO сильно зависит от того, какой storage под stream processing pipeline мы берем. Для большинства известных мне практических задач, где stream processing вообще имеет смысл, понадобятся KV-хранилища и персистентные очереди, а они дороже, чем простой blob storage вида GFS/HDFS.
Про сложность написания невозможно судить в отрыве от задач. Тем более, что выражать свои мысли совсем не обязательно в MapReduce-терминах, есть и более высокоуровневые средства для описания вычислений (в т.ч. и в Яндексе).
Интерес к Spark и прочим обобщениям совершенно естественен и понятен, и определенную нишу они уже заняли. Но переносить на них большинство тяжелых процессов не осмысленно. Да и сама реализация (если говорить о Spark) еще очень далека до идеала, по крайней мере такие выводы можно сделать из кулуарного общения с теми, кто ее реально применяет.
MapReduce дает оптимальный с точки зрения IO способ обработки больших объемов данных, но ценой значительной латентности (минуты, часы). Stream processing дает возможность сократить латентность до секунд, но заметно дороже в плане IO и CPU и зачастую требует менять сам алгоритм.
У нас есть много задач, где приходится обрабатывать (а не просто хранить) петабайты данных. Для них использование stream processing неоправданно.
Там, где латентность важна, мы применяем иные приемы (см. хотя бы довольно древнюю публикацию https://habrahabr.ru/company/yandex/blog/189362/). В том же YT мы последнее время как раз развиваем тему KV-хранилищ и очередей данных, без которых потоковая обработка невозможна.
Сейчас мы всерьез изучаем такую возможность, но пока сложно сказать с полной определенностью.
Чтобы выкладка в open source имела смысл, нужно не просто выполнить некоторую разовую работу по подготовке кодовой базы и написанию подробной документации, но и быть готовыми поддерживать и развивать сообщество вокруг данной технологии. Это, в свою очередь, требует постоянных ненулевых усилий со стороны компании в целом и нашей команды в частности.
Конечно, если мы решимся на такой шаг, то об этом обязательно будет отдельный анонс.