ETL dans Java Spring Batch vs Apache Spark Benchmarking

En tant que responsable du projet Spring Batch, je suis sûr que vous comprendrez que j'ai une perspective spécifique. Cependant, avant de commencer, je dois rappeler que les frameworks dont nous parlons ont été conçus pour deux cas d'utilisation très différents. Spring Batch a été conçu pour gérer le traitement par lots d'entreprise traditionnel sur la JVM. Il a été conçu pour appliquer des modèles bien compris qui sont communs dans le traitement par lots d'entreprise et les rendre pratiques dans un cadre pour la JVM. Spark, sur d'autre part, a été conçu pour les cas d'utilisation big data et machine learning. Ces cas d'utilisation ont des modèles, des défis et des objectifs différents d'un système par lots d'entreprise traditionnel, et cela se reflète dans la conception du framework. Cela étant dit, voici mes réponses à vos questions spécifiques.

Quelqu'un a-t-il comparé les performances entre Apache Spark et Java Spring Batch?

Personne Ne peut vraiment répondre à cette question pour vous. Les critères de performance sont très chose en particulier. Les cas d'utilisation comptent. Sujets de matériel. Je vous encourage à faire vos propres benchmarks et profilage des performances pour déterminer ce qui fonctionne le mieux pour vos cas d'utilisation dans vos topologies de déploiement.

Quels pourraient être les avantages d'utiliser Spring Batch sur Spark?

modèle de Programmation similaire à d'autres charges de travail d'entreprise
Les entreprises doivent être conscientes des ressources dont elles disposent lorsqu'elles prennent des décisions architecturales. Utilise la nouvelle technologie X vaut la reconversion ou l'embauche de frais généraux de la technologie Y? Dans le cas de Spark vs Spring Batch, la montée en puissance d'un développeur de ressort existant sur Spring Batch est très minime. Je peux prendre n'importe quel développeur qui est à l'aise avec Spring et les rendre pleinement productifs avec Spring Batch très rapidement. Spark a une courbe d'apprentissage plus raide pour le développeur d'entreprise moyen, non seulement en raison de la surcharge d'apprentissage du cadre Spark, mais toutes les technologies connexes pour prodictionaliser un travail Spark dans cet écosystème (HDFS, Oozie, etc.).

Aucune infrastructure dédiée nécessaire
Lors de l'exécution dans un environnement distribué, vous devez configurer un cluster à l'aide de YARN, Mesos ou de la propre installation de clustering de Spark (il existe une option experimental Kubernetes disponible au moment d'écrire ces lignes, mais, comme indiqué, elle est étiquetée comme expérimentale). Cela nécessite une infrastructure dédiée pour des cas d'utilisation spécifiques. Spring Batch peut être déployé sur n'importe quelle infrastructure. Vous pouvez l'exécuter il via Spring Boot avec des fichiers JAR exécutables, vous pouvez le déployer dans des conteneurs de servlet ou des serveurs d'applications, et vous pouvez exécuter des tâches par lots Spring via YARN ou n'importe quel fournisseur de cloud. De plus, si vous utilisez le concept JAR exécutable de Spring Boot, il n'y a rien à configurer à l'avance, même si vous exécutez une application distribuée sur la même infrastructure cloud sur laquelle vous exécutez vos autres charges de travail.

Plus de lecteurs/rédacteurs prêts à l'emploi simplifient la création d'emplois
L'Étincelle de l'écosystème se concentre sur les cas d'utilisation du big Data. Pour cette raison, les composants qu'il fournit prêts à l'emploi pour la lecture et l'écriture sont axés sur ces cas d'utilisation. Des choses comme différentes options de sérialisation pour lire les fichiers couramment utilisés dans les cas d'utilisation de big Data sont gérées nativement. Cependant, le traitement de choses comme des morceaux d'enregistrements dans une transaction ne le sont pas.

Spring Batch, quant à lui, fournit une suite complète de composants pour l'entrée et la sortie déclaratives. Lecture et écriture à plat fichiers, fichiers XML, à partir de bases de données, de magasins NoSQL, de files d'attente de messagerie, d'écriture d'e-mails...la liste est longue. Lot de printemps provices tous ceux hors de la boîte.

Spark a été conçu pour le big Data...tous les cas d'utilisation ne sont pas des cas d'utilisation de big data
En bref, les fonctionnalités de Spark sont spécifiques au domaine pour lequel il a été conçu: big data et machine learning. Des choses comme la gestion des transactions (ou des transactions du tout) n'existent pas dans Spark. L'idée de rouler lorsqu'une erreur se produit n'existe pas (à ma connaissance) sans code personnalisé. Des cas d'utilisation de gestion des erreurs plus robustes tels que skip/retry ne sont pas fournis au niveau du framework. La gestion des états pour des choses comme le redémarrage est beaucoup plus lourde dans Spark que Spring Batch (persistance de l'ensemble du RDD vs stockage de l'état trivial pour des composants spécifiques). Toutes ces fonctionnalités sont des fonctionnalités natives de Spring Batch.

Spring Batch est-il "vraiment distribué"

L'un des avantages de Spring Batch est le capacité à faire évoluer un processus par lots d'un simple processus JVM unique exécuté séquentiellement à une solution entièrement distribuée et en cluster avec un minimum de modifications. Spring Batch prend en charge deux modes distribués principaux:

1. Partitionnement à distance - Ici Spring Batch s'exécute dans une configuration maître/travailleur. Les maîtres délèguent le travail aux travailleurs sur la base du mécanisme d'orchestration (beaucoup d'options ici). Restartability complet, gestion des erreurs, etc. est tout disponible pour cette approche avec surcharge réseau minimale (transmission des métadonnées décrivant chaque partition uniquement) aux JVM distantes. Spring Cloud Task fournit également des extensions à Spring Batch qui permettent aux mécanismes natifs du cloud de déployer dynamiquement les travailleurs.
2. Remote Chunking - Remote chunking délègue uniquement les phases de traitement et d'écriture d'une étape à une JVM distante. Toujours en utilisant une configuration maître/travailleur, le maître est responsable de fournir les données aux travailleurs pour traitement et écriture. Dans cette topologie, les données se déplacent sur le fil, provoquant une charge réseau plus lourde. Il est généralement utilisé uniquement lorsque les avantages de traitement peuvent dépasser la surcharge du trafic réseau ajouté.

Il existe d'autres réponses Stackoverflow qui discutent de ces fonctionnalités plus en détail (tout comme la documentation):

Avantages du lot de printemps
Différence entre spring batch remote chunking et le partitionnement à distance
Printemps Documentation des lots