La vélocité : un moyen d’exploiter la variabilité des données du Big Data

La vélocité : un moyen d'exploiter la variabilité des données du Big Data

Que ce soit pour des besoins techniques ou fonctionnels, un système produisant des données doit être contrôlé, supervisé ; cette activité permet d’assurer le bon fonctionnement de ce système, et également de créer de nouvelles fonctionnalités si l’on est capable d’exploiter la variation et le flux des données générées. Une des façons de le faire est l’utilisation des vélocités, notamment dans les moteurs de règles qui permettent une mise en œuvre facile.
Après une courte définition des vélocités, on s’attachera à décrire l’usage qui en est fait dans les moteurs de règles pour terminer par quelques notes sur leur implémentation technique.

Qu’est-ce qu’une vélocité ? 

Dans le monde de l’IT, une vélocité est une quantité d’information par période de temps. On retrouve le concept de vélocité dans plusieurs domaines tels que l’informatique décisionnelle ou la supervision.

Dans l’informatique décisionnelle, un système est fréquemment analysé sur des périodes de temps. Par exemple, pour un site e-commerce, les ventes de chaque rayon seront analysées par jour, par semaine, par mois…
Le nombre de ventes d’un rayon par semaine est une vélocité.

Dans le domaine de la supervision, des indicateurs sont suivis à l’aide de séries temporelles : charge CPU des serveurs, nombre de connectés simultanés sur une application web, etc.
Le nombre de connections sur la dernière minute est une vélocité.

En résumé, une vélocité capture l’évolution dans le temps d’une donnée métier. Son analyse et son suivi permettent de mesurer et contrôler l’aspect dynamique d’un système.

Vélocité et moteurs de règles 

Dans le domaine de la gestion du risque et de la fraude que les vélocités sont régulièrement voire systématiquement utilisées. En effet, pour détecter un comportement anormal, on va chercher à comparer le comportement actuel au comportement à d’autres périodes dans le temps. Cette comparaison peut se faire par l’usage de vélocités dans les règles métier.

Par exemple, dans la lutte contre la fraude, on vérifiera le nombre de commandes d’un client dans le dernier mois, ou l’usage d’un moyen de paiement dans les dernières 24 heures ou, plus largement, le montant des produits commandés d’un rayon sur la dernière semaine, ou encore le nombre de transactions à l’étranger dans les dix derniers mois. Pour résumer, toutes les données métier liées directement ou indirectement à une commande e-commerce ou à une transaction de paiement peuvent être utilisées dans les règles métier.

Mais contrairement à l’utilisation traditionnelle de l’informatique décisionnelle ou à la supervision qui manipulent les données en différé ou léger différé, le calcul de risques peut se fait en temps réel : à chaque commande ou à chaque transaction bancaire, les vélocités sont mises à jour et agrégées en temps réel. Il est donc nécessaire d’avoir une solution technique adaptée.

A titre indicatif, le tableau ci-dessous reprend les vélocités disponibles lors de l’exécution des règles dans un système de lutte contre la fraude. Elles sont mises à jour en temps réel à chaque commande passée dans le système.

En moyenne, pour une commande de 5 produits, une quarantaine de vélocités sont modifiées. Ces vélocités sont ensuite manipulées dans les règles métier.

Implémentation

En complément des besoins fonctionnels, plusieurs contraintes et exigences doivent être prises en compte pour un service de gestion des vélocités. On peut noter :

  • Précision : la donnée métier évolue dans le temps. Elle peut être stockée à la milliseconde ou pré-agrégée. Dans ce dernier cas, il faut définir la précision suffisante pour répondre aux besoins métier ; une précision à la seconde est généralement bien suffisanteCe besoin amène une contrainte technique de mises à jour nombreuses dans de faibles périodes de temps : par exemple, le nombre de commandes calculé au niveau d’un site e-commerce est modifié plusieurs fois par seconde.
  • Volumétrie : on l’a vu, le besoin de vélocités est commun à plusieurs domaines (lutte contre la fraude, lutte contre le blanchiment d’argent, etc.). En complément, dans les modes de déploiement actuels, une solution multi-tenant (c’est-à-dire capable de proposer des environnements cloisonnés les uns des autres) est un impératif. La solution technique doit donc supporter le volume généré par plusieurs tenants et plusieurs services fonctionnels.
  • Temps de réponse : les données métier sont agrégées sur des périodes glissantes variables, par exemple on aura des minutes pour les connexions utilisateurs, des heures pour un moyen de paiement, des jours pour le nombre de commandes. Il faut donc, pour une utilisation temps réel, que les agrégations puissent s’exécuter en quelques millisecondes par vélocité.

Pour l’implémentation, notre choix du stockage s’est porté sur Apache Hbase grâce notamment à ses colonnes de type compteur et à la possibilité de créer des colonnes à la volée. Apache HBase permet aussi de distribuer les agrégations côté serveurs et donc de rendre virtuellement infini la capacité de traitement.

Pour l’interopérabilité, un service REST, développé en Scala, expose les fonctions de gestion des vélocités permettant à toute application tierce de les exploiter sans intégration lourde. Outre, les fonctions exposées précédemment, le service rend possible des agrégations spécifiques pour une utilisation dans un modèle de prédiction.

Conclusion

Avec un système distribué NoSQL comme Apache HBase, il est maintenant possible d’utiliser des vélocités dans des règles métier. Vélocités qui permettent un contrôle plus fin et en temps réel du comportement d’un système produisant des données en temps réel.