Crédito da imagem: Getty Images

OBS: Artigo criado por André Sionek (Engenheiro de Dados e trabalha na Gousto, em Londres), originalmente publicado aqui.

Completar alguns cursos online, estudar o dataset Iris, resolver o desafio do Titanic, agendar scripts no agendador de tarefas do Windows. Quem trabalha com dados, de alguma forma já passou por estas situações. Se você conseguiu um emprego na área, vai perceber com o tempo que não dá pra rodar um script crítico para o negócio no próprio laptop que fica ligado 24 horas por dia no escritório. Então fazemos um benchmark, assistimos alguma palestra, lemos algum post e ouvimos coisas como:

Lá na empresa usamos Airflow pra orquestrar as tarefas de ETL e machine learning.

Então nós, aspirantes a cientistas e engenheiros de dados, começamos a estudar Airflow e aprendemos tudo sobre DAGs e Operators. E quando nos damos conta, percebemos que o Airflow ainda roda no nosso próprio laptop e que ele não é nada mais que o velho agendador de tarefas que já usávamos antes. E que aquele script crítico, continua rodando na nossa própria máquina. Então algum desenvolvedor chega na gente e fala:

Tem que rodar isso aí num EC2 na AWS.

Então nós abrimos a documentação, lemos tudo, porém não entendemos nada. Recorremos a mais cursos online e ganhamos certificados bonitos pra mostrar no LinkedIn. Porém conforme mais estudamos, mais ficamos perdidos. Aviso: a quantidade de tecnologias para aprender aumenta exponencialmente com a quantidade artigos e cursos completados.

Agora precisamos aprender Docker, Kubernetes, SageMaker, ECS, Git, Spark, Scala, VPC, Terraform, CircleCI, Lambda, APIs, MLFlow, NiFi, CloudWatch, Jenkins, DBT… E parece que para rodar o bendito Airflow na AWS ou colocar um simples modelo em produção precisaremos aprender tudo isso antes. Porém, ao mesmo tempo, não achamos nenhum conteúdo relevante e específico para nos ajudar.

Parabéns! Você deu de cara no grande muro do mercado de dados.

Que muro é esse aí?

Se a sua ideia sobre o trabalho de um cientista ou engenheiro de dados veio de blogs e cursos online, você provavelmente tem uma visão enviesada. O trabalho de um cientista de dados NÃO É 80% limpeza de dados e 20% modelagem. O trabalho de um engenheiro de dados NÃO É só fazer ETL. As responsabilidades vão muito além disso e geralmente boa parte do trabalho consiste no processo de produtizar os seus scripts ou modelos.

Se você for analisar o conteúdo disponível na internet, vai ver que ele não serve mais pra você estudar por conta e resolver um problema específico (como colocar algo em produção). Isso porque não existe muito conteúdo disponível pra quem chegou nessa etapa. E é por isso que o muro está aí!

Temos muitos links “Caça-Cliques”, cursos e artigos para iniciantes que vendem a ideia do mundo perfeito que existe do lado de lá do muro do mercado de dados, mas pouco conteúdo mostrando a realidade e ensinando as pessoas a vencer o muro e a colocar projetos em produção.

A triste realidade é que se você quiser botar alguma coisa em produção, vai ser só você, Deus e a documentação. Isso quando a documentação for bem escrita.

A boa notícia é que uma vez que você cruzou o muro, as coisas vão ficando mais simples, óbvias, rápidas e reprodutíveis. Criar o primeiro script de deploy automatizado vai te consumir um bom tempo, do segundo em diante vai ser muito mais rápido.

Agora, discutir sobre por que o muro existe já é uma questão mais filosófica, mas eu vejo duas explicações:

• Quem tem experiência em colocar em produção não cria conteúdo sobre o assunto. Produtizar código exige muito trabalho e geralmente ninguém cria uma infraestrutura de produtização só por diversão no final de semana. As pessoas fazem isso dentro das empresas no dia-a-dia, e acabam não escrevendo sobre o assunto. Quando escrevem, é aquele artigo bem raso e promocional pro blog da empresa.
• Escrever sobre produtização dá muito mais trabalho e é muito mais difícil do que escrever um artigo sobre pandas para iniciantes.

O que fazer para vencer o muro?

Se você está desesperado por que acha que precisa aprender trilhões de coisas novas então calma, respire fundo e tente seguir algumas dessas dicas.

Estude somente o essencial

Se você precisa aprender alguma tecnologia nova, não tente aprender tudo o que ela te oferece. Estude somente o básico para você se familiarizar. Por exemplo, se você quer colocar um modelo em produção, pode estudar algum framework como Serverless ou Zappa, mas somente o suficiente para você ter uma noção de como eles funcionam.

Força bruta não é rápido, mas resolve todos os problemas

