Criando um pipeline model na AWS sem SageMaker
O uso de Machine Learning e Bigdata tem ganhado cada vez mais espaço nas empresas. Entender o comportamento dos clientes é fundamental, para que seja possível aproveitar as oportunidades de negócio. É preciso mitigar o Churn Rate e conseguir estabilidade nos serviços; Assim como também é preciso lidar com terabytes de dados produzidos e se reinventar. Para ajudar nesse processo, as Cloud oferecem uma infraestrutura que não seria possível tê-la “feita em casa”. Nesse sentido, o fato de ter à disposição o trabalho de vários engenheiros devops, que estão preocupados com a infraestrutura, é fascinante pois, é o que permite dar saltos maiores no negócio. O arcabouço infraestrutural é bastante importante ao se produzir modelos com machine learning, devido ao fato de se encontrar processos de treinamento demorados, que duram horas ou dias, até mais !, o que exige grande capacidade de processamento, várias GPUs, rede, armazenamento e segurança, afinal, dados são o novo petróleo.
O pipeline model é o processo que envolve a extração dos dados de alguma fonte, posterior armazenamento, assim como formatação adequada destes. O pipeline model inicia como um processo de ETL. Mas, não para por ai, ainda é preciso treinar um modelo. Por que não selecionar o melhor modelo antes ? otimizá-lo alterando seus hiperparâmetros, disponibilizar esse modelo pré-treinado e criar uma API, se for a caso, para consumo. Tudo isso, de forma automatizada, síncrona e transparente, logs de execução . Ufa ! acabou ? — Ainda não. É preciso versionar os modelos de acordo com a periodicidade de geração. Dado tudo isso, como posso estruturar meu pipeline model garantindo os passos necessários ?
A Amazon oferece um serviço que é responsável por gerenciar toda essa esteira de construção de soluções de ML e Bigdata, o SageMaker. Este, oferece suporte desde a etapa de coleta e preparação dos dados com o Amazon SageMaker Ground Truth, que segundo a própria AWS pode reduzir em até 70% o custo com rotulação. Suporte a Notebooks Jupyter o que ajuda na resolução de problemas comuns e compartilhamento de data storytelling. Na escolha do algoritmo é possível optar por TensorFlow, de forma otimizada, Apache MXNet, PyTorch, Chainer, Scikit-learn, SparkML, Horovod, Keras e Gluon. Bastante não é mesmo ? Ainda há os algoritmos pré-treinados e a possibilidade de integrar um modelo com container Docker. Ainda é possível otimizar um modelo previamente escolhido por meio de seleção de hiperparâmetros o que pode ocasionar ganho de dias ou semanas na configuração do modelo. Por fim, o modelo é versionado automaticamente, e disponibilizado por meio da criação de endpoints.
Mas se o SageMaker oferece toda as ferramentas necessária para disponibilização do meu modelo, e de uma forma otimizada, pensando em redução de custos, por que deveria optar por não usar ?
Bem, em um passado não muito distante, os MainFrames eram as grandes forças de processamento das grandes corporações. Com o passar do tempo, praticamente uma empresa continuava a suporta-los e produzi-los. Isso acarretou em uma dependência tecnológica que dificulta a migração entre tecnologias e plataformas que oferecem algum tipo de benefício não encontrado até então. Caso evitar a dependência de uma nuvem específica não seja um problema, é recomendável continuar com o SageMaker. Caso não, continuemos !.
A primeira etapa do nosso pipeline acontece ao extrair os dados de uma fonte, e formatá-los de acordo com as necessidades. Para esse primeiro processo pode ser utilizado o AWS EMR que vem pré-configurado com Spark e Hadoop. Por baixo dos panos, o EMR cria um EC2 com determinadas versões do Spark e Hadoop, além de outras configurações desejadas. E assim, por meio de um script Python, Scala ou mesmo com Java é possível extrair e formatar os dados. O EMR pode ser chamado utilizando Lambdas que disparam em um horário específico, o que torna o processo barato e configurável. Ao final desse processo, um arquivo de entrada para treinamento do modelo pode ser disponibilizado em Bucket no S3 ou, se for o caso no Elasticahe com Redis ou outros.
O próximo passo é lançar mão do arquivo de entrada devidamente formatado e realizar o treinamento do modelo. Para isso, uma Lambda orquestrará um EC2 para treinamento especificando entradas, scripts para execução e parâmetros para otimização. Essa Lambda pode ser chamada diretamente do EMR, imediatamente depois da disponibilização do arquivo de entrada, ou ser chamada em um momento específico. Ao final, uma versão treinada e otimizada do modelo será armazenado e versionado em um Bucket S3 por exemplos.
A última etapa se dá a disponibilizar esse modelo por meio de apis. Uma EC2 com auto scaling é criada e pode ser avisada na criação de um novo modelo, e assim ir na fonte de armazenamento e baixá-lo, ou pegá-lo de tempos em tempos por meio de crontab com ebextesions.
No final, um pipeline automático será capaz de disponibilizar seu modelo em formato de fácil manutenção e independente de tecnologias específicas.