Чтобы сделать курсы по Spark еще более интересными и полезными, сегодня мы расскажем, зачем этот Big Data фреймворк разворачивают на Kubernetes (K8s) – платформе автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Читайте в нашей статье про основные варианты использования и достоинства этого подхода к администрированию и эксплуатации Apache Spark.
Зачем вам нужен Apache Spark на Kubernetes: 3 варианта использования
Можно выделить несколько типовых сценариев, когда целесообразно Apache Spark на Kubernetes [1]:
- разработка и тестирование (отладка) программного обеспечения (ПО), когда разработчику необходим гибкий доступ к экземплярам конечных систем;
- развертывание разработанного ПО в соответствии с DevOps-подходом, включая непрерывную интеграцию и развертывание (CI/CD, Continuous Integration и Continuous Delivery). Чтобы упростить этот процесс, можно использовать Apache Livy в качестве REST API для запуска задач Spark, который размещен внутри кластера Kubernetes, через обычные cURL-запросы с поддержкой аутентификации;
- регулярный запуск Spark-задач на кластере Kubernetes в промышленной эксплуатации (production). Это можно сделать с помощью Kubernetes-сущности CronJob или через использование специальных операторов для управления приложениями, в частности, с мая 2020 года для версии Apache Spark 2.4.5 K8s поддерживает Spark Operator. Он позволяет настраивать параметры конфигурации, например, монтировать ConfigMap с конфигурацией доступа к Hadoop в поды Spark и запускать задачи по расписанию.
Чем хорош Спарк на K8s
Рассмотрим преимущества запуска Apache Spark на Kubernetes [2]:
- контейнеризация, которая является главным мотивом применения K8s в принципе. Контейнеры делают приложения более портативными, упрощая упаковку зависимостей, а также обеспечивая повторяемые и надежные рабочие процессы сборки. Они уменьшают общую нагрузку на DevOps и позволяют быстрее выполнять итерации разработки в соответствии с Agile-подходом. А управление зависимостями позволяет создать новый Docker-образ для каждого приложения, который упаковывает необходимые библиотеки, чтобы динамически добавлять поверх них код конкретного приложения.
- расширенная экосистема, позволяющая, например, использовать пространство имен и квот для управления многопользовательским режимом, а также управлять доступом на основе ролей по гибкой RBAC-модели, интегрированной с системой управления учетными данными (IAM, Identity and Access Management) облачного провайдера для точной безопасности и доступа к данным. Также плюсом является возможность повторного использования уже существующих инструментов, ставшими стандартами де-факто для администрирования и мониторинга Big Data инфраструктуры, например, панель управления Kubernetes для базового логгирования или связка Prometheus+Grafana для мониторинга.
- эффективное совместное использование ресурсов – в отличие от других кластерных диспетчеров, например, Apache Hadoop YARN или Mesos, настройка динамического распределения и автомасштабирования кластера Kubernetes позволит совместить выгоды общей инфраструктуры и полной изоляции непересекающихся наборов контейнеров без недостатков изоляции зависимостей и производительности. В частности, это поможет решить проблемы, когда приложения должны использовать одну и ту же глобальную версию Spark и Python или замедление одного приложения из-за повышенной активности другого. К примеру, Kubernetes нужно всего 10 секунд или менее, чтобы удалить бездействующий исполнитель (executor) Spark из одного приложения и выделить эти ресурсы другой программе. Кроме того, использование K8s нивелирует сложности балансировки нагрузки, управления очередями и компромиссами, характерные при для Apache Hadoop
Примечательно, что бенчмаркинговый анализ производительности Kubernetes и Hadoop YARN, проведенный в июле 2020 года, показал, что эти показатели работы этих кластерных менеджеров практически равны. Исследование проводилось по типовому TPC-DS (TPC Benchmark Decision Support) протоколу, который считается наиболее популярным бенчмаркинговым тестом для оценки производительности систем. Он включает оценку следующих параметров [3]:
- время ответа на запрос в однопользовательском режиме;
- пропускная способность запросов в многопользовательском режиме;
- производительность обслуживания данных для данного оборудования, операционной системы и конфигурации системы обработки данных при контролируемой, сложной и многопользовательской рабочей нагрузке.
Для TPC-DS теста использовалась выборка размером 1TB, по которой вычислялась скорость работы Apache Spark 3.0, развернутого на Google Kubernetes Engine, и эта же версия Спарк под управлением Apache Hadoop YARN. В качестве драйвера использовался экземпляр n2-standard-4 (4 виртуальных процессора, 16 ГБ оперативной памяти) и 5 исполнителей на инстансах n2-highmem-4 (4 виртуальных процессора, 32 ГБ RAM, 375 ГБ локальный SSD). YARN показал незначительное преимущество в 5% над Kubernetes, однако эту разница нивелируется вышеперечисленными достоинствами K8s, а также с помощью оптимизации настроек Spark, таких как количество разделов, управление памятью, структуры для перемешивания данных (shuffle), используемые при операциях аналитики Big Data (группировка, агрегация и join-соединение) [4].
Обратной стороной всех этих достоинств запуска Apache Spark на Kubernetes являются некоторые специфические ограничения, которые можно рассматривать как недостатки. О них мы поговорим в следующей статье. А как администрировать и использовать Apache Spark для аналитики больших данных в проектах цифровизации своего бизнеса, а также государственных и муниципальных предприятий, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
