par Les Geo Time Series (GTS) sont le cœur de la plateforme Warp 10. Seules les GTS qui peuvent être stockées dans la base de données Warp 10 et ce sont des citoyens de première classe à la fois dans FLoWS et WarpScript. C'est pourquoi il y a tant de fonctions WarpLib pour leur manipulation et tant de billets de blog faisant mention de GTS!
Par conséquent, comprendre le modèle GTS est la première étape de la maîtrise de la plateforme Warp 10. Heureusement, ce modèle est assez simple, mais puissant, et cet article passera en revue la plupart de ses aspects.
Que sont les Geo Time Series?
Geo Time Series est un modèle pour représenter des données de séries temporelle avec des informations de localisation facultatives pour chaque point.
Si vous préférez un exemple, imaginez un capteur de pollution atmosphérique sur un bus couplé à un GPS. Ce capteur mesure des niveaux d’ozone de temps en temps pendant que le bus se déplace. La séquence de lectures, chacune composée d’un horodatage, d’une latitude, d’une longitude, d’une élévation et d’un niveau d’ozone, forme une série.
Comme nous allons indexer le temps, nous les appelons séries temporelle et comme nous aurons non seulement la valeur du capteur mais aussi sa géolocalisation, nous les appelons Geo Time Series.
Les GTS sont indexés par le temps afin que vous puissiez facilement sélectionner une plage de temps et obtenir les valeurs et les positions associés. Vous pouvez également indexer des positions, mais cela n’est pas fait par défaut. L’index au temps est utilisé lors de l’obtention des données d’un stockage (LevelDB, HBase, mémoire, HFile, S3, etc.) mais aussi lors de la manipulation du GTS, notamment avec des frameworks.
Valeur en fonction de l’espace et du temps
Vous devez vous demander: pourquoi regrouper les positions et les valeurs dans un seul modèle? Il est en effet possible d’avoir une série temporelle de latitudes, une de longitudes, une d’élévations et une de valeurs. L’avantage du modèle GTS est triple.
Premièrement, cela contextualise la valeur mesurée. Si l’on garde le même exemple de pollution de l’air que ci-dessus, il est évident que le niveau d’ozone est fortement dépendant du temps, mais aussi de l'emplacement du capteur. Mathématiquement, nous pouvons voir les enregistrements comme des échantillons d’une fonction f (temps, lieu) = ozone, qui sont tous, commodément, dans le même modèle.
Deuxièmement, cela rend les données plus compactes. Le fractionnement des données en plusieurs séries temporelles nécessiterait la duplication des horodatages. Si vous multipliez cela par des milliards ou des billions d’enregistrements, le gain peut être important. Attention cependant, vous ne pouvez généraliser cela à aucune valeur. Par exemple, si nous avions un modèle tabulaire, factorisant l’horodatage pour plusieurs capteurs, les capteurs pourraient avoir des fréquences d’échantillonnage très différents, disons 1Hz et 100Hz, cela conduirait à des tables presque vides. Même si une solution pour éviter de perdre de l’espace peut être trouvée, la manipulation d’une telle table ne serait pas pratique.
Troisièmement, cela rend l’analyse beaucoup plus facile. Avoir toutes ces informations dans le même modèle est bien plus pratique que d’avoir à combiner plusieurs structures. Vous pouvez facilement analyser l’influence de l’altitude sur la pollution ou restreindre votre analyse à une zone spécifique.
Les Geo Time Series sont un sur-ensemble de séries temporelles
Pour les capteurs fixes, ce n’est évidemment pas une bonne idée de stocker leurs positions pour chaque valeur. Bonne nouvelle, le couple latitude / longitude et l’élévation sont tous deux optionnels! Ce cas est bien géré par Warp 10 et stocker les GTS sans emplacement et les charger en mémoire ne prend pas de place pour représenter les emplacements «manquants». Il n’y a aucun inconvénient à utiliser Geo Time Series sans emplacement.
En ce sens, les Geo Time Series sont un sur-ensemble de séries temporelles, car une GTS peut à la fois associer des horodatages pour représenter des valeurs ou des couples valeurs / position. Très souvent, un bon modèle de GTS mélange les deux types de GTS. Par exemple, lorsque vous avez un capteur à très haute fréquence sur un objet à déplacement lent, comme la fibre optique dans un yacht, stocker la position est une mauvaise idée car l'emplacement sera à peu près le même pour des milliers d’enregistrements consécutifs. Si vous avez besoin de combiner ces capteurs haute fréquence avec des données de localisation pendant l’analyse, c’est en effet possible.
Les Geo Time Series sont le modèle de données principal de Warp 10. Il répond à la plupart des besoins de modélisation de séries chronologiques, avec des informations de localisation facultatives.
Valeurs dans les Geo Time Series
Jusqu’à présent, nous nous sommes concentrés sur l’aspect spatial et temporel d’une GTS, mais il est temps de se concentrer sur les valeurs. Une GTS peut stocker 4 types principaux de valeurs: booléens, entiers longs, doubles et chaînes de caractères. Ces types suffisent à couvrir n’importe quel cas d’utilisation.
Les booléens sont les valeurs les plus simples qu’une GTS puisse stocker: vrai ou faux, c’est tout. Même si elles sont très simples, elles sont extrêmement utiles: une alerte est-elle déclenchée? Les trains d’atterrissage sont-ils au sol? Ils ont également un très faible encombrement disque et mémoire, ce qui les rend parfaits pour optimiser certains calculs.
Ensuite, probablement les types les plus courants: les GTS numérique. Un grand nombre de capteurs donnent des nombres à virgule flottante ou entiers, comme la température, les codes de squawk, le nombre d’écriture, etc…. Ils prennent plus de place que les GTS booléennes, mais le stockage est optimisé pour les entiers longs et les doubles.
Enfin, les chaînes de caractères sont le type le plus polyvalent mais n’est pas optimisé comme les autres types. Les valeurs de chaîne peuvent stocker des annotations ou des messages de journal par exemple. Elles peuvent également être utilisées pour stocker des structures plus complexes comme les chaînes JSON ou base64 qui rendent possible la sérialisation et la désérialisation des objets stockés dans GTS.
Pour aller plus loin, Warp 10 permet le stockage de valeurs binaires dans les GTS, qui sont représentées par GTS de chaînes de caractères codées ISO8859-1. Pour aller encore plus loin, Warp 10 permet le stockage de GTS encodées sous forme de valeurs binaires dans une GTS: le multi-valeurs. Cela rend possible des modèles de données très complexes qui ont à la fois d’excellentes performances et sont faciles à utiliser.
Organisation des Geo Time Series
Nommez votre Geo Time Series
Maintenant que nous avons défini précisément le contenu d’une GTS, il est temps de voir comment nous identifions une seule GTS ou un sous-ensemble spécifique de GTS. Chaque GTS est identifiée de manière unique par un nom de classe et des paires clé-valeur facultatives appelées label. C’est exactement le même principe que Prometheus avec son nom de métrique et ses labels et OpenTSDB avec son nom de métrique et ses tags, ce n’est pas une surprise puisque tous ces outils ont été inspirés par le modèle utilisé dans le Borgmon de Google. Il est très important de comprendre que le nom de la classe et les labels forment un identifiant unique. Changez quoi que ce soit, une valeur de label par exemple, et vous faites référence à une autre GTS.
Prenons un exemple. Imaginez que vous ayez installé 2 capteurs de vitesse du vent sur un pétrolier. Le nom de classe définit généralement la valeur mesurée. Dans notre cas, pour les deux GTS, le nom de classe serait com.company.fleet.aws car AWS signifie Vitesse du vent apparent. Ensuite, nous utilisons les labels pour définir précisément le capteur. Nous pouvons utiliser presque autant de labels que nous le souhaitons, mais deux suffiront: le nom du navire et le côté. Enfin, nous sélectionnons des valeurs pour les labels, mybigtanker sera associé à shipname et un capteur aura le port associé au côté tandis que l’autre aura le tribord.
Vous pouvez voir comment com.company.fleet.aws {shipname = mybigtanker, side = port} identifie de manière unique un seul capteur. Vous devez faire très attention à ne pas ajouter de label qui pourrait changer pendant la durée de vie de la métrique. Dans ce cas, ajouter quelque chose comme la marque du capteur ou la destination du bateau est probablement une mauvaise idée car le capteur pourrait être remplacé et la destination est appelée à changer. Les GTS sont déjà indexées au temps, il n’y a donc guère d’avantages à ajouter un label dépendante du temps.
Sélectionnez votre Geo Time Series
La façon dont les GTS sont nommées permet la définition d’ensembles de GTS à l’aide de sélecteurs. Vous voulez tous les GTS AWS sur le navire? Interrogez com.company.fleet.aws {shipname = mybigtanker}, les labels non spécifiés peuvent prendre n’importe quelle valeur. Vous voulez tous les GTS sur votre pétrolier? Requête ~com.company.fleet.*{Shipname=mybigtanker}, ~ signifie que le nom de classe suivant est une expression régulière. Vous pouvez également utiliser la même logique sur les valeurs de label pour sélectionner plusieurs bateaux avec com.company.fleet.aws{shipname~my(big|small)tanker}.
Auriez-vous besoin d’ajouter des informations supplémentaires à une GTS qui ne sont pas essentielles à son identification? Vous pouvez ajouter des attributs. Les attributs sont également des paires clé-valeur mais sont modifiables. Vous pouvez ajouter l’attribut {class = tanker} à votre GTS, ce qui vous permettrait de sélectionner facilement tous les pétroliers de la même manière que vous utilisez les labels dans les sélecteurs.
Manipulation des Geo Time Series
Il serait trop long de lister toutes les manipulations possibles qui peuvent être faites sur des GTS, mais nous allons vous donner quelques pointeurs vers des ressources utiles. Comme nous manipulons des séries temporelles, le temps est de la plus haute importance dans presque toutes les fonctions liées aux GTS. Par exemple, le framework MAP vous permet d’appliquer une fonction sur une fenêtre glissante sur une GTS. REDUCE combine des points de différentes GTS partageant le même horodatage, etc.
Ces deux fonctions font partie des frameworks qui sont presque toujours au cœur même de chaque script que vous allez écrire. Ce sont des fonctionnalités très puissantes et polyvalentes qui peuvent, par exemple, synchroniser les horodatages entre GTS ou rendre les horodatages de données irrégulières, uniformément espacés.
En savoir plus sur tous les frameworks disponibles dans WarpScript
Outre les frameworks, d’autres fonctions plus spécialisées facilitent considérablement l’analyse des données de séries temporelles. Certaines fonctions permettent le découpage d’une GTS selon différents paramètres: temps ou distance entre points consécutifs ou détection d’arrêt plus complexe. Il est également possible de détecter des anomalies dans des GTS à l’aide de différents algorithmes.
Toutes ces fonctions évitent d’avoir à réécrire du code complexe chaque fois que vous devez concevoir un script pour l’analyse de séries temporelle. Cela vous fait gagner du temps de développement et vous permet de vous concentrer sur la logique de votre analyse.
Plier les Geo Time Series à votre volonté
Cet article ne serait pas complet si nous ne parlions pas de la manière de corrompre ce modèle GTS. Attention, cette section concerne la modélisation et la manipulation très avancées des GTS.
Premièrement, les positions dans une GTS sont codées en tant que codes HHC 64 bits. Donc, pour le dire franchement, une GTS est une séquence d’enregistrements, chacun composé de 1 entier long, 2 entiers longs optionnels et un Boolean, un entier Long, un Double ou une chaîne de caractères. Vous utilisez normalement les 3 Longs pour représenter l’horodatage, l'emplacement HHCode et l’élévation, mais on peut en fait représenter n’importe quoi.
Si vous souhaitez stocker une GTS, les horodatages doivent être uniques dans une GTS. Vous pouvez stocker un identifiant unique dans des horodatages, par exemple, un MMSI, identifiant unique d’un navire, un ID de voie OSM ou même un HHCode. Cela vous permet de récupérer rapidement les informations dont vous avez besoin sans avoir besoin d’une base de données supplémentaire pour stocker ce type d’informations.
Si vous avez besoin que votre GTS stocke 3 Longs par point de données, vous pouvez les stocker dans la position, l’élévation et la valeur. Par défaut, l’entier long de la position est interprété comme un HHCode 64 bits et converti en latitude / longitude. Vous pouvez facilement récupérer la représentation Long avec la fonction <a href="https://www.warp10.io/doc/AIt6K4C7H3CEG3KBIot6" target="_blank" rel="noreferrer noopener">->GTSHHCODELONG</a>. Attention, le HHCode 91480763316633925 est réservé et signifie «pas de position», vous ne devez donc pas l’utiliser.
En résumé
Une Geo Time Series est un modèle polyvalent pour représenter des données de séries temporelles, bien adapté aux données provenant de capteurs et de métriques d’un large éventail de domaines. Les Geo Time Series peuvent éventuellement stocker un emplacement et une altitude pour chaque point, mais il n’y a pas d’inconvénient à utiliser une Geo Time Series sans localisation.
Elles peuvent stocker des booléens, des longs, des doubles et des chaînes de caractères, ce qui offre à la fois des performances et une compatibilité avec presque tous les types de données. Pour interroger les Geo Time Series, elles sont identifiées de manière unique par un nom de classe et des paires clé-valeur facultatives appelées labels. Cela permet de sélectionner une série unique ou un groupe d’entre elles pour les combiner et les analyser.
Enfin, les fonctions WarpLib offrent un large éventail de fonctionnalités pour manipuler les Geo Time Series. Le but de ces fonctions est de vous faire gagner du temps de développement et vous permettre de vous concentrer sur la logique de votre analyse.
Article Original : https://blog.senx.io/all-about-geo-time-series-model/
