Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Сегодня все и больше и больше специалистов по Data Science/Data Engineering применяют в своей каждодневной работе контейнеры. Такой подход дает возможность разделить рабочие среды, а также упрощает миграцию как из On-premise в облако, так и обратно. Пользуясь Kubernetes и контейнерами, вы, по сути, приближаетесь к Cloud Native. Что же, давайте посмотрим, какие конкретные плюсы можно получить, если запустить Spark внутри Kubernetes.</p>

2 <h2>Изоляция сред</h2>

3 <p>При традиционном развертывании в Hadoop-кластере существует проблема версионности Spark. К примеру, если надо перейти на новую версию, то проблем добавится как дата-инженерам, так и командам администрирования. Тем же админам надо будет организовать бесшовный апгрейд кластера, в то время как дата-инженерам придется проверять все свои пайплайны, дабы удостовериться в том, что они в новой версии Spark будут правильно работать. Если же использовать Spark в Kubernetes, вышеописанная проблема решается, ведь любой член команды может создать для себя отдельное окружение, которое станет работать в независимом контейнере, а потом упаковать в это окружение Spark-приложение со всем нужным кодом и требуемыми зависимостями. При этом вы можете выбрать как любую версию Spark, так и любые зависимости -- никому мешать вы не будете.</p>

4 <h2>Управление ресурсами</h2>

5 <p>Kubernetes дает возможность накладывать ограничения ресурсов на различные приложения и различные типы пайплайнов, к примеру, используя<strong>Namespace</strong>.</p>

6 <h2>Гибкое масштабирование</h2>

7 <p>Kubernetes в облаке способен задействовать львиную долю ресурсов именно на то время, в котором они реально используются. К примеру, у вас есть приложение, которому для нормальной работы обычно хватает десять ядер процессора, но в некоторых ситуациях возникает необходимость в сложной обработке данных, для чего кратковременно требуется от 500 до 1000 ядер. В таком случае вы можете подключить функцию автомасштабирования кластера. В результате, когда приложение запросит 500 ядер, облако их выделит. А в тот момент, когда приложение больше не будет генерировать такую нагрузку, избыточные ресурсы автоматически будут возвращены в облако.</p>

8 <h2>Возможность разделения Storage- и Compute-слоев</h2>

9 <p>Не секрет, что в Hadoop-кластере каждая нода -- это и Storage, и Compute. Но если для приложения надо добавить больше ядер, приходится добавлять и новую ноду, которая, в свою очередь, добавляет и диски, а за них нужно платить. Аналогичным образом происходит, когда заканчивается место на дисках: CPU хоть и хватает, но нам все равно приходится добавлять лишнюю ноду. Применение облака позволит разделить Storage- и Compute-слои, при этом Kubernetes выступает в роли<strong>Compute</strong>, тогда как объектное S3-хранилище -- в роли<strong>Storage</strong>. Но даже в том случае, если вы не захотите использовать S3, Kubernetes позволит вам реализовать комбинированный сценарий. К примеру, вы сможете задействовать Hadoop-кластер как обычно, однако в моменты пиковых нагрузок вы сможете запускать Spark в Kubernetes для использования его ресурсов.</p>

10 <h2>Более эффективное использование ресурсов</h2>

11 <p>Когда у вас уже есть рабочий Kubernetes-кластер, вы можете применить его, чтобы поднять Spark либо любое другое приложение. Профит в том, что вам при этом не придется создавать новый кластер.</p>

12 <p><em>По материалам https://mcs.mail.ru/blog/.</em></p>