Skip to content

Blog


2022 Projets des stagiaires d'été Article n°3

4 avril 2023

|
Rini Vasan

Rini Vasan

Peyton Chen

Peyton Chen

William Louis

William Louis

Amrita Rajan

Amrita Rajan

DoorDash offre à ses stagiaires d'été l'opportunité de s'intégrer pleinement aux équipes d'ingénierie afin d'acquérir le type d'expérience industrielle réelle qui n'est pas enseignée dans les salles de classe. Ce billet est le troisième d'une série d'articles présentant les projets de nos stagiaires de l'été 2022. Si vous avez manqué le premier ou le deuxième article, les liens sont ici et ici. Vous pouvez lire chaque projet ci-dessous.

Contenu : 

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.

Il existe plusieurs microservices (Aggregator, Reprocessor, Archiver, Workflow) pour la plateforme de revenus qui travaillent en tandem pour atteindre notre objectif, mais ce billet se concentrera sur le travail du service Archiver. L'objectif principal d'Archiver est de récupérer les événements contenant des données de transactions financières envoyées par différentes équipes en amont et de stocker ces données dans un lac de données. Ces données sont actuellement conservées à des fins d'audit et pour être utilisées en cas de correction des données comptables.

Problèmes avec les données stockées dans Archiver actuellement

Actuellement, pour interroger et lire les événements bruts, nous utilisons une application appelée Reprocessor, qui récupère les données d'événements stockées par Archiver et les envoie pour retraitement par la plateforme. Archiver est une application flink qui écoute plusieurs événements différents sur des sujets kafka. Les données d'événements sont stockées dans AWS S3 dans un format encodé dans des fichiers JSON. Une fois que le flux de travail a traité les données, nous pouvons interroger les événements de la base de données cockroachDB, qui est utilisée par DoorDash comme solution de base de données, et l'entrepôt de données Snowflake pour voir les résultats finaux du traitement. Après le retraitement, nous sommes en mesure de décoder et de lire les données d'événements stockées par l'archiveur pour le retraitement. 

Toutefois, lorsqu'on utilise un bloc-notes en ligne pour l'analyse des données afin d'analyser les fichiers JSON, les données ne sont pas décodables, ce qui signifie qu'elles ne peuvent pas être interrogées. Ces données non décodables rendent beaucoup plus difficile la compréhension des données stockées par l'archiveur. En ne pouvant lire les données d'événements qu'après le traitement du flux de travail, les autres équipes qui utilisent ces données devront attendre que l'équipe Revenue Platform intègre les événements au flux de travail et qu'ils apparaissent dans la base de données cockroachDB. Ce processus entraîne des retards lorsque les équipes construisent des événements nouveaux ou modifiés, car il n'y a pas de moyen facile de vérifier les données dans les événements nouveaux ou mis à jour, ce qui ralentit considérablement le lancement de nouvelles fonctionnalités et l'expérimentation.

Rendre les données stockées dans Archiver interrogeables

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. 

Avec les nouveaux changements apportés à l'archiveur, au lieu de stocker les données dans un format JSON encodé, nous avons stocké les données d'événements au format parquet avec un schéma défini par type d'événement. La raison pour laquelle nous avons choisi d'utiliser le format parquet au lieu de JSON est que le format parquet est nativement interrogeable par de nombreux outils d'analyse différents tels que les carnets Apache Spark basés sur le web avec une fonctionnalité analytique sans aucun besoin de décodage. Cependant, si nous continuions à utiliser JSON, nous ne serions pas en mesure de lire ou d'interroger directement les données sans passer par l'ensemble du cycle de vie décrit ci-dessus, ce qui prend beaucoup de temps. 

Pour mettre en œuvre les changements décrits ci-dessus, nous avons lu les données d'événements qui nous parviennent directement et les avons agrégées dans un objet de classe similaire, comme décrit dans le cycle de vie ci-dessus. Nous avons ensuite utilisé un connecteur de Flink appelé Streaming File Sink pour convertir les données au format parquet et les pousser directement vers S3 sans avoir besoin d'un code personnalisé pour le cycle de vie complet. Streaming File Sink prend en charge le chemin de sortie qui serait le chemin S3 pour stocker les données et un objet d'écriture de parquet. Dans S3, nous avons stocké les fichiers parquet par événement dans un dossier par heure. 

