Chi esegue workload Apache Spark su larga scala conosce il compromesso tra costo e affidabilita’, particolarmente evidente usando istanze EC2 Spot o processando dataset molto skewed. Un post dell’AWS Big Data Blog mostra come Apache Celeborn, un Remote Shuffle Service open source, risolva questo trade-off su Amazon EMR on EKS ed EMR on EC2, migliorando l’affidabilita’ dei job e sbloccando ulteriori risparmi. Il tema e’ concreto per chiunque gestisca pipeline Spark shuffle-heavy.
Tre problemi dello shuffle locale
Il post individua tre nodi. Primo: le interruzioni Spot innescano ricomputazioni costose, perche’ quando un executor su Spot viene reclamato con due minuti di preavviso i suoi dati di shuffle locali vanno persi e Spark deve rigenerare interi stage a monte. Secondo: lo storage di shuffle locale porta a un over-provisioning dell’intero cluster, dato che ogni nodo deve riservare memoria e disco per l’output di shuffle anche se solo pochi nodi fanno la maggior parte del lavoro, un classico problema di storage e compute accoppiati. Terzo: per proteggere i dati di shuffle, la logica di scaling di Spark impedisce di ridurre i nodi che li trattengono ancora, lasciando compute inattivo, effetto amplificato dallo skew dei dati.
Cosa fa Apache Celeborn
Celeborn disaccoppia del tutto i dati di shuffle dal ciclo di vita degli executor con un’architettura Leader-Worker-Client: invece di scrivere su disco locale, gli executor Spark spingono i dati verso un cluster Celeborn condiviso e ottimizzato per lo storage. Cosi’ i nodi executor di EMR possono girare al 100% su Spot, le reclamazioni Spot non causano piu’ perdita di dati di shuffle e gli executor scalano liberamente senza ricomputazioni a monte. Celeborn offre alta disponibilita’ basata su Raft, replica dei dati per job e uno shuffle manager sostitutivo con modifiche di configurazione minime. Il modello push-based riduce inoltre le connessioni N per M nella fase di lettura, migliorando prestazioni e stabilita’ su scala.
Deployment e produzione
La soluzione proposta fa girare Celeborn su un cluster EKS dedicato, separato dagli ambienti Spark, cosi’ ognuno usa tipi di istanza ottimizzati per il proprio profilo (Celeborn e’ intensivo su storage e I/O di rete, Spark su CPU e memoria) e un singolo cluster Celeborn serve piu’ cluster EMR tramite un Network Load Balancer interno. I nodi primari mantengono lo stato di coordinamento via Raft su StatefulSet con volumi EBS persistenti, mentre i worker tengono i dati di shuffle su NVMe locale effimero ma veloce, replicando ogni partizione su altri due worker. Lato configurazione, sul client Spark si disabilita l’External Shuffle Service e si imposta il SparkShuffleManager di Celeborn; lato server, tre repliche primarie per il quorum Raft e worker in numero inferiore ai nodi EC2. Il post copre anche osservabilita’ con ADOT, Prometheus e Grafana, e le considerazioni per la produzione: isolamento dei dati tra team, cifratura in transito e a riposo, autorizzazione a livello applicativo, autoscaling e Pod Disruption Budget.
- Disaccoppiare lo shuffle dagli executor consente di girare al 100% su Spot senza che le reclamazioni causino ricomputazioni.
- Un cluster Celeborn dedicato da’ indipendenza di ciclo di vita e permette di ridimensionare separatamente storage e compute.
- Replica per job, HA basata su Raft e fallback automatico allo shuffle nativo di Spark rendono l’architettura resiliente ai guasti dei nodi.
Fonte: High-performance Remote Shuffle Service on Amazon EMR with Apache Celeborn — https://aws.amazon.com/blogs/big-data/high-performance-remote-shuffle-service-on-amazon-emr-with-apache-celeborn/
Hai qualcosa da aggiungere? Unisciti alla discussione.