Skip to main content

Sélections de la rédaction

Options de stockage des données pour GeoAnalytics Server

Published Date

ArcGIS GeoAnalytics Server d’Esri fournit un cadre fiable pour l’analyse de données spatiales massives. Pour que les fonctionnalités de GeoAnalytics s’exécutent avec succès, la première étape consiste à réfléchir à l’endroit où les données requises doivent être stockées. Ce billet de blogue est le premier d’une série portant sur les plateformes de données massives, qui est suivie par un ensemble de tutoriels connexes qui expliquent comment effectuer les différentes sortes d’analyses de données massives.

Les données massives se définissent généralement par le fait qu’elles dépassent les capacités de stockage, de traitement et d’analyse des systèmes traditionnels. Ce billet de blogue se veut une introduction parlant de la nature des données massives en général, et plus particulièrement dans le domaine spatial. Il présente aux lecteurs les options de sources de données qui existent pour GeoAnalytics Server, qui est la solution de traitement des données massives offerte par Esri dans son produit ArcGIS Enterprise. Il s’agit du premier d’une série qui traite des plateformes de données massives, comme Apache Hadoop et les services de stockage infonuagique. Ces billets seront suivis d’un ensemble de tutoriels connexes qui expliquent comment lire les données de l’une de ces plateformes et les utiliser dans l’écosystème Esri afin d’effectuer le genre d’analyses de données massives que les outils standard ne peuvent pas facilement traiter.

Trois grandes propriétés rendent les données massives (qu’elles soient de nature spatiale ou générale) difficiles à stocker et à traiter dans les bases de données relationnelles traditionnelles qui sont communes à la plupart des logiciels SIG commerciaux. Voici les propriétés en question :

  • Volume : le volume de données que les entreprises collectent chaque jour a monté en flèche ces dernières années. De plus, l’avènement de l’Internet des objets (IdO) et la présence généralisée de réseaux de capteurs génèrent un volume important de données liées à presque tous les aspects de la vie moderne. Ces facteurs nous obligent à repenser et à « réarchitecturer » les paradigmes traditionnels de stockage et de traitement des données. Le stockage de grands volumes de données dans une base relationnelle classique n’est plus une stratégie rentable ou efficace, d’autant plus que leur capacité est limitée quand on parle de pétaoctet.
  • Vitesse : les données massives ont tendance à arriver à grande vitesse. Par conséquent, les opérations de lecture et d’écriture doivent être très rapides et se dérouler en parallèle pour traiter l’énorme quantité de données qui sont générées en peu de temps. Avec le modèle de la base de données relationnelle, les opérations de lecture et d’écriture ne sont pas assez rapides pour enregistrer en temps réel les données générées en très peu de temps. De plus, la base de données relationnelle est fortement handicapée par son recours au format tabulaire, mal adapté au flux et au stockage de telles données massives. En bref, dans le modèle de la base de données relationnelle, les données sont stockées dans un certain nombre de tables liées, avec des schémas prédéfinis. Il en découle qu’on doit concevoir à l’avance les tables nécessaires, les relations entre ces tables et la définition des types de données de chaque colonne de table. À cela s’ajoutent d’autres contraintes, comme les définitions des champs primaires et de clés étrangères. Ce modèle peut être utile lorsqu’il s’agit de petits ou moyens ensembles de données (structurés) de l’ordre du gigaoctet (voire du téraoctet), mais pas toujours lorsque les ensembles de données sont de l’ordre du pétaoctet. En termes simples, la performance des opérations de lecture et d’écriture diminue de manière importante en raison de ces restrictions, alors que ce n’est pas nécessaire.
  • Variété : les données massives proviennent de différentes sources, dans des formats variés et des structures distinctes. Étant donné la grande hétérogénéité des flux (on parle de la vidéo et de l’audio, pour ne nommer que quelque sources), les données entrantes se présentent de façons structurées, semi-structurées ou non structurées, ou encore dans une combinaison des trois types. Les données structurées font référence aux informations qui ont un schéma prédéfini et qui peuvent être stockées de manière ordonnée dans un format ligne-colonne fixe. Par données non structurées, on entend des informations qui, contrairement aux données structurées, ne cadrent pas avec le format traditionnel ligne-colonne des bases de données relationnelles. Le texte, les images et les vidéos font partie des principaux types de données non structurées. Entre ces deux extrêmes, il existe une troisième catégorie appelée semi-structurée. Comme les données non structurées, les données semi-structurées ne s’intègrent pas bien dans le format tabulaire des bases de données relationnelles, mais il est toujours possible de créer des propriétés sémantiques (telles que des balises ou des clés) qui peuvent être utilisées pour interpréter le contenu des données. Les documents formatés en XML et JSON sont deux exemples de données semi-structurées. Le modèle de base de données relationnelle a été principalement développé pour stocker des données structurées; il n’est donc pas adapté aux deux autres grands types de données qui ont récemment pris de l’ampleur.

