Una reducción del 80% en el tiempo de cálculo de audiencia estándar

Audiences es una de las herramientas más flexibles, poderosas y fuertemente aprovechadas dentro de la plataforma mParticle. Los usuarios de mParticle pueden definir audiencias en función de los datos relacionados con el usuario capturados de cualquier fuente, ya sea una entrada estándar como una aplicación web, iOS o Android, o un feed de socios.

Una vez que se crean las audiencias, puede reenviarlas fácilmente a los socios de activación posteriores para potenciar una amplia variedad de casos de uso, como impulsar la participación de los usuarios y las descargas de aplicaciones o visualizar los recorridos de los clientes, por nombrar solo algunos.

Dado que Audiences es fundamental para el valor que los clientes obtienen de mParticle, este conjunto de características es una prioridad alta cuando se trata del trabajo de optimización del rendimiento. Esta es la razón por la que recientemente se llevó a cabo un proyecto para revisar las audiencias estándar, un producto que amplía la funcionalidad de las audiencias regulares.

Este artículo analiza cómo llevamos a cabo investigaciones sobre áreas potenciales de optimización, ejecutamos estas oportunidades y evaluamos los resultados.

¿Qué es el público estándar?

los Audiencias estándar La característica de la plataforma mParticle le permite definir y crear audiencias en función de los datos históricos de los usuarios, que se almacenan en Amazon S3, el almacén de datos a largo plazo de mParticle.

Dado que las audiencias estándar se basan en eventos que los clientes realizan durante un largo período de tiempo, son muy útiles para dirigirse a subconjuntos de usuarios que han demostrado un alto valor de por vida.

¿Cómo se calculan las audiencias estándar?

Los cálculos de audiencia estándar utilizan el mismo motor de audiencia que las audiencias en tiempo real. La principal diferencia radica en cómo se alimentan el perfil de usuario y los datos de eventos en el motor de audiencia.

El cálculo de audiencia en tiempo real es un trabajo de procesamiento de flujo que lee eventos de usuario en tiempo real de un flujo. Por otro lado, el cálculo de audiencia estándar es un trabajo por lotes que lee desde S3.

Un trabajo por lotes típico de Standard Audience necesita leer muchos terabytes (hasta unos pocos petabytes) de datos de S3. Como tal, es obvio que necesitamos dividir todo el trabajo en partes más pequeñas y procesarlas al mismo tiempo.

Un trabajo por lotes de audiencia estándar se puede representar como un DAG (gráfico acíclico dirigido) que consta de muchas tareas independientes, cada una de las cuales es responsable de calcular la membresía de la audiencia para un pequeño subconjunto de usuarios. Al final, los resultados del cálculo de la audiencia estándar se almacenan en una ubicación única para cada DAG en S3.

Las dependencias de las tareas, el estado de las tareas y las especificaciones de la carga de trabajo de las tareas son administradas por un administrador de trabajos por lotes desarrollado internamente, que utiliza una base de datos MySQL para almacenar el DAG y los datos de las tareas y envía las tareas a AWS Batch para su ejecución.

Identificar oportunidades de optimización

A medida que el uso de audiencias sin conexión y la cantidad de datos de usuario en S3 crecían orgánicamente, notamos que algunos DAG de audiencia estándar grandes que constaban de cientos de miles de tareas podían tardar seis días en finalizar, lo que interrumpía los flujos de trabajo de nuestros clientes, ya que tenían que esperar. durante casi una semana para obtener resultados.

Nos propusimos investigar los cuellos de botella en el sistema y aprender qué podíamos hacer para mejorar el rendimiento. Agregamos más métricas y registros a todos los pasos en la tarea de cálculo de audiencia, y esto es lo que encontramos:

Hallazgo 1: la lógica detrás de las llamadas a la API podría optimizarse

La tarea de cálculo de audiencia realiza llamadas API a un servicio de perfil de usuario y un administrador de trabajos por lotes. Cuando hay muchas llamadas simultáneas, pueden volverse lentas o fallar en la devolución. Cuando una tarea falla, se volverá a intentar hasta cuatro veces.

Dado que un reintento a nivel de tarea implica comenzar una tarea desde el principio, esta es una operación costosa.

Soluciones :

• Vuelva a examinar la lógica de llamadas de la API y realice solo la cantidad mínima de llamadas necesarias.
• Dimensione los servicios/bases de datos externos correctamente para manejar la carga de trabajo en la que incurre el DAG de audiencia estándar más grande.
• Agregue lógica de reintento con retroceso exponencial con jitter a todas las llamadas a la API.

Resultado:

• Reducción del tiempo de ejecución y el costo en un 20%.

Hallazgo 2: el requisito de memoria para las tareas podría reducirse

El requisito de memoria para cada tarea individual (configurado en la definición de trabajo de AWS Batch) es de 30 GB, que se determinó en el peor de los casos.

La mayoría de las tareas no necesitan tanta memoria. Podríamos ejecutar muchas más tareas simultáneamente en el mismo clúster de ECS si podemos reducir el requisito de memoria por tarea.

Soluciones :

• Reduzca el requisito de memoria predeterminado a 7,5 GB y, si una tarea falla porque se quedó sin memoria, vuelva a intentarlo con el doble del requisito de memoria de la ejecución anterior (con un límite de 30 GB).

Resultado:

• Un aumento de 4 veces en la cantidad de tareas que podríamos ejecutar en el mismo clúster de ECS.

  
  

• Un aumento de 2 veces en el rendimiento, lo que reduce el tiempo de ejecución y el costo total de DAG en un 50 %. Es 2x, no 4x porque cuando ejecutamos contenedores 4x con 7,5 GB de memoria cada contenedor en la misma instancia EC2, tardan más en finalizar y un pequeño porcentaje de ellos debe volver a intentarse con más memoria. El resultado final es un aumento de aproximadamente 2 veces en el rendimiento total.

Hallazgo 3: hacer que la lógica de búsqueda de datos sea más eficiente

El rendimiento está limitado por IO. La mayor parte del tiempo se dedica a recuperar datos para el subconjunto de usuarios de los que es responsable una tarea de cálculo de audiencia fuera de línea.

La recuperación de datos consta de dos pasos principales: encontrar los datos y descargarlos. Encontrar datos en S3 significa que ListBucket llama desde muchas tareas simultáneas, lo cual es relativamente rápido pero el tiempo agregado es significativo.

Soluciones :

• Refactorice la lógica de búsqueda de datos de modo que una pequeña cantidad de llamadas S3 ListBucket puedan encontrar los datos para todas las tareas de cálculo de audiencia. Ponga esta lógica en una nueva tarea de la que dependan todas las tareas de cálculo de audiencia.

Resultado:

• Una reducción promedio del 30 % en el tiempo total de ejecución de DAG.

Hallazgo 4: los tamaños de las particiones se pueden ajustar

Usamos instancias puntuales de EC2 en los clústeres de ECS administrados por AWS Batch. Esto significa que podrían ser rescindidos en cualquier momento. Por un lado, queremos que cada tarea individual finalice rápidamente para que cuando se eliminen debido a la finalización de la instancia puntual, no perdamos mucho tiempo de CPU.

Por otro lado, queremos que cada tarea individual sea bastante grande porque la descarga de una mayor cantidad de datos de S3 en una solicitud genera menos gastos generales. Esto significa que se debe ajustar el tamaño de la partición para tareas individuales.

Soluciones :

• Encontrar el tamaño óptimo de partición de tareas individuales a través de experimentos.

Resultado:

• Una reducción del 30% en el tiempo total de ejecución de DAG.

Ahora analicemos los números: (1 - 20 %) (1 - 50 %) (1 - 30 %) (1 - 30 %) = 19,6 %.

Es así como redujimos el tiempo y costo de cálculo de la Audiencia Estándar en un 80%. El resultado es muy notorio. Ahora, la mayoría de los DAG de audiencia estándar finalizan en 10 horas, con un máximo de aproximadamente un día en los DAG de nuestros clientes más importantes.

Invertimos continuamente en la infraestructura que impulsa los resultados de nuestros clientes, lo cual es muy valioso. Además, estos problemas son realmente divertidos de resolver, por ingenieros muy talentosos. Este proyecto estaba en la intersección de Valor, Diversión y Talento, ¡lo cual es muy emocionante!

- Lee Morris, vicepresidente sénior de ingeniería

Optimizaciones basadas en datos

En las soluciones descritas anteriormente, adoptamos un enfoque basado en datos para encontrar los mejores parámetros, como el tamaño de la partición o el requisito de memoria inicial. Específicamente, volvimos a ejecutar varios DAG con diferentes parámetros, extrajimos las métricas de rendimiento y luego comparamos los resultados usando portátiles Jupyter.

No adivinamos. Dejamos que los datos hablen por sí mismos.

Métricas y Monitoreo

Para rastrear el rendimiento y el costo de los DAG de audiencia estándar, agregamos métricas para rastrear eventos escaneados por DAG, bytes leídos por DAG, latencia total por tarea y tiempo invertido por el motor de cálculo de audiencia por tarea, aprovechando el informes de costos automatizados nuestro equipo de servicios de datos construido internamente.

Implementamos dos versiones de estas métricas, una para monitoreo interno y la otra para métricas de cara al cliente. Por ejemplo, para los eventos escaneados por DAG, rastreamos el total real de eventos escaneados por DAG para el monitoreo interno (incluidos los eventos escaneados por tareas fallidas y luego reintentadas) y rastreamos el total de eventos escaneados por ejecuciones de tareas exitosas por DAG para fines de facturación del cliente.

Si se volvieron a intentar algunas tareas dentro de un DAG, esto es algo que debemos saber, pero no debemos cobrar a los clientes el costo de los reintentos.

Al analizar las métricas de rendimiento, pudimos establecer SLO para los DAG de audiencia estándar. Uno de los SLO clave es la latencia total de DAG de 24 horas. Configuramos el monitoreo de DataDog para los SLO para recibir alertas si se exceden.

Trabajo futuro

Después de estas optimizaciones, Standard Audience sigue siendo un trabajo muy vinculado a IO. Creemos que podemos mejorar aún más el rendimiento de las siguientes maneras.

1. Cree mejores índices para los datos de eventos de usuario en S3, reduciendo la cantidad de transferencias de datos.

   
   

2. Agregue puntos de control persistentes a la tarea de cálculo de audiencia estándar para que pueda reanudarse donde se quedó en caso de que se elimine debido a la finalización de la instancia puntual.

   
   

3. Diseñe mejores esquemas de partición para eliminar las particiones activas. Esto dividiría el trabajo en particiones de tamaño más uniforme.

Hacemos que sea fácil comenzar y respaldar el valor que ofrecemos. Es por eso que ofrecemos una prueba gratuita de 30 días líder en la industria y rica en funciones. ¡ Regístrese ahora !