Mover Média Hadoop

Eu me deparei com este artigo: que menciona como calcular a média móvel usando o Hadoop. Observe que todos os registros de uma CHAVE devem ser classificados e depois reduzidos. Agora, suponha que os registros de uma determinada CHAVE estejam espalhados por todos os fragmentos do cluster Mongo. Nesse caso, seria possível calcular a média móvel Eu entendo que Mongo faz o mapa reduzir em cada nó. O requisito principal para resolver este problema é garantir que todos os emissos para um mapa sejam reduzidos em uma única fase de redução. Se for esse o caso, Mongo Map Reduce nunca poderá resolver esses problemas. Existe algum mal-entendido básico. Além disso, com bilhões de linhas e petabytes de dados, por que a Hadoop Reduzir a fase não faz falta na memória, uma vez que tem que lidar com pelo menos várias TBs de dados mapeados. Perguntou 16 de maio 13 às 7:31 Você pode explicar por que Hadoop não afastou a memória por essa computação. Da minha compreensão, toda a redução acontecerá em um nó, onde todos os registros de uma CHAVE serão reduzidos. Isso deve resultar em uma enorme sobrecarga de memória nesse nó, uma vez que as TBs de dados precisam estar presentes lá. Como Hadoop lida com uma enorme quantidade de dados ndash P. Prasad 16 de maio 13 às 8:29 Eu acredito que, ao contrário de MongoDB, o hadoop, assim como o SQL ao processar uma grande associação, irá escrever coisas no disco e ler somente quando necessário O sistema operacional usando swap como suporte de memória temporário para certas coisas provavelmente. MongoDB faz mais na RAM antes de gravar no disco, como tal, irá facilmente resgatar o ndash Sammaye 16 de maio 13 em 8: 37David, sim, MapReduce destina-se a operar em uma grande quantidade de dados. E a idéia é que, em geral, o mapa e reduzir as funções não devem se preocupar com quantos mapeadores ou quantos redutores existem, isso é apenas otimização. Se você pensa cuidadosamente sobre o algoritmo que postei, você pode ver que não importa qual mapeador recebe as partes dos dados. Cada registro de entrada estará disponível para cada operação de redução que o necessite. Ndash Joe K 18 de setembro 12 às 22:30 Na melhor das minhas compreensões, a média móvel não é bem mapas para o paradigma MapReduce, uma vez que seu cálculo é basicamente uma janela deslizante sobre dados classificados, enquanto a MR é o processamento de intervalos não interceptados de dados ordenados. A solução que vejo é a seguinte: a) Implementar particionador personalizado para poder fazer duas partições diferentes em duas execuções. Em cada corrida, seus redutores obterão diferentes faixas de dados e calcularão a média móvel quando apropriado vou tentar ilustrar: Em dados de primeira execução para redutores devem ser: R1: Q1, Q2, Q3, Q4 R2: Q5, Q6, Q7, Q8 . Aqui você irá calcular a média móvel para alguns Qs. Na próxima execução, seus redutores devem obter dados como: R1: Q1. Q6 R2: Q6. Q10 R3: Q10..Q14 E caclule o resto das médias móveis. Então você precisará agregar resultados. Idéia de compartilhamento personalizado que terá dois modos de operação - cada vez que se divide em intervalos iguais, mas com alguma mudança. Em um pseudocódigo, será assim. Partição (keySHIFT) (MAXKEY numOfPartitions) onde: SHIFT será retirado da configuração. MAXKEY valor máximo da chave. Eu assumo por simplicidade que eles começam com zero. RecordReader, IMHO não é uma solução, uma vez que está limitado a divisão específica e não pode deslizar sobre o limite das divisões. Outra solução seria implementar lógica personalizada de dados de entrada de divisão (é parte do InputFormat). Pode ser feito para fazer 2 slides diferentes, semelhante ao particionamento. Respondeu 17 de setembro 12 às 8:59