Les TSDB ne sont pas toujours la bonne solution

Parmi toutes les données produites il est une catégorie particulière dont l'importance croit tous les jours, les séries temporelles.

Qu'est-ce qu'une série temporelle ?

On appelle série temporelle une séquence de valeurs indexées par le temps. Qu'il s'agisse de suivre l'évolution de la température, le cours d'une action ou d'une crypto monnaie ou encore la position d'un avion, les données sous-jacentes sont des séries temporelles et nécessitent des outils adaptés.

Cette nécessité s'explique par plusieurs caractéristiques des séries temporelles. D'une part leur rythme de production diffère des autres types de données, principalement parce qu'elles sont majoritairement produites par des machines et non des humains. Il en découle une génération de données beaucoup plus fréquente et avec peu ou pas d'interruption. On estime qu'un client bancaire actif est à l'origine d'environ 2500 transactions par an. À titre de comparaison l'analyse de phénomènes vibratoires dans le domaine industriel peut conduire à produire près de 50000 mesures par seconde en continu, soit 630 millions de fois plus de données par an.

D'autre part les traitements que l'on est amené à réaliser sur des séries temporelles sont souvent plus complexes que de simples agrégations. Pour reprendre le cas de l'analyse vibratoire ci-avant, il s'agira de passer avant tout les données dans le domaine fréquentiel via une transformée de Fourier puis d'analyser ces données spectrales pour détecter d'éventuels problèmes.

TSDB

Cette problématique de gestion des données de type séries temporelles a donné naissance à des outils dédiés appelés TSDB pour Time Series DataBase. Ces composants d'infrastructure sont optimisés pour ingérer des flux importants et pour organiser les données afin de limiter le volume occupé tout en offrant des performances d'accès importantes. Ces bases de données spécialisées se caractérisent également par des fonctionnalités d'analyse propres aux séries temporelles. Le but est d'éviter l'anti-pattern malheureusement trop classique qui consiste à considérer une TSDB comme une simple base de données et à effectuer les analyses dans des outils externes comme Python par exemple, en n'interagissant avec la TSDB que pour récupérer des données brutes, induisant par là-même des transferts inefficaces entre la base et le script d'analyse.

La plupart des TSDB se veulent généralistes, permettant théoriquement de les utiliser pour des séries temporelles dans des secteurs variés. Malheureusement en pratique il s'avère souvent que les compromis effectués lors de leur conception soient sources de problèmes dès lors qu'elles sont utilisées en dehors du cas d'usage initial. Il est par exemple délicat d'utiliser une TSDB comme influxdb, pensée pour le monitoring IT, dans un contexte IoT où des historiques profonds sont nécessaires, ou bien QuestDB, pensée pour la finance, pour tout autre usage qui nécessiterait par exemple de supporter des données arrivant dans le désordre ou bien le besoin de supprimer des données, ce qui n'est plus une option depuis l'entrée en vigueur du RGPD.

Approche tabulaire ou approche en série ?

Ces compromis de conception couvrent généralement plusieurs aspects, le modèle de données, l'organisation des données et les capacités d'analyse.

Les deux approches les plus fréquentes pour la modélisation des données sont l'approche tabulaire et l'approche en séries. La modélisation en tables offre une simplicité de compréhension pour les populations habituées aux bases de données relationnelles au détriment de la souplesse et de la flexibilité. L'approche en séries est beaucoup moins contraignante et devra être privilégiée pour tous les cas d'usages où les données remontées pourraient évoluer. Il est également important pour l'analyse des données de plutôt raisonner en séries qu'en tables afin de ne pas s'imposer de contraintes inutiles. L'inconvénient de l'approche séries est la problématique de cardinalité qui si elle n'est pas correctement gérée peut vite devenir limitante.

