Migrar do Vertex AI Feature Store (legado) para o Bigtable

Migrar uma carga de trabalho de gerenciamento de atributos de machine learning do Vertex AI Feature Store (legado) para o Bigtable pode resultar em melhor desempenho e flexibilidade. Este guia apresenta uma visão geral dos conceitos relacionados e do processo de migração.

O Feature Store da Vertex AI (legado) é um ambiente gerenciado que usa o Bigtable na camada de veiculação on-line. Executar sua plataforma de IA ou Feature Store diretamente no Bigtable sem usar a Vertex AI Feature Store (legada) pode resultar em velocidades mais rápidas e custos reduzidos.

Recomendamos um caminho de migração mínimo viável focado na migração de dados das tabelas do Bigtable na Vertex AI Feature Store (legado) para uma instância do Bigtable criada no seu projeto Google Cloud .

Benefícios da migração

A migração para o Bigtable oferece várias vantagens estratégicas e operacionais:

  • Eficiência de custos: você elimina o prêmio de gerenciamento de nós específico do Vertex AI Feature Store (legado), reduzindo os custos de infraestrutura.
  • Controle direto: você tem acesso total aos recursos do Bigtable. O monitoramento do Bigtable expõe muito mais métricas do que a Vertex AI Feature Store (legado). Você também tem mais controle sobre layouts e escalonamento de arquitetura personalizados.
  • Alto desempenho: o Bigtable oferece suporte a cargas de trabalho de alto desempenho e recursos de alto desempenho, como agregação em gravações e pesquisa vetorial.

  • Integração entre produtos: você tem acesso a integrações do Bigtable, como tabelas externas do BigQuery, conectores para Apache Spark, Apache Flink e Kafka Connect e ETL reverso do BigQuery.

  • Captura de dados alterados: é possível ativar os fluxos de alterações para capturar as mudanças na tabela do repositório de recursos do Bigtable à medida que elas acontecem.

Principais conceitos

Esta seção descreve como os principais conceitos do Vertex AI Feature Store (legado) são implementados pelo Bigtable e pelo BigQuery.

Retenção de dados

No Bigtable, você gerencia a retenção de dados com a coleta de lixo. A coleta de lixo é o processo automático e contínuo de remover dados expirados e obsoletos das tabelas do Bigtable. Uma política de coleta de lixo é um conjunto de regras que você cria para informar quando os dados em um recurso específico, definido no Bigtable como um grupo de colunas, não são mais necessários. As políticas de coleta de lixo são definidas com base no carimbo de data/hora associado aos dados ou no número de versões que você quer manter.

A coleta de lixo é um processo em segundo plano assíncrono interno que ocorre durante a compactação. A coleta de lixo acontece em uma programação fixa. Até que sejam excluídos, os dados aparecem nos resultados de leitura, mas é possível filtrar as leituras para excluir esses dados. Para mais informações, consulte Visão geral da coleta de lixo.

Além disso, o armazenamento em níveis do Bigtable pode ser uma solução econômica para lojas de recursos on-line que precisam reter dados históricos para treinamento de modelo ou conformidade regulatória. O armazenamento em camadas gerencia a movimentação de dados acessados com pouca frequência do serviço on-line em armazenamento SSD para uma camada de armazenamento de custo mais baixo.

Desenvolvimento de recursos

No Bigtable, é possível implementar o desenvolvimento de recursos on-line com o SQL do Bigtable e o desenvolvimento de recursos off-line usando DataFrames do BigQuery.

Ao usar o Feature Store da Vertex AI (legado), você trabalha com APIs de desenvolvedor e modelos de dados que são mapeados para fontes de dados preparadas no BigQuery. Em seguida, registre essas fontes de dados e colunas de atributos específicas no registro de atributos. Com um repositório de recursos do Bigtable, você trabalha diretamente com dados nas instâncias do BigQuery e do Bigtable, sem precisar mapear para o modelo de dados do Vertex AI Feature Store (legado).

Desenvolvimento de recursos on-line

Para o desenvolvimento de recursos on-line, o Bigtable oferece várias ferramentas:

Desenvolvimento de recursos off-line

Para o desenvolvimento de recursos off-line, o BigQuery DataFrames fornece uma interface Python com mais de 750 APIs pandas e scikit-learn. Essas APIs são implementadas por meio da conversão de SQL para APIs do BigQuery e do BigQuery ML. A geração de recursos do BigQuery DataFrames permite funções Python integradas e definidas pelo usuário. Ele também fornece sincronização de dados automatizada com o Bigtable para veicular recursos criados em processos em lote e off-line, descritos na próxima seção.

Sincronização de recursos on-line e off-line

