Feature Store do zero à automação com esteiras de CI/CD
Por: Monica Borges
Revisores: Iago Brandão, Willy Hsu e João Marcos Badaró
VIA — Uma das maiores varejistas no país
A Via é conhecida como uma das maiores varejistas do país, atuando no ramo desde 2010. Somos responsáveis pelas redes Casas Bahia e Ponto, além de gerenciar o site de e-commerce Extra.
Definimos a nossa estratégia baseados em Customer Centric, onde o Cliente é o nosso pilar; a fonte de combustão que alimenta e impulsiona nossas decisões no negócio, porém, para que essa estratégia de fato impacte a vida de todos nossos clientes e parceiros (internos e externos), contamos com um time gigantesco de áreas (RH, administração, tecnologia, marketing, logística etc.), que atua de forma integrada com objetivo de garantir eficiência, qualidade e transparência para todos nossos stakeholders.
Identificando o problema…
Atendemos diariamente diversos clientes ao redor do Brasil. Clientes estes, que estão cada vez mais engajados em acompanhar de perto as evoluções da marca. Cobrando sempre por um serviço justo, personalizável e que atenda de fato sua necessidade. E quando falamos em necessidade, podemos estar nos referindo à clientes que enfrentaram algum tipo de problema, seja no momento de realizar sua compra no app; atraso na entrega; erro na geração de faturas ou até mesmo problemas internos. Todas essas informações de erros ou problemas são registradas em nossos bancos de dados e para que situações semelhantes sejam mitigadas no futuro, utilizamos os mesmos dados do passado como inferências na construção de modelos de Machine Learning.
Destrinchado Machine Learning através de um problema real…
Quando pensamos em Machine Learning, quase que subitamente uma sensação de algo sobrenatural pode surgir e várias palavras podem vir à tona a fim de trazer conforto e segurança em relação ao que de fato estamos nos referindo: estatística, codificação, padrão, testes, deploy, qualidade, escala, desenvolvimento, consistência… E embora todas essas palavras estejam relacionadas, podemos facilitar o entendimento definindo Machine Learning como uma contribuidora na solução de "DORES" que foram exemplificadas anteriormente; porém, para que o processo tenha início através de uma solicitação da área cliente (área de negócio) e seja entregue, por intermédio de uma API ou até mesmo com os resultados de predição (scoring) do modelo salvos em uma base especifica de dados, existe um processo gigantesco… mas hoje, iremos compartilhar um dos desafios encontrados e a forma que encontramos de contorná-lo.
"Mas de fato, como funciona o processo de modelagem"
Metodologia CRISP-DM
Assim que o cientista recebe a solicitação da área de negócio, a escolha de alguma metodologia de desenvolvimento pode ser escolhida; que para o nosso exemplo será a CRISP-DM…
Tendo como base a metodologia acima; logo após o entendimento do problema com a área solicitante e entendimento dos dados com auxílio do time de engenharia/governança; o cientista se concentra na etapa de “data preparation”, que basicamente envolve a análise, limpeza e transformação de dados, com objetivo de construir a Master Table (ABT — Analytical base table), ou seja, a tabela contendo features que servirão para alimentar o modelo. E aqui, entra um ponto extremamente relevante: “O sucesso de um modelo está diretamente relacionado à qualidade de suas variáveis de entrada”, ou seja, se imputarmos sujeira em uma prensa, teremos sujeira na saída; portanto, para que seja desenvolvido um modelo de qualidade, é imprescindível que sua tabela de alimentação, contenha features de qualidade… Por este motivo, cada variável é analisada de forma individual e conjunta, através de uma descritiva com uma série de exigências, dependendo das técnicas que serão utilizadas posteriormente. Como estamos falando da experimentação entre diversas variáveis, fica nítido o nível de energia exigidos nesta etapa, que pode corresponder entre 60% e 70% de todo esforço envolvido para o desenvolvimento completo de um modelo. Considerando este cenário, encontramos alguns gargalos que poderiam ser ajustados, trazendo agilidade, padronização e economia.
Identificando gargalos
Ao considerar cientistas atuando em áreas diferentes da empresa; embora estejam atuando na solução de problemas específicos, em muitos casos, as mesmas features, fazem parte do conjunto relevante para a solução de problemas distintos. Neste caso, temos alguns problemas:
1 — Vários cientistas concentrando o seu tempo e energia no desenvolvimento da mesma variável;
2 — Duplicidade de códigos no DataLake, considerando que essas informações serão salvas.
Analisando o cenário acima; temos em resumo: Má gestão de tempo; duplicação de códigos, gerando um ambiente “poluído” e gastos elevados de armazenamento.
Uma possível solução…
Para contornar os problemas mencionados, surge o Feature Store, que basicamente é um centralizador de features de Machine Learning; um repositório de dados, que suporta variáveis únicas em diversos formatos (batch, streaming ou real-time), resolvendo assim nossos problemas de duplicação e compartilhamento.
Em meio à testes e implementações, surge a dúvida: “Como padronizamos o processo garantindo integridade, segurança e ESCALA? Enquanto estudávamos sobre a ferramenta, um termo ainda mais novo surge: Feature Store Platform, que sucintamente “abraça” o Feature Store incluindo novas funcionalidades com o objetivo de garantir um processo end-to-end escalável. As funcionalidades inseridas são:
· Design (SQL, Spark, Python);
· Repositório (GitHub);
· Engenharia (unificação de diversas fontes de fontes de dados);
· Gerenciamento (monitoria, governança e discovery).
Organização do projeto no Github
Perfeito… tínhamos o caminho das pedras, mas por ser um tema totalmente novo, o modo de desenvolvimento e estruturação do processo foi sem dúvidas um grande e rico aprendizado. O primeiro deles envolveu o entendimento de como criar e atualizar Feature tables de forma manual. O intuito, era justamente aprender e sentir como funcionava a nova ferramenta… durante essa etapa, percebemos a necessidade de versionar tudo no GitHub, mas como? Monorepo? Multi-repo? Foi um processo de muitas conversas e alinhamentos até estruturarmos um repositório que atendesse nossa necessidade… adotamos o desenvolvimento com a utilização de Mono-repos, onde cada tabela sugerida, faz parte de um grande assunto (CRM, cliente, pedido, logística, navegação etc.). Temos portanto, tabelas de assuntos distintos inseridas em um grande assunto.
Durante o desenvolvimento manual das Features Tables, identificamos um padrão que foi convertido em template… após sua validação de eficiência contemplando alguns de nossos cenários, foi feita a inclusão em nosso repositório… acreditem, foi gratificante ver o GitHub tomando forma e evoluindo… decidimos então, padronizar as branchs para que trouxesse ainda mais organização. Abaixo, descrevemos o que consta em cada branchs:
· Master: Tabelas em camada produtiva, sem inteiras de CI/CD;
· Dev: Tabelas em camada de desenvolvimento, contendo nossas esteiras de CI/CD.
· Legado: Contendo tabelas iniciais de testes e experimentações iniciais.
Mas, como em tecnologia resolvemos um problema e criamos outro, para assim resolver e criar e resolver… percebemos que não queríamos mais executar o processo de forma manual; era cansativo, repetitivo e sem grandes desafios…
CI/CD
Os olhos brilhavam ao enxergar um novo desafio, que provavelmente nos levaria à um patamar jamais discutido para o cenário… E a pergunta que martelava era justamente: Como automatizar… seguindo os aprendizados internos de deploy, nos perguntamos, por que não adotar a filosofia DevOps para inserção e atualização das Feature Tables de forma escalável…
Esteira de CI — Continuous Integration
Quando falamos em Integração, estamos nos referindo aos testes… Nessa primeira fase da esteira, estamos concentrados em garantir que tudo o que desenvolvemos está de fato funcionando como deveria… O Template está correto no repositório? As funções independentes estão retornando os resultados esperados? As funções dependentes estão retornando os resultados esperados? O processo por completo funciona como esperado?
No nosso desenho inicial para o CI, temos 3 etapas:
· CI [1] Um “validator” que: 1 — verifica se o desenvolvimento da Feature Table segue o template adotado previamente, com arquivos, classes e funções obrigatórias; 2- Analisa o Padrão de Nomenclatura das tabelas e colunas.
· CI [2] Formatação do código inserido conforme PEPs e normas sugeridas pela linguagem Python: Formatador e ordenador de todos nossos arquivos Python com as bibliotecas Blue e isort;
· CI [3] Testes em toda camada de desenvolvimento (Pytest/Unittest): 1- Testes unitários; 2- Testes de Integração; 3- Teste End-to-end.
· * Lembrando que, todas as classes e funções desenvolvidas contam com Docstrings e Type hints, conforme PEPs e normas sugeridas pela linguagem Python.
Esteira de CD — Continuous Delivery
Quando falamos em CD, nos referimos à parte da realização automatizada das tarefas que de fato precisamos realizar de forma manual… no nosso caso, seria o processo de inserção da Feature Table no nosso Feature Store… Só que embora o processo envolve diversas tarefas… para a execução automatizada, precisamos que uma série de etapas seja executadas:
· CD [1]: Clona o nosso projeto na branch especificada em uma VM Linux;
· CD [2]: Gera os artefatos (arquivos python, na mesma estrutura que executamos localmente) que serão executados em cluster (“Super Máquina”) — arquivo shell;
· CD [3]: Envia os artefatos para o Blob;
· CD [4]: Envia as bibliotecas necessárias para execução do processo para um caminho que o cluster consiga “enxergar”;
· CD [5]: Cria nosso pipeline de criação/atualização da Feature Table no ADF (Azure DataFactory) com trigger de execução.
Para que as etapas de CI/CD seguissem um fluxo conectado e dependente, adotamos o GitHub Action como workflow. O que temos dentro do nosso repositório é basicamente um diretório chamado que contém nossos yaml`s.
Nosso arquivo yaml de CI/CD
Achamos importante dar uma pincelada em como pensamos em desenvolver o yaml:
0. O nosso arquivo está atrelado à branch;
1. CI [1]
2. CI [2]
3. CI [3]
** O CD possui dependência do CI, ou seja, só é permito a execução do CD, caso o CI ocorra com sucesso. Após isto, temos as seguintes etapas:
4. CD [1]
5. CD [2]
6. CD [3]
7. CD [4]
8. CD [5]
Destaco a seguir, algumas tecnologias e ferramentas utilizadas para a resolução compartilhada.
Até aqui, foi um caminho cheio de desafios e muito aprendizado, porém, permanecemos otimistas em relação ao futuro.
Finalizo agradecendo ao meu coordenador, Iago Modesto Brandão e à todo time de Dados, MLOps e parceiros Via! Em especial, deixo os meus sinceros agradecimentos aos gestores da área de DataOps Luciano Pinho, Renato Tironi, Cézar Steinz e Jonathan Santana e aos meus pares Pedro Carvalho, Willy Hsu, Dante de Souza, Antonio Gerardo e Eric Venarusso.
