2.3.1 Limites de la norme ISO-19125
Malgré son rôle fondamental, la norme ISO-19125 manque sur certains points d’exhaustivité. Ainsi, la transformation du système de coordonnées employé par une géométrie n’est pas décrite par ce standard, alors même que son ajout faciliterait l’intégration de données provenant de sources diffé- rentes. Une telle méthode est pourtant décrite par des normes plus générales comme ISO-19107 et ISO-13249-3 et employée couramment par des solutions comme PostGIS et pourrait tout à fait être implémentée à l’aide des classes de conversion fournies par JTS. Au vu de ces possibilités et de leur intérêt, l’ajout d’une méthode de transformation du système de coordonnées au modèle d’Elcano a été rendue effective dans un article ultérieur [4.2.4.3].
2.3.2 Évolution du mode de sérialisation d’Elcano
Au début de la conception du système Elcano, la version la plus récente de Spark était la 1.6. Or, la Fondation Apache a depuis rendu disponible Spark 2.x. Cette nouvelle branche constitue une évolu- tion majeure, dans laquelle certaines fonctionnalités ont été abandonnées et d’autres réimplémentées. Malheureusement, il suit que la rétrocompatibilité avec les anciennes versions de Spark n’est pas sys- tématique. Ainsi, la possibilité pour le développeur de gérer la persistance des données dans Spark SQL à l’aide de types de données personnalisés (UDT16) consultables depuis SQL a été retirée de la version 2.017et remplacée par une solution totalement différente dans les versions ultérieures. Une telle rupture dans la continuité de Spark a obligé à repenser l’architecture d’Elcano, et en par- ticulier la façon dont les géométries y sont persistées dans Spark SQL en vue de leur consultation depuis des requêtes SQL. Afin qu’un compte rendu subsiste de cette évolution, cette section détaille les caractéristiques de la version d’origine, ainsi que les avantages de celle qui l’a remplacée.
La première version d’Elcano gérait la sérialisation des données spatiales en vue de leur lecture de- puis des requêtes SQL en implémentant un UDT18Spark spécifique appelé GeometryUDT. Celui-ci sérialisait les géométries dans le format binaire WKB19, afin de réduire leur volume en mémoire lors de leur stockage par Spark SQL. Lorsqu’ensuite les géométries étaient lues en tant que résultat d’une requête SQL, l’UDT les désérialisait afin qu’elles redeviennent des géométries.
Afin que Spark applique automatiquement les méthodes de sérialisation et de désérialisation de Geo- metryUDT lors du traitement de données spatiales, cette classe héritait de la classe UserDefinedType de Spark SQL. Réciproquement, la classe Geometry était définie par annotation comme un type de données traitable par Spark SQL. Une telle mise en œuvre était rapide à implémenter, mais comportait
16. UDT est un acronyme de « User Defined Type ».
17. Ce retrait a été commenté par un concepteur de Spark le 23 août 2016 sur http://stackoverflow.com/ questions/39096268/how-to-use-user-defined-types-in-spark-2-0.
18. UDT est un acronyme de « User Defined Type » 19. WKB est un acronyme de « Well-know binary ».
un revers : elle imposait de déclarer Geometry comme une classe concrète alors même que celle-ci n’était jamais instanciée. La figure2.4présente le modèle résultant de cet ancien mode de sérialisation, tandis que la figure2.5fournit un exemple d’implémentation en Scala de la classe GeometryUDT.
FIGURE2.4 – Ancien mode de gestion de la persistance dans Elcano
FIGURE2.5 – Implémentation Scala de la classe GeometryUDT
Pour sa part, le nouveau mode de sérialisation d’Elcano n’a plus recours aux UDT. Ce renoncement lui permet de rester compatible aussi bien avec la récente branche 2.x de Spark qu’avec des versions plus anciennes. Il continue par contre d’utiliser le format WKB pour stocker les géométries dans Spark SQL sous forme binaire, mais ces WKB ne sont traduits en géométries que lorsque des fonctions spatiales SQL leur sont appliquées plutôt qu’à chaque lecture SQL. Le nouveau mode de sérialisation réduit donc le volume de mémoire vive et le temps processeur utilisés pour traiter des géométries, ce qui rend le système plus performant. Le modèle résultant est également amélioré : comme la classe
GeometryUDT en disparaît, la classe Geometry ne doit plus être indiquée comme un type de données traitable par cet UDT et peut devenir abstraite. Par contre, un effet secondaire du nouveau mode de sérialisation est l’impossibilité d’obtenir directement une géométrie comme retour d’une requête SQL. Cependant, cet aspect est facilement contourné par l’extraction du WKB puis sa conversion en géométrie via la « fabrique abstraite » GeometryFactory d’Elcano.
2.3.3 Autre application de la norme ISO-19125-2
Si Elcano constitue le premier moteur de traitement spatial sous Spark à respecter la norme ISO- 19125-2, il existe un précédent dans l’environnement Hadoop. En effet You et al. ont conçu en 2015 ISP [122], un système reposant sur Impala qui permet l’intégration de données massives à partir de données spatiales. Les performances de la première version d’ISP (ISP-MC) sont décrites par ses concepteurs comme inférieures à celles de Spatial Spark [124]. Mais ce n’est plus vrai d’une version plus récente (ISP-GPU), qui semble dépasser Spatial Spark en vitesse d’exécution [125].
Cependant ISP-GPU est conçu spécifiquement pour être exécuté sur des processeurs multi-cœurs de type GPU20, ce qui rend l’emploi et l’évaluation de cette solution problématique. Son efficacité est en effet conditionnée par l’emploi d’un type de matériel dont peu de clusters disposent et que les autres prototypes de gestion des données spatiales massives ne sont pas à même de gérer. En outre, puisque You et al. ont initialement constaté la supériorité de Spatial Spark sur ISP à processeurs égaux [124], il semble légitime de supposer qu’un extension spatiale de Spark adaptée aux GPU surclasserait ISP-GPU. Les limitations d’Impala détaillées dans la section [1.1.1.2] plaident aussi en ce sens.