Dimensionar seu trabalho do Stream Analytics com funções do Machine Learning Studio (clássico)

Dica

É altamente recomendado usar UDFs do Azure Machine Learning em vez de UDFs do Machine Learning Studio (clássico) para melhorar o desempenho e a confiabilidade.

Importante

O suporte para o Machine Learning Studio (clássico) terminará em 31 de agosto de 2024. É recomendável fazer a transição para o Azure Machine Learning até essa data.

Desde 1º de dezembro de 2021, não é possível criar recursos (workspace e plano do serviço Web) do Machine Learning Studio (clássico). Até 31 de agosto de 2024, você poderá continuar usando os experimentos e serviços Web existentes do Machine Learning Studio (clássico).

A documentação do ML Studio (clássico) está sendo desativada e pode não ser atualizada no futuro.

Este artigo aborda como dimensionar com eficiência os trabalhos do Azure Stream Analytics que usam funções do Machine Learning Studio (clássico). Para saber mais sobre como dimensionar trabalhos do Stream Analytics em geral, confira o artigo Dimensionar os trabalhos do Stream Analytics.

O que é uma função do Studio (clássico) no Stream Analytics?

Uma função do Estúdio do Azure Machine Learning no Stream Analytics pode ser usada como uma chamada de função normal na linguagem de consulta do Stream Analytics. No entanto, nos bastidores, essas chamadas de função são, na verdade, solicitações de Serviço Web do Studio (clássico).

Você pode melhorar a taxa de transferência das solicitações de serviço Web do Studio (clássico) por meio de "envio em lote" de várias linhas na mesma chamada à API do serviço Web. Esse agrupamento é chamado de minilote. Para saber mais, confira Serviços Web do Machine Learning Studio (clássico). Suporte para o Studio (clássico) no Stream Analytics.

Configurar um trabalho do Stream Analytics com as funções do Studio (clássico)

Há dois parâmetros para configurar a função do Studio (clássico) usada pelo seu trabalho do Stream Analytics:

  • Tamanho do lote das chamadas de função do Studio (clássico).
  • O número de unidades de streaming (SUs) provisionadas para o trabalho do Stream Analytics.

Para determinar os valores apropriados para as SUs, decida se deseja otimizar a latência do trabalho do Stream Analytics ou a taxa de transferência de cada SU. As SUs podem ser sempre adicionadas a um trabalho a fim de aumentar a taxa de transferência de uma consulta do Stream Analytics bem particionada. SUs adicionais aumentam o custo da execução do trabalho.

Determine a tolerância de latência do seu trabalho do Stream Analytics. Aumentar o tamanho do lote aumentará a latência das solicitações do Studio (clássico) e a latência do trabalho do Stream Analytics.

O aumento do tamanho do lote permite que o trabalho do Stream Analytics processe mais eventos com o mesmo número de solicitações de serviço Web do Studio (clássico). Normalmente, o aumento da latência de serviço Web do Studio (clássico) é sublinear ao aumento do tamanho do lote.

É importante considerar o tamanho de lote mais econômico para um serviço Web do Studio (clássico) em qualquer situação. O tamanho de lote padrão para solicitações de serviço Web é 1000. Você pode alterar esse tamanho padrão usando a API REST do Stream Analytics ou o cliente do PowerShell para Stream Analytics.

Depois de decidir o tamanho de lote, defina o número de unidades de streamings (SUs) com base no número de eventos que a função precisa processar por segundo. Para obter mais informações sobre o unidades de streaming, consulte Dimensionar trabalhos do Trabalhos de escala do Stream Analytics.

Cada 6 SUs recebem 20 conexões simultâneas com o serviço Web do Studio (clássico). No entanto, um trabalho de SU e 3 trabalhos de SU recebem 20 conexões simultâneas.

