Migra de Vertex AI Feature Store (Legacy) a Bigtable

Migrar una carga de trabajo de administración de atributos de aprendizaje automático desde Vertex AI Feature Store (heredado) a Bigtable puede mejorar el rendimiento y la flexibilidad. En esta guía, se proporciona una descripción general de los conceptos relacionados y el proceso de migración.

Vertex AI Feature Store (heredado) es un entorno administrado que usa Bigtable para su capa de entrega en línea. Ejecutar tu plataforma de IA o tu almacén de atributos directamente en Bigtable sin usar Vertex AI Feature Store (heredado) puede generar velocidades más rápidas y costos reducidos.

Recomendamos una ruta de migración viable mínima enfocada en migrar datos de las tablas subyacentes de Bigtable en Vertex AI Feature Store (Legacy) a una instancia de Bigtable que crees en tu proyecto de Google Cloud .

Beneficios de la migración

La migración a Bigtable ofrece varias ventajas estratégicas y operativas:

  • Rentabilidad: Eliminas la prima de administración de nodos específica de Vertex AI Feature Store (heredado), lo que suele reducir los costos de infraestructura.
  • Control directo: Obtienes acceso completo a las capacidades de Bigtable. La supervisión de Bigtable expone muchas más métricas que Vertex AI Feature Store (Legacy). También tienes mayor control sobre los diseños y el escalamiento de la arquitectura personalizada.
  • Alto rendimiento: Bigtable admite cargas de trabajo de alto rendimiento y funciones de alto rendimiento, como la agregación en escrituras y la búsqueda de vectores.

  • Integración en varios productos: Obtienes acceso a integraciones de Bigtable, como tablas externas de BigQuery, conectores para Apache Spark, Apache Flink y Kafka Connect, y ETL inversa desde BigQuery.

  • Captura de datos modificados: Puedes habilitar flujos de cambios para capturar los cambios en tu tabla del almacén de atributos de Bigtable a medida que se producen.

Conceptos clave

En esta sección, se describe cómo Bigtable y BigQuery implementan los conceptos principales de Vertex AI Feature Store (heredado).

Retención de datos

En Bigtable, la retención de datos se administra con la recolección de elementos no utilizados. La recolección de elementos no utilizados es el proceso automático y continuo que consiste en quitar datos caducados y obsoletos de las tablas de Bigtable. Una política de recolección de elementos no utilizados es un conjunto de reglas que creas y que indican cuándo los datos de una función específica, definida en Bigtable como una familia de columnas, ya no son necesarios. Las políticas de recolección de elementos no utilizados se establecen según la marca de tiempo asociada a los datos o la cantidad de versiones que deseas conservar.

La recolección de elementos no utilizados es un proceso en segundo plano, integrado y asíncrono que se lleva a cabo durante la compactación. La recolección de elementos no utilizados se realiza en un horario fijo. Hasta que los datos se borren, aparecerán en los resultados de lectura, pero puedes filtrar las lecturas para excluir estos datos. Para obtener más información, consulta la Descripción general de la recolección de elementos no utilizados.

Además, el almacenamiento por niveles de Bigtable puede ser una solución rentable para los almacenes de atributos en línea que necesitan conservar datos históricos para el entrenamiento de modelos o el cumplimiento de reglamentaciones. El almacenamiento por niveles administra el movimiento de los datos a los que se accede con poca frecuencia desde la publicación en línea en el almacenamiento SSD a un nivel de almacenamiento de menor costo.

Desarrollo de funciones

En Bigtable, puedes implementar el desarrollo de funciones en línea con Bigtable SQL y el desarrollo de funciones sin conexión con BigQuery DataFrames.

Cuando usas Vertex AI Feature Store (heredado), trabajas con APIs para desarrolladores y modelos de datos que se asignan a fuentes de datos subyacentes preparadas en BigQuery. Luego, registras estas fuentes de datos y columnas de atributos específicas en el registro de atributos. Con un almacén de atributos de Bigtable, trabajas directamente con los datos en las instancias subyacentes de BigQuery y Bigtable, sin necesidad de asignar al modelo de datos de Vertex AI Feature Store (legacy).

Desarrollo de funciones en línea

Para el desarrollo de funciones en línea, Bigtable ofrece varias herramientas:

  • Biblioteca cliente de Python: Usa la biblioteca cliente de Python para Bigtable y trabaja directamente con los datos en Bigtable.
  • GoogleSQL: Usa GoogleSQL para leer y transformar datos en Bigtable. Puedes ejecutar consultas en SQL directamente en la consola de Bigtable o desde la biblioteca cliente de Python.
  • Vistas materializadas continuas: Para crear funciones casi en tiempo real que requieren transformaciones y agregaciones recurrentes, usa las vistas materializadas continuas de Bigtable para ejecutar de forma incremental una consulta en SQL en los datos a medida que ingresan en Bigtable.

