Prática de evolução nativa da nuvem em grande escala ByteDance Spark Shuffle

Spark é um mecanismo de computação amplamente utilizado no ByteDance e tem sido amplamente utilizado em vários cenários de processamento de dados em grande escala, aprendizado de máquina e big data. Atualmente, o número de tarefas diárias na China ultrapassou 1,5 milhão e o volume diário de leitura e gravação do Shuffle excede 500 PB. Ao mesmo tempo, os dados do Shuffle de algumas tarefas únicas podem atingir centenas de níveis de TB.

Ao mesmo tempo, o volume de trabalho e o volume de dados Shuffle ainda estão crescendo.Em comparação com o ano passado, o número de tarefas diárias este ano aumentou em 500.000, e o volume geral de dados cresceu em mais de 200 PB, atingindo 50% aumentar. Shuffle é uma função que é frequentemente acionada em trabalhos de usuário. Shuffle é usado em várias operações ReduceByKey, groupByKey, Join, sortByKey e Repartition. Portanto, em clusters Spark de grande escala , o Spark Shuffle muitas vezes se torna um gargalo para desempenho e estabilidade; os cálculos do Shuffle também envolvem operações frequentes de IO de disco e rede . A solução é reparticionar e combinar os dados de todos os nós. A seguir apresentaremos em detalhes a prática de evolução em larga escala da ByteDance na direção da nativação da nuvem Spark Shuffle.

Introdução ao Princípio Spark Shuffle

No princípio básico do modo Shuffle usado por padrão no modo Community Edition ESS, foi apenas mencionado que o cálculo do Shuffle irá reparticionar os dados.Aqui, os dados do Mapa são reorganizados em todos os Redutores. Se houver M Mappers e R Redutores, os dados da partição dos M Mappers serão particionados na partição dos R Redutores subsequentes. O processo Shuffle pode ser dividido em duas etapas - Shuffle Write e Shuffle Read. Durante a gravação aleatória, o Mapper irá dividir a partição atual em R novas partições de acordo com a partição reduzida, classificá-las e gravá-las no disco local. A saída do mapa gerada contém dois arquivos: o arquivo de índice e o arquivo de dados classificado por partição. Quando todos os mapeadores terminarem de escrever a saída do mapa, a segunda fase – fase de leitura aleatória começará. Neste momento, cada Redutor acessará todos os ESSs contendo sua Partição Redutora e lerá os dados da Partição Redutora correspondente. Aqui, o ESS onde estão localizadas todas as Partições pode ser solicitado até que o Redutor obtenha os dados de todas as Partições de Redução correspondentes.

Na fase Shuffle Fetch, cada ESS receberá todas as solicitações do Redutor e retornará os dados correspondentes. Isso gerará M vezes R níveis de conexões de rede e IO aleatórios de leitura e gravação de disco , envolvendo um grande número de leituras e gravações de disco e transmissões de rede. É por isso que o Shuffle tem solicitações muito frequentes de IO de disco e rede.

Como o Shuffle tem requisitos e consumo de recursos muito altos, a sobrecarga de CPU, disco e rede provavelmente será a causa da falha de busca ou do gargalo da velocidade lenta do Shuffle. No cenário Shuffle em grande escala da ByteDance, o mesmo nó ESS pode precisar atender vários comerciantes ao mesmo tempo, e esses clusters não realizam isolamento de IO , o que pode fazer com que o Shuffle se torne o principal motivo para falha no trabalho do usuário e um ponto problemático.

Portanto, a ByteDance começou a trabalhar na nativação da nuvem do Spark Shuffle no início de 2021, e os trabalhos do Spark e outros ecossistemas de big data começaram a migrar do Yarn Gödel. Gödel é o agendador desenvolvido pela ByteDance baseado em Kubernetes . Durante a migração, ele também fornece uma solução de migração do Hadoop para a nuvem - Yodel (Yarn on Gödel). É um protocolo totalmente compatível com o Hadoop Yarn e visa suavizar todos os grandes aplicativos de dados. Migre para o sistema Kubernetes.

