Como escolher um processador de fluxo para seu aplicativo com base em recursos avançados?

por Miyuru Dayarathna e Srinath Perera

Srinath Perera Blocked Unblock Seguir Seguindo 24 de dezembro

Introdução

O Stream Processing permite que os usuários consultem fluxos de dados contínuos e detectem condições rapidamente dentro de um pequeno período de tempo medido a partir do horário da recepção. O período de tempo de detecção pode variar de alguns milissegundos a minutos. Por exemplo, com o processamento de fluxo, você pode receber um alerta consultando um fluxo de dados proveniente de um sensor de temperatura e detectando quando a temperatura atingiu o ponto de congelamento. (Se você é novo no tópico, por favor leia A Gentle Introduction to Stream Processing .)

Se você deseja criar um aplicativo que manipule dados de fluxo e tome decisões em tempo real, você tem duas opções: usar uma ferramenta ou construí-la você mesmo. A resposta depende da complexidade do seu caso de uso, dos requisitos de escalabilidade e dos requisitos de confiabilidade e tolerância a falhas.

Se você deseja construir o aplicativo, primeiro coloque eventos em um tópico do message broker (por exemplo, ActiveMQ, RabbitMQ ou Kafka), escreva código para receber eventos de tópicos no broker (eles se tornam seu fluxo) e finalmente publique os resultados para o corretor. Um código que executa as três etapas acima é chamado de ator no mundo de processamento de fluxo.

No entanto, em vez de codificar o cenário acima a partir do zero, você economiza tempo usando uma estrutura de processamento de fluxo. Um processador de fluxo de eventos permite gravar a lógica usando o Streaming SQL e cuida do resto.

Você pode enviar eventos diretamente para o processador de fluxo ou enviá-los por meio de um corretor. Um processador de fluxo de evento fará o trabalho pesado coletando dados, entregando-os a cada ator, certificando-se de que eles sejam executados na ordem correta, coletando resultados, escalonando se a carga estiver alta e lidando com falhas.

A próxima pergunta é: “qual processador de fluxo você deve usar?”. Tenho boas e más notícias. Uma boa notícia é que há muitos (veja Quora Question: Quais são as melhores soluções de processamento de fluxo por aí? ), Então você tem muitas opções. A má notícia é que há muitos, e provavelmente você enfrentará o paradoxo da escolha .

Muitas considerações

Diferentes sistemas de processamento de fluxo têm suporte para diferentes recursos.

  1. Ingestão de dados com um agente de mensagens
  2. Escrevendo consultas com o SQL de fluxo contínuo
  3. APIs de processamento de fluxo e ambiente de escrita de consulta
  4. Confiabilidade, alta disponibilidade (HA) e HA mínima
  5. Facilidade de uso de negócios via arrastar e soltar interfaces gráficas do usuário (GUIs)
  6. Aprendizado de Máquina de Streaming
  7. Garantia de processamento de mensagens
  8. Eventos fora de ordem
  9. Desempenho do sistema em grande escala (Escalabilidade, Lidar com janelas grandes)

Isso é um monte de recursos. Estávamos lutando para tomar uma decisão considerando todos esses aspectos em 19 processadores de fluxo.

Idéia: “O produto médio”

Depois de pensar sobre isso por algum tempo, chegamos a duas ideias.

Primeiro é preciso ter recursos vs. opcionais. Os recursos obrigatórios são os recursos que a maioria dos usuários acabará usando em um aplicativo de processamento de fluxo contínuo e, portanto, necessária. Resto são recursos opcionais.

Então a segunda ideia é “o produto médio” . Definimos o produto médio como um produto hipotético que possui apenas recursos que são suportados por mais de 2/3 dos processadores de fluxo no mercado.

Então, você pode avaliar cada produto em contraste com o produto médio. Se o produto tiver recursos adicionais ao produto médio, será positivo se o produto tiver recursos ausentes, em contraste com o produto médio que é negativo.

O produto médio é um ponto de referência para comparar e contrastar cada produto com a média.

Recursos obrigatórios

Depois de pesquisar 19 processadores de fluxo, decidimos seguir quatro como recursos obrigatórios.

  1. Suporte para Ingestão de Dados com um Broker de Mensagens
  2. Streaming SQL
  3. APIs de processamento de fluxo e ambiente de escrita de consulta
  4. Confiabilidade, alta disponibilidade (HA) e HA mínima

Nós discutimos acima quatro características essenciais em detalhes em nosso artigo da InfoQ, Como Escolher um Processador de Fluxo para Seu Aplicativo ?

