Using Metrics Layer to Standardize and Scale Experimentation at DoorDash

Les mesures sont essentielles pour évaluer le succès de toute entreprise axée sur les données, mais il peut être difficile de s'assurer que ces mesures sont cohérentes et précises dans l'ensemble de l'organisation. La couche métrique, également connue sous le nom de couche sémantique, est un composant essentiel de la pile de données moderne qui a récemment fait l'objet d'une attention particulière de la part de l'industrie et qui offre une solution puissante au défi que représente la normalisation des définitions des mesures. En servant de référentiel centralisé pour les définitions normalisées des mesures commerciales, la couche métrique permet une prise de décision à la fois cohérente et démocratisée. Ces définitions de mesures contiennent la logique utilisée pour calculer les valeurs des mesures qui peuvent ensuite être exploitées pour une gamme de cas d'utilisation analytique, y compris l'expérimentation, l'apprentissage automatique, l'analyse exploratoire et la création de rapports. Les définitions de métriques standardisées permettent également à différents personas tels que les Data Scientists, les ingénieurs et les Product Managers d'utiliser plus facilement les mêmes définitions de métriques et de s'assurer qu'ils mesurent tous les métriques d'une manière cohérente et précise.

Experimentation is one of the primary use cases that relies on metrics. The impact of experiments such as A/B tests and switchback tests is typically assessed by measuring the changes in metrics. A centralized metrics layer ensures accurate and reliable measurement of experiment results and streamlines the analysis process by minimizing the need for ad-hoc analysis. Additionally, having a centralized repository of metrics facilitates easy access to metrics, empowering all members of an organization to analyze experiment results. Experimentation is embedded into DoorDash's product development and growth strategy, and we run a lot of experiments with different features, products, and algorithms to improve the user experience, increase efficiency, and also gather insights that can be used to power future decisions. We have our in-house experimentation analysis platform called Curie, which automates and unifies the process of analyzing experiments at DoorDash. It allows our product teams to quickly iterate on their features by evaluating the impact of experiments on key business metrics using our robust statistical methodologies. 

Construire une couche de métriques qui fonctionne pour l'expérimentation n'est pas simple, car elle doit prendre en charge différents types de métriques d'échelle variable qui sont utilisés dans la gamme variée de tests A/B qui sont exécutés sur différents produits. Dans cet article, nous nous concentrerons sur l'importance de la couche de métriques et sur la façon dont elle peut améliorer l'évolutivité et la rapidité du processus de prise de décision, en discutant de notre parcours de construction d'une couche de métriques pour Curie. Nous nous pencherons également sur nos processus de conception et de mise en œuvre et sur les leçons que nous en avons tirées.

Défis des SQL ad hoc

Our initial goal with Curie was to standardize the analysis methodologies and simplify the experiment analysis process for data scientists. As we mentioned in our previous blog, we began with a 'Bring Your Own SQL' method, in which data scientists checked in ad-hoc Snowflake (our primary data warehouse) SQL files to create metrics for experiments, and metrics metadata was provided as JSON configs for each experiment. This approach provided maximum flexibility for users, as they didn't have to change much in their workflow, and most were already using similar ad-hoc SQLs to manually analyze their experiments.

Cependant, au fur et à mesure de l'adoption de Curie, nous avons rencontré plusieurs autres problèmes liés à notre approche, qui sont abordés ci-dessous :

Manque de normalisation  

Chez DoorDash, plusieurs équipes mènent des expériences pour optimiser un ensemble commun de paramètres commerciaux. Cependant, il n'existait pas de méthode normalisée pour définir les indicateurs, ce qui entraînait des incohérences dans la définition d'un même indicateur par les différentes équipes. L'absence d'une source unique de vérité pour les métriques présentait un risque de décisions commerciales incorrectes. L'approche SQL ad hoc exigeait que les scientifiques des données écrivent leur propre SQL pour définir les mesures, et ces SQL n'étaient ni facilement découvrables ni réutilisables par les autres équipes.

Dépendance à l'égard de la connaissance du domaine

This challenge created a heavy reliance on subject matter experts (SMEs), who have a deep understanding of the metrics and SQL expertise. This dependency created challenges in democratizing metrics, as the required domain knowledge was often siloed within particular teams, and it was not easy for users to identify the relevant tables, columns, or query functions for specific metrics. Dependency on SQL made it challenging for non-technical users to analyze experiments without assistance from data scientists. As a result, product stakeholders were often blocked by the limited data scientists' bandwidth.

