Topologia de tempestades elásticas / Coexistência de Storm-Hadoop

9

Estamos avaliando a perseguição de Storm para uma implantação, mas estou um pouco preocupado. Atualmente, executamos o Hadoop MapReduce e gostaríamos de fazer a transição de alguns dos nossos processos de MapReduce para Storm. Note que isso é alguns, mas não todos. Ainda teríamos alguma funcionalidade do MapReduce.

Eu encontrei o Mesos, o que poderia (potencialmente) nos permitir manter uma implantação do Storm e do Hadoop no mesmo hardware, mas tinha alguns outros problemas:

  • Eu imagino a situação ideal como sendo capaz de "emprestar" slots entre o Storm e o Hadoop arbitrariamente. ex. ambos usariam os mesmos recursos conforme necessário. Infelizmente, essa é uma implantação fixa e não é "baseada em nuvem", como o EC2 ou algo semelhante.

  • Eu quero evitar gargalos no nosso ambiente Storm. Um caso ideal seria "girar" (ou inverter) mais instâncias de Bolts, conforme exigido pela demanda. Isso é possível / realista?

  • "Reiniciar" uma topologia parece uma operação bastante cara, e não tenho certeza se é realmente uma opção. Idealmente, eu gostaria que fosse o mais simples possível.

Estamos nos aproximando desse problema corretamente? Essencialmente, uma topologia do Storm "alimentaria" um trabalho em lote do MapReduce. Alguns de nossos processamentos podem ser processados em fluxo contínuo e seriam muito melhores como uma topologia Storm, enquanto alguns deles exigem processamento em lote.

Qualquer feedback geral, mesmo que não aborde minhas perguntas específicas, seria bem-vindo. Esta é mais uma fase exploratória neste momento, e eu posso estar totalmente se aproximando disso da maneira errada.

    
por jon 03.01.2013 в 05:01
fonte

1 resposta

5

Alguns pensamentos e minhas experiências até agora em fazer um experimento semelhante (trabalhado em um Spike durante um Sprint):

  • A partir de minhas experiências (posso estar errado), você não aumenta mais os parafusos à medida que a demanda aumenta, mas sim ajusta as configurações de paralelismo de cada uma na topologia. As topologias não são dimensionadas adicionando mais parafusos, em vez disso, elas são dimensionadas aumentando o paralelismo para qualquer parafuso que seja o gargalo. Tome o exemplo de problema de contagem de palavras:
builder.setBolt(4, new MyBolt(), 12)
    .shuffleGrouping(1)
    .shuffleGrouping(2)
    .fieldsGrouping(3, new Fields("id1", "id2"));

Esse último parâmetro (o "12") é o paralelismo desse parafuso. Se é um gargalo na topologia e você precisa aumentar a escala para atender à demanda, você aumenta isso. Um paralelismo de 12 significa que resultará em 12 threads executando o parafuso em paralelo através do cluster de tempestade.

  • Em 0.8.0 você pode usar "Executores", que também permitem ajustes "na hora" para ajudar a escalar um parafuso / etc para cima / baixo. Exemplo:
  

builder.setBolt (new MyBolt (), 3)             .setNumTasks (64)             .shuffleGrouping ("someSpout");

Aqui, o número de executores (encadeamentos) para MyBolt() é 3 e você pode alterar o número de encadeamentos dinamicamente sem afetar a topologia. storm rebalance é usado para isso:

$ storm rebalance someTopology -n 6 -e mySpout=4 -e myBolt=6

Isso altera o número de trabalhadores para a topologia "someTopology" para 6, o número de executores / threads para mySpout para 4 e o número de executores / threads para myBolt para 6.

  • Parece que sua topologia de tempestade processaria os dados de streaming. Os dados que exigem processamento em lote serão iniciados após sua persistência em qualquer armazenamento de dados (HDFS) que você esteja usando. Nesse caso, você envolveria um parafuso para fazer persistência no armazenamento de dados para quaisquer dados necessários.
  • Se, por outro lado, você quiser fazer algum tipo de processamento incremental em cima de qualquer armazenamento de dados que já tenha (e permanecer com estado), use Trident ( link ). Trident pode realmente resolver muitas das perguntas que você tem.
por Jack 10.01.2013 / 20:37
fonte