Avec les nouveaux changements décrits ci-dessus, les détails spécifiques d'un événement peuvent être écrits au format parquet, qui est nativement interrogeable par les notebooks Spark sans avoir besoin de décodage ou d'utiliser des librairies spécifiques à Revenue Platform. Une fois que les données d'un événement sont poussées vers la production, nous pouvons permettre à d'autres équipes d'interroger les données directement sans attendre que l'application de workflow les traite.

Impact de l'archiveur mis à niveau 

Maintenant que nous sommes en mesure d'interroger les données stockées par l'archiveur, cela aide les ingénieurs à alerter, surveiller et déboguer tout problème qui pourrait survenir dans d'autres applications impliquées dans le cycle de vie complet de la plateforme de revenus. Cela permet de réduire les frais généraux des développeurs et les heures de développement pour de nombreux problèmes. Nous économisons maintenant deux jours de travail pour les développeurs lorsqu'ils obtiennent des détails sur de nouveaux événements en amont. Auparavant, ces deux jours auraient été utilisés pour intégrer les nouveaux événements dans tous les services de la plateforme de revenus. Cependant, nous pouvons désormais vérifier instantanément les événements et l'attente n'est plus nécessaire. De plus, nous sommes maintenant en mesure d'ouvrir la requête Spark notebooks à d'autres équipes. Par conséquent, l'impact de l'archiveur mis à niveau permet maintenant à d'autres équipes, même à des équipes qui ne sont pas des ingénieurs, comme les équipes de comptabilité ou d'audit, d'interroger les événements et de vérifier elles-mêmes tous les changements, ce qui augmente considérablement la vitesse de lancement des nouvelles fonctionnalités.

Accélérer la productivité des développeurs en créant un débogueur de livraison

Par 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.

Problèmes liés aux méthodes actuelles de collecte de données pour le débogage

Quelques raisons essentielles ont motivé la création de cet outil : 

  • Nous nous appuyons sur notre ancien code, que nous sommes en train d'abandonner, pour exécuter les requêtes de la base de données. 
  • Les outils d'assistance à la clientèle peuvent être utiles et fournir certaines informations, mais ils font souvent abstraction des principales sources de vérité et ne sont pas orientés vers l'ingénieur.
  • Il est possible d'exécuter des requêtes sur notre entrepôt de données, mais ce n'est pas du temps réel.
  • Les bases de données de production sont sensibles et ne permettent pas les jointures, ce qui nécessite des solutions de contournement car les informations critiques sont réparties entre de nombreuses tables différentes.
  • Les requêtes manuelles sont lentes et requièrent beaucoup d'expérience
  • D'autres ingénieurs adressent souvent à notre équipe de simples demandes de collecte de données qui prennent du temps à répondre, ce qui allonge le délai moyen de résolution et consomme des ressources d'ingénierie inutiles.

Construire le débogueur

Notre nouveau débogueur est une plateforme en libre-service et un tableau de bord permettant d'agréger les données de manière convaincante et de mettre en évidence les incohérences des données afin de répondre à toutes les préoccupations susmentionnées. Il est hébergé en tant que plugin sur un site web d'outils internes adapté à DoorDash et basé sur Backstage de Spotify. La version actuelle du débogueur affiche des groupements logiques avec des champs similaires, ce qui permet de voir comment une livraison est représentée dans la base de données, comme le montre la figure 1. La plus grande caractéristique est d'offrir un affichage de chaque mutation sur l'objet de livraison au fur et à mesure qu'il est créé, jusqu'à ce qu'il soit livré ou dans un autre état terminal, comme le montre la figure 2. Les données sont fournies par un point d'extrémité gRPC que nous avons créé et qui lit une base de données qui reflète chaque fois qu'un événement kafka est envoyé depuis le sujet kafka qui suit tous les événements qu'une livraison rencontre. L'historique des affectations est également proposé avec les informations associées sur le Dasher, l'équipe et l'itinéraire de l'équipe, comme le montre la figure 3.

