Kudu FAQ - E-MapReduce: Central de Documentação do Alibaba Cloud

Respostas para perguntas comuns sobre o Kudu no EMR.

Geral

Onde ficam armazenados os arquivos de log do Kudu?

Os arquivos de log do Kudu estão em /mnt/disk1/log/kudu/@filepath.

Quais métodos de particionamento o Kudu suporta?

O Kudu suporta particionamento por intervalo e por hash. É possível combinar os dois métodos. Para mais detalhes, consulte Design de esquema do Apache Kudu.

Como acesso a interface web do Kudu?

O Kudu não tem integração com o Knox. Crie um túnel SSH para acessar a interface web. Para obter instruções, consulte Criar um túnel SSH para acessar interfaces web de componentes open source.

Onde encontro as perguntas frequentes da comunidade Kudu?

Consulte a página de Solução de problemas do Apache Kudu.

Erros de inicialização

`NonRecoverableException` ao conectar o cliente Kudu

Esse erro indica que a quantidade de nós mestre configurada no cliente difere da esperada pelo cluster:

org.apache.kudu.client.NonRecoverableException: Could not connect to a leader master. Client configured with 1 master(s) (192.168.0.10:7051) but cluster indicates it expects 3 master(s) (192.168.0.36:7051,192.168.0.11:7051,192.168.0.10:7051)

Implante todos os nós mestre necessários e conecte o cliente Kudu ao nó mestre primário.

Falha na inicialização do Kudu devido a defeito no monitor Bigboot

Um defeito na versão V3.5.0 do Bigboot impede a reinicialização do Kudu após uma falha. O monitor do Bigboot não remove informações obsoletas de serviço do banco de dados e causa falhas nas tentativas subsequentes de reinicialização.

Interrompa o Kudu e inicie-o novamente diretamente na máquina com os comandos a seguir.

Execute os comandos abaixo em um nó core ou task. Se executá-los em um nó mestre, substitua kudu-tserver por kudu-master.

/usr/lib/b2monitor-current/bin/monictrl -stop kudu-tserver
/usr/lib/b2monitor-current/bin/monictrl -start kudu-tserver

Nota

Execute esses comandos na própria máquina. O console do EMR pode não conseguir parar o serviço porque ele já foi encerrado.

Erro de sincronização de relógio impede a inicialização do Kudu

Este erro ocorre quando o ntpd não consegue se conectar ao servidor NTP configurado:

Service unavailable: RunTabletServer() failed: Cannot initialize clock: timed out waiting for clock synchronisation: Error reading clock. Clock considered unsynchronized

Os logs também podem incluir uma saída semelhante a:

E1010 10:37:54.165313 29920 system_ntp.cc:104] /sbin/ntptime
------------------------------------------
stdout:
ntp_gettime() returns code 5 (ERROR)
  time e6ee0402.2a452c4c  Mon, Oct 10 2022 10:37:54.165, (.165118697),
  maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 187.830 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x2041 (PLL,UNSYNC,NANO),
  time constant 6, precision 0.001 us, tolerance 500 ppm,

Reinicie o servidor e tente novamente.

Erros de tempo de execução

Erro de rede: impossível resolver o nome do host

Bad status: Network error: Could not obtain a remote proxy to the peer.: unable to resolve address for <hostname>: Name or service not known

Esse erro ocorre quando não é possível resolver um nome de host para um endereço IP. Sem um mapeamento válido, o par Raft do tablet Kudu não identifica seus pares e encerra a conexão.

Solução 1: Adicione o mapeamento de nome de host para IP no arquivo /etc/hosts/@filepath.

Solução 2: Se o host associado ao nome tiver sido liberado, adicione um mapeamento entre o nome do host e qualquer endereço IP no arquivo /etc/hosts/@filepath. O endereço IP não precisa ser acessível. Após criar o mapeamento, o servidor de tablet do Kudu replica os dados do servidor Raft indisponível para um novo servidor Raft no grupo Raft.

Erro de integridade do layout do sistema de arquivos

Bad status: I/O error: Failed to load Fs layout: could not verify integrity of files: <directory>, <number> data directories provided, but expected <number>

A quantidade de discos especificada por -fs_data_dirs não corresponde aos metadados registrados por -fs_metadata_dir. Atualize o parâmetro -fs_data_dirs para que a contagem de discos corresponda ao valor registrado em -fs_metadata_dir.

Falha na criação de thread (erro 11 em `pthread_create`)

pthread_create failed: Resource temporarily unavailable (error 11)

Verifique as causas a seguir nesta ordem.

Limites de processo insuficientes

Verifique o limite atual para o máximo de processos de usuário:

ulimit -a

Se o valor estiver muito baixo, aumente-o modificando o arquivo /etc/security/limits.conf/@filepath ou criando o arquivo /etc/security/limits.d/kudu.conf/@filepath.

Vazamento de threads no cliente Kudu V0.8 em implantações híbridas

Em implantações híbridas, os executores do Spark podem apresentar vazamento de threads ao usar o cliente Kudu V0.8. Trata-se de um problema conhecido, documentado em KUDU-1453. Atualize para o cliente Kudu V0.9 para resolver a questão.

Vazamento de thread de desligamento no Trino