Calculs métriques non calculables

L'utilisation de SQL ad hoc pour les calculs métriques dans la plateforme Curie a également posé des problèmes d'évolutivité. Les SQL étaient monolithiques par nature et incluaient de multiples métriques et dimensions, ce qui entraînait des jointures compliquées et des balayages de tables complètes qui ont gravement affecté les performances de notre plateforme. Il y avait trop de calculs redondants, car la même mesure était souvent calculée à plusieurs reprises pour diverses expériences. Cela entraînait des temps d'attente élevés pour les analyses en raison des requêtes coûteuses qui bloquaient nos files d'attente, ce qui était source de frustration pour les utilisateurs et ralentissait en fin de compte leur processus de prise de décision. L'équipe en charge de la plateforme ne disposait que de leviers limités pour améliorer les performances, et l'ajout de ressources était la seule option pour passer à l'échelle supérieure. 

Des résultats peu fiables 

La fiabilité des résultats d'expérience affichés sur Curie suscitait des inquiétudes. L'absence de suivi de la qualité et de la fraîcheur des ensembles de données en amont utilisés dans les définitions des mesures présentait le risque de fonder d'importantes décisions commerciales sur des données obsolètes ou de mauvaise qualité.

Caractéristiques limitées

Les problèmes d'extensibilité ont également entravé la mise en œuvre de fonctions avancées, telles que l'analyse dimensionnelle automatisée pour le découpage des résultats en fonction des attributs qualitatifs. Nous n'avons pas été en mesure de mettre en place des fonctions d'analyse spéciales telles que CUPED pour la réduction de la variance, les vérifications de biais avant l'expérience, et d'autres en raison de ces limitations. Cette limitation a créé des obstacles à notre capacité d'innovation et a finalement entravé notre capacité à tirer davantage de valeur de Curie.

Manque de gouvernance 

Notre plateforme ne disposait pas de politiques de gouvernance pour les définitions des indicateurs. La propriété des mesures n'était pas clairement définie et il n'existait pas de processus formel d'examen ou d'approbation pour les changements de définition. Les métadonnées de chaque mesure étaient incluses dans la configuration de l'expérience et pouvaient être ajustées au niveau de l'analyse, ce qui entraînait des incohérences dans l'utilisation des mesures par les différentes équipes.

Nous avons constaté que les difficultés rencontrées étaient principalement dues à l'absence de normalisation, de centralisation et d'évolutivité de nos calculs de mesures. Pour résoudre ces problèmes, nous avons proposé de créer une couche de mesures centralisée pour l'expérimentation et de repenser entièrement notre cadre de calcul des mesures.

Comment nous avons mis en œuvre les différents piliers de notre couche de métriques

Dans cette section, nous allons approfondir notre approche des différents aspects de la conception de notre couche de métrologie, y compris ses modèles de données de base et son moteur de calcul des métriques.

Modèles de données de base / Sémantique

Nous avons mis l'accent sur l'identification des modèles de données de base les plus complets et les plus efficaces pour permettre aux utilisateurs de créer leurs propres mesures. Nous avons pris en compte plusieurs facteurs clés :

Attributs métriques

Par essence, la définition d'une métrique doit inclure les métadonnées de base, les tables sources, les colonnes de l'entrepôt de données pour récupérer les données et la logique de calcul pour les agrégations et les filtres nécessaires. Les scientifiques des données sont les principaux créateurs de métriques et sont déjà familiarisés avec SQL. Il était donc logique d'utiliser SQL comme langage pour définir les métriques plutôt que de construire notre propre DSL.

Modélisation des données

Notre plateforme exige l'accès aux données au niveau du fait ou de l'événement brut, et pas seulement aux agrégats. Cette exigence nous permet d'effectuer un filtrage précis et une analyse dimensionnelle au niveau de l'événement.

Dimensions

Les dimensions doivent être définies séparément, comme des citoyens de première classe, et ne doivent pas être combinées avec des mesures. Les liens entre les métriques et les dimensions devraient être construits au stade de la consommation pour une flexibilité maximale.

Généralisabilité

L'intégration avec la plateforme Curie était une priorité absolue, mais nous avons également veillé à ce que les concepts d'expérimentation ne fassent pas partie des modèles de données de base, car ils doivent être suffisamment génériques pour être utilisés à l'avenir dans d'autres cas d'utilisation analytique.

Après avoir pris en compte les facteurs susmentionnés et étudié d'autres cadres métriques existants, nous avons décidé d'adopter des modèles de données BI standard. Les utilisateurs définiront les deux modèles suivants : Les sources de données et les métriques.

Sources de données

Une source de données représente un ensemble de données qui peut être représenté par une table ou une instruction SQL SELECT. Elle expose un ensemble de colonnes en tant que mesures ou dimensions.

Mesures

As with standard BI modeling, "measures" refer to quantitative values that represent specific aspects of events or facts. These measures are later aggregated to create metrics. Measures are always defined at the most granular level possible without any aggregations. This level of detail allows the platform to access raw events and perform accurate filtering and dimensional analysis. For example, while evaluating the number of orders metric in an experiment, the platform can automatically count only deliveries made by a user after their time of first exposure to the experiment. Platform can also slice and dice the metric across different dimensional cuts of the deliveries

Un exemple de source définissant des mesures pour les indicateurs de livraison

source:
  name: deliveries
  alias: Delivery Measures
  description: This source contains all the deliveries [including canceled deliveries].
    delivery_id is a primary key for this source and the timestamp is in UTC.
  tags:
    - kpi
  entity_units:
    - name: delivery_id
      primary: true
    - name: consumer_id
  measures:
    - name: n_delivery
      description: Measure for delivery event
    - name: delivery_profit
      description: Profit from deliveries made by a consumer in dollars
    - name: completed_delivery
      description: A delivery which was not canceled
  compute:
    sql: |-
      SELECT
        delivery_id,
        to_char(consumer_id) AS consumer_id,
        1 AS n_delivery,
        CASE WHEN dd.cancelled_at IS NULL THEN 1 END AS completed_delivery,
        profit/100 AS delivery_profit,
        created_at AS event_ts
      FROM prod.public.fact_deliveries
      WHERE event_ts::DATE BETWEEN {{start_date}} AND {{end_date}}
    dependencies:
      - prod.public.fact_deliveries
    look_back_period: 90
  owners:
    - arunkumar

Un exemple de source définissant des mesures pour les indicateurs de livraison

Dimensions

Les dimensions sont les attributs qualitatifs d'un événement ou d'une entité qui peuvent être utilisés pour découper les résultats métriques d'une expérience.

source:
  name: core_consumer_dimensions
  alias: User level Dimensions
  description: Core dimensions for consumers
  entity_units:
    - name: consumer_id
      primary: true
  dimensions:
    - name: country
      description: Consumer's most recent country of app usage
    - name: platform
      description: Device platform where the consumer was last active (ios/android/web)
  compute:
    sql: |-
      SELECT
          to_char(du.consumer_id) AS consumer_id,
          dc.name AS country,
          du.platform AS platform,
          active_dt AS active_date
      FROM proddb.public.dimension_users du
      LEFT JOIN geo.public.dimensions_country dc
          ON du.country_id = dc.id
      WHERE active_date BETWEEN {{start_dt}} AND {{end_date}}
    dependencies:
      - prod.public.dimension_users
      - geo.public.dimensions_country
  owners:
    - arunkumar

Exemple de source définissant les dimensions d'une entité consommateur

Outre les mesures et les dimensions, les sources contiennent également des unités d'entité, qui peuvent être utilisées comme clés de jonction avec d'autres sources ou journaux d'affectation des expériences. Ces unités d'entité comprennent souvent des identifiants tels que consumer_id, dasher_id et delivery_id, qui seront également utilisés comme clés de regroupement ou unités de randomisation pour les expériences. Il comprend également une colonne "timestamp" définie dans son instruction SQL, qui indique soit le timestamp auquel l'événement s'est produit (dans le cas des mesures), soit la date d'activation d'une dimension d'entité. D'autres métadonnées nécessaires au calcul sont également incluses, telles que les dépendances des tables en amont pour l'orchestration, la période de recul pour les calculs incrémentiels, les balises pour la découvrabilité et les identités de propriété.

Métriques

Les métriques sont créées en agrégeant les mesures définies dans la source, et nous prenons en charge différents types de métriques tels que les agrégations normales, les ratios et les métriques à fenêtre. Les utilisateurs peuvent inclure des métadonnées de base et des paramètres d'expérimentation tels que des covariables dans leurs définitions de métriques. Par exemple, dans l'illustration ci-dessous, nous voyons que les prédictions ML sont définies comme covariable pour la réduction de la variance à l'aide de CUPAC. En outre, les utilisateurs peuvent créer des métriques de fenêtre en tant que métriques dérivées en étendant simplement les métriques principales avec des configurations de fenêtre supplémentaires, ce qui facilite la tâche des utilisateurs et permet de capturer la lignée entre la métrique parentale et les métriques dérivées. Par exemple, l'exemple ci-dessous montre comment les utilisateurs définissent une métrique de fenêtre de 7 jours pour analyser comment les utilisateurs se convertissent dans les sept jours suivant leur exposition à une expérience.

metric:
  name: conversion_rate
  alias: Order Rate
  description: number of orders placed within a period
  desired_direction: INCREASE
  spec:
    type: RATIO
    numerator:
      measure: n_checkouts
      aggregation: COUNT
    denominator:
      measure: n_visits
      aggregation: COUNT
  window_metrics:
    - name: conversion_rate_exposure_7d
      window_params:
        window_type: EXPOSURE
        lower_bound: 0
        upper_bound: 7
        window_unit: DAY
  curie_settings:
    covariates:
      - conversion_rate_predictions
  owners:
    - arunkumar

Exemple de définition du ratio de taux de conversion et de la fenêtre de mesure qui en découle

Paternité et gouvernance

La création de métriques implique la création des modèles de base susmentionnés sous forme de fichiers YAML et leur téléchargement sur GitHub pour un contrôle approprié de la source. Ce processus permet aux utilisateurs d'évaluer et de valider facilement les définitions des métriques avant qu'elles ne soient appliquées à une analyse expérimentale. Avec GitHub, nous facilitons un processus de révision rationalisé, garantissant l'exactitude technique et commerciale des définitions.

Les modifications apportées aux modèles font l'objet d'une série de validations automatisées en plus de l'audit manuel. Ces contrôles sont exécutés dans le cadre du processus d'intégration continue (CI) pour les demandes d'extraction, y compris la validation des unités d'entité, les contrôles d'unicité pour les métriques, les dimensions, les sources, et les validations SQL pour confirmer la présence des colonnes de mesure et d'horodatage requises dans l'ensemble de résultats, et plus encore. Ces contrôles de validation sont très utiles pour trouver et signaler les erreurs courantes de l'utilisateur qui pourraient plus tard interrompre les pipelines de calcul. Si la demande d'extraction passe toutes les validations et reçoit l'approbation requise, les définitions mises à jour sont synchronisées avec le système et mises à disposition pour l'analyse des expériences en quelques minutes. Un service interne du GRPC héberge ces définitions et les fournit à la plateforme d'expérimentation et aux pipelines de calcul métrique via l'API, comme le montre la figure 1.

Packs de métriques pour une meilleure gouvernance

We introduced another abstraction called "Metrics Packs," which are standardized collections of metrics. These packs, built and approved by specific teams, simplify the usage and promote standardization of metrics. Teams can construct a standard set of metrics they are interested in, with configurable parameters such as covariates, metric labels, and dimensional cuts, and reuse them across multiple experiments without the need to reconfigure each time. This makes it easier for everyone on the team to quickly identify the metrics they need to monitor and also ensures that experiments are evaluated consistently against standardized and agreed-upon criteria. 

Metrics packs also enable the sharing of metric configurations across different teams and users. For example, both the search and ads teams can use the same metric pack to measure conversion metrics without having to work on the definitions and configurations multiple times. Furthermore, we created core metric packs containing critical company-level metrics that are automatically added to all experiment analyses based on the entity the experiment is randomized on. This ensures that the company's core metrics are consistently monitored for any adverse changes resulting from experiments.

Moteur de calcul des métriques

En plus de la standardisation, une autre raison principale pour laquelle nous avons construit une couche de métriques était d'améliorer l'extensibilité du calcul des métriques pour l'expérimentation. Nos pipelines SQL ad-hoc comprenaient beaucoup de calculs redondants parce que, souvent, chaque métrique sera évaluée dans plusieurs expériences, et ils étaient calculés de manière répétée. Pour relever ce défi, avec la couche métrique, nous avons construit un moteur de calcul personnalisé à partir de la base pour pré-calculer les mesures pour toutes les métriques et réutiliser ces données calculées dans les pipelines d'analyse. En conséquence, nous avons éliminé les balayages de table et les jointures inefficaces, qui sont des opérations gourmandes en ressources sur Snowflake.