Figure 1 : Des regroupements logiques de données dans la base de données ainsi que des liens pratiques vers d'autres outils et filtres sont fournis.
Figure 1 : Des regroupements logiques de données dans la base de données ainsi que des liens pratiques vers d'autres outils et filtres sont fournis.
Figure 2 : Pour chaque événement d'une livraison, une vue détaillée est fournie, indiquant les champs de la base de données de la livraison qui ont été modifiés dans le cadre de cet événement.
Figure 2 : Pour chaque événement d'une livraison, une vue détaillée est fournie, indiquant les champs de la base de données de la livraison qui ont été modifiés dans le cadre de cet événement.
Figure n° 3 : Pour chaque livraison, une vue détaillée est fournie pour chaque mission qu'une livraison prend en charge, ainsi que le Dasher et l'équipe associés à la mission.
Figure n° 3 : Pour chaque livraison, une vue détaillée est fournie pour chaque mission qu'une livraison prend en charge, ainsi que le Dasher et l'équipe associés à la mission.

En plus de fournir des vues pratiques, nous avons l'intention de développer un ensemble robuste de contraintes et un affichage pour les cas de violation de contraintes, indiquant des bogues potentiels dans la représentation d'une livraison. Nous avons également l'intention d'avoir un tableau de bord qui suggère des livraisons à examiner - comme celles qui ne respectent pas les règles de contrainte susmentionnées ou les 100 commandes les plus en retard au cours des 30 derniers jours, pour ne citer que deux exemples. 

Impact

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.

Restez informé grâce aux mises à jour hebdomadaires

Abonnez-vous à notre blog d'ingénierie pour recevoir régulièrement des informations sur les projets les plus intéressants sur lesquels notre équipe travaille.

Optimiser les initiatives de notification push

Par William Louis 

DoorDash propose de nombreuses promotions, offres et autres deals à ses consommateurs. Nous faisons de la publicité pour engager nos utilisateurs autant que possible sur notre plateforme. L'une des méthodes pour les informer de ces avantages est l'envoi de courriels. Toutefois, les utilisateurs sont plus susceptibles de consulter les notifications de leur application et d'en apprendre davantage à partir de là. Le fait d'inviter les utilisateurs à activer leurs notifications nous permet de les informer plus facilement de ces avantages. 

Problème avec notre groupe d'utilisateurs désinscrits

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.

Figure 1 : Le centre de préférences des notifications qui existe dans la page du compte.
Figure 1 : Le centre de préférences des notifications qui existe dans la page du compte.

L'initiative "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. 

Figure 2 : Les bannières de push prompt sur les pages du Hub des Offres et des Commandes
Figure 2 : Les bannières de push prompt sur les pages du Hub des Offres et des Commandes

L'initiative de push prompt a consisté à ajouter des artefacts de push prompt dans des parties clés du parcours de l'utilisateur. Ces parties clés comprenaient les pages centrales des commandes et des offres, et des bannières ont été ajoutées à ces pages sur l'application iOS (voir Figure 2). Ces deux pages enregistrent un très grand nombre d'impressions quotidiennes. Nous avons donc décidé qu'il serait judicieux de placer ces bannières à cet endroit afin de toucher les millions d'utilisateurs qui n'ont pas souscrit aux notifications.

Comment nous avons développé les fonctionnalités de push prompt

Lorsque l'on clique sur la bannière, le flux de travail déclenche l'affichage d'une feuille inférieure (voir les figures 3 et 4). Dans la feuille inférieure, des boutons invitent à s'abonner ou à quitter la feuille. Plusieurs flux de travail peuvent être exécutés par l'intermédiaire de cette feuille inférieure.