Neste conjunto de trabalhos de migração, o ESS também fez trabalhos relacionados à customização, concluiu o trabalho de adaptação de migração do Yarn Auxiliary Service do modo Yarn Node Manager anterior para o modo de implantação Kubernetes DaemonSet e iniciou a migração de trabalhos Shuffle. Demorou dois anos para migrar com sucesso todos os aplicativos de big data, incluindo aplicativos Spark , para o atual ecossistema nativo da nuvem em 2023 .

Desafios nativos da nuvem

Durante o processo de migração nativa da nuvem, também encontramos muitos desafios:

Em primeiro lugar, durante a migração do NM para o DaemonSet , a CPU do ESS no DaemonSet tem restrições muito rígidas.No modo NM anterior, o ESS pode basicamente usar todos os recursos da CPU. Portanto, nesta prática de migração, os recursos de CPU do ESS inicialmente configurado são muitas vezes insuficientes e necessitam de ajustes contínuos. Mais tarde, alguns clusters de última geração usaram diretamente a CPU ESS.
Ao mesmo tempo, DaemonSet e Pod têm limites mais rígidos na CPU dos trabalhos do Spark . Isso também fez com que o trabalho de muitos usuários ficasse mais lento após a migração para a nova arquitetura. Isso ocorre porque no modo anterior a CPU estava sobrecarregada até certo ponto, então esta situação precisa ser ajustada. Habilitamos o modo CPU Shares nas arquiteturas Kubernetes e Gödel para que os usuários não percebam nenhuma diferença de desempenho durante o processo de migração.
Além disso, o Pod tem restrições de memória muito rígidas, o que resulta na incapacidade de usar recursos livres de cache de página durante a leitura aleatória , resultando em uma taxa de acertos de cache de página muito baixa durante a leitura aleatória. Nesse processo, ocorrerá mais sobrecarga de E/S de disco, resultando em um desempenho geral insatisfatório. Tomamos as medidas apropriadas para reduzir o impacto do Shuffle no desempenho após a migração, abrindo adequadamente o uso do cache de página pelo Pod.

Benefícios nativos da nuvem

Depois de concluir o trabalho de migração, unificamos com sucesso todos os pools de recursos off-line e conseguimos implementar algumas estratégias de otimização e agendamento mais amigáveis no nível de agendamento, melhorando assim a utilização geral dos recursos. O ESS Daemonset também obteve muitos benefícios em comparação com o Yarn Auxiliary Service. Em primeiro lugar, o ESS DaemonSet é independente e torna-se um serviço, rompendo com o forte acoplamento com o NM, reduzindo custos de operação e manutenção. Além disso, o isolamento dos recursos ESS por Kubernetes e Pods também aumenta a estabilidade do ESS, o que significa que o ESS não será mais afetado por outros trabalhos ou serviços no nó.

Ambiente nativo da nuvem

Atualmente, os trabalhos do Spark nativos da nuvem têm dois ambientes operacionais principais:

Ambiente de cluster de recursos estável . Esses clusters de recursos estáveis concentram-se principalmente na tarefa de atender SLA e de alta qualidade. O disco implantado é um disco SSD com melhor desempenho. Para esses clusters de recursos estáveis, usamos principalmente serviços ESS baseados na comunidade e profundamente personalizados; usamos discos SSD, leitura e gravação ESS e discos SSD locais de alto desempenho; eles são implantados no modo Daemonset e na arquitetura Gödel.
Ambiente de cluster de recursos co-localizados . Esses clusters atendem principalmente a trabalhos de médio a baixo nível, concentrando-se em algumas tarefas temporárias de consulta, depuração ou teste. Os recursos destes clusters são implementados principalmente em discos HDD , e alguns são transferidos através de recursos online ou partilhados com outros serviços, ou são implementados em conjunto com outros serviços online. Isso significa que os recursos do cluster não são exclusivos e o desempenho geral do disco e o ambiente de armazenamento não são particularmente excelentes.

