Razorpay Otimiza Atualização de Data Warehouse em 10x com Grafos e Índices
Aprofundamento CEVIU
Aprofundamento
A otimização da Razorpay no data warehouse é um belo exemplo de engenharia de dados que se adapta à complexidade do negócio. Eles substituíram um sistema de atualização full refresh, que varria tabelas inteiras diariamente, por uma abordagem incremental baseada em grafos. Essa mudança trouxe uma redução de 90% no tempo de atualização e um impacto significativo nos custos. A arquitetura envolve o uso de uma camada silver para desduplicar alterações diárias por chave primária, garantindo a integridade dos dados mais recentes. Em vez de ler tudo, o sistema agora foca só no que mudou.
Para dar agilidade, a Razorpay usa índices secundários para armazenar colunas de junção e metadados de partição. Isso elimina os
Linha do tempo
Razorpay constrói sua própria Customer Data Platform para processar dados transacionais em larga escala.
Arcesium Revoluciona Data Warehousing com Migração para DuckDB e Iceberg.
Razorpay otimiza atualização de data warehouse em 10x com grafos e índices.
Perguntas frequentes
O que são 'Facts' no contexto do data warehouse da Razorpay?
Na Razorpay, 'Facts' são tabelas desnormalizadas e amplas, construídas unindo dados de 10 a 30 tabelas de microserviços. Elas consolidam informações para facilitar consultas e relatórios, agindo como visões materializadas específicas para cada domínio, como pagamentos ou reembolsos.
Qual era o principal problema da abordagem 'full refresh' anterior?
A abordagem 'full refresh' anterior da Razorpay realizava varreduras completas das tabelas, o que era ineficiente, caro e demorado. Isso resultava em pipelines que rodavam por horas, custavam muito em clusters EMR e causavam latência de até 48 horas na atualização dos dados. O sistema não escalava bem para dados com referências antigas ou alta cardinalidade.
Como os grafos e índices secundários otimizam a atualização do data warehouse?
A Razorpay modela a configuração de seus 'Facts' como grafos de dependência. Isso permite que o sistema processe apenas as alterações nas linhas relevantes, evitando varreduras completas. Os índices secundários, por sua vez, servem para localizar rapidamente os dados necessários no data lake, direcionando as leituras para partições específicas e eliminando a necessidade de full table scans.
Por que a Razorpay abandonou uma tentativa anterior de usar <i>streaming</i> para denormalização de dados?
Uma tentativa anterior de streaming via Kafka falhou devido a dados altamente mutáveis, alto volume de eventos e o custo insustentável de operações de join. A necessidade de manter todos os dados históricos em um warm store como o TiDB também bloqueava iniciativas de retenção, além da amplificação de escrita gerada pelos joins de alta cardinalidade. Isso levou à conclusão de que streaming nem sempre é a resposta para cenários específicos.
Fontes
- engineering.razorpay.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 16 de julho de 2026
- Editoria
- CEVIU Dados