Coleção de dados

A primeira parte de qualquer tarefa de ciência de dados é obter um bom conjunto de dados para trabalhar. Temos muitos dados, mas preparar os conjuntos de dados pode ser um trabalho muito difícil - você realmente precisa “sujar as mãos” para obter os dados de todas as fontes e tabelas e convertê-los em um conjunto de dados fácil de usar.

Desafios:

Quais são os principais desafios na criação de um bom conjunto de dados para usar?

• Muitas tabelas de saída - tabelas que armazenam solicitações de recomendações, recomendações veiculadas, cliques do usuário, perfis para os usuários e documentos e muito mais.
• Número de armazenamentos de dados - essas tabelas são armazenadas em várias fontes, devido à sua natureza diferente. Algumas são tabelas Hive, alguns dados são armazenados no MySQL e no Cassandra também.
• Consultas longas - algumas dessas tabelas são muito grandes. Consultá-los, especialmente por um longo período, pode demorar um pouco.
• Dados irrelevantes - raramente queremos dados de todo o tráfego. Normalmente, queremos apenas uma parte relevante para a tarefa de modelagem atual.

Silos e particionamento:

Além desses desafios, há outras vantagens em um bom processo de coleta de dados.

Queremos ter a capacidade de treinar modelos em diferentes silos - diferentes grupos populacionais, que podem se comportar de maneira diferente e exigir modelos diferentes.

Para permitir isso com facilidade, adicionamos várias colunas e partições às nossas tabelas de agregação de saída - como plataforma, país, idioma e muito mais.

Isso nos permite experimentar rapidamente nossos modelos em diferentes grupos.

Resultado:

Decidimos dividir nossa produção em 2 partes principais:

Primeiro, um conjunto de dados para criar modelos: ele conterá apenas as recomendações veiculadas que queremos (de variantes específicas do tráfego) e deve conter todas as recomendações clicadas, além de uma amostra dos não cliques, para ter um conjunto de dados equilibrado para aprendizado.

Segundo, um conjunto de dados que será usado para simulação das métricas de negócios.

Nossas recomendações são exibidas em widgets, mostrando um pequeno lote de recomendações.
Para esse caso de uso, aceitamos apenas recomendações de widgets que receberam pelo menos um clique.

Com esse conjunto de dados, podemos aplicar nosso modelo apenas nesses widgets clicados e ver quão bem avaliamos a recomendação clicada em comparação com as outras recomendações sem cliques.

A solução - trabalho Automatic Spark

Nossa solução para resolver todos esses desafios foi criar um trabalho de coleta automática de dados.

O trabalho é executado a cada hora, acionado pelo nosso mecanismo ETL.
Uma tarefa horária do Apache Spark agrega um conjunto de dados por hora, com os dados relevantes; cria as partições necessárias; e cria as duas saídas descritas acima.

O uso do Spark foi muito conveniente para este caso de uso. Isso nos permitiu criar um fluxo legível, que consulta diferentes fontes de entrada e retém dados de memória comuns às duas tabelas antes de gravar a saída final no Hive.

Uma observação rápida sobre como monitoramos nossos trabalhos do Spark:

É um desafio compreender como um trabalho do Spark se comporta, além das mensagens de erro básicas e verificar a saída do trabalho.

Para tornar o progresso e o status da tarefa mais visíveis, enviamos métricas do driver da tarefa, usando HTTP, para o nosso servidor de monitoramento, que as agrega.

Isso nos permite criar painéis simples de usar e entender com facilidade o que está acontecendo.

Além disso, enviamos logs de texto para o nosso servidor de monitoramento, que os indexa para um cluster ElasticSearch. Em seguida, podemos visualizar os logs com facilidade usando o Kibana.

Abaixo está um exemplo de painel para um trabalho de demonstração, coletando uma parte de nossos dados.

Desafios de modelagem e clichê

A construção de um modelo contém muitas partes comuns.

Primeiro é manipular a entrada. Mesmo depois de separarmos os dados com nosso processo de coleta de dados, ainda precisamos lê-los e dividi-los corretamente para treinar e testar e ler dados para o nosso processo de simulação.

Outra parte comum é avaliar as métricas de teste.
Executar o modelo nos dados de teste e exibir diferentes métricas de teste, como MSE, AUC e outras métricas, para ver o desempenho do modelo.

Terceiro, está verificando as métricas de negócios.
Antes de experimentar um modelo em produção, queremos simular como o modelo se comporta em relação aos KPIs de negócios.
Avaliamos várias métricas que servem como bons proxies para o desempenho dos negócios.