Se o seu aplicativo gera 200.000 eventos por segundo, e o tamanho do lote é 1000, a latência do serviço Web resultante é de 200 ms. Essa taxa significa que cada conexão pode fazer cinco solicitações para o serviço Web do Studio (clássico) a cada segundo. Com 20 conexões, o trabalho do Stream Analytics pode processar 20.000 eventos em 200 ms e 100.000 eventos em um segundo.

Para processar 200.000 eventos por segundo, o trabalho do Stream Analytics precisará de 40 conexões simultâneas, provenientes de 12 SUs. O diagrama a seguir ilustra as solicitações do trabalho do Stream Analytics para o ponto de extremidade de serviço Web do Studio (clássico) – a cada 6 SUs há, no máximo, 20 conexões simultâneas com o serviço Web do Studio (clássico).

Scale Stream Analytics with Studio (classic) Functions two job example

Em geral, B para tamanho do lote, L para a latência do serviço Web com o tamanho do lote B em milissegundos, a taxa de transferência de um trabalho do Stream Analytics com N SUs será:

Scale Stream Analytics with Studio (classic) Functions Formula

Você também pode configurar o “máximo de chamadas simultâneas”' no serviço Web do Studio (clássico). É recomendado definir esse parâmetro como o valor máximo (200 no momento).

Para saber mais sobre essa configuração, examine o artigo sobre dimensionamento de serviços Web do Estúdio do Azure Machine Learning.

Exemplo – análise de sentimento

O exemplo a seguir inclui um trabalho do Stream Analytics com a função do Studio (clássico) de análise de sentimento, conforme descrito no Tutorial de integração do Estúdio do Azure Machine Learning do Stream Analytics.

A consulta é uma consulta simples e totalmente particionada, seguida pela função sentimento, conforme mostrado abaixo:

    WITH subquery AS (
        SELECT text, sentiment(text) as result from input
    )

    Select text, result.[Score]
    Into output
    From subquery

Vamos examinar a configuração necessária para criar um trabalho do Stream Analytics, que faz a análise de sentimento dos tweets a uma taxa de 10.000 tweets por segundo.

Com uma SU, esse trabalho do Stream Analytics processará o tráfego? O trabalho pode manter a entrada usando o tamanho de lote padrão de 1000. A latência padrão da análise de sentimento do serviço Web do Studio (clássico) (com um tamanho de lote padrão de 1 mil) cria não mais que um segundo de latência.

A latência geral ou de ponta a ponta do trabalho do Stream Analytics normalmente seria de alguns segundos. Dê uma olhada mais detalhada nesse trabalho do Stream Analytics, especialmente nas chamadas de função do Studio (clássico). Com um tamanho de lote de 1000, uma taxa de transferência de 10.000 eventos precisa de aproximadamente 10 solicitações ao serviço Web. Mesmo com uma AU, há conexões simultâneas suficientes para acomodar esse tráfego de entrada.

Se a taxa de eventos de entrada aumentar em 100x, o trabalho do Stream Analytics precisará processar 1.000.000 de tweets por segundo. Há duas opções para realizar o aumento da escala:

  1. Aumente o tamanho do lote.
  2. Particione o fluxo de entrada para processar os eventos simultaneamente.

Com a primeira opção, a latência do trabalho aumenta.

Com a segunda opção, você precisará provisionar mais SUs para ter mais solicitações simultâneas de serviço Web do Studio (clássico). Esse número maior de SUs aumenta o custo do trabalho.

Vamos examinar a colocação em escala usando as medidas de latência a seguir para cada tamanho de lote:

Latency Tamanho do lote
200 ms Lotes de 1.000 eventos ou menos
250 ms Lotes de 5.000 eventos
300 ms Lotes de 10.000 eventos
500 ms Lotes de 25.000 eventos
  1. Usando a primeira opção (não Provisionando mais SUs). O tamanho do lote pode ser aumentado para 25.000. Aumentar o tamanho do lote dessa maneira permitirá que o trabalho processe 1 milhão de eventos com 20 conexões simultâneas para o serviço Web do Studio (clássico) (com uma latência de 500 ms por chamada). Portanto, a latência adicional do trabalho do Stream Analytics causada pelas solicitações de função de sentimento aumentaria de 200 ms para 500 ms em comparação com as solicitações de serviço Web do Studio (clássico). No entanto, não é possível aumentar o tamanho do lote infinitamente, pois os serviços Web do Studio (clássico) exige que o tamanho do conteúdo de uma solicitação seja de 4 MB ou menos e o tempo limite das solicitações de serviço Web se esgota após 100 segundos de operação.
  2. Usando a segunda opção, o tamanho do lote é deixado em 1000, com latência de serviço Web de 200 ms, cada 20 conexões simultâneas com o serviço Web seriam capazes de processar 1000 * 20 * 5 eventos = 100.000 por segundo. Então, para processar 1.000.000 eventos por segundo, o trabalho precisaria de 60 SUs. Comparando com a primeira opção, o trabalho do Stream Analytics faria mais solicitações em lote do serviço Web, gerando um aumento do custo.

Veja abaixo uma tabela sobre a produtividade do trabalho do Stream Analytics para SUs e tamanhos de lote diferentes (em número de eventos por segundo).

tamanho do lote (latência de AM) 500 (200 ms) 1\.000 (200 ms) 5\.000 (250 ms) 10.000 (300 ms) 25.000 (500 ms)
1 SU 2\.500 5\.000 20,000 30,000 50.000
3 SUs 2\.500 5\.000 20,000 30,000 50.000
6 SUs 2\.500 5\.000 20,000 30,000 50.000
12 SUs 5\.000 10.000 40.000 60.000 100.000
18 SUs 7\.500 15,000 60.000 90.000 150.000
24 SUs 10.000 20,000 80.000 120.000 200.000
60 SUs 25.000 50.000 200.000 300.000 500.000

Agora, você já deve ter uma boa compreensão de como as funções do Studio (clássico) no Stream Analytics funcionam. É provável que você também entenda que os jobs do Stream Analytics "extraem" dados de fontes de dados e cada "pull" retorna um lote de eventos para o trabalho do Stream Analytics processar. Como esse modelo de obtenção afeta as solicitações de serviço Web do Studio (clássico)?

Normalmente, o tamanho do lote que definimos para as funções do Studio (clássico) não será exatamente divisível pelo número de eventos retornados para cada trabalho de "pull" do Stream Analytics. Quando isso ocorre, o serviço Web do Studio (clássico) é chamado com lotes "parciais". Usar lotes parciais evita a sobrecarga adicional de latência de trabalho em eventos acumulados a cada pull.

Na área de Monitoramento de um trabalho do Stream Analytics, foram adicionadas três métricas relacionadas à função. São elas FUNCTION REQUESTS, FUNCTION EVENTS e FAILED FUNCTION REQUESTS, como mostrado no gráfico a seguir.

Scale Stream Analytics with Studio (classic) Functions Metrics

Estas são as definições:

SOLICITAÇÕES DE FUNÇÃO: O número de solicitações de função.

EVENTOS DE FUNÇÃO: O número de eventos nas solicitações de função.

SOLICITAÇÕES DE FUNÇÃO COM FALHA: O número de solicitações de função com falha.

Principais observações

Para escalar um trabalho do Stream Analytics com funções do Studio (clássico), considere os seguintes fatores:

  1. A taxa de eventos de entrada.
  2. A latência tolerada para execução do trabalho do Stream Analytics (e, portanto, o tamanho do lote das solicitações de serviço Web do Studio (clássico)).
  3. As SUs do Stream Analytics provisionadas e o número de solicitações de serviço Web do Studio (clássico) (os custos adicionais relacionados à função).

Uma consulta do Stream Analytics totalmente particionada foi usada como exemplo. Se uma consulta mais complexa for necessária, a página de perguntas& respostas da Microsoft para o Azure Stream Analytics é um excelente recurso para se obter ajuda adicional da equipe do Stream Analytics.

Próximas etapas

Para saber mais sobre o Stream Analytics, confira: