No outro dia, decidimos conversar com Dmitry Bugaychenko ( dmitrybugaychenko ), um de nossos professores do programa Análise de Dados no Scala, e discutir com ele questões reais do uso do Scala nas tarefas de Ciência de Dados e Engenharia de Dados. Dmitry é um engenheiro analítico em Odnoklassniki.
- Dima, você trabalha na Odnoklassniki. Diga-me, o que você está fazendo aí?
Em Odnoklassniki, comecei a trabalhar em 2011 em uma recomendação de música preliminar. Foi uma tarefa muito interessante e difícil - a maioria dos serviços de recomendação de música da época era baseada em conteúdo de publicação bem catalogado, enquanto tínhamos UGC (conteúdo gerado pelo usuário) real, que precisava ser penteado e classificado primeiro nas prateleiras. Em geral, o sistema resultante mostrou-se bastante bom e eles decidiram estender a experiência para outras seções do site: recomendações de grupos, amizades, classificação do feed etc. Ao mesmo tempo, a equipe cresceu, a infraestrutura foi desenvolvida, novos algoritmos e tecnologias foram introduzidos. Agora, tenho uma gama bastante ampla de responsabilidades: coordenação dos dados dos cientistas, desenvolvimento da infraestrutura do DS, projetos de pesquisa etc.
- Há quanto tempo você começou a usar o Spark? Qual é a necessidade?
As primeiras tentativas de fazer amizade com o Spark foram em 2013, mas não tiveram êxito. Tínhamos uma necessidade urgente de uma ferramenta interativa poderosa que nos permitisse testar rapidamente hipóteses, mas o Spark daquele tempo não podia fornecer a estabilidade e a escalabilidade que precisávamos. A segunda tentativa que fizemos um ano depois, em 2014, e desta vez tudo ficou muito melhor. No mesmo ano, começamos a implementar ferramentas de análise de streaming baseadas em Kafka e Samza, experimentamos o Spark Streaming, mas não foi possível iniciar. Devido à implementação relativamente cedo, em 2017 nos encontramos em uma posição de recuperação por um tempo - uma grande quantidade de código no primeiro Spark nos impediu de mudar para o segundo, mas no verão de 2018 resolvemos esse problema e agora estamos trabalhando no 2.3.3. Nesta versão, o streaming já funcionou mais estável e já fizemos algumas novas tarefas de prod.
- Pelo que entendi, você usa a API Scala, não Python, como a maioria. Porque
Sinceramente, não vejo razão para usar o Python para trabalhar com o Spark, exceto pela preguiça. A API Scala é mais flexível e muito mais eficiente, mas não mais complicada. Se você usar os recursos padrão do Spark SQL, o código Scala será quase idêntico ao código Python correspondente e a velocidade será idêntica. Mas se você tentar criar a função mais simples definida pelo usuário, a diferença se tornará óbvia - o trabalho do código Scala permanece tão eficiente e o código Python transforma um cluster de vários núcleos em uma abóbora e começa a queimar quilowatt / hora para atividades completamente improdutivas. Na escala com a qual temos que trabalhar, simplesmente não podemos permitir esse desperdício.
- Python C é compreensível. E quando comparado ao Java, o Scala é algo melhor para análise de dados? Em Java, muitas coisas são escritas na pilha de big data.
Usamos o Java muito amplamente, inclusive no aprendizado de máquina. Tentamos não acessar os aplicativos Scala mais carregados. Mas quando se trata de análise interativa e prototipagem rápida, o laconicismo de Scala se torna um plus. É verdade que você sempre deve ter em mente que, ao programar no Scala, é muito fácil levar as pernas aos ouvidos - muitos designs podem não se comportar como você esperaria de uma posição de bom senso, e algumas operações simples causam cópias desnecessárias e tentativas de materializar enormes conjuntos de dados na memória.
- Com todas essas vantagens, por que o Scala ainda não é tão popular? Claramente supera Python e Java?
Scala é uma ferramenta muito poderosa que requer uma qualificação suficientemente alta de quem a utiliza. Além disso, com o desenvolvimento da equipe, requisitos adicionais também são impostos ao nível geral da cultura de desenvolvimento: o código no Scala é muito fácil de escrever, mas nem sempre é lido com sucesso pelo autor após algum tempo e, sob o capô de uma API simples, ele pode criar algum tipo de jogo. Portanto, atenção especial deve ser dada à manutenção de um estilo unificado, teste funcional e de estresse da solução.
Bem, ao comparar idiomas da JVM, não se pode deixar de mencionar o Kotlin - ele está ganhando popularidade, é considerado por muitos como mais "verificado ideologicamente" e até suporta o Spark como parte do projeto do sparklin, embora ainda seja muito limitado. Nós mesmos ainda não o usamos para o Spark, mas estamos acompanhando de perto o desenvolvimento.
- De volta ao Spark. Pelo que entendi, você ainda não gostou da funcionalidade da API Scala e escreveu algum tipo de fork para o Spark?
Seria errado chamar a bifurcação do projeto PravdaML : esta biblioteca não substitui, mas complementa a funcionalidade SparkML com novos recursos. Chegamos às decisões que foram implementadas lá, tentando escalar e colocar nos trilhos reproduzíveis os modelos de classificação de fitas. O fato é que, ao desenvolver algoritmos efetivos de aprendizado de máquina distribuído, é necessário levar em consideração muitos fatores "técnicos": como decompor corretamente os dados em nós, em que ponto armazenar em cache, reduzir a amostra etc. Não há como gerenciar esses aspectos no SparkML padrão, e eles precisam ser movidos para além do pipeline de ML, o que afeta negativamente a capacidade de gerenciamento e a reprodutibilidade.
- Lembro que você tinha duas opções para o nome ...
Sim, o nome original ok-ml-pipelines parecia chato para os caras, então agora estamos no processo de “rebranding” com o novo nome PravdaML.
- Muitas pessoas usam isso fora do seu time?
Não penso muito, mas estamos trabalhando nisso. J
- Vamos falar sobre papéis e profissões no campo do trabalho com dados. Diga-me, um cientista de dados deve escrever código em produção ou isso já é outra profissão e função?
A resposta a esta pergunta é a minha opinião e existe uma dura realidade. Sempre acreditei que, para a implementação bem-sucedida de soluções de ML, uma pessoa deve entender onde e por que tudo está sendo implementado (quem é o usuário, quais são suas necessidades e quais são as necessidades da empresa), precisa entender quais métodos matemáticos podem ser aplicados para desenvolver a solução e como esses métodos podem funcionar do ponto de vista técnico. Portanto, em Odnoklassniki ainda tentamos aderir ao modelo de responsabilidade única, quando uma pessoa cria alguma iniciativa, a implementa e implementa. Obviamente, para resolver problemas particulares, seja um DBMS eficaz ou uma composição interativa, você sempre pode atrair pessoas com grande experiência nessas áreas, mas a integração de tudo isso em um único mecanismo permanece com o Cientista, como a pessoa que melhor entende o que exatamente deve funcionar. saída.
Mas existe uma dura realidade no mercado de trabalho, que agora está superaquecido no campo da ML, o que leva ao fato de muitos jovens especialistas não considerarem necessário estudar outra coisa que não a própria ML. Como resultado, fica cada vez mais difícil encontrar um especialista em ciclo completo. Embora uma boa alternativa tenha surgido recentemente: a prática mostrou que bons programadores aprendem ML rapidamente e muito bem. J
- O engenheiro de data precisa conhecer Scala? Quão bom, a propósito? Preciso entrar na selva da programação funcional?
É definitivamente necessário conhecer o Scala, apenas porque duas ferramentas fundamentais, como Kafka e Spark, estão escritas nele, e você precisa ler o código-fonte. Quanto à "selva da programação funcional", recomendo fortemente que não abusem demais: quanto mais desenvolvedores puderem ler e entender o código, melhor. Mesmo que, para isso, às vezes você precise implantar um design funcional "elegante" em um ciclo banal.
- O universo de profissões nessa área já deixou de se expandir, ou ainda devemos esperar o surgimento de novas profissões?
Penso que, no futuro previsível no ML e no DS, haverá um ponto de virada relacionado à automação: os principais padrões que as pessoas seguem ao trabalhar com atributos, escolher um modelo e seus parâmetros e verificar a qualidade serão automatizados. Isso levará ao fato de que a demanda por especialistas que "selecionam os parâmetros" diminuirá significativamente, mas os engenheiros do AutoML que são capazes de implementar e desenvolver soluções automatizadas estarão em demanda.
"Você está ensinando ativamente, como eu o entendo." Por que você considera isso importante? Qual é a motivação por trás disso?
Todos nós um dia nos aposentaremos e a qualidade de nossa vida dependerá muito de quem nos substituirá. Portanto, o investimento na educação da próxima geração é um dos mais importantes.
- Em nosso programa "Data Analysis on Scala", você realizará várias aulas. Conte-me brevemente sobre eles. Qual a importância deles?
Nestas aulas, estudaremos apenas como a engenharia e a matemática se encaixam: como organizar o processo corretamente, sem introduzir barreiras desnecessárias ao ETL-> ML-> Prod. O curso será desenvolvido com base nos recursos do Spark ML: conceitos básicos, conversões suportadas, algoritmos implementados e suas limitações. Entraremos em contato com a área em que os recursos existentes do SparkML não são suficientes e torna-se necessário o uso de extensões como o PravdaML. Bem, definitivamente haverá prática, não apenas no nível de “montagem de uma solução a partir de cubos prontos”, mas também sobre como entender que um novo “cubo” é necessário aqui e como implementá-lo.
- Existe algum trocadilho favorito com Scala? Parede de escalada, alpinista, arte rupestre - você usa em sua rotina diária?
A menos que o epíteto "indoskal", que usamos para abordar partes particularmente notáveis de código aberto, cujo autor claramente desejasse demonstrar a notável capacidade de construir código ilegível usando abstrações funcionais.
Moscou ou Peter?
Cada cidade tem seu próprio entusiasmo. Moscou é uma cidade rica e bem cuidada, com um ritmo rápido. Peter é mais calmo e cheio do charme da antiga capital europeia. Por isso, gosto de vir a Moscou para visitar, mas prefiro morar em São Petersburgo.