Cenário de recursos estável

Como existem muitos trabalhos de alta qualidade em um ambiente de cluster estável, a primeira tarefa é melhorar a estabilidade do Shuffle desses trabalhos e a duração do trabalho durante o tempo de execução para garantir o SLA desses trabalhos. Para resolver o problema do Shuffle, os três recursos a seguir foram profundamente customizados para o ESS: aprimorar os recursos de monitoramento/governança do ESS, adicionar a função de limitação de corrente do ESS Shuffle e adicionar a função de divisão de overflow do Shuffle .

Personalização profunda do ESS

Melhorar as capacidades de monitorização e governação do ESS

Capacidades de monitoramento

Em termos de monitoramento, durante o processo de utilização da versão de código aberto , descobrimos que o monitoramento existente não era suficiente para solucionar profundamente os problemas encontrados no Shuffle e o status atual do ESS. Como resultado, não há como localizar rapidamente quais nós estão causando o problema do Shuffle e não há como detectar os nós problemáticos. Portanto, fizemos algumas melhorias em nossos recursos de monitoramento.

Primeiro, foram adicionados alguns indicadores-chave para monitorar a lentidão do Shuffle e os recursos de taxa de busca, incluindo Queued Chunks e Chunk Fetch Rate. Queued Chunks é usado para monitorar o acúmulo de solicitações nos nós ESS solicitados atualmente, enquanto Chunk Fetch Rate é usado para monitorar o tráfego de solicitações nesses nós. Ao mesmo tempo, também conectamos os indicadores de métricas do ESS ao sistema de métricas da ByteDance, permitindo-nos localizar rapidamente o acúmulo de nós ESS por meio dos indicadores de dimensão do aplicativo fornecidos pelo sistema. Em termos de interface do usuário (IU), nossa melhoria é adicionar duas novas funções à página de detalhes do estágio , que são usadas para exibir os nós mais lentos encontrados por cada tarefa aleatória no estágio atual, bem como todos os encontros de tarefas após as estatísticas do estágio. Para o nó superior com mais tempos de Shuffle. As operações acima não apenas facilitam as consultas dos usuários, mas também utilizam esses indicadores para construir mercados relevantes.

Com essas melhorias de monitoramento e IU, quando os usuários perceberem que o Shuffle está lento na IU, eles poderão abrir o monitoramento Shuffle correspondente por meio da IU. Isso facilita aos usuários e a nós localizar rapidamente os nós ESS que causam problemas de Shuffle e ver rapidamente a situação real nesses nós, de modo a localizar rapidamente de quais aplicativos vêm essas solicitações acumuladas.

O novo monitoramento também detectará indicadores-chave, como acúmulo real de pedaços e latência no nó ESS durante a execução e solução de problemas do Shuffle . Isso ajuda a agir com mais eficiência em tempo real quando o Shuffle está lento. Uma vez localizado o problema do Shuffle, podemos analisar a situação e fornecer orientação e otimização de governança.

Capacidade de governança

O trabalho de governança é implementado principalmente através do sistema BatchBrain . BatchBrain é um sistema inteligente de ajuste de trabalho especialmente projetado para trabalhos Spark . Ele coleta principalmente dados de trabalho e realiza análises offline e em tempo real. Esses dados coletados incluem o log de eventos do próprio Spark, eventos internos mais detalhados da linha do tempo e vários indicadores de métricas , incluindo indicadores Shuffle personalizados adicionados ao ESS.

Na análise off-line, é necessário principalmente gerenciar trabalhos periódicos. Com base nas características históricas de cada trabalho e nos dados coletados, o desempenho desses trabalhos no Estágio Shuffle é analisado. Após vários ajustes iterativos, um conjunto de parâmetros Shuffle adequados é finalmente fornecido . , para que esses trabalhos possam executar os parâmetros Shuffle otimizados ao serem executados novamente, obtendo assim melhor desempenho e resultados.

O BatchBrain também pode usar os indicadores Shuffle adicionados anteriormente para verificação automática na parte de análise em tempo real. Os usuários também podem consultar o status de embaralhamento de tarefas em seu cluster por meio da API BatchBrain , localizar efetivamente nós e trabalhos que sofrem acúmulo de embaralhamento e notificar o pessoal relevante por meio de alarmes. Se for descoberto que o Shuffle está lento devido a outros trabalhos ou trabalhos anormais, os usuários também podem tomar ações diretas de gerenciamento, como interromper ou expulsar esses trabalhos, para liberar mais recursos para trabalhos de maior prioridade para o Shuffle.

Função de limitação de corrente aleatória

Através do monitoramento e gerenciamento do Shuffle, descobrimos que quando o Shuffle está lento nos nós ESS, geralmente é porque o volume de dados de algumas tarefas é muito grande ou parâmetros inadequados são definidos, resultando no número de Mapeadores e Redutores desses Estágios do Shuffle sendo muito alto. Excepcionalmente grande. Um número anormalmente grande de Mapeadores e Redutores pode causar um grande acúmulo de solicitações no nó ESS, e o tamanho do bloco dessas solicitações também pode ser muito pequeno. O tamanho médio do pedaço de alguns trabalhos anormais pode não chegar a 20 KB. Esses trabalhos enviam uma grande quantidade de solicitações ao ESS, mas a falha do ESS em processá-las a tempo pode eventualmente levar a uma pilha de solicitações, até mesmo causar atrasos no trabalho ou levar diretamente à falha.

Em resposta a estes fenómenos, a solução que adoptámos é limitar o número total de pedidos para cada Aplicação no nó ESS. Quando as solicitações de busca de um aplicativo atingirem o limite superior, o ESS rejeitará novas solicitações de busca enviadas pelo aplicativo até que o aplicativo aguarde o término da solicitação existente antes de poder continuar a enviar novas solicitações. Isso evita que um único Aplicativo ocupe recursos excessivos no nó e faça com que o ESS não consiga atender adequadamente outras solicitações de tarefa. Ele também pode evitar que outros trabalhos falhem ou que a velocidade do Shuffle diminua e aliviar o impacto negativo de trabalhos Shuffle anormais ou em grande escala no cluster Shuffle.

Recursos da função de limitação de corrente Shuffle

Quando o trabalho estiver funcionando normalmente, mesmo que a função de limitação atual seja iniciada, isso não terá nenhum impacto no trabalho. Se o nó puder atender normalmente, não há necessidade de acionar qualquer limitação de corrente.
Somente quando a carga do nó exceder a faixa tolerável e o Shuffle IO exceder o limite definido, o mecanismo de limitação de corrente será ativado para reduzir o número de solicitações que tarefas anormais podem enviar ao ESS e reduzir a pressão atual no serviço ESS. Como a capacidade de carga do serviço ESS excedeu a faixa tolerável neste momento, mesmo que receba essas solicitações, ele não poderá retornar essas solicitações normalmente. Portanto, limitar solicitações excessivas para tarefas anormais pode melhorar melhor o desempenho dessas próprias tarefas.
No caso de limitação de corrente, também será considerada a prioridade do trabalho. Para tarefas de alta qualidade, será permitido maior tráfego.
Quando o limite atual entrar em vigor, se for constatado que o tráfego ESS voltou ao normal, o limite atual será rapidamente eliminado. Os aplicativos com tráfego restrito podem retornar rapidamente aos níveis de tráfego anteriores.

Fluxo detalhado de limitação de corrente