Mesures avant le calcul

Notre moteur de calcul des mesures génère dynamiquement des pipelines de données basés sur les modèles créés par les utilisateurs. Pour chaque modèle source, nous créons un job Dagster quotidien pour calculer et matérialiser de manière incrémentale les mesures définies dans ce modèle dans un tableau Snowflake ([A] dans la Figure 3). Le choix d'utiliser Dagster comme moteur d'orchestration a été motivé par ses caractéristiques, telles qu'une approche déclarative de l'orchestration basée sur les actifs de données, des API intuitives pour la construction de pipelines, la prise en charge de l'exécution de backfills à partir de l'interface utilisateur, une architecture multi-tenant native qui permet l'exécution transparente de plusieurs cas d'utilisation, une interface web robuste et une prise en charge puissante de l'API GraphQL, parmi d'autres.

Pour s'assurer que notre pipeline reste à jour, nous avons construit des générateurs de jobs Dagster qui suivent périodiquement les changements apportés à nos modèles à l'aide de nos APIs et construisent ou modifient automatiquement les jobs nécessaires. Les dépendances en amont de tous les travaux sont automatiquement déduites des modèles et orchestrées. Nous générons un capteur Dagster pour chaque travail source qui vérifie périodiquement l'état de la dernière partition des tables en amont et déclenche le travail source correspondant une fois que les partitions de données sont disponibles. Les jobs gèrent également les migrations de bases de données sur Snowflake en créant de nouvelles tables en fonction des types de mesures et d'identifiants définis dans le SQL source, et en ajoutant automatiquement de nouvelles colonnes pour toutes les nouvelles mesures. 

These automations ensure that any changes made to the models are reflected in the data pipelines within minutes without the need for manual intervention. From the user's perspective, this results in a significant increase in velocity, as data scientists can add new metrics and use them in their experiments within minutes, without the support of the infrastructure team. 

Nous avons adopté le paradigme de l'ingénierie fonctionnelle des données en concevant tous nos travaux de manière à ce qu'ils soient idempotents, logiquement partitionnés par dates, et en traitant ces partitions comme immuables. Chaque tâche se voit attribuer un ensemble de partitions qu'elle doit écraser à l'aide de Dagster run-config. Ce modèle permet d'effectuer des remplissages manuels ou automatisés de manière répétée en indiquant la plage de dates requise dans la configuration de l'exécution du travail. En outre, tous les travaux sont conscients de la rétroactivité, et nos travaux quotidiens remplissent automatiquement les données pour les dates antérieures sur la base de la période de rétroactivité définie dans le modèle source. La période de rétrospection est généralement définie par les utilisateurs en fonction du nombre de partitions de dates mises à jour quotidiennement dans les tables en amont. Nous avons également conçu nos pipelines de manière à ce qu'ils s'auto-réparent. Ainsi, lorsqu'un travail ne s'exécute pas certains jours, l'exécution suivante du pipeline tente de rattraper systématiquement le retard et de remplir toutes les données non traitées sur la base de la dernière mise à jour de l'horodatage. Ces étapes garantissent que nos données sont toujours à jour et complètes.

Calcul des métriques et analyse des expériences

Une fois les mesures brutes calculées, notre moteur d'orchestration déclenche les pipelines de données d'agrégation pour les métriques dérivées de ces mesures. À ce stade ([B] dans la figure 3), nous exécutons les pipelines SQL générés automatiquement pour joindre les mesures aux expositions de l'expérience (assignations de variantes de chaque entité de randomisation pour une expérience) pour chaque expérience, puis nous calculons les agrégats pour la métrique découpée par les différentes variantes de l'expérience.

