Questions essentielles sur les base de données Time Series

Aujourd’hui, le gros des données Big Data est de nature temporelle. On le constate dans les médias comme chez nos clients : compteurs intelligents, transactions bancaires, usines intelligentes, véhicules connectés… IoT et Big Data font bon ménage.

Nous avons plusieurs fois traité des Time Series par le passé, à travers des études comparatives et la réalisation de PoCs (Proof of Concept), ou bien via la mise en production de certaines des solutions disponibles. Parmi les technologies utilisées, citons Graphana+OpenTSDB+HBase, Warp 10, Druid, Cassandra

Ces solutions sont-elles incontournables lorsqu’on traite des Time Series ? À partir de quel volume de données ces solutions apportent un avantage décisif ? Sont-elles matures ?

Légitimité

On peut répondre à la question “quand faut-il passer sur une base de données spécifique ?” de la même manière qu’on justifierait une transition d’une base de données classique à une plateforme Big Data : dès que la solution en cours n’est plus en mesure d’adresser ses services, que ce soit dû aux coûts, à la difficulté de maintenir un service opérationnel ou à la volumétrie. Cette volumétrie ne se limite pas au stockage des données mais aussi au profil des requêtes, à leur nombre (concurrency), à leur vitesse d’exécution (latency), aux accès en écriture, etc.

Solutions disponibles

Depuis quelques années, sont apparues plusieurs bases de données dédiées à la gestion de grandes quantités de données de mesure horodatées (time-series databases) dont la plupart sont des logiciels libres. Les solutions pour stocker des données temporelles sont diverses. Elles incluent :

Presque toutes ces solutions peuvent être considérées comme matures et sont en production. Nous avons par exemple testé la première fois OpenTSDB en 2011, pendant la préhistoire du Big Data. De part leur spécialisation, une bonne compréhension des cas d’usage et des PoCs comparatifs sont nécessaires avant validation.

Toutes ces solutions sont Open Source, mis à part InfluxDB. Plus précisément, son cœur de solution est OpenSource, cependant le code est propriétaire et les fonctionnalités de scalabilité (clustering) ne sont accessibles que par l’offre Enterprise. Cela peut entrer en conflit avec la vision “OpenSource First” d’un grand nombre d’entreprise.

Critères de comparaison

Il y a de nombreux aspects à comparer dont les performances, l’écosystème, les fonctionnalités ou encore l’opérabilité. Aussi, il convient de délimiter ce que l’outil apporte versus ce qui est de la responsabilité de l’application. Doit-on considérer la base de donnée comme un stockage brut, auquel cas HBase et Cassandra sont d’excellents candidats, ou bien comme embarquant des fonctionnalités spécifiques aux Time Series (eg requêtes GroupBy et TopN), nécessitant une solution spécialisée comme Druid ou InfluxDB.

Attention aux comparatifs douteux. Par exemple, notre opinion nous a été demandé à propos d’un comparatif InfluxDB vs ElasticSearch qui n’a aucune pertinence si le sujet est traité sous l’angle des performances. Cela revient en effet à comparer les performances d’une voiture familiale avec celle d’une voiture de course. On ne se porte pas acquéreur d’une voiture familiale pour sa vitesse. Ainsi ElasticSearch n’a pas vocation à être une base de données optimisée pour le stockage des Time Series mais, comme une base de données relationnelle, son modèle lui permet de le faire au détriment des performances.

Batch vs Streaming

Les données peuvent être stockées en fichier et être traitées par batch, que ce soit sur Hadoop (eg HDFS + ORC + Hive) ou bien sur le Cloud (eg S3 + Spot Instance + Spark). Ces architectures sont techniquement simples à mettre en œuvre et justifiables pour certain traitements d’Analytics et de Data Science ou dans l’attente de futurs cas d’usage.

À terme, des solutions plus ambitieuses imposent une alimentation et des traitements en flux continue (semi temps réel) ainsi que des requêtes interactives à très faible latence et/ou très forte concurrence. Ce type de requêtes impose des stockages qui échangent la flexibilité contre une forte spécialisation.

Pour choisir entre une architecture batch ou une architecture streaming, il y a plusieurs approches possibles :

  1. Des questions sont toujours en suspens : les cas d’usage ne sont pas encore très clairs ; les composants, le matériel et la quantité à commander ne sont pas encore définis ; on souhaite disposer d’un peu plus temps à la réflexion ou à l’expérimentation ; les données doivent être stockées au plus vite afin de construire le futur dataset et le délivrer à des populations de Data Analysts et Data Scientists. Alors le plus sage est de conserver une architecture batch avec par example un stockage dans HDFS ou bien S3.
  2. Les contraintes autour des données sont fortes : un ou plusieurs cas d’usage nécessitent des accès uniques, par exemple 1 ou N capteurs sur une plage de temps déterminée, à très faible latence et en fortes quantités ; les données sont alimentées au fil de l’eau et doivent être mises à disposition en quasi-temps réel tout au long de la chaîne d’ingestion ; le système est fortement sollicité en nombre d’écriture. Dans ce cas une base de données spécifique aux Time Series est requise.