A função de limitação de corrente é executada principalmente no servidor ESS. O indicador de latência é verificado no nó a cada 5 segundos. Quando o indicador de latência excede o limite definido, será determinado que a carga do nó excedeu a carga que pode suportar . Em seguida, todos os aplicativos atualmente em processo de Shuffle no nó ESS serão avaliados para determinar se a limitação de corrente deve ser habilitada. Usando os indicadores adicionados anteriormente, podemos contar o tráfego total de busca e IO neste nó nos últimos 5 minutos . De acordo com o limite superior do tráfego total, o tráfego de cada aplicativo atualmente executando o Shuffle em cada nó ESS pode ser razoavelmente alocado e restrito. . A distribuição do tráfego também é ajustada com base na prioridade do Aplicativo. Se o Shuffle de qualquer aplicativo ou a Chunk Fetch Rate atualmente acumulada exceder o tráfego alocado, eles serão limitados e as solicitações recém-enviadas serão rejeitadas até que as solicitações acumuladas tenham sido parcialmente liberadas.

Existe também um sistema escalonado para a distribuição dos limites atuais. Primeiro, a alocação é baseada no número de aplicativos que executam o Shuffle no nó atual . Quanto maior o número de aplicativos, menos tráfego cada aplicativo pode ser alocado. Quando o número de aplicativos em um nó é relativamente pequeno, cada aplicativo pode receber mais tráfego. O nível limite atual também será ajustado a cada 30 segundos com base na situação real do nó.

No caso da limitação de corrente, se a latência no nó não melhorar e o tráfego total do Shuffle não se recuperar, a limitação de corrente será atualizada e restrições de tráfego mais rigorosas serão impostas a todas as aplicações. Pelo contrário, se a latência melhorar ou o tráfego do nó estiver a recuperar, o limite atual será reduzido ou mesmo aumentado diretamente. Finalmente, o limite atual também é ajustado adequadamente com base na prioridade de todos os trabalhos.

Efeitos e benefícios

Os problemas de empilhamento de pedaços são significativamente atenuados. Devido à limitação de corrente , o acúmulo de Chunk causado por tarefas anormais é efetivamente reduzido, o que reduz bastante o acúmulo de um grande número de solicitações em alguns nós do cluster.

Além disso, a situação da Latência também foi melhorada. Antes de ativar a limitação de corrente, frequentemente vemos alta latência nos nós do cluster. Depois de ativar a função de limitação de corrente, a situação geral de latência foi significativamente aliviada. Ao reduzir solicitações desnecessárias e inválidas e limitar o número de solicitações iniciadas por várias tarefas grandes ou anormais para nós ESS, evitamos o impacto negativo dessas tarefas anormalmente grandes na carga do serviço ESS e reduzimos a necessidade de outras tarefas de alta qualidade para correr. Impacto.

Função de divisão de estouro aleatório

Ao analisar alguns trabalhos Shuffle lentos , também descobrimos outro fenômeno: a quantidade de dados Shuffle gravados por cada Executor em um trabalho pode ser muito desigual. Como o ESS utiliza o mecanismo de Alocação Dinâmica, o tempo de execução de cada Executor e o número de Tarefas de Mapa alocadas podem ser diferentes. Isso faz com que uma grande quantidade de dados do Shuffle seja concentrada em alguns Executores durante a execução do trabalho, fazendo com que os dados do Shuffle sejam realmente concentrados em alguns nós.

Por exemplo, na figura abaixo, descobrimos que o volume de gravação Shuffle de 5 Executores excede o de outros Executores em mais de 10 vezes. Neste caso, as solicitações Shuffle podem estar concentradas nesses nós, fazendo com que a carga nesses nós ESS seja muito alta, o que também aumenta indiretamente a possibilidade de Fetch Failure.