Escolha com base em Avançado (recursos opcionais)

Este artigo discute os recursos opcionais e como podemos usar a ideia de um produto geral para avaliá-los.

De acordo com nossa definição, o produto de processamento Stream geral possui os seguintes recursos. Ou em outras palavras, ? de produtos ou mais tem os seguintes recursos.

  • O produto pode ser executado de maneira distribuída e escalonável
  • Suporta pelo menos uma vez garantias de entrega de mensagens
  • Fornece tolerância a falhas para falhas de nó
  • Suporta checkpoints periódicos e recuperação
  • Suporta contrapressão
  • Suporta transformação, agregação, correlação, operadores de janela de tempo
  • Suporta depuração
  • Suporta múltiplas fontes de dados e sumidouros
  • Suporta a gravação de operadores personalizados
  • Suporta monitoramento do sistema em execução

Você pode avaliar um processamento de fluxo específico selecionando primeiro os recursos opcionais que importam para seu aplicativo e comparando o processador de fluxo selecionado em termos de recursos opcionais de seleção no produto médio.

Vamos discutir cada recurso opcional e qual nível de suporte é requerido por diferentes casos de uso.

Recursos Opcionais

Noção de tempo

Um processamento de fluxo é sempre um aplicativo distribuído. Primeiro, os dados são coletados de sensores que são executados em um ou mais computadores, depois transferidos para um processador de fluxo, processados e os resultados são entregues a um ou mais outros computadores.

Consequentemente, não existe uma única noção de tempo ou um relógio em todos os nós do sistema (isso é um resultado bem conhecido em sistemas distribuídos). Existem várias noções de tempo e os usuários as escolhem com base em sua aplicação.

A noção de tempo de um processador de fluxo é de três tipos: tempo do evento, tempo do fluxo e tempo de processamento.

  • Hora do evento – a hora em que o evento realmente foi gerado
  • Tempo de fluxo – o horário em que o processador de fluxo recebe dados na plataforma
  • Tempo de processamento – os processadores de fluxo de tempo processam os dados

A noção de tempo torna-se muito importante para aplicações de streaming que lidam com operações sensíveis à ordem do tempo.

Diferentes processadores de fluxo suportam o tempo em diferentes níveis. Alguns têm a capacidade de lidar com o tempo do evento e o tempo de processamento. Alguns lidam apenas com tempo de fluxo. Alguns lidam com as três vezes. Por exemplo, se o aplicativo de geração de alertas descrito acima precisar usar uma janela de tempo com base no horário do evento e fazer a comparação em um determinado campo durante um determinado intervalo de tempo (por exemplo, 17h às 8h), um processador de fluxo que use somente tempo de fluxo não pode ser usado para tal finalidade. É porque se usado o tempo de fluxo com o Windows, ele pode lançar alertas incorretos. Portanto, você deve escolher um processador de fluxo com base no nível de suporte de pedido de tempo exigido por seu aplicativo.

Os processadores de fluxo que distinguem o horário do evento e o tempo do fluxo precisam lidar com a questão da correção dos eventos fora de ordem. Isso ocorre porque muitas vezes a falta de ordem entre os eventos acontece quando eles estão em trânsito para o receptor do processador de fluxo. Eventos fora de ordem em um fluxo são produzidos devido a vários motivos, como a paralelização do operador, a latência da rede e a mesclagem de fluxos assíncronos. Uma técnica de manuseio fora de ordem é normalmente usada para lidar com tais situações. Detalhes do processamento fora de ordem serão discutidos em detalhes em uma subseção posterior deste artigo.

Facilidade de uso do negócio

O suporte para usuários de negócios para criar aplicativos de processamento de fluxo melhora a usabilidade de um processador de fluxo. Um usuário corporativo é alguém que precisa usar a análise de fluxo contínuo para um caso de uso de negócios, mas não possui um bom conhecimento técnico sobre os aspectos técnicos subjacentes da solução de processamento de fluxo. A facilidade de uso do negócio permite que tanto desenvolvedores como usuários businuss projetem, implementem e personalizem seus casos de uso.

Um exemplo onde é necessária a facilidade de uso de negócios é uma empresa que está espalhada por diferentes localizações geográficas. Em tais casos de uso, os centros de operação em cada localização geográfica estarão executando o mesmo processo com variáveis diferentes. Nesse cenário, projetar o processo de maneira abstrata e tornar o processo personalizado para cada localização geográfica simplifica significativamente o caso de uso.

Existem várias abordagens de exemplo em que os processadores de fluxo alcançam a facilidade de uso dos negócios. Uma abordagem é através do uso de planilhas para processamento de fluxo. Embora os usuários de negócios (ou seja, especialistas em domínio) nem sempre sejam programadores, eles estão familiarizados com os processadores de planilhas, já que mais de 500 milhões de pessoas em todo o mundo relataram usar planilhas . As planilhas foram usadas para visualizar transmissões ao vivo, programação ao vivo para computar novos fluxos e exportar cálculos para serem executados em um servidor, de modo que os cálculos possam ser compartilhados com outros usuários e persistirem além da vida útil da planilha. O documento “Planilhas para processamento de fluxo com janelas e partições ilimitadas”, de Hirzel, é um exemplo de abordagem, embora, pelo que sabemos, nenhum processador de fluxo suporta isso ainda.

Outro exemplo é o uso de modelos no WSO2 Stream Processor (WSO2 SP). O Gerenciador de Regras de Negócios do WSO2 SP permite especificar consultas como modelos (isto é, esqueletos). Um desenvolvedor com conhecimento sobre como escrever consultas de processamento de fluxo decidirá quais valores devem ser mantidos como variáveis. Um usuário corporativo que tenha pouco ou nenhum conhecimento sobre como gravar consultas de fluxo contínuo pode usar os esqueletos e criar os aplicativos. Por exemplo, suponhamos que queremos escrever uma consulta para detectar quando os veículos excederam o limite de velocidade. No entanto, os usuários corporativos podem decidir o limite de velocidade com base em onde a consulta é implantada. Os modelos incluem um formulário que o usuário empresarial pode preencher para alterar o comportamento da consulta. No entanto, diferentes parâmetros podem mudar em organizações e cenários de negócios, preservando a mesma estrutura de consulta. O uso de um Business Rules Manager permite gerar rapidamente consultas em execução usando um modelo de consulta e designando valores para os parâmetros.

Como discutido anteriormente, as Interfaces Gráficas do Usuário (GUIs) do tipo arrastar e soltar permitem a implementação de aplicativos encapsulando a lógica de consulta usando ícones e janelas de propriedades. Por exemplo, quando o usuário arrasta e solta um componente de fluxo na GUI de arrastar e soltar, ele pode usar a janela de propriedades associadas do componente de fluxo para adicionar os nomes de atributos e seus tipos.

Apenas 32% dos processadores de fluxo investigados por nós forneceram pelo menos algum suporte para usuários de negócios para desenvolver aplicativos de processamento de fluxo. O fornecimento de aplicativos de negócios pré-construídos e ferramentas de usuário de negócios também ajuda os usuários de negócios a transformar rapidamente seus processos de negócios com o sistema de processamento de fluxo. Dos processadores de fluxo pesquisados, apenas três fornecem aplicativos de negócios pré-construídos.

Integração ao Aprendizado de Máquina

Aprendizado de máquina (ML) aprende com dados e resolve problemas que são difíceis de resolver escrevendo um algoritmo. Por exemplo, um modelo de aprendizado de máquina pode ser usado para detectar atividades fraudulentas. Um classificador pode ser incorporado ao aplicativo de geração de alerta para gerar alertas com melhor precisão, em vez de usar critérios simples, como maior que a comparação.

A maioria dos novos casos de uso irá incorporar aprendizado de máquina de alguma forma. Portanto, precisamos de processadores de fluxo para suportar modelos de aprendizado de máquina. No entanto, a integração de algoritmos ML em aplicativos de processamento de fluxo não é uma tarefa trivial.

O tradicional ML baseado em lotes geralmente possui duas fases: treinamento de modelo e previsão baseada em modelo. A abordagem comum é primeiro treinar o modelo usando algoritmos de lote e, em seguida, importar o modelo ML pré-treinado para o aplicativo de processamento de fluxo. Existem apenas alguns processadores de fluxo que possuem recursos internos de ML. Para carregar um modelo ML pré-treinado em um aplicativo de processamento de fluxo, o modelo precisa ser salvo em um formato conhecido, como PMML, para que o modelo possa ser carregado sem problemas de formatação.

Alguns processadores de fluxo também suportam o aprendizado de máquina de fluxo, que é a tecnologia que pode construir e melhorar o modelo à medida que os dados chegam. No entanto, a precisão do aprendizado de máquina de fluxo é menor do que os modelos construídos com aprendizado de máquina clássico (baseado em lote). Ao mesmo tempo, os modelos clássicos não melhoram com os dados. Portanto, os modelos precisam ser atualizados de tempos em tempos.

