Ces deux outils peuvent être mis à contribution dans le champ des Analytics. On cherche alors à obtenir des KPI dont la justesse dépend du traitement des données lorsqu’elles transitent par différents systèmes. Souvent fragmentés, ces transferts restent un passage obligé pour que les données puissent être enrichies et agrégées. L’écueil majeur est que pendant leur « trajet » des éléments se perdent. Quel que soit le business de votre entreprise, quelle est la meilleure solution entre Elastic et Imply pour vous aider dans vos analyses ?
Le suivi des évènements se révèle crucial
Généralement on ne s’intéresse qu’à deux états des évènements : lorsqu’ils entrent dans un système et lorsqu’ils en sortent. Par exemple, chez un de nos clients dans le secteur de la distribution, il s’agit de la prise en charge d’un colis dans le réseau et sa mise en distribution. Pour accéder à une vision globale du processus, faire du process mining et obtenir des indicateurs fiables, on va avoir besoin d’outils spécifiques.
À partir d’une simple requête dans Elastic Search on récupère les différents fragments de données et on les agrège. On voit ainsi, posé sur une seule ligne le cheminement suivi par un événement donné et ses délais de traitement, par exemple. En bref, on récolte des fragments d’éléments, on fusionne la donnée pour la mettre « à plat ». Cette dernière nous sert à calculer nos agrégats. La complexité et le coût se trouvent portés par l’indexation et la fusion des données.
La méthode Imply
Le point bloquant dans Imply concerne la fusion des données. En effet, cette fusion ne peut pas être réalisée de prime abord. En effet, Elastic Search permet de faire de la mise à jour d’objet par identifiants et d’autres paramètres. Les deux solutions se différencient de manière fondamentale dans leur façon de stocker les données. Dans Elastic Search, les données sont stockées par identifiant de document, elles sont d’ailleurs appelées documents. Dans Imply, elles sont stockées en mode « time series », la date et l’heure de l’évènement demeurent des éléments clés. Éventuellement, quelques attributs viennent compléter cet horodatage, mais c’est à peu près tout.
C’est la raison pour laquelle, la fusion et la mise à plat de la donnée ne peut être réalisée dans Imply. Pour obtenir les mêmes indicateurs, Imply va s’appuyer, lui, sur les requêtes. Les fragments d’évènement vont être mis bout à bout, ensemble dans une même source de données. C’est au moment de la requête qu’on va regrouper tous les fragments de l’évènement 1, ceux du numéro 2 et ainsi de suite. Avec Imply, les étapes de fusion deviennent inutiles, elles sont faites avec des regroupements au moment de la requête. Le coût de l’indexation, devenu quasi nul, est déporté sur les requêtes, le groupage et les agrégats.
Comment se décider ?
Pour choisir judicieusement entre ces deux outils, tout dépend de l’échelle. Soit, on travaille à la maille fragmentée et on lance des requêtes complexes avec Imply. Soit, on travaille à la maille évènement, avec Elastic Search, et on met à plat tous les fragments pour obtenir des agrégats plus simples. Aujourd’hui, fusionner la donnée et construire les agrégats dans Elastic reste simple. En revanche, le regroupement et le calcul sur chaque groupe demeure trop compliqué pour être mis en œuvre avec cet outil. C’est là qu’Imply tire son épingle du jeu. Notamment avec sa maîtrise des requêtes complexes, avec pour limite la richesse de son système de requêtes SQL. Il sait calculer la différence entre deux dates, mais pas un délai en jours ouvrés. Son moteur étant basé sur Apache Calcite, open source, il devrait être facile de le personnaliser avec des fonctions écrites en Java.
Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Andrea