Desarrollo de funciones sin conexión

Para el desarrollo de atributos sin conexión, BigQuery DataFrames proporciona una interfaz de Python con más de 750 APIs de Pandas y scikit-learn. Estas APIs se implementan a través de la conversión de SQL a las APIs de BigQuery y BigQuery ML. La generación de características de BigQuery DataFrames permite usar funciones de Python integradas y definidas por el usuario. También proporciona sincronización automática de datos con Bigtable para publicar funciones creadas en procesos por lotes y sin conexión, que se describen en la siguiente sección.

Sincronización de funciones en línea y sin conexión

Cuando usas Bigtable directamente para cargas de trabajo de AA, puedes asegurarte de que se importe un valor de atributo sin conexión desde BigQuery y de que ese mismo valor se reutilice para el entrenamiento y la entrega, lo que mantiene sincronizadas las rutas de código para generar atributos entre el entrenamiento y la entrega. Las siguientes tecnologías permiten la sincronización de funciones:

  • Sincronización por lotes: La ETL inversa de BigQuery a Bigtable permite exportar los resultados de una consulta de BigQuery a Bigtable. Estas consultas se ejecutan por lotes y se pueden programar directamente desde BigQuery.
  • Sincronización de transmisión: Las consultas continuas de BigQuery son instrucciones de SQL que se ejecutan de forma continua y generan filas en una tabla de Bigtable.
  • Sincronización desde BigQuery DataFrames: Para capturar atributos sin conexión desarrollados en Python, puedes usar un BigFrames StreamingDataFrame para generar una consulta continua de BigQuery que capture tu lógica de Python para la generación de atributos y sincronice los resultados de los datos con Bigtable.
  • Desarrollo de atributos sin conexión directamente en los datos de Bigtable: Puedes compilar atributos sin conexión en BigQuery a partir de los datos almacenados en Bigtable con una tabla externa de BigQuery. Una tabla externa refleja el aspecto de una tabla de BigQuery y ofrece la mayoría de las mismas funciones, como las uniones, las consultas programadas y las funciones avanzadas de BigQuery SQL, sin necesidad de volver a mover los datos al almacenamiento de BigQuery. Para evitar afectar el tráfico de servicio de tu aplicación, puedes usar la computación sin servidores de Data Boost cuando lees datos de Bigtable con tablas externas de BigQuery. El uso de Data Boost es especialmente rentable para las consultas ad hoc. Para usar Data Boost, especifica un perfil de app de Data Boost cuando crees la definición de la tabla externa. Para obtener más información sobre Data Boost, consulta la descripción general de Bigtable Data Boost.

Después de la migración, puedes seguir usando Vertex AI Model Monitoring para hacer un seguimiento de la calidad de tus modelos.

La práctica de usar Bigtable y BigQuery juntos es un patrón común para compilar bases de datos de análisis en tiempo real.

Fases de migración

Para garantizar la continuidad del servicio, la migración suele ejecutarse en las siguientes fases distintas.

Fase 1: Prepara la infraestructura

Antes de comenzar la migración, configura el entorno de destino:

Fase 2: Define la asignación de esquemas entre Vertex AI Feature Store (heredado) y Bigtable

  1. Revisa y comprende las prácticas recomendadas para el diseño de esquemas de Bigtable. A continuación, se muestra una asignación general de la API de Vertex AI Feature Store (heredado) a la API de Bigtable:

    Recurso de Vertex AI Feature Store (heredado)

    Componente de Bigtable

    FeatureOnlineStore

    Instancia de Bigtable

    FeatureView

    Familia de columnas

    featureValues (lote)

    Columna (una sola celda por clave)

    featureValues (continuo)

    Columna (varias celdas por clave [control de versiones])

  2. Después de definir la asignación del esquema, crea una tabla de Bigtable que tenga una familia de columnas para cada función en el almacén de funciones de origen.

Fase 3: Extracción y sincronización de datos

En esta fase, migras los datos con un enfoque por niveles según la frecuencia de actualización de los datos.

Sincronización de funciones en tiempo real