En raison des propriétés susmentionnées, les magasins de données non relationnels (tels que les bases de données NoSQL, les systèmes de fichiers distribués et les services de stockage d’objet) surpassent les bases de données relationnelles lorsqu’il s’agit de stocker et de récupérer des données massives. Une grande partie des données massives sont intrinsèquement spatiales, et une composante géographique s’y rattache. Pensons aux données sur la circulation, les mesures de stations météorologiques (qualité de l’air, vitesse du vent), la mobilité humaine, les accidents de voiture, la criminalité et la surveillance des espèces menacées. Il importe par-dessus tout de disposer d’un cadre robuste et fiable pour traiter et analyser les données massives spatiales. ArcGIS GeoAnalytics Server d’Esri procure cette robustesse et cette fiabilité. Cependant, pour que la fonctionnalité GeoAnalytics d’ArcGIS fonctionne correctement, la première étape consiste à réfléchir à l’endroit où les données requises doivent être stockées. La section suivante traite de la solution de stockage de données ArcGIS GeoAnalytics Server, qui est bien adaptée pour répondre au défi que représente le stockage des données massives.

GeoAnalytics Server

ArcGIS GeoAnalytics Server d’Esri est intégré dans ArcGIS Enterprise. Cette solution est précisément conçue pour traiter et analyser des données massives dans des scénarios semblables à ceux que j’ai décrits ci-dessus. Pour afficher les capacités de la plateforme GeoAnalytics Server, un site ArcGIS Server doit d’abord être doté d’une licence pour le rôle GeoAnalytics Server. La boîte à outils GeoAnalytics Server contient un ensemble d’outils puissants qui ont été développés de façon à ce que l’on puisse faire une analyse spatiale performante de données massives. Avant d’exécuter un outil GeoAnalytics, il faut préciser l’emplacement des grands volumes de données qui seront traités par la plateforme GeoAnalytics.

Les données nécessaires aux outils de GeoAnalytics sont accessibles à partir de quatre sources dans l’écosystème Esri :

  • Les couches d’entité hébergées dans un magasin de données relationnel ArcGIS Data Store : cette approche convient aux données SIG.
  • Les couches d’entité hébergées dans un magasin de données massives spatiotemporelles : cette approche représente une solution de stockage de données non relationnelle au sein de l’écosystème Esri. Le magasin de données massives spatiotemporelles prend en charge la mise à l’échelle horizontale et permet des opérations de lecture et d’écriture très performantes. Cette méthode permet d’archiver un grand volume de données en temps réel qui proviennent du serveur GeoEvent Server ou des données de suivi de localisation qui sont collectées par des applications telles qu’ArcGIS Tracker.
  • Les services d’entité : cette approche convient aux données tabulaires SIG ou non spatiales.
  • Les services de flux de données : grâce à cette approche, les outils GeoAnalytics peuvent recevoir des flux de données en temps réel par l’intermédiaire du serveur GeoEvent Server.

