Padrões da solução Azure Stream Analytics
Como muitos outros serviços no Azure, o Stream Analytics é melhor usado com outros serviços para criar uma solução de ponta a ponta maior. Este artigo discute soluções simples do Azure Stream Analytics e vários padrões de arquitetura. Você pode aproveitar esses padrões para desenvolver soluções mais complexas. Os padrões descritos neste artigo podem ser usados em uma ampla variedade de cenários. Exemplos de padrões específicos de cenário estão disponíveis em arquiteturas de solução do Azure.
Crie um trabalho do Stream Analytics para potencializar a experiência de painel em tempo real
Com o Azure Stream Analytics, você pode criar rapidamente painéis e alertas em tempo real. Uma solução simples ingere eventos de Hubs de Eventos ou Hub IoT e alimenta o painel do Power BI com um conjunto de dados de streaming. Para obter mais informações, consulte o tutorial detalhado Analisar dados de chamadas fraudulentas com o Stream Analytics e visualizar resultados no painel do Power BI.
Você pode criar essa solução em apenas alguns minutos usando o portal do Azure. Você não precisa codificar extensivamente. Em vez disso, você pode usar a linguagem SQL para expressar a lógica de negócios.
Esse padrão de solução oferece a menor latência da fonte de eventos para o painel do Power BI em um navegador. O Azure Stream Analytics é o único serviço do Azure com essa capacidade interna.
Usar SQL para painel
O painel do Power BI oferece baixa latência, mas você não pode usá-lo para produzir relatórios completos do Power BI. Um padrão de relatório comum é enviar seus dados para o Banco de dados SQL primeiro. Em seguida, use o conector SQL do Power BI para consultar o SQL para obter os dados mais recentes.
Quando você usa o Banco de dados SQL, ele oferece mais flexibilidade, mas às custas de uma latência um pouco maior. Esta solução é ideal para trabalhos com requisitos de latência superiores a um segundo. Ao usar esse método, você pode maximizar os recursos do Power BI para fatiar e segmentar ainda mais os dados para relatórios e muito mais opções de visualização. Você também ganha a flexibilidade de usar outras soluções de painel, como o Tableau.
O SQL não é um armazenamento de dados de alta taxa de transferência. A taxa de transferência máxima para o Banco de Dados SQL do Azure Stream Analytics é atualmente de cerca de 24 MB/s. Se as fontes de eventos em sua solução produzirem dados a uma taxa mais alta, você precisará usar a lógica de processamento no Stream Analytics para reduzir a taxa de saída para SQL. Você pode usar técnicas como filtragem, agregações em janela, correspondência de padrões com junções temporais e funções analíticas. Você pode otimizar a taxa de saída para SQL usando técnicas descritas na saída do Azure Stream Analytics para o Banco de Dados SQL do Azure.
Incorpore informações em tempo real em seu aplicativo com mensagens de eventos
O segundo uso mais popular do Stream Analytics é gerar alertas em tempo real. Neste padrão de solução, a lógica de negócios no Stream Analytics pode ser usada para detetar padrões ou anomalias temporais e espaciais e, em seguida, produzir sinais de alerta. No entanto, ao contrário da solução de painel em que o Stream Analytics usa o Power BI como um ponto de extremidade preferencial, você pode usar outros coletores de dados intermediários. Esses coletores incluem Hubs de Eventos, Barramento de Serviço e Azure Functions. Você, como construtor de aplicativos, precisa decidir qual coletor de dados funciona melhor para seu cenário.
Você precisa implementar a lógica de consumidor de eventos downstream para gerar alertas em seu fluxo de trabalho de negócios existente. Como você pode implementar a lógica personalizada no Azure Functions, o Azure Functions é a maneira mais rápida de executar essa integração. Para obter um tutorial sobre como usar o Azure Function como saída para um trabalho do Stream Analytics, consulte Executar o Azure Functions a partir de trabalhos do Azure Stream Analytics. O Azure Functions também suporta vários tipos de notificações, incluindo texto e e-mail. Você também pode usar Aplicativos Lógicos para essa integração, com Hubs de Eventos entre o Stream Analytics e os Aplicativos Lógicos.
O serviço Hubs de Eventos do Azure, por outro lado, oferece o ponto de integração mais flexível. Muitos outros serviços, como o Azure Data Explorer e o Time Series Insights, podem consumir eventos de Hubs de Eventos. Os serviços podem ser conectados diretamente ao coletor de Hubs de Eventos do Azure Stream Analytics para concluir a solução. Os Hubs de Eventos também são o agente de mensagens de taxa de transferência mais alto disponível no Azure para esses cenários de integração.
Aplicações e websites dinâmicos
Você pode criar visualizações personalizadas em tempo real, como visualização de painel ou mapa, usando o Azure Stream Analytics e o Serviço Azure SignalR. Quando você usa o SignalR, os clientes da Web podem ser atualizados e mostrar conteúdo dinâmico em tempo real.
Incorpore insights em tempo real em seu aplicativo por meio de armazenamentos de dados
Atualmente, a maioria dos serviços Web e aplicativos Web usa um padrão de solicitação/resposta para servir a camada de apresentação. O padrão de solicitação/resposta é simples de criar e pode ser facilmente dimensionado com baixo tempo de resposta usando um frontend sem estado e armazenamentos escaláveis, como o Azure Cosmos DB.
O alto volume de dados geralmente cria gargalos de desempenho em um sistema baseado em CRUD. O padrão de solução de fornecimento de eventos é usado para resolver os gargalos de desempenho. Padrões temporais e insights também são difíceis e ineficientes de extrair de um armazenamento de dados tradicional. Os aplicativos modernos orientados por dados de alto volume geralmente adotam uma arquitetura baseada em fluxo de dados. O Azure Stream Analytics como o mecanismo de computação para dados em movimento é um ponto central nessa arquitetura.
Neste padrão de solução, os eventos são processados e agregados em armazenamentos de dados pelo Azure Stream Analytics. A camada de aplicativo interage com armazenamentos de dados usando o padrão tradicional de solicitação/resposta. Devido à capacidade do Stream Analytics de processar um grande número de eventos em tempo real, o aplicativo é altamente escalável sem a necessidade de aumentar a camada de armazenamento de dados. A camada de armazenamento de dados é essencialmente uma visão materializada no sistema. A saída do Azure Stream Analytics para o Azure Cosmos DB descreve como o Azure Cosmos DB é usado como uma saída do Stream Analytics.
Em aplicativos reais onde a lógica de processamento é complexa e há a necessidade de atualizar certas partes da lógica de forma independente, vários trabalhos do Stream Analytics podem ser compostos juntamente com Hubs de Eventos como o agente de eventos intermediário.
Esse padrão melhora a resiliência e a capacidade de gerenciamento do sistema. No entanto, embora o Stream Analytics garanta exatamente um processamento, há uma pequena chance de que eventos duplicados cheguem aos Hubs de Eventos intermediários. É importante que o trabalho do Stream Analytics downstream elimine eventos usando chaves lógicas em uma janela de retrospetiva. Para obter mais informações sobre a entrega de eventos, consulte Referência de garantias de entrega de eventos.
Usar dados de referência para personalização de aplicativos
O recurso de dados de referência do Azure Stream Analytics foi projetado especificamente para personalização do usuário final, como limite de alerta, regras de processamento e cercas geográficas. A camada de aplicativo pode aceitar alterações de parâmetros e armazená-las no Banco de dados SQL. O trabalho do Stream Analytics consulta periodicamente as alterações do banco de dados e torna os parâmetros de personalização acessíveis por meio de uma associação de dados de referência. Para obter mais informações sobre como usar dados de referência para personalização de aplicativos, consulte Dados de referência SQL e associação de dados de referência.
Esse padrão também pode ser usado para implementar um mecanismo de regras onde os limites das regras são definidos a partir de dados de referência. Para obter mais informações sobre regras, consulte Processar regras baseadas em limites configuráveis no Azure Stream Analytics.
Adicione o Machine Learning aos seus insights em tempo real
O modelo de Deteção de Anomalias incorporado do Azure Stream Analytics é uma forma conveniente de introduzir o Machine Learning na sua aplicação em tempo real. Para obter uma gama mais ampla de necessidades de Aprendizado de Máquina, consulte O Azure Stream Analytics integra-se ao serviço de pontuação do Azure Machine Learning.
Para usuários avançados que desejam incorporar treinamento e pontuação on-line no mesmo pipeline do Stream Analytics, veja este exemplo de como fazer isso com a regressão linear.
Armazenamento de dados em tempo real
Outro padrão comum é o armazenamento de dados em tempo real, também chamado de data warehouse de streaming. Além dos eventos que chegam aos Hubs de Eventos e ao Hub IoT a partir do seu aplicativo, o Azure Stream Analytics em execução no IoT Edge pode ser usado para atender às necessidades de limpeza de dados, redução de dados e armazenamento e encaminhamento de dados. O Stream Analytics em execução no IoT Edge pode lidar com problemas de limitação de largura de banda e conectividade no sistema. O Stream Analytics pode suportar taxas de transferência de até 200 MB/seg enquanto escreve no Azure Synapse Analytics.
Arquivamento de dados em tempo real para análise
A maioria das atividades de ciência de dados e análise ainda acontece offline. Você pode arquivar dados no Azure Stream Analytics por meio dos formatos de saída Gen2 e Parquet do Azure Data Lake Store. Esse recurso remove o atrito para alimentar dados diretamente no Azure Data Lake Analytics, Azure Databricks e Azure HDInsight. O Azure Stream Analytics é usado como um mecanismo ETL (Extract-Transform-Load) quase em tempo real nesta solução. Você pode explorar dados arquivados no Data Lake usando vários mecanismos de computação.
Utilizar dados de referência para enriquecimento
O enriquecimento de dados é muitas vezes um requisito para motores ETL. O Azure Stream Analytics dá suporte ao enriquecimento de dados com dados de referência do Banco de Dados SQL e do armazenamento de Blob do Azure. O enriquecimento de dados pode ser feito para aterrissagem de dados no Azure Data Lake e no Azure Synapse Analytics.
Operacionalizar insights de dados arquivados
Se você combinar o padrão de análise offline com o padrão de aplicativo quase em tempo real, poderá criar um ciclo de feedback. O loop de feedback permite que o aplicativo se ajuste automaticamente para alterar padrões nos dados. Esse ciclo de feedback pode ser tão simples quanto alterar o valor limite para alertas ou tão complexo quanto retreinar modelos de Machine Learning. A mesma arquitetura de solução pode ser aplicada a trabalhos ASA executados na nuvem e no IoT Edge.
Como monitorar trabalhos ASA
Um trabalho do Azure Stream Analytics pode ser executado 24 horas por dia, 7 dias por semana, para processar eventos de entrada continuamente em tempo real. Sua garantia de tempo de atividade é crucial para a saúde da aplicação geral. Embora o Stream Analytics seja o único serviço de análise de streaming no setor que oferece uma garantia de disponibilidade de 99,9%, você ainda incorre em algum nível de tempo de inatividade. Ao longo dos anos, o Stream Analytics introduziu métricas, logs e estados de trabalho para refletir a saúde dos trabalhos. Todos eles são apresentados por meio do serviço Azure Monitor e podem ser exportados para o OMS. Para obter mais informações, consulte Monitorar o trabalho do Stream Analytics com o portal do Azure.
Há duas coisas fundamentais a monitorizar:
-
Em primeiro lugar, você precisa ter certeza de que o trabalho está em execução. Sem o trabalho no estado de execução, nenhuma nova métrica ou log é gerado. Os trabalhos podem mudar para um estado de falha por vários motivos, incluindo ter um alto nível de utilização de SU (ou seja, ficar sem recursos).
Métricas de atraso de marca d'água
Essa métrica reflete o quanto o pipeline de processamento está atrasado em tempo de relógio de parede (segundos). Parte do atraso é atribuído à lógica de processamento inerente. Como resultado, monitorar a tendência crescente é muito mais importante do que monitorar o valor absoluto. O atraso em estado estacionário deve ser resolvido pelo design do seu aplicativo, não por monitoramento ou alertas.
Em caso de falha, os logs de atividade e os logs de diagnóstico são os melhores lugares para começar a procurar erros.
Crie aplicativos resilientes e de missão crítica
Independentemente da garantia de SLA do Azure Stream Analytics e do cuidado com que você executa seu aplicativo de ponta a ponta, as interrupções acontecem. Se o seu aplicativo é de missão crítica, você precisa estar preparado para interrupções, a fim de recuperar normalmente.
Para aplicativos de alerta, o mais importante é detetar o próximo alerta. Você pode optar por reiniciar o trabalho a partir da hora atual durante a recuperação, ignorando alertas anteriores. A semântica da hora de início do trabalho é pela primeira hora de saída, não pela primeira hora de entrada. A entrada é rebobinada para trás um período de tempo apropriado para garantir que a primeira saída no momento especificado esteja completa e correta. Como resultado, você não receberá agregações parciais e disparará alertas inesperadamente.
Você também pode optar por iniciar a saída de algum tempo no passado. Tanto os Hubs de Eventos quanto as políticas de retenção do Hub IoT armazenam uma quantidade razoável de dados para permitir o processamento do passado. A contrapartida é a rapidez com que você pode alcançar a hora atual e começar a gerar novos alertas oportunos. Os dados perdem seu valor rapidamente ao longo do tempo, por isso é importante acompanhar o tempo atual rapidamente. Há duas maneiras de recuperar o atraso rapidamente:
- Prover mais recursos (SU) quando recuperar o atraso.
- Reinicie a partir da hora atual.
Recomeçar a partir do tempo atual é simples de fazer, com a compensação de deixar uma lacuna durante o processamento. Reiniciar dessa maneira pode ser OK para cenários de alerta, mas pode ser problemático para cenários de painel e não é um ponto de partida para cenários de arquivamento e armazenamento de dados.
O provisionamento de mais recursos pode acelerar o processo, mas o efeito de ter um aumento na taxa de processamento é complexo.
Teste se o seu trabalho é escalável para um número maior de SUs. Nem todas as consultas são escaláveis. Você precisa ter certeza de que sua consulta está paralelizada.
Verifique se há partições suficientes nos Hubs de Eventos upstream ou no Hub IoT para que você possa adicionar mais Unidades de Taxa de Transferência (TUs) para dimensionar a taxa de transferência de entrada. Lembre-se, cada TU de Hubs de Eventos atinge o máximo a uma taxa de saída de 2 MB/s.
Certifique-se de ter provisionado recursos suficientes nos coletores de saída (ou seja, Banco de Dados SQL, Azure Cosmos DB), para que eles não limitem o aumento na saída, o que às vezes pode fazer com que o sistema trave.
O mais importante é antecipar a mudança na taxa de processamento, testar esses cenários antes de entrar em produção e estar pronto para dimensionar o processamento corretamente durante o tempo de recuperação de falhas.
No cenário extremo em que os eventos de entrada estão todos atrasados, é possível que todos os eventos atrasados sejam descartados se você tiver aplicado uma janela de chegada tardia ao seu trabalho. A queda dos eventos pode parecer um comportamento misterioso no início; no entanto, considerando que o Stream Analytics é um mecanismo de processamento em tempo real, ele espera que os eventos recebidos estejam próximos do tempo do relógio de parede. Tem que descartar eventos que violem essas restrições.
Arquiteturas do Lambda ou processo de preenchimento
Felizmente, o padrão de arquivamento de dados anterior pode ser usado para processar esses eventos tardios graciosamente. A ideia é que o trabalho de arquivamento processe os eventos de entrada na hora de chegada e arquive os eventos no bucket de tempo certo no Blob do Azure ou no Repositório Azure Data Lake com a hora do evento. Não importa quão tarde um evento chegue, ele nunca será descartado. Ele sempre pousará no balde de tempo certo. Durante a recuperação, é possível reprocessar os eventos arquivados e preencher os resultados para o repositório de escolha. Isso é semelhante à forma como os padrões lambda são implementados.
O processo de preenchimento deve ser feito com um sistema de processamento em lote offline, que provavelmente tem um modelo de programação diferente do Azure Stream Analytics. Isso significa que você tem que reimplementar toda a lógica de processamento.
Para o backfilling, ainda é importante provisionar pelo menos temporariamente mais recursos para os coletores de saída para lidar com uma taxa de transferência maior do que as necessidades de processamento em estado estacionário.
| Cenários | Reiniciar apenas a partir de agora | Reiniciar a partir da última hora parada | Reiniciar a partir de agora + preenchimento com eventos arquivados |
|---|---|---|---|
| Painel de controle | Cria lacuna | OK para interrupções curtas | Utilização para interrupções prolongadas |
| Alertas | Aceitável | OK para interrupções curtas | Não é necessário |
| Aplicativo de sourcing de eventos | Aceitável | OK para interrupções curtas | Utilização para interrupções prolongadas |
| Armazenamento de dados | Perda de dados | Aceitável | Não é necessário |
| Análise offline | Perda de dados | Aceitável | Não é necessário |
Juntar tudo
Não é difícil imaginar que todos os padrões de solução mencionados anteriormente podem ser combinados em um sistema complexo de ponta a ponta. O sistema combinado pode incluir painéis, alertas, aplicativo de fornecimento de eventos, data warehouse e recursos de análise offline.
A chave é projetar seu sistema em padrões combináveis, para que cada subsistema possa ser construído, testado, atualizado e recuperado de forma independente.
Próximos passos
Agora você viu vários padrões de solução usando o Azure Stream Analytics. Em seguida, pode criar o seu primeiro trabalho do Stream Analytics e experimentá-lo na prática:
- Create a Stream Analytics job by using the Azure portal (Criar um trabalho do Stream Analytics com o portal do Azure).
- Create a Stream Analytics job by using Azure PowerShell (Criar um trabalho do Stream Analytics com o Azure PowerShell).
- Crie um trabalho do Stream Analytics usando o Visual Studio.