Ir al contenido

Blog


2022 Summer Intern Projects Artículo nº 3

4 de abril de 2023

|
Rini Vasan

Rini Vasan

Peyton Chen

Peyton Chen

Guillermo Luis

Guillermo Luis

Amrita Rajan

Amrita Rajan

DoorDash ofrece a nuestros becarios de verano la oportunidad de integrarse plenamente con los equipos de ingeniería para obtener el tipo de experiencia real en el sector que no se enseña en las aulas. Esta es la tercera entrada en el blog de una serie de artículos que muestran nuestros proyectos de prácticas de verano 2022. Si te perdiste el primero o el segundo artículo, los enlaces están aquí y aquí. A continuación puedes leer sobre cada proyecto.

Contenido: 

Enabling DoorDash's Financial Data to be Queryable by Storing Data in Parquet Files

By Rini Vasan

As DoorDash's business grows exponentially we need to accurately record the changes that affect financials, but the challenge is that these changes are distributed throughout different domains and across various flows. For example, an order submission will touch a customer, a Dasher (our name for delivery drivers), a merchant, a pay-in, and a payout. Today these changes are entered as single entry systems that are prone to errors and difficult to reconcile. There are various challenges with respect to data mutability, long intervals between changes, and data fixes. The Revenue Platform (RP) team is attempting to mitigate these issues by providing mechanisms for recording financial transactions in a compliant and auditable way that is amenable to accounting and reporting.

Existen múltiples microservicios (Aggregator, Reprocessor, Archiver, Workflow) para la plataforma de ingresos que trabajan en tándem para lograr nuestro objetivo, pero este post se centrará en el trabajo del servicio Archiver. El objetivo principal de Archiver es recoger eventos que contengan datos de transacciones financieras enviados por diferentes equipos ascendentes y almacenar estos datos en un lago de datos. En la actualidad, estos datos se conservan con fines de auditoría y para utilizarlos en caso de corrección de cualquier dato contable.

Problemas con los datos almacenados actualmente en Archiver

Actualmente, para consultar y leer los eventos en bruto, utilizamos una aplicación llamada Reprocessor, que recoge los datos de eventos almacenados por Archiver y los envía para su reprocesamiento por la plataforma. Archiver es una aplicación flink que escucha múltiples eventos diferentes en temas kafka. Los datos de eventos se almacenan en AWS S3 en un formato codificado en archivos JSON. Después de que el flujo de trabajo procesa los datos, podemos consultar los eventos desde la base de datos cockroachDB, que DoorDash utiliza como solución de base de datos, y el almacén de datos Snowflake para ver los resultados finales del procesamiento. Tras el reprocesamiento, podemos descodificar y leer los datos de eventos almacenados por archiver para su reprocesamiento. 

Sin embargo, cuando se utiliza un cuaderno web de análisis de datos para analizar los archivos JSON, los datos no son decodificables, lo que significa que no se pueden consultar. Estos datos no decodificables hacen que nos resulte mucho más difícil comprender los datos almacenados por el archivador. Al no poder leer los datos de eventos hasta después del procesamiento del flujo de trabajo, otros equipos que utilicen estos datos tendrán que esperar a que el equipo de la plataforma de ingresos incorpore los eventos al flujo de trabajo y a que aparezcan en la base de datos cockroachDB. Este proceso provoca retrasos cuando los equipos crean eventos nuevos o modificados, ya que no existe una forma sencilla de verificar los datos de los eventos nuevos o actualizados, lo que ralentiza considerablemente el lanzamiento de nuevas funciones y la experimentación.

Cómo consultar los datos almacenados en Archiver

Currently, Archiver stores the data with a lot of custom code that follows a specific lifecycle. First, the event is ingested and the data is read and aggregated into different attributes such as the ingestion time as well as other specifics about the Event itself. All of this data and the raw event data itself is encoded and stored in a class object. Next, the data is read and pushed into AWS S3 through S3's APIs. 

