Повысьте свою эффективность работы с данными.
Начните осваивать продвинутые инструменты дата инженера 27 сентября с демо-занятия «Приземление данных с помощью Apache Flink». Занятие проведет Вадим Опольский, Scala Big Data разработчик в Luxoft. За 1,5 часа рассмотрим проблемы чтения и записи данных из Apache Kafka. Познакомимся с Apache Flink и посмотрим на стенде, как можно эти проблемы решить.
***
Сегодня все и больше и больше специалистов по Data Science/Data Engineering применяют в своей каждодневной работе контейнеры. Такой подход дает возможность разделить рабочие среды, а также упрощает миграцию как из On-premise в облако, так и обратно. Пользуясь Kubernetes и контейнерами, вы, по сути, приближаетесь к Cloud Native. Что же, давайте посмотрим, какие конкретные плюсы можно получить, если запустить Spark внутри Kubernetes.
Изоляция сред
При традиционном развертывании в Hadoop-кластере существует проблема версионности Spark. К примеру, если надо перейти на новую версию, то проблем добавится как дата-инженерам, так и командам администрирования. Тем же админам надо будет организовать бесшовный апгрейд кластера, в то время как дата-инженерам придется проверять все свои пайплайны, дабы удостовериться в том, что они в новой версии Spark будут правильно работать. Если же использовать Spark в Kubernetes, вышеописанная проблема решается, ведь любой член команды может создать для себя отдельное окружение, которое станет работать в независимом контейнере, а потом упаковать в это окружение Spark-приложение со всем нужным кодом и требуемыми зависимостями. При этом вы можете выбрать как любую версию Spark, так и любые зависимости -- никому мешать вы не будете.
Управление ресурсами
Kubernetes дает возможность накладывать ограничения ресурсов на различные приложения и различные типы пайплайнов, к примеру, используя Namespace.
Гибкое масштабирование
Kubernetes в облаке способен задействовать львиную долю ресурсов именно на то время, в котором они реально используются. К примеру, у вас есть приложение, которому для нормальной работы обычно хватает десять ядер процессора, но в некоторых ситуациях возникает необходимость в сложной обработке данных, для чего кратковременно требуется от 500 до 1000 ядер. В таком случае вы можете подключить функцию автомасштабирования кластера. В результате, когда приложение запросит 500 ядер, облако их выделит. А в тот момент, когда приложение больше не будет генерировать такую нагрузку, избыточные ресурсы автоматически будут возвращены в облако.
Возможность разделения Storage- и Compute-слоев
Не секрет, что в Hadoop-кластере каждая нода -- это и Storage, и Compute. Но если для приложения надо добавить больше ядер, приходится добавлять и новую ноду, которая, в свою очередь, добавляет и диски, а за них нужно платить. Аналогичным образом происходит, когда заканчивается место на дисках: CPU хоть и хватает, но нам все равно приходится добавлять лишнюю ноду. Применение облака позволит разделить Storage- и Compute-слои, при этом Kubernetes выступает в роли Compute, тогда как объектное S3-хранилище -- в роли Storage. Но даже в том случае, если вы не захотите использовать S3, Kubernetes позволит вам реализовать комбинированный сценарий. К примеру, вы сможете задействовать Hadoop-кластер как обычно, однако в моменты пиковых нагрузок вы сможете запускать Spark в Kubernetes для использования его ресурсов.
Более эффективное использование ресурсов
Когда у вас уже есть рабочий Kubernetes-кластер, вы можете применить его, чтобы поднять Spark либо любое другое приложение. Профит в том, что вам при этом не придется создавать новый кластер.
По материалам https://mcs.mail.ru/blog/.