Isolamento de carga de trabalho no Apache Doris: otimizando o gerenciamento e o desempenho de recursos

Esta é uma introdução detalhada aos recursos de isolamento de carga de trabalho do Apache Doris . Mas antes de tudo, por que e quando você precisa do isolamento da carga de trabalho? Se você se identifica com alguma das seguintes situações, continue lendo e você encontrará uma solução:

• Você tem diferentes departamentos comerciais ou locatários compartilhando o mesmo cluster e deseja evitar interferência na carga de trabalho.

  
  

• Você tem tarefas de consulta com vários níveis de prioridade e deseja dar prioridade às suas tarefas críticas (como análise de dados em tempo real e transações online) em termos de recursos e execução.

  
  

• Você precisa de isolamento de carga de trabalho, mas também deseja alta relação custo-benefício e taxas de utilização de recursos.

  
  

Apache Doris oferece suporte ao isolamento de carga de trabalho com base na etiqueta de recurso e no grupo de carga de trabalho. A etiqueta de recurso isola os recursos de CPU e memória para diferentes cargas de trabalho no nível dos nós de backend, enquanto o mecanismo do grupo de carga de trabalho pode dividir ainda mais os recursos dentro de um nó de backend para maior utilização de recursos.

Isolamento de recursos com base na etiqueta de recursos

Vamos começar com a arquitetura do Apache Doris. Doris possui dois tipos de nós : frontends (FEs) e backends (BEs). Os nós FE armazenam metadados, gerenciam clusters, processam solicitações de usuários e analisam planos de consulta, enquanto os nós BE são responsáveis pela computação e armazenamento de dados. Assim, os nós BE são os principais consumidores de recursos.

A ideia principal de uma solução de isolamento baseada em Resource Tag é dividir os recursos de computação em grupos, atribuindo tags aos nós BE em um cluster, onde os nós BE da mesma tag constituem um Grupo de Recursos. Um Grupo de Recursos pode ser considerado uma unidade para armazenamento e computação de dados. Para dados ingeridos no Doris, o sistema gravará réplicas de dados em diferentes grupos de recursos de acordo com as configurações. As consultas também serão atribuídas aos seus grupos de recursos correspondentes para execução.

Por exemplo, se quiser separar cargas de trabalho de leitura e gravação em um cluster 3-BE, você poderá seguir estas etapas:

1. Atribuir tags de recursos aos nós BE : Vincule 2 BEs à tag "Read" e 1 BE à tag "Write".

   
   

2. Atribuir tags de recursos às réplicas de dados : Supondo que a Tabela 1 tenha 3 réplicas, vincule 2 delas à tag "Read" e 1 à tag "Write". Os dados gravados na Réplica 3 serão sincronizados com a Réplica 1 e a Réplica 2, e o processo de sincronização de dados consome poucos recursos do BE 1 e BE2.

   
   

3. Atribuir grupos de carga de trabalho a tags de recursos : as consultas que incluem a tag "Read" em seus SQLs serão roteadas automaticamente para os nós marcados com "Read" (neste caso, BE 1 e BE 2). Para tarefas de gravação de dados, também é necessário atribuir-lhes a tag "Write" para que possam ser roteados para o nó correspondente (BE 3). Dessa forma, não haverá contenção de recursos entre cargas de trabalho de leitura e gravação, exceto as despesas gerais de sincronização de dados da réplica 3 para as réplicas 1 e 2.

A Resource Tag também permite multilocação no Apache Doris. Por exemplo, os recursos de computação e armazenamento marcados com "Usuário A" são apenas para o Usuário A, enquanto aqueles marcados com "Usuário B" são exclusivos do Usuário B. É assim que Doris implementa o isolamento de recursos multilocatários com Tags de Recursos no lado BE .

A divisão dos nós BE em grupos garante um alto nível de isolamento :

• CPU, memória e E/S de diferentes locatários são fisicamente isolados.

  
  

