Pourquoi Spark est-il lent ?

Pourquoi Spark est-il lent ?

En commençant par un titre accrocheur, « Pourquoi Spark est-il lent ?? », il est important de noter qu'appeler Spark « lent » peut signifier diverses choses. Est-ce lent au niveau des agrégations ? Chargement des données ? Différents cas existent. De plus, « Spark » est un terme général et ses performances dépendent de facteurs tels que le langage de programmation et le contexte d'utilisation. Alors, affinons le titre pour être plus précis avant de nous lancer.

Étant donné que j'utilise principalement Spark avec Python sur Databricks, je vais restreindre davantage la portée.

Le titre affiné sera :

"Premières impressions de Spark : "J'ai entendu dire que c'était rapide, mais pourquoi est-ce que ça semble lent ?" Le point de vue d'un débutant"

---

Motivation pour l'écriture (pensées informelles)

En tant que personne travaillant beaucoup avec les pandas, NumPy et les bibliothèques d'apprentissage automatique, j'ai admiré l'attrait de la capacité de Spark à gérer le Big Data avec un traitement parallèle et distribué. Quand j'ai finalement pu utiliser Spark pour le travail, j'ai été intrigué par les scénarios où il semblait plus lent que les pandas. Incertain de ce qui n'allait pas, j'ai découvert plusieurs idées et j'aimerais les partager.

---

Quand votre Spark devient-elle lente ?

Avant d'arriver au sujet principal

Voyons brièvement l'architecture de base de Spark.

(Aperçu du mode cluster)

Un cluster Spark se compose de Worker Nodes, qui effectuent le traitement proprement dit, et d'un Driver Node, qui coordonne et planifie l'exécution. Cette architecture influence tout ce qui est discuté ci-dessous, alors gardez-la à l'esprit.

Maintenant, passons aux points principaux.

---

1. L'ensemble de données n'est pas assez grand

Spark est optimisé pour le traitement de données à grande échelle, bien qu'il puisse également gérer de petits ensembles de données. Cependant, jetez un œil à ce benchmark :

(Analyse comparative d'Apache Spark sur une machine à nœud unique)

Les résultats montrent que pour les ensembles de données inférieurs à 15 Go, les pandas surpassent Spark dans les tâches d'agrégation. Pourquoi? En un mot, la surcharge des optimisations de Spark dépasse les avantages pour les petits ensembles de données.

Le lien montre les cas où Spark n'est pas plus lent, mais ceux-ci sont souvent en mode cluster local. Pour les configurations autonomes, les ensembles de données plus petits peuvent constituer un inconvénient en raison de la surcharge de communication réseau entre les nœuds.

• pandas : traite tout en mémoire sur une seule machine, sans E/S de réseau ou de stockage.
• Spark : utilise des RDD (Resilient Distributed Datasets), implique une communication réseau entre les Workers (s'ils sont distribués) et entraîne une surcharge dans l'organisation des données pour un traitement parallèle.

---

2. Comprendre l'évaluation paresseuse

Spark utilise une évaluation paresseuse, ce qui signifie que les transformations ne sont pas exécutées immédiatement mais différées jusqu'à ce qu'une action (par exemple, collecter, compter, afficher) déclenche le calcul.

Exemple (pandas) :

df = spark.read.table("tpch.lineitem").limit(1000).toPandas()
df["l_tax_percentage"] = df["l_tax"] * 100
for l_orderkey, group_df in df.groupby("l_orderkey"):
    print(l_orderkey, group_df["l_tax_percentage"].mean())

Temps d'exécution : 3,04 secondes

Équivalent dans Spark :

from pyspark.sql import functions as F
sdf = spark.read.table("tpch.lineitem").limit(1000)
sdf = sdf.withColumn("l_tax_percentage", F.col("l_tax") * 100)

for row in sdf.select("l_orderkey").distinct().collect():
    grouped_sdf = sdf.filter(F.col("l_orderkey") == row.l_orderkey).groupBy("l_orderkey").agg(
        F.mean("l_tax_percentage").alias("avg_l_tax_percentage")
    )
    print(grouped_sdf.show())

Temps d'exécution : Toujours en cours d'exécution après 3 minutes.

---

Pourquoi ?

1. Évaluation paresseuse : toutes les transformations sont mises en file d'attente et exécutées uniquement lors d'une action comme show.
2. Communication conducteur-travailleur : les opérations telles que la collecte et l'affichage impliquent le transfert de données des travailleurs vers le conducteur, ce qui entraîne des retards.

Le code Spark fait cela efficacement chez les pandas :

for l_orderkey, group_df in df.groupby("l_orderkey"):
    df["l_tax_percentage"] = df["l_tax"] * 100
    print(l_orderkey, group_df["l_tax_percentage"].mean())

Évitez de tels modèles en utilisant le cache de Spark ou en restructurant la logique pour minimiser les calculs répétés.

---

3. Attention aux mélanges

https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations

Les

Les mélanges se produisent lorsque les données sont redistribuées entre les Workers, généralement lors d'opérations telles que groupByKey, join ou repartition. Les lectures aléatoires peuvent être lentes à cause de :

• Communication réseau entre les nœuds.
• Tri et agrégation globale des données sur les partitions.

Par exemple, avoir plus de Workers n'améliore pas toujours les performances lors d'un mélange.

• 32 Go x 8 Workers peut être plus lent que 64 Go x 4 Workers, car moins de Workers réduisent la communication entre les nœuds.

---

Conclusion

Avez-vous trouvé cela utile ? Spark est un excellent outil lorsqu’il est utilisé efficacement. Au-delà d’accélérer le traitement des données à grande échelle, Spark brille par sa gestion évolutive des ressources, notamment dans le cloud.

Essayez Spark pour optimiser vos opérations et votre gestion de données !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!