Nosso objetivo nessa estrutura é facilitar a vida dos cientistas de dados, permitindo que eles se concentrem nos modelos, em vez de escrever códigos padronizados que consomem tempo.

Estrutura do Modelo

Queríamos criar uma estrutura que inclua essas peças prontas para uso.
Executa o processo de ajuste, salva o modelo, testa o desempenho e executa a simulação.

Todos os dados que os cientistas devem focar são a lógica de seu modelo.
Eles podem usar quaisquer pacotes Spark ML, implementações de código aberto ou suas próprias implementações internas; o resto eles ficam "de graça" a partir da estrutura.

A interface que eles precisam implementar é simples:

• Preparando o conjunto de dados - extraindo novos recursos, transformando os dados.
• Ajustando o modelo nos dados - a lógica real do algoritmo.
• Retornando os nomes das colunas (recursos) necessários para o modelo operar
• Salvando uma representação do modelo para uso posterior

Produtividade de modelos

A parte final do quadro é a ponte entre pesquisa e produção.
Queremos que essa transição seja o mais simples e rápida possível, para que possamos chegar rapidamente a conclusões e continuar melhorando.

Primeiro, queremos permitir testes A / B rápidos e fáceis de novos modelos.

Um lembrete rápido de como os testes A / B funcionam: dividimos a população em 2 grupos independentes de usuários semelhantes.
Atendemos um grupo com o tratamento - o novo modelo e atendemos o outro grupo com o controle - nossa linha de base de produção que o sistema atualmente usa.
Depois de algum tempo, analisamos os dados, avaliamos as métricas de engajamento e monetização usando testes estatísticos e concluímos se o tratamento conseguiu melhorar significativamente.

Para apoiar isso, adicionamos uma etapa no final da estrutura.
A etapa lê os coeficientes do modelo e atualiza as configurações de teste A / B com uma variante que atenderá uma pequena parte de nossos usuários com o novo modelo.

De maneira semelhante, uma vez que tenhamos um modelo com valor comprovado - queremos ajustá-lo regularmente para continuar aprendendo com base nos novos dados que coletamos.

• Executamos todo o fluxo de modelagem regularmente, acionado pelo nosso mecanismo ETL.
  Um novo modelo é criado com variáveis ​​atualizadas.
• A cada execução, validamos as métricas de negócios, para garantir que o modelo continue com bom desempenho e não se deteriore.
• Por fim, se as métricas forem positivas, atualizamos as configurações de produção.

Design de alto nível

Aqui está uma rápida visão geral de alto nível desta parte do sistema:

Nossos dados de entrada são armazenados em 2 tabelas de colméia, depois de preparadas pelo processo de coleta de dados.
O modelo é criado usando o gerador de modelos, que inicializa a implementação com base na configuração da tarefa.
A estrutura então executa todas as partes comuns:

• Lê os dados e os divide em um teste, treinamento e simulação
• Chama a implementação de ajuste do modelo e salva o resultado.
• Usa o modelo para previsões de dados de teste e armazena os resultados para análise.
• Executa o modelo nos dados da simulação e calcula as métricas de simulação do KPI de negócios.
• Salva o modelo para uso posterior no HDFS.

Todos os resultados são armazenados como no Cassandra.

A última parte é a etapa de produção:
obtém as variáveis ​​atualizadas do modelo da saída de ajuste, valida as métricas de simulação para verificar o desempenho do modelo e atualiza as configurações de produção no MySQL.

Aprendizado

Para resumir, aqui estão as principais lições que aprendemos que evoluíram para essa estrutura:

• Prepare bem seus dados - para permitir a modelagem em alta escala, isso é crucial!
  Não posso enfatizar demais o quanto isso é importante, a fim de evitar afogamentos nos dados e passar muito tempo da pesquisa com consultas intermináveis.
• Crie um ciclo de pesquisa eficaz - invista tempo para criar uma boa estrutura de aprendizado de máquina de big data. Realmente valerá a pena a longo prazo e manterá seus cientistas de dados produtivos e felizes.
• Conecte pesquisa e produção - os resultados da pesquisa são inúteis se levar uma eternidade para aplicá-los em seu produto. Ciclos mais curtos permitirão que você experimente mais modelos e implementações e continue melhorando.
  Procure tornar isso o mais rápido e fácil possível.

Máxima comunicação com proteção ao extremo? Avance Network: A verdadeira rede social junte-se a nós