Processing Spatial
Big Data with
and SQL
Pr Hajji Hicham,
PhD, Msc, Eng
ESGIT Rabat IAV H2
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
Spatial Big Data: Big Picture - Location based service
- IOT
- Medecine et genomics
- Reseaux sociaux
- Monitoring du changement
climatiques
Vecteur Raster
Calcul dans le Spatial Big Data:
Paralléliser
Pourquoi Spark?
In Memory Facilité d’utilisation
Moteur Unifié
Partitionnement
Pt_X, PtY
Pt_X, PtY
Partitionnement n'est rien que diviser les données en parties et les stocker
dans le cluster.
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
Contraintes du
partitionnement
spatial
Spatial Data
Skew
Limites des
objets:
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
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
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
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
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
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
- 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
Malgré plusieurs Types de
RDDs, ils nous faut créer
d’autres pour le spatial:
Exp SpatialRDD
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)
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
LocationSpark
Frameworks Spatial : RDD Based
Problèmes avec les approches basées RDD
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
Extension Basée Dataframe/Dataset
Spark-SQL
•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
Exemple Dataframe
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
• 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
Exemple Dataset
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???
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
- 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
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
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
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.
Exemple requête SQL et comment les règles
s’appliquent
Exemple requête SQL et comment les règles
s’appliquent
Exemple requête SQL et comment les règles
s’applique
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
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
Exemples d’extensions spatiales
avec spark sql
(Projet Non Officiel )
SIGMOD’16,
June 26-July 01, 2016,
San Francisco, CA, USA
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
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
Réécriture de la jointure
Exemple RO dans Magellan
DataSource API
•Filtrer les données à la source et donner le relai à catalyst pour le reste de l’optimisation
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

Presentation intis 2017 version27112017

  • 1.
    Processing Spatial Big Datawith and SQL Pr Hajji Hicham, PhD, Msc, Eng ESGIT Rabat IAV H2
  • 2.
    Plan •Exemples •Contraintes du SpatialBig 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 leSpatial Big Data: Paralléliser
  • 5.
    Pourquoi Spark? In MemoryFacilité d’utilisation Moteur Unifié
  • 6.
    Partitionnement Pt_X, PtY Pt_X, PtY Partitionnementn'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.
  • 9.
    Partition 1 Partition2 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 DataSkew 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 fautretenir 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 Coutsupplé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 leSpatial 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 DistributedDataset •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 transformationdé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 Typesde RDDs, ils nous faut créer d’autres pour le spatial: Exp SpatialRDD
  • 17.
    Nous pouvons étendre l'APIspark 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 unCustom 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.
  • 20.
    Problèmes avec lesapproches basées RDD
  • 21.
    Problèmes avec lesapproches 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.
  • 23.
    •Collection distribuée dedonné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.
  • 25.
    Problèmes avec lesDataframe •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 (programmationfonctionnelle, 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.
  • 28.
    Select st_area(t1.SpatialUDT), st_area(t2.SpatialUDT) FromTable1 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 SparkSQL, 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 desfonctions 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êtesspatiales 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 maiscomment? 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 SQLet comment les règles s’appliquent
  • 35.
    Exemple requête SQLet comment les règles s’appliquent
  • 36.
    Exemple requête SQLet comment les règles s’applique
  • 37.
    Les stratégies d’exécutiondans 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 avecspark sql (Projet Non Officiel ) SIGMOD’16, June 26-July 01, 2016, San Francisco, CA, USA
  • 40.
    Exemple RO dans Règle -D’abordTransformer 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 SEdans 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 lajointure Exemple RO dans Magellan
  • 43.
    DataSource API •Filtrer lesdonnées à la source et donner le relai à catalyst pour le reste de l’optimisation
  • 44.
    Conclusion : Qu’estce 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