Von Vertex AI Feature Store (Legacy) zu Bigtable migrieren

Die Migration einer Arbeitslast für die Verwaltung von Machine-Learning-Features von Vertex AI Feature Store (Legacy) zu Bigtable kann zu einer verbesserten Leistung und Flexibilität führen. Dieser Leitfaden bietet einen Überblick über die zugehörigen Konzepte und den Migrationsprozess.

Vertex AI Feature Store (Legacy) ist eine verwaltete Umgebung, in der Bigtable für die Onlinebereitstellungsebene verwendet wird. Wenn Sie Ihre KI-Plattform oder Ihren Feature Store direkt in Bigtable ausführen, ohne Vertex AI Feature Store (Legacy) zu verwenden, können Sie die Geschwindigkeit erhöhen und die Kosten senken.

Wir empfehlen einen minimalen Migrationspfad, bei dem Daten aus den zugrunde liegenden Bigtable-Tabellen in Vertex AI Feature Store (Legacy) in eine Bigtable-Instanz migriert werden, die Sie in Ihrem Google Cloud Projekt erstellen.

Vorteile der Migration

Die Migration zu Bigtable bietet mehrere strategische und operative Vorteile:

  • Kosteneffizienz: Sie sparen die Prämie für die knotenspezifische Verwaltung von Vertex AI Feature Store (Legacy) ein, was häufig die Infrastrukturkosten senkt.
  • Direkte Steuerung: Sie erhalten vollen Zugriff auf die Bigtable-Funktionen. Bigtable-Monitoring bietet viel mehr Messwerte als Vertex AI Feature Store (Legacy). Außerdem haben Sie mehr Kontrolle über benutzerdefinierte Architektur-Layouts und die Skalierung.
  • Hohe Leistung: Bigtable unterstützt Arbeitslasten mit hoher Leistung und Funktionen mit hoher Leistung wie Aggregation bei Schreibvorgängen und Vektorsuche.

  • Produktübergreifende Integration: Sie erhalten Zugriff auf Bigtable-Integrationen wie externe BigQuery-Tabellen, Connectors für Apache Spark, Apache Flink und Kafka Connect sowie Reverse-ETL aus BigQuery.

  • Change Data Capture: Sie können Änderungsstreams aktivieren, um Änderungen an Ihrer Bigtable-Feature Store-Tabelle zu erfassen, sobald sie eintreten.

Wichtige Konzepte

In diesem Abschnitt wird beschrieben, wie die Kernkonzepte von Vertex AI Feature Store (Legacy) von Bigtable und BigQuery implementiert werden.

Datenaufbewahrung

In Bigtable verwalten Sie die Datenaufbewahrung mit der automatischen Speicherbereinigung. Bei der automatischen Speicherbereinigung handelt es sich um den automatischen, fortlaufenden Prozess, bei dem abgelaufene und veraltete Daten aus Bigtable-Tabellen entfernt werden. Eine Richtlinie für die automatische Speicherbereinigung ist ein Satz von Regeln, die Sie erstellen, wenn Daten in einem bestimmten Attribut, das in Bigtable als Spaltenfamilie definiert ist, nicht mehr benötigt werden. Richtlinien für die automatische Speicherbereinigung werden basierend auf dem Zeitstempel der Daten oder der Anzahl der Versionen festgelegt, die Sie beibehalten möchten.

Die automatische Speicherbereinigung ist ein integrierter, asynchroner Hintergrundprozess, der während der Kompaktierung stattfindet. Die automatische Speicherbereinigung erfolgt nach einem festen Zeitplan. Solange die Daten nicht gelöscht wurden, werden sie in den Leseergebnissen angezeigt. Sie können die Leseergebnisse jedoch filtern, um diese Daten auszuschließen. Weitere Informationen finden Sie unter Automatische Speicherbereinigung – Übersicht.

Bigtable-Speicherklassen können außerdem eine kostengünstige Lösung für Online-Feature-Stores sein, in denen Verlaufsdaten für das Modelltraining oder die Einhaltung von Vorschriften aufbewahrt werden müssen. Bei Tiered Storage werden Daten, auf die selten zugegriffen wird, von der Onlinebereitstellung auf SSD-Speicher in eine kostengünstigere Speicherebene verschoben.

