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.
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
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
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
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
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
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
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.
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
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
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