Esta publicación fue coescrita por Mahesh Pasupuleti y Gaurav Shah de Poshmark.

Poshmark es un mercado social líder de estilos nuevos y de segunda mano para mujeres, hombres, niños, mascotas, hogar y más. Al combinar la conexión humana de las compras físicas con los beneficios de escala, facilidad y selección del comercio electrónico, Poshmark hace que comprar y vender sea simple, social y sostenible. Su comunidad de más de 80 millones de usuarios registrados en EE. UU., Canadá, Australia e India está impulsando un futuro más sostenible para la industria de la moda.

Un objetivo importante a lograr para cualquier organización es aumentar los ingresos de primera línea. Los ingresos brutos se refieren al valor total de las ventas de los servicios o productos de una organización. Los dos enfoques principales que emplean las organizaciones para aumentar los ingresos son expandirse geográficamente para ingresar a nuevos mercados y aumentar la participación de mercado dentro de un mercado al mejorar la experiencia del cliente (CX).

Mejorar CX es una guía bien conocida para atraer y retener clientes y, por lo tanto, aumentar la participación de mercado. En esta publicación, compartimos cómo Poshmark mejoró la CX y aceleró el crecimiento de los ingresos mediante el uso de una solución de análisis en tiempo real. Discutimos cómo crear una solución de este tipo usando Secuencias de datos de Amazon Kinesis, Streaming gestionado por Amazon para Kafka (Amazon MSK), Análisis de datos de Amazon Kinesis para Apache Flink; las decisiones de diseño que entraron en la arquitectura; y los beneficios comerciales observados por Poshmark.

Desafío de alto nivel: la necesidad de análisis en tiempo real

Los esfuerzos anteriores en Poshmark para mejorar CX a través de análisis se basaron en el procesamiento por lotes de datos analíticos y su uso diario para mejorar CX. Aunque estos esfuerzos basados ​​en análisis por lotes tuvieron éxito hasta cierto punto, vieron oportunidades para mejorar la experiencia del cliente con personalización en tiempo real y orientación de seguridad durante la interacción del cliente con la aplicación Poshmark. Los conocimientos de los clientes recopilados a partir del análisis por lotes no se pudieron combinar con las actividades actuales de los clientes en tiempo real debido a las latencias involucradas en el enriquecimiento de las actividades actuales con el conocimiento obtenido a través de los procesos por lotes. Por lo tanto, se perdió la oportunidad de ofrecer ofertas personalizadas o exhibir productos basados ​​en las preferencias y comportamientos de los clientes casi en tiempo real, lo que contribuye a una experiencia del cliente mucho mejor. Del mismo modo, también se perdió la oportunidad de detectar el fraude en un segundo, antes de pagar.

Para mejorar la experiencia del cliente, Poshmark decidió invertir en la creación de una plataforma de análisis en tiempo real para habilitar capacidades en tiempo real, como se explica más adelante en esta publicación. Los ingenieros de Poshmark trabajaron en estrecha colaboración con los arquitectos de AWS a través de la Programa de laboratorio de datos de AWS. El laboratorio de datos de AWS ofrece compromisos de ingeniería conjuntos y acelerados entre los clientes y los recursos técnicos de AWS para crear productos tangibles que aceleren las iniciativas de modernización de datos y análisis. El laboratorio de diseño es un compromiso de medio o dos días con el equipo del cliente que ofrece orientación prescriptiva para llegar al diseño óptimo de la arquitectura de la solución antes de embarcarse en la construcción de la plataforma.

Diseño de la arquitectura de la solución a través del proceso de AWS Data Lab

Las partes interesadas comerciales y técnicas de Poshmark y los arquitectos de AWS Data Lab analizaron los requisitos comerciales a corto y largo plazo junto con las capacidades funcionales y no funcionales necesarias para decidir el enfoque de la arquitectura. Revisaron la arquitectura del estado actual y las restricciones para comprender el flujo de datos y los puntos de integración técnica. El equipo conjunto discutió los pros y los contras de varios servicios de AWS que ya existen en la arquitectura actual de Poshmark, así como otros servicios de AWS que pueden cumplir con los requisitos.