Concernant l'organisation des données, les TSDB optent généralement pour un modèle hybride permettant d'offrir des performances d'accès satisfaisantes tout en supportant les flux d'entrée élevés ainsi que les suppressions. Certaines TSDB vantent un stockage en colonnes. Cette approche indique généralement une modélisation en tables avec les restrictions inhérentes, attention donc de ne pas imaginer trop rapidement qu'il s'agit là d'une panacée.

Enfin les capacités d'analyse des TSDB varient grandement d'une solution à l'autre. La richesse offerte par chacune dépend grandement du cas d'usage initial adressé.

Ainsi de nombreuses solutions n'offrent finalement que des choses très simples permettant de faire des agrégations mais contraignant à tomber dans l'anti-pattern précédemment mentionné pour toute analyse plus avancée. Si un besoin d'analyse sur des volumétries importantes (soit historique profond, soit nombre de séries important) existe, l'immense majorité des solutions n'offrent pas de possibilité, orientant l'utilisateur vers des outils classiques comme Spark. Malheureusement cette approche présente plusieurs problèmes, d'une part tous les développements d'analyses effectués avec l'environnement propre à la solution ne seront généralement pas utilisables, d'autre part l'accès aux données devra nécessairement faire appel à la TSDB limitant de façon importante la performance du traitement parallèle.

Alors, que faire ?

On le voit, trouver une solution idéale pour gérer et analyser des séries temporelles est délicat, et souvent une solution étiquetée TSDB est choisie sans penser aux points qui viennent d'être évoqués. Pour de nombreux cas d'usages une TSDB n'est d'ailleurs probablement pas l'outil adapté, du moins pas un système intégré imposant son organisation des données et son environnement d'analyse accessible uniquement via la TSDB.

On peut distinguer deux familles de cas d'usage. D'une part ceux qui s'intéressent à des données vives, généralement récentes, et d'autre part ceux qui s'intéressent à des données historiques.

L'usage qui est fait des données va être radicalement différent. Dans le premier cas il s'agira d'afficher des tableaux de bord ou bien de faire des calculs qui seront intégrés dans une application tierce. Dans le second cas il s'agira plutôt d'analyses de tendance ou bien de détection de situations particulières sur un corpus important.

Si pour la première famille d'usages une interaction avec une TSDB convient parfaitement, la seconde nécessite des traitements parallèles en mode batch. On pourrait se dire qu'il est dans ce cas simple de mettre en place un cycle de vie des données où les données récentes sont mises dans une TSDB puis après un certain âge elles sont déchargées dans des fichiers type parquet, malheureusement il peut être nécessaire d'afficher un tableau de bord non pas sur les données récentes mais sur une période passée. Il faut donc que toutes les données soient accessibles à la fois via la TSDB ET en mode batch. Or une duplication des données n'est souvent pas envisageable tant les volumes en jeu sont conséquents.

Une approche différente avec Warp 10

Ce constat nous a poussé, chez SenX, à augmenter les possibilités de Warp 10 pour offrir une approche permettant de réconcilier les deux familles de cas d'usage. L'extension History File Store actuellement en technology preview permet en effet de stocker des données historiques de façon très efficace dans des fichiers qui peuvent ensuite soit être accédés depuis une instance Warp 10, soit manipulés en batch depuis des outils comme Spark ou Flink, dans les deux cas en bénéficiant de l'utilisation des mêmes fonctions d'analyse. Il est donc possible de capitaliser sur les développements faits dans l'un ou l'autre des environnements et de passer de l'un à l'autre sans dupliquer les données. Ces fichiers peuvent être stockés indifféremment sur des systèmes de fichiers locaux, sur HDFS ou bien sur un object store type S3.

Cette approche allie compacité du stockage, richesse de l'analyse et performances d'accès. Elle constitue la meilleure voie pour les cas d'usages comportant des historiques importants de données immutables :

• Surveillance aéronautique et maritime.
• Automobile.
• Équipements médicaux.
• Internet des Objets, Industrie 4.0

Pour participer à notre programme technology preview et essayer l'extension History File Store sur vos propres cas d'usages, n'hésitez pas à contacter nos équipes.