Mein Name ist James Rowan und ich bin ein aufstrebender Junior, der am MIT Mathematik studiert. Ich durfte meinen Sommer als Praktikant im Analytics-Team von edX verbringen und mich auf die Datenpipeline. Das Analyseteam stellt Daten und Metriken zur Verwendung durch Kursteams, Forscher und interne Teams bei edX bereit. Meine Arbeit in diesem Sommer konzentrierte sich auf die Verbesserung unseres Data Warehouse, einer HP Vertica-Datenbank, die verwendet wird, um interne Berichte für die Marketing- und Führungsteams zu erstellen.
Erweiterung des Data Warehouse
Mein erstes Projekt bestand darin, das Data Warehouse mit Informationen zu Kursthemen zu ergänzen. Während das anfängliche Warehouse-Schema es Analysten ermöglichte, Einschreibungs- und Aktivitätsmetriken auf Kurs-für-Kurs-Basis abzufragen, gab es keine Möglichkeit, Kurse nach Fachgebiet zusammenzufassen und zu vergleichen. Informationen zu Kursfächern im Lager zu haben, würde es dem Marketingteam ermöglichen, beispielsweise zu sehen, welche Fachbereiche die höchsten verifizierten Teilnahmeraten für Zertifikate aufweisen, während andere Analysten in der Lage wären, nach Engagementmustern nach Fachbereichen zu fragen (sehen Mathematikkurse tendenziell viele Lernende versuchen, Probleme zu lösen, während geisteswissenschaftliche Kurse eine stärkere Nutzung von Diskussionsforen beinhalten?).
Um diese Aufgabe auszuführen, musste ich zuerst lernen Luigi, das Datenverarbeitungsframework, das von der offenen edX-Pipeline verwendet wird. Luigi ist ein von Spotify entwickeltes Open-Source-Python-Datenverarbeitungs-Framework, das Datenverarbeitungs-Workflows in eine Reihe von Aufgaben mit jeweils eigener Ausgabe aufteilt, sodass die Handhabung von Abhängigkeiten vereinfacht wird und Workflows neu gestartet werden können, nachdem Zwischenschritte fehlgeschlagen sind. Diese Eigenschaft von Luigi veranlasst uns, möglichst modulare Arbeitsabläufe anzustreben.
Der Workflow der Kursthemenbereiche besteht aus drei Teilen:
- Ruf den Kurskatalog API, das eine Liste aller auf der Website vermarkteten Kurse enthält, zusammen mit Informationen wie Themen, Dozenten und Dauer.
- Analysieren Sie die Ausgabe der API in eine tabulatorgetrennte Wertedatei, wobei jede Zeile eine Kurs-ID, einen Themenbereich für den Kurs und einige zusätzliche Informationen enthält.
- Laden Sie diese Fachgebietsdaten in die Vertica-Datenbank.
Die drei unterschiedlichen Phasen dieses Prozesses, die ich oben identifiziert habe, wurden auf natürliche Weise in Luigi-Aufgaben übersetzt, und die ersten beiden waren ziemlich einfach zu schreiben. Der dritte war interessanter. Während Luigi vorgefertigte Aufgaben zum Laden in MySQL-Datenbanken hat, gab es keine vorgefertigte Vertica-Ladeaufgabe, also musste ich zuerst eine allgemeine Vertica-Bulk-Loading-Luigi-Aufgabe erstellen. Dieser allgemeine Bulk-Loader wurde im Laufe des Sommers von anderen Teammitgliedern verwendet, und ich genoss es, Eigentümer dieses Teils der Pipeline zu sein, das die Infrastruktur für zukünftige Workflows bereitstellen wird, um unser internes Analyselager weiter auszubauen.
Die folgende Grafik zeigt ein Beispiel für eine Frage, die Analysten dank dieses Projekts jetzt beantworten können. Es zeigt, wie viel Prozent der Lernenden, die in Kursen auf edx.org aktiv waren, in Kursen bestimmter Fachgebiete aktiv waren. Im Herbst 2014 waren jeweils rund zehn Prozent der aktiven Lernenden in den Studiengängen Informatik, Wirtschaft, Datenanalyse und Geisteswissenschaften aktiv. Im Jahr 2015 war jedoch ein viel größerer Teil der aktiven Lernenden in Kursen auf edx.org in Informatikkursen aktiv. Im Juni 2015 war fast die Hälfte aller aktiven Lernenden auf edx.org in einem Informatikkurs aktiv! Auch die anderen drei gezeigten Themenbereiche erfreuten sich bei den aktiven Nutzern steigender Beliebtheit und stiegen auf jeweils zwanzig Prozent.
Nach dem Themenbereichsprojekt arbeitete ich an einem experimentellen Feature für die Produktanalyse. Alle Benutzerinteraktionen mit der Plattform, vom Abspielen von Videos über das Ausprobieren von Problemen bis hin zum Bearbeiten von Benutzerprofilen, werden zur Analyse protokolliert. Wenn eine neue Funktion hinzugefügt wird und mit der Ausgabe von Ereignissen beginnt, möchte das Produktteam möglicherweise wissen, wie häufig sie verwendet wird oder ob sie eine unverhältnismäßig hohe Nutzung in Desktop-Browsern feststellt (was auf ein Problem mit der Kompatibilität mit Mobilgeräten hindeutet). Anstatt darauf warten zu müssen, dass das Analyseteam einen Pipeline-Workflow zum Sammeln von Tracking-Protokollinformationen über die neue Funktion erstellt, sollten Produkt- und andere Teams in der Lage sein, selbst eine vorläufige Analyse der Ereignisprotokolle durchzuführen.
Die Schwierigkeit beim direkten Abfragen von Ereignisprotokollen besteht darin, dass die Ereignisprotokolle halbstrukturiert sind und im JSON-Format gespeichert werden. Da unterschiedliche Arten von Ereignissen unterschiedliche Attribute haben, wäre es unhandlich zu versuchen, ein einziges Tabellenschema für Ereignisse zu erstellen; Stattdessen nutzte ich Flextische von Vertica und wählte ein Tabellenschema, das materialisierte Spalten (erstklassige SQL-Tabellenspalten) für die Felder hat, die allen oder fast allen Ereignissen gemeinsam sind (Dinge wie Benutzername, Zeitstempel und Benutzergerätetyp), während es Benutzern weiterhin ermöglicht, ereignisspezifische Felder abzufragen (Dinge wie der Zeitstempel in einem Video, zu dem jemand navigiert). Wir sind uns zwar nicht sicher, ob dies unser Framework für die Produktanalyse in Zukunft sein wird, aber es hat uns geholfen, die Möglichkeiten unseres Lagers zu erkunden.
Integration der BI-Datenverarbeitung in die Pipeline
Als ich diesen Sommer anfing, bei edX zu arbeiten, hatten wir im Grunde zwei separate Pipelines: eine für die in Insights (Öffnen Sie das Analyse-Dashboard von edX) und eine weitere für unsere eigene interne Business Intelligence (BI)-Berichterstattung. Die Pipeline für nach außen gerichtete Daten ist in Luigi geschrieben und verfügt über Batch-Hadoop-Jobs zum Füllen eines Ergebnisspeichers für die Daten-API, während die Pipeline für das interne Reporting Pentaho Data Integration verwendet, um Daten aus dem LMS und dem Ergebnisspeicher zu extrahieren, sie zu transformieren und in das Warehouse zu laden. Die BI-Pipeline hing von einigen Ergebnissen aus der Hauptpipeline ab, konnte ihr diese Abhängigkeiten jedoch nicht mitteilen, was das Team zwang, die Ausführung der Aufgaben auf unserem Jenkins-Build-Server sorgfältig zu planen, und den Zweck, Luigi überhaupt für die Abhängigkeitsbehandlung zu verwenden, zunichte machte .
Die alte Analytics-Pipeline-Architektur mit zwei disjunkten Datenflusspfaden.
Ich wurde beauftragt, die technische Schuld zu reduzieren, die mit der Wartung von zwei Systemen verbunden ist Beginn der Umwandlung der Pentaho-Aufgaben in Luigi-Aufgaben. Neben den klaren Vorteilen des Übergangs zu einem einzigen Datenverarbeitungs-Framework ebnet dieses Unterfangen auch den Weg für weitere Data-Warehouse-Verbesserungen. Da in dieser neuen Architektur alle Schreibvorgänge in das Warehouse über die Pipeline erfolgen, können neue Datenverarbeitungsaufgaben (wie die Aufgaben zu meinen Kursthemen oben) in das Warehouse schreiben, ohne dass sie manuell um das Laden von Pentaho-Daten herum geplant werden müssen Schritte. Ein einheitlicher Datenverarbeitungs-Workflow erleichtert auch die Datenvalidierung; Datenvalidierungsaufgaben könnten in die Verarbeitungsschritte eingebettet werden, indem einfach Luigi-Aufgaben zur einheitlichen Pipeline hinzugefügt werden.
Die Architektur der internen Analyse (BI) nach der Pensionierung von Pentaho ist abgeschlossen.
Dieses Projekt ermöglichte es mir, mit dem kompletten Technologie-Stack der Pipeline zu arbeiten. Ich hatte die Möglichkeit, Aufgaben zu schreiben, die mit den MySQL-LMS-Datenbanken, den Ereignisverfolgungsprotokollen, dem Zwischenergebnis-Warehouse von Apache Hive und dem fertigen Data-Products-Warehouse von Vertica interagieren, und es war ein schöner Höhepunkt der Nutzung der Fähigkeiten, die ich mir im Laufe der Zeit angeeignet hatte Verlauf des Sommers.
Fazit
Ich habe es genossen, diesen Sommer die Gelegenheit zu bekommen, bei edX zu arbeiten. Dieses Praktikum hat mir eine Reihe von technischen Fähigkeiten beigebracht (das Luigi-Framework, das MapReduce-Paradigma, SQL, Git), und die Zugehörigkeit zum Analyseteam ermöglichte es mir auch, aus erster Hand Erfahrungen mit dem Design von Datenverarbeitungsarchitekturen, der Wartung großer Codebasen, und der Entwicklungszyklus von Software- und Datenprodukten. Das Erlernen der Arbeit im Kontext eines agilen Teams ist auch eine breit anwendbare Fähigkeit und hat mich dazu gebracht, bewusster über Gruppendynamik und Projektmanagement in Nicht-Arbeitsumgebungen nachzudenken.
Ich möchte John Baker, Gabe Mulley und Brian Wilson dafür danken, dass sie mir bei Fragen zur technischen Pipeline geholfen haben, dem Rest des Analytics-Teams für die Bereitstellung einer großartigen Arbeitsumgebung und allen anderen bei edX dafür, dass sie diesen Sommer Spaß gemacht haben.
