Impressões da Feature Store — Databricks
Feature Store(FS) pode não resolver todos seus problemas de dados e Machine Learning, mas com certeza será uma peça fundamental nessa jornada. Drift contornado em dias e lineage na ponta da língua! É com isso em mente que nós da VIA escolhemos a Feature Store da Databricks, a queridinha plataforma de dados indicado por 9 em cada 10 profissionais de dados!
Para você desavisado, uma rápida explicação. A Feature Store é um local centralizado para obtenção de features, sejam resultado de uma agregação ou não. Isso permite agilidade e uma forte consistência dos dados de treino até deploy ao longo do ciclo de vida de um modelo, além de outros benefícios que irei comentar ao longo do artigo.
As Feature Tables podem ser agrupadas para que o usuário final tenha um contexto em nível de negócio do que está explorando. Simplificando, imagine, na Feature Table Customer ficará todas, e somente nela, as informações do cliente. Assim como na Feature Table Sales, que haverá apenas de vendas.
E por que isso é útil? Vejamos alguns casos:
1. Cientista de Dados: Redução do tempo procurando features. Queries mais simples.
2. Engenheiro de Dados: Reutilização de um pipeline para vários modelos.
3. ML engineering/Devops: Facilidade em deploy, dados organizados.
Fora esses benefícios diretos, pessoalmente, acredito que duas coisas acontecerão com a adoção da SF: Um, o time de dados terá mais confiança nos dados. Dois, o time errará mais, errará rápido e aprenderá muito. O que terá imenso valor para a VIA.
Com essa breve introdução feita, vejamos o que a Databricks aborda esses problemas. Mas já adianto, é fácil dar os primeiros passos.
Agora engenheiro, vá buscar o CREA e seu python , que iremos criar uma tabela e irei passar os comandos de ‘Delete’ para ficar no seu arsenal. Para isso precisaremos de 3 passos no Create/Write e 1 para o Delete.
from databricks.feature_store import FeatureStoreClient#1. o dado que irá ser inseridodata = spark.sql(“select pk_user,date,sales from db_sales.table”)#2. crie a FS tablefs= FeatureSoreClient()fs.create_table(name='fs_database.fs_table', primary_keys=[pk1','pk2'], df=data, schema= data.schema, #também aceita explícito description= 'descrição ótima e bem pensada')
#3 insira os dados, nesse método você também faz o update’’’
Para update apenas adicione os campos no select e rode o write novamente’’’fs.write_table( name='fs_database.fs_table', df = data, mode = 'merge' #ou overwrite se você quiser sobrescrever os dados)
#4 para deletar tabelasfs.drop_table('fs_database.fs_table')
Para você cientista, também é bem simples dar os primeiros passos. A fim de facilitar um pouco sua vida, proponho a você usar esse código abaixo feito por mim. Agora está um pouco nebuloso, mas entenderá logo menos o porquê disso.
# esse cara permitirá você passar uma lista de features, ao invés de #escrever uma a umaval = {‘table_name’: <str> ,’feature_name_list’: <list> ,’lookup_key’: <str> }
def build_feat_lookups(vals): lookups_list=[] table_name = vals.get(‘table_name’) feature_name_list = vals.get(‘feature_name’) lookup_key = vals.get(‘lookup_key’) for feature_name in feature_name_list: lookups_list.append(
FeatureLookup(table_name=table_name, feature_name=feature_name , lookup_key=lookup_key )) return lookups_list
Para quem já trabalhou com uma ORM da vida, essa etapa pode parecer familiar. Iremos declarar a tabela e a chave para fazer o join por meio do método FeatureLookup, como mostrado a seguir:
from databricks.feature_store import FeatureLookupfeature_lookups_list = [ FeatureLookup( table_name = ‘fs_database.fs_table’, feature_name = ‘feature01’, lookup_key = [‘pk1’,’pk2'], ), FeatureLookup( table_name = ‘fs_database.fs_table’, feature_name = ‘feature02’, lookup_key = [‘pk1’,’pk2'], ), FeatureLookup( table_name = ‘fs_database.fs_table’, feature_name = ‘featureN’, lookup_key = [‘pkn’,’pkn’], ),]with mlflow.start_run(): training_set = fs.create_training_set( df, feature_lookups = feature_lookups, label = ‘coluna_que_o_modelo_vai _predizer’, exclude_columns = [‘coluna_que_é_melhor_ficar_de_fora’]). . .fs.log_model( model, #um modelo que é válido com MLflow flavor.save_model “model”, flavor=mlflow.sklearn, training_set=training_set, registered_model_name=”example_model” )predictions = fs.score_batch( ‘models:/example_model/1’, df_para_fazer_a_scoragem ))
Perceba que a implementação da FeatureLookup tem um design estranho. Por isso a minha sugestão do build_feat_lookup, menos chata que a original.
A interação com mlflow, no entanto, são muito interessantes, elas permitem duas coisas incríveis: um, ter um lineage dos dados via fs.log_model e dois, identificar o drift do modelo via fs.score_batch. Reforçando, é obrigatório o Mlflow.
Outra coisa legal dessa solução, é que de você tem acesso à essa UI de feature table clicando no ícone ou escrevendo no final da sua url #feature-store. Essa página mostra quais modelos estão usando uma feature em particular, o que é incrível em época de LGPD.
imagem: ui da databricks feature table, acesso ao dado e modelo
Debruçado nesses dois pequenos exemplos, percebemos como a FS da Databricks tem o potencial para atingir nossas expectativas e agilizar nossos pipelines de ML. Mais que isso, a FS também precisa de muita organização e planejamento do time. E nisso a VIA é fera.
Com isso, nós do time de Machine Learning Operations vemos que o FS da Databricks não se limita somente ao escopo do Balthasar, mas também abrange em vários aspectos pontos de nossa plataforma de desenvolvimento (Melchior) e também de nossa plataforma de deploy (Casper). Esses nomes são estranhos por agora, mas saiba que eles fazem parte da trajetória de ML dentro da VIA, eles são o MAGI.
E pra você que ficou com curiosidade, fique ligado que nosso próximo post será sobre exatamente isso! A MAGI!
Obrigado Pedro Carvalho (@p.hcarvalho) que revisou esse texto para mim e para você que leu até aqui! Até logo com grandes novidades.