Con los nuevos cambios en el archivador, en lugar de almacenar los datos en un formato JSON codificado, almacenamos los datos de eventos en formato parquet con un esquema definido por tipo de evento. La razón por la que elegimos utilizar el formato parquet en lugar de JSON es porque el formato parquet es consultable de forma nativa por muchas herramientas de análisis diferentes, como los cuadernos Apache Spark basados en web con funcionalidad analítica sin necesidad de decodificación. Sin embargo, si siguiéramos utilizando JSON, no podríamos leer o consultar directamente sin pasar por todo el ciclo de vida descrito anteriormente, lo que lleva mucho tiempo. 

Para implementar los cambios descritos anteriormente, leemos los datos de eventos que llegan directamente y los agregamos a un objeto de clase similar como se describe en el ciclo de vida anterior. A continuación, utilizamos un conector de Flink llamado Streaming File Sink para convertir los datos en formato parquet y enviarlos directamente a S3 sin necesidad de código personalizado para el ciclo de vida completo. Streaming File Sink toma la ruta de salida, que sería la ruta de S3 para almacenar los datos y un objeto escritor de parquet. En S3, almacenamos los archivos parquet por evento en una carpeta por hora. 

Con estos nuevos cambios descritos anteriormente, los detalles específicos de un evento se pueden escribir en formato parquet, que se puede consultar de forma nativa a través de cuadernos Spark sin necesidad de decodificación ni de utilizar bibliotecas específicas de la plataforma Revenue. Una vez que los datos del evento se envían a producción, podemos permitir que otros equipos consulten los datos directamente sin tener que esperar a que la aplicación de flujo de trabajo los procese.

Repercusiones de la actualización del archivador 

Ahora que podemos consultar los datos almacenados por el archivador, ayuda a los ingenieros a alertar, supervisar y depurar cualquier problema que pueda surgir de otras aplicaciones implicadas en el ciclo de vida completo de la plataforma de ingresos. Esto permite reducir la sobrecarga de trabajo de los desarrolladores y las horas de desarrollo para muchos problemas. Ahora ahorramos dos días de trabajo a los desarrolladores cuando obtienen detalles sobre nuevos eventos de las aplicaciones de origen. Antes, estos dos días se habrían empleado en incorporar los nuevos eventos a todos los servicios de la plataforma de ingresos. Sin embargo, ahora podemos verificar los eventos al instante y ya no es necesario esperar. Además, ahora podemos abrir la consulta de los cuadernos Spark a otros equipos. Por lo tanto, el impacto del archivador actualizado permite ahora a otros equipos, incluso a los que no son de ingeniería, como los de Contabilidad o Auditoría, consultar los eventos y verificar todos los cambios por sí mismos, lo que aumenta significativamente la velocidad de lanzamiento de nuevas funciones.

Acelerar la productividad de los desarrolladores creando un depurador de entregas

Por Peyton Chen 

One of the largest challenges of the logistics platform team is that we are the owner of numerous critical services with downstream dependencies relying on these services as sources of truth, especially those surrounding delivery information and delivery-to-Dasher assignment information. When deliveries do unfortunately go wrong, pulling information from these sources of truth is typically the first step of identifying root causes. However, outside of manual database queries across multiple distinct data sources, there is currently a lack of resources in debugging production issues - a pain point during outages. Here, we will describe how we built a new internal tool as part of our goal for operational excellence and quality.

Problemas con los métodos actuales de recopilación de datos para depuración

Hay algunas razones clave que motivan la creación de esta herramienta: 

  • Dependemos de nuestra base de código heredada, que estamos abandonando activamente, para ejecutar consultas a la base de datos. 
  • Las herramientas de atención al cliente pueden ser útiles y proporcionar cierta información, pero a menudo se abstraen de las principales fuentes de verdad y no están orientadas a los ingenieros.
  • Ejecutar consultas en nuestro almacén de datos es una posibilidad, pero no en tiempo real.
  • Las bases de datos de producción son sensibles y no permiten uniones, por lo que es necesario recurrir a soluciones provisionales, ya que la información crítica está repartida entre muchas tablas diferentes.
  • Las consultas manuales son lentas y requieren mucha experiencia
  • A menudo, otros ingenieros envían a nuestro equipo simples solicitudes de recopilación de datos que tardamos en responder, lo que se traduce en un mayor tiempo medio de resolución y consume recursos de ingeniería innecesarios.

Construcción del depurador

