Guia de seleção do nível de Atlas Stream Processing

Estágios que suportam paralelismo

Os seguintes estágios aceitam um valor de parallelism. Cada um tem como padrão 1.

Como funciona o paralelismo em tempo de execução

Um processador de stream move dados pela seguinte sequência:

Source -> Buffer -> Transform -> Buffer -> Sink

Para uma origem Apache Kafka, o Atlas Stream Processing inicia um thread de consumidor para cada partição de origem, para que um processador possa ler de várias partições de uma só vez. Os estágios de transformação no meio do pipeline ainda são executados em um único thread e processam os dados armazenados em buffer em lotes.

Quando um estágio com um parallelism valor maior que 1 recebe um lote, seus threads paralelos ou solicitações processam esse lote. O lote então passa para o próximo estágio.

Distribuição e ordenação de documentos

Quando o valor parallelism de um estágio é maior que 1, o Atlas Stream Processing distribui documentos entre threads da seguinte forma:

• Se você não especificar partitionBy, o Atlas Stream Processing atribuirá documentos a threads em ordem circular.

• Se você especificar partitionBy, o Atlas Stream Processing enviará todos os documentos que têm o mesmo valor de partitionBy para o mesmo thread, que os processará em ordem.

$merge é uma exceção: ele usa os campos em sua cláusula on como chave da partição.

Paralelismo cumulativo

Cada processador de fluxo tem um valor máximo de paralelismo cumulativo determinado por seu nível. O paralelismo cumulativo de um processador de fluxo é calculado da seguinte forma:

parallelism total - parallelized stages

Onde parallelism total é a soma de todos os valores de parallelism maiores que 1 nos estágios $source, $lookup, $merge, $emit e $externalFunction, e parallelized stages é o número desses estágios com valores de parallelism maiores que 1.

Por exemplo, se o seu estágio $source define um valor parallelism de 4, o seu estágio $lookup não define nenhum valor parallelism (portanto, o padrão é 1) e o seu estágio $merge define um parallelism valor de 2, então você tem dois parallelized stages, e o paralelismo cumulativo do seu processador de fluxo é calculado como (4 + 2) - 2.

Se um processador de fluxo exceder o paralelismo cumulativo máximo para seu nível, o Atlas Stream Processing lançará um erro e o avisará sobre o nível mínimo de processador necessário para o nível pretendido de paralelismo. Você deve dimensionar o processador para um nível superior ou reduzir os valores de paralelismo de seus estágios para resolver o erro. Para saber mais, consulte Stream Processing.

Partições de origem Kafka

Os processadores que leem do Apache Kafka também estão limitados pelo limite de partição de origem de seu nível. O nível SP2 limita um processador a 32 partições de origem e o nível SP5 limita um processador a 64. O nível SP10 e superiores não impõem limite de partição.

Um processador que excede o limite de partição de seu nível falha e você deve escalá-lo para oferecer suporte às partições adicionais. Como um tópico pode obter partições enquanto um processador é executado, escolha um nível com espaço para o crescimento da partição que você antecipa. Para saber mais sobre o comportamento de origem do Kafka, consulte Limitações de Atlas Stream Processing .

Monitorar o paralelismo configurado

Para comparar o paralelismo configurado com o paralelismo disponível para o nível do processador, use o campo stats.addedParallelism que as estatísticas do processador retornam. O Atlas Stream Processing retorna esse campo somente se pelo menos um estágio definir um valor parallelism maior que 1.

Onda de inicialização

Um processador de fluxo pode exigir mais recursos durante sua execução inicial do que durante operações regulares. Por exemplo, um processador que executa um initialSync em relação a uma grande coleção do Atlas precisa suportar E/S e computação pesadas durante a sincronização.

Para suportar essa demanda elevada, selecione um nível mais alto temporariamente e reduza a escala do processador quando a sincronização estiver concluída e o processador fizer a transição para consumir apenas novos eventos de fluxo de alterações.

Lógica de Pipeline

A lógica do pipeline de agregação é o principal driver do consumo de CPU e RAM.

• Windows: janelas de longa duração consomem mais RAM para manter a bordo

  Documentos.

• Lógica Personalizada: estágios Javascript $function ou agrupamento complexo

  a lógica aumenta os requisitos computacionais de cada mensagem.

• Combinação de complexidade: estágios adicionais com estado ou computacionalmente complexos

  introduzir mais variação potencial na demanda de recursos. A manutenção da capacidade excedente garante uma taxa de transferência consistente, mesmo durante picos de consumo.

Infraestrutura

Cada ponto de rede ou contato de armazenamento aumenta a sobrecarga de um processador de fluxo.

• Densidade de origem ou coletor: lendo ou gravando em paralelizado

  fontes ou coletores — como os tópicos do Apache Kafka com suas partições — aumenta os requisitos de E/S.

• Enriquecimento de Dados: $lookup e $https estágios; e operações

  contra coleções do Atlas para Enriquecer os dados em um fluxo exigem largura de banda da rede e pool de conexões.

• Coordenação: Em implantações complexas orquestrando muitas fontes

  e coletores, os processadores de fluxo podem servir como centros que roteiam o fluxo de dados entre cada um desses nós. Esses processadores se beneficiam da maior taxa de transferência dos níveis SP30 e SP50.

Por outro lado, cargas de trabalho de Stream Processing de alta taxa de transferência podem aumentar a demanda dos recursos conectados.

• Impacto no Atlas: E/S paralelizada e de alto volume de um fluxo

  processador pode exceder a capacidade de leitura ou gravação dos Atlas clusters de origem ou coletor. Isso não só pode aumentar a latência do processador, mas também gargalos de outras cargas de trabalho dependentes desses clusters.

  Para garantir o desempenho de todo o sistema, escale seus Atlas clusters proporcionalmente aos processadores com os quais eles interagem.

Desempenho e latência

As metas de desempenho podem exigir um processador de nível superior, mesmo quando a lógica de processamento é mínima.

• Alta taxa de transferência: os processadores de nível superior oferecem suporte melhor aos fluxos de suporte

  que produzem eventos em uma taxa alta.

• SLAs de baixa latência: o alto paralelismo oferecido pelos processadores de nível superior ajuda a garantir que os eventos não se acumulem em uma fila quando a velocidade é importante. Em particular, os processadores SP50 oferecem quatro vezes os threads do que os processadores SP30.

• Enriquecimento de dados e cache: ao usar $cachedLookup para enriquecimento

  fluxos com grandes conjuntos de dados de referência estáticos ou de mudança lenta, favorecem processadores de nível superior para fornecer a RAM necessária para o cache.

• Sinks complexos: Alguns coletores envolvem mais caros

  transformações, transações e sobrecarga de gerenciamento de arquivos. Para os processadores que interagem com esses sinks, os níveis mais altos ajudam a garantir desempenho e latência consistentes.