Qual é / são as principais diferenças entre Flink e Storm?


137

O Flink foi comparado ao Spark , que, a meu ver, é a comparação incorreta, porque compara um sistema de processamento de eventos em janelas com o micro lote; Da mesma forma, não faz muito sentido comparar Flink com Samza. Nos dois casos, ele compara uma estratégia de processamento de eventos em tempo real versus uma de lotes, mesmo que em uma "escala" menor no caso do Samza. Mas eu gostaria de saber como o Flink se compara ao Storm, que parece conceitualmente muito mais semelhante a ele.

Eu encontrei isso (Slide 4) documentando a principal diferença como "latência ajustável" para o Flink. Outra dica parece ser um artigo de Slicon Angle que sugere que o Flink se integra melhor ao mundo Spark ou HadoopMR, mas nenhum detalhe real é mencionado ou referenciado. Por fim, o próprio Fabian Hueske observa em uma entrevista que "Comparada ao Apache Storm, a funcionalidade de análise de fluxo do Flink oferece uma API de alto nível e usa uma estratégia de tolerância a falhas mais leve para fornecer garantias de processamento exatamente uma vez".

Tudo isso é um pouco escasso para mim e não entendi direito. Alguém pode explicar quais problemas com o processamento de fluxo no Storm são (são?) Exatamente resolvidos pelo Flink? A que Hueske se refere pelos problemas da API e sua "estratégia mais leve de tolerância a falhas"?


2
Observe que o Apache Spark (o foco da pergunta vinculada) não é o mesmo que o Apache Storm (essa pergunta aqui) - portanto, não, isso não é de forma alguma uma duplicata.
precisa saber é

Respostas:


211

Isenção de responsabilidade : sou um colaborador do Apache Flink e membro do PMC e estou familiarizado apenas com o design de alto nível do Storm, não com os internos.

O Apache Flink é uma estrutura para fluxo unificado e processamento em lote. O tempo de execução do Flink suporta nativamente os dois domínios devido a transferências de dados em pipeline entre tarefas paralelas, que incluem shuffles em pipeline. Os registros são enviados imediatamente, desde a produção de tarefas até as tarefas de recebimento (depois de coletados em um buffer para transferência de rede). Os trabalhos em lote podem ser executados opcionalmente usando o bloqueio de transferências de dados.

O Apache Spark é uma estrutura que também suporta processamento em lote e fluxo. A API de lote do Flink é bastante semelhante e aborda casos de uso semelhantes ao Spark, mas difere nos internos. Para streaming, os dois sistemas seguem abordagens muito diferentes (mini-lotes vs. streaming), o que os torna adequados para diferentes tipos de aplicativos. Eu diria que comparar o Spark e o Flink é válido e útil, no entanto, o Spark não é o mecanismo de processamento de fluxo mais semelhante ao Flink.

