#3 Mettre à disposition la donnée lorsque l'on est Data Engineer
III. De nos jours : Les outils modernes utilisés pour le serving
Les bases de données orientées colonnes ont remplacé les cubes OLAP en raison de leurs meilleures performances pour les requêtes analytiques, sans nécessiter de pré-agrégation des données. Elles permettent de lire uniquement les colonnes pertinentes, ce qui réduit les temps de traitement et optimise la compression des données. Contrairement aux cubes OLAP, elles évitent la complexité de création de pipelines ETL, offrant ainsi une flexibilité et une évolutivité supérieures pour les analyses décisionnelles.
Les bases de données orientées colonnes ne sont pas les seuls outils disponibles pour donner accès aux données.
Il existe notamment ce qu’on appelle des bases de données clé-valeur, ou Key-Value Store.
Une base de données clé-valeur stocke les données sous forme de paires clé-valeur, où chaque clé est unique, et la valeur correspondante peut être de différents types de données. Ces bases de données sont conçues pour être simples, évolutives et rapides, notamment pour les opérations de lecture/écriture sur de grands volumes de données avec des requêtes simples basées sur les clés.
Au-delà de ces considérations, j’aime bien, pour ma part, séparer les outils en quatre catégories pour le serving en fonction des besoins :
Besoins de requêtes relationnelles :
Il est possible que votre client est besoin via l’api ou pour son dashboard de faire des filtres, des légers calculs et surtout des jointures entre les données. Pour ce genre de besoins classiques une base de données relationnelle est tout indiquée.
Besoin d’accès très rapide à la donnée :
Les Key-Value Stores seront très adaptés à ce besoin. Largement utilisés dans des contextes Big Data, les Key-Value store sont des énormes dictionnaires qui permettent d’avoir accès en un temps records aux informations stockées en fonction de la ou des clés que vous requêtez. Ils permettent aussi des écritures très rapides.
On peut citer : GCP Big Table, DynamoDB whez AWS dans des contextes Big Data.
De plus il est assez récurrent que l’on ait besoin de faire de gros calculs sur notre donnée ! C’est généralement tout l’intérêt d’une infrastructure data, calculer des chiffres d’affaires, des kpis et autres mesures intéressantes, cela fait écho au précédent article.
On a ici deux familles de technologies : celles qui préagrègent les données et celles qui agrègent tout en temps réel.
Les technologies qui préagrégent la donnée :
On pourrait placer ici notre fameux cube OLAP. Nous avons, par exemple, Cube ou encore le méconnu Apache Kylin.
Cube : Cube anciennement Cube.js est un framework open-source d'analyse de données qui permet de créer un backend rapide et flexible pour construire des applications analytiques en pré-agrégeant les données et en fournissant une API avec d’autres fonctionnalités (sécurité, caching, et couche sémantique principalement).
J’avais écrit un post linkedin il y a plusieurs mois dessus, si vous voulez plus de détails.
Les pré-agrégations sont définies dans le modèle de données Cube. Elles sont créées soit à la demande lorsqu'une requête correspond à une définition de pré-agrégation, soit selon un planning défini.Les pré-agrégations sont généralement stockées dans une base de données séparée optimisée pour les lectures rapides, comme Cube Store.
Apache Kylin : Apache Kylin est un moteur d'analyse distribué open-source conçu pour le big data, permettant d'effectuer des requêtes OLAP rapides sur de grands ensembles de données.
Il tire parti de l'OLAP multidimensionnel en pré-agrégeant les données dans des cubes, ce qui permet aux utilisateurs d'effectuer efficacement des requêtes analytiques complexes sur plusieurs dimensions.
Je dois avouer que je n’avais jamais entendu parler d’Apache Kylin avant d’écrire cet article. Mais J’ai étais très amusé de trouver une technologie ayant repris l’idée des analyses multidimensionnelles et de la préagrégation à la façon des cubes OLAP.
Kylin propose également une API RESTful pour les requêtes, permettant aux applications de récupérer rapidement des résultats analytiques, parfait pour une API.
Il existe aussi des stratégies intéressantes pour préagréger les données dans un Key-Value Store comme DynamoDB (ici un article très intéressant d’AWS expliquant comment mettre à jour des metrics stockées dans un key value store à chaque nouvelle arrivée d’un message grâce à des Lambdas : https://aws.amazon.com/fr/blogs/database/build-a-near-real-time-data-aggregation-pipeline-using-a-serverless-event-driven-architecture/)
Les technologies d’agrégation en temps réel : Les technologies d’agrégation en temps réel comme ElasticSearch, ClickHouse ou encore Apache Druid.
ElasticSearch : Elasticsearch est un moteur de recherche et d'analyse de données open source distribué, basé sur Apache Lucene et développé en Java. Très connu pour la recherche textuelle dans des documents ou dans les logs, il permet de stocker, rechercher et analyser rapidement de grands volumes de données, presque en temps réel.
Pour effectuer des agrégations en temps réel avec Elasticsearch, on peut utiliser son API REST pour envoyer des requêtes d'agrégation sur les données indexées. Ces agrégations permettent de calculer des métriques, de créer des regroupements ou des distributions statistiques sur les données, le tout de manière très rapide grâce à la nature distribuée d'Elasticsearch.
Par exemple, on peut facilement obtenir des sommes, des moyennes, des minimums/maximums ou des histogrammes sur de grands ensembles de données en quelques millisecondes.
Bien qu’ElasticSearch soit un super outil, concernant les agrégations temps réel, l’outil suivant est encore plus performant.
Clickhouse : Clickhouse est un système de gestion de base de données orienté colonnes, open source, conçu pour l'analyse en temps réel de grands volumes de données.
Clickhouse a été conçu à la base par Yandex, la société russe, pour faire de la récolte de click et des calculs sur ces données sans préagréagation.
D’ailleurs le nom "ClickHouse" est la contraction de "Clickstream Data Warehouse" ;).
Clickouse est en effet très performant. Des entreprises avec des fortes contraintes temps réel l’utilisent comme moteur de calcul comme ContentSquare notamment.
Avec de si grosses performances aucun problème pour envoyer des requêtes api, Clickhouse propose même nativement de créer des endpoints pour les requêtes.
Apache Druid : Druid est une base de données distribuée, orientée colonnes et open source, écrite en Java. Druid est conçu pour ingérer rapidement d’énormes quantités de données d’événement et renvoyer les données avec un faible temps de latence.
Druid est conçu pour les applications qui nécessitent une gestion en temps réel des données en continu, garantissant que les nouvelles données sont immédiatement prises en compte dans les requêtes.
ClickHouse, en revanche, n'offre pas cette garantie, ce qui le rend moins adapté pour des scénarios de mise à jour instantanée des données.
Par exemple les ingénieurs de Netflix ont créé une application analytique avec Druid qui ingère 2 millions d'événements par seconde, intégrant des filtres, des agrégations et des requêtes de type "group by" pour détecter des anomalies au sein de leur infrastructure, l'activité des endpoints et le flux de contenu à travers un dataset de plus de 1,5 trillion de lignes – le tout dans le but d'optimiser la livraison de contenu.
Conclusion
Dans cette série d’articles, je suis allé plus en profondeur sur la mise à disposition des données via la couche de "serving". Nous avons pu observer l’évolution, au fil des décennies, des technologies conçues pour répondre à ce besoin.
Les technologies que j’ai mentionnées dans ce dernier article ne sont qu’un échantillon de ce qui existe.
J’ai présenté de nombreux outils de stockage, mais une autre partie importante de la couche de "serving" est le développement au-dessus de ces backends de webApi entre autres pour permettre le requêtage par les clients.
Merci pour votre lecture, et à très bientôt pour de nouveaux articles ! ;)