Migrer de Vertex AI Feature Store (ancien) vers Bigtable

La migration d'une charge de travail de gestion des caractéristiques de machine learning depuis Vertex AI Feature Store (ancien) vers Bigtable peut améliorer les performances et la flexibilité. Ce guide présente les concepts associés et le processus de migration.

Vertex AI Feature Store (ancien) est un environnement géré qui utilise Bigtable pour sa couche de diffusion en ligne. Exécuter votre plate-forme d'IA ou votre feature store directement sur Bigtable sans utiliser Vertex AI Feature Store (ancien) peut entraîner des vitesses plus rapides et des coûts réduits.

Nous vous recommandons de suivre un chemin de migration viable minimal qui consiste à migrer les données des tables Bigtable sous-jacentes dans Vertex AI Feature Store (ancien) vers une instance Bigtable que vous créez dans votre projet Google Cloud .

Avantages de la migration

La migration vers Bigtable offre plusieurs avantages stratégiques et opérationnels :

  • Rentabilité : vous éliminez les frais supplémentaires liés à la gestion des nœuds spécifiques à Vertex AI Feature Store (ancien), ce qui réduit souvent les coûts d'infrastructure.
  • Contrôle direct : vous bénéficiez d'un accès complet aux fonctionnalités de Bigtable. La surveillance Bigtable expose beaucoup plus de métriques que Vertex AI Feature Store (ancien). Vous avez également plus de contrôle sur les mises en page et le scaling de l'architecture personnalisée.
  • Hautes performances : Bigtable est compatible avec les charges de travail hautes performances et les fonctionnalités hautes performances telles que l'agrégation sur les écritures et la recherche vectorielle.

  • Intégration interproduit : vous avez accès aux intégrations Bigtable telles que les tables externes BigQuery, les connecteurs pour Apache Spark, Apache Flink et Kafka Connect, ainsi que l'ETL inversé depuis BigQuery.

  • Capture de données modifiées : vous pouvez activer les flux de modifications pour capturer les modifications apportées à votre table Bigtable du feature store au fur et à mesure qu'elles se produisent.

Concepts clés

Cette section décrit comment les concepts de base de Vertex AI Feature Store (ancien) sont implémentés par Bigtable et BigQuery.

Conservation des données

Dans Bigtable, vous gérez la conservation des données avec la récupération de mémoire. La récupération de mémoire est un processus automatique et continu qui permet de supprimer les données expirées et obsolètes des tables Bigtable. Une stratégie de récupération de mémoire est un ensemble de règles, créées par vos soins, qui indiquent quand les données d'une fonctionnalité spécifique, définie dans Bigtable comme une famille de colonnes, ne sont plus nécessaires. Les règles de récupération de mémoire sont définies en fonction du code temporel associé aux données ou du nombre de versions que vous souhaitez conserver.

La récupération de mémoire est un processus en arrière-plan, asynchrone et intégré qui a lieu pendant la compression. La récupération de mémoire s'effectue selon un calendrier fixe. Les données apparaissent dans les résultats de lecture jusqu'à leur suppression, mais vous pouvez filtrer vos lectures pour les exclure. Pour en savoir plus, consultez Présentation de la récupération de mémoire.

De plus, le stockage hiérarchisé Bigtable peut être une solution économique pour les magasins de caractéristiques en ligne qui doivent conserver des données historiques pour l'entraînement des modèles ou la conformité réglementaire. Le stockage hiérarchisé gère le déplacement des données rarement consultées depuis le service en ligne sur le stockage SSD vers un niveau de stockage moins coûteux.

Développement de fonctionnalités

Dans Bigtable, vous pouvez implémenter le développement de caractéristiques en ligne avec Bigtable SQL, et le développement de caractéristiques hors connexion avec les DataFrames BigQuery.

Lorsque vous utilisez Vertex AI Feature Store (ancien), vous travaillez avec des API de développeur et des modèles de données qui correspondent aux sources de données sous-jacentes préparées dans BigQuery. Vous enregistrez ensuite ces sources de données et les colonnes de caractéristiques spécifiques dans le registre de caractéristiques. Avec un feature store Bigtable, vous travaillez directement avec les données des instances BigQuery et Bigtable sous-jacentes, sans avoir besoin de les mapper au modèle de données Vertex AI Feature Store (hérité).

Développement de fonctionnalités en ligne