Funktionsentwicklung

In Bigtable können Sie die Online-Feature-Entwicklung mit Bigtable SQL und die Offline-Feature-Entwicklung mit BigQuery DataFrames implementieren.

Wenn Sie Vertex AI Feature Store (Legacy) verwenden, arbeiten Sie mit Entwickler-APIs und Datenmodellen, die den zugrunde liegenden Datenquellen zugeordnet sind, die in BigQuery vorbereitet wurden. Anschließend registrieren Sie diese Datenquellen und bestimmte Featurespalten in der Feature Registry. Mit einem Bigtable-Feature-Store arbeiten Sie direkt mit Daten in den zugrunde liegenden BigQuery- und Bigtable-Instanzen, ohne dass Sie das Datenmodell von Vertex AI Feature Store (Legacy) zuordnen müssen.

Entwicklung von Onlinefunktionen

Für die Online-Featureentwicklung bietet Bigtable mehrere Tools:

  • Python-Clientbibliothek: Mit der Python-Clientbibliothek für Bigtable können Sie direkt mit Daten in Bigtable arbeiten.
  • GoogleSQL: Mit GoogleSQL können Sie Daten in Bigtable lesen und transformieren. Sie können SQL-Abfragen direkt in der Bigtable-Konsole oder über die Python-Clientbibliothek ausführen.
  • Kontinuierliche materialisierte Ansichten: Wenn Sie Funktionen in Echtzeit erstellen möchten, für die wiederkehrende Transformationen und Aggregationen erforderlich sind, verwenden Sie kontinuierliche materialisierte Ansichten von Bigtable, um eine SQL-Abfrage inkrementell für Daten auszuführen, sobald sie in Bigtable eingehen.

Entwicklung von Offlinefunktionen

Für die Offline-Feature-Entwicklung bietet BigQuery DataFrames eine Python-Schnittstelle mit mehr als 750 Pandas- und Scikit-Learn-APIs. Diese APIs werden durch SQL-Konvertierung in BigQuery- und BigQuery ML-APIs implementiert. Mit der Funktion „BigQuery DataFrames“ können sowohl integrierte als auch benutzerdefinierte Python-Funktionen verwendet werden. Außerdem bietet sie eine automatische Datensynchronisierung mit Bigtable für die Bereitstellung von Funktionen, die in Batch- und Offlineprozessen erstellt wurden (siehe nächster Abschnitt).

Synchronisierung von Online- und Offlinefunktionen

Wenn Sie Bigtable direkt für ML-Arbeitslasten verwenden, können Sie dafür sorgen, dass ein Offline-Featurewert aus BigQuery importiert wird und derselbe Wert sowohl für das Training als auch für die Bereitstellung wiederverwendet wird. So bleiben die Codepfade für das Generieren von Features zwischen Training und Bereitstellung synchron. Die folgenden Technologien ermöglichen die Synchronisierung von Funktionen:

  • Batchsynchronisierung: Mit Reverse ETL von BigQuery nach Bigtable können Sie die Ergebnisse einer BigQuery-Abfrage in Bigtable exportieren. Diese Abfragen werden im Batchmodus ausgeführt und können direkt über BigQuery geplant werden.
  • Streaming-Synchronisierung: Kontinuierliche BigQuery-Abfragen sind SQL-Anweisungen, die kontinuierlich ausgeführt werden und Zeilen in eine Bigtable-Tabelle ausgeben.
  • Synchronisierung über BigQuery DataFrames: Um Offline-Features zu erfassen, die in Python entwickelt wurden, können Sie einen BigFrames StreamingDataFrame verwenden, um eine kontinuierliche BigQuery-Abfrage zu generieren, die Ihre Python-Logik für die Feature-Generierung erfasst und die Datenergebnisse mit Bigtable synchronisiert.
  • Offline-Feature-Entwicklung direkt für Bigtable-Daten: Sie können Offline-Features in BigQuery für Daten erstellen, die in Bigtable gespeichert sind. Dazu verwenden Sie eine externe BigQuery-Tabelle. Eine externe Tabelle ähnelt einer BigQuery-Tabelle und bietet die meisten Funktionen wie Joins, geplante Abfragen und erweiterte BigQuery-SQL-Funktionen, ohne dass Daten zurück in den BigQuery-Speicher verschoben werden müssen. Um den Traffic Ihrer Anwendung nicht zu beeinträchtigen, können Sie Data Boost-Serverless Compute verwenden, wenn Sie Bigtable-Daten mit externen BigQuery-Tabellen lesen. Die Verwendung von Data Boost ist besonders kostengünstig für Ad-hoc-Abfragen. Wenn Sie Data Boost verwenden möchten, geben Sie beim Erstellen der Definition der externen Tabelle ein Data Boost-Anwendungsprofil an. Weitere Informationen zu Data Boost finden Sie unter Bigtable Data Boost-Übersicht.

Nach der Migration können Sie weiterhin Vertex AI Model Monitoring verwenden, um die Qualität Ihrer Modelle zu verfolgen.

Die gemeinsame Verwendung von Bigtable und BigQuery ist ein gängiges Muster für die Erstellung von Echtzeit-Analysedatenbanken.

Migrationsphasen

Um die Kontinuität des Dienstes zu gewährleisten, wird die Migration in der Regel in den folgenden Phasen durchgeführt.

Phase 1: Infrastruktur vorbereiten

Richten Sie vor Beginn der Migration die Zielumgebung ein:

Phase 2: Schemazuordnung zwischen Vertex AI Feature Store (Legacy) und Bigtable definieren

  1. Best Practices für das Bigtable-Schemadesign Eine allgemeine Zuordnung der Vertex AI Feature Store (Legacy)-API zur Bigtable API sieht so aus:

    Vertex AI Feature Store-Ressource (Legacy)

    Bigtable-Komponente

    FeatureOnlineStore

    Bigtable-Instanz

    FeatureView

    Spaltenfamilie

    featureValues (Batch)

    Spalte (eine Zelle pro Schlüssel)

    featureValues (Dauervertrag)

    Spalte (mehrere Zellen pro Schlüssel [Versionsverwaltung])

  2. Nachdem Sie die Schemazuordnung definiert haben, erstellen Sie eine Bigtable-Tabelle mit einer Spaltenfamilie für jedes Attribut im Quellattributspeicher.

Phase 3: Datenextraktion und ‑synchronisierung

In dieser Phase migrieren Sie Daten mithilfe eines stufenweisen Ansatzes, der auf der Aktualisierungshäufigkeit der Daten basiert.

Echtzeitsynchronisierung von Funktionen

Beginnen Sie, dieselben Daten in die neue Bigtable-Tabelle zu schreiben, wenn Sie Funktionen mit write_feature_values oder entsprechenden API-Aufrufen schreiben.

  1. Installieren Sie die Python-Clientbibliothek für Bigtable.
  2. Konfigurieren Sie Ihre Anwendung so, dass Feature-Daten gleichzeitig in Vertex AI Feature Store (Legacy) und Bigtable geschrieben werden. Weitere Informationen zum Schreiben von Daten in Bigtable finden Sie unter Schreibvorgänge.

Batch-Funktionsmigration

Migrieren Sie als Nächstes die Daten, die vor dem Beginn der Dual-Writes gespeichert wurden. Dazu müssen die Daten aus Vertex AI Feature Store (Legacy) nach BigQuery und dann nach Bigtable verschoben werden.

  1. Exportieren Sie Feature Store-Daten mit den Exportfunktionen von Vertex AI Feature Store (Legacy) in BigQuery. Damit können Sie alle Werte oder Snapshots exportieren. So kann BigQuery als Offlinespeicher für Vertex AI Feature Store (Legacy) dienen.
  2. Migrieren Sie die Verlaufsdaten aus BigQuery zu Bigtable mit einer der folgenden Methoden:
    1. Reverse-ETL
    2. Bigtable Spark-Connector
    3. Dataflow-Vorlage für BigQuery zu Bigtable

Phase 4: Umstellung von Anwendung und SDK

Der letzte Schritt ist die Umstellung der Anwendungsschicht.

  1. Nachdem die Migration abgeschlossen und getestet wurde, stellen Sie das Schreiben in Vertex AI Feature Store (Legacy) ein.

  2. Ändern Sie Ihre Anwendung so, dass nur die Python-Clientbibliothek für Bigtable verwendet wird.

    Im folgenden Beispiel wird gezeigt, wie Sie mit Python ein einzelnes Feature aus Bigtable abrufen.

    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"))

    Ein weiteres Beispiel dafür, wie Daten mit den Bigtable Data und Admin APIs gelesen und geschrieben werden, finden Sie unter Python Hello World.

    Mit der Python-Clientbibliothek für Bigtable können Sie auch GoogleSQL verwenden, um Features zurückzugeben, die Ihren Filterkriterien entsprechen, oder um Transformationen der Features durchzuführen. Im folgenden Beispiel wird gezeigt, wie Sie eine SQL-Abfrage asynchron über die Bigtable-Python-Clientbibliothek aufrufen. Weitere Informationen zu GoogleSQL für Bigtable finden Sie unter Zusätzliche SQL-Beispiele.

    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. Beginnen Sie mit der Verwendung von Bigtable-Messwerten, um Latenz und Durchsatz zu überwachen. Weitere Informationen finden Sie unter Monitoring.

Best Practices

Nachdem Sie von Vertex AI Feature Store (Legacy) zu einer Bigtable-Feature Store-Implementierung migriert sind, müssen Sie die interne Vorverarbeitungs- und Optimierungslogik replizieren, die zuvor vom Dienst verarbeitet wurde, um Stabilität und Leistung aufrechtzuerhalten.

Clientseitige adaptive Drosselung

Das Backend von Vertex AI Feature Store (Legacy) verwendet einen clientseitigen adaptiven Drosselungsmechanismus, um die zugrunde liegenden Bigtable-Instanzen vor Überlastung bei Trafficspitzen oder bei hoher Latenz oder Fehlern im Speicher-Backend zu schützen. Wir empfehlen, einen ähnlichen Throttler in Ihrem Anwendungscode zu implementieren, um Backend-Antworten zu registrieren und Anfragen bei Bedarf proaktiv zu drosseln.

Partitionierung und Batchgröße optimieren

Bigtable-Zeilenfilter haben eine feste Obergrenze von 20 KB. Wenn Sie in einem einzelnen gefilterten Lesevorgang zu viele Funktionen oder Entitäts-IDs anfordern, können Anfragen fehlschlagen. Um das Verhalten von Vertex AI Feature Store (Legacy) zu spiegeln, gehen Sie so vor:

  • Feature-IDs in Blöcke aufteilen: Beschränken Sie die Anzahl der Feature-IDs pro Bigtable-Lesevorgang auf etwa 100.
  • Batchvorgänge für Entitäten ausgleichen: Um eine Überlastung von Client- oder Serverressourcen bei Lesezugriffen auf mehrere Entitäten zu vermeiden, sollten Sie folgende Vorsichtsmaßnahmen treffen:
    • Teilen Sie Entitäten in kleine, gleichzeitige Batches auf, z. B. 10 Entitäten pro Batch.
    • Begrenzen Sie die maximale Anzahl gleichzeitiger Batchanfragen, z. B. auf 10 bis 20.

Intelligente Filterauswahl

Das Berechnen und Anwenden von Spaltenfiltern auf dem Server verursacht zusätzlichen Aufwand. Wenn Ihre Anwendung in der Regel fast alle Funktionen in einer Spaltenfamilie anfordert, z. B. > 99,9%, ist es effizienter, den Spaltenfilter zu überspringen und die gesamte Zeile zu lesen. Die Ergebnisse werden dann clientseitig gefiltert.

Gleichzeitigkeit und asynchrone Ausführung

Um die Zeit bis zum ersten Ergebnis in Streaming-Szenarien zu minimieren, verwenden Sie asynchrone Muster oder Thread-Bundles, um Entitäts-Batches parallel abzurufen. So kann die Anwendung mit der Verarbeitung der Ergebnisse beginnen, sobald der erste Batch zurückgegeben wird, anstatt auf den Abschluss eines großen seriellen Lesevorgangs zu warten.

Nächste Schritte