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

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 : 

• Permettre aux données financières de DoorDash d'être interrogeables en stockant les données dans des fichiers Parquet - par Rini Vasan
• Accélérer la productivité des développeurs en construisant un débogueur de livraison - par Peyton Chen
• Optimiser les initiatives de notification push - par William Louis 
• Envoi de notifications Mx Banking pour éviter la désactivation - par Amrita Rajan¬†

Permettre l'interrogation des données financières de DoorDash en stockant les données dans des fichiers Parquet

Par Rini Vasan

Alors que l'activité de DoorDash connaît une croissance exponentielle, nous devons enregistrer avec précision les changements qui affectent les finances, mais la difficulté réside dans le fait que ces changements sont distribués dans différents domaines et à travers différents flux. Par exemple, la soumission d'une commande touche un client, un Dasher (notre nom pour les livreurs), un commerçant, un paiement et un retrait. Aujourd'hui, ces changements sont saisis dans des systèmes à entrée unique qui sont sujets aux erreurs et difficiles à réconcilier. La mutabilité des données, les longs intervalles entre les changements et les corrections de données posent de nombreux problèmes. L'équipe de la plateforme de revenus (RP) tente d'atténuer ces problèmes en fournissant des mécanismes d'enregistrement des transactions financières d'une manière conforme et vérifiable, qui se prête à la comptabilité et à l'établissement de rapports.

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énement 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

Actuellement, Archiver stocke les données à l'aide d'un code personnalisé qui suit un cycle de vie spécifique. Tout d'abord, l'événement est ingéré et les données sont lues et agrégées en différents attributs tels que l'heure d'ingestion ainsi que d'autres spécificités de l'événement lui-même. Toutes ces données et les données brutes de l'événement lui-même sont encodées et stockées dans un objet de classe. Ensuite, les données sont lues et poussées dans AWS S3 via les API de S3. 

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 pousser ces données 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 

L'un des plus grands défis de l'équipe de la plateforme logistique est qu'elle est propriétaire de nombreux services critiques avec des dépendances en aval qui s'appuient sur ces services comme sources de vérité, en particulier ceux qui concernent les informations de livraison et les informations d'affectation de la livraison au casier. Lorsque les livraisons se déroulent mal, l'extraction d'informations à partir de ces sources de vérité est généralement la première étape de l'identification des causes profondes. Cependant, en dehors des requêtes manuelles sur les bases de données à travers de multiples sources de données distinctes, il y a actuellement un manque de ressources dans le débogage des problèmes de production - un point douloureux pendant les pannes. Nous décrirons ici comment nous avons construit un nouvel outil interne dans le cadre de notre objectif d'excellence opérationnelle et de qualité.

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.

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

Nous constatons déjà l'adoption de l'outil, l'amélioration de la productivité des développeurs étant estimée entre 5 et 10 % lors de la résolution des problèmes. En fin de compte, le résultat le plus important que nous avons commencé à obtenir est de donner l'exemple à d'autres équipes sur l'importance et la valeur d'un outil interne qui peut aider les développeurs à identifier des modèles rapidement et de manière autonome avec des livraisons problématiques. De nombreuses équipes ont déjà exprimé leur volonté de continuer à intégrer leurs services au débogueur de livraisons ou de créer des outils similaires. Nous espérons avoir ouvert la voie à de meilleurs outils de débogage des problèmes de production, ce qui nous permettra de continuer à nous développer et à devenir le meilleur fournisseur de services logistiques du dernier kilomètre au monde.

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. Cependant, 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

L'équipe chargée des notifications au sein de l'organisation de croissance de DoorDash a effectué une analyse et a découvert que des millions d'utilisateurs avaient un statut d'abonnement aux notifications invalide ou nul. L'équipe a pu réabonner 88 % de ces utilisateurs désabonnés aux notifications push des applications mobiles, laissant un grand nombre d'utilisateurs désabonnés (les 12 % restants). Nous souhaitons que le plus grand nombre possible d'utilisateurs soient abonnés, car les utilisateurs désabonnés ne reçoivent pas les messages marketing qui leur permettraient de rester engagés sur notre plateforme et de continuer à utiliser nos services. Dans l'application mobile, il existe un centre de préférences pour les notifications (voir figure 1) qui peut aider ces utilisateurs à s'abonner, se désabonner et se réabonner aux notifications de DoorDash. Cependant, cette fonction nécessite davantage de travail manuel de la part de l'utilisateur et comme l'obsession du client est l'un de nos principes fondamentaux, nous voulons rendre le processus d'abonnement aussi automatisé que possible.

