Padrões de solução do Azure Stream Analytics
Assim como muitos outros serviços no Azure, o Stream Analytics é mais usado com outros serviços para criar uma solução maior de ponta a ponta. Este artigo aborda soluções de Azure Stream Analytics simples e vários padrões de arquitetura. Você pode se basear nesses 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 do cenário estão disponíveis em arquiteturas da solução do Azure.
Criar um trabalho do Stream Analytics para a experiência de criação de painéis em tempo real
Com Azure Stream Analytics, você pode criar rapidamente painéis e alertas em tempo real. Uma solução simples ingere eventos dos Hubs de Eventos ou do Hub IoT e alimenta o painel Power BI com um conjunto de dados de streaming. Para obter mais informações, consulte o tutorial detalhado Analisar dados de chamada fraudulenta com o Stream Analytics e visualizar os 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 origem do evento para o painel do Power BI em um navegador. O Azure Stream Analytics é o único serviço do Azure com esse recurso integrado.
Usar o SQL para painel
O painel do Power BI oferece baixa latência, mas não pode ser usado para produzir relatórios completos do Power BI. Um padrão de relatório comum é a saída dos dados primeiro para o Banco de Dados SQL. Em seguida, use o conector SQL do Power BI para consultar o SQL para os dados mais recentes.
Quando você usa o Banco de Dados SQL, ele oferece mais flexibilidade, mas às custas de uma latência ligeiramente maior. Essa solução é ideal para trabalhos com requisitos de latência maiores que um segundo. Ao usar esse método, você pode maximizar os recursos do Power BI para fatiar e analisar ainda mais os dados para relatórios e muito mais opções de visualização. Você também obterá 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. Atualmente, a taxa de transferência máxima para o Banco de Dados SQL do Azure Stream Analytics está em cerca de 24 MB/s. Se as origens do evento 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 o SQL. Você pode usar técnicas como filtragem, agregações em janelas, padrões correspondentes com junções temporais e funções analíticas. Você pode otimizar a taxa de saída para SQL usando técnicas descritas em Saída do Azure Stream Analytics para o Banco de Dados SQL do Azure.
Incorporar 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. Nesse padrão de solução, a lógica de negócios no Stream Analytics pode ser usada para detectar padrões ou anomaliastemporais 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, outros coletores de dados intermediários podem ser usados. Esses coletores incluem Hubs de Eventos, barramento de serviço e o Azure Functions. Você, como criador do aplicativo, precisa decidir qual coletor de dados funciona melhor para seu cenário.
Você precisa implementar a lógica do consumidor de eventos downstream para gerar alertas em seu fluxo de trabalho de negócios existente. Como você pode implementar uma 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 de trabalhos do Azure Stream Analytics. O Azure Functions também dá suporte a vários tipos de notificações, incluindo texto e email. 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 dos Hubs de Eventos. Os serviços podem ser conectados diretamente ao coletor dos 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 alta disponível no Azure para esses cenários de integração.
Aplicativos e sites dinâmicos
Você pode criar visualizações personalizadas em tempo real, como painel ou visualização de mapa, usando o Azure Stream Analytics e o Serviço do Azure SignalR. Ao usar o SignalR, os clientes da Web podem ser atualizados e mostrar conteúdo dinâmico em tempo real.
Incorporar insights em tempo real em seu aplicativo por meio de armazenamentos de dados
A maioria dos serviços Web e aplicativos Web atualmente usa um padrão de solicitação/resposta para atender à camada de apresentação. O padrão de solicitação/resposta é simples de criar e pode ser facilmente dimensionado com pouco tempo de resposta usando um front-end sem estado e armazenamentos escaloná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 aquisição de eventos é usado para resolver os gargalos de desempenho. Padrões temporais e insights também são difíceis e ineficientes para extrair de um armazenamento de dados tradicional. Aplicativos modernos baseados em dados de alto volume geralmente adotam uma arquitetura baseada em fluxo de dados. O Azure Stream Analytics como mecanismo de computação para dados em movimento é um linchpin nessa arquitetura.
Nesse padrão de solução, os eventos são processados e agregados em armazenamentos de dados pelo Azure Stream Analytics. A camada do aplicativo interage com os armazenamentos de dados usando o padrão de solicitação/resposta tradicional. Devido à capacidade do Stream Analytics de processar um grande número de eventos em tempo real, o aplicativo é altamente escalonável sem a necessidade de aumentar a camada do armazenamento de dados. A camada do repositório de dados é essencialmente uma exibição materializada no sistema. Saída do Azure Stream Analytics para o Azure Cosmos DB descreve como o Cosmos DB é usado como uma saída do Stream Analytics.
Em aplicativos reais em que a lógica de processamento é complexa e há a necessidade de atualizar determinadas partes da lógica de forma independente, vários trabalhos do Stream Analytics podem ser compostos junto com os Hubs de Eventos como o agente de evento 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 único, há uma pequena chance de que eventos duplicados cheguem aos Hubs de Eventos intermediários. É importante para o trabalho do Stream Analytics downstream desduplicar eventos usando chaves lógicas em uma janela lookback. Para obter mais informações sobre a entrega de eventos, consulte a referência de Garantias de entrega de eventos.
Usar dados de referência para personalização do aplicativo
O recurso de dados de referência do Azure Stream Analytics foi projetado especificamente para a personalização do usuário final, como limite de alerta, regras de processamento e limites geográficos. A camada do aplicativo pode aceitar alterações de parâmetro e armazená-las no Banco de Dados SQL. O trabalho do Stream Analytics consulta periodicamente em busca de alterações do banco de dados e torna os parâmetros de personalização acessíveis por meio de uma junçã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 do SQL e junção de dados de referência.
Esse padrão também pode ser usado para implementar um mecanismo de regras em que os limites das regras são definidos a partir dos dados de referência. Para obter mais informações sobre regras, consulte Regras baseadas em limites de processos configuráveis no Azure Stream Analytics.
Adicionar Machine Learning aos insights em tempo real
O modelo de Detecção de Anomalias integrado do Azure Stream Analytics é uma maneira conveniente de introduzir Machine Learning no seu aplicativo em tempo real. Para uma variedade maior de Machine Learning, consulte O Azure Stream Analytics se integra ao de pontuação do Azure Machine Learning.
Para usuários avançados que querem incorporar treinamento e pontuação online no mesmo pipeline do Stream Analytics, consulte este exemplo de como fazer isso com regressão linear.
Data Warehousing em tempo real
Outro padrão comum é o armazenamento de dados em tempo real, também chamado de Data Warehouse. Além dos eventos que chegam aos Hubs de Eventos e ao Hub IoT 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, armazenamento de dados e encaminhamento. O Stream Analytics em execução em IoT Edge pode lidar normalmente com problemas de conectividade e limitação de largura de banda no sistema. O Stream Analytics pode dar suporte a taxas de transferência de até 200 MB/s durante a gravação no Azure Synapse Analytics.
Arquivar dados em tempo real para análise
A maioria das atividades de ciência de dados e análise ainda ocorre offline. Os dados podem ser arquivados no Azure Stream Analytics por meio dos formatos de saída do Azure Data Lake Store Gen2 e Parquet. Essa funcionalidade remove o atrito para alimentar dados diretamente no Azure Data Lake Analytics, no Azure Databricks e no Azure HDInsight. O Azure Stream Analytics é usado como mecanismo de 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.
Usar dados de referência para enriquecimento
O enriquecimento de dados geralmente é um requisito para os mecanismos de ETL. O Azure Stream Analytics dá suporte ao enriquecimento de dados com dados de referência do Banco do Dados SQL e do armazenamento de blobs do Azure. O enriquecimento de dados pode ser feito para a aterrissagem de dados no Azure Data Lake e no Azure Synapse Analytics.
Operacionalização de 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 loop de comentários. O loop de comentários permite que o aplicativo se ajuste automaticamente a padrões de alteração nos dados. Esse loop de comentários pode ser tão simples quanto alterar o valor do limite para alertas ou tão complexo quanto treinar novamente os modelos de Machine Learning. A mesma arquitetura de solução pode ser aplicada a ambos os trabalhos do ASA em execução na nuvem e no IoT Edge.
Como monitorar trabalhos do ASA
Um trabalho do Azure Stream Analytics pode ser executado 24/7 para processar eventos de entrada continuamente em tempo real. Sua garantia de tempo de atividade é crucial para a integridade do aplicativo 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 poderá experimentar 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 integridade dos trabalhos. Todos eles são exibidos por meio do serviço do Azure Monitor e podem ser exportados para o OMS. Para obter mais informações, confira Monitorar o trabalho do Stream Analytics com o portal do Azure.
Há duas coisas principais a serem monitoradas:
-
Primeiro, você precisa verificar se 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 com falha por vários motivos, inclusive 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 quão distante o pipeline de processamento está no tempo do relógio (segundos). Parte do atraso é atribuída à lógica de processamento inerente. Como resultado, monitorar a tendência crescente é muito mais importante do que monitorar o valor absoluto. O atraso de estado estável deve ser resolvido pelo design do aplicativo, não pelo monitoramento ou alertas.
Após a falha, os logs de atividades e os logs de diagnóstico são os melhores locais para começar a procurar erros.
Criar aplicativos resilientes e críticos
Independentemente de a SLA do Azure Stream Analytics e do cuidado com que você executa seu aplicativo de ponta a ponta, paralisações ocorrerão. Se o aplicativo for crítico, você precisará estar preparado para as paradas a fim de se recuperar normalmente.
Para aplicativos de alerta, o mais importante é detectar o próximo alerta. Você pode optar por reiniciar o trabalho do momento atual ao recuperar, ignorando os alertas passados. A semântica de hora de início do trabalho é pela primeira hora de saída e não pela primeira hora de entrada. A entrada é revertida para trás tempo suficiente para garantir que a primeira saída no momento especificado esteja concluída e correta. Você não obterá agregações parciais, nem disparará alertas inesperadamente como resultado.
Você também pode optar por iniciar a saída em um determinado período de tempo no passado. Os Hubs de Eventos e as políticas de retenção do Hub IoT têm uma quantidade razoável de dados para permitir o processamento do passado. A vantagem é a rapidez com que você pode acompanhar a hora atual e começar a gerar novos alertas em tempo. Os dados perdem seu valor rapidamente ao longo do tempo e, portanto, é importante acompanhar o momento atual rapidamente. Há duas maneiras de acompanhar rapidamente:
- Provisione mais recursos (SU) ao se recuperar.
- Reinicie a partir da hora atual.
A reinicialização a partir da hora atual é simples de fazer, com a compensação de deixar uma lacuna durante o processamento. Reiniciar dessa maneira pode ser adequado para cenários de alerta, mas pode ser problemático para cenários de painel e é um não início para cenários de arquivamento e armazenamento de dados.
O provisionamento de mais recursos pode acelerar o processo, mas o efeito de ter um surto de taxa de processamento é complexo.
Teste se seu trabalho é escalonável para um número maior de SUs. Nem todas as consultas são escalonáveis. Você precisa se certificar de que sua consulta esteja paralelizada.
Verifique se há partições suficientes nos Hubs de Eventos upstream ou no Hub IoT que você pode adicionar mais unidades de taxa de transferência (TUs) para escalar a taxa de transferência de entrada. Lembre-se de que cada TU dos Hubs de Eventos é maximizada a uma taxa de saída de 2 MB/s.
Verifique se você provisionou recursos suficientes nos coletores de saída (ou seja, no Banco de Dados SQL, no Azure Cosmos DB etc.) para que eles não limitem as chegadas na saída, pois isso pode fazer com que o sistema seja bloqueado.
A coisa mais importante é prever a alteração da taxa de processamento, testar esses cenários antes de entrar em produção e estar pronto para escalar o processamento corretamente durante o tempo de recuperação de falha.
No cenário extremo que os eventos de entrada são todos atrasados, é possível que todos os eventos atrasados sejam removidos caso tenha aplicado uma janela de chegada em atraso ao seu trabalho. A remoção dos eventos pode parecer um comportamento misterioso no início; no entanto, considerando que o Stream Analytics é um mecanismo de processamento em tempo real, espera-se que os eventos de entrada estejam próximos do tempo do relógio de parede. Ele precisa descartar eventos que violem essas restrições.
Arquiteturas Lambda ou processo de provisionamento
Felizmente, o padrão de arquivamento de dados anterior pode ser usado para processar esses eventos atrasados normalmente. A ideia é que o trabalho de arquivamento processa eventos de entrada em tempo de chegada e arquiva eventos no bucket de tempo certo no blob do Azure ou no Azure Data Lake Store com a hora do evento. Não importa a hora em que um evento chega, ele nunca será descartado. Ele sempre será aterrissar no bucket de tempo certo. Durante a recuperação, é possível reprocessar os eventos arquivados e fazer o provisionamento dos resultados para o armazenamento de sua escolha. Isso é semelhante a como os padrões lambda são implementados.
O processo de provisionamento 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ê precisa reimplementar toda a lógica de processamento.
Para o provisionamento, ainda é importante provisionar temporariamente mais recursos para os coletores de saída para processar uma taxa de transferência maior do que as necessidades de processamento em estado estável.
| Cenários | Reiniciar somente a partir de agora | Reiniciar a partir da hora da última parada | Reiniciar a partir de agora + provisionar com eventos arquivados |
|---|---|---|---|
| Dashboarding | Cria lacuna | OK para uma breve paralisação | Usar para uma longa paralisação |
| Alertas | Aceitável | OK para uma breve paralisação | Não é necessário |
| Aplicativo de fornecimento de eventos | Aceitável | OK para uma breve paralisação | Usar para uma longa paralisação |
| Data warehouse | Perda de dados | Aceitável | Não é necessário |
| Análise offline | Perda de dados | Aceitável | Não é necessário |
Juntando as peças
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, aplicativos de fornecimento de eventos, armazenamento de dados e recursos de análise offline.
O importante é projetar seu sistema em padrões combináveis, para que cada subsistema possa ser compilado, testado, atualizado e recuperado de forma independente.
Próximas etapas
Agora, você viu uma variedade de padrões de solução usando o Azure Stream Analytics. Em seguida, você pode se aprofundar e criar seu primeiro trabalho do Stream Analytics: