Oferecendo personalização em escala em tempo actual
Cada milissegundo conta quando os viajantes procuram hotéis, voos ou experiências. Como a maior agência de viagens on-line da Índia, a MakeMyTrip compete em velocidade e relevância em tempo actual. Uma de suas características mais importantes são os hotéis “últimamente pesquisados”: à medida que os usuários tocam na barra de pesquisa, eles esperam uma lista personalizada em tempo actual de seus interesses recentes, com base em sua interação com o sistema.
Na escala da MakeMyTrip, fornecer essa experiência requer latência de menos de um segundo em um pipeline de produção que atende milhões de usuários diários – em linhas de negócios de viagens corporativas e de consumo. Ao implementar o Databricks Modo em tempo actual (RTM)—o mecanismo de execução de próxima geração em Apache Spark™ Structured Streaming, MakeMyTrip alcançou com sucesso latências de milissegundos, mantendo uma infraestrutura econômica e reduzindo a complexidade de engenharia.
O desafio: latência ultrabaixa sem fragmentação arquitetônica
A equipe de dados da MakeMyTrip precisava de latência inferior a um segundo para o fluxo de trabalho dos hotéis da “última pesquisa” em todas as linhas de negócios. Em sua escala, mesmo algumas centenas de milissegundos de atraso criam atrito na jornada do usuário, impactando diretamente as taxas de cliques.
O modo microlote do Apache Spark introduziu limites de latência inerentes que a equipe não conseguiu quebrar, apesar do ajuste extensivo – fornecendo consistentemente uma latência de um a dois segundos, muito lenta para seus requisitos.
Em seguida, eles avaliaram o Apache Flink em cerca de 10 pipelines de streaming que resolveu seus requisitos de latência. No entanto, a adoção do Apache Flink como segundo mecanismo teria introduzido desafios significativos de longo prazo:
- Fragmentação arquitetônica: Manter mecanismos separados para processamento em lote e em tempo actual
- Lógica de negócios duplicada: As regras de negócios precisariam ser implementadas e mantidas em duas bases de código
- Maior sobrecarga operacional: Duplicando o esforço de monitoramento, depuração e governança em vários pipelines
- Riscos de consistência: Os resultados correm o risco de divergência entre o processamento em lote e em tempo actual
- Custos de infraestrutura: Executar e ajustar dois mecanismos aumenta os gastos com computação e a carga de manutenção
Por que o modo em tempo actual: latência de milissegundos em uma única pilha Spark
Como a MakeMyTrip nunca quis uma arquitetura de motor duplo, o Apache Flink não period uma opção viável a longo prazo. A equipe tomou uma decisão arquitetônica deliberada: esperar que o Apache Spark se tornasse mais rápido, em vez de fragmentar a pilha.
Portanto, quando o Apache Spark Structured Streaming introduziu o RTM, a MakeMyTrip se tornou o primeiro cliente a adotá-lo. O RTM permitiu que atingissem latência de nível de milissegundos no Apache Spark — atendendo aos requisitos em tempo actual sem introduzir outro mecanismo ou dividir a plataforma.
Manter dois mecanismos significa duplicar a complexidade e o risco de desvio lógico entre cálculos em lote e em tempo actual. Queríamos uma fonte de verdade – um pipeline baseado em Spark – em vez de dois motores para manter. O Modo Tempo Actual nos proporcionou o desempenho que precisávamos com a simplicidade que queríamos.” — Aditya Kumar, Diretora Associada de Engenharia, MakeMyTrip
O RTM oferece processamento contínuo e de baixa latência por meio de três inovações técnicas importantes que trabalham juntas para eliminar as fontes de latência inerentes à execução de microlotes:
- Fluxo de dados contínuo: Os dados são processados à medida que chegam, em vez de serem discretizados em blocos periódicos.
- Programação de pipeline: Os estágios são executados simultaneamente sem bloqueio, permitindo que tarefas downstream processem dados imediatamente, sem esperar a conclusão dos estágios upstream.
- Transmissão aleatória: Os dados são transmitidos entre tarefas imediatamente, contornando os gargalos de latência dos embaralhamentos tradicionais baseados em disco.
Juntas, essas inovações permitem que o Apache Spark alcance pipelines em escala de milissegundos que antes só eram possíveis com mecanismos especializados. Para saber mais sobre a base técnica do RTM, leia este weblog, “Quebrando a barreira do microbatch: a arquitetura do modo em tempo actual do Apache Spark”.
A arquitetura: um pipeline unificado em tempo actual
O pipeline do MakeMyTrip segue um caminho de alto desempenho:
- Ingestão unificada: Os tópicos de clickstream B2C e B2B são mesclados em um único stream. Toda a lógica de personalização — enriquecimento, pesquisa com estado e processamento de eventos — é aplicada de forma consistente em ambos os segmentos de usuários.
- Processamento RTM: O mecanismo Apache Spark usa agendamento simultâneo e streaming aleatório para processar eventos em milissegundos.
- Enriquecimento com estado: O pipeline realiza uma pesquisa de baixa latência no Aerospike para recuperar os “Últimos N” hotéis de cada usuário.
- Serviço instantâneo: Os resultados são enviados para um cache de UI (Redis), permitindo que o aplicativo forneça resultados personalizados em menos de 50 ms.
Configurando RTM: uma alteração de código de linha única
Usar RTM em sua consulta de streaming não requer a reescrita da lógica de negócios ou a reestruturação de pipelines. A única alteração de código necessária é definir o tipo de gatilho como RealTimeTrigger, conforme mostrado no seguinte trecho de código:
A única consideração de infraestrutura: os slots de tarefas de cluster devem ser maiores ou iguais ao número whole de tarefas ativas nos estágios de origem e aleatório. A equipe da MakeMyTrip analisou antecipadamente suas partições Kafka, partições aleatórias e complexidade do pipeline para garantir simultaneidade suficiente antes de ir para a produção.
Co-desenvolvimento de RTM para produção
Como primeiro adotante do RTM, MakeMyTrip trabalhou diretamente com a engenharia da Databricks para deixar o pipeline pronto para produção. Vários recursos exigiram colaboração ativa entre as duas equipes para construir, ajustar e validar.
- Stream Union: Mesclando B2C e B2B em um único pipeline
A MakeMyTrip precisava unificar dois fluxos de tópicos Kafka separados – fluxo de cliques do consumidor B2C e viagens corporativas B2B – em um único pipeline RTM para que a mesma lógica de personalização pudesse ser aplicada de forma consistente em ambos os segmentos de usuários. Após um mês de estreita colaboração com a engenharia da Databricks, o recurso foi criado e enviado. O resultado foi um pipeline único onde toda a lógica de negócios reside em um só lugar, sem risco de divergência entre segmentos de usuários. - Multiplexação de tarefas: Mais partições, menos núcleos
O modelo padrão do RTM atribui um slot/núcleo por partição Kafka. Com 64 partições na configuração de produção do MakeMyTrip, isso se traduz em 64 slots/núcleos – com custo proibitivo em sua escala. Para resolver isto, a equipa da Databricks introduziu a opção MaxPartitions para Kafka, que permite que múltiplas partições sejam tratadas por um único núcleo. Isso deu à MakeMyTrip a alavanca necessária para reduzir custos de infra-estrutura sem comprometer o rendimento. - Endurecimento de pipeline: Ponto de verificação, contrapressão e tolerância a falhas
A equipe superou um conjunto de desafios operacionais específicos para cargas de trabalho de alto rendimento e baixa latência: ajuste de frequência e retenção de pontos de verificação, tratamento de tempos limite e gerenciamento de contrapressão durante picos no quantity de fluxo de cliques. Ao dimensionar para 64 partições Kafka, ativar a contrapressão e limitar o MaxRatePerPartition em 500 eventos, a equipe otimizou o rendimento e a estabilidade. Por meio desse ajuste iterativo de configurações em lote, particionamento e comportamento de novas tentativas, eles chegaram a um pipeline estável de nível de produção que atende milhões de usuários diariamente.
Resultados
O RTM permitiu personalização instantânea e capacidade de resposta aprimorada, maior envolvimento medido por meio de taxas de cliques e simplicidade operacional de um único mecanismo unificado. As principais métricas são mostradas abaixo.
Apache Spark como mecanismo em tempo actual
A implantação do MakeMyTrip prova que o RTM no Spark oferece a latência extremamente baixa que seus aplicativos em tempo actual exigem. Como o RTM é construído nas mesmas APIs familiares do Spark, você pode usar a mesma lógica de negócios em pipelines em lote e em tempo actual. Você não precisa mais da sobrecarga de manter uma segunda plataforma ou base de código separada para processamento em tempo actual e pode simplesmente ativar o RTM no Spark com uma única linha de código.
O modo em tempo actual nos permitiu compactar nossa infraestrutura e oferecer experiências em tempo actual sem gerenciar vários mecanismos de streaming. À medida que avançamos na period dos agentes de IA, orientá-los de forma eficaz requer a construção de contexto em tempo actual a partir de fluxos de dados. Estamos experimentando o Spark RTM para fornecer aos nossos agentes o contexto mais rico e recente necessário para tomar as melhores decisões possíveis.” — Aditya Kumar, Diretora Associada de Engenharia, MakeMyTrip
Introdução ao modo em tempo actual
Para saber mais sobre o modo em tempo actual, assista a isto vídeo sob demanda sobre como começar ou revise o documentação.