Data Marts da Delhivery - Jornada de migração de OLTP para HTAP

Como plataforma líder de atendimento para comércio digital na Índia, a Delhivery atende um milhão de pacotes por dia, 365 dias por ano. Seus 24 centros de triagem automatizados, 101 hubs, mais de 3.100 centros de entrega direta, mais de 1.000 centros parceiros, mais de 11.000 frotas e mais de 60.000 membros de equipe funcionam perfeitamente graças a uma vasta rede de dispositivos IoT. Milhares de eventos de dados e mensagens entram e saem de nossos pipelines a cada segundo. Isto equivale a um enorme volume diário de dados em terabytes, o que torna a visibilidade operacional crucial para nós e para as nossas partes interessadas.

Reconhecendo os requisitos, decidimos construir data marts – bancos de dados centralizados e eventualmente consistentes que oferecem aos usuários acesso rápido a dados de negócios pré-agregados. Isso permite que nossos stakeholders acessem rapidamente insights de negócios sem pesquisar em um data warehouse inteiro.

No entanto, com esta escala assustadora, um dos principais desafios era manter a integridade dos dados e a baixa latência, ao mesmo tempo que fornecia capacidade para cargas de trabalho analíticas.

Neste blog, vou descompactar todos os meus aprendizados durante a migração de nossos data marts do Amazon Aurora para o TiDB, um banco de dados SQL distribuído de processamento transacional/analítico híbrido (HTAP). Esperançosamente, esta postagem pode fornecer insights para líderes de engenharia de dados, administradores de banco de dados ou arquitetos de dados que estão considerando uma migração semelhante para TiDB ou qualquer outro banco de dados HTAP.

OLTP, OLAP e HTAP

Para entender melhor o caso de data marts em tempo real na Delhivery, vamos primeiro nos familiarizar com três conceitos que estão no centro do nosso caso de uso: OLTP, OLAP e HTAP:

• OLTP: Os sistemas Online Transaction Processing (OLTP) são projetados para aplicações orientadas a transações, garantindo a integridade dos dados por meio de propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade).
• OLAP: Os sistemas de Processamento Analítico Online (OLAP) permitem análises multidimensionais e de alta velocidade de grandes volumes de dados, auxiliando na tomada de decisões orientada por dados.
• HTAP: Hybrid Transaction/Analytical Processing (HTAP) combina funcionalidades OLTP e OLAP, permitindo análises em tempo real de dados transacionais.

Caso de uso de data marts em tempo real na Delhivery

Os data marts em tempo real diferem dos data marts tradicionais porque ingerem dados em tempo real, não em intervalos específicos. Esses data marts são essenciais para a tomada de decisões operacionais terrestres em Delhivery porque não podemos nos permitir qualquer atraso na sincronização desses eventos.

Nossa jornada de data mart em tempo real começou em 2020, quando identificamos a necessidade de painéis centralizados – especificamente o painel EYE. O objetivo deste painel era fornecer visibilidade operacional em tempo real às operações terrestres, permitindo a tomada de decisões com base em dados atualizados ao minuto. Exemplos de usos incluem:

• Planejamento e visibilidade de veículos: monitoramento em tempo real dos cronogramas de conexão de entrada e saída para hubs Delhivery.
• Acompanhamento de desempenho: Acompanhamento contínuo do desempenho das instalações da Delhivery.
• Visibilidade de controle centralizado: Fornecer à equipe central informações precisas sobre os bloqueadores de solo para tomar as ações apropriadas. Isso pode ser devido a vários fatores, como queda no desempenho do centro, envelhecimento das remessas ou congestionamento nas conexões de entrada e saída.
• Conformidades: Rastreamento de métricas de conformidade de colocação e seleção

Implementação inicial e os desafios

Pensamos em resolver nossos casos de uso usando ferramentas de data warehouse como Redshift e Snowflake, mas nenhuma dessas soluções funcionou para nós, considerando o padrão de design e a necessidade de ingestão de dados em tempo real junto com a mesclagem.

Assim, inicialmente escolhemos o Aurora (PostgreSQL) para atender nosso caso de uso de data mart.

O processo de ingestão de dados em torno do Aurora

Arquitetamos nossos data marts em tempo real usando Spark Streaming e Aurora. Nosso pipeline fumegante era muito simples: ler dados do Kafka, processar dados em microlotes do Spark e realizar operações de upsert no Aurora.

Nosso banco de dados foi modelado usando uma arquitetura multicamadas, que consiste em uma camada bruta, uma camada particionada e uma camada de data marts. Os usuários não tinham acesso para visualizar ou modificar dados na camada bruta. A camada particionada é mantida para manter todas as tabelas particionadas (geralmente tabelas de dimensões). Abaixo está um design de esquema simples de nosso banco de dados:

Desafios que enfrentamos com Aurora

O sistema inicialmente teve um bom desempenho, até precisar lidar com uma taxa de transferência superior a 3 mil mensagens por segundo. Isto marcou o início de vários desafios:

• Limitação de escalabilidade: à medida que excedemos a taxa de transferência de 3 mil mensagens por segundo, as limitações de operações de entrada/saída por segundo (IOPS) do Aurora se tornaram um gargalo. A restrição de escalabilidade começou a impactar nossas operações.

  
  

• Problema de inchaço: cada atualização de registro levou à criação de um novo registro e de uma tupla morta (versão anterior do registro). Quando a taxa de produção dessas tuplas mortas ultrapassou o processo de limpeza, ocorreu o inchaço. Como o VACUUM FULL não conseguiu reivindicar o armazenamento, o uso do disco aumentou continuamente. Para aproximadamente 5 TB de dados, o Aurora estava usando mais de 30 TB de armazenamento.

  
  

• Carga de manutenção: O problema do inchaço está diretamente ligado aos nossos desafios de manutenção. Com mais de 70 pipelines e um QPS de gravação total superior a 5 mil mensagens/segundo, descobrimos que o processo de limpeza automática do PostgreSQL, Auto Vacuum, não conseguiu acompanhar a taxa de geração de tuplas mortas. Portanto, é necessário executar manualmente VACUUM ou VACUUM FULL para recuperar o banco de dados. Nossas tentativas com ferramentas PostgreSQL como pg_repack e pgcompacttable também não tiveram sucesso. Consequentemente, a manutenção tornou-se cada vez mais complexa e demorada.

• Custo: para acomodar a carga de trabalho de leitura e gravação, tivemos que escalar para os nós mais altos disponíveis (24XLarge). Isso levou a um gasto de aproximadamente US$ 100.000 por mês para um cluster Aurora de três nós. Com essa escala, o Aurora acabou sendo caro por causa do escalonamento automático de IOPS.

Procurando alternativas

Para resolver as limitações do Aurora, decidimos encontrar uma alternativa melhor que atendesse aos seguintes requisitos:

• Escalável com alto QPS de gravação: o banco de dados deve suportar pelo menos 10k+ QPS de gravação e é escalonável horizontalmente.
• Análise em tempo real: o banco de dados deve ser capaz de fornecer recursos OLAP de alta velocidade ou em tempo real
• Totalmente distribuído: O banco de dados deve ser distribuído em vários locais para fornecer alta disponibilidade e tolerância a falhas.
• Consistência forte: O banco de dados deve manter uma consistência forte, garantindo que todos os usuários vejam os mesmos dados.

Considerando todos os requisitos acima, inicialmente exploramos muitas alternativas do PostgreSQL, incluindo Spanner e Yugabyte, porque queríamos manter nosso gerenciamento de mudanças mínimo.

Chave inglesa

Spanner é um serviço distribuído de gerenciamento e armazenamento de banco de dados SQL oferecido pelo Google. É totalmente gerenciado no Google Cloud Platform (GCP). No entanto, descobrimos que o Spanner pode não ser um bom caso de uso para nossa arquitetura pelos seguintes motivos:

• O Spanner não oferece suporte a esquemas.
• Não encontramos as ferramentas adequadas para carregar dados históricos. Exploramos Harbourbridge, uma ferramenta de código aberto para avaliação e migração do Spanner. No entanto, tinha limitações em torno de 100 GB de carregamento de dados.

Yugabyte