Depois de estudar o essencial é hora de tentar colocar o seu código em produção usando o que você acabou de aprender. Com certeza vai falhar. Estude o erro, use o Google, faça modificações e tente de novo. E repita até conseguir. Em uma ou duas semanas você terá aprendido muito mais sobre aquela tecnologia do que qualquer curso ou artigo poderia te ensinar. É claro que você somente terá aprendido o necessário pra colocar o modelo em produção. Mas você fez sozinho, na força bruta, e a cada iteração você aprendeu alguma coisa nova. Com cada erro besta, ganhou mais experiência.

Pode ser que você não saiba imediatamente usar aquela tecnologia com outro propósito, mas se um dia você precisar, estará numa posição muito melhor e conseguirá aprender muito mais rápido.

Peça para um desenvolvedor rever o seu trabalho

Depois que você tiver algo que julga pronto para ir pra produção, peça para um desenvolvedor revisar. Eles já estão acostumados com processo de revisão de código e conhecem boas práticas que você pode implementar. Não entre no detalhe do algoritmo ou do script que você vai executar, o foco é entender se seu código está pronto para produção. Provavelmente você vai voltar com uma lista de coisas que precisam ser melhoradas.

Por experiência própria, não adianta muito pedir ajuda aos desenvolvedores para aprender algo novo, pois não vão ter tempo de te pegar pela mão e ensinar alguma tecnologia nova. As exceções são algumas ferramentas que eles já utilizem no dia a dia, como Git e CircleCI. Mas mesmo assim, provavelmente você só vai ganhar algumas aulas introdutórias ao assunto. Depois vai ter que ser na força bruta.

Tente pensar nos cenários limite

O que vai acontecer se eu tiver 1000 requisições simultâneas na minha API? E se o job de ETL falhar na metade, vai gerar dados duplicados? E se o job parar de funcionar, como eu identifico e atuo rapidamente? E como eu identifico se meu modelo está rodando, mas retornando resultados incorretos? E se minha API receber um payload inválido?

Pensar nos casos limite vai te ajudar a procurar soluções antecipadas para estes problemas. Que acontecem com uma frequência maior do que você imagina.

Aprenda e aplique boas práticas de desenvolvimento de software

Ao criar projetos de dados que irão para produção tente aplicar algumas boas práticas como:

• Infraestrutura como código
• Configurável com YAML
• Integração contínua (CI/CD)
• Testes unitários
• Alertas e monitoramento
• Documentação

Se pra fazer deploy do teu código, você precisa pausar todos os teus jobs e então subir uma nova instância na mão, então não está pronto pra ir pra produção. Se pra mudar alguma configuração você precisa alterar o código fonte, pois está “hard-coded” então também não está pronto pra produção.

Como aprender boas práticas?

Trabalhando numa empresa que já implemente boas práticas e aprendendo com exemplos, ao observar como as outras pessoas produtizam código.

Ou aprendendo na dor, ao fazer algo errado que poderia ser evitado por boas práticas.

Ou criando projetos nos fins de semana. Ao invés de só treinar o modelo pra predizer o preço de um imóvel, coloque ele em produção, automatize o deploy, crie testes e alertas, escreva uma boa documentação. E depois publique um artigo sobre como você fez!

O que fazer para destruir o muro?

Se você já está do lado de lá do muro então crie conteúdo direcionado para esse público que já aprendeu o básico, mas que não sabe colocar algo em produção. Escreva tutoriais e artigos, disponibilize repositórios que facilitem a vida de quem quer pular o muro.

Eu já perdi quase um mês de trabalho tentando colocar o Airflow em produção na AWS. Na época só encontrava conteúdo básico ensinando a fazer deploy em Docker/localmente. Depois de muita pesquisa achei um repositório que me ajudou a fazer deploy em ECS com Terraform, mas mesmo assim, não tinha funcionalidades de autoscaling e outras necessidades específicas para um ambiente produtivo de verdade. Recentemente publiquei um repositório que resolve boa parte desses problemas. Se eu perdi quase um mês com isso, então provavelmente outras pessoas passam pela mesma dificuldade. Por que não ajudá-las?

Criar pontes para ajudar as pessoas a cruzarem essa etapa desafiadora da carreira em dados é bom para você que publica conteúdo: aprofunda seu conhecimento e melhora o seu portfólio. E também é bom para quem está sofrendo tentando pular esse muro: aprende mais rápido aplicar boas práticas e a colocar projetos em produção.

Você prefere ter alguém ingressando no seu time que já tenha boas noções de produtização? Ou quer começar ensinando que o agendador de tarefas não é uma boa opção?

André Sionek (Engenheiro de Dados e trabalha na Gousto, em Londres), é facilitador do Bootcamp Engenharia de Dados, com foco em produtização, aqui, na How.