Je m'appelle James Rowan et je suis un jeune étudiant en mathématiques au MIT. J'ai passé mon été à travailler en tant que stagiaire dans l'équipe d'analyse d'edX, en me concentrant sur le pipeline de données. L'équipe d'analyse fournit des données et des mesures à utiliser par les équipes de cours, les chercheurs et les équipes internes d'edX. Mon travail cet été s'est concentré sur l'amélioration de notre entrepôt de données, une base de données HP Vertica utilisée pour générer des rapports internes pour les équipes marketing et exécutives.
Extension de l'entrepôt de données
Mon premier projet était d'ajouter des informations sur les matières du cours à l'entrepôt de données. Alors que le schéma d'entrepôt initial permettait aux analystes d'interroger les métriques d'inscription et d'activité cours par cours, il n'y avait aucun moyen d'agréger et de comparer les cours par domaine. Le fait d'avoir des informations sur les matières du cours dans l'entrepôt permettrait à l'équipe marketing de voir quelles matières ont les taux d'obtention de certificats vérifiés les plus élevés, par exemple, tandis que d'autres analystes pourraient poser des questions sur les modèles d'engagement par matière (les cours de mathématiques ont-ils tendance à voir de nombreux apprenants tentent des problèmes, tandis que les cours de sciences humaines utilisent davantage les forums de discussion ?).
Pour accomplir cette tâche, j'avais d'abord besoin d'apprendre Luigi, l'infrastructure de traitement de données utilisée par le pipeline edX ouvert. Luigi est un framework de traitement de données Python open source développé par Spotify qui divise les flux de travail de traitement de données en séries de tâches, chacune avec sa propre sortie, de sorte que la gestion des dépendances est simplifiée et que les flux de travail peuvent être redémarrés après l'échec des étapes intermédiaires. Cette propriété de Luigi nous amène à viser des workflows les plus modulaires possibles.
Le flux de travail des domaines de cours comporte trois parties :
- Appeler le API du catalogue de cours, qui contient une liste de tous les cours commercialisés sur le site, ainsi que des informations telles que leur(s) sujet(s), les instructeurs et les durées.
- Analysez la sortie de l'API dans un fichier de valeurs séparées par des tabulations, chaque ligne contenant un identifiant de cours, un domaine pour le cours et des informations supplémentaires.
- Chargez ces données de domaine dans la base de données Vertica.
Les trois phases distinctes de ce processus que j'ai identifiées ci-dessus se sont naturellement traduites en tâches Luigi, et les deux premières étaient assez simples à écrire. Le troisième était plus intéressant. Bien que Luigi ait des tâches prédéfinies pour le chargement dans les bases de données MySQL, il n'y avait pas de tâche de chargement Vertica prédéfinie, j'ai donc d'abord dû créer une tâche Luigi générale de chargement en masse Vertica. Ce chargeur en vrac général a été utilisé par d'autres membres de l'équipe au cours de l'été, et j'ai apprécié d'être propriétaire de cette partie du pipeline, qui fournira l'infrastructure pour les futurs flux de travail afin d'étendre davantage notre entrepôt d'analyse interne.
Le graphique suivant montre un exemple de question à laquelle les analystes peuvent désormais répondre grâce à ce projet. Il montre quel pourcentage d'apprenants actifs dans des cours sur edx.org étaient actifs dans des cours de matières particulières. À l'automne 2014, environ dix pour cent des apprenants actifs étaient actifs dans des cours d'informatique, de commerce, d'analyse de données et de sciences humaines. En 2015, cependant, une fraction beaucoup plus importante des apprenants actifs dans les cours sur edx.org avait une activité dans les cours d'informatique. En juin 2015, près de la moitié de tous les apprenants actifs sur edx.org étaient actifs dans un cours d'informatique ! Les trois autres domaines présentés ont également connu une popularité croissante parmi les utilisateurs actifs, atteignant vingt pour cent chacun.
Après le projet thématique, j'ai travaillé sur une fonctionnalité expérimentale d'analyse de produits. Toutes les interactions des utilisateurs avec la plate-forme, de la lecture de vidéos aux tentatives de problèmes en passant par la modification des profils d'utilisateurs, sont enregistrées pour analyse. Si une nouvelle fonctionnalité est ajoutée et commence à émettre des événements, l'équipe produit peut vouloir savoir à quelle fréquence elle est utilisée, ou si elle constate une utilisation disproportionnée sur les navigateurs de bureau (suggérant un problème de compatibilité mobile). Au lieu d'avoir à attendre que l'équipe d'analyse crée un flux de travail de pipeline pour agréger les informations du journal de suivi sur la nouvelle fonctionnalité, les équipes produit et autres devraient être en mesure d'effectuer elles-mêmes une analyse préliminaire des journaux d'événements.
La difficulté d'interroger directement les journaux d'événements est que les journaux d'événements sont semi-structurés, étant stockés au format JSON. Étant donné que différents types d'événements ont des attributs différents, il serait compliqué d'essayer de créer un schéma de table unique pour les événements ; au lieu de cela, j'ai profité de Les tables flexibles de Vertica et choisi un schéma de table qui a des colonnes matérialisées (colonnes de table SQL de première classe) pour les champs communs à tous ou presque tous les événements (comme le nom d'utilisateur, l'horodatage et le type d'appareil utilisateur) tout en permettant aux utilisateurs de rechercher des champs spécifiques à l'événement (des choses comme l'horodatage dans une vidéo vers laquelle quelqu'un navigue). Bien que nous ne sachions pas si ce sera notre cadre pour l'analyse des produits à l'avenir, cela nous a aidés à explorer les capacités de notre entrepôt.
Intégration du traitement des données BI dans le pipeline
Lorsque j'ai commencé à travailler chez edX cet été, nous avions essentiellement deux pipelines distincts : un pour les données destinées aux instructeurs utilisées dans Insights (Ouvrir le tableau de bord d'analyse d'edX) et un autre pour nos propres rapports internes de Business Intelligence (BI). Le pipeline pour les données externes est écrit en Luigi et comporte des tâches Hadoop par lots pour remplir un magasin de résultats pour le API de données, tandis que le pipeline pour les rapports internes utilise Pentaho Data Integration pour extraire les données du LMS et du magasin de résultats, les transformer et les charger dans l'entrepôt. Le pipeline BI dépendait de certains résultats du pipeline principal mais ne pouvait pas lui communiquer ces dépendances, obligeant l'équipe à chronométrer soigneusement l'exécution des tâches sur notre serveur de build Jenkins et à contrecarrer l'objectif d'utiliser Luigi pour la gestion des dépendances en premier lieu .
L'ancienne architecture de pipeline d'analyse, avec deux chemins disjoints de flux de données.
Afin de réduire la dette technique inhérente à la maintenance de deux systèmes, j'ai été chargé de commencer la transition des tâches Pentaho vers les tâches Luigi. Outre les avantages évidents de la transition vers un cadre de traitement de données unique, cette entreprise ouvre également la voie à d'autres améliorations de l'entrepôt de données. Étant donné que, dans cette nouvelle architecture, toutes les écritures dans l'entrepôt se font via le pipeline, de nouvelles tâches de traitement de données (comme la tâche de ma matière de cours ci-dessus) pourront écrire dans l'entrepôt sans avoir à être programmées manuellement autour du chargement des données Pentaho pas. Un flux de travail de traitement des données unifié facilitera également la validation des données ; les tâches de validation des données pourraient être intégrées aux étapes de traitement en ajoutant simplement des tâches Luigi dans le pipeline unifié.
L'architecture d'analyse interne (BI) après le retrait de Pentaho est terminée.
Ce projet m'a permis de travailler avec la pile technologique complète du pipeline. J'ai eu la chance d'écrire des tâches interagissant avec les bases de données MySQL LMS, les journaux de suivi des événements, l'entrepôt de résultats intermédiaires Apache Hive et l'entrepôt de produits de données Vertica fini, et ce fut une belle utilisation culminante des compétences que j'avais acquises au cours de la cours de l'été.
Conclusion
J'ai apprécié d'avoir l'opportunité de travailler chez edX cet été. Ce stage m'a appris un certain nombre de compétences techniques (le framework Luigi, le paradigme MapReduce, SQL, git), et faire partie de l'équipe d'analyse m'a également permis d'acquérir une expérience de première main avec la conception d'architectures de traitement de données, la maintenance de grandes bases de code, et le cycle de développement des logiciels et des produits de données. Apprendre à travailler dans le contexte d'une équipe agile est également une compétence largement applicable, et cela m'a amené à réfléchir plus consciemment à la dynamique de groupe et à la gestion de projet dans des environnements non professionnels.
J'aimerais remercier John Baker, Gabe Mulley et Brian Wilson de m'avoir aidé avec les questions techniques sur le pipeline, le reste de l'équipe d'analyse pour avoir fourni un excellent environnement de travail et tous les autres chez edX pour avoir rendu cet été amusant.