• Um locatário nunca será afetado pelas falhas (como falhas de processo) de outro locatário.

  
  

Mas tem algumas desvantagens:

• Na separação leitura-gravação, quando a gravação dos dados é interrompida, os nós BE marcados com "Escrita" ficam ociosos. Isso reduz a utilização geral do cluster.

  
  

• Em multilocação, se você quiser isolar ainda mais diferentes cargas de trabalho do mesmo locatário atribuindo nós BE separados a cada uma delas, você precisará arcar com custos significativos e baixa utilização de recursos.

  
  

• O número de locatários está vinculado ao número de réplicas de dados. Portanto, se você tiver 5 locatários, precisará de 5 réplicas de dados. Isso é uma enorme redundância de armazenamento.

  
  

Para melhorar isso, fornecemos uma solução de isolamento de carga de trabalho baseada no Workload Group no Apache Doris 2.0.0 e aprimorada no Apache Doris 2.1.0 .

Isolamento de carga de trabalho com base no grupo de carga de trabalho

A solução baseada em Workload Group realiza uma divisão de recursos mais granular. Ele divide ainda mais os recursos de CPU e memória dentro dos processos nos nós BE, o que significa que as consultas em um nó BE podem ser isoladas umas das outras até certo ponto. Isto evita a competição de recursos nos processos de BE e otimiza a utilização de recursos.

Os usuários podem relacionar consultas a grupos de carga de trabalho, limitando assim a porcentagem de recursos de CPU e memória que uma consulta pode usar. Sob altas cargas de cluster, Doris pode eliminar automaticamente as consultas que mais consomem recursos em um grupo de carga de trabalho. Sob baixas cargas de cluster, Doris pode permitir que vários grupos de carga de trabalho compartilhem recursos ociosos.

Doris suporta limite flexível de CPU e limite rígido de CPU. O limite flexível permite que os grupos de carga de trabalho ultrapassem o limite e utilizem recursos ociosos, permitindo uma utilização mais eficiente. O limite rígido é uma garantia rígida de desempenho estável porque evita o impacto mútuo dos grupos de carga de trabalho.

(O limite flexível da CPU e o limite rígido da CPU são contraditórios entre si. Você pode escolher entre eles com base em seu próprio caso de uso.)

Suas diferenças em relação à solução baseada em Resource Tag incluem:

• Grupos de carga de trabalho são formados dentro de processos. Vários grupos de carga de trabalho competem por recursos no mesmo nó BE.

  
  

• A consideração da distribuição de réplicas de dados está fora de cogitação porque o Grupo de carga de trabalho é apenas uma forma de gerenciamento de recursos.

Limite suave da CPU

O limite flexível da CPU é implementado pelo parâmetro cpu_share , que é conceitualmente semelhante aos pesos. Grupos de carga de trabalho com maior cpu_share receberão mais tempo de CPU durante um intervalo de tempo.

Por exemplo, se o Grupo A estiver configurado com cpu_share de 1 e o Grupo B, 9. Em um intervalo de tempo de 10 segundos, quando o Grupo A e o Grupo B estiverem totalmente carregados, o Grupo A e o Grupo B poderão consumir 1s e 9s de tempo de CPU, respectivamente.

O que acontece em casos reais é que nem todas as cargas de trabalho no cluster funcionam com capacidade total. Sob o limite flexível, se o Grupo B tiver uma carga de trabalho baixa ou nula, o Grupo A poderá usar todos os 10s de tempo de CPU, aumentando assim a utilização geral da CPU no cluster.

Um limite flexível traz flexibilidade e uma maior taxa de utilização de recursos. Por outro lado, pode causar flutuações de desempenho.

Limite rígido da CPU

O limite rígido da CPU no Apache Doris 2.1.0 foi projetado para usuários que exigem desempenho estável. Em termos simples, o limite rígido da CPU define que um grupo de carga de trabalho não pode usar mais recursos de CPU do que seu limite, independentemente de haver recursos de CPU ociosos ou não.