Chegando à pergunta original, o Apache Storm é um processador de fluxo de dados sem recursos em lote. De fato, o mecanismo em pipeline do Flink internamente se parece um pouco com o Storm, ou seja, as interfaces das tarefas paralelas do Flink são semelhantes aos parafusos do Storm. Storm e Flink têm em comum que eles visam o processamento de fluxo de baixa latência por transferências de dados em pipeline. No entanto, o Flink oferece uma API de mais alto nível em comparação com o Storm. Em vez de implementar a funcionalidade de um parafuso com um ou mais leitores e coletores, a API DataStream do Flink fornece funções como Map, GroupBy, Window e Join. Muitas dessas funcionalidades devem ser implementadas manualmente ao usar o Storm. Outra diferença é a semântica de processamento. O Storm garante processamento pelo menos uma vez, enquanto o Flink fornece exatamente uma vez. As implementações que dão essas garantias de processamento diferem bastante. Enquanto o Storm usa reconhecimentos em nível de registro, o Flink usa uma variante do algoritmo Chandy-Lamport. Em poucas palavras, as fontes de dados injetam periodicamente marcadores no fluxo de dados. Sempre que um operador recebe esse marcador, ele verifica seu estado interno. Quando um marcador foi recebido por todos os coletores de dados, o marcador (e todos os registros que foram processados ​​antes) são confirmados. Em caso de falha, todos os operadores de origem são redefinidos para seu estado quando viram o último marcador confirmado e o processamento é continuado. Essa abordagem de ponto de verificação de marcador é mais leve que as confirmações em nível de registro do Storm. este as fontes de dados injetam periodicamente marcadores no fluxo de dados. Sempre que um operador recebe esse marcador, ele verifica seu estado interno. Quando um marcador foi recebido por todos os coletores de dados, o marcador (e todos os registros que foram processados ​​antes) são confirmados. Em caso de falha, todos os operadores de origem são redefinidos para seu estado quando viram o último marcador confirmado e o processamento é continuado. Essa abordagem de ponto de verificação de marcador é mais leve que as confirmações em nível de registro do Storm. este as fontes de dados injetam periodicamente marcadores no fluxo de dados. Sempre que um operador recebe esse marcador, ele verifica seu estado interno. Quando um marcador foi recebido por todos os coletores de dados, o marcador (e todos os registros que foram processados ​​antes) são confirmados. Em caso de falha, todos os operadores de origem são redefinidos para seu estado quando viram o último marcador confirmado e o processamento é continuado. Essa abordagem de ponto de verificação de marcador é mais leve que as confirmações em nível de registro do Storm. este todos os operadores de origem são redefinidos para seu estado quando viram o último marcador confirmado e o processamento continua. Essa abordagem de ponto de verificação de marcador é mais leve que as confirmações em nível de registro do Storm. este todos os operadores de origem são redefinidos para seu estado quando viram o último marcador confirmado e o processamento continua. Essa abordagem de ponto de verificação de marcador é mais leve que as confirmações em nível de registro do Storm. esteO conjunto de slides e a palestra correspondente discutem a abordagem de processamento de streaming da Flink, incluindo tolerância a falhas, ponto de verificação e manipulação de estado.

O Storm também oferece uma API de alto nível, exatamente uma vez, chamada Trident. No entanto, o Trident é baseado em mini-lotes e, portanto, mais semelhante ao Spark do que ao Flink.

A latência ajustável do Flink se refere à maneira como o Flink envia registros de uma tarefa para outra. Eu disse antes, que o Flink usa transferências de dados em pipeline e encaminha registros assim que são produzidos. Por questões de eficiência, esses registros são coletados em um buffer que é enviado pela rede quando estiver cheio ou quando um determinado limite de tempo for atingido. Esse limite controla a latência dos registros porque especifica a quantidade máxima de tempo que um registro permanecerá em um buffer sem ser enviado para a próxima tarefa. No entanto, não pode ser usado para fornecer garantias concretas sobre o tempo que leva para que um registro entre e saia de um programa, porque isso também depende do tempo de processamento nas tarefas e do número de transferências de rede, entre outras coisas.


2
Muito obrigado mesmo! Talvez um ponto em aberto, se eu puder incomodá-lo mais uma vez: sobre o que é essa questão da "latência ajustável"? Parece que isso pode ser bastante relevante, uma vez que domínios de aplicativos diferentes terão requisitos diferentes a esse respeito. Você pode explicar o que isso implica, pelo menos em termos de Flink?
FNL

6
Claro, estendi minha resposta e discuti a latência ajustável. Diga-me se tiver mais perguntas.
Fabian Hueske

O Flink permite alterações "quentes" no fluxo de trabalho do DAG, como é possível implementar, por exemplo, usando Erlang? IE. Pode-se alterar o DAG durante o tempo de execução?
Thomas Browne

1
A troca de código quente não é possível. No entanto, você pode manter o estado de um aplicativo como um ponto de salvamento. O ponto de salvamento pode ser usado para iniciar um aplicativo modificado. Isso pode ser feito enquanto o aplicativo original ainda estiver em execução, de modo que a saída possa ser invertida em algum momento. Observe que os aplicativos não podem ser modificados arbitrariamente ao retomar de um ponto de salvamento existente.
Fabian Hueske

1
A vantagem interessante e enorme do Flink é a capacidade de executar o Apache Beam com API de nível ainda mais alto. É um dos corredores mais ricos e completos da Beam.
Piotr Gwiazda

