Meu nome é James Rowan, e sou um calouro em ascensão estudando matemática no MIT. Passei o verão trabalhando como estagiário na equipe de análise da edX, focando no pipeline de dados. A equipe de análise fornece dados e métricas para uso por equipes de cursos, pesquisadores e equipes internas da edX. Meu trabalho neste verão se concentrou em melhorar nosso data warehouse, um banco de dados HP Vertica usado para gerar relatórios internos para as equipes de marketing e executivas.
Estendendo o data warehouse
Meu primeiro projeto era adicionar informações sobre as áreas temáticas do curso ao data warehouse. Embora o esquema inicial do warehouse permitisse que os analistas consultassem as métricas de matrícula e atividade em uma base de curso por curso, não havia como agregar e comparar cursos por área de assunto. Ter as informações da área de assunto do curso no warehouse permitiria que a equipe de marketing visse quais áreas de assunto têm as maiores taxas de obtenção de certificados verificados, por exemplo, enquanto outros analistas poderiam perguntar sobre padrões de engajamento por área de assunto (os cursos de matemática tendem a ver muitos alunos tentando resolver problemas, enquanto os cursos de humanidades apresentam mais uso de fóruns de discussão?).
Para realizar essa tarefa, primeiro precisei aprender sobre Louis, a estrutura de processamento de dados que o pipeline edX aberto usa. Luigi é uma estrutura de processamento de dados Python de código aberto desenvolvida pelo Spotify que divide os fluxos de trabalho de processamento de dados em uma série de tarefas, cada uma com sua própria saída, para que o tratamento de dependências seja simplificado e os fluxos de trabalho possam ser reiniciados após as etapas intermediárias falharem. Essa propriedade de Luigi nos leva a buscar fluxos de trabalho o mais modulares possível.
O fluxo de trabalho das áreas de assunto do curso tem três partes:
- Ligue para o api do catálogo de cursos, que contém uma lista de todos os cursos comercializados no site, juntamente com informações como disciplina(s), instrutores e duração.
- Analise a saída da API em um arquivo de valores separados por tabulação, com cada linha contendo um ID do curso, uma área de assunto para o curso e algumas informações adicionais.
- Carregue esses dados de área de assunto no banco de dados Vertica.
As três fases distintas desse processo que identifiquei acima se traduziram naturalmente em tarefas do Luigi, e as duas primeiras foram bastante simples de escrever. O terceiro foi mais interessante. Embora o Luigi tenha tarefas pré-criadas para carregar em bancos de dados MySQL, não havia uma tarefa de carregamento Vertica pré-criada, então primeiro tive que criar uma tarefa Luigi geral de carregamento em massa Vertica. Esse carregador em massa geral foi usado por outros membros da equipe ao longo do verão, e gostei de ter a propriedade dessa parte do pipeline, que fornecerá a infraestrutura para futuros fluxos de trabalho para expandir ainda mais nosso armazém de análise interna.
O gráfico a seguir mostra um exemplo de uma pergunta que os analistas agora podem responder graças a este projeto. Ele mostra qual porcentagem dos alunos ativos em cursos no edx.org eram ativos em cursos de áreas específicas. No outono de 2014, cerca de dez por cento dos alunos ativos estavam ativos em cursos de ciência da computação, negócios, análise de dados e humanidades. Em 2015, no entanto, uma fração muito maior dos alunos ativos em cursos no edx.org tinha atividade em cursos de ciência da computação. Em junho de 2015, quase metade de todos os alunos ativos no edx.org estavam ativos em um curso de ciência da computação! As outras três áreas de assunto mostradas também aumentaram a popularidade entre os usuários ativos, chegando a vinte por cento cada.
Após o projeto de áreas temáticas, trabalhei em um recurso experimental para análise de produtos. Todas as interações do usuário com a plataforma, desde a reprodução de vídeos até a tentativa de problemas e a edição de perfis de usuários, são registradas para análise. Se um novo recurso for adicionado e começar a emitir eventos, a equipe do produto pode querer saber com que frequência ele é usado ou se vê um uso desproporcionalmente alto em navegadores de desktop (sugerindo um problema com compatibilidade móvel). Em vez de ter que esperar que a equipe de análise crie um fluxo de trabalho de pipeline para agregar informações de log de rastreamento sobre o novo recurso, o produto e outras equipes devem poder fazer análises preliminares nos próprios logs de eventos.
A dificuldade de consultar diretamente os logs de eventos é que os logs de eventos são semiestruturados, sendo armazenados no formato JSON. Como tipos diferentes de eventos têm atributos diferentes, seria difícil tentar criar um único esquema de tabela para eventos; em vez disso, aproveitei As tabelas flexíveis da Vertica e escolheu um esquema de tabela que tenha colunas materializadas (colunas de tabela SQL de primeira classe) para os campos comuns a todos ou quase todos os eventos (coisas como nome de usuário, carimbo de data/hora e tipo de dispositivo do usuário) enquanto ainda permite que os usuários consultem campos específicos do evento (coisas como o timestamp em um vídeo para o qual alguém está navegando). Embora não tenhamos certeza se essa será nossa estrutura para análise de produtos daqui para frente, ela nos ajudou a explorar os recursos de nosso depósito.
Integrando o processamento de dados de BI ao pipeline
Quando comecei a trabalhar na edX neste verão, tínhamos basicamente dois pipelines separados: um para os dados voltados para o instrutor usados no Insights (Abra o painel de análise do edX) e outro para nossos próprios relatórios internos de inteligência de negócios (BI). O pipeline para dados externos é escrito em Luigi e apresenta trabalhos em lote do Hadoop para preencher um armazenamento de resultados para o API de dados, enquanto o pipeline para relatórios internos usa o Pentaho Data Integration para extrair dados do LMS e armazenamento de resultados, transformá-los e carregá-los no warehouse. O pipeline de BI dependia de alguns resultados do pipeline principal, mas não conseguia comunicar essas dependências a ele, forçando a equipe a cronometrar cuidadosamente a execução das tarefas em nosso servidor de compilação Jenkins e anulando o propósito de usar Luigi para tratamento de dependência em primeiro lugar .
A antiga arquitetura de pipeline de análise, com dois caminhos separados de fluxo de dados.
Para reduzir a dívida técnica inerente à manutenção de dois sistemas, fui encarregado de iniciando a transição das tarefas do Pentaho para as tarefas do Luigi. Além dos claros benefícios da transição para uma única estrutura de processamento de dados, esse empreendimento também abre caminho para outras melhorias no data warehouse. Uma vez que, nesta nova arquitetura, todas as gravações no warehouse são feitas através do pipeline, novas tarefas de processamento de dados (como a tarefa das áreas de assunto do meu curso acima) poderão gravar no warehouse sem precisar ser agendadas manualmente em torno do carregamento de dados do Pentaho degraus. Um fluxo de trabalho de processamento de dados unificado também facilitará a validação de dados; as tarefas de validação de dados podem ser incorporadas nas etapas de processamento simplesmente adicionando tarefas Luigi ao pipeline unificado.
A arquitetura de análise interna (BI) após a aposentadoria do Pentaho é concluída.
Este projeto me permitiu trabalhar com a pilha de tecnologia completa do pipeline. Tive a chance de escrever tarefas interagindo com os bancos de dados MySQL LMS, os logs de rastreamento de eventos, o armazém de resultados intermediários do Apache Hive e o armazém de produtos de dados Vertica finalizado, e foi um bom uso culminante das habilidades que vinha adquirindo ao longo do curso do verão.
Conclusão
Gostei de ter a oportunidade de trabalhar na edX neste verão. Este estágio me ensinou uma série de habilidades técnicas (o framework Luigi, o paradigma MapReduce, SQL, git), e estar na equipe de análise também me permitiu obter experiência em primeira mão com o design de arquiteturas de processamento de dados, a manutenção de grandes bases de código, e o ciclo de desenvolvimento de software e produtos de dados. Aprender a trabalhar no contexto de uma equipe ágil também é uma habilidade amplamente aplicável, e me levou a pensar de forma mais consciente sobre dinâmicas de grupo e gerenciamento de projetos em ambientes fora do trabalho.
Gostaria de agradecer a John Baker, Gabe Mulley e Brian Wilson por me ajudarem com questões técnicas de pipeline, ao restante da equipe de análise por fornecer um ótimo ambiente de trabalho e a todos na edX por tornarem este verão divertido.
