Mi chiamo James Rowan e sono uno studente in ascesa che studia matematica al MIT. Ho passato la mia estate lavorando come stagista nel team di analisi di edX, concentrandomi sul pipeline di dati. Il team di analisi fornisce dati e metriche per l'utilizzo da parte dei team del corso, dei ricercatori e dei team interni di edX. Il mio lavoro di quest'estate si è concentrato sul miglioramento del nostro data warehouse, un database HP Vertica utilizzato per generare report interni per i team di marketing e dirigenti.
Ampliamento del data warehouse
Il mio primo progetto era aggiungere informazioni sulle aree tematiche del corso al data warehouse. Sebbene lo schema del magazzino iniziale consentisse agli analisti di eseguire query per le metriche di iscrizione e attività corso per corso, non era possibile aggregare e confrontare i corsi per area tematica. Avere informazioni sull'area tematica del corso nel magazzino consentirebbe al team di marketing di vedere quali aree tematiche hanno i tassi di acquisizione dei certificati verificati più alti, ad esempio, mentre altri analisti potrebbero chiedere informazioni sui modelli di coinvolgimento per area disciplinare (i corsi di matematica tendono a vedere molti studenti tentano problemi, mentre i corsi umanistici prevedono un maggiore utilizzo dei forum di discussione?).
Per eseguire questo compito, avevo prima bisogno di conoscere Luigi, il framework di elaborazione dati utilizzato dalla pipeline edX aperta. Luigi è un framework di elaborazione dati Python open source sviluppato da Spotify che suddivide i flussi di lavoro di elaborazione dei dati in serie di attività, ciascuna con il proprio output, in modo che la gestione delle dipendenze sia semplificata e i flussi di lavoro possano essere riavviati dopo che i passaggi intermedi falliscono. Questa proprietà di Luigi ci porta a puntare a flussi di lavoro il più possibile modulari.
Il flusso di lavoro delle aree tematiche del corso si compone di tre parti:
- Chiama il api catalogo corsi, che contiene un elenco di tutti i corsi commercializzati sul sito, insieme a informazioni come materie, docenti e durata.
- Analizza l'output dell'API in un file di valori separati da tabulazioni, con ogni riga contenente un ID corso, un'area tematica per il corso e alcune informazioni aggiuntive.
- Carica i dati di questa area tematica nel database di Vertica.
Le tre fasi distinte di questo processo che ho identificato sopra si sono tradotte naturalmente nei compiti di Luigi e le prime due sono state abbastanza semplici da scrivere. Il terzo era più interessante. Sebbene Luigi abbia attività predefinite per il caricamento nei database MySQL, non esisteva alcuna attività di caricamento Vertica predefinita, quindi ho dovuto prima creare un'attività Luigi generale per il caricamento di massa di Vertica. Questo caricatore di massa generale è stato utilizzato da altri membri del team nel corso dell'estate e mi è piaciuto avere la proprietà di questo pezzo della pipeline, che fornirà l'infrastruttura per i flussi di lavoro futuri per espandere ulteriormente il nostro magazzino di analisi interno.
Il grafico seguente mostra un esempio di una domanda a cui gli analisti possono ora rispondere grazie a questo progetto. Mostra quale percentuale degli studenti attivi nei corsi su edx.org erano attivi nei corsi di particolari aree tematiche. Nell'autunno del 2014, circa il dieci percento degli studenti attivi ha frequentato corsi di informatica, economia, analisi dei dati e scienze umane. Nel 2015, tuttavia, una frazione molto più ampia degli studenti attivi nei corsi su edx.org ha svolto attività nei corsi di informatica. Nel giugno del 2015, quasi la metà di tutti gli studenti attivi su edx.org erano attivi in un corso di informatica! Anche le altre tre aree tematiche mostrate hanno visto una maggiore popolarità tra gli utenti attivi, salendo al venti percento ciascuna.
Dopo il progetto delle aree tematiche, ho lavorato su una funzionalità sperimentale per l'analisi dei prodotti. Tutte le interazioni degli utenti con la piattaforma, dalla riproduzione di video ai tentativi di problemi alla modifica dei profili utente, vengono registrate per l'analisi. Se viene aggiunta una nuova funzionalità e inizia a emettere eventi, il team del prodotto potrebbe voler sapere con quale frequenza viene utilizzata o se vede un uso sproporzionato sui browser desktop (suggerendo un problema con la compatibilità mobile). Invece di dover attendere che il team di analisi crei un flusso di lavoro della pipeline per aggregare le informazioni del registro di monitoraggio sulla nuova funzionalità, il prodotto e gli altri team dovrebbero essere in grado di eseguire analisi preliminari sui registri eventi stessi.
La difficoltà con l'interrogazione diretta dei registri eventi è che i registri eventi sono semi-strutturati, essendo archiviati in formato JSON. Poiché diversi tipi di eventi hanno attributi diversi, sarebbe poco pratico provare a creare un unico schema di tabella per gli eventi; invece ne ho approfittato I tavoli flessibili di Vertica e ha scelto uno schema di tabella che ha colonne materializzate (colonne di tabella SQL di prima classe) per i campi comuni a tutti o quasi tutti gli eventi (cose come nome utente, timestamp e tipo di dispositivo utente) pur consentendo agli utenti di eseguire query per campi specifici dell'evento (cose come il timestamp all'interno di un video verso cui sta navigando qualcuno). Sebbene non siamo sicuri se questo sarà il nostro framework per l'analisi dei prodotti in futuro, ci ha aiutato a esplorare le capacità del nostro magazzino.
Integrazione dell'elaborazione dei dati BI nella pipeline
Quando ho iniziato a lavorare in edX quest'estate, avevamo sostanzialmente due pipeline separate: una per i dati relativi all'istruttore utilizzati in Insights (Apri il dashboard di analisi di edX) e un altro per la nostra reportistica interna di business intelligence (BI). La pipeline per i dati rivolti all'esterno è scritta in Luigi e presenta lavori Hadoop batch per popolare un archivio dei risultati per il API dati, mentre la pipeline per il reporting interno utilizza Pentaho Data Integration per estrarre i dati dall'LMS e archiviare i risultati, trasformarli e caricarli nel magazzino. La pipeline di BI dipendeva da alcuni risultati della pipeline principale ma non poteva comunicargli queste dipendenze, costringendo il team a cronometrare attentamente l'esecuzione delle attività sul nostro server di build Jenkins e vanificando lo scopo dell'utilizzo di Luigi per la gestione delle dipendenze in primo luogo .
La vecchia architettura della pipeline di analisi, con due percorsi disgiunti del flusso di dati.
Mi è stato affidato il compito di ridurre il debito tecnico inerente al mantenimento di due sistemi iniziando la transizione dei compiti di Pentaho in compiti di Luigi. Oltre ai chiari vantaggi del passaggio a un quadro unico per l'elaborazione dei dati, questo impegno apre anche la strada a ulteriori miglioramenti del data warehouse. Poiché, in questa nuova architettura, tutte le scritture al warehouse vengono eseguite tramite la pipeline, le nuove attività di elaborazione dei dati (come l'attività delle aree tematiche del corso sopra) saranno in grado di scrivere nel warehouse senza dover essere programmate manualmente attorno al caricamento dei dati di Pentaho passi. Un flusso di lavoro unificato di elaborazione dei dati renderà anche più semplice la convalida dei dati; le attività di convalida dei dati potrebbero essere incorporate nelle fasi di elaborazione semplicemente aggiungendo le attività Luigi alla pipeline unificata.
L'architettura di analisi interna (BI) dopo il ritiro di Pentaho è stata completata.
Questo progetto mi ha permesso di lavorare con lo stack tecnologico completo della pipeline. Ho avuto la possibilità di scrivere attività che interagiscono con i database MySQL LMS, i log di tracciamento degli eventi, il magazzino dei risultati intermedi di Apache Hive e il magazzino dei prodotti di dati Vertica finito, ed è stato un bell'uso culminante delle competenze che avevo acquisito durante il corso dell'estate.
Conclusione
Mi è piaciuto avere l'opportunità di lavorare in edX quest'estate. Questo tirocinio mi ha insegnato alcune competenze tecniche (il framework Luigi, il paradigma MapReduce, SQL, git), ed essere nel team di analisi mi ha anche permesso di fare esperienza diretta con la progettazione di architetture di elaborazione dati, la manutenzione di grandi basi di codice, e il ciclo di sviluppo di prodotti software e dati. Anche imparare a lavorare nel contesto di un team agile è un'abilità ampiamente applicabile e mi ha portato a pensare in modo più consapevole alle dinamiche di gruppo e alla gestione dei progetti in ambienti non lavorativi.
Vorrei ringraziare John Baker, Gabe Mulley e Brian Wilson per avermi aiutato con domande tecniche sulla pipeline, il resto del team di analisi per aver fornito un ottimo ambiente di lavoro e tutti gli altri in edX per aver reso questa estate divertente.