É assim que funciona:

Suponha que o Grupo A esteja definido com cpu_hard_limit=10% e o Grupo B com cpu_hard_limit=90% . Se o Grupo A e o Grupo B forem executados com carga total, o Grupo A e o Grupo B usarão, respectivamente, 10% e 90% do tempo total da CPU. A diferença está em quando a carga de trabalho do Grupo B diminui. Nesses casos, independentemente de quão alta seja a carga de consulta do Grupo A, ele não deverá utilizar mais do que 10% dos recursos de CPU alocados a ele.

Ao contrário de um limite flexível, um limite rígido garante um desempenho estável do sistema à custa da flexibilidade e da possibilidade de uma taxa de utilização de recursos mais elevada.

Limite de recursos de memória

A memória de um nó BE compreende as seguintes partes:

• Memória reservada para o sistema operacional.

  
  

• Memória consumida por não consultas, que não é considerada nas estatísticas de memória do Grupo de Carga de Trabalho.

  
  

• A memória é consumida por consultas, incluindo gravação de dados. Isso pode ser rastreado e controlado pelo Workload Group.

  
  

O parâmetro memory_limit define a memória máxima (%) disponível para um grupo de carga de trabalho no processo BE. Também afeta a prioridade dos Grupos de Recursos.

No status inicial, um grupo de recursos de alta prioridade receberá mais memória. Ao configurar enable_memory_overcommit , você pode permitir que Grupos de Recursos ocupem mais memória do que os limites quando houver espaço ocioso. Quando a memória estiver fraca, Doris cancelará tarefas para recuperar os recursos de memória que elas comprometeram. Nesse caso, o sistema reterá o máximo possível de recursos de memória para grupos de recursos de alta prioridade.

Fila de consulta

Acontece que o cluster está realizando mais cargas do que pode suportar. Neste caso, o envio de novas solicitações de consulta não será apenas infrutífero, mas também interromperá as consultas em andamento.

Para melhorar isso, o Apache Doris fornece o mecanismo de fila de consulta . Os usuários podem limitar o número de consultas que podem ser executadas simultaneamente no cluster. Uma consulta será rejeitada quando a fila de consultas estiver cheia ou após um tempo limite de espera, garantindo assim a estabilidade do sistema sob cargas elevadas.

O mecanismo de fila de consulta envolve três parâmetros: max_concurrency , max_queue_size e queue_timeout .

Testes

Para demonstrar a eficácia do limite flexível e do limite rígido da CPU, fizemos alguns testes.

• Ambiente: máquina única, 16 núcleos, 64 GB

  
  

• Implantação: 1 FE + 1 BE

  
  

• Conjunto de dados: ClickBench, TPC-H

  
  

• Ferramenta de teste de carga: Apache JMeter

Teste de limite flexível da CPU

Inicie dois clientes e envie consultas continuamente (ClickBench Q23) com e sem usar grupos de carga de trabalho, respectivamente. Observe que o cache de página deve ser desativado para evitar que afete os resultados do teste.

Comparando os rendimentos dos dois clientes em ambos os testes, pode-se concluir que:

• Sem configurar Workload Groups , os dois clientes consomem os recursos da CPU igualmente.

  
  

• Configurando grupos de carga de trabalho e definindo cpu_share como 2:1, a taxa de transferência dos dois clientes é 2:1. Com um cpu_share mais alto, o Cliente 1 recebe uma porção maior de recursos de CPU e oferece uma taxa de transferência mais alta.

Teste de limite rígido da CPU

Inicie um cliente, defina cpu_hard_limit=50% para o grupo de carga de trabalho e execute o ClickBench Q23 por 5 minutos em um nível de simultaneidade de 1, 2 e 4, respectivamente.

À medida que a simultaneidade de consulta aumenta, a taxa de utilização da CPU permanece em torno de 800%, o que significa que são usados 8 núcleos. Em uma máquina de 16 núcleos, isso representa 50% de utilização , o que é esperado. Além disso, como são impostos limites rígidos à CPU, o aumento na latência do TP99 à medida que a simultaneidade aumenta também é um resultado esperado.