Este é um trade-off. Se o seu aplicativo de streaming precisar de modelos de aprendizado de máquina, será necessário selecionar entre o aprendizado em lote e de streaming da máquina, pensando no trade-off de precisão versus desvio de conceito (quão rápido o modelo cai com novos dados).

Garantia de processamento de mensagens

“Qual nível de precisão você deseja que seu aplicativo demonstre?” É determinado pelo nível de garantia de processamento de mensagens oferecido pelo processador de fluxo. A garantia de processamento de mensagens (isto é, semântica) determina a confiabilidade da entrega de mensagens do processador de fluxo. Que tipo de semântica, como uma estrutura que você deseja usar, depende do que faz sentido em seu caso de uso. Existem três garantias principais de processamento de mensagens, chamadas no máximo uma vez, pelo menos uma vez e exatamente uma vez.

A garantia mais fraca é no máximo uma vez. No máximo uma vez, na verdade, não garante que entregará nada. Por exemplo, dois eventos podem entrar no aplicativo do fluxo de entrada e apenas uma mensagem pode sair do aplicativo. Ao implementar, no máximo, uma vez que não há estado exigido no remetente ou no receptor, uma vez que não há protocolo de reconhecimento envolvido. No máximo, uma vez não introduz uma sobrecarga de desempenho adicional e é a mais fácil de implementar entre as três garantias de processamento de mensagens.

Uma garantia mais forte é pelo menos uma vez em que a mensagem pode ser processada pelo menos uma vez. Isso significa que a mensagem irá definitivamente chegar ao destinatário, mas existe a possibilidade de duplicatas. A falha do sistema resultará na mesma mensagem repetida várias vezes no fluxo de saída. Portanto, os aplicativos downstream precisam lidar com essas mensagens duplicadas cuidadosamente. Se os dados forem idempotentes, o uso de pelo menos uma garantia de processamento de mensagens será suficiente para seu caso de uso. A fim de implementar pelo menos uma vez o remetente tem para as faixas para quem a mensagem é enviada, quais mensagens ainda não foram reconhecidas, e quando a mensagem tem que ser re-entregue. Pelo menos uma vez a garantia da mensagem é boa o suficiente para muitos casos de uso. Por exemplo, para um aplicativo de geração de alerta, pelo menos uma garantia de mensagem é suficiente, pois garante que a notificação do alerta seja entregue às partes pretendidas com êxito.

O terceiro tipo de garantia de processamento de mensagens é exatamente uma vez o processamento que é procurado pela maioria da comunidade de processamento de fluxo, embora possa ou não fazer sentido. Exatamente quando uma garantia é necessária para algumas aplicações de missão crítica, como ordens de compra, sistemas de negociação financeira, reserva de voo, reserva de hotel, etc. Se duas mensagens entrarem no aplicativo e ocorrer alguma falha no sistema, exatamente uma vez garante que cada mensagem seja processada exatamente um tempo. Ao implementar a garantia de mensagem exatamente uma vez, precisamos manter o estado no emissor e no receptor. O receptor também tem que acompanhar quais mensagens já foram vistas e processadas antes, pelo menos por algum tempo. Portanto, essa abordagem é a mais cara de implementar entre as três garantias de processamento de mensagens.

Muitos dos casos de uso de processamento de fluxo só precisam no máximo uma vez e pelo menos uma vez garante. Observamos que cerca de 47% dos 19 processadores de fluxo suportavam pelo menos uma vez a semântica, 37% suportavam exatamente uma vez e 21% não tinham garantia de processamento de mensagens.

Se o seu aplicativo de streaming precisar de garantias mais fortes, você deve selecionar o processador de fluxo de acordo.

Processamento fora de ordem e incerteza de manuseio

O que acontecerá se os dados de entrada vierem em ordem temporal diferente da produzida na origem? Eventos fora de ordem (isto é, eventos de chegada tardia) em um fluxo são produzidos devido a vários motivos, como sensores distribuídos, paralelização do operador, latência de rede e mesclagem de fluxos assíncronos. O processamento de eventos sem pedidos pode resultar em resultados errados. Por exemplo, o tratamento de eventos fora de ordem é necessário para garantir a operação correta da correspondência de padrões de eventos. Um alerta pode ser configurado para ser gerado se o evento X chegar após o evento Y. Suponhamos que uma consulta detecte eventos ordenados como Y seguidos por X. Se a consulta receber eventos X após Y devido a problemas de ordem, eles não corresponderão. Da mesma forma, um aplicativo com janela de tempo que é acionado com base no horário do evento também pode ser afetado por esses eventos fora de ordem. No entanto, determinados aplicativos, como filtros de eventos, não são afetados pelos eventos fora de ordem.

O tratamento de eventos fora de ordem é um tópico que tem sido explorado ativamente. Existem várias abordagens de alto nível.

A primeira é interceptar os eventos e depois reordená-los em um buffer antes de processá-los. Esse método acrescentou latência proporcional ao valor que cada evento pode atrasar. Esse método funciona quando o atraso causado por falta de ordem é pequeno e limitado.

A segunda abordagem é criar operadores resilientes que possam trabalhar e se recuperar de eventos fora de ordem. Isso, no entanto, torna as operadoras complexas para implementar. Um exemplo é o uso de pontuações. As técnicas baseadas em pontuação dependem de tuplas especiais enviadas com fluxos de dados. Pontuações informam explicitamente um operador de consulta quando retornar resultados para janelas. Portanto, ao contrário das técnicas baseadas em Buffer descritas acima, o operador de consulta pode consumir entradas fora de ordem diretamente.

A terceira abordagem é chamada de especulação onde aplicamos uma técnica de compensação para corrigir resultados de consulta imprecisos anteriormente emitidos quando eventos fora de ordem são observados. Aqui assumimos a chegada em ordem das tuplas e produzimos os resultados de uma janela imediatamente quando a janela é fechada. Quando uma chegada tardia e é detectada, os resultados anteriormente emitidos que são afetados por e são invalidados. Novas revisões desses resultados são produzidos tomando e em conta. Esta abordagem funciona melhor quando as chegadas tardias são menores. Se o fluxo receber continuamente eventos fora de ordem, isso poderá introduzir latência adicional para as correções.

O tratamento de eventos fora de ordem não é realizado pela maioria dos processadores de fluxo, embora uma quantidade significativa de pesquisa tenha sido conduzida para várias abordagens para lidar com o transtorno. Apenas 47% dos processadores de fluxo dos 19 pesquisados se importam com eventos fora de ordem. Além disso, apenas alguns processadores de fluxo fora dos 47% que realmente fizeram reordenação. Os outros simplesmente desistiram dos eventos fora de ordem.

atuação

Um aplicativo típico de processamento de fluxo com persistência de evento é executado em torno de 50 mil eventos / segundo. Portanto, a maioria dos cenários de processamento de fluxo pode ser implementada com a configuração HA de dois nós (por exemplo, ver Obesos do processador de fluxo? ). No entanto, pode haver um requisito de escalonar o sistema além de 2 nós. Além disso, janelas com um estado grande podem consumir uma grande quantidade de memória do sistema. O processador de fluxo precisa ter suporte para lidar com um estado tão grande.

Escalabilidade do sistema

O que acontecerá se seu aplicativo precisar lidar com cargas crescentes? A escalabilidade e o desempenho do sistema são métricas importantes que medem a capacidade de um processador de fluxo lidar com grandes cargas de trabalho. O nível esperado de desempenho depende do caso de uso e, uma vez escolhido, a mudança para um processador de fluxo diferente é uma operação muito cara.

Por exemplo, o caso de uso pode inicialmente ser operações simples de filtragem em pequenos eventos (com poucos campos totalizando algumas centenas de bytes). Mas, com o tempo, os eventos podem ficar maiores com a adição de novos campos com quantidades significativamente grandes de dados (por exemplo, alguns megabytes). Além disso, com o tempo o negócio continua crescendo e a lógica do aplicativo também pode ser reforçada com junções complexas, correspondência de padrões de eventos, processamento de janelas, etc. Com essas mudanças, o caso de uso pode exigir desempenho muito superior ao que poderia ser fornecido por o sistema inicial. Portanto, se o caso de uso precisar de muito desempenho, você precisará testar se os SPs candidatos podem manipular uma carga de trabalho tão pesada.

Um processador de fluxo escalável pode expandir sua escala operacional adicionando mais recursos. Se for garantido que um processador de fluxo receba apenas uma taxa fixa de eventos de entrada de um conjunto fixo de fontes de entrada (por exemplo, processador de fluxo para redes veiculares), o processador de fluxo não precisa ter recursos de escalabilidade. No entanto, se o processador de fluxo for executado, por exemplo, como um serviço de software, no qual ele precisa lidar com cargas de trabalho em constante mudança , a capacidade de dimensionamento é geralmente necessária. A maioria dos processadores de fluxo discute sua capacidade de dimensionamento horizontal (incluindo novos nós) sem muitos detalhes sobre o dimensionamento vertical (adicionando recursos mantendo o mesmo nó). É um fator muito importante considerar a escalabilidade vertical do processador de fluxo, especialmente se o ambiente de implementação não puder ser provisionado com mais servidores. Além disso, o escalonamento horizontal introduz uma sobrecarga de comunicação de rede adicional. Isso significa que devemos primeiro tentar dimensionar verticalmente o máximo possível antes de ir para a escala horizontal.

Os processadores de fluxo distribuído de software livre publicaram números de throughput nos intervalos de milhões de eventos por segundo. A maioria dos processadores de fluxo proprietários não tem números de rendimento publicados. Dado um fluxo fixo de dados de entrada constante, a taxa de transferência de um processador de fluxo é subjetiva para vários fatores, como tamanho da fila, núcleo da CPU, memória e largura de banda entre nós. Por isso, é praticamente impossível encontrar estudos realizados em toda a lista de produtos. Dos números de desempenho que podem ser encontrados em processadores de fluxo distribuídos, a maior taxa de transferência encontrada foi de 110 milhões de eventos / s com baixa latência de 30ms. A melhor latência para as versões de nó único encontradas foi 0,003ms.

Manipulando Longas Janelas de Agregação

O que acontecerá se o aplicativo envolver janelas com milhões de eventos? O processamento de fluxo, em geral, aplica processamento único leve em um fluxo de dados. Os aplicativos de fluxo geralmente precisam conduzir agregações na parte superior das janelas. O tamanho da janela é muito importante, pois a janela deve ser mantida na memória. Se a janela pode consistir em milhões de eventos, ela deve ser mantida na memória e o sistema pode ficar sobrecarregado, tornando-se uma grande ameaça à estabilidade do sistema. Por exemplo , em sistemas de telecomunicações, pode haver casos de uso de registros de chamadas de longa distância, com 300 milhões de registros por dia para 100 milhões de clientes. Outro aplicativo seria a engenharia de tráfego de rede, na qual as informações sobre o desempenho atual da rede (por exemplo, latência e largura de banda) são agregadas on-line e usadas para monitorar e ajustar o desempenho da rede dinamicamente.

As soluções podem ser fornecidas do lado do processador de fluxo, bem como do lado da aplicação. Para lidar com grandes janelas, o processador de fluxo deve ser provisionado com muita memória. Se não, o processador de fluxo precisa ser equipado com os recursos de reduzir o consumo de memória, comprimindo a janela ou armazenando parte da janela no armazenamento secundário.

A solução do ponto de vista da aplicação seria conduzir a agregação usando quantidades menores e, em seguida, calcular valores de nível mais alto com base nas quantidades menores (isto é, agregação incremental ). Por exemplo, se os resultados finais esperados pela manutenção de uma janela de duração de 300 milhões de registros for calcular a duração total de chamadas telefônicas, o mesmo resultado pode ser obtido pela agregação dos registros de chamadas em minutos, use esses resultados para calcular a soma por hora, e finalmente use esses valores por hora para calcular a duração total do dia inteiro.

Conclusão

Diferentes processadores de fluxo possuem recursos inerentes que os combinam para diferentes casos de uso. Ao tentar selecionar o processador de fluxo melhor para você, o número de recursos a considerar é grande, o que dificulta a escolha correta.

Este artigo apresenta uma abordagem sistemática para a escolha de um processador de fluxo.

O artigo faz isso introduzindo dois conceitos.

  • Deve ter recursos – esses são os recursos que a maioria dos aplicativos de streaming precisará em seu ciclo de vida
  • Produtos gerais – Este produto conceitual consiste nos recursos que supporting ou mais produtos de processamento de fluxo estão suportando. Pode-se decidir comparar dois processadores de fluxo comparando ambos ao produto geral.

A abordagem responde a duas questões principais. Primeiro, até que ponto o processador de fluxo suporta os recursos de arquitetura do processador de fluxo principal? Segundo, quais são os requisitos especiais do aplicativo e até que ponto eles estão sendo atendidos pelos processadores de fluxo candidatos?

Ao responder a segunda questão, podemos usar a ideia do “produto geral” como linha de base. Você pode avaliar um processamento de fluxo específico, comparando-o ao produto médio.