Poshmark quería abordar los siguientes casos de uso comercial a través de la plataforma de análisis en tiempo real:

• Sesionización – Poshmark captura tanto los eventos de la aplicación del lado del servidor como los eventos de seguimiento del lado del cliente. Querían usar estos eventos para identificar y analizar las sesiones de los usuarios para rastrear el comportamiento.
• Prevención de registro e inicio de sesión ilegítimos – Poshmark quería detectar y prohibir el registro ilegítimo o eventos de inicio de sesión de bots o tráfico no humano en tiempo real en la aplicación Poshmark.
• traducción de PI – Las direcciones IP presentes en los eventos se traducirán a ciudad, estado y código postal, y se enriquecerán con otra información para implementar servicios de ubicación casi en tiempo real que abarcan funciones relacionadas con la seguridad, así como funciones de personalización.
• Anonimización – Poshmark quería anonimizar los eventos y poner los datos a disposición de los usuarios internos para consultarlos casi en tiempo real.
• Tarjetas personales – El comportamiento del usuario basado en eventos de flujo de clics se puede capturar hasta el último segundo antes de enriquecerlo para personalizarlo y enviarlo al modelo para predecir las recomendaciones.
• Otros casos de uso – Casos de uso adicionales relacionados con agregaciones y casos de uso de inferencia de aprendizaje automático (ML), como la autorización para operar, enumerar la detección de spam y evitar la apropiación de cuentas (ATO), entre otros.

Un patrón común identificado para estos casos de uso fue la necesidad de una canalización de enriquecimiento de datos central para enriquecer los eventos sin procesar entrantes antes de que los datos de eventos se puedan utilizar para el procesamiento comercial real. En el laboratorio de diseño, nos enfocamos en el diseño de canales de enriquecimiento de datos destinados a enriquecer eventos con datos de archivos estáticos, almacenes de datos dinámicos como bases de datos, API o dentro del mismo flujo de eventos para los casos de uso de transmisión antes mencionados. Más adelante en esta publicación, cubrimos los puntos más destacados discutidos durante el laboratorio sobre diseño y arquitectura.

Arquitectura de la solución de análisis por lotes

El siguiente diagrama muestra la arquitectura anterior en Poshmark. Para abreviar, solo se explica el flujo correspondiente a la plataforma de análisis en tiempo real.

Las interacciones de los usuarios en las aplicaciones web y móviles de Poshmark generan eventos del lado del servidor. Estos eventos incluyen agregar al carrito, pedidos, transacciones y más en los servidores de aplicaciones, y la vista de página, los clics y más en los servidores de seguimiento. fluido con un Kinesis amazónica El complemento está configurado tanto en la aplicación como en los servidores de seguimiento para enviar estos eventos a Secuencias de datos de Amazon Kinesis. El complemento Fluentd Kinesis agrega eventos antes de enviarlos a Kinesis Data Streams. Actualmente se configura un solo flujo de datos de Kinesis para capturar estos eventos. Se configura una clave de partición aleatoria en Fluentd para los eventos a fin de permitir una distribución uniforme de eventos entre fragmentos. El formato de datos del evento es JSON anidado. Poshmark mantiene la misma gramática de esquema en el primer nivel de JSON para los eventos del servidor del lado del servidor y del lado del cliente. Los atributos en el nivel anidado pueden diferir entre los eventos del lado del servidor y del lado del cliente.

Poshmark recibe alrededor de mil millones de eventos por día (1 millones por hora durante las horas pico, 100 millones por hora durante las horas no pico). El tamaño medio del registro de eventos es de 10 KB.

Dos aplicaciones consumen los datos del flujo de datos de Kinesis:

• Una aplicación de transmisión Spark en EMR de Amazon se utiliza para escribir datos del flujo de datos de Kinesis en un lago de datos alojado en Servicio de almacenamiento simple de Amazon (Amazon S3) de forma particionada. Los datos del lago de datos S3 se utilizan para procesamiento por lotes y análisis a través de Amazon EMR y Desplazamiento al rojo de Amazon.
• Druid alojado en Nube informática elástica de Amazon (Amazon EC2) se integra con el flujo de datos de Kinesis para la ingestión de transmisión y permite a los usuarios ejecutar consultas OLAP segmentadas. Los paneles operativos están alojados en Grafana integrado con Druid.

Mejoras deseadas a la solución inicial

Los casos de uso discutidos durante las sesiones de arquitectura caen en una o más combinaciones de los siguientes requisitos de procesamiento de flujo:

• Procesamiento de eventos sin estado – Por ejemplo, anonimización casi en tiempo real.
• búsqueda externa – Consultar un valor de almacenes externos. Por ejemplo, dirección IP, ciudad, código postal, estado o identificación.
• Procesamiento de datos con estado – Acceder a eventos pasados ​​o agregaciones o inferencias de ML.

Para cumplir con estos requisitos, la plataforma de transmisión se divide en dos capas:

• Enriquecimiento de datos centrales – Esta capa ejecuta los enriquecimientos comúnmente requeridos por las aplicaciones de transmisión descendente. Esto ayudará a evitar la replicación de la misma lógica de enriquecimiento en cada aplicación y permitirá un mejor mantenimiento operativo. El enriquecimiento debe aspirar al procesamiento por registro en la mayoría de los casos.
• Aplicaciones de transmisión específicas – Esta capa albergará aplicaciones de transmisión específicas con respecto a los casos de uso y utilizará datos enriquecidos de la canalización central de enriquecimiento de datos.

Para el enriquecimiento central de datos, realizamos las siguientes mejoras en la plataforma:

• La latencia total, incluida la ingesta y el enriquecimiento de datos, era muy crítica y debería estar en el rango de latencia de milisegundos de dos dígitos según el presupuesto de latencia general de Poshmark para lograr respuestas de ML en tiempo real a los eventos. Kafka logró la latencia de ingestión más baja y el equipo decidió optar por la versión administrada de Kafka, Amazon MSK.
• Del mismo modo, también se requiere un procesamiento de datos de baja latencia y, en consecuencia, se debe considerar el marco apropiado.
• Se requerían garantías de entrega exactamente una vez para evitar la duplicación de datos que resultara en cálculos erróneos.
• La fuente de enriquecimiento podría ser cualquier fuente, como archivos estáticos, bases de datos y API, y las latencias pueden variar entre ellos. Se generan una serie de eventos del lado del servidor y del lado del cliente cuando un usuario interactúa con una aplicación de Poshmark. Como resultado, se requiere la misma información de la fuente de enriquecimiento para enriquecer cada evento. Esta información de acceso frecuente almacenada en caché centralizada optimizará el tiempo de recuperación.

Decisiones de diseño para la nueva solución.

Poshmark tomó las siguientes decisiones de diseño para el enriquecimiento de datos central:

• Kafka puede admitir una latencia de milisegundos de dos dígitos del productor al consumidor con el ajuste de rendimiento adecuado. Kafka puede proporcionar semántica exactamente una vez tanto en aplicaciones de productores como de consumidores. AWS proporciona Kafka como parte de su oferta de Amazon MSK, lo que elimina la sobrecarga operativa de mantener y ejecutar la infraestructura de clústeres de Kafka en AWS, lo que le permite concentrarse en desarrollar y ejecutar aplicaciones basadas en Kafka. Poshmark decidió usar Amazon MSK para sus requisitos de almacenamiento e ingesta de transmisión.
• También decidimos usar Flink para aplicaciones de enriquecimiento de datos de transmisión por las siguientes razones:
  • Flink puede proporcionar un procesamiento de baja latencia incluso con un mayor rendimiento con garantías exactamente una vez. Spark Structured Streaming, por otro lado, puede proporcionar baja latencia con bajo rendimiento debido al procesamiento basado en microlotes. El procesamiento continuo de Spark Structured Streaming es una característica experimental y proporciona al menos una vez garantías.
  • La llamada de solicitudes de enriquecimiento a una tienda externa si se modela en una función de mapa (API de mapa de Spark o API MapFunction de Flink) realizará llamadas sincrónicas a la tienda externa. La llamada esperará una respuesta del almacenamiento externo antes de procesar el próximo evento, lo que aumentará las demoras y reducirá el rendimiento general. La interacción asíncrona permitirá enviar solicitudes y recibir respuestas simultáneamente desde tiendas externas. Esto reducirá el tiempo de espera y mejorará el rendimiento general. Soportes Flink E/S asíncrona operadores de forma nativa, lo que permite a los usuarios utilizar clientes de solicitud asíncrona con flujos de datos. La API maneja la integración con los flujos de datos, así como el manejo del orden, la hora del evento, la tolerancia a fallas y más. Spark Structured Streaming no proporciona ningún tipo de soporte de forma nativa y deja que los usuarios lo implementen de forma personalizada.
    
  • Poshmark seleccionó Kinesis Data Analytics para Apache Flink para ejecutar la aplicación de enriquecimiento de datos. Kinesis Data Analytics para Apache Flink proporciona la infraestructura subyacente para sus aplicaciones de Apache Flink. Maneja capacidades básicas como el aprovisionamiento de recursos de cómputo, cómputo paralelo, escalado automáticoy copias de seguridad de aplicaciones (implementadas como puntos de control e instantáneas).
• Un microservicio de enriquecimiento que acompaña Amazon ElastiCache para Redis se configuró para abstraer el acceso de las aplicaciones de enriquecimiento de datos. La función AsyncFunction en el operador de E/S asíncrona de Flink no tiene subprocesos múltiples y no funcionará de una manera verdaderamente asíncrona si la llamada está bloqueada o esperando una respuesta. El microservicio de enriquecimiento maneja las solicitudes y respuestas de manera asincrónica provenientes de los operadores de E/S asíncrona de Flink. Los datos también se almacenan en caché en ElastiCache para Redis para mejorar la latencia del microservicio.
• Las aplicaciones de Poshmark ML son los consumidores de estos datos enriquecidos. El equipo ha creado e implementado diferentes modelos de ML a lo largo del tiempo. Estos modelos incluyen un algoritmo de aprendizaje para clasificar, detección de fraude, personalización y recomendaciones, y filtrado de spam en línea. Anteriormente, para implementar cada modelo en producción, el equipo de Poshmark tenía que pasar por una serie de pasos de configuración de la infraestructura que implicaban la extracción de datos de fuentes en tiempo real, la creación de funciones agregadas en tiempo real a partir de datos de transmisión, el almacenamiento de estas funciones en una latencia baja. base de datos (Redis) para inferencias de submilisegundos y, finalmente, realizar inferencias a través de Amazon SageMaker puntos finales alojados.
• También diseñamos una canalización de almacenamiento de características de ML que consume datos de las fuentes de transmisión enriquecidas (Kinesis o Kafka), genera características de un solo nivel y de nivel agregado, e ingiere estas características generadas en un repositorio de almacenamiento de características con una latencia muy baja de menos de 80 milisegundos.
• Los modelos ML ahora pueden extraer las funciones necesarias con una latencia de menos de 10 milisegundos del repositorio de funciones y realizar inferencias de modelos en tiempo real.

Arquitectura de solución de análisis en tiempo real

El siguiente diagrama ilustra la arquitectura de la solución para análisis en tiempo real con Amazon MSK y Kinesis Data Analytics para Apache Flink.

El flujo de trabajo es el siguiente:

1. Los usuarios interactúan en la aplicación web o móvil de Poshmark.
2. Los eventos del lado del servidor se capturan en los servidores de aplicaciones y los eventos del lado del cliente se capturan en los servidores de seguimiento. Estos eventos se escriben en el clúster de MSK descendente.
3. Los eventos sin procesar se incorporarán al clúster de MSK mediante el complemento Fluentd para generar datos para Kafka.
4. El microservicio de enriquecimiento consta de API de búsqueda de enriquecimiento reactivas (asincrónicas) que obtienen datos de almacenes de datos persistentes. ElastiCache para Redis almacena en caché los datos a los que se accede con frecuencia, lo que reduce el tiempo de recuperación para las API de búsqueda de enriquecimiento.
5. La aplicación Flink que se ejecuta en Kinesis Data Analytics para Apache Flink consume eventos sin procesar de Amazon MSK y ejecuta el enriquecimiento de datos por registro. La aplicación de enriquecimiento de datos de Flink utiliza la E/S asíncrona de Flink para leer datos externos del almacén de búsqueda de enriquecimiento para enriquecer eventos de transmisión.
6. Los eventos enriquecidos se escriben en el clúster de MSK bajo diferentes temas de eventos enriquecidos.
7. La aplicación de transmisión de Spark existente consume del tema de eventos enriquecidos (o tema de eventos sin procesar) en Amazon MSK y escribe los datos en un lago de datos S3.
8. La ingestión de transmisión de Druid ahora lee el tema de eventos enriquecidos o el tema de eventos sin procesar en Amazon MSK, según los requisitos.

Enriquecimiento de los datos de eventos capturados

En esta sección, discutimos los diferentes pasos para enriquecer los datos de eventos capturados.

Procesamiento de enriquecimiento

Kinesis Data Analytics para Apache Flink proporciona la infraestructura subyacente para las aplicaciones de Apache Flink. Maneja capacidades básicas como el aprovisionamiento de recursos informáticos, computación paralela, escalado automático y copias de seguridad de aplicaciones (implementadas como puntos de control e instantáneas). Puede utilizar las características de programación de alto nivel de Flink (como operadores, funciones, fuentes y sumideros) de la misma manera que las utiliza cuando aloja la infraestructura de Flink usted mismo.

Flink en Amazon EMR brinda la flexibilidad de elegir su versión, instalación, configuración, instancias y almacenamiento de Flink. Sin embargo, también debe ocuparse de la gestión del clúster y los requisitos operativos, como el escalado, la copia de seguridad de las aplicaciones y el aprovisionamiento.

Almacén de búsqueda de enriquecimiento

La función AsyncFunction en el operador de E/S asíncrona de Flink no tiene subprocesos múltiples y no funcionará de una manera verdaderamente asíncrona si la llamada está bloqueada o esperando una respuesta. La API de búsqueda de enriquecimiento debe manejar las solicitudes y respuestas de forma asíncrona provenientes de los operadores de E/S asíncrona de Flink. La API de búsqueda de enriquecimiento se puede alojar en Amazon EC2 o en contenedores como Servicio de contenedor elástico de Amazon (Amazon ECS) o Servicio Amazon Elastic Kubernetes (Amazon EKS).

Se generan una serie de eventos del lado del servidor y del lado del cliente cuando un usuario interactúa con una aplicación de Poshmark. Como resultado, se requiere la misma información para enriquecer cada evento. Esta información de acceso frecuente almacenada en un caché centralizado puede optimizar el tiempo de recuperación. La latencia de la memoria caché centralizada se puede reducir aún más alojando el cliente (API de búsqueda de enriquecimiento) y el servidor de memoria caché en la misma zona de disponibilidad.

Conciliación en caso de errores de canalización

El enriquecimiento de eventos puede fallar en las aplicaciones de enriquecimiento de datos por varios motivos, como que se agote el tiempo de espera del almacén externo o que falte información en el almacén. Los campos enriquecidos pueden o no ser críticos para las aplicaciones de flujo descendente. Debe crear sus aplicaciones de transmisión descendente teniendo en cuenta que estos errores pueden ocurrir e implementar un mecanismo de respaldo, por ejemplo, volver a intentar el enriquecimiento bajo demanda desde la aplicación. El manejo de fallas también se regirá por la tolerancia de latencia de la aplicación.

El procesamiento de datos se basa en el tiempo del evento. En algunas situaciones, los datos pueden llegar tarde a la plataforma. Tanto Flink como Spark permiten retrasos y marcas de agua para que los usuarios manejen los datos que llegan tarde mediante la definición de umbrales. Los datos que llegan tarde más allá del umbral se descartan del procesamiento. Es posible obtener estos datos descartados demasiado tarde en Flink usando una salida lateral. No existe tal disposición en Spark Structured Streaming.

Algunas aplicaciones de transmisión requieren que su contraparte por lotes reconcilie los datos por hora o por día para manejar la falta de coincidencia o discrepancia de datos debido a datos que llegan tarde o faltan datos.

Mejora de la experiencia del cliente

La nueva arquitectura en tiempo real ofreció los siguientes beneficios para mejorar la experiencia del cliente:

• Anonimización – Poshmark ahora puede proporcionar y utilizar datos anonimizados en tiempo real para múltiples funciones tanto internas como externas porque la anonimización ocurre en tiempo real.
• Mitigación de fraude – Poshmark anteriormente pudo detectar y prevenir el 45 % de los ATO con la solución basada en lotes. Con el sistema en tiempo real, Poshmark puede prevenir el 80 % de las ATO.
• Personalización – Al proporcionar resultados de búsqueda personalizados, Poshmark logró una mejora del 8 % en las tasas de clics para la búsqueda. Este es un aumento significativo en la parte superior del embudo, lo que aumenta las conversiones de búsqueda en general.

La mejora en estos tres factores ayudó a los clientes finales a ganar confianza en la aplicación y el sitio web de Poshmark, lo que a su vez permitió a los clientes aumentar su interacción con la aplicación y ayudó a acelerar el crecimiento y la participación de los clientes.

Conclusión

En esta publicación, discutimos la ingestión de flujo de clics en tiempo real y datos de eventos de registro en Amazon MSK. Mostramos cómo se puede realizar el enriquecimiento de los datos capturados a través de Kinesis Data Analytics para Apache Flink. Dividimos el procesamiento de enriquecimiento en varios componentes, como Kinesis Data Analytics para Apache Flink, los microservicios de enriquecimiento y el almacén de búsqueda de enriquecimiento, y un caché de enriquecimiento. Discutimos las aplicaciones posteriores que usaron esta información enriquecida del cliente para realizar controles de seguridad en tiempo real y ofrecer recomendaciones personalizadas a los usuarios finales. También discutimos algunas de las áreas que pueden necesitar atención en caso de que haya fallas en la tubería. Por último, mostramos cómo Poshmark mejoró la experiencia de sus clientes y ganó participación de mercado al implementar esta canalización de análisis en tiempo real.

Sobre los autores

Mahesh Pasupuleti es vicepresidente de ingeniería de datos y aprendizaje automático en Poshmark. Ha ayudado a varias empresas emergentes a tener éxito en diferentes dominios, incluida la transmisión de medios, la atención médica, el sector financiero y los mercados. Le encanta la ingeniería de software, la creación de equipos de alto rendimiento y la estrategia, y disfruta de la jardinería y jugar al bádminton en su tiempo libre.

Gaurav Shah es Director de Ingeniería de Datos y ML en Poshmark. Él y su equipo ayudan a crear soluciones basadas en datos para impulsar el crecimiento en Poshmark.

Raghu Mannam es Arquitecto de Soluciones Sr. en AWS en San Francisco. Trabaja en estrecha colaboración con nuevas empresas en etapa avanzada, muchas de las cuales han tenido OPI recientes. Su enfoque es la solución de extremo a extremo, incluida la seguridad, la automatización de DevOps, la resiliencia, el análisis, el aprendizaje automático y la optimización de la carga de trabajo en la nube.

Deepesh Malviya es Solutions Architect Manager en el equipo de AWS Data Lab. Él y su equipo ayudan a los clientes a diseñar y crear soluciones de datos, análisis y aprendizaje automático para acelerar sus iniciativas clave como parte del laboratorio de datos de AWS.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/big-data/accelerating-revenue-growth-with-real-time-analytics-poshmarks-journey/