Ao sair do Trino, a thread do hook de desligamento bloqueia no método take da classe BlockingQueue enquanto aguarda um elemento. Como essa thread não pode ser interrompida, o controle do EMR continua enviando sinais SIGTERM e gera novas threads de tratamento de SIGTERM até atingir o limite de processos.

Corrija o problema no lado do Trino ou force o encerramento do processo com kill -9.

Vazamento de pool de threads do Jindo SDK

O Spark utiliza a classe JindoOssCommitter para jobs de escrita. Essa classe cria um objeto JindoOssMagicCommitter que gera um pool de threads chamado oss-committer-pool. O pool de threads não é estático e nunca é encerrado. Conforme novos objetos JindoOssMagicCommitter são criados, os pools de threads se acumulam sem liberação. Esse cenário é especialmente provável em cargas de trabalho do Spark Streaming ou Structured Streaming.

Adicione os seguintes parâmetros do Spark como solução alternativa:

spark.sql.hive.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
spark.sql.sources.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter

Identificar o processo com mais threads

Use o script threads_monitor.sh/@filepath abaixo para identificar qual processo consome mais threads:

#!/bin/bash

total_threads=0
max_pid=-1
max_threads=-1

for tid in `ls /proc`
do
  if [[ $tid != *self && -f /proc/$tid/status ]]; then
    num_threads=`cat /proc/$tid/status | grep Threads | awk '{print $NF}'`
    ((total_threads+=num_threads))
    if [[ ${max_pid} -eq -1 || ${max_threads} -lt ${num_threads} ]]; then
      max_pid=${tid}
      max_threads=${num_threads}
    fi
#    echo "Thread ${pid}: ${num_threads}"
  fi
done

echo "Total threads: ${total_threads}"
echo "Max threads: ${max_threads}, pid is ${max_pid}"
ps -ef | grep ${max_pid} | grep -v grep

Limite flexível de memória excedido

Rejecting Write request: Soft memory limit exceeded

O throughput de escrita ultrapassou o limite flexível de memória. Para resolver, ajuste um dos seguintes parâmetros:

Configure o parâmetro memory_limit_hard_bytes/@parmname para aumentar o tamanho da memória. O valor padrão é 0, o que indica que o sistema define automaticamente o uso máximo de memória. Altere o valor para -1 para remover qualquer limite de uso de memória.
Configure o parâmetro memory_limit_soft_percentage/@parmname para ajustar a porcentagem de memória disponível. O valor padrão é 80.

Configuração da lista de permissões do Kudu e renovação de token

O EMR oferece um botão para ativar ou desativar manualmente a lista de permissões do Kudu?

Problema: Você deseja ativar ou desativar a lista de permissões do Kudu pelo console do EMR.

Solução: O EMR não fornece um botão dedicado para esse recurso. A lista de permissões é um item de configuração personalizado adicionado manualmente. Após modificar o arquivo de configuração, reinicie o serviço Kudu para aplicar as alterações. Não é possível alternar entre o modo de acesso total e o modo de acesso parcial sem reiniciar o serviço.

É necessário reiniciar o serviço Kudu para renovar um token expirado?

Problema: O token do serviço Kudu expirou e você precisa renová-lo.

Solução: Sim. Reinicie o serviço Kudu para renovar o token.

Erro: "Unable to open the Kudu table" ou "Unable to initialize the Kudu scan node" ao consultar tabelas Kudu via Impala

Problema: Você recebe um dos erros abaixo ao usar o Impala para consultar tabelas Kudu:

Unable to open the Kudu table
Unable to initialize the Kudu scan node

Causa: Geralmente, esse erro resulta de um token do Kudu Master expirado, falha na obtenção do líder ou falha de autenticação. O problema não está relacionado às configurações do Ranger.

Solução:

Adicione a sub-rede do cliente (por exemplo, 10.85.0.0/16) à configuração da lista de permissões do Kudu.
Reinicie o serviço Kudu.

Perguntas frequentes sobre a reinicialização do Kudu

O console fica carregando indefinidamente ao reiniciar o serviço Kudu

Problema: Ao reiniciar o serviço Kudu, a página do console permanece exibindo um indicador de carregamento.

Solução: Esse comportamento pode ocorrer se sua sessão de login tiver expirado e causado problemas na atualização da página, ou porque o processo de reinicialização do serviço leva tempo para atualizar o status. Atualize a página ou verifique o histórico de operações.

Posso executar consultas no Impala durante a reinicialização do serviço Kudu?

Problema: Você quer saber se é possível consultar dados durante a reinicialização do serviço Kudu.

Solução: Recomendamos não executar consultas durante a reinicialização. Embora o serviço Impala possa permanecer disponível, as consultas que envolvem tabelas Kudu falharão devido a interrupções de conexão.

O serviço apresenta status anormal ou solicita a inicialização manual de outros serviços após reiniciar o Kudu

Problema: Após reiniciar o serviço Kudu, o console mostra um status anormal ou solicita que você inicie manualmente outros serviços.

Solução: Nenhuma ação manual é necessária. O status anormal geralmente aparece porque as verificações de saúde detectam que o serviço ainda não iniciou completamente. Se o serviço se recuperou automaticamente e o nó Master consegue executar consultas, a reinicialização foi concluída. Não há necessidade de iniciar outros serviços manualmente.