Jan 01, 1970
2,086 lecturas
Una guía para usar Apache Cassandra como una tienda de funciones en tiempo real
Demasiado Largo; Para Leer
Esta guía explora la IA en tiempo real y los atributos únicos de rendimiento y costo de Cassandra que la convierten en una excelente base de datos para una tienda de funciones.Esta es una guía práctica para usar Apache Cassandra como un almacén de funciones en tiempo real. Exploramos la IA en tiempo real y los atributos únicos de rendimiento y costo de Cassandra que la convierten en una excelente base de datos para una tienda de características y luego nos sumergimos en los conceptos básicos de las tiendas de características y su función en las aplicaciones en tiempo real. Cassandra es utilizada como tienda de características por grandes empresas, incluidas
La guía se divide en varias secciones clave. Comenzamos presentando a Cassandra y sus características que la convierten en una opción ideal para una tienda de características. Luego, explicamos los conceptos básicos de las tiendas de funciones, incluidos qué son y cómo se pueden usar en aplicaciones en tiempo real. Después de eso, exploramos los detalles de implementación de la creación de una tienda de funciones con Cassandra. Esto incluye el modelado de datos, la ingesta y recuperación de características y el manejo de actualizaciones de datos. Finalmente, ofrecemos las mejores prácticas y consejos para usar Cassandra como una tienda de funciones para garantizar un rendimiento y una escalabilidad óptimos, desde los requisitos de latencia hasta los requisitos de métricas de rendimiento estimado para las arquitecturas de referencia y la compatibilidad del ecosistema.
Esta guía no discute la
¿Qué es la IA en tiempo real?
La IA en tiempo real hace inferencias o modelos de entrenamiento basados en eventos recientes . Tradicionalmente, los modelos de entrenamiento y las inferencias (predicciones) basadas en modelos se han realizado por lotes, generalmente durante la noche o periódicamente durante el día. Hoy en día, los sistemas modernos de aprendizaje automático realizan inferencias de los datos más recientes para proporcionar la predicción más precisa posible. Un pequeño conjunto de empresas como TikTok y Google ha impulsado aún más el paradigma en tiempo real al incluir el entrenamiento de modelos sobre la marcha a medida que ingresan nuevos datos.
Debido a estos cambios en la inferencia y los cambios que probablemente ocurrirán en el entrenamiento del modelo, la persistencia de los datos de características (datos que se usan para entrenar y realizar inferencias para un modelo de ML) también debe adaptarse. Cuando termine de leer esta guía, tendrá una idea más clara de cómo Cassandra y DataStax Astra DB, un servicio administrado basado en Cassandra, satisface las necesidades de IA en tiempo real y cómo se pueden usar junto con otras tecnologías de bases de datos. para inferencia y entrenamiento de modelos.
¿Qué es una tienda de funciones?
Un almacén de funciones es un sistema de datos específico del aprendizaje automático (ML) que:
- Ejecuta canalizaciones de datos que transforman datos sin procesar en valores de características
- Almacena y administra los datos de características en sí, y
- Sirve datos de características de manera consistente para propósitos de entrenamiento e inferencia
La IA en tiempo real impone demandas específicas en una tienda de funciones que Cassandra está especialmente calificada para cumplir, específicamente cuando se trata del almacenamiento y la prestación de funciones para la prestación de servicios de modelos y la capacitación de modelos.
Mejores prácticas
**Implemente consultas de baja latencia para el servicio de funciones
Para la inferencia en tiempo real, las características deben devolverse a las aplicaciones con baja latencia a escala. Los modelos típicos involucran ~200 características distribuidas en ~10 entidades. Las inferencias en tiempo real requieren que se presupueste tiempo para recopilar características, transformaciones ligeras de datos y realizar una inferencia. De acuerdo con la siguiente encuesta (también confirmada por nuestras conversaciones con profesionales), las tiendas de funciones deben devolver las funciones a una aplicación que realiza inferencias en menos de 50 ms.
Por lo general, los modelos requieren "uniones internas" en varias entidades lógicas: combinar valores de filas de varias tablas que comparten un valor común; esto presenta un desafío significativo para el servicio de características de baja latencia. Tomemos el caso de Uber Eats, que predice el tiempo para entregar una comida. Es necesario unir los datos de la información del pedido, que se une con la información del restaurante, que luego se une con la información del tráfico en la región del restaurante. En este caso, son necesarias dos uniones internas (vea la ilustración a continuación).
Para lograr una unión interna en Cassandra, uno puede desnormalizar los datos al momento de la inserción o hacer dos consultas secuenciales a Cassandra + realizar la unión en el lado del cliente. Aunque es posible realizar todas las uniones internas al insertar datos en la base de datos a través de la desnormalización, tener una proporción de 1:1 entre el modelo y la tabla no es práctico porque significa mantener una cantidad excesiva de tablas desnormalizadas. Las mejores prácticas sugieren que el almacén de funciones debe permitir 1 o 2 consultas secuenciales para uniones internas, combinadas con desnormalización.
Aquí hay un resumen de las métricas de rendimiento que se pueden usar para estimar los requisitos para las canalizaciones de ML en tiempo real:
Condiciones de prueba:
caracteristicas = 200
número de tablas (entidades) = 3
número de uniones internas = 2
Consulta TPS: 5000 consultas / segundo
Escribir TPS: 500 registros / segundo
Tamaño del clúster: 3 nodos en AstraDB*
Resumen de rendimiento de latencia (las incertidumbres aquí son desviaciones estándar):
tp95 = 13,2 (+/-0,6) ms
tp99 = 23,0 (+/-3,5) ms
tp99.9 = 63 (+/- 5) ms
Efecto de la compactación:
- tp95 = despreciable
- tp99, tp999 = insignificante, capturado por los sigmas citados anteriormente
Efecto de la captura de datos modificados (CDC):
tp50, tp95 ~ 3-5ms
tp99 ~ 3ms
tp999 ~ insignificante
*Las siguientes pruebas se realizaron en el nivel gratuito de Astra DB de DataStax, que es un entorno sin servidor para Cassandra. Los usuarios deben esperar un rendimiento de latencia similar cuando se implementan en tres notas con la siguiente configuración recomendada .
El impacto más significativo en la latencia es el número de uniones internas. Si solo se consulta una tabla en lugar de tres, el tp99 cae un 58%; para dos mesas, es un 29% menos. El tp95 cae un 56% y un 21%, respectivamente. Debido a que Cassandra es escalable horizontalmente, la consulta de más funciones tampoco aumenta significativamente la latencia promedio.
Por último, si los requisitos de latencia no se pueden cumplir de inmediato, Cassandra tiene dos características adicionales: la capacidad de admitir datos desnormalizados (y, por lo tanto, reducir las uniones internas) debido a las capacidades de alto rendimiento de escritura y la capacidad de replicar datos de forma selectiva para incorporarlos. cachés de memoria (por ejemplo, Redis) a través de Change Data Capture. Puedes encontrar más consejos para reducir la latencia aquí.
Implemente escrituras tolerantes a fallas y de baja latencia para transformaciones de características
Un componente clave de la IA en tiempo real es la capacidad de usar los datos más recientes para hacer una inferencia del modelo, por lo que es importante que los nuevos datos estén disponibles para la inferencia lo antes posible. Al mismo tiempo, para los casos de uso empresarial, es importante que las escrituras sean duraderas porque la pérdida de datos puede causar importantes desafíos de producción.
*Los almacenes de objetos (p. ej., S3 o HIVE) se pueden reemplazar con otros tipos de sistemas orientados a lotes, como almacenes de datos.
Existe una compensación entre las escrituras duraderas de baja latencia y el servicio de características de baja latencia. Por ejemplo, es posible almacenar los datos solo en una ubicación no duradera (p. ej., Redis), pero las fallas de producción pueden dificultar la recuperación de las funciones más actualizadas porque requeriría un gran recálculo a partir de eventos sin procesar. .
Una arquitectura común sugiere escribir funciones en una tienda fuera de línea (p. ej., Hive/S3) y replicar las funciones en una tienda en línea (p. ej., caché en memoria). Aunque esto proporciona durabilidad y baja latencia para el servicio de funciones, tiene el costo de introducir latencia para escrituras de funciones, lo que invariablemente provoca un rendimiento de predicción más bajo.
Cassandra ofrece una buena compensación entre el servicio de funciones de baja latencia y las escrituras de funciones "duraderas" de baja latencia. Los datos escritos en Cassandra normalmente se han replicado un mínimo de tres veces y admiten la replicación en varias regiones. La latencia desde la escritura hasta la disponibilidad para leer suele ser inferior al milisegundo. Como resultado, al conservar las funciones directamente en la tienda en línea (Cassandra) y pasar por alto la tienda fuera de línea, la aplicación tiene un acceso más rápido a los datos recientes para hacer predicciones más precisas. Al mismo tiempo, CDC, desde la tienda en línea hasta la tienda fuera de línea, permite el entrenamiento por lotes o la exploración de datos con las herramientas existentes.
Implemente baja latencia y escrituras para el almacenamiento en caché de predicciones y la supervisión del rendimiento
Además de almacenar la transformación de funciones, también existe la necesidad de almacenar predicciones y otros datos de seguimiento para monitorear el rendimiento.
Hay varios casos de uso para almacenar predicciones:
- Almacén de predicciones : en este escenario, una base de datos utilizada para almacenar en caché las predicciones realizadas por un sistema por lotes o un sistema de transmisión . La arquitectura de transmisión es particularmente útil cuando el tiempo que lleva la inferencia está más allá de lo aceptable en un sistema de solicitud y respuesta.
- Monitoreo del rendimiento de la predicción A menudo es necesario monitorear el resultado de la predicción de una inferencia en tiempo real y compararlo con los resultados finales. Esto significa tener una base de datos para registrar los resultados de la predicción y el resultado final.
Cassandra es una tienda adecuada para ambos casos de uso debido a sus capacidades de alto rendimiento de escritura.
Plan para cargas de trabajo de lectura y escritura elásticas
El nivel de transacciones de consulta y escritura por segundo generalmente depende de la cantidad de usuarios que usan el sistema simultáneamente. Como resultado, las cargas de trabajo pueden cambiar según la hora del día o la época del año. Es importante tener la capacidad de escalar y reducir rápidamente el clúster para admitir mayores cargas de trabajo. Cassandra y Astra DB tienen funciones que permiten el escalado dinámico de clústeres.
El segundo aspecto que podría afectar las cargas de trabajo de escritura es si hay cambios en la lógica de transformación de funciones. Con un gran aumento en las cargas de trabajo de escritura, Cassandra prioriza automáticamente el mantenimiento de consultas de baja latencia y la escritura de TPS sobre la consistencia de los datos, lo que suele ser aceptable para realizar inferencias en tiempo real.
Implementar soporte multirregional de baja latencia
A medida que la IA en tiempo real se vuelve omnipresente en todas las aplicaciones, es importante asegurarse de que los datos de características estén disponibles lo más cerca posible de donde se produce la inferencia. Esto significa tener el almacén de funciones en la misma región que la aplicación que realiza la inferencia. La replicación de los datos en el almacén de funciones en todas las regiones ayuda a garantizar esa función. Además, replicar solo las funciones en lugar de los datos sin procesar utilizados para generar las funciones reduce significativamente las tarifas de salida de la nube.
Astra DB es compatible con la replicación de múltiples regiones lista para usar, con una latencia de replicación en milisegundos. Nuestra recomendación es transmitir todos los datos de eventos sin procesar a una sola región, realizar la generación de funciones y almacenar y replicar las funciones en todas las demás regiones.
Aunque, en teoría, se puede lograr cierta ventaja de latencia al generar características en cada región, a menudo los datos de eventos deben combinarse con datos de eventos sin procesar de otras regiones. desde el punto de vista de la corrección y la eficiencia, es más fácil enviar todos los eventos a una región para su procesamiento en la mayoría de los casos de uso. Por otro lado, si el uso del modelo tiene más sentido en un contexto regional y la mayoría de los eventos están asociados con entidades específicas de la región, entonces tiene sentido tratar las entidades como específicas de la región. Cualquier evento que deba replicarse entre regiones se puede colocar en espacios clave con estrategias de replicación global, pero idealmente, esto debería ser un pequeño subconjunto de eventos. En cierto punto, la replicación de tablas de eventos globalmente será menos eficiente que simplemente enviar todos los eventos a una sola región para los cálculos de características.
Planifique soporte multinube rentable y de baja latencia
La compatibilidad con varias nubes aumenta la resiliencia de las aplicaciones y permite a los clientes negociar precios más bajos. Las tiendas en línea de una sola nube, como DynamoDB, dan como resultado una mayor latencia para recuperar funciones y costos significativos de salida de datos, pero también crea el bloqueo a un solo proveedor de nube.
Las bases de datos de código abierto que admiten la replicación entre nubes brindan el mejor equilibrio de costos de rendimiento. Para minimizar el costo de salida, los eventos y la generación de funciones deben consolidarse en una nube, y los datos de funciones deben replicarse en bases de datos de código abierto en las otras nubes. Esto minimiza los costos de salida.
Planifique el entrenamiento por lotes y en tiempo real de los modelos de producción
La infraestructura de procesamiento por lotes para la creación de modelos se utiliza para dos casos de uso: la creación y prueba de nuevos modelos y la creación de modelos para la producción. Por lo tanto, por lo general, era suficiente que los datos de características se almacenaran en almacenes de objetos más lentos con el fin de entrenar. Sin embargo, los paradigmas de entrenamiento de modelos más nuevos incluyen la actualización de los modelos en tiempo real o casi en tiempo real (entrenamiento en tiempo real); esto se conoce como “aprendizaje en línea” (por ejemplo , Monolith de TikTok ). El patrón de acceso para el entrenamiento en tiempo real se encuentra en algún lugar entre la inferencia y el entrenamiento por lotes tradicional. Los requisitos de datos de rendimiento son más altos que los de la inferencia (porque normalmente no accede a una búsqueda de una sola fila), pero no tan altos como el procesamiento por lotes que implicaría escaneos completos de la tabla.
Cassandra puede admitir una calificación TPS de cientos de miles por segundo (con un modelo de datos adecuado), lo que puede proporcionar suficiente rendimiento para la mayoría de los casos de uso de capacitación en tiempo real. Sin embargo, en el caso de que el usuario quiera mantener el entrenamiento en tiempo real desde un almacén de objetos, Cassandra lo logra a través de CDC para el almacenamiento de objetos. Para el entrenamiento por lotes, CDC debe replicar los datos en el almacenamiento de objetos. Vale la pena señalar que los marcos de aprendizaje automático como Tensorflow y PyTorch están particularmente optimizados para el entrenamiento paralelo de modelos ML desde el almacenamiento de objetos.
Para obtener una explicación más detallada del "aprendizaje en línea", consulte la explicación de Chip Huyuen sobreel aprendizaje continuo o este documento técnico de Gomes et. al .
Soporte para arquitectura Kappa
La arquitectura Kappa está reemplazando gradualmente a la arquitectura Lambda debido a problemas de costos y calidad de datos debido al sesgo en línea/fuera de línea. Aunque muchos artículos analizan las ventajas de pasar de capas separadas de procesamiento por lotes y en tiempo real a una única capa en tiempo real, los artículos no suelen describir cómo diseñar la capa de servicio.
El uso de la arquitectura Kappa para generar características trae algunas consideraciones nuevas:
- Las características de actualización se actualizan en masa y pueden generar una cantidad significativa de escrituras en la base de datos. Es importante asegurarse de que la latencia de las consultas no sufra durante estas grandes actualizaciones.
- La capa de servicio aún necesita admitir diferentes tipos de consultas, incluidas consultas de baja latencia para inferencia y consultas de alto TPS para entrenamiento por lotes de modelos.
Cassandra es compatible con la arquitectura Kappa de las siguientes maneras:
- Cassandra está diseñado para escrituras; una mayor afluencia de escrituras no reduce significativamente la latencia de las consultas. Cassandra opta por procesar las escrituras con consistencia final en lugar de consistencia sólida, que suele ser aceptable para hacer predicciones.
- Con CDC, los datos se pueden replicar en el almacenamiento de objetos para entrenamiento y almacenamiento en memoria para inferencia. CDC tiene poco impacto en la latencia de las consultas a Cassandra.
Compatibilidad con la arquitectura Lambda
La mayoría de las empresas tienen una arquitectura Lambda, con una canalización de capa por lotes que está separada de la canalización en tiempo real. Hay varias categorías de características en este escenario:
- Funciones que solo se calculan en tiempo real y se replican en el almacén de funciones por lotes para el entrenamiento
- Funciones que solo se calculan por lotes y se replican en el almacén de funciones en tiempo real
- Las características se calculan primero en tiempo real y luego se vuelven a calcular en el lote. Luego, las discrepancias se actualizan tanto en tiempo real como en el almacén de objetos.
En este escenario, sin embargo, DataStax recomienda la arquitectura como se describe en esta ilustración:
Las razones son las siguientes:
- Cassandra está diseñado para realizar cargas por lotes de datos con poco impacto en la latencia de lectura
- Al tener un único sistema de registro, la gestión de datos se vuelve significativamente más fácil que si los datos se dividen entre el almacén de características y el almacén de objetos. Esto es especialmente importante para las características que primero se calculan en tiempo real y luego se vuelven a calcular por lotes.
- Al exportar datos de Cassandra a través de CDC al almacén de funciones de objetos, la exportación de datos se puede optimizar para el entrenamiento por lotes (un patrón común utilizado en empresas como Facebook ), lo que reduce significativamente los costos de infraestructura de entrenamiento.
Si no es posible actualizar las canalizaciones existentes, o si existen razones específicas por las que las características deben estar primero en el almacén de objetos, nuestra recomendación es optar por una ruta de CDC bidireccional entre el almacén de características de Cassandra y el almacén de objetos, como ilustrado a continuación.
Garantice la compatibilidad con el ecosistema de software de ML existente
Para usar Cassandra como una tienda de funciones, debe integrarse con dos partes del ecosistema: bibliotecas de aprendizaje automático que realizan inferencia y capacitación, y bibliotecas de procesamiento de datos que realizan la transformación de funciones.
Los dos marcos más populares para el aprendizaje automático son TensorFlow y PyTorch. Cassandra tiene controladores de Python que permiten una fácil recuperación de características de la base de datos de Cassandra; en otras palabras, se pueden obtener varias funciones en paralelo ( consulte este código de ejemplo ). Los dos marcos más populares para realizar la transformación de funciones son Flink y Spark Structured Streaming . Los conectores para Flink y Spark están disponibles para Cassandra. Los profesionales pueden usar tutoriales para Flink and Spark Structured Streaming y Cassandra.
Las tiendas de funciones de código abierto como FEAST también tienen un conector y un tutorial para Cassandra.
Comprender los patrones de consulta y el rendimiento para determinar los costos
El número de consultas de lectura para Cassandra como almacén de características depende del número de solicitudes de inferencia entrantes. Suponiendo que los datos de la característica se dividen en varias tablas, o si los datos se pueden cargar en paralelo, esto debería dar una estimación del despliegue entre la inferencia en tiempo real que se puede realizar. Por ejemplo, 200 características en 10 entidades en 10 tablas separadas le brindan una proporción de 1:10 entre la inferencia en tiempo real y las consultas a Cassandra.
El cálculo del número de inferencias que se realizan dependerá del patrón de tráfico de inferencias. Por ejemplo, en el caso de la "inferencia de transmisión", se realizará una inferencia cada vez que cambie una característica relevante, por lo que el número total de inferencias depende de la frecuencia con la que cambien los datos de la característica. Cuando la inferencia se realiza en una configuración de "solicitud-respuesta", solo se realiza cuando un usuario lo solicita.
Comprenda los patrones de escritura por lotes y en tiempo real para determinar los costos
El rendimiento de escritura está dominado principalmente por la frecuencia con la que cambian las características. Si ocurre una desnormalización, esto también podría afectar la cantidad de funciones que se escriben. Otras consideraciones de rendimiento de escritura incluyen el almacenamiento en caché de inferencias para escenarios de inferencia por lotes o de transmisión.
Conclusión
Al diseñar una canalización de ML en tiempo real, se debe prestar especial atención al rendimiento y la escalabilidad del almacén de funciones. Los requisitos son particularmente bien satisfechos por las bases de datos NoSQL como Cassandra. Instale su propia tienda de funciones con Cassandra o AstraDB y pruebe Feast.dev con el conector Cassandra .
L O A D I N G
. . . comments & more!
. . . comments & more!
