This talk (in french) develops how users can extend Spark and Spark SQL for processing Spatial Big Data. The talk focus only on Vector Data but the same tricks can be applied to Raster Datasets. A longer version will be posted later with more details.

1. Processing Spatial
Big Data with
and SQL
Pr Hajji Hicham,
PhD, Msc, Eng
ESGIT Rabat IAV H2

2. Plan
•Exemples
•Contraintes du Spatial Big Data
•Approches d’extension de Spark pour le
Spatial Big Data
RDD Based
Dataframe/Dataset Based
Data Source API
•Questions ouvertes

3. Spatial Big Data: Big Picture - Location based service
- IOT
- Medecine et genomics
- Reseaux sociaux
- Monitoring du changement
climatiques
Vecteur Raster

4. Calcul dans le Spatial Big Data:
Paralléliser

5. Pourquoi Spark?
In Memory Facilité d’utilisation
Moteur Unifié

6. Partitionnement
Pt_X, PtY
Pt_X, PtY
Partitionnement n'est rien que diviser les données en parties et les stocker
dans le cluster.

7. Pourquoi le partitionnement
Pt_X, PtY
- En calcul distribué, le principal défi consiste à minimiser le trafic réseau.
Transformations (Join, GroupByKey, reduceByKey, combineByKey), il y
a une bonne quantité de données qui sera échangée sur le réseau
(Shuffling).
Si des clés ou des plages de clés similaires sont stockées
dans la même partition, le Shuffling est minimisé et le
traitement devient sensiblement rapide

8. Contraintes du
partitionnement
spatial
Spatial Data
Skew
Limites des
objets:

9. Partition 1 Partition 2 Partition 3 Partition 4
RDD
Partition 5 Partition 6
P8P5
Spatial Data Skew
Les données géospatiales tendent à être fortement asymétriques.
Si OpenStreetMap est partitionné
en 1 000 x 1 000 tuiles de taille
fixe, le nombre d'objets contenus
dans la tuile la plus asymétrique
est près de trois fois supérieur à
celui d'une tuile moyenne

10. Problème du Data Skew
Spark attribue une tâche par partition et chaque Worker peut traiter une tâche à la fois
Partitions Temps d’éxécutionParfois inévitable

11. Ce qu’il faut retenir
Très peu de partitions
Partition Trop chargée
Moins de concurrence et des cores (CPU) non utilisés
Une pression sur la mémoire pour des opérateurs comme:
groupBy, reduceByKey
Beaucoup de partitions
Partition contient peu de données
Beaucoup de latence due au scheduling des tâches
Plus de CPU context-switch

12. Limites des objets
Cout supplémentaire de calcul à rajouter
Les limites d’objets peuvent appartenir à plusieurs partitions
(violant ainsi l’indépendance des partitions)
Une bonne approche de partitionnement doit minimiser le nombre
d’objets dupliqués
Partition 1 Partition 2 Partition 3 Partition 4

13. Spark pour le Spatial Big Data
Extensions
RDD
DataFrame
/ DataSet
Maintenant que le problème de partitionnement est discuté, on passe à la partie calcul spatial sur des données distribuées sur le
cluster Spark

14. RDD: Resilient Distributed Dataset
•RDD: une collection distribuée et résiliente de données sur laquelle on peut opérer et appliquer des
transformations et des actions.
•Propriétés:
•Distribuée + Immutable + Cachable + Lazy evaluated
•RDD sont juste une collection de partitions

15. - Une transformation décrit comment transformer une RDD en une autre RDD
- Une action calcule un résultat à partir d’un RDD
RDD: Opérations

16. Malgré plusieurs Types de
RDDs, ils nous faut créer
d’autres pour le spatial:
Exp SpatialRDD

17. Nous pouvons étendre
l'API spark de deux
façons:
Ajouter un opérateur
personnalisé pour les
RDD existants
Créer notre propre
RDD: SpatialRDD
PointRDD
LineRDD
PolygonRDD
TileRDD
Voir code github pour voir exemple : https://github.com/hajjihi/
MonRDD.KNN (2)

18. Comment créer un Custom RDD
•Parfois on a besoin de créer une RDD qui correspond au métier qu’on traite: Custom RDD (RDD métier)
Méthodes à
redéfinir:
Compute
Cette méthode est celle qui
calcule la valeur pour
chaque partition de RDD
getPartitions
La méthode getPartitions permet
au développeur de spécifier les
nouvelles partitions
pour le RDD

19. LocationSpark
Frameworks Spatial : RDD Based

20. Problèmes avec les approches basées RDD

21. Problèmes avec les approches basées RDD
• Besoin d’un langage déclaratif comme SQL
Focus sur le « Comment»
et non le « Quoi»
• Les développeurs doivent optimiser chaque RDD en fonction de ses
attributs.
Aucun moteur
d'optimisation intégré
• les RDD n'infèrent pas le schéma des données ingérées et nécessitent que
l'utilisateur le spécifie.
Traitement des données
structurées
• En tant qu'objets JVM en mémoire, les RDD impliquent l'overhead de
Garbage Collection et Java Serialization qui sont coûteux lorsque les
données augmentent.
Limitation de
performance

22. Extension Basée Dataframe/Dataset
Spark-SQL