L'initiative "push prompt

L'équipe chargée des notifications souhaitait créer une stratégie permettant aux utilisateurs de s'abonner facilement aux notifications de DoorDash. Nous voulions que les utilisateurs disposent d'une méthode automatisée pour être informés de tous les avantages que nous leur offrions afin qu'ils s'engagent sur notre plateforme. Cette stratégie consistait à mettre en avant les avantages de l'abonnement tout en fournissant un accès facile à ces processus d'abonnement en un seul clic, ce qui était plus pratique que d'utiliser le centre de notifications de l'application. 

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'inscrire ou à quitter la feuille. Plusieurs flux de travail peuvent être exécutés par l'intermédiaire de cette feuille inférieure.

Comment nous avons mis en place la fonction "push prompt

La mise en œuvre technique de notre fonction d'invitation à pousser dans l'application iOS impliquait que les API EnablePushNotificationsDeeplinkHandler, PushRegistrationService et les API de niveau système iOS fonctionnent toutes ensemble (voir figure 5). EnablePushNotificationsDeeplinkHandler gère les URL d'action de la bannière en rendant la feuille de bas de page. En plus de la présentation, le gestionnaire s'occupe également des clics sur les boutons et utilise PushRegistrationService pour déterminer le flux. Si un flux de travail nécessite la vérification des paramètres au niveau du système, PushRegistrationService s'interface avec l'API des paramètres au niveau du système. 

Résultats

Notre équipe d'analystes a pu effectuer une analyse et prédire que le placement de la bannière de notification sur la page du Hub d'offres contribuerait à une augmentation de 15 % du nombre d'utilisateurs qui choisiront de s'abonner aux notifications d'applications lorsqu'ils visiteront l'une des pages ciblées. Nous avons également analysé le placement de la bannière d'invitation à pousser sur la page de commande et, jusqu'à présent, nos expériences ont révélé une augmentation de 27,5 % des taux d'acceptation de poussée pour les clients qui visitent la page. Ces deux fonctionnalités ont été déployées sur l'application iOS pour des tests A/B. D'ici quatre semaines, nous espérons conclure que les augmentations de nos messages push sur les indicateurs de consommation sont statistiquement significatives.

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 ?

Lorsque les commerçants saisissent leurs informations bancaires lors de l'inscription, l'organisme de paiement ne vérifie pas immédiatement les informations afin d'éviter les retards. Lors d'un examen ultérieur, si le processeur détermine que les informations d'un commerçant ne sont pas valides, les paiements du commerçant peuvent être bloqués. Au bout d'un certain temps, si ces problèmes ne sont pas résolus, le compte du commerçant sera finalement désactivé. 

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 vérifier manuellement le portail pour s'apercevoir 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

Pour mettre en œuvre cette fonctionnalité, nous devrions disposer d'informations sur les paiements et les informations bancaires d'un commerçant dans le service d'accueil. Le service d'intégration appartient à l'équipe chargée de la sélection et de l'intégration des commerçants. Il héberge les opérations relatives à l'intégration des commerçants. 

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.

Nous avons mis en place une intégration Kafka dans le service d'accueil. Kafka est un type de flux d'événements qui nous permet de traiter des données en temps réel. Le service de paiement produit un sujet Kafka - ou un type d'événement - qui contient toutes les informations nécessaires sur le statut de vérification actuel d'un commerçant. La mise en place d'une intégration Kafka dans le service d'onboarding nous permet de lire les informations du service de paiement, établissant ainsi une connexion entre les deux 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.

Chaque fois que nous recevons un événement Kafka ou des informations sur les données financières d'un commerçant, nous les traitons. Nous analysons différents champs afin de déterminer si le commerçant est vérifié ou non. S'il ne l'est pas, nous lui envoyons des courriels récurrents pour lui rappeler de consulter son portail et de mettre à jour ses informations. En revanche, s'il est vérifié, nous cessons de lui envoyer des courriels. Afin d'envoyer ces courriels de manière proactive, nous utilisons Cadence, un flux de travail qui exécute une séquence d'activités.

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.