As práticas recomendadas a seguir ajudarão você a planejar e usar o Feature Store da Vertex AI em vários cenários. Este guia não deve ser completo...
Recursos de modelagem que descrevem várias entidades
Alguns recursos podem ser aplicados a vários tipos de entidade. Por exemplo, você pode ter um valor calculado que registra cliques por produto por usuário. Esse recurso descreve os pares produto-usuário.
A prática recomendada,
neste caso, é criar um tipo de entidade separado para agrupar recursos compartilhados. É possível criar um tipo de entidade, como product-user, para conter
os recursos compartilhados.
Para IDs de entidades específicos, concatene os IDs de entidades individuais, como os IDs de um produto e usuário. O único requisito é que os IDs sejam strings. Esses tipos de entidade combinados são chamados de tipos compostos de entidade.
Para mais informações, consulte Como criar um tipo de entidade.
Usar políticas do IAM para controlar o acesso entre várias equipes
Use papéis e políticas do IAM para definir diferentes níveis de acesso a diferentes grupos de usuários. Por exemplo, pesquisadores de ML, cientistas de dados, DevOps e engenheiros de confiabilidade de sites exigem acesso ao mesmo featurestore, mas o nível de acesso deles pode ser diferente. Por exemplo, os usuários de DevOps podem exigir permissões para gerenciar um featurestore, mas não exigem acesso ao conteúdo do featurestore.
Também é possível restringir o acesso a um tipo específico de featurestore ou entidade usando políticas do IAM no nível do recurso.
Por exemplo, imagine que sua organização inclua os seguintes perfis. Cada perfil requer um nível de acesso diferente, e cada um deles recebe um papel do IAM predefinido diferente. Também é possível criar e usar seus próprios papéis personalizados.
| Perfil | Descrição | Papel predefinido |
|---|---|---|
| Pesquisador de ML ou analista de negócios | Usuários que só veem dados de tipos específicos de entidade | roles/aiplatform.featurestoreDataViewer (pode ser concedido no nível do projeto ou do recurso) |
| Cientistas ou engenheiros de dados | Usuários que trabalham com recursos de tipos de entidade específicos. Nos recursos próprios, eles podem delegar acesso a outras principais. | roles/aiplatform.entityTypeOwner (pode ser concedido no nível do projeto ou do recurso) |
| TI ou DevOps | Usuários que precisam manter e ajustar o desempenho de featurestores específicos, mas não precisam de acesso aos dados. | roles/aiplatform.featurestoreInstanceCreator (pode ser
concedido no nível do projeto ou do recurso) |
| Pipeline de importação de dados automatizada | Aplicativos que gravam dados em tipos de entidade específicos. | roles/aiplatform.featurestoreDataWriter (pode ser concedido no nível do projeto ou do recurso) |
| Engenheiro de confiabilidade do site | Usuários que gerenciam determinados featurestores ou todos os featurestores em um projeto | roles/aiplatform.featurestoreAdmin (pode ser concedido no nível do projeto ou do recurso) |
| Global (qualquer usuário da Vertex AI Feature Store) | Permitir que os usuários visualizem e pesquisem recursos existentes. Se encontrarem um recurso com que querem trabalhar, eles poderão solicitar acesso aos proprietários. Para usuários do console do Google Cloud, esse papel também é necessário a fim de visualizar a página de destino da Vertex AI Feature Store (legada), a página de jobs de importação e a página de jobs de disponibilização em lote. |
Conceda o papel roles/aiplatform.featurestoreResourceViewer para envolvidos no projeto. |
Monitorar e ajustar recursos de acordo com a otimização da importação em lote
Os jobs de importação em lote exigem que os workers processem e gravem dados, o que pode aumentar a utilização da CPU do featurestore e afetar o desempenho da disponibilização on-line. Se a preservação do desempenho de exibição on-line for uma prioridade, comece com um worker para cada 10 nós de exibição on-line. Durante a importação, monitore o uso da CPU pelo armazenamento on-line. Se o uso da CPU for inferior ao esperado, aumente o número de workers para jobs de importação em lote futuros a fim de aumentar a capacidade. Se o uso da CPU for superior ao esperado, aumente o número de nós de disponibilização on-line para aumentar a capacidade da CPU ou diminua a contagem de workers de importação em lote, porque ambos podem reduzir o uso da CPU.
Se você aumentar o número de nós de exibição on-line, observe que o Feature Store na Vertex AI leva cerca de 15 minutos para alcançar o desempenho ideal após a atualização.
Para mais informações, consulte Atualizar um featurestore e Valores de atributos de importação em lote.
Para mais informações sobre o monitoramento de featurestores, consulte Métricas do Cloud Monitoring.
Usar o campo disableOnlineServing ao preencher dados históricos
O preenchimento é o processo de importação de valores de atributos históricos e não afeta os valores de atributo mais recentes. Nesse caso, é possível desativar a exibição on-line, o que ignora todas as alterações na loja on-line. Para mais informações, consulte os dados históricos de preenchimento.
Usar o escalonamento automático para reduzir custos durante flutuações de carga
Se você usar o Feature Store da Vertex AI de maneira extensiva e encontrar flutuações de carga frequentes nos seus padrões de tráfego, use o escalonamento automático para otimizar os custos. O escalonamento automático permite que a Vertex AI Feature Store analise os padrões de tráfego e ajuste automaticamente o número de nós para cima ou para baixo, dependendo da utilização da CPU, em vez de manter uma alta contagem de nós. Essa opção funciona bem para padrões de tráfego que encontram crescimento e queda graduais.
Para mais informações sobre escalonamento automático, consulte Opções de escalonamento.
Testar o desempenho dos nós de exibição on-line para exibição em tempo real
Para garantir o desempenho do seu featurestore durante a exibição on-line em tempo real, teste o desempenho dos nós de exibição on-line. É possível executar esses testes com base em vários parâmetros de comparativo de mercado, como QPS, latência e API. Siga estas diretrizes para testar o desempenho dos nós de exibição on-line:
Execute todos os clientes de teste da mesma região, de preferência no Compute Engine ou no Google Kubernetes Engine: isso evita discrepâncias devido à latência da rede resultante de saltos entre regiões.
Usar a API gRPC no SDK: a API gRPC tem desempenho melhor que a API REST. Se você precisar usar a API REST, ative a opção "sinal de atividade HTTP" para reutilizar as conexões HTTP. Caso contrário, cada solicitação resultará na criação de uma nova conexão HTTP, o que aumentará a latência.
Executar testes de duração mais longa: execute testes com uma duração maior (15 minutos ou mais) e um mínimo de 5 QPS para calcular métricas mais precisas.
Adicione um período de "aquecimento": se você começar a testar após um período de inatividade, pode observar uma alta latência enquanto as conexões são restabelecidas. Para contabilizar o período inicial de alta latência, você pode designar esse período como um "período de aquecimento", quando as leituras iniciais de dados serão ignoradas. Como alternativa, você pode enviar uma taxa de tráfego artificial baixa, mas consistente, para o featurestore, para manter a conexão ativa.
Se necessário, ative o escalonamento automático: se você prevê um crescimento gradual e um declínio no seu tráfego on-line, ative o escalonamento automático. Se você escolher o escalonamento automático, a Vertex AI vai mudar automaticamente o número de nós de exibição on-line com base no uso da CPU.
Para saber mais sobre a exibição on-line, consulte Exibição on-line. Para saber mais sobre os nós de exibição on-line, consulte Nós de exibição on-line.
Especifique um horário de início para otimizar os custos de armazenamento off-line durante a exibição em lote e a exportação em lote
Para otimizar os custos de armazenamento off-line durante a exibição em lote e a exportação em lote, especifique um startTime na solicitação batchReadFeatureValues ou exportFeatureValues. A solicitação executa uma consulta em um subconjunto de dados do recurso disponíveis, com base no startTime especificado. Caso contrário, a solicitação consulta todo o volume disponível de dados de recurso, resultando em altos custos de uso do armazenamento off-line.