Nos Services


Traitement des données

Volume des données, variété des sources… plus une organisation avance dans la collecte de données, et plus le traitement et la valorisation de ces données sont complexes. Et si le gestionnaire ne veut pas se retrouver très vite avec un « cimetière de données », il doit respecter trois règles très simples. Première règle : c’est la qualification des données collectées. C’est-à-dire la capacité pour n’importe quel utilisateur d’identifier la source et la nature des données qu’il consulte. Deuxième règle : c’est la fiabilisation : on ne bâti pas une stratégie globale sur des fondations bancales. L’horodatage, la synchronisation des sources sur un même pas de temps, la gestion des trous de données et la certification en sont autant de composantes. Troisième règle : c’est l’automatisation du parcours de la donnée. Cette automatisation doit permettre à l’utilisateur de se concentrer sur des tâches à plus forte valeur ajoutée que le relevé manuel d’index ou la gestion de tableaux Excel multiples… Logiquement, cette règle dépend des deux premières, car on n’automatise pas un processus qui n’a pas été auparavant testé et éprouvé. Ces principes forment la base de chaque nouveau projet. Sans eux, les services qu’on y ajoute formeront un château de sable voué à s’écrouler.

Un système d’information à la pointe de la technologie

M2M S.A utilise une base de données de type NoSQL gérée avec le middleware Cassandra.

Cette configuration nous donne des capacités quasi-illimitées pour le traitement, l’agrégation, et l’organisation des données des clients sur la plateforme. Et c’est pour cette raison qu’elle est utilisée par les grands groupes comme Microsoft, Facebook, Ebay ou IBM : elle est la réponse optimale aux problématiques posées par la génération de données massives, non structurées et de natures différentes. Si on veut comprendre ce qui différencie cette base d’autres outils existants, il faut notamment mentionner : La répartition des données : les données d’un nœud (désignation pour une instance de Cassandra) sont automatiquement répliquées vers d’autres nœuds (différentes machines).

Ainsi, si un nœud est hors service, les données présentes sont disponibles sur d’autres nœuds. En calibrant le facteur de réplication, on peut changer le nombre de nœuds où la donnée est répliquée. Une autre instance de Cassandra est désignée sous le terme de cluster : il s’agit d’un groupe d’au-moins deux nœuds. Les data center, eux, désignent des clusters délocalisés. Avec Cassandra, la réplication peut se faire sur différents data center. Les points individuels de défaillance sont donc inexistants et les nœuds qui sont tombés peuvent être remplacés sans indisponibilité du service.

L’architecture décentralisée : dans un cluster, tous les nœuds sont égaux. Il n’y a pas de notion de maître, d’esclave, ou d’instance qui aurait à sa charge la gestion globale. Cette organisation horizontale signifie donc que le traitement des opérations clientes (requêtage et calculs immédiats) est réparti en temps réel entre plusieurs data centers, garantissant une faible latence pour l’utilisateur final.

L’élasticité : la base s’adapte en temps réel au volume de données générées par l’organisation. Elle ajoute des nœuds dans ses clusters en fonction du taux de charge et ce, sans indisponibilité du système ni interruption des applications. La taille, la structure et la nature des informations importent peu : le traitement est réparti de façon égale sur plusieurs clusters. Le volume de données augmente ?

Des grappes de serveurs peuvent s’ajouter en quelques clics.

Le modèle de données : Le modèle de données de Cassandra s’appuie sur un schéma dynamique, avec un modèle de données orienté en colonne. Cela signifie que, contrairement à une base de données relationnelle, il n’est pas nécessaire de modéliser toutes les colonnes puisqu’une ligne n’a potentiellement pas le même ensemble de colonnes. Les colonnes et leurs métadonnées peuvent être ajoutées par l’application lorsque cela s’avère nécessaire.

En fait, le modèle de données de Cassandra est créé pour répondre à des problématiques de données distribuées et diffère complètement d’un modèle classique de base de données relationnelle où les données sont stockées dans des tables qui sont, dans la plupart des cas, en relation entre elles. En outre, dans un modèle relationnel, les données sont généralement normalisées. Afin d’éviter la redondance. Des jointures sont faites entre les tables sur des clés communes afin de satisfaire les requêtes. Dans Cassandra, le Keyspace est le conteneur des données de l’application (un peu comme une database ou un schéma pour une base de données relationnelle). Dans ces keyspaces se trouvent une ou plusieurs familles de colonnes (qui correspondent aux tables en base de données relationnelles). Ces familles de colonnes contiennent des colonnes ainsi qu’un ensemble de colonnes connexes qui sont identifiées par une clé de ligne. En outre, chaque ligne d’une famille de colonnes ne dispose pas nécessairement des mêmes colonnes qu’une autre ligne. Enfin, Cassandra n’impose pas de relations entre les familles de colonnes au sens base de données relationnelles : il n’y a pas de clés étrangères et les jointures entre familles de colonnes ne sont pas supportées. En bref, chaque famille de données dispose de son ensemble de colonnes destinées à être consultées ensemble pour satisfaire les requêtes spécifiques à l’application.