Nuestro nuevo depurador es una plataforma de autoservicio y un panel de información para proporcionar una agregación convincente de datos y poner de relieve las incoherencias de datos con el objetivo de abordar todas las preocupaciones anteriores. Se aloja como un plugin en un sitio web de herramientas internas adaptado a DoorDash y basado en Backstage de Spotify. La versión actual del depurador muestra agrupaciones lógicas con campos similares que ofrecen una visión de cómo se representa una entrega en la base de datos, tal y como se muestra en la figura 1. La característica más importante es que ofrece una visualización de cada mutación en el objeto de entrega a medida que se desplaza desde su creación hasta su entrega u otro estado terminal, como se muestra en la figura 2. Los datos se suministran desde un punto final gRPC que creamos leyendo de una base de datos que refleja cada vez que se envía un evento kafka desde el tema kafka que rastrea todos los eventos que encuentra una entrega. También se ofrece el historial de asignaciones con la información asociada de Dasher, la información del turno y la ruta del turno, como se muestra en la Figura 3.

Figura nº 1: Se proporcionan agrupaciones lógicas de datos en la base de datos junto con prácticos enlaces a otras herramientas y filtros.
Figura nº 1: Se proporcionan agrupaciones lógicas de datos en la base de datos junto con prácticos enlaces a otras herramientas y filtros.
Figura nº 2: Para cada evento de una entrega, se proporciona una vista detallada que indica qué campos de la base de datos de la entrega han cambiado como parte de este evento.
Figura nº 2: Para cada evento de una entrega, se proporciona una vista detallada que indica qué campos de la base de datos de la entrega han cambiado como parte de este evento.
Figura nº 3: Para cada entrega, se proporciona una vista detallada de cada asignación que asume una entrega, así como el Dasher y el turno asociados a la asignación.
Figura nº 3: Para cada entrega, se proporciona una vista detallada de cada asignación que asume una entrega, así como el Dasher y el turno asociados a la asignación.

Además de proporcionar vistas prácticas, tenemos previsto desarrollar un sólido conjunto de restricciones y una visualización de los casos de violación de restricciones, que indican posibles errores en la representación de una entrega. También queremos disponer de un cuadro de mandos que sugiera entregas a las que prestar atención, como las que incumplen las reglas de restricción mencionadas o los 100 pedidos más retrasados de los últimos 30 días, por citar dos ejemplos. 

Impacto

We are already seeing adoption of the tool, with developer productivity improvement estimated to be in the 5-10% region when troubleshooting. Ultimately, the biggest result we have begun to achieve is setting an example for other teams on the importance and value of internal tooling that can help developers identify patterns quickly and autonomously with problematic deliveries. Multiple teams have already expressed commitment for continuing to integrate their services with the delivery debugger or create similar tools. We anticipate to have paved the way for better tools to debug production issues, allowing us to continue to grow and be the world's best last-mile logistics provider.

Manténgase informado con las actualizaciones semanales

Suscríbase a nuestro blog de ingeniería para estar al día de los proyectos más interesantes en los que trabaja nuestro equipo.

Optimización de las iniciativas de avisos de notificaciones push

Por William Louis 

DoorDash tiene muchas promociones, ofertas y otros tratos que ofrecemos a nuestro grupo de consumidores. Hacemos publicidad para involucrar a nuestros usuarios tanto como sea posible en nuestra plataforma. Un método para notificarles estas ventajas es a través de correos electrónicos. Sin embargo, es más probable que los usuarios consulten las notificaciones de su aplicación y se enteren por ahí. Pedir a los usuarios que activen sus notificaciones nos permite llegar a ellos en relación con estos beneficios más fácilmente. 

Problema con nuestro grupo de usuarios no suscritos

The notifications team under the DoorDash growth organization conducted analysis and found that millions of users had an invalid or null notification subscription status. The team was able to re-subscribe 88% of these unsubscribed users to mobile application push notifications, leaving a large number of users unsubscribed (the remaining 12%). We want as many users as possible to be subscribed since unsubscribed users do not receive the marketing pushes that would keep them engaged on our platform and with our services. Within the mobile application, there exists a notification preference center (see Figure 1) that can help these users subscribe, unsubscribe, and re-subscribe to DoorDash notifications. However, this feature requires more manual work on the user's part and as being customer-obsessed is one of our core principles, we want to make the subscription process as automated as possible.