En plus des quatre sources de données internes mentionnées ci-dessus, quatre types de sources externes qui existent en dehors de l’écosystème Esri peuvent également être enregistrés auprès du serveur GeoAnalytics Server afin de fournir les données massives nécessaires aux outils GeoAnalytics :

  • Un partage de fichiers : cette approche fait référence à un répertoire qui réside sur le stockage d’un appareil local ou sur un serveur de votre réseau qui est accessible à toutes les instances du serveur GeoAnalytics Server. Toutes les données requises doivent être placées dans ce répertoire.
  • Le système de fichiers distribués Apache Hadoop (HDFS) : cette approche fait référence à un répertoire (dossier) parent situé dans l’environnement HDFS (une autorisation appropriée est également requise pour l’accès).
  • L’infrastructure d’entrepôt de données Apache Hive : cette approche se rapporte au référentiel central Metastore Hive. Apache Hive est un entrepôt de données dans l’écosystème Hadoop qui fournit une interface de type SQL. Metastore est le référentiel central d’Apache Hive qui stocke les métadonnées des tables de Hive.
  • Un stockage dans le nuage : cette approche fait référence aux services de stockage de données dans le nuage. Quatre types de services de stockage dans le nuage peuvent être enregistrés auprès du serveur GeoAnalytics Server, à savoir les compartiments Amazon Simple Storage Service (S3), les espaces de stockage blob de Microsoft Azure, le service de stockage d’objets Alibaba (OSS) et les magasins Data Lake de Microsoft Azure.

Dans le domaine spatial, les données telles que les fichiers SHP, ou les données non spatiales comme les fichiers texte ou .csv, peuvent être enregistrées au moyen de l’un des emplacements externes mentionnés ci-dessus auprès du serveur GeoAnalytics Server afin de fournir l’accès aux données requis pour tout outil GeoAnalytics. De plus, les résultats des outils GeoAnalytics peuvent être écrits dans un partage de fichiers enregistré, un HDFS ou un service de stockage infonuagique.

Bien que le partage de fichiers puisse offrir une sécurité accrue, cette option pourrait ne pas être recommandable pour de grands volumes de données en raison des inconvénients suivants :

  • Chaque machine a une certaine capacité limitée de stockage de données.
  • La performance de l’opération de lecture, qui est cruciale pour l’analyse de données massives, diminue considérablement lorsqu’elle est effectuée à partir d’une seule machine.
  • Les disques durs sont fragiles, ils peuvent tomber en panne à tout moment et des données peuvent être perdues.

Malgré ces inconvénients potentiels, une approche de partage de fichiers peut néanmoins être une bonne option pour le prototypage et le développement, ou dans les situations où un système local a une capacité suffisante pour stocker des données et où les performances ne sont pas un problème. Cependant, pour de nombreuses applications du monde réel, le référencement des données à l’aide des trois autres options (c’est-à-dire HDFS, Hive et service de stockage infonuagique) constitue une approche plus pratique. Le HDFS est le stockage principal de données de Hadoop qui permet aux utilisateurs de stocker de grands volumes de données sur des centaines de machines. Hive est une composante de l’écosystème Hadoop qui utilise un service Metastore pour stocker les métadonnées des ensembles de données, tandis que les ensembles de données réels sont stockés dans un des systèmes de fichiers compatibles Hadoop, comme HDFS, Kudu, S3 d’Amazon ou l’espace de stockage blob d’Azur. L’accès aux données par l’intermédiaire d’un Metastore offre généralement de meilleures performances que l’accès direct à partir du HDFS. Le stockage dans le nuage offre de nombreux avantages, comme l’évolutivité, la disponibilité et la rentabilité.

Tout en rappelant ces éléments d’introduction, simples mais importants, le prochain billet de blogue expliquera plus en détail les inconvénients des systèmes traditionnels de stockage de données pour le traitement des données massives et comment les stockages de données non relationnels permettent de surmonter ces problèmes. L’examen portera particulièrement sur l’architecture HDFS d’Apache et démontrera comment elle fournit une solution très fiable, rentable et performante pour le stockage et la récupération de données massives.

Ce billet a été écrit en anglais par Hossein Hosseini et peut être consulté ici.