YugabyteDB é um banco de dados SQL distribuído transacional de alto desempenho para aplicativos nativos da nuvem, desenvolvido pela Yugabyte. Este banco de dados está muito próximo do nosso caso de uso porque era totalmente compatível com PostgreSQL, escalável horizontalmente e totalmente distribuído. Infelizmente, não funcionou tão bem devido à sua limitação de escalabilidade. Nossos critérios de sucesso exigiam mais de 7 mil transações por segundo, mas a Yugabyte só conseguiu escalar até 5 mil.

Também analisamos outros possíveis candidatos, como o BigQuery, mas nenhum deles atendeu bem aos nossos requisitos.

Aterrissando com TiDB

Após as alternativas do PostgreSQL acima, decidimos adicionar HTAP aos nossos requisitos, o que nos levou ao TiDB. Ele oferece suporte a escalabilidade, consistência, disponibilidade, topologia de implantação em vários locais e muitos outros recursos prontos para uso. Por ser um banco de dados distribuído, o TiDB possui vários componentes que se comunicam entre si e formam um sistema TiDB completo.

• TiDB: é o componente de processamento SQL sem estado que fornece ao usuário o endpoint voltado para o cliente. Ele localiza o nó TiKV correto para conectar-se do PD para obter os dados.
• TiKV: É um armazenamento de dados de valor-chave transacional distribuído que mantém os dados no intervalo esquerdo-fechado-direito-aberto. Os dados são mantidos em fragmentos com múltiplas réplicas. TiKV usa o protocolo Raft para replicação.
• PD: O driver de posicionamento (PD) mantém os metadados do cluster, como locais de réplica de fragmentos, e também é responsável por agendar os fragmentos entre nós TiKV. O líder PD lida com essas tarefas enquanto outros nós mantêm alta disponibilidade.
• TiFlash: A extensão de armazenamento colunar que usa o protocolo Multi-Raft Learner para replicar dados do TiKV em tempo real, garantindo dados consistentes entre o mecanismo de armazenamento baseado em linhas do TiKV.

Os seguintes recursos do TiDB abordaram nossos principais desafios e atenderam aos nossos requisitos operacionais:

• Dimensionamento fácil

  O design da arquitetura TiDB separa a computação do armazenamento, permitindo que você expanda ou dimensione a capacidade de computação ou armazenamento on-line conforme necessário. O processo de escalonamento é transparente para a equipe de operações e manutenção do aplicativo.

• Compatível com ACID

  TiDB é compatível com MySQL e oferece suporte a transações prontas para uso. Ele suporta tipos de transações otimistas e pessimistas. Isso o torna único em relação a outros bancos de dados.

• Altamente disponível

  O TiKV armazena dados em múltiplas réplicas e usa o protocolo Multi-Raft para obter o log de transações. Uma transação só pode ser confirmada quando os dados foram gravados com sucesso na maioria das réplicas. Isso garante forte consistência e alta disponibilidade quando uma minoria de réplicas fica inativa.

• HTAP em tempo real

  O TiDB combina armazenamento em linha (TiKV) e armazenamento em coluna (TiFlash) na mesma arquitetura, formando uma pilha de tecnologia simplificada que facilita a produção de análises em tempo real de dados operacionais.

Nossa infraestrutura TiDB

Nossa infraestrutura TiDB é implantada nas VMs dos principais provedores de serviços em nuvem. Utilizamos o TiUP, gerenciador de pacotes do TiDB, para gerenciar o cluster e todas as operações administrativas. Nosso cluster é implantado em 3 zonas disponíveis (AZs).

Nossas configurações de cluster são as seguintes:

• PD: A camada PD possui 3 nós divididos em Multi-AZs. O líder PD lida com essas tarefas enquanto outros nós mantêm alta disponibilidade.
• TiDB: A camada TiDB possui 9 nós da família n2-highmem-8. Esses nós foram escolhidos com base nos requisitos de memória, com 64 GB de RAM e CPUs de 8 núcleos alocadas para cada nó TiDB.
• TiKV: A camada TiKV possui 15 nós da família n2-highmem-16 que possui 128 GB de RAM e 16 CPUs vCORE.

Ao implantar nosso cluster TiDB em várias AZs e selecionar cuidadosamente os tipos de nós para atender às nossas necessidades de processamento e memória, criamos uma infraestrutura robusta e altamente disponível, capaz de lidar com nossos requisitos de alto rendimento de dados.

