Pourquoi utiliser Apache Spark sur Databricks

Apache Spark est un outil Big Data dont l’objectif est de traiter de grands ensembles de données de manière parallèle et distribuée. Conçu pour exploiter le computing en mémoire, Spark peut être 100 fois plus rapide que Hadoop pour le traitement de données à grande échelle.
Cependant, pour les utilisateurs de Spark, il reste difficile de déboguer et de comprendre comment leur code est interprété et distribué sur les clusters.
Databricks aide. Avec cette plate-forme d’analyse unifiée au-dessus d’Apache Spark, nous pouvons facilement gérer les clusters en quelques clics, utiliser l’interface utilisateur visuelle Spark pour le débogage.

« Chez Databricks, nous travaillons dur pour rendre Spark plus facile à utiliser et à exécuter que jamais, grâce à nos efforts sur la base de code Spark et les supports qui l’entourent. Tout notre travail sur Spark est open source et va directement à Apache. »
Matei Zaharia, VP, Apache Spark, Co-founder & Chief Technologist, Databricks

Comment choisir des stratégies de jointure ?

Les jointures sont l’une des opérations fondamentales lors du développement d’un travail Spark. Il vaut donc la peine de connaître les optimisations avant de travailler avec des jointures.
Une stratégie de jointure appropriée est utile pour optimiser les opérations de jointure délicates, en trouvant la cause première de certaines erreurs de mémoire insuffisante ; et l’amélioration des performances des travaux Spark.

Les performances des jointures Spark dépendent de la stratégie utilisée pour aborder chaque scénario qui, à son tour, dépend de la taille des tables. En règle générale, les jointures de diffusion sont les plus efficaces car elles évitent les mélanges, mais elles ne s’appliquent qu’aux ensembles de données plus petits. La jointure de fusion de tri et la jointure de hachage aléatoire sont les deux principales jointures puissantes pour le Big Data.

Broadcast Hash Join - Jointure par hachage diffusé

Lorsque l’un des jeux de données est suffisamment petit pour tenir dans la mémoire, il est diffusé à tous les exécuteurs où réside le jeu de données plus volumineux. Il permet d’économiser les coûts de mélange, puis une jointure par hachage est effectuée.

Spark déploie cette stratégie de jointure lorsque la taille du jeu de données est inférieure au seuil. La propriété Spark est configurable :
spark.sql.autoBroadcastJoinThreshold
Default is 10MB

Shuffle hash join – Jointure par hachage aléatoire

Comme nous le savons, Spark est un moteur informatique distribué. Le grand nombre de données peut être divisé en un jeu de données plus petit pour le calcul parallèle. Cette idée est appliquée dans la jointure par hachage aléatoire.

Il y a 2 phases dans la jointure par hachage Shuffle :
1. Phase de remaniement - L’idée ici est que si 2 tables ont les mêmes clés, elles se retrouvent dans la même partition de sorte que les données requises pour les jointures sont disponibles dans la même partition.
2. Phase de hachage – Un seul nœud de hachage joint les données sur chaque partition
La jointure par hachage aléatoire est toujours une jointure coûteuse car elle implique à la fois le brassage et le hachage. La maintenance d’une table de hachage nécessite de la mémoire et des calculs.

Sort merge join

Lorsque les deux tables sont très volumineuses, Spark SQL utilise un nouvel algorithme pour joindre la table, c’est-à-dire Trier la jointure de fusion. Cette méthode n’a pas besoin de charger toutes les données, mais doit trier les données avant la jointure.

Il y a 3 phases dans Sort Merge Join :
1. Phase de lecture aléatoire : Les 2 grandes tables sont repartitionnées selon les clés de jointure sur les partitions du cluster.
2. Phase de tri : tri des données dans chaque partition en parallèle.
3. Phase de fusion : jointure des 2 données partitionnées triées.

Maximiser le parallélisme à grande échelle

Une grande partie de l’efficacité de Spark est due à sa capacité à exécuter plusieurs tâches en parallèle à grande échelle. Il est extrêmement important de savoir comment les données doivent être distribuées afin que le cluster puisse traiter efficacement les données. Le secret pour y parvenir est le partitionnement.
Le partitionnement est un concept important dans Spark car il détermine la façon dont les ressources sont accessibles lors de l’exécution d’une tâche. Dans Spark, une partition est créée avec une taille de 64 Mo par défaut.
Une bonne stratégie de partitionnement connaît les données, leur structure et la configuration du cluster. Il y a toujours un compromis lorsqu’il s’agit de décider du nombre de partitions.

Comment définir le nombre de partitions ?

En général, nous avons ces règles :
Limite inférieure : 2 x le nombre de cœurs dans le cluster disponibles pour l’application
Limite supérieure : l’exécution de la tâche doit prendre plus de 100 ms. Si cela prend moins de temps, cela signifie que les données partitionnées sont trop petites et que votre application passe peut-être plus de temps à planifier les tâches.

Deux types de partitionnement :

1. Partitionnement de hachage
Le partitionnement par hachage tente de répartir les données uniformément sur diverses partitions en fonction de la clé.
partition = key.hashCode () % noOfPartitions.
Attention, le partitionnement de hachage peut rendre les données distribuées faussées.
2. Partitionnement de plage
Il partitionne les données en fonction de certaines plages de clés triées. Les tuples avec la même gamme seront sur la même machine.
Les techniques de partitionnement de plage et de partitionnement par hachage de Spark sont idéales pour divers cas d’utilisation de Spark, mais le partitionnement n’est possible que dans les paires RDD.

Comment partitionner les RDD?

Les RDD peuvent être créés avec un partitionnement spécifique de deux manières :
1. En appelant la méthode partitionBy() et en passant la partition function

2. En appelant la transformation à l’aide de partitionneurs spécifiques.
Opérations sur les RDD de paire qui tiennent à un partitionneur : 

Répartition

Plusieurs fois, les développeurs Spark devront changer la partition d’origine. Cela peut être réalisé en modifiant la taille de la partition Spark et le nombre de partitions Spark avec la méthode repartition( ). Il mélange les données et les divise en un certain nombre de partitions. Mais une meilleure façon de partitionner dans Spark est de le faire à la source de données et cela économise le trafic réseau.

Utilisez Coalesce pour réduire le nombre de partitions

Coalesce est utile car il évite un mélange complet, il utilise des partitions existantes pour minimiser la quantité de données qui sont mélangées.

Mise en cache / Persistance

Les deux contribuent à améliorer les performances des trames de données ou des tables fréquemment consultées. Quelle est la différence entre la mise en cache et la persistance ?
cache() stocke autant de partitions lues en mémoire sur les exécuteurs Spark que la mémoire le permet, tandis que persist() offre plus de contrôle sur la façon et l’endroit où vos données sont stockées, en mémoire ou sur disque, sérialisées ou non.

Quand mettre en cache / persister?

Les cas d’utilisation courants de la mise en cache sont lorsque vous souhaitez accéder fréquemment à un jeu de données volumineux pour des requêtes ou des transformations par exemple.
1. Formation itérative à l’apprentissage automatique
2. Transformations fréquentes pendant l’ETL

Quand ne pas mettre en cache / persister?

Tous les jeux de données n’ont pas besoin d’être mis en cache. Certains scénarios qui devraient éviter la mise en cache comme :
1. Jeux de données trop volumineux pour tenir dans la mémoire
2. Une transformation peu coûteuse sur des jeux de données rarement utilisés, quelle que soit leur taille.
En règle générale, vous devez utiliser la mise en cache de la mémoire avec bon sens, car elle peut entraîner des coûts de ressources.