La pré-maternelle, en batch ou en stream?

Chez EURA NOVA, il y a beaucoup de jeunes papas et mamans. Alors, pendant le temps de midi, ça parle beaucoup poussées de dents, varicelle et choix cartésien entre vélo ou draisienne. Il n’est pas rare que les non-initiés ou les parents en devenir interrogent leurs collègues sur les critères de sélection d’une crèche ou la pédagogie Montessori. Et quand des hipsters expliquent à des geeks comment fonctionne le système scolaire belge, ils utilisent des technologies big data pour illustrer.

L’entrée en maternelle

Pour beaucoup d’entre nous, vendredi dernier avait donc un sévère goût de rentrée des classes — où est ton cartable, ça ira un Grany et un Capri Sun pour la récré ou tu veux un Petit Prince, dépêche-toi on va être en retard. Charles, papa d’un petit garçon, avait prévenu d’emblée :

-”Il est possible que j’arrive un peu en retard vendredi. Martin entre en pré-maternelle.”

-“C’est quoi, la pré-maternelle?” a demandé Malian qui, de toute évidence, n’a pas d’enfant.

Et Charles d’expliquer :

-“En Belgique, l’école est autorisée à partir de deux ans et demi. Tu peux laisser ton enfant à la crèche jusqu’à ses trois ans, si tu veux, mais beaucoup de parents n’attendent pas les 3 ans de leurs enfants pour les mettre à l’école. Certaines écoles accueillent les enfants n’importe quand pendant l’année, le jour de leurs deux ans et demi, que ce soit le 1er octobre ou le 2 juin. D’autres organisent des rentrées après chaque période de vacances scolaires (le 1er septembre, évidemment, et le premier jour après les vacances de Toussaint, de Noël, de Carnaval et de Pâques). L’effet est forcément différent, que ce soit pour le personnel de l’école ou les petits enfants… C’est un peu comme si tu faisais du batch processing!” a-t-il ponctué.

La comparaison est brillante et est parfaite pour vous parler de deux notions usitées en data science : le batch et le stream processing.

Une école maternelle qui fait du stream processing des petits enfants de 2 ans et demi les accueille au fur et à mesure de l’année, n’importe quand, dès que leurs parents débouchent le champagne pour fêter la fin des 500€ mensuels de crèche. En une heure, l’enfant visite l’école avec ses parents, passe par le secrétariat pour créer son dossier puis se présente devant les copains. A l’inverse, une école maternelle qui fait du batch processing organise des tirs groupés d’une journée et accueille ses nouveaux élèves à des moments précis de l’année pour les gérer ensemble. C’est comme si, virtuellement, les enfants attendaient dans la cour de récré entre le jour de leur 2,5 ans et le premier jour après les prochaines vacances, et qu’on les faisait ensuite visiter tous ensemble l’école, passer tous ensemble au secrétariat et se présenter tous ensemble aux copains.

Dans l’un ou l’autre cas, le processus est le même (la visite, le secrétariat, les copains). Dans le premier cas (le stream), il est répété

• n’importe quand,
• dès qu’un enfant entre en pré-maternelle,
• pour un seul enfant.

Dans le second cas (le batch), il est répété:

• de façon ponctuelle,
• le premier jour qui suit chaque période de vacances scolaires,
• pour plusieurs enfants.

On comprend dès lors que le paramètre critique de l’un ne sera pas celui de l’autre. L’école qui fait du stream processing des enfants doit être comme un scout — toujours prête, hyper réactive et rodée pour assurer l’accueil des petits nouveaux. L’école qui fait du batch, elle, doit pouvoir gérer les arrivées massives des enfants après les vacances.

Dans les entreprises

Imaginons à présent ces deux concepts appliqués à une grande entreprise — une banque, par exemple.

Une banque peut vouloir traiter les données des dernières 24h pendant la nuit, en batch : le soir, elle prend toutes les données produites au cours de la journée comme on prendrait une pile de courrier accumulé sur un bureau et elle les utilise pour l’une ou l’autre raison (tri, perfectionnement des modèles, mise à jour, sauvegarde, etc.). Le lendemain, le batch est remis à zéro, se remplit au fil des heures et à 22h, rebelote.

Une banque peut également avoir besoin de faire du stream processing, de traiter des données ou des demandes dès qu’elles apparaissent. Par exemple, les cas de fraude ou de vol de carte bancaire peuvent se résoudre plus rapidement si les données parviennent rapidement. Imaginez :

-“Allô la banque? On vient de me voler ma carte de crédit! Pouvez-vous la bloquer s’il vous plaît?

-“Bien sûr, j’ai envoyé une demande. Ce sera traité pendant la nuit et effectif demain matin.”

Vous changeriez de banque, pas vrai ?

Flink ou Spark ?

Le traitement des données d’entreprises peut donc se faire de deux manières : en batch ou en stream (qui peut être vu comme une succession de mini-batches… mais on va pas trop compliquer l’affaire non plus). Parmi le grand paysage Big Data, certaines technologies de processing de données s’utilisent davantage pour l’un ou pour l’autre. Ainsi, on avait l’habitude de différencier Spark, l’américain, de Flink, l’Européen, par leurs origines géographiques.

-”Ce n’est plus le cas, fait remarquer Maher, data scientist chez EURA NOVA. On préfère utiliser Flink quand la latence est critique. La latence est le laps de temps qui s’écoule entre l’arrivée de la donnée et son traitement (l’arrivée du gamin à l’école et sa présentation aux copains). Flink est donc recommandé quand le délai de traitement est critique (pour les enfants impatients de rencontrer leurs nouveaux copains, par exemple). Spark se concentre sur le débit — le nombre maximum d’enfants pouvant arriver chaque jour : dans ce cas, 100 enfants peuvent arriver le même jour en prématernelle. Ils mettront peut-être un peu de temps à rencontrer leurs copains, mais il seront tous assurés de rentrer ce jour-là. Dans tous les cas, il s’agit d’un compromis à faire entre ces deux aspects.

Lambda, kappa, EURA NOVA

Mais comment met-on place tout cela ? Une école où le débit est critique a tout intérêt à avoir un secrétariat spacieux pour accueillir un troupeau de petits nouveaux et une bonne réserve de petits lits. Une école qui considère davantage la latence mise plutôt sur la disponibilité et l’enthousiasme à tout épreuve du corps enseignant, qui peut à tout instant de l’année accueillir avec entrain un nouveau bambin.

Et pour une entreprise, ça se passe comment?

Il y a quelques années, les entreprises utilisaient une architecture dites lambda : une partie de leurs données était streamée, l’autre était traitée en batch (cf. ci-dessous). Une banque pouvait donc faire la mise à jour quotidienne de ses machines ET désactiver des cartes de crédits dans les secondes qui suivent l’appel du client détroussé.

Imaginons que j’aie un compte bancaire matérialisé par deux cartes : une carte type bancontact et une carte de crédit. Sur mon application bancaire, je vois que le décompte bancontact se fait en stream : je peux voir le fil des dépenses au fur et à mesure de mes achats et mon solde qui s’amoindrit petit à petit. Par contre, le décompte de ma carte de crédit est plutôt en batch : le montant à débiter grandit sournoisement et puis boum, le 7 de chaque mois, ma banque me rappelle gentiment que j’ai acheté beauuuuuuucoup trop de vêtements. Sur mon application, ce sont deux types de données bien distinctes qui affectent pourtant le même capital.

Un peu embêtant, non?

Oui, et pour la banque aussi, qui doit maintenir deux types de traitement en parallèle.

L’architecture kappa a succédé à l’architecture lambda (cf. schéma ci-après) et a proposé une solution au problème. Comment? En streamant systématiquement les données entrantes, pour ensuite les traiter en stream et/ou en batch. Le résultat? La possibilité de faire du real time sur toutes les données tout en les stockant pour des besoins futurs.

Avec ce système, je pourrais voir sur mon application l’historique de TOUTES mes dépenses en temps réel, tout en conservant la vue mensuelle sur mon crédit.

Depuis quelques mois, EURA NOVA travaille sur une version améliorée de cette architecture kappa, la Data Architecture Vision, qui permet

1. de toujours intercepter et collecter toutes les données (exogènes ou endogènes)
2. de rassembler toutes les données dans un seul grand entrepôt (un data lake)
3. pour toutes ces données, d’utiliser des technologies de batch et de stream processing (Spark, Map Reduce, Flink, Kafka, etc.)

Bien sûr, cette architecture (ci-dessous) comprend d’autres petites originalités par rapport à l’architecture kappa. Mais ça, je vous en parlerai une autre fois!