Ajustando o TiDB para o nosso caso

Para que funcionasse em nosso caso de uso, trabalhamos em estreita colaboração com a equipe PingCAP para ajustar o banco de dados. Aqui estão alguns dos ajustes críticos que fizemos:

Otimização de índice

Defina os seguintes parâmetros antes de iniciar o índice.

 SET @@global.tidb_ddl_reorg_worker_cnt = 16; SET @@global.tidb_ddl_reorg_batch_size = 4096;

Redefinir para os valores padrão após a criação do índice.

 SET @@global.tidb_ddl_reorg_worker_cnt = 4; SET @@global.tidb_ddl_reorg_batch_size = 256;

Poda de partição

Isto é importante principalmente para tabelas particionadas. Ele analisa as condições de filtro em instruções de consulta e elimina (remove) partições quando elas não contêm nenhum dado necessário.

 SET @@session.tidb_partition_prune_mode = 'dynamic';

Análise de ajuste

Às vezes, o analisador automático no TiDB falha se um grande volume de dados for ingerido. Nesse caso, todas as consultas podem usar o plano de execução errado e acabar verificando a tabela completa. Para evitar tal situação fizemos as seguintes alterações nas configurações do TiDB:

 set global tidb_max_auto_analyze_time = 86400; set global tidb_enable_pseudo_for_outdated_stats = off; set global tidb_sysproc_scan_concurrency = 15;

Se você estiver trabalhando com tabelas particionadas, sugerimos que você execute operações de análise de tabela manualmente para uma partição por vez, para evitar falhas de análise.

Através de ajustes como esses, conseguimos agilizar efetivamente o uso do TiDB, para que possamos alcançar um desempenho ideal para nosso data mart em tempo real.

Nossa experiência com TiDB

• Melhor desempenho de consultas

  Avaliamos mais de 400 consultas e descobrimos que todas as consultas estão sendo executadas dentro do SLA. Vimos até um ganho de desempenho de 15-20% nas consultas P95.

• Migração fácil

  Usamos a ferramenta TiDB Lighting para migrar todos os dados históricos de nossa tabela do Postgres para o TiDB. Esta ferramenta é muito fácil de usar e muito rápida. Conseguimos carregar terabytes de dados em aproximadamente 2 a 3 horas. No entanto, é importante notar que são necessários muitos ajustes antes de carregar dados tão grandes.

• Um forte apoio

  Passamos por alguns contratempos durante a configuração da infraestrutura de produção, mas a equipe de suporte do PingCAP desempenhou um papel crucial e nos ajudou a ajustar o cluster para a natureza da carga de trabalho.

  
  

Conclusão

Nesta postagem, exploramos os desafios de usar o Aurora com nosso caso de uso de data marts em tempo real e a jornada de migração para o TiDB. Também discutimos como a Delhivery está usando o TiDB em grande escala.

Apesar do nosso sucesso com o TiDB, reconhecemos que nenhuma solução é perfeita e a eficácia pode variar dependendo do caso de uso. No TiDB, observamos algumas áreas que precisam ser melhoradas, incluindo a falta de suporte pronto para uso para visualizações materializadas e gerenciamento de cotas nativas. No entanto, com soluções alternativas e ajustes apropriados, conseguimos resolver essas limitações de forma eficaz.

Até agora, implantamos o TiDB em nosso ambiente de produção. Com base em nossos benchmarks, o TiDB nos permite lidar com milhares de solicitações por segundo com latência inferior a 100 ms. No futuro, continuaremos a explorar mais casos de uso que exigem um banco de dados robusto e distribuído de forma consistente.

Referências

https://docs.pingcap.com/tidb/stable/tidb-lightning-overview

https://reorg.github.io/pg_repack/

https://github.com/dataegret/pgcompacttable

https://cloud.google.com/spanner

https://www.yugabyte.com/yugabytedb/

https://cloud.google.com/bigquery/

https://docs.pingcap.com/tidb/dev/transaction-overview

https://proxysql.com/

Autor:

Hari Kishan (Gerente Sênior de Engenharia em Delhivery)

Akash Deep Verma (Diretor de Tecnologia @ Delhivery)