Cache de aplicações do mapa no Hadoop MapReduce?

Question

Olhando para a combinação de MapReduce e HBase partir de uma perspectiva de fluxo de dados, o meu problema parece se encaixar. Eu tenho um grande conjunto de documentos que eu quero Mapa, Combine e reduzir. Minha implementação SQL anterior era para dividir a tarefa em operações em lote, cumulativamente armazenar o que seria o resultado do Mapa na tabela e, em seguida, executar o equivalente a uma reduzir. Isto teve o benefício que em qualquer ponto durante a execução (ou entre execuções), eu tive os resultados do Mapa naquele ponto no tempo.

Pelo que entendi, a execução deste trabalho como MapReduce exigiria todas as funções de mapa para executar cada tempo.

My Map funções (e na verdade qualquer função) dá sempre a mesma saída para uma dada entrada. Não há simplesmente nenhum ponto na saída de cálculo re-se eu não preciso. Minha entrada (um conjunto de documentos) serão continuamente crescendo e eu vou correr minha operação MapReduce periodicamente sobre os dados. Entre as execuções eu deveria realmente só tem que calcular as funções de mapa para documentos recém-adicionados.

Meus dados provavelmente será HBase -> MapReduce -> HBase. Dado que o Hadoop é um ecossistema inteiro, pode ser capaz de saber que uma determinada função tem sido aplicada a uma linha com uma determinada identidade. Estou assumindo entradas imutáveis ??na tabela HBase. Does / pode, ter em conta Hadoop isso?

Eu estou ciente da documentação (especialmente os vídeos Cloudera) que re-cálculo (de dados potencialmente redundante) pode ser mais rápido do que persistir e recuperar para a classe de problema que Hadoop está sendo utilizado.

Quaisquer comentários / respostas?

Answer 1

Se você estiver olhando para evitar correr o passo Mapa de cada vez, quebrá-lo como seu próprio degrau (ou usando a IdentityReducer ou definir o número de redutores para o trabalho a 0) e executado posteriormente passos usando a saída de seu mapa etapa.

Se isto é realmente mais rápido do que recomputing partir dos dados brutos de cada vez depende do volume e forma dos dados de entrada versus os dados de saída, como é complicado o seu mapa passo é, etc.

Note que a execução de seu mapeador de novos conjuntos de dados não vai acréscimo para execuções anteriores - mas você pode contornar isso usando uma pasta de saída datado. Isso quer dizer que você poderia armazenar a saída de mapear o seu primeiro lote de arquivos em my_mapper_output/20091101, e lote na próxima semana em my_mapper_output/20091108, etc. Se você quiser reduzir ao longo de todo o conjunto, você deve ser capaz de passar no my_mapper_output como o pasta de entrada, e pegar todos os conjuntos de saída.

Answer 2

Por que não aplicar o fluxo de trabalho SQL em um ambiente diferente? Ou seja, adicionar uma coluna "processado" à tabela de entrada. Quando chega a hora de executar um resumo, execute um gasoduto que vai algo como:

map (map_function) em (tabela de entrada filtrado por processado!); loja em map_outputs quer em HBase ou simplesmente hdfs.

mapa (reduzir a função) em (map_outputs); loja em HBase.

Você pode tornar a vida um pouco mais fácil, supondo que você está armazenando seus dados em HBase ordenadas por data de inserção, se você gravar marcas de tempo em algum lugar de execuções sumárias de sucesso, e abrir o filtro de insumos que são datadas mais tarde do último resumo bem sucedido - você vai economizar algum tempo de digitalização significativa.

Aqui está uma apresentação interessante que mostra como uma empresa arquitetados seu fluxo de trabalho (embora eles não usam HBase): http: //www.scribd. com / doc / 20971412 / Hadoop-mundo-Produção-Deep-Dive-com-High Availability