Figura 1: El centro de preferencias de notificaciones que existe dentro de la página de la cuenta.
Figura 1: El centro de preferencias de notificaciones que existe dentro de la página de la cuenta.

La iniciativa "push prompt

The notifications team wanted to create a strategy that allowed users to easily subscribe to DoorDash notifications. We wanted users to have an automated method of getting notified of all the benefits that we offered to them in order for them to be engaged on our platform. This strategy involved advocating the benefit of the subscription while providing easy access to these subscription workflows in a single click which was more convenient than using the app's notifications center. 

Figura 2: Banners de aviso en las páginas de Ofertas y Pedidos
Figura 2: Banners de aviso en las páginas de Ofertas y Pedidos

La iniciativa de avisos push consistió en añadir artefactos de avisos push en partes clave del recorrido del usuario. Estas partes clave incluían las páginas centrales de pedidos y ofertas, y se añadieron banners a estas páginas en la aplicación para iOS (véase la figura 2). Estas dos páginas tienen una gran cantidad de impresiones diarias, por lo que decidimos que sería un buen enfoque colocar estos banners aquí para llegar a los millones de usuarios que no se habían suscrito a las notificaciones.

Cómo creamos los avisos push

Al hacer clic en el banner, el flujo de trabajo hará que se muestre una hoja inferior (véanse las figuras 3 y 4). En la hoja inferior, hay botones para suscribirse o descartar la hoja. Hay varios flujos de trabajo que pueden ejecutarse a través de esta hoja inferior.

Figura 3: Este flujo implica que el usuario se suscriba a las notificaciones.
Figura 3: Este flujo implica que el usuario se suscriba a las notificaciones.
Figura 4: En este flujo, el usuario se da de baja de las notificaciones.
Figura 4: En este flujo, el usuario se da de baja de las notificaciones.

Cómo implementamos la función de avisos push

The engineering implementation of our push prompt feature in the iOS application involved the EnablePushNotificationsDeeplinkHandler, PushRegistrationService, and iOS system level APIs all working together (see Figure 5). The EnablePushNotificationsDeeplinkHandler handled the banner's action URLs by rendering the bottomsheet. Along with presentation, the handler also handled the button clicks and would utilize PushRegistrationService to take care of flow determination. If any workflow required checking system level settings, then PushRegistrationService would interface with the system level settings API. 

Figure 5: The end-to-end walkthrough of the feature’s behavior
Figure 5: The end-to-end walkthrough of the feature's behavior

Resultados

Our analytics team was able to conduct analysis and predict that the notification banner placement in the Offers Hub page would contribute to a 15% uplift on the number of users that will opt into subscribing to App notifications upon visiting one of the targeted pages. We also did some analysis for the order page push prompt banner placement, and so far, our experiments read that there is a 27.5% uplift in push opt-in rates for customers visiting the page. Both of these features have been rolled out on the iOS application for A/B testing. Within 4 weeks, we hope to conclude that our push prompts' uplifts on consumer metrics to be statistically significant.

Envío de notificaciones de Mx Banking para evitar la desactivación

Por Amrita Rajan

Uno de los retos para garantizar que los comerciantes tengan una experiencia de incorporación a DoorDash sin problemas es recopilar información bancaria precisa. Si cualquier información bancaria se añade incorrectamente, puede causar la desactivación o la frustración general. En este artículo, hablaremos de cómo mitigar este problema mediante la creación de notificaciones en torno a la información bancaria de los comerciantes utilizando Kafka y Cadence.

Por qué necesitamos notificar explícitamente a los comerciantes

When merchants input their banking information during onboarding, the payment processor does not immediately verify the information in order to prevent delays. Upon later review, if the processor determines that a merchant has invalid information, the merchant's payouts can become blocked. After a certain period, if these issues are not resolved, the merchant's account will ultimately become deactivated. 

Actualmente, la página de banca del portal del comerciante muestra un banner de alerta si hay algún error o falta información. Aunque útil, esta función no es eficaz para resolver el problema porque el comerciante no recibe ninguna alerta y, por tanto, tendría que comprobar manualmente el portal para saber que algo va mal. Los comerciantes sólo reciben un correo electrónico después de desactivar su cuenta, lo que puede ser demasiado tarde para resolver el problema.

