Как развернуть кластер Spark — Kubernetes, YARN или EMR — и что реально меняется?

Реальный движок исполнения Spark идентичен независимо от того, что планирует его executor'ы. Выбор менеджера кластера — это на самом деле выбор того, кто владеет провижинингом, масштабированием и восстановлением после сбоев: Spark или вы.

Что реально берёт на себя каждый вариант

YARN — исходный менеджер ресурсов Hadoop: зрелый, хорошо понятный всем, кто уже управлял Hadoop-кластером, но это отдельная система, которую вы сами провижините, патчите и мониторите, целиком отдельно от Spark. Kubernetes запускает executor'ы Spark как поды напрямую, а значит Spark использует ваш уже существующий инструментарий K8s (RBAC, мониторинг, автомасштабирование) вместо собственного — по-настоящему привлекательно, если K8s уже то, как всё остальное в вашей организации деплоится, и по-настоящему лишняя работа, если нет. Управляемые варианты (EMR, Databricks, Dataproc) полностью владеют слоем менеджера кластера — вы получаете API провижининга кластера и счёт, а не систему для патчинга.

Где реально проявляются операционные различия

Не в самой Spark-задаче — в том, что ломается и кого будят по звонку, когда это происходит. Очереди capacity scheduler кластера YARN и здоровье узлов — проблема вашей команды по настройке и мониторингу; на Kubernetes это становится запросами/лимитами ресурсов подов и тем автомасштабировщиком, который вы подключили — возможно, его уже владеет ваша платформенная команда для всего остального. Управляемый EMR/Databricks убирает сбои узлов, патчинг AMI/образов и политику масштабирования за контракт поддержки — реальная ценность ценой потери части доступа к низкоуровневой настройке, которую дают самоуправляемые кластеры (кастомные параметры ядра, нестандартные конфигурации инстансов).

Решение, которое дорого обратить

Смена менеджера кластера позже — это не изменение конфига, это перепровижининг инфраструктуры, перепроверка границ IAM/сети и обычно период параллельного прогона для уверенности перед переключением. Код самой Spark-задачи почти не меняется (в основном только --master и настройки ресурсов, специфичные для менеджера кластера), что соблазняет считать выбор менеджера кластера обратимым — необратим именно окружающий операционный инструментарий и знания команды.