Exploration de données en temps réel avec les tranches

Joannes Vermorel

Il y a deux mois, nous avons déployé une nouvelle fonctionnalité majeure pour Lokad : notre première exploration de données en temps réel. Cette fonctionnalité est codée sous le nom de tranches de tableau de bord, et elle nous a demandé une refonte complète du traitement des données de bas niveau qui alimente Envision. Avec les tranches de tableau de bord, chaque tableau de bord devient un dictionnaire complet de vues de tableau de bord, qui peuvent être explorées en temps réel à l’aide d’une barre de recherche.

Par exemple, en tranchant un tableau de bord destiné à un inspecteur de produit, qui rassemble en un seul endroit toutes les informations sur un produit - y compris les prévisions de demande probabiliste et de délai d’approvisionnement, par exemple - il est maintenant possible de passer en temps réel d’un produit à l’autre.

À l’heure actuelle, Lokad prend en charge jusqu’à 200 000 tranches (alias vues de tableau de bord) à produire pour un seul tableau de bord ; et ces tranches peuvent être affichées en temps réel grâce au sélecteur, qui est doté d’une fonction de recherche en temps réel pour faciliter l’exploration des données. Contrairement aux outils de business intelligence (BI), ces tranches peuvent contenir des calculs très complexes, et ne se limitent pas à la simple découpe d’un cube OLAP.

En ce qui concerne le traitement des données et les rapports, il y a généralement deux camps : le traitement en ligne et le traitement par lots. Le traitement en ligne prend un flux de données, et il est généralement attendu que tout ce qui est affiché par le système soit toujours à jour : le système ne prend pas plus de quelques minutes, voire quelques secondes, de retard par rapport à la réalité. Les cubes OLAP, et la plupart des outils appelés business intelligence, relèvent de cette catégorie. Bien que les analyses en temps réel soient très souhaitables, non seulement d’un point de vue commercial (les données fraîches sont meilleures que les données obsolètes), mais aussi d’un point de vue utilisateur final (la performance est une fonctionnalité), elles présentent également des limitations strictes. En d’autres termes, il est extrêmement difficile de fournir des analyses intelligentes en temps réel. Par conséquent, tous les systèmes analytiques en ligne présentent des limitations sévères en ce qui concerne le type d’analyse pouvant être effectué par le système.

D’autre part, le traitement par lots est généralement exécuté de manière planifiée (par exemple, des exécutions quotidiennes) tandis que toutes les données historiques (ou une partie importante de celles-ci) sont entrées. La fraîcheur des résultats est limitée par la fréquence de la planification : un traitement par lots quotidien vous donne toujours des résultats reflétant la situation d’hier, et non celle d’aujourd’hui. Comme toutes les données sont disponibles dès le départ, le traitement par lots est idéal pour effectuer toutes sortes d’optimisations de calcul qui peuvent considérablement augmenter les performances de calcul globales du processus. Par conséquent, grâce au traitement par lots, il est possible d’exécuter des classes entières de calculs complexes qui restent hors de portée lorsqu’on considère le traitement en ligne. De plus, d’un point de vue informatique, le traitement par lots tend à être beaucoup plus facile à mettre en œuvre et à exploiter ¹. Le principal inconvénient du traitement par lots étant le délai imposé par la nature par lots du processus.

En tant que plateforme logicielle, Lokad est définitivement dans le camp du traitement par lots. En effet, bien que l’optimisation de la Supply Chain Quantitative nécessite un haut degré de réactivité, il existe de nombreuses décisions qui ne nécessitent pas une réactivité instantanée, par exemple décider s’il faut produire une palette supplémentaire de produits, ou décider s’il est temps de baisser le prix afin de liquider un stock. Pour ces décisions, la principale préoccupation est de prendre la meilleure décision possible, et si cette décision peut être améliorée de manière mesurable en passant une heure de calcul supplémentaire sur le cas, il est presque garanti que cette heure de calcul supplémentaire sera un bon investissement ².

Ainsi, Envision est conçu dans une perspective de traitement par lots. Nous avons quelques astuces dans notre manche pour rendre Envision très rapide même lorsqu’il s’agit de téraoctets de données ; mais à cette échelle, il s’agit d’obtenir des résultats en quelques minutes, pas en moins d’une seconde. En fait, en raison de la nature hautement distribuée du modèle de calcul d’Envision, il est difficile pour Lokad de terminer l’exécution de n’importe quel script Envision en moins de 5 secondes environ, même lorsqu’il n’y a que quelques mégaoctets de données impliqués. Plus un système est distribué, plus il y a d’inertie interne pour synchroniser toutes les parties. Plus la scalabilité est élevée, plus la latence est élevée.

Il y a quelques années, nous avons introduit la notion de formulaires d’entrée dans Envision : une fonctionnalité qui vous permet d’ajouter un formulaire configurable sur le tableau de bord, qui devient une entrée accessible depuis le script Envision. Par exemple, grâce à cette fonctionnalité, il était facile de concevoir un tableau de bord destiné à un _inspecteur de produits_affichant toutes les informations pertinentes relatives aux produits spécifiés. Malheureusement, pour aligner le tableau de bord sur la valeur du formulaire nouvellement saisie, le script Envision devait être réexécuté, ce qui entraînait des secondes de délai pour obtenir les résultats actualisés ; une durée qui était inacceptable pour l’exploration des données.

Les tranches du tableau de bord (consultez notre documentation technique) représentent notre tentative d’obtenir le meilleur des deux mondes : le traitement en ligne et par lots. Le truc, c’est que Lokad peut maintenant calculer en lot un grand nombre de tranches (chaque tranche peut refléter un produit, un emplacement, un scénario, ou une combinaison de toutes ces choses) et vous permettre de passer d’une tranche à une autre en temps réel, ce qui est possible parce que tout a été précalculé. Naturellement, précalculer un grand nombre de tranches est plus coûteux en termes de calcul, mais pas autant qu’on pourrait le penser. Il est généralement moins cher pour Lokad de calculer 10 000 tranches à la fois, plutôt que d’effectuer 100 exécutions indépendantes, chaque exécution étant dédiée à une seule tranche.

Grâce aux tranches, Lokad acquiert des capacités de business intelligence surpuissantes : non seulement il est possible d’explorer de nombreuses vues différentes (par exemple, produits, emplacements, périodes de temps) en temps réel, mais sans aucune des restrictions habituelles des architectures de traitement en ligne.