O que é Feature Store

Conheça uma das maiores tendências para esse ano em Machine Learning e como ex-funcionários da Uber estão revolucionando a área

Published in

Data Hackers

12 min readJan 24, 2021

Esse post é uma tradução e localização do artigo da Tecton.ai, empresa fundada pelos criadores do Michelangelo da Uber e do Feast da Gojek. Leia o post original aqui e conheça mais sobre a Tecton.

Times de dados estão começando a perceber que o chamado Machine Learning operacional requer resolver problemas de dados que vão muito além da simples criação de data pipelines.

No post anterior da Tecton, Why We Need DevOps for ML Data, nós destacamos alguns dos principais desafios de dados que as equipes enfrentam quando precisam produtizar sistemas de Machine Learning, como:

Acesso ao dado bruto correto
Criação de features a partir desses dados brutos
Combinar features no conjunto de treino
Calcular e servir tais features em produção
Monitoramento das features em produção

Um novo tipo de problema

Aplicações de dados em produção não são algo novo, sejam elas para realizar análises de larga escala ou streaming em real-time. Contudo, o Operational Machine Learning — modelos de ML incorporados a aplicações voltadas para o cliente — é novo para a maioria das equipes. O desafio de deployar modelos de Machine Learning em produção para propósitos operacionais (sistemas de recomendação, detecção a fraude, personalização, etc.) introduz novos requisitos para nossas ferramentas de dados.

Um novo tipo de infra-estrutura específica para Machine Learning está emergindo para tornar isso possível

Cada vez mais os times de Data Science e Data Engineering estão se voltando para ferramentas como Feature Store para gerenciar seus conjuntos de dados e data pipelines necessários para produtizar aplicações de Machine Learning. Esse post descreve os principais componentes de uma solução moderna de Feature Store e como a soma dessas partes atuam como uma força multiplicadora nas organizações, reduzindo duplicidade de esforços de Engenharia de Dados, acelerando o ciclo de vida de projetos de Machine Learning, e possibilitando uma nova forma de colaboração entre times de Ciência de Dados.

O que é uma Feature?

Para relembrar: em Machine Learning, uma feature é o dado utilizado 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 ou não, uma feature útil poderia ser se a transação foi feita em um país no exterior, ou como o valor dessa transação se compara com outras compras do cliente. Quando nos referimos a uma feature, geralmente estamos nos referindo ao conceito desse sinal (exemplo: transação_em_pais_do_exterior), não a um valor específico da feature (exemplo: transação nº 1364 foi em um país estrangeiro).

Entra a Feature Store

“A interface entre modelos e dados”

Nós inicialmente introduzimos Feature Stores em nosso blog falando sobre a plataforma Michelangelo, da Uber. Desde então, Feature Stores tem emergido como componentes necessários para a parte operacional de Machine Learning.

Feature stores facilitam o processo de:

Produtizar novas features sem a necessidade de um grande esforço de engenharia
Automatizar o cálculo e processamento de features, backfills, e geração de logs.
Compartilhamento e reutilização de pipelines de features entre times
Versionamento de features, linha do tempo (lineage) e metadados
Garantir consistência entre dados de treino e do mundo real
Monitoramento da saúde dos pipelines de features em produção

Feature Stores visam resolver os maiores problemas de Data Management encontrados quando construímos e produtizamos aplicações de Machine Learning.

Uma Feature Store é um sistema de dados específico para ML que:

Rodam pipelines que transformam dados brutos em features
Armazenam e gerenciam a feature em si, e
Servem os dados das features de forma consistente, para propósitos de treino e inferência de modelos

Para oferecer suporte ao gerenciamento das features, Feature Stores possuem abstrações de dados que facilitam a construção, deploy, e raciocínio sobre pipelines de features em diferentes ambientes. Por exemplo, elas permitem definir a transformação da feature uma vez, então calculam e servem seus valores consistentemente tanto para ambientes de desenvolvimento (para treinamento em dados históricos) quanto para ambientes em produção (para inferência em valor mais recentes).

Feature Stores atuam como um HUB central de features e metadata ao longo do ciclo de vida de um projeto de ML. Os dados em uma Feature Store são usados para:

Exploração e engenharia de features
Iteração, treino e debugging de modelos
Compartilhamento e descobrimento de features
Servir features em produção para inferência dos modelos
Monitoramento da saúde operacional

Feature Stores economizam no processo de escala em organizações de ML ao permitir a colaboração. Quando uma feature é registrada em uma Feature Store, ela se torna disponível para reutilização imediata em outros modelos através da organização. Isso reduz duplicação de esforços de Data Engineering e permite que novos projetos de Machine Learning sejam criados a partir de uma biblioteca curada com features prontas para uso.

Feature Stores eficientes são desenhadas como sistemas modulares, que podem ser adaptados aos ambientes nos quais elas serão deployadas. Existem cinco principais componentes que fazem parte de uma Feature Store. No restante desse post, nós vamos passar por esses componentes e descrever suas funções no processo de melhorar operações de aplicações de ML.

Os componentes de uma Feature Store

Há cinco principais componentes em uma moderna estrutura de Feature Store: Transformação, Armazenamento, Monitoramento, Serving, e Registro de feature:

Nas próximas seções nós vamos dar um overview do propósito de cada componente:

Serving

Feature Stores fornecem features para modelos. Tais modelos necessitam de uma visão consistente das features entre o treino e o serving. A definição das features usadas para treinar um modelo precisam ser iguais as features que vão ser utilizadas em produção. Quando isso não acontece, o chamado training-serving skew é introduzido, o que pode acarretar em problemas catastróficos de performance do modelo, problema esses difíceis de debuggar.

Uma Feature Store abstrai a lógica e processamento utilizado para gerar a feature, fornecendo aos usuários uma forma fácil e canônica para acessar todas as features da empresa consistentemente em todos os ambientes em que elas são necessárias.

Quando retornam dados offline (por exemplo, para treinamento), os valores das features geralmente são acessados através de SDKs criadas para notebooks. Eles oferecem uma visão exata do estado do mundo para cada exemplo usado para treinar um modelo (também conhecido como “time-travel”).

Quando são utilizadas online, uma Feature Store entrega um vetor único de features de cada vez com os valores mais recentes das features, servidas através de uma API de alta performance, suportada por um banco de dados de baixa latência.

Armazenamento

As features são persistidas nas Feature Stores para que depois possam ser retornadas nas camadas de consumo. Geralmente eles contém uma camada de armazenamento para uso online e offline, para suportar os requerimentos de diferentes sistemas.

As camadas de armazenamento offline geralmente são usadas para armazenar meses ou anos de dados de features, que serão usadas para treinamento. Dados offline de Feature Store geralmente são armazenados em Data Warehouses ou Data Lakes como S3, Google BigQuery, Snowflask, ou Amazon Redshift. Extender um Data Lake ou Data Warehouse já existente para armazenar features offline é preferível para evitar silos de dados.

Já as camadas de armazenamento online são usadas para persistir os valores das features que serão consultadas durante a inferência. Na maior parte das vezes, essas camadas armazenam apenas o valor mais recente das features para cada entidade, modelando o estado atual do mundo. O armazenamento online tem, na maior parte, consistência eventual, e não tem requisitos estritos de consistência para a maioria dos casos de uso em ML. Geralmente eles são implementados em bancos de chave-valor como DynamoDB, Redis, ou Cassandra.

Feature Stores usam modelos de dados baseado em entidades, onde cada valor de feature é associado com uma entidade (por exemplo, um usuário) e um registro de tempo (timestamp). Um modelo baseado em entidade proporciona uma estrutura mínima para suportar padrões de gerenciamento de features, se encaixa natualmente em workflows de feature engineering, e permite um retorno simples das consultas em produção.

Transformação

Aplicações de MLOps requerem processamento de novos dados em features de forma regular, para que modelos possam fazer predições usando uma visão atualizada do mundo. Feature Stores podem tanto gerenciar e orquestrar as transformações de dados que produzem esses valores, assim como ingerir valores produzidos por sistemas externos. As transformações gerenciadas pelas Feature Stores são configuradas, por definição, em um registro comum de features (common feature registry), descrito abaixo.

A maioria dos times iniciando com Feature Stores já possuem pipelines de dados existentes que estão produzindo valores de features. É muito importante que as Feature Stores sejam adotadas gradualmente, e quem tenham excelentes integrações com plataformas de dados existentes, permitindo imediatamente que as equipes operacionalizem pipelines de ETLs existentes para seus projetos de Machine Learning.

É comum que Feature Stores interajam com três tipos principais de Data Transformation:

Um benefício-chave é facilitar o uso de diferentes tipos de features juntas no mesmo modelo.

Modelos precisam acessar os valores recentes das features para inferência. Feature Stores possibilitam isso ao recalcular as features periodicamente. Jobs de transformação são orquestrados para garantir que novos dados são processados e transformados em novos valores de features. Esses jobs são executados em motores (engines) de processamento de dados (como Spark ou Pandas) nos quais as Features Stores estão conectadas.

Desenvolvimento de modelos trazem diferentes necessidades de transformação. Quando iteramos em um modelo, geralmente adicionamos novas features para serem usadas nos datasets de treino que contém dados históricos (por exemplo, todas as compras nos últimos 6 meses). Para suportar essas formas de uso, Feature Stores facilitam a execução dos chamados “backfill jobs”, que geram e persistem valores históricos de uma feature para ser utilizada em treinamento.

O código de transformação é reutilizado entre diferentes ambientes, evitando o problema de “training-serving skew” e tirando das equipes a necessidade de precisarem reescrever os códigos de um ambiente para o próximo.

As Feature Store gerenciam todos os recursos relacionados as features (processamento, armazenamento, serving) de forma holística através do ciclo de vida da feature. Ao automatizar as tarefas repetitivas de engenharia necessárias para produtizar uma feature, elas criam um caminho simples e rápido para a produção. Além disso, elas permitem o gerenciamento de otimizações (como retirar features que não estão sendo usadas por nenhum modelo, ou retirar duplicidades de features entre modelos), que traz uma eficiência significante, especialmente à medida que as equipes aumentam cada vez mais a complexidade do gerenciamento manual de features.

Monitoramento

Quando algo dá errado em um sistema de ML, geralmente é um problema de dados, e Feature Stores estão posicionados de maneira única para detectar esse tipo de problema. Elas podem calcular métricas das features que são armazenadas e servidas, mostrando sua qualidade e o quão correta estão. Feature Stores monitoram essas métricas para oferecer um sinal da saúde geral de uma aplicação de Machine Learning.

Os dados das features podem ser validados com base em um esquema pré-definido pelo usuário, ou outro critério de estrutura. A qualidade dos dados é rastreada ao monitorarmos problemas de drift e training-serving skew. Por exemplo, o dado de uma feature servida para um modelo é comparado aos dados que foram utilizados quando o modelo foi treinado, para detectar inconsistências que podem degradar a performance do modelo.

Quando estamos rodando modelos em produção, também é muito importante monitorar métricas operacionais. Feature stores rastreiam métricas operacionais relacionadas as suas atividades principais, como métricas relacionadas ao feature storage (disponibilidade, capacidade, utilização, desatualização) ou feature serving (throughput, latência, taxas de erros). Há também métricas que descrevem as operações de componentes de sistemas adjacentes, por exemplo, métricas operacionais de processamento de dados externos (taxa de sucesso de jobs, throughput, ou lag e taxa de processamento).

Essas métricas são disponibilizadas pela Feature Store para serem utilizadas em sistemas de monitoramento já existentes. Isso permite que a saúde de aplicações de Machine Learning possam ser monitoradas e gerenciadas com ferramentas de observabilidade já utilizadas em produção.

Além disso, para ter visibilidade sobre quais features são usadas por determinados modelos, as Feature Stores podem automaticamente criar alertas e métricas de saúde em visualizações relevantes para usuários, modelos ou ferramentas específicas.

Não é essencial que todas as Feature Stores implementem tais monitoramento internamente, mas eles devem ao menos providenciar interfaces nas quais sistemas de monitoramento de qualidade de dados possam ser plugados. Diferentes casos de uso de Machine Learning podem ter necessidades diferentes de monitoramento.

Registro

Um componente crítico em todas as Feature Stores é ter um registro centralizado de padrões de definições e metadados de features. O registro age como uma fonte única da verdade para informações sobre uma feature na organização.

O registro é uma interface central para interações de usuários com a Feature Store. As equipes usam o registro como um catalogo para explorar, desenvolver, colaborar, e publicar novas definições dentro e entre os times.

As definições no registro configuram o comportamento do sistema da Feature Store. Jobs automatizados usam o registro para agendar a ingestão dos dados, transformação, e armazenamento. Ele forma a base de quais dados são armazenados na Feature Store e como eles são organizados. APIs usam o registro para entender quais features estão disponíveis, quem tem permissão para acessá-las, e como elas devem ser entregues.

O registro permite que metadados importantes sejam anexados as definições da feature. Isso proporciona uma rota para rastrearmos quem são os danos, quais são as especifícações do projeto ou domínio, além de um caminho fácil para integrar sistemas adjacentes. Isso inclui informações sobre dependências e versões, as quais são para rastreio na linha do tempo da feature (lineage tracking).

E, para ajudar nas questões de debugging, compliance, e processos de auditoria, o registro age como um registro imutável do que está disponível analiticamente, e o que está rodando em produção.

Até agora, nós olhamos para os componentes indispensáveis de uma Feature Store. Na prática, as empresas também possuem necessidades de compliance, governança, e segurança, que requerem capacidades adicionais focadas em empresas. Isso será o tópico de um post futuro.

Como começar a usar

Nós vemos Feature Stores como o coração de fluxos de dados em aplicações modernas de Machine Learning. Eles tem se mostrado como uma infraestrutura crítica para times de Data Science colocarem ML em produção. Nós esperamos que 2021 seja o ano de uma adoção massiva de Feature Stores, a medida que Machine Learning se torna uma vantagem competitiva em empresas de tecnologia.

Há algumas poucas opções para começar a utilizar Feature Store:

Feast é uma excelente opção caso você já possua pipelines para processar suas features, mas precisa de uma ótima camada de armazenamento e serving para ajudar a colocá-las em produção. Feast está apenas disponível para Google Cloud Platform, mas estamos trabalhando duro para fazer com que Feast seja uma solução de Feature Store leve e poderosa para todos os ambientes. Fique ligado!
Tecton é uma feature-store-as-a-service (Feature Store como um serviço). Uma grande diferença entre Feast e Tecton está no fato de Tecton suportar transformações, permitindo que pipelines de features sejam feitos ponto-a-ponto dentro do Tecton. Tecton é um serviço gerenciado e uma ótima escolha de Feature Store caso você precise de SLAs em produção, hospedagem, colaboração avançada, suporte a diferentes tipos de transformação (batch, streaming, e/ou real-time), e/ou necessita de recursos corporativos específicos.

Nós escrevemos esse post para oferecer uma definição comum de Feature Store a medida que elas estão emergindo como um componente primário na stack de MLOps. Nós acreditamos que a indústria está prestes a testemunhar uma explosão de atividades nessa área.

Se você tem alguma crítica, dúvidas ou sugestões, nós adoraríamos falar com você. Basta enviar um email para hello@tecton.ai ou dar um alô na comunidade do Feast. Nós adorarímos ouvir o que tem a dizer!