Pour le développement de caractéristiques en ligne, Bigtable propose plusieurs outils :

  • Bibliothèque cliente Python : utilisez la bibliothèque cliente Python pour Bigtable afin de travailler directement avec les données dans Bigtable.
  • GoogleSQL : utilisez GoogleSQL pour lire et transformer les données dans Bigtable. Vous pouvez exécuter des requêtes SQL directement dans la console Bigtable ou à partir de la bibliothèque cliente Python.
  • Vues matérialisées continues : pour créer des fonctionnalités quasi en temps réel qui nécessitent des transformations et des agrégations récurrentes, utilisez les vues matérialisées continues de Bigtable pour exécuter de manière incrémentielle une requête SQL sur les données à mesure qu'elles arrivent dans Bigtable.

Développement de fonctionnalités hors connexion

Pour le développement de caractéristiques hors connexion, BigQuery DataFrames fournit une interface Python avec plus de 750 API pandas et scikit-learn. Ces API sont mises en œuvre par le biais d'une conversion SQL vers les API BigQuery et BigQuery ML. La génération de caractéristiques BigQuery DataFrames permet d'utiliser des fonctions Python intégrées et définies par l'utilisateur. Il fournit également une synchronisation automatique des données vers Bigtable pour diffuser les caractéristiques créées dans les processus par lot et hors connexion, décrits dans la section suivante.

Synchronisation des fonctionnalités en ligne et hors connexion

Lorsque vous utilisez Bigtable directement pour les charges de travail de ML, vous pouvez vous assurer qu'une valeur de caractéristique hors connexion est importée depuis BigQuery et que cette même valeur est réutilisée à la fois pour l'entraînement et la diffusion. Cela permet de synchroniser les chemins de code pour générer des caractéristiques entre l'entraînement et la diffusion. Les technologies suivantes permettent la synchronisation des fonctionnalités :

  • Synchronisation par lot : l'opération ETL inversée de BigQuery vers Bigtable permet d'exporter les résultats d'une requête BigQuery vers Bigtable. Ces requêtes sont exécutées par lots et peuvent être planifiées directement depuis BigQuery.
  • Synchronisation en flux continu : les requêtes continues BigQuery sont des instructions SQL qui s'exécutent en continu et génèrent des lignes dans une table Bigtable.
  • Synchronisation à partir de BigQuery DataFrames : pour capturer les caractéristiques hors connexion développées en Python, vous pouvez utiliser un StreamingDataFrame BigFrames afin de générer une requête continue BigQuery qui capture votre logique Python pour la génération de caractéristiques et synchronise les résultats des données avec Bigtable.
  • Développement de caractéristiques hors connexion directement sur les données Bigtable : vous pouvez créer des caractéristiques hors connexion dans BigQuery à partir des données stockées dans Bigtable à l'aide d'une table externe BigQuery. Une table externe ressemble à une table BigQuery et offre la plupart des mêmes fonctionnalités, telles que les jointures, les requêtes planifiées et les fonctions SQL BigQuery avancées, sans avoir à déplacer les données dans le stockage BigQuery. Pour éviter d'impacter le trafic de diffusion de votre application, vous pouvez utiliser le service de calcul sans serveur Data Boost lorsque vous lisez des données Bigtable avec des tables externes BigQuery. L'utilisation de Data Boost est particulièrement rentable pour les requêtes ad hoc. Pour utiliser Data Boost, spécifiez un profil d'application Data Boost lorsque vous créez la définition de table externe. Pour en savoir plus sur Data Boost, consultez la présentation de Bigtable Data Boost.

Après la migration, vous pouvez continuer à utiliser Vertex AI Model Monitoring pour suivre la qualité de vos modèles.

L'utilisation conjointe de Bigtable et BigQuery est une pratique courante pour créer des bases de données d'analyse en temps réel.

Phases de migration

Pour assurer la continuité du service, la migration est généralement exécutée en plusieurs phases distinctes.

Phase 1 : Préparer l'infrastructure

Avant de commencer la migration, configurez l'environnement de destination :

Étape 2 : Définissez le mappage de votre schéma entre Vertex AI Feature Store (ancien) et Bigtable

  1. Passez en revue et comprenez les bonnes pratiques de conception des schémas Bigtable. Voici un mappage général de l'API Vertex AI Feature Store (ancien) à l'API Bigtable :

    Ressource Vertex AI Feature Store (ancien)

    Composant Bigtable

    FeatureOnlineStore

    Instance Bigtable

    FeatureView

    Famille de colonnes

    featureValues (lot)

    Colonne (une seule cellule par clé)

    featureValues (continu)

    Colonne (plusieurs cellules par clé [gestion des versions])

  2. Une fois que vous avez défini votre mappage de schéma, créez une table Bigtable qui comporte une famille de colonnes pour chaque caractéristique du Feature Store source.

Phase 3 : Extraction et synchronisation des données

Dans cette phase, vous migrez les données à l'aide d'une approche par niveaux basée sur la fréquence de mise à jour des données.

Synchronisation des fonctionnalités en temps réel

