¿Cómo despliego un cluster de Spark - Kubernetes, YARN, o EMR - y qué cambia realmente?

El motor de ejecución real de Spark es idéntico sin importar qué agende sus executors. La elección de cluster manager es en realidad una elección sobre quién posee el aprovisionamiento, el escalado y la recuperación de fallos - Spark, o usted.

Qué posee realmente cada opción

YARN es el resource manager original de Hadoop - maduro, bien entendido por cualquiera que haya operado un cluster de Hadoop antes, pero es un sistema separado que usted aprovisiona, parchea y monitorea, completamente aparte de Spark. Kubernetes corre los executors de Spark como pods directamente, lo que significa que Spark comparte su tooling de K8s existente (RBAC, monitoreo, autoescalado) en vez de necesitar el suyo propio - genuinamente atractivo si K8s ya es cómo se despliega todo lo demás en su organización, genuinamente trabajo extra si no lo es. Las opciones administradas (EMR, Databricks, Dataproc) poseen la capa de cluster manager por completo - obtiene una API de aprovisionamiento de clusters y una factura, no un sistema que parchear.

Dónde aparecen realmente las diferencias operacionales

No en el job de Spark en sí - en qué se rompe y a quién le suena la alarma cuando pasa. Las colas del capacity scheduler y la salud de nodos de un cluster de YARN son problema de su equipo para afinar y monitorear; en Kubernetes, eso se convierte en requests/limits de recursos de pods y cualquier autoscaler que haya configurado, que su equipo de plataforma puede ya poseer para todo lo demás. EMR/Databricks administrado mueve las fallas de nodos, el parcheo de AMI/imágenes, y la política de escalado detrás de un contrato de soporte - valor real, al costo de perder algo del acceso a ajuste de bajo nivel que dan los clusters auto-gestionados (parámetros de kernel personalizados, configuraciones de instancia no estándar).

La decisión costosa de revertir

Cambiar de cluster manager después no es un cambio de configuración - es re-aprovisionar infraestructura, re-probar límites de IAM/red, y usualmente un período de ejecución en paralelo para construir confianza antes de hacer el corte. El código del job de Spark en sí apenas cambia (mayormente solo --master y ajustes de recursos específicos del cluster manager), lo cual tienta a tratar la elección del cluster manager como reversible - lo que no lo es es el tooling operacional y el conocimiento del equipo que la rodea.