Master 2019 2020
Stages de la spécialité SAR
Traitements de flux continus de données en temps réel dans une architecture distribuée


Lieu : Orange Village Bâtiment F 67 avenue Lenine 94110 Arcueil
Encadrant : Thomas SAUVAGNAT Jean-Marc PAGEOT
Dates :du 24/02/2020 au 28/08/2020
Mots-clés : Master SAR, autre qu’ATIAM

Cliquer ici pour vous authentifier


Description

Au sein de la DSI des Réseaux, l’équipe « Big Data Technique » est en charge du développement de composants Big Data dont le but est d’aider à répondre plus efficacement aux problématiques techniques d’Orange (métiers de l’intervention, supervision des réseaux et du parc de livebox, etc.).

Le but de la mission est de comparer différents outils/framework/solutions de traitements de flux continus de données (streaming) en quasi temps réel (low latency) fonctionnant sur des architectures distribuées adaptées aux Big Data.

La première phase (2-3 semaines) sera théorique (lecture de la documentation des différentes technologies, des retours d’expérience, etc.) et devra établir un panorama des différents outils/framework/solutions traitant de cette problématique.

A l’issue de cette phase, vous sélectionnerez à minima une, au mieux deux ou trois, outils pour une mise en œuvre d’un cas d’utilisation concret.

L’implémentation devra permettre de valider la chaine de bout en bout suivante : des événements arrivent au fil de l’eau, s’en suit une phase de calculs/traitements (enrichissements, regroupements, etc.) puis une phase de comparaison a des seuils dans l’optique de déclencher ou non des alarmes. La mise en œuvre devra utiliser au mieux les capacités de distributions des calculs pour être scalable aussi bien en fonction du volume de données dans le flux en entrée qu’avec un nombre de seuils à évaluer.

Détails sur le use case à implémenter : En entrée : - un flux de CDR (Call Detail Record) générés par des équipements télécom à la fin d’appels téléphoniques et qui contiennent tout un tas d’info sur l’appel qui arrivent en temps réel dans un topic Kafka - des règles métiers pour calculer des KPI, comme par exemple le taux d’appel sans flux audio, la note MOS (Mean Opinion Score), le NER (Network Effectiveness Ratio), l’ASR (Answer-seizure ratio) - des règles métiers définissant des seuils d’alarming (axe de regroupement des CDR + valeur de comparaison d’un KPI), par exemple : sur les appels qui transitent par tel plateforme de service, on déclenche une alarme si l’ASR est inférieur à 0,65 En sortie : - Des alarmes à écrire dans un topic Kafka Le use case à implémenter (traitement du flux en temps réel et en architecture distribué) : - Lecture de flux de CDR depuis Kafka - Regroupement des données selon les axes nécessaires à l’évaluation des seuils (attention un même CDR peut appartenir à des axes de calcul de plusieurs seuils) - Regroupement temporel : # fenêtrage temporelle : l’évaluation des seuils se fera par paquet de 5 minutes (sur les CDR ayant une date de fin d’appel dans une même période 5 minutes) # faire attention aux données qui arrivent en retard : laisser un délai de grâce avant de déclencher l’évaluation du seuil # éventuellement abandonner l’évaluation du seuil s’il n’y a toujours pas assez de données après le délai de grâce (probablement signe d’un problème dans la chaine de collecte en amont du use case) - Calcul du/des KPI sur ses regroupements (temporelle et fonctionnel) + évaluation du seuil # Génération (ou non) d’une alarme Quelques enjeux sur ce use case : - Scalabilité (sur le volume du flux en entrée et sur le nombre de seuil à évaluer) - Tolérance aux pannes/échecs (que se passe-t-il en cas de problème sur un des exécuteurs) - Prévoir un mécanisme de prise en compte dynamique d’une modification de seuil existant ou de l’ajout d’un nouveau seuil