Cédric Despres, Responsable de l’offre Big Data chez Ysance
Estimé à 8,9 milliards de dollars selon le cabinet Transparency Market Research, le chiffre d’affaires du marché Big Data devrait, selon IDC, atteindre 23,9 milliards en 2016. A l’instar du Cloud Computing, le Big Data s’est installé progressivement dans les mœurs de l’entreprise. Aujourd’hui, sa place dans les budgets IT est quasi-systématique et au minimum de 10% (source : Deloitte). À en juger par la fréquentation croissante du salon Big Data (qui s’est déroulé récemment au CNIT de la Défense), cette démocratisation se traduit aussi bien dans l’offre, de plus en plus complète, que dans la demande, de plus en plus avertie. On dit que les directions métiers sont devenues « data driven » : elles collectent et analysent de plus en plus leurs données, optimisent leurs décisions, personnalisent leurs applications, ... Bref, l’histoire du Big Data est en marche et la tendance va, sans surprise, à l’accélération. Dans cette société habituée à l’instantané et à l’immédiateté, portées notamment par les réseaux sociaux, les applications mobiles, sans oublier l’arrivée imminente de l’internet des objets, obtenir l’information en temps réel est devenue une évidence. Exploiter des données en mode batch, même à J+1, ne suffit plus dans certains cas. Place donc au Fast Data.
Pouvoir activer les bons leviers au bon moment. Si on prend l’exemple d’un pilotage de la performance des ventes rayon par rayon dans une grande surface, savoir le lendemain que l’objectif de CA n’est pas atteint n’est pas totalement satisfaisant car cela ne servira en aucun cas à rectifier le tir le jour J. Dans le cas d’une architecture Fast Data, il sera possible d’observer en temps réel la courbe des ventes, magasin par magasin, rayon par rayon et donc de réagir à temps en activant les bons leviers (management, promotions, marketing, etc.). Cela peut servir également à ne pas rater une vente liée à une rupture de stock grâce à une connaissance immédiate des perturbations côté transporteur ou encore à détecter une tentative de fraude via une analyse scrupuleuse et instantanée de la procédure d’achat.
L’architecture Lambda : solutions et limitations. Recourir au Fast Data, implique de repenser la façon d’appréhender la donnée et de revoir l’ensemble des processus techniques. Dans les faits, la couche de traitement batch (Batch Layer) est conservée. Ce qui change ce sont les flux de données : en mode Fast Data, elles sont reçues et injectées au fil de l’eau (New Data Stream) dans la couche de traitement « temps réel » (Speed Layer) et de l’autre dans la couche batch. En bout de chaine la couche de service (Service Layer) permet de traiter et d’unifier la vision historique et temps réels. On parle d’architecture Lambda. Afin de répondre à cette architecture, l’écosystème Hadoop a été complété par des technologies de collecte au fil de l’eau comme Flume, Kafka (développé par LinkedIn), des couches de calcul en temps réel type Spark streaming, Storm, etc. Côté couche de services, on pourra utiliser des moteurs de recherche temps réel comme Elastic Search et Solar ou encore des bases NoSQL comme HBase ou MongoDB.
Pouvoir activer les bons leviers au bon moment. Si on prend l’exemple d’un pilotage de la performance des ventes rayon par rayon dans une grande surface, savoir le lendemain que l’objectif de CA n’est pas atteint n’est pas totalement satisfaisant car cela ne servira en aucun cas à rectifier le tir le jour J. Dans le cas d’une architecture Fast Data, il sera possible d’observer en temps réel la courbe des ventes, magasin par magasin, rayon par rayon et donc de réagir à temps en activant les bons leviers (management, promotions, marketing, etc.). Cela peut servir également à ne pas rater une vente liée à une rupture de stock grâce à une connaissance immédiate des perturbations côté transporteur ou encore à détecter une tentative de fraude via une analyse scrupuleuse et instantanée de la procédure d’achat.
L’architecture Lambda : solutions et limitations. Recourir au Fast Data, implique de repenser la façon d’appréhender la donnée et de revoir l’ensemble des processus techniques. Dans les faits, la couche de traitement batch (Batch Layer) est conservée. Ce qui change ce sont les flux de données : en mode Fast Data, elles sont reçues et injectées au fil de l’eau (New Data Stream) dans la couche de traitement « temps réel » (Speed Layer) et de l’autre dans la couche batch. En bout de chaine la couche de service (Service Layer) permet de traiter et d’unifier la vision historique et temps réels. On parle d’architecture Lambda. Afin de répondre à cette architecture, l’écosystème Hadoop a été complété par des technologies de collecte au fil de l’eau comme Flume, Kafka (développé par LinkedIn), des couches de calcul en temps réel type Spark streaming, Storm, etc. Côté couche de services, on pourra utiliser des moteurs de recherche temps réel comme Elastic Search et Solar ou encore des bases NoSQL comme HBase ou MongoDB.
Notons cependant que l’obtention de données en temps réel n’est pas justifiée dans tous les cas. D’autant que les indicateurs calculés en temps réel n’offrent pas un niveau de fiabilité aussi précis et exact que lorsqu’ils sont calculés par la couche Batch. Le Fast Data est fondé sur ces deux principes : premièrement toute la donnée ne doit pas être traitée en temps réel, mais uniquement celle dont on a besoin. Deuxièmement, il faut accepter une moindre qualité des calculs effectués par la Speed Layer. Généralement on donne un indicateur de fiabilité à hauteur de 90-95% ce qui est suffisamment pertinent pour un usage temps réel. Le lendemain tout est recalculé pour la couche Batch qui fournit alors les chiffres définitifs des KPI pour la journée passée.
Le direct, ce n’est pas pour tout le monde. Côté coûts, il s’agit essentiellement de temps de développement. En général pour celles concernées, 20% maximum des données d’entreprises nécessitent une approche Fast Data. Les développements étant deux fois plus chers car plus complexes à mettre en place - plus de fine tuning - cela nous amène à 40% du coût initial. Dans les faits, il est possible de démarrer par du Big Data en mode batch et d’évoluer par la suite vers le Fast Data. C’est d’ailleurs conseillé. Il est préférable de bien maitriser les technologies du Big Data avant de se lancer ; cela permet de mieux appréhender ses besoins et de s’éviter les déconvenues causées par le manque de recul. Pour terminer, rappelons qu’en termes de traitement de données, le critère temps doit être réservé aux usages qui le justifient. Privilégier la vitesse à la précision n’a effectivement du sens que si le coût d’un retard dépasse de très loin celui d’une erreur.
Le direct, ce n’est pas pour tout le monde. Côté coûts, il s’agit essentiellement de temps de développement. En général pour celles concernées, 20% maximum des données d’entreprises nécessitent une approche Fast Data. Les développements étant deux fois plus chers car plus complexes à mettre en place - plus de fine tuning - cela nous amène à 40% du coût initial. Dans les faits, il est possible de démarrer par du Big Data en mode batch et d’évoluer par la suite vers le Fast Data. C’est d’ailleurs conseillé. Il est préférable de bien maitriser les technologies du Big Data avant de se lancer ; cela permet de mieux appréhender ses besoins et de s’éviter les déconvenues causées par le manque de recul. Pour terminer, rappelons qu’en termes de traitement de données, le critère temps doit être réservé aux usages qui le justifient. Privilégier la vitesse à la précision n’a effectivement du sens que si le coût d’un retard dépasse de très loin celui d’une erreur.