Ao usar o Bigtable diretamente para cargas de trabalho de ML, é possível garantir que um valor de atributo off-line seja importado do BigQuery e que o mesmo valor seja reutilizado para treinamento e veiculação, mantendo os caminhos de código sincronizados para gerar atributos entre treinamento e veiculação. As seguintes tecnologias permitem a sincronização de recursos:

  • Sincronização em lote: a ETL reversa do BigQuery para o Bigtable permite exportar os resultados de uma consulta do BigQuery para o Bigtable. Essas consultas são executadas em lote e podem ser programadas diretamente no BigQuery.
  • Sincronização de streaming: as consultas contínuas do BigQuery são instruções SQL que são executadas continuamente e geram linhas em uma tabela do Bigtable.
  • Sincronização dos DataFrames do BigQuery: para capturar recursos off-line desenvolvidos em Python, use um StreamingDataFrame do BigFrames para gerar uma consulta contínua do BigQuery que capture sua lógica do Python para geração de recursos e sincronize os resultados dos dados com o Bigtable.
  • Desenvolvimento de recursos off-line diretamente nos dados do Bigtable: você pode criar recursos off-line no BigQuery com base em dados armazenados no Bigtable usando uma tabela externa do BigQuery. Uma tabela externa espelha a aparência de uma tabela do BigQuery e oferece a maioria das mesmas funcionalidades, como junções, consultas programadas e funções avançadas do SQL do BigQuery, sem a necessidade de mover os dados de volta para o armazenamento do BigQuery. Para evitar afetar o tráfego de serviço de aplicativos, use a computação sem servidor do Data Boost ao ler dados do Bigtable com tabelas externas do BigQuery. Usar o Data Boost é especialmente econômico para consultas ad hoc. Para usar o Data Boost, especifique um perfil de app do Data Boost ao criar a definição de tabela externa. Para mais informações sobre o Data Boost, consulte Visão geral do Data Boost do Bigtable.

Após a migração, você pode continuar usando o Vertex AI Model Monitoring para acompanhar a qualidade dos seus modelos.

A prática de usar o Bigtable e o BigQuery juntos é um padrão comum para criar bancos de dados de análise em tempo real.

Fases da migração

Para garantir a continuidade do serviço, a migração normalmente é executada nas seguintes fases distintas.

Fase 1: preparar a infraestrutura

Antes de iniciar a migração, configure o ambiente de destino:

Fase 2: definir o mapeamento de esquema entre o Vertex AI Feature Store (legado) e o Bigtable

  1. Revise e entenda as práticas recomendadas de design de esquema do Bigtable. Um mapeamento geral da API da Vertex AI Feature Store (legado) para a API do Bigtable é o seguinte:

    Recurso do Vertex AI Feature Store (legado)

    Componente do Bigtable

    FeatureOnlineStore

    Instância Bigtable

    FeatureView

    Grupo de colunas

    featureValues (lote)

    Coluna (uma célula por chave)

    featureValues (contínuo)

    Coluna (várias células por chave [controle de versões])

  2. Depois de definir o mapeamento de esquema, crie uma tabela do Bigtable com um grupo de colunas para cada recurso no repositório de recursos de origem.

Fase 3: extração e sincronização de dados

Nesta fase, você migra os dados usando uma abordagem em camadas com base na frequência de atualização deles.

Sincronização de recursos em tempo real

Para recursos que você está escrevendo com write_feature_values ou chamadas de API equivalentes, comece a gravar os mesmos dados na nova tabela do Bigtable.

  1. Instale a biblioteca de cliente do Python para Bigtable.
  2. Configure seu aplicativo para gravar dados de atributos simultaneamente no Vertex AI Feature Store (legado) e no Bigtable. Para mais informações sobre como gravar dados no Bigtable, consulte Gravações.

Migração de recursos em lote

Em seguida, migre os dados armazenados antes de começar as gravações duplas. Isso envolve mover os dados do Vertex AI Feature Store (legado) para o BigQuery e depois para o Bigtable.

  1. Exporte dados do Feature Store para o BigQuery usando os recursos de exportação do Vertex AI Feature Store (legado), que permitem exportar todos os valores ou snapshots. Isso permite que o BigQuery sirva como o armazenamento off-line da Vertex AI Feature Store (legado).
  2. Migre os dados históricos do BigQuery para o Bigtable usando uma das seguintes opções:
    1. ETL reverso
    2. Conector do Spark para Bigtable
    3. Modelo do Dataflow do BigQuery para o Bigtable

Fase 4: transição do aplicativo e do SDK

A última etapa é a migração da camada de aplicativo.

  1. Depois que a migração for concluída e testada, pare de gravar na Vertex AI Feature Store (legado).

  2. Modifique o aplicativo para usar apenas a biblioteca de cliente Python do Bigtable.

    O exemplo a seguir demonstra o uso do Python para extrair um único recurso do Bigtable.

    from google.cloud import bigtable
from google.cloud.bigtable import row_filters
# Replace 'project_id' and 'instance_id' with your actual IDs.
client = bigtable.Client(project=project_id)
instance = client.instance(instance_id)

#return only the latest feature
row_filter = bigtable.row_filters.CellsColumnLimitFilter(1)

# Replace 'user1' and 'feature0` with your actual row key and column qualifier.