Most of the inferences in our stats engine are performed using the Delta method which operates directly on moment aggregates at the experiment level. This process means that we don't need to move a huge volume of raw data into our platform and instead we can compute the experiment variant level aggregates directly on Snowflake and only fetch the aggregates for our statistical analysis.
We also perform automated variance reduction using CUPED within the platform for all the analyzed metrics. Variance reduction is a process used to increase the power or sensitivity of the experiment and CUPED is a common and powerful variance reduction methodology that uses pre-experimental average metric values as covariates. At this stage, we also compute and fetch the required cross-moment aggregates for the pre-experiment covariates of each metric. The covariates used in CUPED are computed from the same measures and computation logic that were used for the actual metric computation but only with a different time range to get the data for the pre-experiment period. We use a similar time-shifted metric computation to perform pre-experimental bias testing for different experiments to detect any systematic difference in the behavior of the treatment and control groups before the experiment starts.

Impact of implementing a Metrics Layer - Improved Experimentation

• Grâce à nos efforts de normalisation, nous avons permis aux équipes de créer des ensembles standard de mesures qui peuvent être partagées et réutilisées par différentes équipes de manière cohérente. En supprimant l'exigence SQL, nous avons permis aux parties prenantes non techniques d'analyser les tests A/B sans trop de supervision en utilisant nos packs de métriques de base.
• Notre cadre de calcul métrique efficace a permis de diviser par 10 le temps moyen d'analyse des expériences par rapport à notre approche SQL ad hoc précédente, ce qui a permis d'obtenir des résultats plus rapidement.
• Nous avons pu mettre en œuvre de nombreuses fonctionnalités avancées telles que la réduction automatisée de la variance CUPED, la vérification automatisée des biais pré-expérimentaux et l'analyse dimensionnelle, ce qui nous a permis de prendre des décisions plus rapides et plus précises.
• Nous avons amélioré la fiabilité et la qualité globale des résultats de nos expériences en suivant les retards et les défaillances des dépendances en amont et en permettant des contrôles de base de la qualité des données. 

Enseignements tirés de la mise en œuvre d'une couche de métriques pour l'expérimentation

L'éducation des utilisateurs favorise l'adoption 

Afin de promouvoir l'adoption de la couche de métrologie, il est important de sensibiliser les utilisateurs aux avantages des métriques normalisées. Ces avantages peuvent être communiqués par le biais de sessions de formation des utilisateurs et de camps d'entraînement pratiques. En démontrant l'impact de l'amélioration des performances et de la réutilisation des mesures, les utilisateurs en apprécieront pleinement la valeur. En particulier, il est utile de souligner comment les scientifiques des données peuvent bénéficier de la capacité de permettre aux parties prenantes non techniques d'analyser des expériences à l'aide de métriques standard sans avoir besoin de beaucoup d'aide, afin qu'ils puissent consacrer leur temps à d'autres objectifs tels que l'étude des tendances, l'analyse exploratoire pour obtenir des informations, l'élaboration de modèles ML, etc.

La performance est la clé 

Pour encourager les utilisateurs à adopter des mesures standard, il est essentiel que la couche de mesures offre des performances fiables et rapides avec un accès à faible latence. Des performances médiocres peuvent inciter les utilisateurs à opter pour des solutions SQL ad hoc. En donnant la priorité aux optimisations les plus simples, on peut améliorer les performances de manière significative. L'adoption de bonnes pratiques d'ingénierie des données, telles que la conception de pipelines incrémentiels par défaut, la construction et l'utilisation de pré-agrégats, la création de tables temporaires pour minimiser les balayages de table, la construction de tables d'exposition séparées pour chaque expérience afin de réduire les balayages répétés sur notre table d'exposition monolithique, et l'activation des remplissages de mesures par lots, a permis d'améliorer les performances dans notre cas de manière significative.

Équilibrer la personnalisation et la normalisation

In order to cater to the diverse needs of DoorDash's experiment and metrics, it's important to prioritize flexibility and customization over rigid, one-size-fits-all approaches. We included features such as the ability to quickly change the analysis or metric configurations and re-trigger on-demand computation, and enhanced filtering capabilities (e.g. filtering on dimensions, date ranges, and experiment versions). Additionally, allowing users to enter SQLs or custom exposure tables provided an escape hatch for users to conduct triggered analysis and improve the sensitivity of their experiments instead of including all the exposures that could not have been impacted by the experiment.

Donner aux utilisateurs les moyens de déboguer eux-mêmes leurs analyses

