Quartet FS et quasardb s’allient pour repousser les limites de l’analyse Big Data

Beaucoup d’articles de presse évoquent le potentiel économique des données. La donnée concourt à la création de nouveaux services et participe à la compétitivité des entreprises en permettant par exemple un pricing dynamique. Derrière ses nouvelles pratiques il faut affronter des défis technologiques dans le domaine des bases de données. Des défis relevés par l’éditeur français Quasardb et la société Quartet FS dont les solutions collaborent à présent pour repousser les limites du Big Data.

Edouard quasardb
Avec Edouard Alligand, fondateur de quasardb

Le développement d’internet a modifié considérablement le comportement des consommateurs. Aujourd’hui avant d’acheter, le consommateur se livre en quelques clics à une véritable étude de marché. Il utilise des comparateurs de prix qui le conduira à choisir entre tel magasin physique et tel site marchand. Le consommateur sait faire la part des choses entre la valeur ajoutée d’un produit et son prix. Internet est devenu un vaste marché ou les compétiteurs s’épient et ajustent leur prix en conséquence. L’exemple du groupe Accor illustre bien le problème. Après avoir vécu la désintermédiation avec des sites en ligne, l’arrivée des comparateurs de prix sur internet, il subit maintenant la concurrence des plateformes locatives comme Airbnb. Le groupe a tardé à réagir avant d’annoncer un investissement de 225 millions d’euros sur 5 ans dans le numérique qui devra permettre d’ajuster les tarifs en fonction d’un certain nombre de paramètres et de personnaliser les offres et les promotions. Ces initiatives reposent en partie sur la mise en place de solutions de Big Data.

Ajuster dynamiquement les prix avec la solution Active Pivot. La tarification est devenue une science. Lors d’un séminaire la FNAC expliquait la complexité de la gestion desActive pivot pricing prix. Les concurrents surveillent en permanence les prix, les mises à jour sont de plus en plus fréquentes et un même produit peut avoir différents prix selon le mode de commercialisation et le type de livraison. Dans ce contexte la FNAC a décidé d’industrialiser sa gestion des prix. Cela signifie d’être capable d’analyser de nombreuses données, de faire des simulations pour vérifier l’impact sur les marges et ensuite de transférer le nouveau prix dans le catalogue. Bien sur toutes ses opérations doivent s’exécuter en temps réel pour une meilleure efficacité. Un défi technologique rendu possible avec la solution Active Pivot de la société Quartet FS qui a développé une base de données analytique « in Memory ». Toutes les données sont donc chargées en mémoire du serveur et permettent d’obtenir des temps de traitements extrêmement rapides sans commune mesure avec un stockage sur disque. Il serait tentant d’étendre l’usage de ce type de solution à toutes les données de l’entreprise mais les analyses plus classiques sur des données historiques ne justifient pas en général le coût d’une solution In-Memory, car les requêtes sont ponctuelles, et les volumes de données peuvent dépasser 100 téraoctets.

Quartet FS et quasardb s’allient pour repousser les limites de l’analyse Big Data. Avoir les avantages du traitement en mémoire sans avoir l’inconvénient des coûts c’est ce que devrait permettre l’accord annoncé par Quartet FS et quasardb le 30 novembre 2015. Quasardb est un éditeur français éditeur français d’une base de données NoSQL Key-Value Store pour le traitement de Big Data. Grâce à son modèle scale-out cette technologie Big Data permet de répartir les données dans des fermes d’ordinateurs standards. La conception permet de gérer des bases de données de taille quasi illimitée. Active Pivot a été modifié pour que les utilisateurs puissent sélectionner des données stockées dans quasardb et les analyser ensuite dans Active Pivot. Les deux technologies s’échangent les données à la vitesse de 10 Gigaoctets par seconde. C’est à dire qu’il faut moins de deux minutes pour mettre à disposition un Téraoctet de données dans Active Pivot. Une fois en mémoire, les données peuvent être analysées de manière extrêmement performante par Active Pivot.

Dans le domaine du Big Data les bases de données semblent se concurrencer. Avec le temps et l’expérience on s’aperçoit qu’elles correspondent à des cas d’usages bien précis et que loin de s’opposer elles se révèlent complémentaires. Comme le fait remarquer Edouard Alligand, fondateur de quasardb, « ce partenariat démontre que les technologies NoSQL et In Memory ne sont pas concurrentes mais complémentaires. En alliant la puissance de calcul de l’in-memory aux capacités de stockage du NoSQL, quasardb et Quartet FS contribuent à faire progresser l’innovation en matière d’analyse des données ».

Pour en savoir plus sur quasardb vous pouvez participer au petit déjeuner que la sociétéquasardb seminaire 15 dec organise le 15 décembre. J’aurai le plaisir de faire l’introduction de la matinée. Peut être l’occasion de s’y rencontrer.

A lire également : Le Big Data exigera des bases de données NoSQL qu’elles repoussent encore leurs limites

Le Big Data exigera des bases de données NoSQL qu’elles repoussent encore leurs limites

Le Big Data sera un des éléments clé de la transformation numérique des entreprises. Le terme recouvre cependant de nombreuses technologies. Parmi celles-ci on trouve les bases de données NoSQL dont la multitude des offres nécessite de comprendre les principes qui régissent leur conception.

life-of-pix-free-stock-photos-light-sky-silo-windows-lillyphotographer

Face au déferlement de données auquel on a assisté ces dernières années, et à la prise de conscience que ces données pouvaient constituées une valeur sans commune mesure pour l’entreprise, une nouvelle vague de bases de données a vu le jour. Un mouvement amorcé en 2009 par les grands acteurs du web qui ont été les premiers à être confrontés à des volumétries inédites de données, structurées et non structurées, et à un nombre vertigineux de requêtes.

Les bases de données NoSQL adressent des enjeux différents de ceux des bases de données relationnelles historiques

Ces bases de données de type NoSQL viennent compléter (et non pas remplacer) les bases de données relationnelles qui se heurtaient à des limites d’évolutivité et de performances dans des environnements de données massives.

Avec la prolifération annoncée des objets connectés qui vont être autant de sources de nouvelles données, la gestion de bases de données massives se posera de manière accrue.

Les solutions de type NoSQL existent en grand nombre aujourd’hui et la difficulté consiste à choisir la base de données NoSQL adaptée à un contexte précis.

Pas réellement de définition précise d’une base de données NoSQL mais des objectifs communs :

Les bases de données NoSQL se différencient du modèle SQL par une logique de représentation de données non relationnelle qui se caractérise en général par :

  • D’importants volumes de données structurées et non structurées
  • Une multitude de requêtes simultanées
  • Une forte évolutivité de type scale out (évolution horizontale par rajout de serveurs)
  • De hautes performances
  • Pas de schéma (schema less) . La base de données n’impose pas de définition des éléments au sein d’un ensemble de données .

Les objectifs étant globalement partagés par l’ensemble des fournisseurs de bases de données NoSQL, comment dès lors faire la différence parmi une offre abondante ?

Les concepteurs de bases de données NoSQL ont du faire des choix d’architecture pour réaliser leurs objectifs. Les caractéristiques et les fonctionnalités d’une base de données NoSQL sont souvent la résultante de compromis et de combinaisons de choix complétés par des développements spécifiques de fonctionnalités.

Choisir une base de données nécessite de comprendre les choix architecturaux qui ont concouru à sa conception

   Le parti pris par les fournisseurs ne préjuge pas de la qualité d’une base de données NoSQL mais il permet de comprendre son positionnement et son adaptation par rapport à des cas d’usage et des conditions d’exploitation. Sans être exhaustif on peut recenser quelques choix d’architectures déterminants

1. Le choix du modèle de données : On trouve quatre modèles qui présentent chacun des intérêts et des limites. Les limites de chaque modèle pouvant être compensées certaines fois par des fonctions additionnelles

      • Clé/Valeur
      • Orienté colonne
      • Documents
      • Graphe

 2. Le mode de répartition des données : Face à une quantité de données importante et à de nombreux accès simultanés, il est nécessaire de répartir les données et les accès sur différents serveurs. Les moyens d’y arriver sont nombreux et on trouvera des systèmes totalement distribués ou de types master/slave. La topologie choisie et les algorithmes pour implémenter la distribution des données auront une incidence sur

  • L’uniformité de la répartition des données et des accès
  • La quantité maximale de données et de requêtes supportées avec le même niveau de performance.
  • Le maintien des performances en cas d’ajout ou de suppression d’une ressource
  • La simplicité de rajout d’une ressource
  • Le maintien des accès en cas de perte d’une ressource

3. La nature de l’algorithme:  Les algorithmes sont utilisés pour mettre en œuvre l’infrastructure distribuée en fonction du modèle de données choisi. Le choix de l’algorithme et son implémentation sont essentiels. Si on a par exemple choisi un modèle de données clé/valeur, pour des raisons de simplicité et de performances, et un système distribué de type pair à pair (peer to peer), pour un équilibrage de charge homogène, on pourra alors s‘appuyer sur un algorithme de type Table de hashage distribuée DHT (Distributed Hash Table) pour la mise en œuvre de la solution.

Dans cet exemple la combinaison « pair à pair » et l’algorithme « DHT » déterminera la qualité de performance, la souplesse d’évolution du cluster et le niveau de disponibilité selon les réplications permises.

4. La programmation:  Rarement mentionnés dans les documentations techniques, les choix de programmation ne sont pas sans conséquence sur les performances et la frugalité (l’usage minimum des ressources) de la base de données.  Plus la programmation sera proche de l’OS (programmation bas niveau), plus les performances seront optimisées et moins la consommation des ressources sera importante. Cela demande cependant une expertise forte et un investissement supérieur en temps de développement

Une maitrise complète des ressources par le code présente l’avantage de pouvoir assurer que certaines fonctions peuvent s’effectuer sans dégrader les performances. Une consommation minimum de ressource mémoire par exemple permet d’optimiser des fonctions de multithread et d’obtenir une scalabilité au sein d’un nœud d’un cluster sans impact sensible sur les performances.

Attention aux effets de seuils: Par définition lorsque l’on s’intéresse aux bases de données NoSQL on arrive dans des domaines extrêmes, ou qui tendront à le devenir dans l’avenir, en termes de nombre de requêtes et en quantité de données. La question est donc de s’assurer que les performances resteront constantes au fur et à mesures de l’augmentation des ressources.  On pourrait imaginer que le problème est résolu par le simple ajout physique de ressources.

Dans la réalité on constate une effet de seuil. Cet effet de seuil, comme son nom l’indique, se déclenche quand un niveau de requête est dépassé. La performance se dégrade alors sans possibilité d’y remédier par l’ajout de ressources matérielles. La manière dont on a implémenté le code de la base de données prend alors toute son importance . Plus l’effort de développement aura porté sur l’optimisation du code en utilisant de la programmation bas niveau, et plus tard l’effet de seuil se fera ressentir.

En fonction de chaque contexte et des prévisions de croissance l’effet de seuil peut être ou non un problème. Des benchmarks permettent de s’assurer que la solution envisagée supportera les charges prévues dans le temps.

Simplicité opérationnelle

Si les notions de scalabilité, de performances et de disponibilité sont particulièrement sensibles dans un contexte de bases de données NoSQl il ne faut pas pour autant négliger le côté opérationnel de la solution

  • Mise en œuvre : simplicité de l’interface utilisateur, utilisation ou non du format de données d’origine, besoin d’interruption lors d’ajout de ressources.
  • Intégration dans un environnement existant : infrastructures et standards du marché supportés

Pas de recette miracle donc mais des questions à se poser qui pourront nécessiter au final quelques tests pour valider que les niveaux de performances et les capacités d’évolution répondent bien aux cas d’usages concernés.

Documentations:

a lire également : Quartet FS et quasardb s’allient pour repousser les limites de l’analyse Big Data

 

Avec le Big Data c’est avant tout de l’économie de la donnée dont on parle

La médiatisation du déluge de données, avec ses chiffres gigantesques, pourrait faire penser que le big data est un domaine réservé aux très grandes entreprises . C’est avant tout de l’économie de la data dont on parle, cela concerne tout le monde et donne naissance à de prometteuses startups françaises.

billet bigdata

Le Big Data : une réponse à des limites techniques

Revenons à quelques notions essentielles. Le déluge de données, mis en avant en 2010 par The Economist, a souligné les problèmes techniques qui allaient se poser. Comment bâtir des architectures capables d’absorber en flux continu des quantités énormes de données et pour un cout acceptable ? Les grands acteurs du Web comme Yahoo et Google ont été les tous premiers à être confrontés à ce problème dès 2004.

Cela a donné naissance au fameux « frameworks » Hadoop  pour constituer des « data-lakes » ou des « data-hubs » capables d’être alimentés en continu par diverses sources de données et de pouvoir s’étendre facilement au gré de la croissance des données. Des bases de données NoSQL sont apparues également pour apporter des réponses en termes de performances et d’extensibilité (scalabilité) là où les bases de données relationnelles montraient leurs limites. On apportait ainsi une réponse technique au problème de gestion de la quantité et de la diversité des données.

L’important c’est la data

Seuls 2 à 3% des données sont réellement exploités. Le terme Big Data est un vecteur médiatique non négligeable qui a permis de sensibiliser le plus grand nombre à la valeur potentielle de la donnée et à son poids grandissant dans l’économie mais il devient trop imprécis quand on s’attaque aux réels cas d’usage.

La finalité est la création de la valeur à partir des données. Les algorithmes et le machine learning prennent ainsi une place grandissante pour exploiter avec de plus en plus de pertinence les données.

Avoir un projet Big Data n’est pas un objectif en soi et n’a pas de réelle signification. La véritable stratégie consiste à identifier les sources de données disponibles et à imaginer les cas d’usages qui pourraient bénéficier à l’entreprise. Ensuite viendra la question de l’architecture à mettre en place. Les choix technologiques dépendront alors de la volumétrie, de la diversité, du flux des données et de la performance d’accès nécessaire.

Selon le contexte de l’entreprise et des cas d’usage, les data seront « Big », « Small » ou « fast » et l’architecture technique sera bâtie en conséquence. On devra tenir compte des perspectives et de la stratégie de l’entreprise pour avoir une cohérence d’ensemble et une pérennité des choix. Au-delà des aspects techniques, l’organisation et les interactions entre les directions métiers et la direction informatique seront essentielles pour éviter la juxtaposition de solutions disparates.

Le Big Data dans l’entreprise ou dans le Cloud :

Axelle Lemaire, secrétaire d’état au numérique, a encore rappelé, lors du débat d’orientation stratégique à l’assemblée nationale, l’importance de l’économie de la donnée. Toutes les entreprises doivent se sentir concernées par cette économie de la donnée et peuvent, selon leur taille et leur prévision, mettre en œuvre des solutions de Big Data dans leur centre informatique ou bien utiliser des services de big data dans le cloud.

On peut se réjouir de voir en France de nombreuses startups innover dans le domaine du Big Data. Impossible de toutes les citer mais en voici quelques-unes qui me paraissent intéressantes :

Criteo: Une réussite pour ce spécialiste français du re-targeting. De nombreuses sociétés de e-commerce utilisent ses solutions basées sur des technologies de big data performantes afin d’inciter les internautes à revenir sur leurs sites marchand.

VirtualScale : Considérée par EBG comme une des 10 startups les plus prometteuses, cette jeune société française propose des solutions d’infrastructure Big Data dans le Cloud.

Quasardb : A ma connaissance c’est la seule solution européenne de type NoSQL et elle est française. Elle se présente comme la nouvelle génération des bases de données NoSQL. Elle a annoncé tout dernièrement son intention d’offrir la solution dans  le cloud Azure de Microsoft

Tastehit : Cette toute jeune société, passée par l’incubateur NUMA, utilise le machine learning pour personnaliser un site commerçant en fonction du visiteur et l’inciter à rester sur le site. La solution, simple de mise en œuvre, est proposée sous forme d’un logiciel en mode SaaS (software as a service) dans le cloud. L’architecture de type NoSQL utilisée par Tastehit est hébergée par un opérateur de cloud..

A n’en pas douter les entreprises qui n’auront pas su, dans l’avenir, exploiter les données perdront un sérieux avantage concurrentiel et passeront à côté de nouvelles opportunités commerciales.