23. •Collection distribuée de données organisées en colonnes nommées
• Conceptuellement équivalent à une table dans une base de données relationnelle
Collection distribuée d'objet
Row:
• Le « Quoi » et non « Comment »SQL comme langage
• Transformation de la requête en syntaxe SQL vers des plans logiques et physiques optimisés avant
leur exécution en code RDD ou code optimisé.
Optimisation à l'aide de
l'optimiseur de CATALYST
•Tungsten fournit un backend d'exécution physique qui gère explicitement la mémoire et génère
dynamiquement du bytecode pour l'évaluation de l'expression.Tungsten
• Structurés et non structurés (Avro, CSV, recherche élastique et Cassandra)
• Systèmes de stockage (HDFS, tables HIVE, MySQL, etc.).
Traitement de l'information:
Dataframe

24. Exemple Dataframe

25. Problèmes avec les Dataframe
•Programmation Fonctionnelle:
Non
Uniquement
opérateurs
relationnels
•Objet JVM non typés
•Erreurs détecté lors de l’exécution
et non lors de la compilation
Non typés

26. • RDD (programmation fonctionnelle, type safe), DataFrame (modèle
relationnel, Optimisation de requête, exécution de tungstène)
Fournit le meilleur de
RDD et de Dataframe
• Avec l'utilisation des encodeurs, il est facile de convertir n'importe quel
objet JVM en un Dataset, ce qui permet aux utilisateurs de travailler avec
des données structurées et non structurées contrairement à Dataframe.
Encodeurs
• Datasets API fournit une sécurité de compilation qui n'était pas disponible
dans Dataframes.Type Safety
Dataset

27. Exemple Dataset

28. Select st_area(t1.SpatialUDT), st_area(t2.SpatialUDT)
From Table1 t1, Table2 t2
Where st_Intersect(t1. SpatialUDT, t2. SpatialUDT)
Et le spatial dans SPARK SQL???

29. 5 éléments à créer :
Types de données spatiales
Fonctions et opérations spatiales
Règles d’optimisations spatiales à intégrer dans Catalyst
Stratégies d’executions spatiales à intégrer dans Catalyst
Data Source API
Et Le spatial dans SPARK SQL???
Domain Specific
Language
Du Plan Logique
vers le Plan
Physique
Optimisation et
Execution
Construction du
Scan / Column et
Filter Pruning

30. - Dans Spark SQL, les types de données intégrés (Built-in) sont stockés dans un format compressé en colonnes
pour la mise en cache en mémoire
- Toute nouvelle structure doit avoir le même comportement
- On doit établir un mapping entre le UDT et les types Built-ins et vice verca.
Types de données Spatiaux
User Defined Type - UDT

31. Permettent d'enregistrer des fonctions
personnalisées Sous la forme de la fonction Scala,
Python, Java pour les appeler dans SQL.
De plus, les fonctions UDF peuvent apparaître
dans des colonnes SELECT ou dans Conditions
WHERE et JOIN.
Spark SQL rend particulièrement facile d'écrire
des UDF.
Fonctions et opérations spatiales
user defined function - UDF
Description de la fonction UDF
Enregistrement de l’UDF
Utilisation de l’UDF dans la requête SQL

32. Réécriture des requêtes spatiales avec
Catalyst Optimizer
Requête
SQL
Plan
logique
Plan
Optimisé
Plan Spark
RDD /Code
Optimisé
Règles
d’optimisations
Stratégies
d’exécutions

33. Catalyst: Oui mais comment?
La plus grande partie du travail effectué par l'optimiseur est exprimée sous forme
de règles, qui prennent un plan de requête et produisent un plan de requête.

34. Exemple requête SQL et comment les règles
s’appliquent

35. Exemple requête SQL et comment les règles
s’appliquent

36. Exemple requête SQL et comment les règles
s’applique

37. Les stratégies d’exécution dans Spark
- Permet de transformer un plan logique en plan physique
(Spark Plan)
- Chaque stratégie applique du Pattern Matching pour
convertir un arbre vers un autre type d’arbre

38. Extensions spark sql – optimisations et stratégies
Name Description
extraStrategies Collection de Strategies utilisées par SparkPlanner
extraOptimizations
Collection de règles pour optimiser des plqns
logiques
• utilisés par SparkOptimizer

39. Exemples d’extensions spatiales
avec spark sql
(Projet Non Officiel )
SIGMOD’16,
June 26-July 01, 2016,
San Francisco, CA, USA

40. Exemple RO dans
Règle
-D’abord Transformer l’expression select originale à une forme
disjonctive Normale (DNF), par exemple. (A∧B)∨C∨(D∧E∧F)
-Faire un pushdown predicate sur la condition vers le filtre de
jointure

41. Exemple de SE dans
SpatialJoinExtractor IndexRelationScans SimbaFilter
KNN Join based on Two-Level R-Tree Structure
KNN Join based on Cartesian Product
KNN Join based on Voronoi Partitioning
KNN Join based on Block Nested Loop Approach

42. Réécriture de la jointure
Exemple RO dans Magellan

43. DataSource API
•Filtrer les données à la source et donner le relai à catalyst pour le reste de l’optimisation

44. Conclusion : Qu’est ce qui rend Spatial
Big Data plus performant
•Spark SQL avec Dataset reste un bon framework pour le Spatial Big Data
•Avec Catalyst
•Avec Tungsten
•Facilité d’extension pour OGC
•Stockage efficace
•Ne sérialiser que lorsque c’est nécessaire
•Lire uniquement ce qui est nécessaire
•Opérations complexes comme Jointure Spatiale
•Minimiser le Shuffle quand c’est possible
•Calculer le moins possible (Utiliser à fond l’évaluation Lazy)
•Génération de Code : WholeStageCodGen (Uniquement Magellan)
•Eviter les appels virtuels autant que possible
•Garder les variables dans le Registre/Cache si possible