Les analyses SQL personnalisées sont généralement plus intuitives et plus faciles à déboguer pour les utilisateurs, mais les pipelines de calcul de métriques standard peuvent souvent impliquer plusieurs étapes intermédiaires, telles que les tables d'exposition et les mesures précalculées, ce qui peut rendre difficile la compréhension et la résolution des problèmes pour les utilisateurs. La plateforme doit permettre aux utilisateurs d'accéder à toutes les informations pertinentes pour les aider à résoudre les problèmes d'analyse par eux-mêmes. Ces informations peuvent inclure des représentations visuelles claires des étapes du pipeline, l'accès aux requêtes SQL et aux journaux de travail pour chaque étape, des mises à jour en temps réel de la progression du pipeline et des notifications d'erreur/d'avertissement sur l'interface utilisateur. Nous générons également automatiquement un carnet d'analyse basé sur le web que les utilisateurs peuvent utiliser pour reproduire la même analyse métrique et approfondir les résultats. Ces efforts peuvent également contribuer à réduire la charge de travail de l'équipe d'expérimentation.

Pré-agrégation vs flexibilité

Les pré-agrégations peuvent améliorer de manière significative les performances des requêtes, mais au détriment de la flexibilité. Le calcul et le stockage d'agrégats inutilisés peuvent devenir coûteux car nous ne connaissons souvent pas tous les schémas d'interrogation à l'avance. Il est donc essentiel de trouver un équilibre entre la préagrégation et la flexibilité. Dans un premier temps, nous avons précalculé et stocké des agrégats pour les mesures concernant différentes unités d'entité telles que user_id et dasher_id. Cependant, nous avons constaté que la plupart de ces agrégats étaient inutilisés et que l'avantage en termes de latence n'était pas très élevé par rapport au coût de leur calcul. Actuellement, nous évaluons d'autres moteurs OLAP comme Pinot pour gérer la préagrégation de manière plus intelligente.

La circulation des données est toujours coûteuse

Data movement is a costly operation, especially when dealing with large volumes of data, and it can result in high network latency. Thus, it's essential to minimize data movement by moving computations closer to the data source whenever possible. For instance, by performing aggregate computations directly in Snowflake and retrieving only the resulting aggregates instead of raw events, we were able to significantly reduce our overall pipeline latency by 50% and cut cloud infrastructure costs associated with analyzing large data volumes by almost 50%. We achieved this by rewriting our computations in SQL, but when it is not possible with SQL, Snowflake's feature called Snowpark can be used to perform more complex data processing directly in Snowflake without having to move data to external systems.

Conclusion 

Chez DoorDash, nous croyons fermement en la valeur d'un magasin de métriques centralisé et en son potentiel d'amélioration et de standardisation de la prise de décision basée sur les données. Notre approche nous a permis de créer, de gérer et de calculer des mesures de manière évolutive et standardisée pour l'expérimentation, en surmontant les défis auxquels nous étions confrontés avec notre précédente approche SQL ad hoc. Nous pensons que nos idées et l'impact que nous avons obtenu serviront à prouver les avantages de la normalisation des mesures et nous espérons que cela encouragera d'autres personnes à envisager l'adoption d'une couche de mesures dans leur organisation. En outre, les détails que nous avons fournis sur nos modèles sémantiques, notre cadre de calcul et l'intégration de la plateforme d'expérimentation sont généralisables et peuvent être utiles à ceux qui cherchent à intégrer leur propre couche de métriques ou une couche externe à leur cadre d'expérimentation.

Bien que nous nous soyons concentrés sur le cas d'utilisation de l'expérimentation, la normalisation des mesures a également des applications plus larges dans d'autres cas d'utilisation basés sur les données. Nous poursuivons notre travail pour reproduire notre succès dans d'autres domaines tels que la veille stratégique, l'analyse exploratoire, les prévisions, etc. et nous nous engageons à réaliser le plein potentiel de notre couche de métriques. Dans les prochains blogs, nous parlerons plus en détail de nos fonctionnalités avancées, telles que l'analyse dimensionnelle automatisée des résultats d'expériences, et de nos progrès dans les cas d'utilisation non liés à l'expérimentation.

Remerciements

Je remercie tout particulièrement Sagar Akella, Bhawana Goel et Ezra Berger pour leur aide inestimable dans la révision de cet article de blog. En outre, j'aimerais exprimer ma gratitude à l'équipe Experimentation, en particulier Caixia Huang, Drew Trager, Michael Zhou, Sharon Weng, Stas Sajin, Wilson Liu et Yixin Tang, pour leur collaboration à la création de certaines des fonctionnalités étonnantes décrites dans cet article.