En última instancia, esta falta de notificaciones puede perturbar la experiencia del comerciante y debería rectificarse. Si los comerciantes se encuentran en un estado no verificado, el enfoque actual de alertas en banners les retrasa a la hora de activarse en DoorDash y podría desanimarles a unirse por completo. El envío directo de correos electrónicos permite a los comerciantes ser proactivos a la hora de corregir su información.

Obtención de la información de pago del procesador de pagos

In order to implement this feature, we would need to have information about a merchant's payment and banking information in the onboarding service. The onboarding service is owned by the Merchant Selection and Onboarding Team. It houses operations pertaining to merchant onboarding. 

Figura 1: Diagrama de la arquitectura del proyecto que muestra la relación entre el procesador de pagos, el servicio de pagos y el servicio de integración.
Figura 1: Diagrama de la arquitectura del proyecto que muestra la relación entre el procesador de pagos, el servicio de pagos y el servicio de integración.

Como se muestra en la Figura 1, el procesador de pagos envía webhooks al servicio de pagos. Los webhooks son mensajes automatizados que contienen información pertinente y que se envían cuando se produce un evento. Un evento en este escenario sería si un comerciante actualiza su página bancaria o cualquier otra actividad financiera.

We set up a Kafka integration in onboarding service. Kafka is a type of event streaming that enables us to process data in real time. Payment service produces a Kafka topic - or a type of event - that contains all of the necessary information about a merchant's current verification status. Setting up a Kafka integration in onboarding service allows us to read information from payment service, thus, establishing a connection between the two services.

Configurar el flujo de trabajo para enviar correos electrónicos

Tras recibir la información del servicio de pago, la siguiente etapa consiste en enviar realmente los correos electrónicos en el servicio de onboarding.

Figura 2: Diagrama de flujo de la lógica de envío de correos electrónicos a los comerciantes
Figura 2. Diagrama de flujo Diagrama de flujo que muestra la lógica de envío de correos electrónicos a los comerciantes

Each time we receive a Kafka event or information about a merchant's financial information, we process it. We parse various fields in order to decipher whether or not a merchant is verified. If they are not verified, we send them recurring emails that remind them to check their portal and update their information. However, if they are verified, we stop the emails. In order to proactively send these emails, we use Cadence, a workflow that executes a sequence of activities.

Impacto

Tras la puesta en marcha de la función de notificación por correo electrónico, los comerciantes que corran el riesgo de ser desactivados recibirán correos electrónicos recordatorios. A diferencia de lo que ocurre con las alertas en banners, de este modo la información no válida se resolverá antes y con mayor eficacia. El éxito del proyecto puede medirse por la disminución del número de comerciantes desactivados debido a datos bancarios incorrectos.

About the Authors

  • Rini Vasan

    Rini Vasan is a senior at UC Berkeley majoring in Computer Science and minoring in Data Science. During her DoorDash SWE internship, she was on the Revenue Platform team.

  • Peyton Chen

    Peyton is a senior at Stanford University studying computer science and music. During his DoorDash internship, he worked on the Logistics Platform team.

  • Guillermo Luis

    Hi, my name is William Louis, and I am an incoming senior at UC Berkeley studying Computer Science. This summer, I was able to work in the Growth organization under the New User Experience and Notifications team.

  • Amrita Rajan

    Amrita Rajan is senior at UC Berkeley majoring in Computer Science and Data Science, with an emphasis in Applied Mathematics and Modeling. She was on the Merchant Selection and Onboarding Team during her internship.

Trabajos relacionados

Ubicación
Seattle, WA; Sunnyvale, CA; San francisco, CA
Departamento
Ingeniería
Ubicación
San Francisco, CA; Sunnyvale, CA; Los Ángeles, CA; Seattle, WA; Nueva York, NY
Departamento
Ingeniería
Ubicación
San Francisco, CA; Sunnyvale, CA; Los Ángeles, CA; Seattle, WA; Nueva York, NY
Departamento
Ingeniería
Ubicación
New York, NY; San Francisco, CA; Los Angeles, CA; Seattle, WA; Sunnyvale, CA
Departamento
Ingeniería
Ubicación
Toronto, ON
Departamento
Ingeniería