SlideShare une entreprise Scribd logo
1  sur  44
Télécharger pour lire hors ligne
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

Contenu connexe

Tendances

An Introduction to MapReduce
An Introduction to MapReduceAn Introduction to MapReduce
An Introduction to MapReduce
Frane Bandov
 
Apache Olingo - ApacheCon Denver 2014
Apache Olingo - ApacheCon Denver 2014Apache Olingo - ApacheCon Denver 2014
Apache Olingo - ApacheCon Denver 2014
Stephan Klevenz
 
Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...
Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...
Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...
VMware Tanzu
 
Debugging PySpark - PyCon US 2018
Debugging PySpark -  PyCon US 2018Debugging PySpark -  PyCon US 2018
Debugging PySpark - PyCon US 2018
Holden Karau
 

Tendances (20)

State of the Trino Project
State of the Trino ProjectState of the Trino Project
State of the Trino Project
 
Self-learned Relevancy with Apache Solr
Self-learned Relevancy with Apache SolrSelf-learned Relevancy with Apache Solr
Self-learned Relevancy with Apache Solr
 
Time Series Analytics with Spark: Spark Summit East talk by Simon Ouellette
Time Series Analytics with Spark: Spark Summit East talk by Simon OuelletteTime Series Analytics with Spark: Spark Summit East talk by Simon Ouellette
Time Series Analytics with Spark: Spark Summit East talk by Simon Ouellette
 
Initiation à Android
Initiation à AndroidInitiation à Android
Initiation à Android
 
Advanced Data Migration Techniques for Amazon RDS (DAT308) | AWS re:Invent 2013
Advanced Data Migration Techniques for Amazon RDS (DAT308) | AWS re:Invent 2013Advanced Data Migration Techniques for Amazon RDS (DAT308) | AWS re:Invent 2013
Advanced Data Migration Techniques for Amazon RDS (DAT308) | AWS re:Invent 2013
 
An Introduction to MapReduce
An Introduction to MapReduceAn Introduction to MapReduce
An Introduction to MapReduce
 
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )
 
ElasticSearch : Architecture et Développement
ElasticSearch : Architecture et DéveloppementElasticSearch : Architecture et Développement
ElasticSearch : Architecture et Développement
 
Teradata 13.10
Teradata 13.10Teradata 13.10
Teradata 13.10
 
Apache Olingo - ApacheCon Denver 2014
Apache Olingo - ApacheCon Denver 2014Apache Olingo - ApacheCon Denver 2014
Apache Olingo - ApacheCon Denver 2014
 
La démo DAX, le langage de Power BI [webinaire]
La démo DAX, le langage de Power BI [webinaire]La démo DAX, le langage de Power BI [webinaire]
La démo DAX, le langage de Power BI [webinaire]
 
Scala Talk at FOSDEM 2009
Scala Talk at FOSDEM 2009Scala Talk at FOSDEM 2009
Scala Talk at FOSDEM 2009
 
Securefile LOBs
Securefile LOBsSecurefile LOBs
Securefile LOBs
 
Spark SQL Tutorial | Spark Tutorial for Beginners | Apache Spark Training | E...
Spark SQL Tutorial | Spark Tutorial for Beginners | Apache Spark Training | E...Spark SQL Tutorial | Spark Tutorial for Beginners | Apache Spark Training | E...
Spark SQL Tutorial | Spark Tutorial for Beginners | Apache Spark Training | E...
 
Apache spark - Architecture , Overview & libraries
Apache spark - Architecture , Overview & librariesApache spark - Architecture , Overview & libraries
Apache spark - Architecture , Overview & libraries
 
Using Apache Calcite for Enabling SQL and JDBC Access to Apache Geode and Oth...
Using Apache Calcite for Enabling SQL and JDBC Access to Apache Geode and Oth...Using Apache Calcite for Enabling SQL and JDBC Access to Apache Geode and Oth...
Using Apache Calcite for Enabling SQL and JDBC Access to Apache Geode and Oth...
 
Ontology In A Nutshell (version 2)
Ontology In A Nutshell (version 2)Ontology In A Nutshell (version 2)
Ontology In A Nutshell (version 2)
 
Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...
Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...
Achieve Extreme Simplicity and Superior Price/Performance with Greenplum Buil...
 
Exadata troubleshooting
Exadata troubleshootingExadata troubleshooting
Exadata troubleshooting
 
Debugging PySpark - PyCon US 2018
Debugging PySpark -  PyCon US 2018Debugging PySpark -  PyCon US 2018
Debugging PySpark - PyCon US 2018
 

Similaire à Presentation intis 2017 version27112017

Similaire à Presentation intis 2017 version27112017 (20)

Spark SQL principes et fonctions
Spark SQL principes et fonctionsSpark SQL principes et fonctions
Spark SQL principes et fonctions
 
Distributed computing with Spark 2.x
Distributed computing with Spark 2.xDistributed computing with Spark 2.x
Distributed computing with Spark 2.x
 
Spark RDD : Transformations & Actions
Spark RDD : Transformations & ActionsSpark RDD : Transformations & Actions
Spark RDD : Transformations & Actions
 
BigData_TP3 : Spark
BigData_TP3 : SparkBigData_TP3 : Spark
BigData_TP3 : Spark
 
P8 03 presentation
P8 03 presentationP8 03 presentation
P8 03 presentation
 
Cours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkCours Big Data Chap4 - Spark
Cours Big Data Chap4 - Spark
 
spark_intro_1208
spark_intro_1208spark_intro_1208
spark_intro_1208
 
Spark
SparkSpark
Spark
 
Spark docker
Spark dockerSpark docker
Spark docker
 
LP_Admin_base_données.ppt
LP_Admin_base_données.pptLP_Admin_base_données.ppt
LP_Admin_base_données.ppt
 
Spark - An In-Memory Distributed Computing Engine.pptx
Spark - An In-Memory Distributed Computing Engine.pptxSpark - An In-Memory Distributed Computing Engine.pptx
Spark - An In-Memory Distributed Computing Engine.pptx
 
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017) Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
 
MariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQLMariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQL
 
Azure Camp 9 Décembre - slides session développeurs webmedia
Azure Camp 9 Décembre - slides session développeurs webmediaAzure Camp 9 Décembre - slides session développeurs webmedia
Azure Camp 9 Décembre - slides session développeurs webmedia
 
Syllabus advanced big data with spark
Syllabus advanced big data with sparkSyllabus advanced big data with spark
Syllabus advanced big data with spark
 
support_cours.pdf
support_cours.pdfsupport_cours.pdf
support_cours.pdf
 
Big data architectures
Big data architecturesBig data architectures
Big data architectures
 
DataStax Enterprise BBL
DataStax Enterprise BBLDataStax Enterprise BBL
DataStax Enterprise BBL
 
Analyse et optimisation des performances du moteur SQL Serveur
Analyse et optimisation des performances du moteur SQL ServeurAnalyse et optimisation des performances du moteur SQL Serveur
Analyse et optimisation des performances du moteur SQL Serveur
 
Architecture Big Data open source S.M.A.C.K
Architecture Big Data open source S.M.A.C.KArchitecture Big Data open source S.M.A.C.K
Architecture Big Data open source S.M.A.C.K
 

Plus de Dr Hajji Hicham

Plus de Dr Hajji Hicham (6)

SEED4NA _AI4DRONE.pdf
SEED4NA _AI4DRONE.pdfSEED4NA _AI4DRONE.pdf
SEED4NA _AI4DRONE.pdf
 
Urban Big Data .pdf
Urban Big Data .pdfUrban Big Data .pdf
Urban Big Data .pdf
 
Slides Edataday2021_V2.pdf
Slides Edataday2021_V2.pdfSlides Edataday2021_V2.pdf
Slides Edataday2021_V2.pdf
 
Visual Transformer Overview
Visual Transformer OverviewVisual Transformer Overview
Visual Transformer Overview
 
Processing Drone data @Scale
Processing Drone data @ScaleProcessing Drone data @Scale
Processing Drone data @Scale
 
Overview of Interpretability Approaches in Deep learning: Focus on Convnet ar...
Overview of Interpretability Approaches in Deep learning: Focus on Convnet ar...Overview of Interpretability Approaches in Deep learning: Focus on Convnet ar...
Overview of Interpretability Approaches in Deep learning: Focus on Convnet ar...
 

Presentation intis 2017 version27112017

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