Как перевести кластер Apache Spark от YARN в Kubernetes: пошаговый план

Spark Kubernetes Yarn, курсы по Spark, обучение Apache Spark, Apache Spark для разработчиков и инженеров данных, Kubernetes курсы обучение, Big Data, курсы инженеров данных, обучение дата-инженеров, администрирование кластера курсы, администратор big Data кластера обучение курсы, обучение большим данным, курсы Big Data, Школа Больших Данных Учебный центр Коммерсант

Учитывая рост интереса к DevOps-инструментам, сегодня рассмотрим, зачем переводить кластер Apache Spark, управляемый YARN, в Kubernetes, и как это сделать наиболее эффективно. А также разберем, какие системные метрики контейнерных Spark-приложений надо отслеживать и с помощью каких средств.

Зачем переводить кластер Apache Spark от YARN на Kubernetes

Apache Spark не зря считается самым популярным фреймворком распределенных вычислений с открытым исходным кодом. Он позволяет распараллеливать обработку больших объемов данных в кластере и включает множество полезных библиотек, от потоковых вычислений в режиме реального времени и SQL до машинного обучения. Однако, движок не управляет вычислительными узлами самостоятельно, а использует менеджер кластера или планировщик. Традиционно это был Hadoop YARN на базе виртуальной машины Java. Но сегодня в связи с ярко выраженной тенденцией перевода инфраструктуры в облачные платформы, многие компании переходят с YARN на Kubernetes для управления кластерами Spark. Apache Spark в Kubernetes доступен с момента выпуска релиза 3.1 в марте 2021 года.

Популярность Spark способствовала снижению интереса к стеку Hadoop в целом. А рост интереса к DevOps-инструментам, особенно простота и гибкость платформы контейнерной виртуализации Kubernetes ускорили уход от Hadoop. Основываясь на более чем десятилетнем опыте работы с рабочими нагрузками в Google, Kubernetes предлагает множество почти неограниченную масштабируемость количества рабочих нагрузок, открытый исходный код и гибкость развертывания в любой инфраструктуре (облака, локальный кластер или гибридная среда).

Также Kubernetes предлагает лучшее управление зависимостями, управление ресурсами и включает в себя богатую экосистему интеграций:

  • Spark традиционно боролся с управлением зависимостями, а работа в контейнерах Kubernetes позволяет дата-инженерам и разработчикам распределенных приложений упаковать все свои зависимости в контейнеры и перенести их со своего компьютера в рабочую среду.
  • контейнеры позволяют лучше изолировать рабочие нагрузки, расширяя возможности их групповой упаковки. YARN требует запуска нескольких кластеров или компрометации изоляции, что увеличивает затраты или снижает совместное использование ресурсов. Spark в Kubernetes позволяет запускать разные версии Spark и Python в одном кластере и обеспечивает беспроблемное совместное использование ресурсов. Когда одно задание завершается, можно запланировать другое и автоматически масштабировать кластер для дальнейшей оптимизации затрат.
  • Kubernetes поддерживает множество сред и фреймворков, а квоты ресурсов и пространства имен обеспечивают больший контроль над тем, как приложения используют системные ресурсы и совместно используют их. Управление доступом на основе ролей дает подробные разрешения на доступ к ресурсам и данным для повышения безопасности.

Это не единственные плюсы замены YARN на K8s. О других преимуществах развертывания Spark-приложений в Kubernetes мы писали здесь и здесь.

Как организовать переход: 4 простых шага