Ces deux approches peuvent être complémentaires l’une de l’autre :

  • Parce qu’elles adressent des requêtes différentes: faible latence et forte concurrence (OLTP) contre haut débit de lecture (OLAP).
  • Sur des rétentions différentes, avec par exemple un stockage fichier long terme et du in-memory à court terme

Also published on Medium.

Par |2018-06-05T22:36:40+00:00March 19th, 2018|Big Data, Data Engineering|3 Commentaires

À propos de l'auteur :

Passionné de programmation, de données et d'entrepreneuriat, je participe à façonner Adaltas pour qu'elle soit une équipe d'ingénieurs talentueux partageant leurs savoir-faire et leurs expériences.

3 Comments

  1. David Pilato March 21, 2018 à 1:05 pm - Répondre

    A propos de

    > Ainsi ElasticSearch n’a pas vocation à être une base de données optimisée pour le stockage des Time Series mais, comme une base de données relationnelle.

    Alors, non, Elasticsearch (et non ElasticSearch) n’a pas vocation à être une base de données relationnelle. Loin de là. On peut classer elasticsearch dans la série des NoSQL orienté documents, donc plutôt une base “objet”.

    > son modèle lui permet de le faire au détriment des performances.

    De quoi parle t’on ici ? Elasticsearch est extrêmement performant lors du requêtage. Certes, la plupart du travail est réalisé à l’indexation. Donc je dirais pour simplifier à l’extrême qu’on paye le prix (mais très raisonnable) à l’indexation mais pas à la recherche.

    Nous avons des utilisateurs indexant 10 millions de documents par seconde. Pour citer Verizon, ils ont un cluster de plus de mille milliards de documents (https://www.elastic.co/use-cases/verizon-wireless).

    Beaucoup d’utilisateurs utilisent elasticsearch pour leurs time series. Nous avons ajouté des fonctionnalités de machine learning qui justement travaillent sur les time-series d’elasticsearch.

    Autrement dit, je pense que les deux phrases ici à propos d’elasticsearch, sont fausses.
    Ou en tout cas mériteraient des précisions sur le contexte des tests qui permet cette affirmation.

    David

    • David Worms March 21, 2018 à 1:26 pm - Répondre

      La citation complète est :

      > ElasticSearch n’a pas vocation à être une base de données optimisée pour le stockage des Time Series mais, comme une base de données relationnelle, son modèle lui permet de le faire au détriment des performances.

      Ce qui signifie qu’Elasticsearch possède un modèle de stockage suffisemment flexible pour stocker des Time Series. En aucun cas il est fait mention qu’un moteur de recherche distribué qui indexe des documents est une base de données relationnelle.

      > son modèle lui permet de le faire au détriment des performances.

      Le stockage des données n’est pas nativement ordonné selon l’axe temps, il est indexé. Comme tout index, cela impose un stockage complémentaire et un lookup sur la data et donc des performances dégradées.

      Nous aussi utilisons ElasticSearch chez l’essentiel de nos clients pour stocker des Series Temporelles. Nous le recommandons pour le confort que la solution nous offre et sur des volumétries maitrisées. Tout le sujet de l’article est que passé un certain volume, des centaines de tera bytes ou des dizaines de peta bytes pour un grand nombre de nos clients, ce mode d’indexation n’est plus compétitif face à des solutions dédiées au stockage de séries temporelles. Sur le terrain des performance, l’article mentionné plus haut comparant Elasticsearch et InfluxDB en est un bon indicateur.

  2. David PIlato March 21, 2018 à 2:02 pm - Répondre

    > Le stockage des données n’est pas nativement ordonné selon l’axe temps

    A lire: https://www.elastic.co/blog/index-sorting-elasticsearch-6-0

    > Comme tout index, cela impose un stockage complémentaire et un lookup sur la data et donc des performances dégradées.

    Non pas vraiment. Les data sont stockées également dans l’index. Donc en même temps qu’on récupère le hit qui matche, on récupère le JSON Source dans Lucene. Alors on peut assimiler ça à un lookup mais ce n’est pas un lookup externe.
    A noter que cela n’est pas obligatoire et que typiquement quand on fait des aggrégations, on met le parametre size à 0 car on ne veut plus un document mais du calcul sur des documents. Du coup, plus de “lookup interne” du tout…

Laisser un commentaire