Para las funciones que escribas con write_feature_values o llamadas a la API equivalentes, comienza a escribir los mismos datos en la nueva tabla de Bigtable.

  1. Instala la biblioteca cliente de Python para Bigtable.
  2. Configura tu aplicación para que escriba datos de atributos de forma simultánea en Vertex AI Feature Store (heredado) y Bigtable. Para obtener más información sobre cómo escribir datos en Bigtable, consulta Escrituras.

Migración de atributos por lotes

A continuación, migra los datos que se almacenaron antes de que comenzaras a realizar escrituras duales. Esto implica mover los datos de Vertex AI Feature Store (heredado) a BigQuery y, luego, a Bigtable.

  1. Exporta datos del almacén de atributos a BigQuery con las capacidades de exportación de Vertex AI Feature Store (heredado), que te permiten exportar todos los valores o instantáneas. Esto permite que BigQuery funcione como el almacenamiento sin conexión de Vertex AI Feature Store (Legacy).
  2. Migra los datos históricos de BigQuery a Bigtable con una de las siguientes opciones:
    1. ETL inverso
    2. Conector de Bigtable Spark
    3. Plantilla de Dataflow de BigQuery a Bigtable

Fase 4: Transición de la aplicación y el SDK

El paso final es la transferencia de la capa de aplicación.

  1. Una vez que se haya completado y probado la migración, deja de escribir en Vertex AI Feature Store (Legacy).

  2. Modifica tu aplicación para que solo use la biblioteca cliente de Python para Bigtable.

    En el siguiente ejemplo, se muestra cómo usar Python para extraer un solo atributo 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"))

    Para ver otro ejemplo de cómo leer y escribir datos con las APIs de administración y datos de Bigtable, consulta el ejemplo de Python Hello World.

    La biblioteca cliente de Python para Bigtable también te permite usar GoogleSQL para devolver atributos que cumplen con tus criterios de filtro o para realizar transformaciones de los atributos. En el siguiente ejemplo, se muestra cómo llamar a una consulta en SQL de forma asíncrona desde la biblioteca cliente de Bigtable en Python. Para obtener información adicional sobre GoogleSQL para Bigtable, consulta Ejemplos adicionales 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. Comienza a usar las métricas de Bigtable para supervisar la latencia y el procesamiento. Para obtener más información, consulta Supervisión.

Prácticas recomendadas

Después de migrar de Vertex AI Feature Store (heredado) a una implementación de almacén de atributos de Bigtable, debes replicar la lógica interna de optimización y procesamiento previo que antes controlaba el servicio para mantener la estabilidad y el rendimiento.

Limitación adaptable del cliente

El backend de Vertex AI Feature Store (Legacy) utiliza un limitador adaptable del cliente para proteger sus instancias subyacentes de Bigtable de la sobrecarga durante los picos de tráfico o cuando el backend de almacenamiento experimenta errores o latencia alta. Te recomendamos que implementes un limitador similar en el código de tu aplicación para registrar las respuestas del backend y limitar de forma proactiva las solicitudes cuando sea necesario.

Optimización del tamaño del lote y la creación de particiones de solicitudes

Los filtros de filas de Bigtable tienen un límite estricto de 20 KB. Solicitar demasiadas funciones o IDs de entidades en una sola lectura filtrada puede provocar errores en las solicitudes. Para replicar el comportamiento de Vertex AI Feature Store (Legacy), haz lo siguiente:

  • IDs de entidades de fragmentos: Limita la cantidad de IDs de entidades por lectura de Bigtable a aproximadamente 100.
  • Balancea los lotes de entidades: Para evitar saturar los recursos del cliente o del servidor cuando realices lecturas de varias entidades, toma las siguientes precauciones:
    • Divide las entidades en lotes pequeños simultáneos, como 10 entidades por lote.
    • Limita la cantidad máxima de solicitudes por lotes simultáneas, por ejemplo, de 10 a 20.

Selección inteligente de filtros

Calcular y aplicar filtros de columnas en el servidor agrega una sobrecarga. Si tu aplicación suele solicitar casi todas las funciones de una familia de columnas (por ejemplo, más del 99.9%), es más eficiente omitir el filtro de columnas y leer la fila completa, y luego filtrar los resultados del lado del cliente.

Simultaneidad y ejecución asíncrona

Para minimizar el tiempo hasta el primer resultado en situaciones de transmisión, usa patrones asíncronos o paquetes de subprocesos para recuperar lotes de entidades en paralelo. Esto garantiza que la aplicación pueda comenzar a procesar los resultados en cuanto se devuelva el primer lote, en lugar de esperar a que se complete una lectura serial grande.

¿Qué sigue?