O que é um Repositório de Features?

Este blog foi originalmente publicado por Tecton.ai, que foi adquirida pela Databricks em agosto de 2025. Desde a aquisição, a Databricks Feature Store lançou as APIs de Recursos Declarativos, uma abstração poderosa para experimentação de recursos que automatiza a criação de pipelines de recursos gerenciados para dados em lote e streaming.

Atualizado: 15 de maio de 2025

Sobre os autores:
Mike Del Balso, CEO e Co-Fundador da Tecton
Willem Pienaar, Criador do Feast

As equipes de dados estão começando a perceber que o aprendizado de máquina operacional exige a solução de problemas de dados que vão muito além da criação de pipelines de dados.

Em uma postagem anterior, Por que precisamos de DevOps para Dados de ML, destacamos alguns dos principais desafios de dados que as equipes enfrentam ao colocar sistemas de ML em produção.

• Acessar os dados brutos corretos
• Construir recursos a partir de dados brutos
• Combinar recursos em dados de treinamento
• Calcular e servir recursos em produção
• Monitorar recursos em produção

Sistemas de dados de produção, seja para análises em larga escala ou streaming em tempo real, não são novidade. No entanto, o aprendizado de máquina operacional — inteligência impulsionada por ML integrada a aplicativos voltados para o cliente — é novo para a maioria das equipes. O desafio de implantar o aprendizado de máquina em produção para fins operacionais (por exemplo, sistemas de recomendação, detecção de fraude, personalização, etc.) introduz novos requisitos para nossas ferramentas de dados.

Um novo tipo de infraestrutura de dados específica para ML está surgindo para tornar isso possível.

Cada vez mais, as equipes de Ciência de Dados e Engenharia de Dados estão recorrendo a feature stores para gerenciar os conjuntos de dados e pipelines de dados necessários para colocar suas aplicações de ML em produção. Esta postagem descreve os principais componentes de um feature store moderno e como a soma dessas partes atua como um multiplicador de força nas organizações, reduzindo a duplicação de esforços de engenharia de dados, acelerando o ciclo de vida do aprendizado de máquina e desbloqueando um novo tipo de colaboração entre as equipes de ciência de dados.

Revisão rápida: em ML, um recurso (feature) são dados usados como um sinal de entrada para um modelo preditivo.

Por exemplo, se uma empresa de cartão de crédito está tentando prever se uma transação é fraudulenta, um recurso útil pode ser se a transação está ocorrendo em um país estrangeiro, ou como o tamanho desta transação se compara à transação típica do cliente. Quando nos referimos a um recurso, geralmente estamos nos referindo ao conceito desse sinal (por exemplo, “transaction_in_foreign_country”), não a um valor específico do recurso (por exemplo, não “a transação #1364 foi em um país estrangeiro”).

Qual é o Propósito Principal de um Feature Store

“A interface entre modelos e dados”

Introduzimos os feature stores pela primeira vez em nossa postagem de blog descrevendo a plataforma Michelangelo da Uber. Desde então, os feature stores surgiram como um componente necessário da pilha de aprendizado de máquina operacional.

Os benefícios do feature store incluem:

1. Colocar novos recursos em produção sem suporte extensivo de engenharia
2. Automatizar o cálculo de recursos, preenchimentos retroativos (backfills) e registro (logging)
3. Compartilhar e reutilizar pipelines de recursos entre equipes
4. Rastrear versões de recursos, linhagem e metadados
5. Alcançar consistência entre dados de treinamento e de serviço
6. Monitorar a saúde dos pipelines de recursos em produção

Os feature stores visam resolver todo o conjunto de problemas de gerenciamento de dados encontrados ao construir e operar aplicações de ML operacionais.

Um feature store é um sistema de dados específico para ML que:

• Executa pipelines de dados que transformam dados brutos em valores de recursos
• Armazena e gerencia os próprios dados de recursos, e
• Serve dados de recursos de forma consistente para fins de treinamento e inferência

Para suportar o gerenciamento simples de recursos, os feature stores fornecem abstrações de dados que facilitam a construção, implantação e raciocínio sobre pipelines de recursos em diferentes ambientes. Por exemplo, eles facilitam a definição de uma transformação de recurso uma única vez, para então calcular e servir seus valores de forma consistente tanto no ambiente de desenvolvimento (para treinamento em valores históricos) quanto no ambiente de produção (para inferência com novos valores de recursos).

Os feature stores atuam como um hub central para dados e metadados de recursos ao longo do ciclo de vida de um projeto de ML. Os dados em um feature store são usados para:

• Exploração e engenharia de recursos
• Iteração, treinamento e depuração de modelos
• Descoberta e compartilhamento de recursos
• Serviço de produção para um modelo para inferência
• Monitoramento de saúde operacional

Os feature stores trazem economias de escala para as organizações de ML, permitindo a colaboração. Quando um recurso é registrado em um feature store, ele se torna disponível para reutilização imediata por outros modelos em toda a organização. Isso reduz a duplicação de esforços de engenharia de dados e permite que novos projetos de ML iniciem com uma biblioteca de recursos curados e prontos para produção.

Feature stores eficazes são projetados para serem sistemas modulares que podem ser adaptados ao ambiente em que são implantados. Existem cinco componentes primários que tipicamente compõem um feature store. No restante desta postagem, abordaremos esses componentes e descreveremos seu papel no suporte a aplicações de ML operacionais.

Quais são os Componentes de um Feature Store

Existem 5 componentes principais de um feature store moderno: Transformação, Armazenamento, Serviço, Monitoramento e Registro de Recursos.

Nas seções seguintes, faremos uma visão geral do propósito e das capacidades típicas de cada uma dessas seções.

Servindo Dados de Recursos

Feature stores fornecem dados de recursos para modelos. Esses modelos exigem uma visão consistente dos recursos entre treinamento e serviço. As definições dos recursos usados para treinar um modelo devem corresponder exatamente aos recursos fornecidos no serviço online. Quando não correspondem, ocorre o desvio entre treinamento e serviço (training-serving skew), o que pode causar problemas catastróficos e difíceis de depurar no desempenho do modelo.

Feature stores abstraem a lógica e o processamento usados para gerar um recurso, oferecendo aos usuários uma maneira fácil e canônica de acessar todos os recursos de uma empresa de forma consistente em todos os ambientes em que são necessários.

Ao recuperar dados offline (por exemplo, para treinamento), os valores dos recursos são comumente acessados por meio de SDKs de feature store compatíveis com notebooks. Eles fornecem visões corretas do estado do mundo em um determinado ponto no tempo para cada exemplo usado para treinar um modelo (também conhecido como “viagem no tempo”).

Para serviço online, um feature store entrega um único vetor de recursos por vez, composto pelos valores de recursos mais recentes. As respostas são servidas por meio de uma API de alto desempenho, apoiada por um banco de dados de baixa latência.

Armazenamento de Dados para Machine Learning

Feature stores persistem dados de recursos para suportar a recuperação através de camadas de serviço de recursos. Eles geralmente contêm uma camada de armazenamento online e offline para suportar os requisitos de diferentes sistemas de serviço de recursos.

Camadas de armazenamento offline são tipicamente usadas para armazenar dados de recursos de meses ou anos para fins de treinamento. Os dados de feature store offline são frequentemente armazenados em data warehouses ou data lakes como S3, BigQuery, Snowflake, Redshift. Estender um data lake ou data warehouse existente para armazenamento de recursos offline é geralmente preferível para evitar silos de dados.

Camadas de armazenamento online são usadas para persistir valores de recursos para consulta de baixa latência durante a inferência. Eles geralmente armazenam apenas os valores de recursos mais recentes para cada entidade, modelando essencialmente o estado atual do mundo. Feature stores online são geralmente eventualmente consistentes e não possuem requisitos de consistência estritos para a maioria dos casos de uso de ML. Eles são geralmente implementados com armazenamentos de chave-valor como DynamoDB, Redis ou Cassandra.

Feature stores usam um modelo de dados baseado em entidade onde cada valor de recurso é associado a uma entidade (por exemplo, um usuário) e um carimbo de data/hora. Um modelo de dados baseado em entidade fornece uma estrutura mínima para suportar o gerenciamento padronizado de recursos, se encaixa naturalmente com fluxos de trabalho comuns de engenharia de recursos e permite consultas de recuperação simples em produção.

Transformação de Dados em Machine Learning

Aplicações de ML operacional exigem o processamento regular de novos dados em valores de recursos para que os modelos possam fazer previsões usando uma visão atualizada do mundo. Feature stores gerenciam e orquestram transformações de dados que produzem esses valores, além de ingerir valores produzidos por sistemas externos. As transformações gerenciadas por feature stores são configuradas por definições em um registro de recursos comum (descrito abaixo).

Feature stores geralmente interagem com três tipos principais de transformações de dados:

Um benefício chave é facilitar o uso de diferentes tipos de recursos juntos nos mesmos modelos.

Modelos precisam de acesso a valores de recursos atualizados para inferência. Feature stores conseguem isso recomputando recursos regularmente de forma contínua. Trabalhos de transformação são orquestrados para garantir que novos dados sejam processados e transformados em novos valores de recursos atualizados. Esses trabalhos são executados em motores de processamento de dados (por exemplo, Spark ou Pandas) aos quais o feature store está conectado.

O desenvolvimento de modelos introduz diferentes requisitos de transformação. Ao iterar em um modelo, novos recursos são frequentemente projetados para serem usados em conjuntos de dados de treinamento que correspondem a eventos históricos (por exemplo, todas as compras nos últimos 6 meses). Para suportar esses casos de uso, feature stores facilitam a execução de “trabalhos de preenchimento retroativo” (backfill jobs) que geram e persistem valores históricos de um recurso para treinamento. Alguns feature stores preenchem automaticamente recursos recém-registrados para intervalos de tempo pré-configurados para conjuntos de dados de treinamento registrados.

O código de transformação é reutilizado entre ambientes, prevenindo o desvio entre treinamento e serviço e liberando as equipes de ter que reescrever o código de um ambiente para o próximo.

Monitoramento de Machine Learning

Quando algo dá errado em um sistema de ML, geralmente é um problema de dados. Feature stores estão em uma posição única para detectar e expor tais problemas. Eles podem calcular métricas sobre os recursos que armazenam e servem, descrevendo correção e qualidade. Feature stores monitoram essas métricas para fornecer um sinal da saúde geral de uma aplicação de ML.

Os dados de recursos podem ser validados com base em esquemas definidos pelo usuário ou outros critérios estruturais. A qualidade dos dados é rastreada monitorando desvios (drift) e desvio entre treinamento e serviço (training-serving skew). Por exemplo, os dados de recursos servidos aos modelos são comparados aos dados nos quais o modelo foi treinado para detectar inconsistências que poderiam degradar o desempenho do modelo.

Ao executar sistemas de produção, também é importante monitorar métricas operacionais. Feature stores rastreiam métricas operacionais relacionadas à funcionalidade central — por exemplo, métricas relacionadas ao armazenamento de recursos (disponibilidade, capacidade, utilização, obsolescência) ou ao serviço de recursos (vazão, latência, taxas de erro). Outras métricas descrevem as operações de componentes importantes do sistema adjacente, como métricas operacionais para motores de processamento de dados externos (por exemplo, taxa de sucesso de trabalho, vazão, atraso e taxa de processamento).

Feature stores disponibilizam essas métricas para a infraestrutura de monitoramento existente. Isso permite que a saúde da aplicação de ML seja monitorada e gerenciada com as ferramentas de observabilidade existentes na pilha de produção.

Tendo visibilidade sobre quais recursos são usados por quais modelos, feature stores podem agregar automaticamente alertas e métricas de saúde em visualizações relevantes para usuários, modelos ou consumidores específicos.

Registro de Modelos de Machine Learning

Um componente crítico em todos os feature stores é um registro centralizado de definições de features padronizadas e metadados. O registro atua como uma única fonte de verdade para informações sobre uma feature em uma organização.

O registro é uma interface central para interações do usuário com o feature store. As equipes usam o registro como um catálogo comum para explorar, desenvolver, colaborar e publicar novas definições dentro e entre as equipes.

As definições no registro configuram o comportamento do sistema do feature store. Trabalhos automatizados usam o registro para agendar e configurar a ingestão, transformação e armazenamento de dados. Ele forma a base de quais dados são armazenados no feature store e como eles são organizados. APIs de serviço usam o registro para uma compreensão consistente de quais valores de feature devem estar disponíveis, quem deve ter acesso a eles e como eles devem ser servidos.

O registro permite que metadados importantes sejam anexados às definições de feature. Isso fornece um caminho para rastrear a propriedade, informações específicas do projeto ou domínio, e uma maneira de integrar facilmente com sistemas adjacentes. Isso inclui informações sobre dependências e versões que são usadas para rastreamento de linhagem.

Para auxiliar nos fluxos de trabalho comuns de depuração, conformidade e auditoria, o registro atua como um registro imutável do que está disponível analiticamente e do que está realmente em produção.

Até agora, examinamos os componentes mínimos essenciais de um feature store. Na prática, as empresas frequentemente têm necessidades como conformidade, governança e segurança que exigem capacidades adicionais focadas em empresas. Esse será o tema de uma futura postagem de blog.

Começando com Feature Stores

Vemos os feature stores como o coração do fluxo de dados em aplicações modernas de ML. Eles estão rapidamente se mostrando uma infraestrutura crítica para equipes de ciência de dados que colocam ML em produção. Esperamos que o número de organizações que usam feature stores quadruplique até 2028

Existem algumas opções para começar com feature stores:

• Feast é uma ótima opção se você já possui pipelines de transformação para calcular suas features, mas precisa de uma excelente camada de armazenamento e serviço para ajudá-lo a usá-las em produção. Feast é apenas para GCP hoje, mas estamos trabalhando duro para tornar o Feast disponível como um feature store leve para todos os ambientes. Fique ligado.
• Tecton é uma plataforma de features como serviço. Uma grande diferença entre Feast e Tecton é que o Tecton suporta transformações, então os pipelines de features podem ser gerenciados de ponta a ponta dentro do Tecton. Tecton é uma oferta gerenciada e uma ótima escolha de feature store se você precisa de SLAs de produção, hospedagem, colaboração avançada, transformações gerenciadas (batch/streaming/tempo real) e/ou capacidades empresariais.

Escrevemos esta postagem de blog para fornecer uma definição comum de feature stores à medida que eles emergem como um componente primário da pilha operacional de ML. Acreditamos que a indústria está prestes a ver uma explosão de atividade neste espaço.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original