print("Getting a single feature by row key.")
key = "user1".encode()

row = table.read_row(key, row_filter)
cell = row.cells[column_family_id.decode("utf-8")][feature0][0]
print(cell.value.decode("utf-8"))

    Para outro exemplo de como ler e gravar dados usando as APIs de dados e de administrador do Bigtable, consulte o Hello World em Python.

    A biblioteca de cliente Python para Bigtable também permite usar o GoogleSQL para retornar recursos que atendam aos critérios de filtro ou para realizar transformações dos recursos. O exemplo a seguir mostra como chamar uma consulta SQL de forma assíncrona na biblioteca de cliente Python do Bigtable. Para mais informações sobre o GoogleSQL para Bigtable, consulte Outros exemplos de SQL.

    import asyncio
from google.cloud.bigtable.data_async import BigtableDataClient
from google.cloud.bigtable_v2.types import ExecuteQueryRequest

async def run_bigtable_sql_query(project_id, instance_id, table_id):
    """
    Runs a GoogleSQL query on a Bigtable table using the async client.
    """
    client = BigtableDataClient(project_id=project_id)
    instance = client.instance(instance_id)
    table = instance.table(table_id)

    # Example query: Select a specific row and all columns from a column family
    # Replace 'my_table' and 'my_cf' with your actual table and column family IDs.
    # The table name in the SQL must be in the format `dataset.table`,
    # where dataset is the instance ID and table is the table ID (in backticks).
    sql_query = f"SELECT _key, my_cf FROM `{instance_id}`.`{table_id}` WHERE _key = 'user_123'"

    print(f"Executing query: {sql_query}")

    # The client library automatically handles the SQL execution
    try:
        # The query method returns an AsyncPartialRowsIterator
        results_iterator = await table.query(query=sql_query)

        async for row in results_iterator:
            print(f"Row key: {row.row_key.decode('utf-8')}")
            # Iterate through the cells in the row
            for col_family, cells in row.cells.items():
                for cell in cells:
                    print(f"  Column Family: {col_family}, Qualifier: {cell.qualifier.decode('utf-8')}, Value: {cell.value.decode('utf-8')}, Timestamp: {cell.timestamp_micros}")

    except Exception as e:
        print(f"An error occurred: {e}")
    finally:
        await client.close()

if __name__ == "__main__":
    # TODO(developer): Replace with your project, instance, and table IDs
    your_project_id = "your-gcp-project-id"
    your_instance_id = "your-bigtable-instance-id"
    your_table_id = "your-bigtable-table-id"

    # Run the asynchronous function
    asyncio.run(run_bigtable_sql_query(your_project_id, your_instance_id, your_table_id))

  3. Comece a usar as métricas do Bigtable para monitorar a latência e a capacidade de processamento. Para mais informações, consulte Monitoring.

Práticas recomendadas

Depois de migrar da Vertex AI Feature Store (legado) para uma implementação do Bigtable Feature Store, é necessário replicar a lógica interna de pré-processamento e otimização que antes era processada pelo serviço para manter a estabilidade e o desempenho.

Limitação adaptativa do lado do cliente

O back-end do Vertex AI Feature Store (legado) usa um limitador adaptável do lado do cliente para proteger as instâncias do Bigtable subjacentes contra sobrecarga durante picos de tráfego ou quando o back-end de armazenamento está com alta latência ou erros. Recomendamos que você implemente um limitador semelhante no código do aplicativo para registrar respostas de back-end e limitar proativamente as solicitações quando necessário.

Otimização do tamanho do lote e do particionamento de solicitações

Os filtros de linha do Bigtable têm um limite fixo de 20 KB. Solicitar muitos recursos ou IDs de entidade em uma única leitura filtrada pode causar falhas nas solicitações. Para espelhar o comportamento da Vertex AI Feature Store (legado), faça o seguinte:

  • IDs de recursos em blocos: limite o número de IDs de recursos por leitura do Bigtable a aproximadamente 100.
  • Balancear lotes de entidades: para evitar a saturação dos recursos do cliente ou do servidor ao realizar leituras de várias entidades, tome as seguintes precauções:
    • Divida as entidades em pequenos lotes simultâneos, como 10 entidades por lote.
    • Limite o número máximo de solicitações em lote simultâneas, como 10 a 20.

Seleção inteligente de filtros

O cálculo e a aplicação de filtros de coluna no lado do servidor adicionam sobrecarga. Se o aplicativo normalmente solicitar quase todos os recursos em um grupo de colunas, como >99,9%, é mais eficiente ignorar o filtro de coluna e ler a linha inteira, filtrando os resultados no lado do cliente.

Simultaneidade e execução assíncrona

Para minimizar o tempo até o primeiro resultado em cenários de streaming, use padrões assíncronos ou pacotes de linhas de execução para buscar lotes de entidades em paralelo. Isso garante que o aplicativo possa começar a processar os resultados assim que o primeiro lote for retornado, em vez de esperar que uma leitura serial grande seja concluída.

A seguir