Pour les fonctionnalités que vous écrivez avec write_feature_values ou des appels d'API équivalents, commencez à écrire les mêmes données dans la nouvelle table Bigtable.

  1. Installez la bibliothèque cliente Python pour Bigtable.
  2. Configurez votre application pour qu'elle écrive simultanément des données de caractéristiques dans Vertex AI Feature Store (ancien) et Bigtable. Pour en savoir plus sur l'écriture de données dans Bigtable, consultez Écritures.

Migration des caractéristiques par lot

Ensuite, migrez les données qui ont été stockées avant que vous ne commenciez les doubles écritures. Cela implique de déplacer les données de Vertex AI Feature Store (ancien) vers BigQuery, puis vers Bigtable.

  1. Exportez les données du feature store vers BigQuery à l'aide des fonctionnalités d'exportation de Vertex AI Feature Store (ancien), qui vous permettent d'exporter toutes les valeurs ou tous les instantanés. Cela permet à BigQuery de servir de magasin hors connexion Vertex AI Feature Store (ancien).
  2. Migrez les données historiques de BigQuery vers Bigtable à l'aide de l'une des méthodes suivantes :
    1. ETL inversé
    2. Connecteur Spark Bigtable
    3. Modèle Dataflow BigQuery vers Bigtable

Phase 4 : Transition de l'application et du SDK

La dernière étape consiste à migrer la couche Application.

  1. Une fois la migration terminée et testée, arrêtez d'écrire dans Vertex AI Feature Store (ancien).

  2. Modifiez votre application pour qu'elle n'utilise que la bibliothèque cliente Python pour Bigtable.

    L'exemple suivant montre comment utiliser Python pour extraire une seule caractéristique de 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"))

    Pour obtenir un autre exemple de lecture et d'écriture de données à l'aide des API Bigtable de données et d'administration, consultez Hello World en Python.

    La bibliothèque cliente Python pour Bigtable vous permet également d'utiliser GoogleSQL pour renvoyer des caractéristiques qui répondent à vos critères de filtrage ou pour effectuer des transformations de ces caractéristiques. L'exemple suivant montre comment appeler une requête SQL de manière asynchrone à partir de la bibliothèque cliente Python Bigtable. Pour en savoir plus sur GoogleSQL pour Bigtable, consultez Autres exemples de code 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. Commencez à utiliser les métriques Bigtable pour surveiller la latence et le débit. Pour en savoir plus, consultez la section Surveillance.

Bonnes pratiques

Après avoir migré de Vertex AI Feature Store (ancien) vers une implémentation Bigtable Feature Store, vous devez répliquer la logique interne de prétraitement et d'optimisation qui était auparavant gérée par le service pour maintenir la stabilité et les performances.

Limitation adaptative côté client

Le backend Vertex AI Feature Store (ancien) utilise un limiteur adaptatif côté client pour protéger ses instances Bigtable sous-jacentes contre la surcharge lors des pics de trafic ou lorsque le backend de stockage présente une latence ou des erreurs élevées. Nous vous recommandons d'implémenter un limiteur similaire dans le code de votre application pour enregistrer les réponses du backend et limiter de manière proactive les requêtes si nécessaire.

Partitionnement des requêtes et optimisation de la taille des lots

La taille des filtres de lignes Bigtable est limitée à 20 Ko. Si vous demandez trop de caractéristiques ou d'ID d'entité dans une même lecture filtrée, les requêtes peuvent échouer. Pour reproduire le comportement de Vertex AI Feature Store (ancien), procédez comme suit :

  • ID de caractéristiques par blocs : limitez le nombre d'ID de caractéristiques par lecture Bigtable à environ 100.
  • Équilibrer les lots d'entités : pour éviter de saturer les ressources client ou serveur lors de la lecture de plusieurs entités, prenez les précautions suivantes :
    • Partitionnez les entités en petits lots simultanés, par exemple 10 entités par lot.
    • Limitez le nombre maximal de requêtes par lot simultanées (par exemple, entre 10 et 20).

Sélection intelligente des filtres

Le calcul et l'application des filtres de colonne côté serveur ajoutent une surcharge. Si votre application demande généralement la quasi-totalité des fonctionnalités d'une famille de colonnes (par exemple, plus de 99,9 %), il est plus efficace d'ignorer le filtre de colonne et de lire la ligne complète, en filtrant les résultats côté client.

Concurrence et exécution asynchrone

Pour minimiser le délai avant le premier résultat dans les scénarios de streaming, utilisez des modèles asynchrones ou des groupes de threads pour récupérer les lots d'entités en parallèle. Cela garantit que l'application peut commencer à traiter les résultats dès le retour du premier lot, au lieu d'attendre la fin d'une lecture série volumineuse.

Étapes suivantes