Dimensione seu trabalho do Stream Analytics com funções (clássicas) do Machine Learning Studio
Gorjeta
É altamente recomendável usar UDFs do Azure Machine Learning em vez de UDF do Machine Learning Studio (clássico) para melhorar o desempenho e a confiabilidade.
Importante
O suporte para o Azure Machine Learning Studio (clássico) terminará em 31 de agosto de 2024. Recomendamos que faça a transição para o Azure Machine Learning até essa data.
A partir de 1º de dezembro de 2021, não é possível criar novos recursos (clássicos) do Machine Learning Studio (espaço de trabalho e plano de serviço Web). Até 31 de agosto de 2024, você pode continuar a usar os experimentos e serviços Web existentes do Machine Learning Studio (clássicos). Para obter mais informações, consulte:
- Migrar para o Azure Machine Learning a partir do Machine Learning Studio (clássico)
- O que é o Azure Machine Learning?
A documentação do Machine Learning Studio (clássica) está sendo desativada e pode não ser atualizada no futuro.
Este artigo descreve como dimensionar com eficiência os trabalhos do Azure Stream Analytics que usam funções (clássicas) do Machine Learning Studio. Para obter informações sobre como dimensionar trabalhos do Stream Analytics em geral, consulte o artigo Dimensionamento de trabalhos.
O que é uma função Studio (clássica) no Stream Analytics?
Uma função (clássica) do Machine Learning Studio no Stream Analytics pode ser usada como uma chamada de função normal na linguagem de consulta do Stream Analytics. Nos bastidores, no entanto, essas chamadas de função são, na verdade, solicitações de serviço Web Studio (clássicas).
Você pode melhorar a taxa de transferência de solicitações de serviço Web do Studio (clássico) "agrupando" várias linhas juntas na mesma chamada de API de serviço Web. Esse agrupamento é chamado de minilote. Para obter mais informações, consulte Serviços Web do Machine Learning Studio (clássico). Suporte para Studio (clássico) no Stream Analytics.
Configurar um trabalho do Stream Analytics com funções do Studio (clássicas)
Há dois parâmetros para configurar a função Studio (clássica) usada pelo seu trabalho do Stream Analytics:
- Tamanho do lote das chamadas de função Studio (clássicas).
- O número de unidades de streaming (SUs) provisionadas para o trabalho do Stream Analytics.
Para determinar os valores apropriados para SUs, decida se deseja otimizar a latência do trabalho do Stream Analytics ou a taxa de transferência de cada SU. Os SUs sempre podem ser adicionados a um trabalho para aumentar a taxa de transferência de uma consulta do Stream Analytics bem particionada. SUs adicionais aumentam o custo de execução do trabalho.
Determine a tolerância de latência para seu trabalho do Stream Analytics. Aumentar o tamanho do lote aumentará a latência das solicitações do Studio (clássicas) e a latência do trabalho do Stream Analytics.
Aumentar o 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). O aumento da latência do serviço Web Studio (clássico) é geralmente sublinear ao aumento do tamanho do lote.
É importante considerar o tamanho de lote mais econômico para um serviço Web 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 PowerShell para Stream Analytics.
Depois de decidir o tamanho de um lote, você pode definir o número de unidades de streaming (SUs), com base no número de eventos que a função precisa processar por segundo. Para obter mais informações sobre unidades de streaming, consulte Trabalhos de escala do Stream Analytics.
Cada 6 SUs obtêm 20 conexões simultâneas com o serviço Web Studio (clássico). No entanto, 1 trabalho SU e 3 empregos SU obter 20 conexões simultâneas.
Se seu aplicativo gerar 200.000 eventos por segundo e o tamanho do lote for 1000, a latência do serviço Web resultante será de 200 ms. Essa taxa significa que cada conexão pode fazer cinco solicitações ao serviço Web 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 precisa de 40 conexões simultâneas, que saem para 12 SUs. O diagrama a seguir ilustra as solicitações do trabalho do Stream Analytics para o ponto de extremidade do serviço Web Studio (clássico) – Cada 6 SUs tem 20 conexões simultâneas com o serviço Web Studio (clássico) no máximo.
Em geral, B para o tamanho do lote, L para a latência do serviço Web no tamanho do lote B em milissegundos, a taxa de transferência de um trabalho do Stream Analytics com N SUs é:
Você também pode configurar o 'máximo de chamadas simultâneas' no serviço Web Studio (clássico). Recomenda-se definir este parâmetro para o valor máximo (200 atualmente).
Para obter mais informações sobre essa configuração, consulte o artigo Dimensionamento para Serviços Web do Machine Learning Studio (clássico).
Exemplo – Análise de Sentimento
O exemplo a seguir inclui um trabalho do Stream Analytics com a função de análise de sentimento Studio (clássica), conforme descrito no tutorial de integração do Stream Analytics Machine Learning Studio (clássico).
A consulta é uma consulta simples totalmente particionada seguida pela função sentimento, conforme mostrado no exemplo a seguir:
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 análise de sentimento de tweets a uma taxa de 10.000 tweets por segundo.
Usando 1 SU, esse trabalho do Stream Analytics poderia lidar com o tráfego? O trabalho pode acompanhar a entrada usando o tamanho de lote padrão de 1000. A latência padrão do serviço Web de análise de sentimento Studio (clássico) (com um tamanho de lote padrão de 1000) não cria mais de 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 neste trabalho do Stream Analytics, especialmente as chamadas de função Studio (clássicas). Com um tamanho de lote de 1000, uma taxa de transferência de 10.000 eventos leva cerca de 10 solicitações para o serviço Web. Mesmo com um SU, 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. Existem duas opções para realizar a escala aumentada:
- Aumente o tamanho do lote.
- Particione o fluxo de entrada para processar os eventos em paralelo.
Com a primeira opção, a latência do trabalho aumenta.
Com a segunda opção, você terá que provisionar mais SUs para ter mais solicitações simultâneas de serviços Web Studio (clássicos). Este maior número de SUs, aumenta o custo do trabalho.
Vamos examinar o dimensionamento usando as seguintes medições de latência para cada tamanho de lote:
| Latência | Tamanho do lote |
|---|---|
| 200 ms | Lotes de 1000 eventos ou inferiores |
| 250 ms | Lotes de 5.000 eventos |
| 300 ms | Lotes de 10.000 eventos |
| 500 ms | Lotes de 25.000 eventos |
- Usando a primeira opção (não provisionar mais SUs). O tamanho do lote poderia ser aumentado para 25.000. Aumentar o tamanho do lote dessa forma permitirá que o trabalho processe 1.000.000 de eventos com 20 conexões simultâneas ao serviço Web Studio (clássico) (com uma latência de 500 ms por chamada). Assim, a latência adicional do trabalho do Stream Analytics devido às solicitações de função de sentimento em relação às solicitações de serviço Web do Studio (clássico) seria aumentada de 200 ms para 500 ms. No entanto, o tamanho do lote não pode ser aumentado infinitamente, pois os serviços Web Studio (clássicos) exigem que o tamanho da carga útil de uma solicitação seja de 4 MB ou menor, e o tempo limite das solicitações de serviço Web após 100 segundos de operação.
- 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. Assim, para processar 1.000.000 de eventos por segundo, o trabalho precisaria de 60 SUs. Em comparação com a primeira opção, o trabalho do Stream Analytics faria mais solicitações em lote de serviços Web, gerando um custo maior.
Abaixo está uma tabela para a taxa de transferência do trabalho do Stream Analytics para diferentes SUs e tamanhos de lote (em número de eventos por segundo).
| tamanho do lote (latência de ML) | 500 (200 ms) | 1.000 (200 ms) | 5.000 (250 ms) | 10.000 (300 ms) | 25.000 (500 ms) |
|---|---|---|---|---|---|
| 1 SU | 2500 | 5.000 | 20.000 | 30 000 | 50 000 |
| 3 SUs | 2500 | 5.000 | 20.000 | 30 000 | 50 000 |
| 6 SUs | 2500 | 5.000 | 20.000 | 30 000 | 50 000 |
| 12 SUs | 5.000 | 10.000 | 40.000 | 60 000 | 100.000 |
| 18 SUs | 7500 | 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 |
Até agora, você já deve ter uma boa compreensão de como funcionam as funções do Studio (clássicas) no Stream Analytics. Você provavelmente também entende que os trabalhos 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 pull 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 por cada trabalho "pull" do Stream Analytics. Quando isso ocorre, o serviço Web Studio (clássico) é chamado com lotes "parciais". O uso de lotes parciais evita incorrer em sobrecarga de latência de trabalho adicional na coalescência de eventos de pull to pull.
Novas métricas de monitoramento relacionadas à função
Na área Monitor de um trabalho do Stream Analytics, três métricas adicionais relacionadas à função foram adicionadas. São eles FUNCTION REQUESTS, FUNCTION EVENTS e FAILED FUNCTION REQUESTS, como mostra o gráfico abaixo.
Os são definidos da seguinte forma:
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 conclusões
Para dimensionar um trabalho do Stream Analytics com funções (clássicas) do Studio, considere os seguintes fatores:
- A taxa de eventos de entrada.
- A latência tolerada para o trabalho do Stream Analytics em execução (e, portanto, o tamanho do lote das solicitações de serviço Web do Studio (clássico)).
- Os SUs provisionados do Stream Analytics e o número de solicitações de serviço Web Studio (clássico) (os custos adicionais relacionados à função).
Uma consulta do Stream Analytics totalmente particionada foi usada como exemplo. Se for necessária uma consulta mais complexa, a página de perguntas e respostas da Microsoft para o Azure Stream Analytics é um ótimo recurso para obter ajuda adicional da equipe do Stream Analytics.
Próximos passos
Para saber mais sobre o Stream Analytics, consulte: