Actualités

22 octobre 2013-

Par Hari Krishnan et Christian Hasker

TL;DR : PROS est un éditeur de logiciels Big Data qui intègre des analyses prescriptives dans ses logiciels, ce qui permet à ses clients d'analyser leurs données et d'obtenir des informations et des conseils pour optimiser la gestion de leurs prix, de leurs ventes et de leur chiffre d'affaires.

PROS utilise Cassandra comme base de données distribuée pour des services à faible latence et à haut débit qui gèrent des charges de travail en temps réel comprenant des centaines de mises à jour par seconde et des dizaines de milliers de lectures par seconde. Par exemple, l'entreprise dispose d'un service en temps réel qui calcule la disponibilité des compagnies aériennes de manière dynamique en tenant compte des données de contrôle des recettes et des niveaux d'inventaire qui peuvent changer plusieurs centaines de fois par seconde. Ce service est interrogé plusieurs milliers de fois par seconde, ce qui se traduit par des dizaines de milliers de consultations de données. Notre couche de stockage pour ce service est Cassandra.

Pour sa solution en temps réel, PROS a réalisé qu'elle avait besoin d'un cache distribué hautement disponible, facilement extensible, avec une architecture sans maître, avec une réplication des données en temps quasi réel, même entre les centres de données, et qui peut gérer les lectures et les écritures en temps réel. PROS a évalué Cassandra par rapport à Oracle Berkeley DB, Oracle Coherence, Terracotta, Voldemort et Redis. Apache Cassandra est facilement arrivé en tête de la liste.

Hari, merci de nous avoir rejoints. Si vous pouviez commencer par nous dire un peu ce que fait PROS et quel est votre rôle, ce serait formidable.

PROS est un éditeur de logiciels de Big Data. La science du Big Data et l'analyse prescriptive de notre logiciel permettent à nos clients d'analyser leurs données et d'obtenir des informations et des conseils pour optimiser la gestion de leurs prix, de leurs ventes et de leur chiffre d'affaires. La pile logicielle de PROS est une combinaison de lourds travaux de backend et d'applications et de services en temps réel.

Nous avons réalisé plus de 600 mises en œuvre de nos solutions dans plus de 50 pays, dans plus de 30 secteurs d'activité. Nos principaux secteurs verticaux sont actuellement l'industrie manufacturière, la distribution, les services et les voyages. Je suis architecte chez PROS. Je me concentre principalement sur les architectures et les solutions temps réel et Big Data.

Votre plateforme optimise donc les ventes pour de nombreux secteurs, mais vous vous concentrez sur l'industrie du voyage. Quel type de données analysez-vous ? Il s'agit d'un type de moteur de recommandation, n'est-ce pas, pour les ventes ?

Nous analysons les transactions commerciales. Dans le domaine du voyage, il s'agit de réservations et dans le domaine du B2B, de transactions de vente. Nous appliquons la science des données aux données historiques afin d'obtenir des analyses prescriptives et des conseils sur la tarification, les ventes et le contrôle des recettes.

D'accord, c'est très bien. Si vous pouviez nous parler un peu de la façon dont vous utilisez Cassandra, de l'application sur laquelle vous l'utilisez et de ce qu'elle fait, ce serait très utile.

Nous utilisons Cassandra comme base de données distribuée pour des services à faible latence et à haut débit qui gèrent des charges de travail en temps réel comprenant des centaines de mises à jour par seconde et des dizaines de milliers de lectures par seconde. Par exemple, nous avons un service en temps réel qui calcule la disponibilité des compagnies aériennes de manière dynamique en tenant compte des données de contrôle des recettes et des niveaux d'inventaire qui peuvent changer plusieurs centaines de fois par seconde. Ce service est interrogé plusieurs milliers de fois par seconde, ce qui se traduit par des dizaines de milliers de consultations de données. Notre couche de stockage pour ce service est Cassandra.

Certaines de nos offres SaaS utilisent Cassandra comme magasin dorsal pour gérer une combinaison de charges de travail en temps réel et par lots basées sur Hadoop.

Donc, en parlant d'Hadoop et de Cassandra côte à côte, vous prenez les données de Cassandra et les mettez dans Hadoop et exécutez Batch et l'analyse sur cela, et ensuite cela retourne dans Cassandra, pouvez-vous nous en parler un peu ?

Oui, nous utilisons l'intégration Hadoop de Cassandra. Nos tâches Hadoop extraient des données de Cassandra, appliquent des transformations ou des analyses spécifiques et renvoient les données dans Cassandra. Nous n'utilisons pas l'édition Datastax Enterprise pour cette intégration, mais seulement l'installation Hadoop open source avec Cassandra.

D'accord, très bien. Vous avez parlé de votre cas d'utilisation, qui correspond manifestement à la force de Cassandra. Comment avez-vous découvert Cassandra et l'avez-vous choisi ?

En 2010, alors que nous améliorions les capacités fonctionnelles et non fonctionnelles de notre solution en temps réel, nous avons réalisé que nous avions besoin d'un cache distribué hautement disponible, facilement extensible, avec une architecture sans maître, avec une réplication des données en temps quasi réel, même entre les centres de données, et qui peut gérer les lectures et les écritures en temps réel. Nous avons évalué Cassandra par rapport à Oracle Berkeley DB, Oracle Coherence, Terracotta, Voldemort et Redis. Outre tous les critères techniques que j'ai déjà mentionnés, nous avons également utilisé le coût, la facilité d'utilisation et le soutien de la communauté du projet comme critères d'évaluation importants. Apache Cassandra est arrivé assez facilement en tête de la liste. Jusqu'à présent, ce choix s'est avéré très judicieux pour nous. Nous l'avons trouvé très polyvalent - un magasin de paires clé-valeur solide ainsi qu'un magasin avec de riches capacités de modélisation de données.

Apache Cassandra évolue rapidement et nous apprenons et comprenons ses capacités, en particulier en ce qui concerne la modélisation des données. Nous le considérons comme une base de données NoSql distribuée de choix pour nos services et solutions Big Data.

Vous avez parlé de la modélisation des données, quel était votre parcours ? Comment s'est déroulée l'adoption du modèle de données et quels conseils donneriez-vous à d'autres personnes désireuses de se lancer dans ce domaine ?

Je viens d'un milieu relationnel et d'un milieu NoSQL à paires de valeurs clés. Nous cherchions à remplacer un key-value store par quelque chose de plus performant en matière de réplication et de distribution de données en temps réel. Nous avons lu pas mal de choses sur Dynamo, le théorème CAP et le modèle de cohérence éventuel. Cassandra correspondait assez bien à ce modèle et le passage à Cassandra a été assez simple et techniquement facile. Au fur et à mesure que nous en apprenions davantage sur les capacités de modélisation des données, nous nous sommes progressivement orientés vers la décomposition des données. Nous avons commencé à utiliser les colonnes composites et les capacités de lignes étendues de manière assez intensive.

Mon conseil serait le suivant : si vous venez d'une base de données relationnelle avec une forte sémantique ACID, prenez le temps de comprendre le modèle de cohérence éventuel. Comprenez très bien l'architecture de Cassandra et ce qu'elle fait sous le capot. Avec Cassandra 2.0, vous disposez de transactions légères et de déclencheurs, mais ils ne sont pas identiques aux transactions traditionnelles des bases de données que l'on peut connaître. Par exemple, il n'y a pas de contraintes de clés étrangères disponibles... elles doivent être gérées par votre application. Comprenez clairement votre cas d'utilisation et vos modèles d'accès aux données avant de modéliser des données avec Cassandra. Lisez toute la documentation disponible.

Vous avez mentionné les transactions légères et les déclencheurs. Êtes-vous sur la version 2.0, l'envisagez-vous ?

Oui, nous commençons à expérimenter ces fonctionnalités. Pour l'instant, nous en sommes toujours à la version 1.2. Nous utilisons beaucoup les lignes larges et la version 2.0 propose des optimisations intéressantes pour la mise en cache des lignes larges. Un grand nombre de nos applications utilisent beaucoup les transactions et les capacités offertes par la version 2.0 seront très utiles.

D'accord, excellent. Pouvez-vous nous parler un peu de l'environnement dans lequel fonctionne Cassandra : matériel, nombre de nœuds, etc.

Bien sûr. La plupart de nos environnements de production actuels sont hébergés dans les centres de données de nos clients. Les déploiements des clients varient évidemment beaucoup en fonction de leurs besoins. À l'heure actuelle, tous nos déploiements se font sur des serveurs Linux x86/64 allant de 8 à 24 cœurs. Certains déploiements utilisent des disques SSD pour un accès rapide, tandis que d'autres utilisent des disques en rotation. Certains de nos déploiements sont répartis sur trois centres de données utilisant autant de clusters, tandis que d'autres sont répartis sur deux centres de données utilisant un seul cluster, et le plus courant est bien sûr un seul centre de données avec un seul cluster. Le nombre de nœuds varie, entre trois et dix par centre de données, et la taille des données par centre de données est généralement d'environ 100 gigaoctets.

Nous commençons à déployer sur Windows Azure pour nos offres SaaS. Ces déploiements porteront sur de très grands ensembles de données distribuées. Nous travaillons sur certaines limitations de la plateforme pour prendre en charge les déploiements multi-centres de données.

D'accord, c'est brillant. Y a-t-il autre chose que vous aimeriez ajouter ? C'était fantastique, merci beaucoup.

Je pense qu'à mesure que nous commençons à examiner les différentes offres et plateformes Cloud telles que GoogleCompute Engine et Windows Azure, nous aimerions voir évoluer une meilleure prise en charge des principales plateformes Cloud.

Nous déployons nos services dans plusieurs centres de données qui ne sont généralement pas ouverts les uns aux autres. Nous avons trouvé que le besoin de Cassandra d'ouvrir complètement les nœuds dans tous les centres de données était assez limitatif. Cela nous oblige à déployer plusieurs anneaux, qui doivent être synchronisés. Le mécanisme de synchronisation est quelque chose que nous devons développer et gérer pour le moment, mais j'espère que quelque chose évoluera dans ce domaine également. Il est assez courant d'avoir un seul centre de données maître et plusieurs centres de données esclaves en lecture seule. Redis fait un bon travail de réplication à sens unique dans ces scénarios. La solution dans ce cas est peut-être un déploiement hybride Cassandra-Redis.

Enfin, je tiens à souligner l'existence de la communauté Apache Cassandra elle-même ; Planet Cassandra est excellent. C'est une grande source d'information en ligne qui agrège le contenu de stackoverflow, twitter et slideshare. Les documents DataStax sont fantastiques, je recommande vivement à tout le monde d'y jeter un coup d'œil et de lire leur documentation. Je dois également mentionner le canal IRC Cassandra sur freenode. Il nous a été très utile pendant que nous écrivions une nouvelle implémentation de Snitch pour supporter les anneaux à travers les réseaux NAT-NAT. Je vous remercie donc.