As métricas são vitais para medir o sucesso em qualquer empresa orientada por dados, mas garantir que essas métricas sejam medidas de forma consistente e precisa em toda a organização pode ser um desafio. A camada de métricas, também conhecida como camada semântica, é um componente crítico da pilha de dados moderna que recentemente recebeu atenção significativa do setor e oferece uma solução poderosa para o desafio de padronizar as definições de métricas. Ao servir como um repositório centralizado para definições de métricas comerciais padronizadas, a camada de métricas permite a tomada de decisões consistentes e democratizadas. Essas definições de métricas contêm a lógica usada para calcular valores de métricas que podem ser aproveitados para uma série de casos de uso analítico, incluindo experimentação, aprendizado de máquina, análise exploratória e relatórios. As definições de métricas padronizadas também permitem que diferentes personas, como cientistas de dados, engenheiros e gestores de produtos, utilizem mais facilmente as mesmas definições de métricas e garantam que todos estão a medir métricas de forma consistente e precisa.
A experimentação é um dos principais casos de utilização que se baseia em métricas. O impacto das experiências, como os testes A/B e os testes de switchback, é normalmente avaliado através da medição das alterações nas métricas. Uma camada de métricas centralizada garante uma medição precisa e fiável dos resultados das experiências e simplifica o processo de análise, minimizando a necessidade de análises ad-hoc. Além disso, a existência de um repositório centralizado de métricas facilita o acesso às métricas, permitindo que todos os membros de uma organização analisem os resultados das experiências. A experimentação está integrada na estratégia de desenvolvimento e crescimento de produtos da DoorDash, e realizamos muitas experiências com diferentes funcionalidades, produtos e algoritmos para melhorar a experiência do utilizador, aumentar a eficiência e também recolher informações que podem ser utilizadas para tomar decisões futuras. Temos a nossa própria plataforma de análise de experiências chamada Curie, que automatiza e unifica o processo de análise de experiências na DoorDash. Esta plataforma permite que as nossas equipas de produtos inovem rapidamente nas suas funcionalidades, avaliando o impacto das experiências nas principais métricas comerciais utilizando as nossas metodologias estatísticas robustas.
Construir uma camada de métricas que funcione para a experimentação não é simples, uma vez que deve suportar diferentes tipos de métricas de escala variável que são utilizadas em toda a gama diversificada de testes A/B que estão a ser executados em diferentes produtos. Neste artigo, vamos focar a importância da camada de métricas e como ela pode melhorar a escalabilidade e a velocidade do processo de tomada de decisão, discutindo nossa jornada de construção de uma para o Curie. Iremos também aprofundar os nossos processos de conceção e implementação e as lições que aprendemos.
Desafios das SQLs ad-hoc
O nosso objetivo inicial com o Curie era normalizar as metodologias de análise e simplificar o processo de análise de experiências para os cientistas de dados. Como mencionámos no nosso blogue anterior, começámos com um método "Bring Your Own SQL", em que os cientistas de dados verificavam ficheiros SQL ad-hoc do Snowflake (o nosso principal armazém de dados) para criar métricas para experiências, e os metadados das métricas eram fornecidos como configurações JSON para cada experiência. Esta abordagem proporcionou a máxima flexibilidade aos utilizadores, uma vez que não tiveram de alterar muito o seu fluxo de trabalho e a maioria já estava a utilizar SQL ad-hoc semelhantes para analisar manualmente as suas experiências.
No entanto, à medida que o Curie foi sendo adotado, deparámo-nos com vários outros desafios na nossa abordagem, que são analisados em seguida:
Falta de normalização
Na DoorDash, várias equipas realizam experiências para otimizar um conjunto comum de métricas empresariais. No entanto, não havia uma forma padronizada de definir as métricas, o que levava a inconsistências na forma como a mesma métrica era definida pelas diferentes equipas. A falta de uma única fonte de verdade para as métricas representava um risco de decisões comerciais incorrectas. A abordagem SQL ad-hoc exigia que os cientistas de dados escrevessem a sua própria SQL para definir métricas, e essas SQLs não eram facilmente detectáveis nem reutilizáveis pelas outras equipas.
Dependência do conhecimento do domínio
Este desafio criou uma forte dependência de especialistas no assunto (SMEs), que têm um profundo conhecimento das métricas e experiência em SQL. Esta dependência criou desafios na democratização das métricas, uma vez que o conhecimento do domínio necessário estava frequentemente isolado em determinadas equipas e não era fácil para os utilizadores identificarem as tabelas, colunas ou funções de consulta relevantes para métricas específicas. A dependência do SQL tornava difícil para os utilizadores não técnicos analisar experiências sem a assistência de cientistas de dados. Consequentemente, os intervenientes no produto eram muitas vezes bloqueados pela largura de banda limitada dos cientistas de dados.
Cálculos métricos não escaláveis
A utilização de SQLs ad-hoc para cálculos métricos na plataforma Curie também colocou desafios de escalabilidade. Os SQLs eram monolíticos por natureza e incluíam múltiplas métricas e dimensões, o que resultava em junções complicadas e pesquisas em tabelas completas que afectavam gravemente o desempenho da nossa plataforma. Havia demasiados cálculos redundantes, uma vez que a mesma métrica era muitas vezes calculada repetidamente para várias experiências. Esta situação conduzia a tempos de fila de análise elevados devido a consultas dispendiosas que bloqueavam as filas de trabalho, o que causava frustração aos utilizadores, acabando por atrasar o seu processo de decisão. A equipa da plataforma tinha poucas possibilidades de melhorar o desempenho e a adição de mais recursos era a única opção para aumentar a escala.
Resultados não fiáveis
Havia preocupações quanto à fiabilidade dos resultados das experiências apresentadas no Curie. A falta de controlo da qualidade e da atualidade dos conjuntos de dados a montante utilizados nas definições das métricas representava um risco de basear decisões comerciais importantes em dados desactualizados ou de baixa qualidade.
Características limitadas
Os desafios de escalabilidade também impediram a implementação de funcionalidades avançadas, tais como a análise dimensional automatizada para cortar e dividir os resultados por atributos qualitativos. Devido a estas limitações, não nos foi possível integrar na plataforma funcionalidades de análise especiais, como o CUPED para redução da variância, verificações de enviesamento pré-experimento de métricas e outras. Esta limitação criou obstáculos à nossa capacidade de inovar e, em última análise, prejudicou a nossa capacidade de retirar mais valor do Curie.
Falta de governação
A nossa plataforma não dispunha de políticas de governação para as definições de métricas. Não havia uma propriedade clara para as métricas e não existia um processo formal de revisão ou aprovação para efetuar alterações às definições. Os metadados de cada métrica estavam incluídos na configuração da experiência e podiam ser ajustados ao nível da análise, o que levava a inconsistências na forma como as métricas eram utilizadas pelas diferentes equipas.
Identificámos que os desafios que enfrentámos foram causados principalmente pela falta de padronização de métricas, centralização e escalabilidade do nosso cálculo de métricas. Para resolver estes problemas, propusemos a construção de uma camada de métricas centralizada para experimentação e a reformulação da nossa estrutura de cálculo de métricas a partir do zero.
Como implementámos os diferentes pilares da nossa camada de métricas
Nesta secção, vamos aprofundar a nossa abordagem a vários aspectos da conceção da nossa camada de métricas, incluindo os seus modelos de dados principais e o motor de cálculo de métricas.
Modelos de dados principais / Semântica
Colocámos uma forte ênfase na identificação dos modelos de dados principais mais abrangentes e eficazes para os utilizadores criarem as suas próprias métricas. Tivemos em conta vários factores-chave:
Atributos métricos
Essencialmente, uma definição de métrica deve incluir metadados básicos, tabelas de origem, colunas do armazém de dados para obter dados e lógica de cálculo para as agregações e filtros necessários. Os cientistas de dados são os principais criadores de métricas e já estão familiarizados com SQL, pelo que fazia sentido utilizar SQL como linguagem para definir métricas em vez de construir a nossa própria DSL.
Modelação de dados
A nossa plataforma requer o acesso aos dados ao nível dos factos ou eventos em bruto, e não apenas aos agregados. Este requisito permite-nos efetuar uma filtragem precisa e uma análise dimensional ao nível do evento.
Dimensões
As dimensões devem ser definidas separadamente como cidadãos de primeira classe e não combinadas com métricas. As junções entre métricas e dimensões devem ser construídas na fase de consumo para máxima flexibilidade.
Generalização
A integração com a plataforma Curie foi uma das principais prioridades, mas também nos certificámos de manter os conceitos de experimentação fora dos modelos de dados principais, uma vez que estes têm de ser suficientemente genéricos para serem utilizados noutros casos de utilização analítica no futuro.
Depois de considerar os factores acima mencionados e estudar outras estruturas de métricas existentes, decidimos adotar modelos de dados de BI padrão. Os utilizadores irão definir os dois modelos seguintes: Fontes de dados e métricas.
Fontes de dados
Uma fonte de dados representa um conjunto de dados que pode ser representado por uma tabela ou uma instrução SQL SELECT. Ela expõe um conjunto de colunas como medidas ou dimensões.
Medidas
Tal como na modelação BI padrão, as "medidas" referem-se a valores quantitativos que representam aspectos específicos de eventos ou factos. Estas medidas são posteriormente agregadas para criar métricas. As medidas são sempre definidas ao nível mais granular possível, sem quaisquer agregações. Este nível de detalhe permite à plataforma aceder a eventos em bruto e efetuar uma filtragem e uma análise dimensional precisas. Por exemplo, ao avaliar a métrica do número de encomendas numa experiência, a plataforma pode contar automaticamente apenas as entregas efectuadas por um utilizador após a sua primeira exposição à experiência. A plataforma também pode dividir a métrica em diferentes cortes dimensionais das entregas
Um exemplo de fonte que define medidas para métricas de entrega
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
Um exemplo de fonte que define medidas para métricas de entrega
Dimensões
As dimensões são os atributos qualitativos de um acontecimento ou de uma entidade que podem ser utilizados para dividir os resultados métricos de uma experiência.
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
Um exemplo de fonte que define dimensões para a entidade consumidor
Para além das medidas e dimensões, as fontes também contêm unidades de entidade, que podem ser utilizadas como chaves de junção com outras fontes ou registos de atribuição de experiências. Estas unidades de entidade incluem muitas vezes IDs como consumer_id, dasher_id e delivery_id, que também serão utilizadas como chaves de bucket ou unidades de aleatorização para experiências. Inclui também uma coluna de carimbo de data/hora definida na sua instrução SQL, indicando o carimbo de data/hora em que o evento ocorreu (no caso das medidas) ou a data ativa de uma dimensão de entidade. Outros metadados necessários para o cálculo também são incluídos, tais como dependências de tabelas a montante para orquestração, o período de lookback para cálculos incrementais, etiquetas para descoberta e identidades de propriedade.
Métricas
As métricas são criadas através da agregação das medidas definidas na fonte e suportamos vários tipos de métricas, tais como agregações normais, rácios e métricas de janela. Os utilizadores podem incluir metadados básicos e definições de experimentação, como covariáveis, nas suas definições de métricas. Por exemplo, na ilustração abaixo, vemos que as previsões de ML são definidas como uma covariável para redução de variância usando CUPAC. Além disso, os utilizadores podem criar métricas de janela como métricas derivadas, apenas estendendo as métricas principais com configurações de janela adicionais, facilitando para os utilizadores e capturando a linhagem entre as métricas principais e derivadas. Por exemplo, o exemplo abaixo demonstra como os utilizadores definem uma métrica de janela de 7 dias para analisar como os utilizadores se convertem nos sete dias seguintes à exposição a uma experiência.
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
Um exemplo de definições de métricas de rácio de taxa de conversão juntamente com as suas métricas de janela derivadas
Mantenha-se informado com as actualizações semanais
Subscreva o nosso blogue de Engenharia para receber actualizações regulares sobre todos os projectos mais interessantes em que a nossa equipa está a trabalhar
Please enter a valid email address.
Obrigado por subscrever!
Autoria e governação
A criação de métricas envolve a criação dos modelos principais acima referidos como ficheiros YAML e o seu carregamento no GitHub para um controlo adequado da fonte. Este processo torna simples para os utilizadores avaliarem e validarem as definições de métricas antes de serem aplicadas em qualquer análise experimental. Com o GitHub, facilitamos um processo de revisão simplificado, garantindo a exatidão técnica e comercial das definições.
As alterações efectuadas nos modelos são submetidas a uma série de validações automatizadas, para além da auditoria manual. Estas verificações são executadas como parte do processo de CI (Integração Contínua) para pedidos pull, incluindo a validação das unidades de entidade, verificações de exclusividade para métricas, dimensões, fontes e validações SQL para confirmar a presença das colunas de medida e carimbo de data/hora necessárias no conjunto de resultados, entre outras. Essas verificações de validação são muito úteis para encontrar e sinalizar quaisquer erros comuns do usuário que poderiam mais tarde quebrar os pipelines de computação. Se o pull request passar em todas as validações e receber a aprovação necessária, as definições actualizadas são sincronizadas com o sistema e disponibilizadas para análise da experiência em poucos minutos. Um serviço GRPC interno aloja estas definições e transmite-as à plataforma de experimentação e aos pipelines de cálculo de métricas através da API, conforme ilustrado na Figura 1.
Pacotes de métricas para uma melhor governação
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.
Os pacotes de métricas também permitem a partilha de configurações de métricas entre diferentes equipas e utilizadores. Por exemplo, tanto as equipas de pesquisa como as de anúncios podem utilizar o mesmo pacote de métricas para medir as métricas de conversão sem terem de trabalhar nas definições e configurações várias vezes. Além disso, criámos pacotes de métricas principais que contêm métricas críticas ao nível da empresa que são automaticamente adicionadas a todas as análises de experiências com base na entidade em que a experiência é aleatória. Isto garante que as principais métricas da empresa são monitorizadas de forma consistente para quaisquer alterações adversas resultantes das experiências.
Motor de cálculo de métricas
Além da padronização, outro motivo principal pelo qual criamos uma camada de métricas foi para melhorar a escalabilidade do cálculo de métricas para experimentação. Os nossos pipelines SQL ad-hoc incluíam muitos cálculos redundantes porque, muitas vezes, cada métrica será avaliada em várias experiências e estava a ser calculada repetidamente. Para resolver este desafio, com a camada de métricas, criámos um motor de cálculo personalizado de raiz para pré-computar as medidas de todas as métricas e reutilizar estes activos de dados calculados nos pipelines de análise. Como resultado, eliminámos as ineficientes pesquisas e junções de tabelas, que são operações que consomem muitos recursos no Snowflake.
Medidas pré-computação
O nosso motor de cálculo de métricas gera dinamicamente pipelines de dados com base nos modelos criados pelos utilizadores. Para cada modelo de origem, criamos um trabalho diário do Dagster para computar e materializar de forma incremental as medidas nele definidas numa tabela Snowflake ([A] na Figura 3). A escolha de utilizar o Dagster como o nosso motor de orquestração foi motivada pelas suas características, tais como uma abordagem declarativa da orquestração que tem em conta os activos de dados, APIs intuitivas para a construção de pipelines, suporte para a execução de backfills a partir da IU, uma arquitetura nativa multi-tenant que permite a execução contínua de múltiplos casos de utilização, uma interface Web robusta e um poderoso suporte da API GraphQL, entre outros.
Para garantir que o nosso pipeline se mantém atualizado, criámos geradores de tarefas Dagster que acompanham periodicamente as alterações aos nossos modelos utilizando as nossas APIs de backend e criam ou modificam automaticamente as tarefas necessárias. As dependências upstream para todos os trabalhos são automaticamente inferidas a partir dos modelos e orquestradas. Geramos um sensor Dagster para cada tarefa de origem que verifica periodicamente o estado da última partição das tabelas a montante e acciona a tarefa de origem correspondente assim que as partições de dados estiverem disponíveis. Os trabalhos também tratam das migrações de bases de dados no Snowflake, criando novas tabelas de acordo com os tipos de medidas e identificadores definidos no SQL de origem, e também adicionando automaticamente novas colunas para quaisquer novas medidas.
Estas automatizações garantem que quaisquer alterações feitas aos modelos são reflectidas nos pipelines de dados em minutos, sem necessidade de intervenção manual. Do ponto de vista do utilizador, isto resulta num aumento significativo da velocidade, uma vez que os cientistas de dados podem adicionar novas métricas e utilizá-las nas suas experiências em poucos minutos, sem o apoio da equipa de infra-estruturas.
Adoptámos o paradigma da Engenharia de Dados Funcional, concebendo todos os nossos trabalhos para serem idempotentes, particionados logicamente por datas e tratando essas partições como imutáveis. A cada execução de tarefa seria atribuído um conjunto de partições que precisava de substituir utilizando o Dagster run-config. Este padrão permitia que os backfills manuais ou automatizados fossem executados de forma repetida, passando o intervalo de datas necessário na configuração da execução do trabalho. Para além disso, todos os trabalhos têm conhecimento do lookback e os nossos trabalhos diários executam automaticamente o backfill de dados para datas anteriores com base no período de lookback definido no modelo de origem. O período de lookback é normalmente definido pelos utilizadores com base no número de partições de datas que são actualizadas diariamente nas tabelas upstream. Também concebemos os nossos pipelines para serem auto-regenerativos, de modo a que, quando um trabalho não é executado em determinados dias, a execução seguinte do pipeline tente recuperar e preencher sistematicamente todos os dados não processados com base no último carimbo de data/hora atualizado. Estes passos garantem que os nossos dados estão sempre actualizados e completos.
Cálculo de métricas e análise de experiências
Uma vez calculadas as medidas brutas, o nosso motor de orquestração acciona os pipelines de dados de agregação para as métricas que são derivadas dessas medidas. Nesta fase ([B] na Figura 3), executamos os pipelines SQL gerados automaticamente para juntar as medidas com as exposições da experiência (atribuições de variantes de cada entidade de aleatorização para uma experiência) para cada experiência e, em seguida, calculamos os agregados para a métrica cortada por diferentes variantes da experiência.
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.
Impacto da implementação de uma camada de métricas - Experimentação melhorada
- Com os nossos esforços de padronização, permitimos que as equipas criassem conjuntos padrão de métricas que pudessem ser partilhados e reutilizados por diferentes equipas de forma consistente. Ao remover o requisito de SQL, permitimos que os intervenientes não técnicos analisassem os testes A/B sem muita supervisão, utilizando os nossos pacotes de métricas principais seleccionados.
- A nossa eficiente estrutura de cálculo de métricas resultou numa melhoria de 10 vezes no tempo médio de análise da experiência, em comparação com a nossa anterior abordagem SQL ad-hoc, permitindo um tempo de obtenção de informações mais rápido.
- Conseguimos implementar várias funcionalidades avançadas, como a redução automatizada da variância CUPED, a verificação automatizada de enviesamento pré-experimento e a análise dimensional, o que conduziu a decisões mais rápidas e mais exactas.
- Melhorámos a fiabilidade e a qualidade geral dos resultados das nossas experiências, acompanhando os atrasos e as falhas das dependências a montante e permitindo verificações básicas da qualidade dos dados.
Aprendizagens da implementação de uma camada de métricas para a Experimentação
A educação dos utilizadores aumenta a adoção
Para promover a adoção da camada de métricas, é importante educar os utilizadores sobre os benefícios das métricas normalizadas. Estes benefícios podem ser comunicados através de sessões de formação de utilizadores e campos de treino práticos. Ao demonstrar o impacto da melhoria do desempenho e da reutilização das métricas, os utilizadores irão apreciar plenamente o valor. Em particular, ajuda a salientar como os cientistas de dados podem beneficiar da capacidade de permitir que as partes interessadas não técnicas analisem experiências utilizando métricas normalizadas sem necessitarem de muita orientação, para que possam gastar o seu tempo noutros objectivos, como o estudo de tendências, a análise exploratória para obter informações, a criação de modelos de ML, etc.
O desempenho é a chave
Para encorajar os utilizadores a adotar métricas padrão, é crucial que a camada de métricas forneça um desempenho fiável e rápido com acesso de baixa latência. O fraco desempenho pode levar os utilizadores a optar por soluções SQL ad-hoc. Dar prioridade às optimizações menos importantes pode melhorar significativamente o desempenho. A adoção de boas práticas de engenharia de dados, como a conceção de pipelines incrementais por predefinição, a criação e a utilização de pré-agregados, a criação de tabelas temporárias faseadas para minimizar as pesquisas de tabelas, como a criação de tabelas de exposição separadas para cada experiência, para reduzir as pesquisas repetidas na nossa tabela de exposições monolíticas, e a ativação de preenchimentos posteriores de medidas em lote melhoraram significativamente o desempenho no nosso caso.
Equilíbrio entre personalização e normalização
Para atender às diversas necessidades dos experimentos e métricas do DoorDash, é importante priorizar a flexibilidade e a personalização em vez de abordagens rígidas e de tamanho único. Incluímos recursos como a capacidade de alterar rapidamente as configurações de análise ou métrica e reativar o cálculo sob demanda, além de recursos aprimorados de filtragem (por exemplo, filtragem de dimensões, intervalos de datas e versões de experimentos). Além disso, a possibilidade de os utilizadores introduzirem SQLs ou tabelas de exposição personalizadas permitiu-lhes realizar análises desencadeadas e melhorar a sensibilidade das suas experiências, em vez de incluírem todas as exposições que não poderiam ter sido afectadas pela experiência.
Capacitar os utilizadores para a auto-purificação de análises
As análises SQL personalizadas são normalmente mais intuitivas e mais fáceis de depurar pelos utilizadores, mas os pipelines de cálculo de métricas padrão podem frequentemente envolver várias etapas intermédias, tais como tabelas de exposição de preparação e medidas pré-computadas, o que pode dificultar a compreensão e a resolução de problemas pelos utilizadores. A plataforma deve fornecer aos utilizadores acesso a todas as informações relevantes para os ajudar a resolver problemas de análise por si próprios. Essas informações podem incluir representações visuais claras dos passos do pipeline, acesso a consultas SQL e registos de trabalho para cada passo, actualizações do progresso do pipeline em tempo real e notificações de erro/aviso na interface do utilizador. Também geramos automaticamente um bloco de notas baseado na Web para análises que os utilizadores podem utilizar para replicar a mesma análise de métricas e aprofundar os resultados. Estes esforços também podem ajudar a reduzir a carga de trabalho da equipa de experimentação
Pré-agregação vs flexibilidade
As pré-agregações podem melhorar significativamente o desempenho das consultas, mas podem ser efectuadas à custa da flexibilidade. Ao pré-agregar métricas, podemos perder a capacidade de consultar dados em bruto, e o cálculo e armazenamento de agregados não utilizados pode tornar-se dispendioso, porque muitas vezes podemos não conhecer de antemão todos os padrões de consulta. Assim, é crucial encontrar um equilíbrio entre a pré-agregação e a flexibilidade. Inicialmente, pré-computámos e armazenámos agregados para métricas em diferentes unidades de entidades, como user_id e dasher_id. No entanto, verificámos que a maioria destes agregados não era utilizada e que o benefício da latência não era muito elevado quando comparado com o custo de os calcular. Atualmente, estamos a avaliar outros motores OLAP, como o Pinot, para gerir a pré-agregação de forma mais inteligente.
A movimentação de dados é sempre dispendiosa
A movimentação de dados é uma operação dispendiosa, especialmente quando se lida com grandes volumes de dados, e pode resultar em alta latência de rede. Assim, é essencial minimizar a movimentação de dados movendo os cálculos para mais perto da fonte de dados sempre que possível. Por exemplo, ao efetuar cálculos agregados diretamente no Snowflake e ao recuperar apenas os agregados resultantes em vez de eventos em bruto, conseguimos reduzir significativamente a latência geral do nosso pipeline em 50% e reduzir os custos da infraestrutura da nuvem associados à análise de grandes volumes de dados em quase 50%. Conseguimos isto reescrevendo os nossos cálculos em SQL, mas quando não é possível com SQL, a funcionalidade do Snowflake chamada Snowpark pode ser utilizada para realizar um processamento de dados mais complexo diretamente no Snowflake sem ter de mover os dados para sistemas externos.
Conclusão
Na DoorDash, acreditamos firmemente no valor de um armazenamento centralizado de métricas e no seu potencial para melhorar e padronizar a tomada de decisões orientada por dados. A nossa abordagem permitiu-nos criar, gerir e calcular métricas de uma forma escalável e padronizada para experimentação, ultrapassando os desafios que enfrentámos com a nossa anterior abordagem SQL ad-hoc. Acreditamos que os nossos conhecimentos e o impacto que alcançámos servirão como prova dos benefícios da normalização das métricas e esperamos que encorajem outros a considerar a adoção de uma camada de métricas nas suas organizações. Além disso, os detalhes que fornecemos sobre os nossos modelos semânticos, a estrutura de cálculo e a integração da plataforma de experimentação são generalizáveis e podem ser úteis para aqueles que pretendem integrar a sua própria camada de métricas ou uma camada externa com a sua estrutura de experimentação.
Embora o nosso foco tenha sido o caso de uso de experimentação, a padronização de métricas tem aplicações mais amplas em outros casos de uso orientados por dados também. Continuamos a trabalhar para replicar o nosso sucesso noutras áreas, como a inteligência empresarial, a análise exploratória, a previsão, etc., e estamos empenhados em concretizar todo o potencial da nossa camada de métricas. Em futuros blogues, falaremos mais sobre as nossas funcionalidades avançadas, como a nossa análise dimensional automatizada para resultados de experiências e o nosso progresso em casos de utilização não relacionados com experiências.
Agradecimentos
Um agradecimento especial a Sagar Akella, Bhawana Goel e Ezra Berger pela sua inestimável ajuda na revisão deste artigo do blogue. Adicionalmente, gostaria de estender a minha gratidão à equipa de Experimentação, especificamente a Caixia Huang, Drew Trager, Michael Zhou, Sharon Weng, Stas Sajin, Wilson Liu e Yixin Tang, pela sua colaboração na construção de algumas das fantásticas funcionalidades detalhadas neste artigo