Para esta situação, a solução que oferecemos é controlar a quantidade total de dados Shuffle gravados no disco por cada contêiner ou nó. Esta função pode ser alcançada sob duas perspectivas. Primeiro, o próprio Spark controla o Shuffle Write Size do Executor, que é a quantidade máxima de dados gravados por cada Executor ao executar o Shuffle. Cada Executor calculará a quantidade de dados Shuffle que está gravando no momento e reportará essas informações ao Spark Driver. O Spark Driver pode usar o mecanismo Excluir em caso de falha para excluir proativamente Executores cujos dados gravados excederam o limite do escopo de agendamento e reciclar esses Executores. Além disso, também melhoramos a estratégia de escalonamento através do escalonador Gödel e tentamos escalonar novos Executores para outros nós para evitar a gravação excessiva de dados em um único contêiner, o que fará com que o disco do nó fique cheio, ou o conjunto de dados no estágio Shuffle Fetch serão preenchidos nesses nós ESS.

Otimização nativa da nuvem

Ao mesmo tempo, algumas otimizações de agendamento e função do Executor também foram feitas na nativação da nuvem. Através da estratégia do agendador Gödel, as capacidades do Shuffle são melhoradas.Ao agendar Executores, alguns nós com alta carga de Shuffle podem ser evitados tanto quanto possível, aliviando assim a possibilidade de esses nós encontrarem problemas de Shuffle. O agendador também pode fornecer funções mais completas para Executores, expulsando Executores em nós com pressão de disco particularmente alta ou despejando alguns contêineres que gravaram uma grande quantidade de Shuffle no disco quando o espaço restante em disco é insuficiente. O controle do Spark Driver do Executor's Shuffle combinado com essas funções de agendamento nativas da nuvem pode dispersar os dados gerais do Shuffle para mais nós, tornando os dados do estágio Shuffle Fetch e o volume de solicitações mais equilibrados.

Efeito

Depois de ativar a otimização Shuffle online profundamente personalizada mencionada acima, observamos efeitos significativos. A seguir estão alguns dados operacionais de três clusters de alta qualidade. O número total de tarefas nesses três clusters de alta qualidade todos os dias pode exceder 300.000, mas o número médio de trabalhos que falham devido à falha do Shuffle Fetch é de cerca de 20 a 30. por dia. Pode-se dizer que foi alcançada uma taxa de falha inferior a 1/10000. Conforme mostrado na figura acima, pode-se observar que a estabilidade desses três clusters de alta qualidade foi significativamente melhorada após a otimização, e os problemas encontrados pelos usuários no Shuffle também foram bastante reduzidos.

Cenário de recursos mistos

Vale a pena notar na otimização de cenários de cluster de co-localização que a falha de busca geralmente é muito mais séria do que em um ambiente de recursos estáveis. O número médio de falhas de busca por dia é muito alto. A principal razão é que a maioria desses recursos vem da transferência de recursos on-line ociosos e seus recursos de E/S de disco e espaço em disco são relativamente limitados. Além disso, alguns recursos são implantados misturados com HDFS ou outros serviços. Como o IOPS do disco e o espaço em disco podem ser muito limitados, isso tem um impacto maior no desempenho do cluster Shuffle, portanto a probabilidade de falha também é alta. O principal objetivo do gerenciamento de recursos de co-localização é reduzir a taxa de falha de empregos e garantir a estabilidade dos empregos.Ele também precisa melhorar o desempenho do Shuffle de todo o cluster e reduzir o desperdício de recursos.

Para clusters com recursos mistos , a principal solução é o Cloud Shuffle Service ( CSS ) autodesenvolvido , que reduz a dependência desses trabalhos em discos locais, fornecendo um serviço Shuffle remoto.

Introdução às funções CSS

