* Por Gerson Koji Saito
Inegável o crescimento explosivo do uso de Python nas grandes corporações. Isso é facilmente comprovado em várias publicações acessadas na web, tanto acadêmicas quanto jornalísticas. Não é à toa que os desenvolvedores focados nas aplicações de missão crítica com uso intensivo de dados passaram unanimemente a preferir as plataformas translíticas de dados para suportar todo tipo de dados e cargas de trabalho.
Afinal, análise de bases de dados e baixa latência são características muito vantajosas dessas plataformas para se trabalhar com modelos analíticos e de aprendizado de máquina (machine learning-ML). Esse trabalho tem como base a criação de modelos de análise que precisam passar por um “treinamento”, que consiste em expor esse modelo a dados históricos e observar como o modelo de ML se comporta e se as conclusões do cientista de dados estão corretas ou não.
A estratégia da escolha por Python, portanto, leva em consideração fatores como grande oferta e demanda de programadores, ter se tornado de fato um padrão de fato para desenvolvimento de modelos de ML e a grande escala de seu uso nas corporações.
O gráfico abaixo mostra o aumento da demanda por programadores em Python.
Um dos pontos mais importantes do ML, no entanto, e que muitas pessoas se esquecem ou não levam em consideração, é a qualidade dos dados usados na etapa de treinamento. Um artigo recente publicado na Forbes nos esclarece sobre isso. A seu respeito, um dos pensadores mais respeitados na comunidade de TI no Brasil, Cezar Taurion, fez o seguinte comentário em um post: “(…) Hoje gasta-se, pelo menos 80% do tempo na preparação e limpeza dos dados para um sistema de ML ser treinado. Modelos com esse conceito tendem a apresentar resultados ruins quando os dados mudam, por exemplo, quando entrando em produção.”
O tempo e o esforço que as corporações dispendem preparando os dados para serem ingeridos nos modelos de ML é muito grande e é “preconceituoso”. O pré-conceito é fazer os dados se adequarem ao modelo, quando o correto seria o inverso. Os dados acumulados representam a vida como ela é, ou seja, a realidade.
O uso de um “Smart Data Fabric”, no qual os dados são tratados como cidadãos de primeira classe, permite que os dados sejam tratados, limpos e anonimizados sem perder a sua significância e a ligação com a realidade.
Um dos grandes gargalos de processamento de modelos analíticos ou de ML é o tempo necessário para preparar os dados, que residem num sistema de armazenamento de dados transacional, e levá-los para o sistema de processamento analítico. Os modelos analíticos requerem uma grande massa de dados, e até o tempo de transferência do resultado de uma query entre os dois sistemas pode ser significativo.
Um dos grandes apelos de se usar Python numa plataforma de dados como a InterSystems IRIS©, por exemplo, é conseguir rodar esses processos analíticos no servidor de banco de dados, eliminando a necessidade de transferir os dados do banco transacional para o servidor de processamento analítico. A partir da versão 2021.2 do InterSystems IRIS©, Python passou a ser uma das linguagens de desenvolvimento que rodam nativamente. A plataforma também permite o desenvolvimento em Java, .Net e ObjectScript©. Dessa forma, os modelos de ML que já existem podem ser portados com pouca ou nenhuma adaptação, o que agiliza o desenvolvimento e a entrada em produção dos modelos de ML.
Hoje a necessidade é que as plataformas de dados sejam translíticas. Translítico é um termo usado pelo Forrester Group para descrever um banco de dados que é capaz de executar operações transacionais tradicionais concomitantemente com operações analíticas. HTAP, do inglês “Hybrid Transactional and Analytical Processing” é outro termo usado para descrever esse tipo de servidor.
A figura abaixo mostra a arquitetura de um teste de ingestão transacional num ambiente translítico. É um teste de performance desenvolvido pela InterSystems e auditado por uma consultoria externa para garantir a idoneidade dos resultados.
Os resultados dos testes de performance HTAP mostram que o InterSystems IRIS© apresenta melhor performance em comparação com outros bancos de dados, em um ambiente misto de ingestão de dados e tempo de resposta das queries.
Os resultados variam entre 60% e 4860% em termos da quantidade de novos registros ingeridos, enquanto os tempos de resposta das queries analíticas variam entre 170% e 5600% na média em favor do InterSystems IRIS©. No link acima, também é possível encontrar os procedimentos para executar o teste em seu próprio ambiente ou em uma nuvem como AWS.
A possibilidade de executar código em Python nativamente na plataforma permite que os cientistas de dados executem os processos no servidor de dados em vez de levar os dados para o servidor de processamento analítico. Além disso, a plataforma de dados deve suportar PMML (Predictive Model Markup Language), que permite que ela importe ou exporte modelos preditivos de Machine Learning, o que a torna a plataforma ideal para a implementação de MLOps (Machine Learning Operations).
MLOps implementa ferramentas para o gerenciamento do ciclo de vida completo de um modelo de ML: treinar o modelo, conduzir análise dos erros para identificar os tipos de dados nos quais o algoritmo apresenta baixa performance, conseguir mais dados via nova coleta ou conseguir marcações mais consistentes para os dados que foram detectados como ambíguos. E finalmente o teste em produção no mundo real, onde os novos dados são usados para refinar continuamente o modelo.
| * Gerson Koji Saito é engenheiro de vendas da InterSystems no Brasil. |