47

Adicionando à resposta de Fabian Hueske:

O Flink aprimora o Storm adicionalmente também das seguintes maneiras:

  • Contrapressão: o tempo de execução do fluxo do Flink é bem comportado quando diferentes operadores executam em velocidades diferentes, porque os operadores downstream contrapressam muito os operadores upstream, embora a camada da rede gere buffer pools.

  • Estado definido pelo usuário: o Flink permite que os programas mantenham um estado personalizado em seus operadores. Esse estado pode realmente participar do ponto de verificação para tolerância a falhas, fornecendo garantias únicas para o estado definido pelo usuário personalizado. Veja este exemplo de uma máquina de estado definida pelo usuário dentro de um operador, que é consistentemente apontado junto com o fluxo de dados.

  • Streaming do Windows: a agregação de janelas e janelas de fluxo é um elemento essencial para a análise de fluxos de dados. O Flink vem com um sistema de janelas bastante poderoso que suporta muitos tipos de janelas.


2
Em relação a seu primeiro ponto, a tempestade é bem-comportado sob contrapressão como de 1,0 (lançado abril 2016)
Colin Nichols

A contrapressão de tempestade pode ser atenuada usando a propriedade "spout_max_pending". Ele define um limite para as tuplas máximas que podem estar presentes em um bico com confirmação pendente. O bico não consumirá mais tuplas daqui para frente até que a confirmação aconteça.
Aman Garg

3

Baseado na minha experiência em Storm and Flink. Eu sinto que essas ferramentas podem resolver o mesmo problema com abordagens diferentes. Todos os recursos do Flink mencionados por @Stephan Ewen podem ser combinados pelo Storm com a API interna (ou seja, spolts e bolts ) e a Trident API agora. Alguém alega que o Trident é do tipo mini-lote, enquanto eu acho que a maioria dos aplicativos complexos relacionados ao estado ou agregação só poderia depender do processamento em lote com o estilo da janela. Então, apenas listo algumas das principais diferenças aqui sem dizer qual é a melhor.

  • Estilo de desenvolvimento . orientado a computação (por exemplo, operador encadeado) no Flink vs. orientado a fluxo de dados (por exemplo addSpolt()/addBolt()) no Storm.
  • API de alto nível . Funções (por exemplo, Mapa, Janela, Juntar-se no nível Streaming) no Flink vs. Janela Nativa e Trident no Storm.
  • Processamento garantido de mensagens (GMP. Ou seja, exatamente uma vez ) . Ponto de verificação com conector de confirmação bifásico (por exemplo, KafkaConsumer) em Flink vs. Tuple-tree com a máquina de estado externa ou Trident in Storm.
  • Tolerância a falhas . Ponto de verificação de marcador no Flink vs. ACK de nível recorde no Storm.
  • Arquitetura interna . Abstração simples e paralelismo relativo (por exemplo, slot para cada encadeamento considerado com núcleos de CPU) em Flink vs. Abstrações de várias camadas (por exemplo, slot para cada JVM como trabalhador no supervisor e cada supervisor pode ter muitos trabalhadores) no Storm.

3

Disclaimer: Eu sou um funcionário da Cloudera, um grande apoiador da Storm e (em breve) Flink.

Funcional

Muitos bons pontos técnicos já foram apresentados. Um breve resumo dos destaques:

  • O Flink e o Storm podem processar por evento
  • O Storm não parece suportar o tempo do evento pronto para uso
  • Storm não retirou o suporte do SQL da fase experimental

Não funcional

  • Muitos clientes acharam o Storm difícil de usar
  • A adoção do Storm diminuiu e a comunidade de Flink agora parece ser mais ativa que o Storm
  • O Flink ainda tem muito o que fazer (por exemplo, exemplos documentados), mas, em geral, alcançou quase todas as áreas em que você pode pensar

Conclusão

Cloudera anunciou recentemente a depreciação do Storm (em HDP). E simultaneamente Flink foi anunciado como seu sucessor.

Portanto, se você tiver casos de tempestade, é claro que eles continuarão a funcionar. Mas, para novos casos de uso, eu procuraria no Flink ou em outros mecanismos de streaming.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.