Ferramentas e Tech Stack do Data Scientist: O Guia Honesto de 2026

Deixe-me descrever o stack que a maioria das equipes de ciência de dados realmente tem, inclusive as que contam com empresas com ARR de oito dígitos por trás.

Um notebook Jupyter no laptop de alguém. Um CSV no S3 com um nome como clientes_FINAL_v3_use_este.csv. Um model.pkl que alguém enviou para um engenheiro backend pelo Slack três trimestres atrás. Um dashboard no Looker em que ninguém confia porque os joins ficam mudando silenciosamente. Uma página no Confluence intitulada "Arquitetura de ML" que foi editada pela última vez no dia antes de o antigo líder de dados pedir demissão.

Se esse é o seu stack, você não está atrasado. A maioria das equipes está aqui. A pergunta honesta não é se a sua situação é constrangedora. É se você fica aqui ou se faz o trabalho entediante para sair.

Este guia é para o Data Scientist IC (não o VP, não a equipe de plataforma) que precisa construir um stack do zero ou auditar a bagunça remendada que herdou. Vamos percorrer as 6 Camadas Principais, nomear os padrões open-source, nomear as alternativas pagas e dizer claramente quando cada uma vale a pena. Se você quiser contratar para essa função corretamente, o template de JD para Data Scientist é o guia complementar.

Por que isso importa agora

Modelos em notebooks não geram dinheiro. A diferença entre "treinei um modelo com AUC 0,87" e "o negócio usa essa previsão todos os dias para tomar uma decisão" é aproximadamente 80% de ferramentas e 20% de ciência. Ninguém gosta de ouvir isso, especialmente o DS que passou três anos em um PhD em estatística, mas é verdade.

O Data Scientist que consegue montar o stack completo do data warehouse até o monitoramento é quem se promove, consegue headcount, consegue orçamento e para de ser tratado como um centro de custo que roda SQL. O que não consegue é quem fica publicando notebooks e se perguntando por que a próxima demissão tem o nome dele.

Você não precisa amar MLOps. Precisa ser versado nisso.

As 6 Camadas Principais: o que todo stack de ML realmente precisa

Seis camadas. Preços reais. Quando vale a pena fazer o upgrade.

Vamos detalhar cada camada, porque a tabela é a cola de bolso, não o argumento.

Data warehouse / camada de dados

Snowflake, BigQuery ou Databricks SQL. Escolha o que sua equipe de Engenharia de Dados já paga. Se não houver equipe de Engenharia de Dados e você está escolhendo do zero, o BigQuery é o mais barato para começar (pague por consulta a $6,25/TB processado, sem custo de warehouse ocioso) e o Snowflake é o mais fácil de compartilhar com analistas não técnicos.

O erro que vejo toda semana: uma equipe de DS tentando "economizar dinheiro" treinando modelos diretamente de Parquet bruto no S3, sem camada de warehouse, cada job relê 200GB e reescreve schemas com Pandas. Isso não é economizar dinheiro. É queimar horas de DS, que custam dez vezes mais do que os créditos de warehouse que você evitou. Compre o warehouse. Use dbt para transformar dentro dele. Treine com tabelas curadas.

Notebook / IDE

Jupyter é gratuito, local e suficiente para trabalho solo. Para equipes de três ou mais, os notebooks colaborativos (Hex a $40-$80/usuário/mês, Deepnote levemente mais barato) justificam o custo porque colocam SQL, Python e um artefato publicável em uma única tela. As partes interessadas conseguem ler um documento no Hex; não conseguem ler seu analise_v7_final.ipynb.

Os Databricks Notebooks vêm incluídos com o compute do Databricks. Se você já paga pelo compute, os notebooks são adequados. Se não paga, você está pagando o preço da plataforma Databricks por algo que é essencialmente um Jupyter hospedado, e essa conta não fecha.

Opção subestimada: VS Code com a extensão Jupyter. Gratuito, rápido, tem git de verdade, debugger e extensões. A maioria dos Data Scientists sênior que respeito usa para trabalho sério e reserva os notebooks hospedados para exploração e compartilhamento com partes interessadas.

Rastreamento de experimentos

Essa é a camada onde a maioria das equipes tem três ferramentas porque ninguém decidiu. Escolha uma.

O MLflow é open-source e pode ser hospedado em uma VM pequena por cerca de $50/mês. A UI de rastreamento é adequada. O registro de modelos funciona. Você vai gastar talvez um dia de Engenharia configurando e algumas horas por trimestre mantendo.

O Weights & Biases tem a UI mais bonita da categoria, é o mais fácil de compartilhar com partes interessadas e vale a pena pagar (entre $20 e $100 por usuário por mês dependendo do plano) se você rodar mais de vinte experimentos por semana ou se sua equipe realmente usar as ferramentas de comparação. Se vocês dois rodam três experimentos por trimestre, o MLflow é suficiente e o W&B é exagero.

O Neptune.ai é a alternativa mais barata ao W&B com a maioria das mesmas funcionalidades. Vale a pena conferir se os preços do W&B assustam.

Qualquer que seja a escolha, elimine as outras. O pior stack de rastreamento de experimentos é o em que Alice usa W&B, Bob usa MLflow e o novo contratado abre TensorBoard porque era isso que havia no emprego anterior.

Repositório de atributos

O Feast é open-source e gratuito em dólares. Não é gratuito em horas. Você precisa hospedar Redis (ou outro armazenamento online), configurar o registro, escrever os jobs de materialização e manter tudo funcionando. Para uma equipe de dois com três modelos em produção, o Feast é infraestrutura teórica e um projeto dbt bem organizado faz o mesmo trabalho com um décimo da manutenção.

O Tecton é a opção paga enterprise. O preço inicial está em seis dígitos. Só se justifica se você tem 50+ modelos em produção com reuso real de atributos entre equipes. Uma equipe de duas pessoas comprando Tecton é o sinal mais alto possível de má alocação de capital neste campo.

O Databricks Feature Store vem incluído se você já usa Databricks. Use-o se for o caso. Não troque de plataforma para obtê-lo.

Opinião honesta: a maioria das equipes com menos de dez modelos em produção ainda não precisa de um repositório de atributos. Precisam de pipelines de atributos limpos no dbt e de uma convenção de nomenclatura. Pule a camada de repositório de atributos até que a dor de duplicar atributos em cinco jobs de treinamento fique mais alta do que a dor de configurar o Feast.

Disponibilização do modelo

A camada de disponibilização é onde a maioria dos stacks é superprojetada. Quatro opções reais:

O SageMaker é nativo da AWS, complexo e custa cerca de $0,05 a $2 por hora por endpoint dependendo da instância. É a resposta certa se você já usa muito AWS e tem um engenheiro de plataforma para gerenciar endpoints. É a resposta errada se você é uma equipe de dois DS e só quer um modelo atrás de um endpoint HTTP.

O Vertex AI é o equivalente do GCP. Preços semelhantes, complexidade semelhante, ressalvas semelhantes.

O Modal é GPU serverless. Você paga por segundo de compute. É excelente para inferência variável (recomendações em um site de baixo tráfego, jobs de pontuação em lote, qualquer coisa onde você pagaria por um endpoint ocioso). A experiência do desenvolvedor é a melhor da categoria. É minha recomendação padrão para configurações solo e de equipes pequenas.

O BentoML é um framework open-source. Você escreve sua lógica de inferência, o BentoML empacota, e você implanta o pacote no Kubernetes (ou Modal, ou Lambda, ou onde preferir). Combine com Modal e você tem um stack de GPU serverless a preços de startup.

A combinação Modal mais BentoML é o que eu construiria hoje se estivesse montando uma equipe de DS do zero sem equipe de plataforma. O SageMaker é o que você escolhe quando tem uma equipe de plataforma e um contrato de procurement que já inclui créditos AWS.

Monitoramento e detecção de desvio

Se você tem modelos em produção e nenhum monitoramento, você não tem modelos em produção. Tem bombas-relógio pontuadas por AUC.

O Evidently é open-source, executável como uma biblioteca Python ou como um serviço independente. É o ponto de partida certo. Você pode conectá-lo a um notebook e ter relatórios básicos de desvio rodando em uma tarde.

O WhyLabs tem um plano gratuito que escala. Boa escolha se você quer um dashboard hospedado sem orçamento para o Arize.

O Arize é a opção paga séria, $1k-$10k/mês para volumes de produção. Vale a pena pagar quando você tem mais de cinco modelos em produção ou qualquer requisito regulatório (serviços financeiros, saúde, qualquer coisa com auditores).

Comece com o Evidently gratuito. Faça o upgrade quando o número de modelos em produção ou a pressão de compliance justificar. Não compre o Arize antes de ter um modelo que precisa de monitoramento.

A questão da fonte única de verdade (onde a maioria dos stacks de DS apodrece)

Labels ruins dentro, modelos ruins fora. Você já sabe disso. O que talvez não tenha internalizado é de onde vem a maioria do lixo nos labels: o sistema operacional de registro. O CRM. A ferramenta de tickets. A configuração de analytics do produto que três PMs diferentes configuraram de três formas diferentes ao longo de duas reorganizações.

Se o seu label "cliente desistiu" vem de um CRM onde o rep de Vendas A marca um negócio como "Perdido - Sem Decisão," o rep B marca a mesma situação como "Perdido - Concorrente," e o rep C simplesmente deleta o negócio, nenhuma quantidade de rastreamento com MLflow vai te salvar. Seu modelo de rotatividade está aprendendo a higiene de dados inconsistente dos seus reps, não o comportamento dos clientes.

Um sistema operacional de registro limpo importa mais do que um repositório de atributos sofisticado. Não é glamoroso. Não te dá uma palestra em conferência. Mas o Data Scientist que passa uma semana corrigindo definições de estágios de pipeline e forçando validação de campos obrigatórios no CRM publica modelos melhores pelos próximos dois anos do que o que troca de repositório de atributos três vezes.

O Rework CRM a $12/usuário/mês oferece estágios de pipeline estruturados, campos personalizados com validação, um log de eventos que você pode transmitir para o seu data warehouse e uma fonte única de verdade para o ciclo de vida do cliente do qual seus modelos de rotatividade e conversão dependem. Qualquer que seja o CRM que você use, o princípio se aplica: a qualidade dos dados upstream decide a qualidade do modelo downstream. Corrija antes de ajustar mais um hiperparâmetro.

Construir versus comprar: a árvore de decisão real

Aqui está a matriz. Encontre a sua linha, construa de acordo. Não pule níveis.

Não pule níveis. Os dois erros de stack mais comuns que vejo, em ordem:

1. A equipe de duas pessoas que comprou Tecton porque alguém assistiu a uma palestra em conferência.
2. A equipe de oito pessoas que ainda roda tudo no laptop de um fundador porque "ainda não precisamos de MLOps."

Ambos são ruins. O primeiro é superinvestimento sem retorno. O segundo é subinvestimento que sangra produtividade e credibilidade toda semana.

A auditoria de stack de 30 dias

Concreto, semana a semana. Execute isso seja qual for a situação, herdada ou construída por você.

Dias 1 a 3: Inventarie o que está realmente em produção

Não o que está no slide de arquitetura. O que está realmente rodando. Abra cada cron, cada DAG do Airflow, cada endpoint do SageMaker, cada notebook agendado. Faça uma planilha. Colunas: ferramenta, responsável, custo mensal, percentual da equipe usando, data do último uso, decisão eliminar-manter-fazer-upgrade.

Você vai encontrar pelo menos três coisas que não sabia que existiam.

Dias 4 a 7: Encontre todos os modelos em produção

Para cada modelo: quem é o responsável, em quais dados treina, quando foi retreinado pela última vez, qual é a métrica de desempenho atual e se alguém notaria se parasse de rodar.

Se ninguém notaria, elimine. Se ninguém é responsável, agora é o seu problema para atribuir.

Dias 8 a 14: Adicione monitoramento ao modelo menos monitorado

Escolha o modelo com maior impacto no negócio e o pior monitoramento. Adicione o Evidently a ele esta semana. Não precisa ser bonito. Um relatório de desvio semanal enviado por e-mail para um canal é suficiente para começar.

Dias 15 a 21: Consolide o rastreamento de experimentos

Escolha uma ferramenta. Migre os experimentos ativos. Diga à equipe para parar de usar as outras. Archive o restante. Isso será politicamente mais difícil do que parece porque a pessoa que configurou a ferramenta que você está eliminando vai levar para o lado pessoal. Faça mesmo assim.

Dias 22 a 30: Documente o stack em um README

Um único README no repositório da equipe. Diagrama de arquitetura (caixas e setas, não uma obra de arte no Visio). Propósito, responsável e login de cada ferramenta. O procedimento de plantão para cada modelo em produção. O próximo Data Scientist contratado deve conseguir ler isso em uma hora e saber o que está herdando.

Depois de 30 dias, você consegue responder em um fôlego: cada modelo em produção, quem é o responsável, quando foi retreinado pela última vez, como está o desvio atual e qual ferramenta você cortaria amanhã. Se não consegue responder isso, a auditoria não está concluída.

Erros comuns

Os maiores, mais ou menos na ordem em que os vejo:

• Comprar ferramentas antes de ter modelos em produção. "Precisamos de um repositório de atributos." Precisam mesmo? Vocês têm atributos? Têm um modelo que os usa? Não compre infraestrutura para um futuro que ainda não construiu.
• Hospedar o MLflow sem orçar tempo de manutenção. É gratuito em dólares. Não é gratuito em horas. Alguém precisa manter a VM atualizada, o banco de dados com backup e a autenticação funcionando. Se esse alguém é você e também precisa publicar modelos, a conta pode favorecer a opção gerenciada.
• Deixar cada DS escolher sua própria ferramenta. "Usamos o que usavam no emprego anterior" é como você acaba com três rastreadores de experimentos, dois repositórios de atributos e um documento de onboarding de 40 páginas.
• Construir uma "plataforma" antes de ter três modelos que a justifiquem. A armadilha da equipe de plataforma de um. Não generalize até ter coisas específicas para generalizar.
• Ignorar o CRM e a camada de dados operacionais porque "não é ML." É a camada que decide se os seus labels são reais. É a fundação do ML, não o vizinho do ML.

Templates que valem a pena construir

Quatro artefatos para manter no repositório da sua equipe:

1. Planilha de auditoria de stack. Ferramenta, custo mensal, responsável, percentual da equipe usando, data do último uso, decisão eliminar-manter-fazer-upgrade.
2. Inventário "o que está realmente em produção". Modelo, responsável, fonte de dados de treinamento, último retreinamento, status de monitoramento, impacto no negócio, procedimento de plantão.
3. Matriz de decisão construir versus comprar. A tabela deste artigo, personalizada para o stack específico da sua equipe.
4. Estrutura de repositório de stack mínimo viável. Um exemplo funcionando de MLflow mais BentoML mais Evidently conectados, para que o próximo Data Scientist contratado possa clonar e publicar um modelo na primeira semana.

A conclusão

A parte mais difícil de um stack de ML não é o ML. É a camada upstream entediante (labels limpos, eventos limpos, uma fonte única de verdade) e a camada downstream entediante (monitoramento que você realmente olha). O meio (qual modelo, qual repositório de atributos, qual framework de disponibilização) recebe mais atenção e importa menos.

As ferramentas importam. A disciplina do stack importa mais. O DS que faz a auditoria de 30 dias, elimina duas ferramentas redundantes e escreve o README é mais valioso do que o que faz benchmark de cinco bibliotecas de gradient boosting.

Se você está contratando para essa função, o template de JD para Data Scientist define as responsabilidades e o critério. Se você já está na função e o seu stack parece o parágrafo de abertura deste guia, comece a auditoria na segunda-feira.

Saiba Mais

• Um Dia na Vida de um Data Scientist
• Seus Primeiros 30/60/90 Dias como Novo Data Scientist
• Movendo Modelos para Produção Sem Quebrá-los
• Métricas de DS: Modelos Publicados, Impacto no Negócio, Degradação
• Template de JD para Data Scientist