1. Introdução
Decidi analisar um artigo descrevendo alguns detalhes interessantes do processamento de streaming exatamente uma vez: exatamente uma vez . O fato é que alguns autores entendem os termos de maneira muito estranha. A análise do artigo nos permitirá esclarecer muitos detalhes mais profundamente, porque A identificação de inconsistências e esquisitices permite que você experimente mais plenamente os conceitos e significados.
Vamos começar.
Análise
Tudo começa muito bem:
O processamento do fluxo de eventos distribuídos se tornou um tópico cada vez mais popular na área de Big Data. Os Notáveis Stream Processing Engines (SPEs) incluem Apache Storm, Apache Flink, Heron, Apache Kafka (Kafka Streams) e Apache Spark (Spark Streaming). Um dos recursos mais notáveis e amplamente discutidos das SPEs é a semântica de processamento, com “exatamente uma vez” sendo uma das mais procuradas e muitas SPEs alegando fornecer semântica de processamento “exatamente uma vez”.
Ou seja, o processamento de dados é extremamente importante etc., e o tópico em discussão é exatamente uma vez. Vamos discutir isso.
Existe muito mal-entendido e ambiguidade, no entanto, cercando o que exatamente "exatamente uma vez" é, o que isso implica e o que realmente significa quando SPEs individuais afirmam fornecê-lo.
De fato, é muito importante entender o que é. Para fazer isso, seria bom fornecer a definição correta antes de um longo raciocínio. E quem sou eu para dar conselhos tão malditamente sólidos?
Discutirei como a semântica de processamento “exatamente uma vez” difere em muitas SPEs populares e por que “exatamente uma vez” pode ser melhor descrito como efetivamente uma vez
Inventar novos termos é, obviamente, uma tarefa importante. Eu mesmo amo essa coisa. Apenas para isso, é necessária justificativa. Vamos tentar encontrá-lo.
Não descreverei as coisas óbvias como gráficos de processamento direcionado e assim por diante. Os leitores podem ler o artigo original por conta própria. Além disso, a análise desses detalhes é irrelevante. Vou dar apenas uma foto:
A seguir, há uma descrição da semântica:
- No máximo uma vez, ou seja, não mais que uma vez. Com a aparente obviedade, esse comportamento é extremamente difícil de garantir em cenários de limites, como falhas, interrupção da conectividade de rede e muito mais. Mas para o autor tudo é simples:
- Pelo menos uma vez, ou seja, pelo menos uma vez. O esquema é mais complexo. E o rake pode ser coletado mais:
- Exatamente uma vez. O que é exatamente uma vez?
Os eventos são garantidos para serem processados "exatamente uma vez" por todos os operadores no aplicativo de fluxo, mesmo no caso de várias falhas.
I.e. a garantia do processamento exatamente uma vez é quando o processamento "exatamente uma vez" ocorreu.
Sente o poder da determinação? Para reformular: processar uma vez é quando o processamento ocorre "uma vez". Bem, sim, também diz que essa garantia deve ser preservada em caso de falhas. Mas para sistemas distribuídos, isso é uma coisa óbvia. E as aspas sugerem que algo está errado aqui. Definir com aspas sem explicar o que isso significa é um sinal de uma abordagem profunda e ponderada.
A seguir, é apresentada uma descrição de como implementar essa semântica. E aqui gostaria de me debruçar com mais detalhes.
Dois mecanismos populares são normalmente usados para obter semântica de processamento "exatamente uma vez".
- Ponto de verificação distribuído de instantâneo / estado
- Entrega de evento pelo menos uma vez mais desduplicação de mensagem
Se o primeiro mecanismo referente a instantâneos e pontos de verificação não levanta questões, bem, exceto por alguns detalhes, como eficiência, existem pequenos problemas com o segundo que o autor ignorou.
Por alguma razão, entende-se que um manipulador só pode ser determinístico. No caso de um manipulador não determinístico, cada reinicialização subsequente fornecerá, de modo geral, outros valores e estados de saída, o que significa que a desduplicação não funcionará, porque os valores de saída serão diferentes. Assim, o mecanismo geral será muito mais complicado do que o descrito no artigo. Ou, francamente, esse mecanismo está incorreto.
No entanto, passamos ao mais delicioso:
É exatamente uma vez realmente exatamente uma vez?
Agora, vamos reexaminar o que a semântica de processamento "exatamente uma vez" realmente garante ao usuário final. O rótulo "exatamente uma vez" é enganoso ao descrever o que é feito exatamente uma vez.
Dizem que é hora de reconsiderar esse conceito, pois existem algumas inconsistências.
Alguns podem pensar que "exatamente uma vez" descreve a garantia para o processamento de eventos em que cada evento no fluxo é processado apenas uma vez. Na realidade, não há SPE que possa garantir o processamento exatamente uma vez. Garantir que a lógica definida pelo usuário em cada operador seja executada apenas uma vez por evento é impossível diante de falhas arbitrárias, porque a execução parcial do código do usuário é uma possibilidade sempre presente.
Caro autor, vale lembrar como os processadores modernos funcionam. Cada processador em processamento executa um grande número de estágios paralelos. Além disso, existem ramificações nas quais o processador começa a executar as ações erradas se o preditor de ramificação estiver errado. Nesse caso, as ações são revertidas. Assim, o processador pode executar o mesmo trecho de código duas vezes, mesmo que nenhuma falha tenha ocorrido!
O leitor atento exclama imediatamente: porque o escape é importante, e não como é realizado. Exatamente! O que importa é o que aconteceu como resultado, não como realmente aconteceu. Se o resultado é como se tivesse acontecido exatamente uma vez, isso significa que aconteceu exatamente uma vez. Não encontra? E todo o resto é casca, irrelevante. Os sistemas são complexos e as abstrações resultantes criam apenas a ilusão de execução de uma certa maneira. Parece-nos que o código é executado seqüencialmente, instrução por instrução, que lê primeiro, depois escreve e depois uma nova instrução. Mas não é assim, tudo é muito mais complicado. E a essência das abstrações corretas é manter a ilusão de garantias simples e compreensíveis, sem se aprofundar a cada vez, quando você precisar atribuir valores a uma variável.
E apenas o problema deste artigo está no fato de que exatamente uma vez é uma abstração que permite criar aplicativos sem pensar em duplicatas e valores perdidos. Que tudo ficará bem, mesmo em caso de queda. E não há necessidade de inventar novos termos para isso.
O código de exemplo no artigo demonstra claramente uma falta de entendimento de como escrever manipuladores:
Map (Event event) { Print "Event ID: " + event.getId() Return event }
O leitor é convidado a reescrever o código de forma independente, para não repetir os erros do autor do artigo.
Então, o que as SPEs garantem quando afirmam semântica de processamento "exatamente uma vez"? Se não for possível garantir que a lógica do usuário seja executada exatamente uma vez, o que é executado exatamente uma vez? Quando os SPEs reivindicam a semântica de processamento "exatamente uma vez", o que eles realmente estão dizendo é que eles podem garantir que as atualizações do estado gerenciado pelo SPE sejam confirmadas apenas uma vez em um armazenamento de back-end durável.
O usuário não precisa de uma garantia da execução física do código. Sabendo como o processador funciona, é fácil concluir que isso não é possível. O principal é a execução lógica exatamente uma vez, como se não houvesse falhas. Atrair os conceitos de "comprometer-se com o data warehouse" apenas agrava a falta de compreensão do autor sobre coisas básicas, porque existem implementações dessa semântica sem a necessidade de confirmação.
Para obter mais informações, você pode ler brevemente meu artigo: Processamento de dados competitivo heterogêneo em tempo real, estritamente uma vez .
Em outras palavras, o processamento de um evento pode ocorrer mais de uma vez, mas o efeito desse processamento é refletido apenas uma vez no armazenamento de estado de back-end durável.
A existência de um "armazenamento de estado de back-end durável" para o usuário é absolutamente violeta. Somente o efeito do processamento é importante, ou seja, consistência e valores de saída em todo o período de processamento de dados de streaming. Vale ressaltar que, para algumas tarefas, não é necessário ter um armazenamento de estado de back-end durável e seria bom garantir exatamente uma vez.
Aqui na Streamlio, decidimos que efetivamente, uma vez é o melhor termo para descrever essas semânticas de processamento.
Um exemplo típico de entrada estúpida de conceitos: escreveremos alguns exemplos e argumentos longos para um parágrafo inteiro e, no final, adicionaremos que "definimos esse conceito". A precisão e a clareza das definições causam uma resposta emocional verdadeiramente vívida.
Conclusões
A incompreensão da essência das abstrações leva a uma distorção do significado original dos conceitos existentes e à subsequente criação de novos termos a partir do zero.
[1] Exatamente uma vez NÃO é exatamente o mesmo .
[2] Processamento de dados competitivo heterogêneo em tempo real estritamente uma vez .