Teste em ambiente de produção simulado

No uso no mundo real, os usuários estão particularmente preocupados com a latência da consulta, em vez de apenas com a taxa de transferência da consulta, uma vez que a latência é mais facilmente perceptível na experiência do usuário. É por isso que decidimos validar a eficácia do Workload Group em um ambiente de produção simulado.

Escolhemos um conjunto SQL que consiste em consultas que devem ser concluídas em 1s (ClickBench Q15, Q17, Q23 e TPC-H Q3, Q7, Q19), incluindo agregações de tabela única e consultas de junção. O tamanho do conjunto de dados TPC-H é de 100 GB.

Da mesma forma, realizamos testes com e sem configuração de grupos de carga de trabalho.

Como mostram os resultados:

• Sem grupo de carga de trabalho (comparando os testes 1 e 2): ao discar a simultaneidade do cliente 2, ambos os clientes experimentam um aumento de 2 a 3 vezes na latência da consulta.

  
  

• Configurando o Grupo de Carga de Trabalho (comparando os Testes 3 e 4): À medida que a simultaneidade do Cliente 2 aumenta, a flutuação de desempenho no Cliente 1 é muito menor, o que é uma prova de como ele é efetivamente protegido pelo isolamento da carga de trabalho.

Recomendações e planos

A solução baseada em Resource Tag é um plano completo de isolamento de carga de trabalho. A solução baseada em Workload Group proporciona um melhor equilíbrio entre isolamento e utilização de recursos e é complementada pelo mecanismo de fila de consultas para garantia de estabilidade.

Então, qual você deve escolher para seu caso de uso? Aqui está nossa recomendação:

• Tag de recurso : para casos de uso em que diferentes linhas de negócios de departamentos compartilham o mesmo cluster, de forma que os recursos e dados sejam fisicamente isolados para diferentes locatários.

  
  

• Grupo de carga de trabalho : para casos de uso em que um cluster realiza várias cargas de trabalho de consulta para alocação flexível de recursos.

  
  

Em versões futuras, continuaremos melhorando a experiência do usuário do Grupo de carga de trabalho e dos recursos de fila de consulta:

• Liberar espaço de memória cancelando consultas é um método brutal. Planejamos implementar isso por meio de derramamento de disco, o que trará maior estabilidade no desempenho da consulta.

  
  

• Como a memória consumida por não consultas no BE não está incluída nas estatísticas de memória do Grupo de Cargas de Trabalho, os usuários podem observar uma disparidade entre o uso de memória do processo BE e o uso de memória do Grupo de Cargas de Trabalho. Abordaremos esse problema para evitar confusão.

  
  

• No mecanismo de fila de consultas, a carga do cluster é controlada definindo a simultaneidade máxima de consultas. Planejamos habilitar a simultaneidade máxima dinâmica de consultas com base na disponibilidade de recursos no BE. Isso cria uma contrapressão no lado do cliente e, portanto, melhora a disponibilidade de Doris quando os clientes continuam enviando cargas elevadas.

  
  

• A ideia principal da Resource Tag é agrupar os nós BE, enquanto a do Workload Group é dividir ainda mais os recursos de um único nó BE. Para compreender essas ideias, os usuários primeiro precisam aprender sobre o conceito de nós BE no Doris. No entanto, do ponto de vista operacional, os utilizadores só precisam de compreender a percentagem de consumo de recursos de cada uma das suas cargas de trabalho e qual a prioridade que devem ter quando a carga do cluster estiver saturada. Assim, tentaremos descobrir uma maneira de nivelar a curva de aprendizado dos usuários, como manter o conceito de nós BE na caixa preta.

  
  

Para obter mais assistência sobre o isolamento de carga de trabalho no Apache Doris, junte-se à comunidade Apache Doris .