В миграции кластера Apache Spark с YARN на Kubernetes можно выделить 4 основных шага:

  • определение сложности заданий и требований к YARN. Простые определения контейнеров YARN можно быстро преобразовать в назначения ресурсов Kubernetes, таких как количество ЦП или памяти. Более сложные определения планировщика YARN, такие как планировщик ресурсов, следует перемещать последними после рассмотрения того, как будут определяться назначения ресурсов Kubernetes.
  • оценка потребностей в подключении к данным. После определения порядка переноса приложений необходимо выполнить проверку подключения к конкретным данным. Kubernetes предлагает множество способов доступа к данным, например, через существующие кластеры HDFS, с хранилищем с поддержкой S3 API или подключением к поставщикам Cloud Object Storage. Следует тщательно определить, где должны храниться данные для каждого бизнес-варианта использования или типа данных.
  • анализ задержки вычислений и хранения. При изменении способа доступа к данным также важно оценить, как это повлияет на производительность вычислений и задержку хранения. Можно сравнить время чтения и записи RDD, отключив все настройки «MEMORY_ONLY». Это обеспечит базовый уровень производительности «DISK_ONLY», который должен быть сопоставим с производительностью RDD с включенной памятью, при условии, что такое же количество ресурсов будет использоваться для назначения в Kubernetes.
  • Аудит политик мониторинга и безопасности. Наконец, при изменении способов доступа, передачи и обработки данных методы мониторинга и безопасности также должны оставаться актуальными.

Чтобы максимально эффективно использовать все возможности Apache Spark в Kubernetes, следует точно знать значения системных метрик контейнерных приложений. Для этого есть множество готовых инструментов, например, платформ Pulse, которая предоставляет сведения о заданиях Spark, их состоянии и других показателях, включая использование памяти в приложениях. Pulse позволяет создавать информационные панели, которые объединяют информацию из Kubernetes и Spark в единое окно, а также предоставляет отдельное окно для анализа метрик данных Spark Streaming.

Информационная панель Kubernetes и веб-GUI Spark предоставляют готовые визуализации, а экспорт показателей Spark в платформу Acceldata обеспечивает гибкий способ отображения этих данных и извлечения полезной информации. Также существует Spark Metrics — настраиваемая система, основанная на библиотеке метрик Dropwizard. Использование этой библиотеки позволяет передавать метрики Spark в различные приемники, включая файлы HTTP, JMX и CSV. Есть два основных способа доступа к метрикам: через пользовательский интерфейс Spark и через REST API. REST API возвращает JSON, упрощая создание визуализаций и использование инструментов мониторинга.

Каждый экземпляр SparkContext запускает пользовательский интерфейс Spark через порт 404 и отображает важные данные, такие как список этапов и задач планировщика, сводку размеров RDD и использования памяти, информацию об окружающей среде и запущенных исполнителях. Эти показатели доступны для просмотра только в течение всего срока работы приложения. Если необходимо сохранять эти данные в хранилище хранилище после завершения работы приложения, для параметра spark.eventLog.enabled следует установить значение true.

Чтобы получить доступ к пользовательскому интерфейсу Spark в Kubernetes, необходимо выполнить перенос на него, запустив команду

$ kubectl port-forward <driver-pod-name> 4040:4040</driver-pod-name>

Затем его можно открыть по адресу http://localhost:4040/.

Если нужно получить доступ к пользовательскому интерфейсу после завершения работы приложения, необходимо настроить конфигурацию spark.eventLog.dir для записи журналов в выбранное серверное хранилище. Затем можно настроить сервер истории Spark с диаграммой Helm и указать на серверную часть для просмотра пользовательского интерфейса Spark.

Кроме того, есть панель мониторинга Kubernetes — универсальный веб-интерфейс для кластеров этой платформы контейнерной виртуализации. Помимо просмотра и управления приложениями, он также позволяет пользователям отслеживать их статус. Панель мониторинга предоставляет основные показатели, такие как использование памяти, загрузка ЦП, ввод-вывод и дисковое пространство. Впрочем, на практике бывает сложно связать эти показатели с реальными заданиями и этапами Spark. Кроме того, метрики теряются после завершения заданий, если только они не сохранены в другой серверной части хранилища. Поэтому для повышения удобства мониторинга контейнерных Spark-приложений можно воспользоваться дополнительными DevOps-инструментами. Например, платформа Acceldata, интегрированная с сервисом Pulse.

Потоковая обработка в Apache Spark

Код курса
SPOT
Ближайшая дата курса
16 мая, 2024
Продолжительность
16 ак.часов
Стоимость обучения
48 000 руб.

Освойте администрирование и эксплуатацию Apache Spark для разработки приложений аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://acceldataio.medium.com/how-and-why-to-move-from-spark-on-yarn-to-kubernetes-5e65609ed58
  2. https://www.acceldata.io/blog/how-to-monitor-spark-on-kubernetes
Поиск по сайту