Figure 3 : Ce flux implique que l'utilisateur s'abonne à des notifications.
Figure 3 : Ce flux implique que l'utilisateur s'abonne à des notifications.
Figure 4 : Ce flux implique que l'utilisateur se désabonne des notifications.
Figure 4 : Ce flux implique que l'utilisateur se désabonne des notifications.

Comment nous avons mis en place la fonction "push prompt

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

Résultats

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.

Envoi de notifications Mx Banking pour éviter les désactivations

Par Amrita Rajan

L'un des défis pour s'assurer que les commerçants ont une expérience d'intégration fluide à DoorDash est de collecter des informations bancaires exactes. Si des informations bancaires sont ajoutées de manière incorrecte, cela peut entraîner une désactivation ou une frustration générale. Dans cet article, nous allons discuter de la façon dont nous atténuons ce problème en créant des notifications autour des informations bancaires des commerçants en utilisant Kafka et Cadence.

Pourquoi faut-il informer explicitement les commerçants ?

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. 

Actuellement, la page bancaire du portail des commerçants affiche une bannière d'alerte en cas d'erreur ou d'information manquante. Bien qu'utile, cette fonction n'est pas efficace pour résoudre le problème car le commerçant ne reçoit aucune alerte et doit donc consulter manuellement le portail pour se rendre compte que quelque chose ne va pas. Les commerçants ne reçoivent un courriel qu'après la désactivation de leur compte, ce qui peut être trop tard pour résoudre le problème.

En fin de compte, ce manque de notifications peut perturber l'expérience des commerçants et devrait être rectifié. Si les commerçants sont dans un état non vérifié, l'approche actuelle de la bannière d'alerte les retarde à devenir actifs sur DoorDash et pourrait potentiellement les décourager de s'inscrire. L'envoi direct d'e-mails permet aux commerçants d'être proactifs dans la correction de leurs informations.

Obtention des informations de paiement auprès de l'organisme de paiement

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. 

Figure 1 : Diagramme décrivant l'architecture du projet, montrant la relation entre le processeur de paiement, le service de paiement et le service d'accueil.
Figure 1 : Diagramme décrivant l'architecture du projet, montrant la relation entre le processeur de paiement, le service de paiement et le service d'accueil.

Comme le montre la figure 1, le processeur de paiement envoie des webhooks au service de paiement. Les webhooks sont des messages automatisés contenant des informations pertinentes qui sont envoyés lorsqu'un événement se produit. Dans ce scénario, un événement se produirait si un commerçant mettait à jour sa page bancaire ou toute autre activité financière.

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.

Mise en place d'un flux de travail pour l'envoi de courriels

Après avoir reçu les informations du service de paiement, l'étape suivante consiste à envoyer les courriels dans le service d'accueil.

Figure 2 : Organigramme mettant en évidence la logique d'envoi des courriels aux commerçants
Figure 2 : Organigramme mettant en évidence la logique d'envoi des courriels aux commerçants

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.

Impact

Une fois la fonction de notification par courrier électronique mise en place, les commerçants qui risquent d'être désactivés recevront des courriers électroniques de rappel. Contrairement à l'approche de l'alerte par bannière, cette méthode permettra de résoudre plus rapidement et plus efficacement le problème des informations non valides. Le succès du projet peut être mesuré par la diminution du nombre de commerçants désactivés en raison d'informations bancaires incorrectes.

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.

  • William Louis

    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.

Emplois connexes

Localisation
Seattle, WA; Sunnyvale, CA; San francisco, CA
Département
Ingénierie
Localisation
San Francisco, CA ; Sunnyvale, CA ; Los Angeles, CA ; Seattle, WA ; New York, NY
Département
Ingénierie
Localisation
San Francisco, CA ; Sunnyvale, CA ; Los Angeles, CA ; Seattle, WA ; New York, NY
Département
Ingénierie
Localisation
New York, NY; San Francisco, CA; Los Angeles, CA; Seattle, WA; Sunnyvale, CA
Département
Ingénierie
Localisation
Toronto, ON
Département
Ingénierie