O modo Push Based Shuffle é diferente do modo ESS recém-introduzido. No modo Push Based Shuffle, os mesmos dados da partição redutora de diferentes mapeadores serão enviados para um serviço remoto comum, mesclados neste serviço e, finalmente, em um determinado serviço Write. ou mais arquivos no Worker para que os dados da partição possam ser lidos através do modo de leitura sequencial durante o estágio de redução, reduzindo a sobrecarga de E/S aleatória .
Suporta a função Partition Group , que é usada para alocar dados de múltiplas partições para um Grupo de Partições Redutoras. Desta forma, durante o estágio Map, o Mapper pode transferir dados através do Batch Push e transferir diretamente os dados do lote para os nós de trabalho do grupo de partição correspondente, reduzindo assim a sobrecarga de IO no modo batch e melhorando o desempenho do modo batch.
A função rápida de backup de gravação dupla usa o modo aleatório e de agregação baseado em push. Todos os dados são realmente coletados em um Worker. Se os dados do Worker forem perdidos, todos os mapeadores terão que recalcular os dados correspondentes. Portanto, para a função de agregação push, é importante usar um backup de gravação dupla. CSS melhora a velocidade de gravação adotando o modo de cópia de gravação dupla na memória e executando a limpeza assíncrona do disco, para que o mapeador possa continuar a enviar dados subsequentes sem esperar que a escovação do disco termine.
Função de balanceamento de carga , CSS gerencia nós em todos os serviços por meio de um Cluster Manager. O Cluster Manager coletará e coletará regularmente informações de carga relatadas pelos nós CSS Worker. Quando um novo aplicativo for enviado, ele executará a alocação equilibrada de recursos para garantir que Shuffle Write e Shuffle Read sejam alocados para clusters com taxas de utilização mais baixas. Nós para obter melhores Embaralhe o balanceamento de carga no cluster.

Estrutura geral

O Cluster Manager é responsável pela alocação de recursos do cluster e pela manutenção do status do trabalhador e do aplicativo do cluster. Ele pode salvar essas informações através do Zookeeper ou disco local para obter serviços com alta disponibilidade.
Worker oferece suporte a dois modos de gravação, nomeadamente modo de disco e modo HDFS . Atualmente, o modo de disco é comumente usado e os dados de cada partição são gravados em dois nós de trabalho diferentes para obter redundância de dados.
CSS Master está localizado no lado do driver Spark e é o principal responsável pelo contato de pulsação com o Cluster Manager e o Application Lifecycle. Quando um trabalho é iniciado, ele também se candidata a um Worker do Cluster Manager. O processo do Shuffle Stage também contará os metadados e o progresso do Shuffle Stage.
Shuffle Client é um componente conectado à API Spark Shuffle, permitindo que qualquer trabalho do Spark use CSS diretamente , sem configuração adicional. Cada Executor usará ShuffleClient para leitura e escrita. O Shuffle Client é responsável pela gravação dupla durante a gravação. Ao ler, ele pode ler os dados de qualquer Worker que tenha dados. Se um dos Workers falhar na leitura, ele mudará automaticamente para outro Worker e desduplicará os dados que foram lidos várias vezes .

processo de leitura e escrita

Quando CSS é escrito, o Worker enviará os dados diretamente, e o Mapper enviará os dados para dois Workers ao mesmo tempo. O Worker não esperará até que o disco seja descarregado e retornará ao Mapeador, mas retornará o resultado ao Mapper de forma assíncrona . Se encontrar uma falha, será enviado ao próximo Worker. Solicitação para notificar o Mapper. Neste momento, o Mapper solicitará novamente dois novos trabalhadores do nó e enviará novamente os dados com falha. Durante a leitura, os dados podem ser lidos de qualquer nó e desduplicados por meio de Map ID, Attempt ID e Batch ID.

Desempenho e evolução futura

No teste de desempenho de benchmark TPC-DS de 1 TB, o CSS foi melhorado em mais de 30% na consulta.

Como um serviço Shuffle remoto, o CSS é particularmente adequado para nativação em nuvem, oferece suporte a implantação flexível ou oferece suporte a serviços de economia mais remotos. Atualmente, o CSS também é de código aberto. Amigos interessados podem acessar o site de código aberto do CSS para obter mais informações. Também esperamos que algumas iterações e otimizações subsequentes possam ser sincronizadas com a comunidade. Na evolução futura do nativo da nuvem, é necessário apoiar a implantação elástica, serviços de armazenamento remoto e outras capacidades relacionadas.

GitHub:github.com/bytedance/CloudShuffleService