Artigo
01/20/2016

Janeiro de 2016

Volume 31 – Número 1

Big Data - Análise de dados em tempo real para desenvolvedores do .NET usando o HDInsight

Empresas de todos os portes começaram a reconhecer o valor de seus enormes conjuntos de dados e a necessidade de aproveitá-los. À medida que as organizações iniciam a utilização de Big Data, geralmente começam com o processamento em lotes de seus ativos de Big Data. Isso pode significar a coleta e a agregação de dados de blogs, cliques do usuário em um aplicativo, telemetria de dispositivos da IoT (Internet das Coisas) ou uma série de outros dados gerados por seres humanos ou por máquinas. Abordei o caso da análise básica de blogs usando o Hive no HDInsight em um artigo há um ano (msdn.com/magazine/dn890370). No entanto, à medida que são alcançados os benefícios do processamento em lotes para obter insights sobre dados históricos, muitas organizações se deparam com o problema de lidar com dados em tempo real e a questão de como coletar, analisar e agir em relação a fluxos contínuos em tempo real.

Como você pode imaginar, existem tecnologias no âmbito de Big Data para abordar essas necessidades. A plataforma Microsoft Azure fornece soluções avançadas para Big Data, como o Azure Data Lake e o HDInsight. Há uma tecnologia de software livre que permite a análise em tempo real altamente distribuída: o Apache Storm. Ele tem suporte nativo no HDInsight, o produto gerenciado do Azure para serviços de Big Data do Apache. Neste artigo, examinarei um cenário simples, mas avançado, que lida com um fluxo de tweets usando o Storm como a ferramenta principal para habilitar a análise contínua em tempo real.

Como você verá, a Microsoft torna esse tipo de desenvolvimento significativamente mais fácil do que outros produtos oferecidos atualmente no mercado, por meio de ferramentas avançadas de criação e depuração no Visual Studio. As Ferramentas do HDInsight para Visual Studio (disponíveis como parte do SDK do Azure) fornecem um ambiente de codificação e depuração familiar aos desenvolvedores do .NET. Essas ferramentas oferecem uma maneira muito mais fácil de se trabalhar com tecnologias de Big Data do que os editores e as ferramentas de linha de comando simples, disponíveis atualmente no mundo do software livre. Embora o Storm para HDInsight dê suporte completo ao uso de programação Java, a Microsoft também habilita os programadores do .NET a usar C# para escrever (e reutilizar) a lógica de negócios. Os exemplos neste artigo demonstram esses recursos do .NET.

Um cenário de acompanhamento de opiniões

O cenário de acompanhamento e análise de tendências emergentes não é novo. Relatos de notícias, acompanhamento do clima e detecção de desastres são exemplos anteriores à computação em nuvem. No entanto, com o progresso da era da nuvem, as áreas em que a detecção de tendências é desejável e a escala em que os dados estão disponíveis para análise se expandiram de forma inimaginável. As redes sociais têm se demonstrado um terreno fértil para a análise de opiniões. Com serviços como o Twitter, que disponibilizam seus dados sociais por meio de APIs, juntamente com plataformas de Big Data pré-pagas, como o HDInsight, a análise de opiniões está ao alcance de organizações de grande e pequeno porte.

O tipo mais simples de análise de opiniões que utiliza o Twitter é contar quantas vezes as pessoas postam tweets sobre certo tópico ou hashtag em um determinado período de tempo. É claro que fazer isso apenas por um período específico, digamos, por um minuto, não é tão interessante quanto fazê-lo a cada minuto do dia, para detectar um aumento ou uma queda na taxa. A identificação de picos de uso de um determinado termo pode ser útil para a detecção de uma tendência. Por exemplo, a detecção de termos relacionados a uma tempestade ou a um terremoto pode fornecer uma rápida indicação de áreas afetadas por um desastre natural e sua gravidade.

Para demonstrar as noções básicas de como isso é feito, explicarei como configurar uma topologia de streaming que coleta dados do Twitter, seleciona alguns dos tweets, calcula métricas, salva tudo no armazenamento e publica alguns dos resultados. Você pode ver a topologia na Figura 1. Para este artigo, selecionei tweets usando a correspondência de palavras-chave simples. As métricas calculadas são contagens de tweets que corresponderam aos critérios de seleção. Os tweets selecionados são colocados em um banco de dados SQL e também são publicados em um site. Tudo é feito na nuvem do Azure usando o Storm, o SQL Server e serviços de sites disponíveis atualmente. Após explicar o exemplo, discutirei algumas das outras tecnologias disponíveis para resolver esse tipo de problema de análise de dados de streaming.

Figura 1 Topologia de análise de opiniões

As noções básicas do Storm

O Storm é um projeto de software livre da Apache (storm.apache.org) que permite efetuar cálculos distribuídos em tempo real em relação a fluxos de dados. Ele faz parte do ecossistema Hadoop de ferramentas de processamento de Big Data e tem suporte direto no HDInsight. Os trabalhos do Storm são definidos como um gráfico de nós de processamento conectados por fluxos de dados na forma de tuplas. Um gráfico desse tipo é chamado de "topologia" no Storm. As topologias não são concluídas como outras consultas: elas continuam a ser executadas até serem suspensas ou eliminadas.

No portal de gerenciamento do Azure, você pode criar um novo cluster HDInsight e escolher o Storm como o tipo. Isso faz com que, em questão de minutos, o Azure crie um cluster de computadores pré-carregados com todos os componentes necessários do sistema operacional, do Hadoop e do Storm. Posso escolher o número de nós que desejo, selecionar diferentes tamanhos de núcleo e de memória e escalar ou reduzir verticalmente o número de nós a qualquer momento. No que se refere a simplificar a experiência do Hadoop, isso já me poupou muito tempo e muitas dores de cabeça associadas à aquisição e à configuração de vários computadores.

Os componentes de uma topologia são chamados de spouts e bolts. Os spouts produzem fluxos de tuplas, que, basicamente, são conjuntos de pares de tipo e valor. Em outras palavras, um spout é um trecho de código que sabe como coletar ou gerar dados e emiti-los em partes. Os bolts são unidades de código que podem consumir um fluxo de dados. Eles podem processar os dados para limpá-los ou calcular estatísticas. Nesses casos, é provável que emitam outro fluxo de tuplas para bolts downstream. Outros bolts gravam dados no armazenamento ou em outro sistema.

Cada um desses componentes pode executar muitas tarefas paralelas. Essa é a chave para a escalabilidade e a confiabilidade do Storm. Posso especificar o grau de paralelismo para cada componente, e o Storm aloca o número de tarefas necessário para executar a lógica no spout ou no bolt. O Storm fornece tolerância a falhas gerenciando as tarefas e reiniciando automaticamente as que falham. Por fim, uma determinada topologia é executada em um conjunto de processos de trabalho que são, essencialmente, contêineres de execução. É possível adicionar trabalhos para aumentar a capacidade de processamento de uma topologia. Esses recursos fornecem as características essenciais que habilitam a escala e a tolerância a falhas no Storm.

Uma topologia pode ser tão complexa quanto necessário para realizar o processamento exigido pelo cenário geral de análise em tempo real. A arquitetura se presta à reutilização de componentes, mas também cria um problema desafiador de gerenciamento e implantação à medida que o número de spouts e bolts aumenta. O conceito de projeto do Visual Studio é uma maneira útil de gerenciar os componentes de código e de configuração necessários para instanciar uma topologia. Como a própria noção de topologia tem natureza essencialmente gráfica, também faz sentido que a possibilidade de visualizar a topologia seja muito útil durante o desenvolvimento e a operação do sistema. Isso pode ser visto na exibição de execução das Ferramentas do HDInsight para Visual Studio, mostrada na Figura 2.

Figura 2 Exibição de monitoramento de uma topologia ativa do Storm

A arquitetura do Storm é baseada no Apache Thrift, uma estrutura que permite o desenvolvimento de serviços implementados em várias linguagens. Embora muitos desenvolvedores usem Java para escrever spouts e bolts, isso não é obrigatório. Com a introdução do pacote de bibliotecas SCP.Net, posso usar o C# para desenvolver spouts e bolts. Esse pacote está incluído no download das Ferramentas do HDInsight para Visual Studio, mas também pode ser baixado a partir do NuGet.

Filtragem de tweets quase em tempo real

Vamos examinar a compilação da topologia de filtragem de fluxo de tweets para ver como essas partes funcionam na prática. A topologia de exemplo é composta de um spout e três bolts. Você pode ver a exibição gráfica da topologia na Figura 2, como mostrado pelas Ferramentas do HDInsight para Visual Studio. Quando envio um projeto do Storm para execução no Azure, o Visual Studio mostra essa exibição gráfica e a atualiza ao longo do tempo com o número de eventos que fluem pelo sistema, bem como as condições de erro que ocorram em qualquer nó.

Aqui, o TwitterSpout é responsável por obter o fluxo de tweets que desejo processar. Ele faz isso interagindo com as APIs do Twitter para coletar tweets e os transforma em tuplas de dados que podem ser transmitidas através do restante da topologia. O TwitterBolt obtém o fluxo e pode fazer agregações, como contar tweets ou combiná-los a outros dados extraídos de outras fontes de dados. Esse bolt emite um novo fluxo, possivelmente com um novo formato, com base na lógica de negócios que ele executou. Os componentes AzureSQLBolt e SignalRBroadcastBolt consomem esse fluxo e gravam partes dos dados em um banco de dados SQLServer hospedado no Azure e em um site SignalR, respectivamente.

Como estou usando o C# para compilar a solução do Storm, posso usar muitas bibliotecas existentes para simplificar e acelerar o desenvolvimento. Dois pacotes-chave para esse exemplo são as bibliotecas Tweetinvi no CodePlex (bit.ly/1kI9sqV) e as bibliotecas SCP.Net no NuGet (bit.ly/1QwICPj).

A estrutura SCP.Net reduz muito a complexidade de lidar com o modelo de programação do Storm e fornece classes de base para encapsular a maior parte do trabalho que, de outra forma, seria manual. Começo herdando da classe de base Microsoft.SCP.ISCPSpout. Isso me fornece três métodos básicos necessários para um spout: NextTuple, Ack e Fail. NextTuple emite os próximos dados disponíveis para o fluxo ou não emite nada. Esse método é chamado em um loop estreito pelo Storm e é o lugar certo para que eu faça uma pausa, se não houver tuplas a serem emitidas. Essa é uma maneira de garantir que eu não consuma 100% dos ciclos da CPU enquanto a topologia for executada continuamente.

Para implementar o processamento de mensagens garantido, como a semântica "pelo menos uma vez" para as tuplas, eu usaria os métodos Ack e Fail para implementar os handshakes necessários entre bolts. No exemplo, não uso nenhum mecanismo de repetição. Portanto, apenas o método NextTuple é implementado, usando código que obtém tweets de um membro de uma fila privada na classe TwitterSpout e o envia à topologia.

Os fluxos na topologia são capturados como esquemas que são publicados por um spout ou bolt. Eles são usados como o contrato entre componentes na topologia e também como as regras de serialização e desserialização que o SCP.Net usa ao transferir os dados. A classe Context é usada para armazenar informações de configuração por instância de spout ou bolt. O esquema das tuplas emitidas pelo spout é armazenado no Context e usado pelo SCP.Net para compilar conexões de componentes.

Vamos examinar o código para a inicialização da classe TwitterSpout, mostrada em parte na Figura 3.

Figura 3 Inicialização da classe TwitterSpout

public TwitterSpout(Context context)
{
  this.context = context;
  Dictionary<string, List<Type>> outputSchema =
    new Dictionary<string, List<Type>>();
  outputSchema.Add(Constants.DEFAULT_STREAM_ID,
    new List<Type>() { typeof(SerializableTweet) });
  this.context.DeclareComponentSchema(new ComponentStreamSchema(
    null, outputSchema));
  // Specify your Twitter credentials
  TwitterCredentials.SetCredentials(
    ConfigurationManager.AppSettings["TwitterAccessToken"],
    ConfigurationManager.AppSettings["TwitterAccessTokenSecret"],
    ConfigurationManager.AppSettings["TwitterConsumerKey"],
    ConfigurationManager.AppSettings["TwitterConsumerSecret"]);
  // Setup a Twitter Stream
  var stream = Tweetinvi.Stream.CreateFilteredStream();
  stream.MatchingTweetReceived += (sender, args) => { NextTweet(args.Tweet); };
  // Setup your filter criteria
  stream.AddTrack("China");
  stream.StartStreamMatchingAnyConditionAsync();
}

A Figura 3 mostra a inicialização do contexto para esse spout usando um contexto passado durante a inicialização da topologia. O contexto é em seguida atualizado com a adição de uma definição de esquema. Crio um objeto Dictionary, ao qual adiciono um identificador para o tipo de fluxo (DEFAULT_STREAM) e uma lista dos tipos para todos os campos da tupla (nesse caso, apenas um SerializableTweet). Agora o contexto contém a definição de esquema que preciso seguir ao emitir tuplas nessa classe, assim como ao consumi-las no TwitterBolt.

O restante do trecho mostra a configuração do fluxo do Twitter. O pacote Tweetinvi fornece abstrações para APIs REST e de streaming do Twitter. Após codificar as credenciais adequadas, simplesmente instancio o tipo de fonte que desejo usar. No caso de fontes de streaming, posso escolher diversos tipos, como fluxos filtrados, amostrados ou de usuário. Eles fornecem interfaces simplificadas para fazer a filtragem de palavras-chave em todos os tweets, realizar a amostragem de tweets públicos aleatórios e acompanhar eventos associados a um usuário específico. Aqui, uso o fluxo filtrado, o que permite a seleção de tweets dentre todos os tweets públicos, verificando a existência de qualquer palavra-chave de um conjunto múltiplo.

Aqui executo a filtragem desejada de tweets no spout, pois as APIs do Tweetinvi facilitam isso. Também poderia fazer a filtragem no componente TwitterBolt, juntamente com outros eventuais cálculos ou agregações que quiser fazer para processar os tweets. A filtragem no spout permite reduzir o volume de dados que fluem pela topologia em um estágio inicial. No entanto, a vantagem do Storm é que ele permite lidar com grandes volumes em qualquer componente da topologia escalando horizontalmente. O Storm fornece dimensionamento quase linear com recursos adicionais, o que permite usar mais trabalhos para expansão sempre que ocorra um afunilamento. O HDInsight dá suporte a essa abordagem permitindo escolher o tamanho do cluster e os tipos de nós, ao configurá-lo e adicionar nós a ele mais tarde. Usando essa abordagem de escala horizontal, posso criar clusters do Storm que processam milhões de eventos por segundo. Sou cobrado pelo número de nós em execução no cluster. Portanto, preciso ter em mente o equilíbrio entre custo e escala.

A única outra parte a ser ressaltada na Figura 3 é o registro de um retorno de chamada a ser chamado pelo objeto de fluxo do Tweetinvi quando ele localiza um tweet que corresponde aos meus critérios. O método NextTweet é esse retorno de chamada, que simplesmente adiciona o tweet fornecido à fila privada mencionada anteriormente na classe TwitterSpout:

public void NextTweet(ITweet tweet)
{
  queue.Enqueue(new SerializableTweet(tweet));
}

Os bolts da topologia são codificados de forma semelhante. Eles são derivados da classe Microsoft.SCP.ISCPBolt e devem implementar o método Execute. Aqui, a tupla é passada como um tipo genérico de SCPTuple e primeiro deve ser convertida para o tipo correto. Em seguida, posso escrever código em C# para executar qualquer processamento detalhado que for necessário. Neste caso, simplesmente uso uma variável global para acumular a contagem do número de tuplas vistas pelo bolt e registrar a contagem e o texto dos tweets. Por fim, emito um novo tipo de tupla a ser consumida por bolts downstream. Eis o código:

public void Execute(SCPTuple tuple)
{
  var tweet = tuple.GetValue(0) as SerializableTweet;
  count++;
  Context.Logger.Info("ExecuteTweet: Count = {0}, Tweet = {1}", count, tweet.Text);
  this.context.Emit(new Values(count, tweet.Text));
}

No caso de um bolt, tenho que especificar esquemas de entrada e de saída ao configurá-lo. O formato é exatamente o mesmo usado na definição de esquema anterior para um spout. Simplesmente defino outra variável Dictionary chamada outputSchema e listo os tipos inteiro e cadeia de caracteres dos campos de saída, como mostrado na Figura 4.

Figura 4 Especificação dos esquemas de entrada e saída para o TwitterBolt

public TwitterBolt(Context context, Dictionary<string, Object> parms)
{
  this.context = context;
  Dictionary<string, List<Type>> inputSchema =
    new Dictionary<string, List<Type>>();
  inputSchema.Add(Constants.DEFAULT_STREAM_ID,
    new List<Type>() { typeof(SerializableTweet) });
  Dictionary<string, List<Type>> outputSchema =
    new Dictionary<string, List<Type>>();
  outputSchema.Add(Constants.DEFAULT_STREAM_ID,
    new List<Type>() { typeof(long), typeof(string) });
  this.context.DeclareComponentSchema(
    new ComponentStreamSchema(inputSchema,
    outputSchema));
}

Os outros bolts seguem o mesmo padrão, mas chamam APIs específicas para SQL Azure e SignalR. O elemento-chave final consiste em definir a topologia enumerando os componentes e suas conexões. Para isso, há outro método que deve ser implementado em todos os spouts e bolts: o método Get, que simplesmente instancia um objeto dessa classe com uma variável Context que é chamada pelo SCPContext durante a inicialização da tarefa do Storm. O SCP.Net instanciará um processo filho de C#, que iniciará a tarefa de spout ou bolt de C# usando o seguinte método representante:

return new TwitterSpout(context);

Com os spouts e bolts prontos, agora posso criar a topologia. Novamente, o SCP.Net fornece uma classe e funções auxiliares para fazer isso. Crio uma classe derivada de Microsoft.SCP.Topology.Topology-Descriptor e substituo o método GetTopologyBuilder. Nesse método, uso um objeto do tipo TopologyBuilder que fornece os métodos SetSpout e SetBolt. Esses métodos permitem especificar o nome e os esquemas de entrada e saída do componente. Eles também permitem especificar o representante Get a ser usado para inicializar o componente e, o que é mais importante, especificar o componente upstream a ser conectado ao componente atual. A Figura 5 mostra o código que define a topologia.

Figura 5 Como criar a topologia de análise do Twitter

namespace TwitterStream
{
  [Active(true)]
  class TwitterTopology : TopologyDescriptor
  {
    public ITopologyBuilder GetTopologyBuilder()
    {
      TopologyBuilder topologyBuilder = new TopologyBuilder(
        typeof(TwitterTopology).Name + DateTime.Now.ToString("-yyyyMMddHHmmss"));
      topologyBuilder.SetSpout(
        typeof(TwitterSpout).Name,
        TwitterSpout.Get,
        new Dictionary<string, List<string>>()
        {
          {Constants.DEFAULT_STREAM_ID, new List<string>(){"tweet"}}
        },
        1);
      topologyBuilder.SetBolt(
        typeof(TwitterBolt).Name,
        TwitterBolt.Get,
        new Dictionary<string, List<string>>()
        {
          {Constants.DEFAULT_STREAM_ID, new List<string>(){"count", "tweet"}}
        },
        1).shuffleGrouping(typeof(TwitterSpout).Name);
      topologyBuilder.SetBolt(
        typeof(SqlAzureBolt).Name,
        SqlAzureBolt.Get,
        new Dictionary<string, List<string>>(),
        1).shuffleGrouping(typeof(TwitterBolt).Name);
      topologyBuilder.SetBolt(
        typeof(SignalRBroadcastBolt).Name,
        SignalRBroadcastBolt.Get,
        new Dictionary<string, List<string>>(),
        1).shuffleGrouping(typeof(TwitterBolt).Name);
      return topologyBuilder;
    }
  }
}

O projeto completo de análise do Twitter pode ser compilado no Visual Studio usando o tipo de projeto do Storm. Esse projeto estabelece convenientemente os vários componentes necessários, de forma simples e familiar que pode ser exibida no Gerenciador de Soluções, como mostrado na Figura 6. Você pode adicionar componentes como bolts e spouts usando a opção Adicionar | Novo Item no menu de contexto de um projeto. A escolha dos tipos de item do Storm adiciona um novo arquivo e inclui o esboço para todos os métodos necessários. Usando o projeto do Storm do Visual Studio, posso adicionar referências a bibliotecas, como Tweetinvi, diretamente ou por meio do NuGet. Para enviar a topologia para execução no Azure, basta um clique no menu de contexto do Gerenciador de Soluções. Todos os componentes necessários são enviados ao cluster do HDInsight Storm de minha escolha, e a topologia é enviada.

Figura 6 Envio de uma topologia com o Gerenciador de Soluções

Após o envio, vejo a Exibição de Topologia na Figura 2, em que posso monitorar o estado da topologia. O Storm permite vários estados para a topologia, como ativado, desativado e eliminado, além de permitir a redistribuição das tarefas entre trabalhos com base em parâmetros de escalabilidade. Posso gerenciar todas essas transições de estado no Visual Studio, bem como observar o fluxo atual de tuplas. Para investigar componentes detalhadamente e depurar problemas, posso analisar detalhadamente componentes individuais, como SqlAzureBolt, que está mostrando uma condição de erro (o contorno e o marcador vermelhos na Exibição de Topologia). Você pode clicar duas vezes no bolt para mostrar estatísticas mais detalhadas sobre o fluxo de tuplas, bem como o resumo de erros do bolt. Você pode até clicar no link de Porta de Erro para acessar os logs completos de tarefas individuais sem ter que sair do Visual Studio.

O código e o projeto da topologia simples abordada neste artigo podem ser encontrados no GitHub, no repositório MicrosoftBigData. Procure a pasta HDInsight e o projeto de exemplo TwitterStream. Você encontrará artigos e exemplos adicionais em bit.ly/1MCfsqM.

Como passar para uma análise mais complexa

O exemplo de topologia do Storm que apresentei é simples. Há muitas maneiras de expandir a capacidade e a complexidade do processamento em tempo real no Storm.

Como já foi mencionado, o número de recursos atribuídos a um cluster do Storm no HDInsight pode ser escalado verticalmente, conforme necessário. Posso observar o desempenho do sistema com base nos dados fornecidos na exibição em tempo de execução do Visual Studio da topologia na Figura 2. Aqui posso ver o número de tuplas que estão sendo emitidas, o número de executores e as tarefas e latências. A Figura 7 mostra a exibição do Portal de Gerenciamento do Azure, que fornece mais detalhes sobre o número de nós, seu tipo e as contagens de núcleos que estão em uso agora. Com base nesses itens, posso optar por dimensionar o cluster e adicionar mais nós supervisores (de trabalho) ao cluster. Esse escalonamento vertical não requer uma reinicialização e ocorrerá em poucos minutos, quando eu disparar uma redistribuição na exibição de topologia no Visual Studio ou no Portal de Gerenciamento.

Figura 7 Exibição do Portal de Gerenciamento do Azure do cluster do Storm

A maioria dos aplicativos de análise opera em vários fluxos de Big Data não estruturados. Nesse caso, a topologia contém vários spouts e bolts que podem ler em mais de um spout. Isso pode ser facilmente expresso na configuração da topologia por meio da especificação de diversas entradas na invocação do método SetBolt. No entanto, a lógica de negócios para lidar com as várias fontes no mesmo bolt será mais complexa, pois as tuplas individuais chegam com diferentes IDs de fluxo. À medida que a complexidade do problema de negócios aumenta, é provável que fontes de dados relacionais ou estruturadas também sejam necessárias durante o processamento. Embora os spouts sejam ideais para fontes de dados semelhantes a filas, é mais provável que dados relacionais sejam fornecidos por um bolt. Novamente, com a implementação flexível de bolts e o uso de C# ou Java, é possível codificar facilmente o acesso a um banco de dados usando APIs estabelecidas ou linguagens de consulta. A complexidade aqui decorre do fato de que essas chamadas serão feitas remotamente a partir de contêineres do Storm em um cluster para o servidor de banco de dados. O SQL Azure e o HDInsight funcionam na mesma malha do Azure e interagem facilmente, mas existem outras opções para serviços baseados em nuvem que também podem ser usadas.

O tempo de execução do Storm permite definir ou ajustar muitos comportamentos refinados do sistema. Muitas dessas configurações aparecem como parâmetros de configuração que podem ser aplicados no nível de topologia ou de tarefa. Elas podem ser acessadas na classe Microsoft.SCP.Topology.StormConfig e usadas para ajustar a carga de trabalho geral do Storm. Alguns exemplos são: configurações para o número máximo de tuplas pendentes por spout, tuplas de marca e estratégia de suspensão de spouts. Outras alterações na topologia podem ser feitas no compilador de topologias. Na topologia de exemplo, o streaming entre todos os componentes é definido como "agrupamento aleatório". Para um determinado componente, o sistema de execução do Storm pode e vai criar muitas tarefas individuais. Essas tarefas são threads de trabalho independentes que podem ser executados em paralelo entre núcleos ou contêineres para espalhar a carga de trabalho do bolt entre vários recursos. Posso controlar a forma como o trabalho é passado de um bolt para o próximo. Escolhendo o agrupamento aleatório, indico que qualquer tupla pode ir para qualquer processo de trabalho no próximo bolt. Também posso escolher outras opções, como o "agrupamento por campos", o que faz com que as tuplas sejam enviadas ao mesmo trabalho com base no valor de um campo específico na tupla. Essa opção pode ser usada para controlar o fluxo de dados para operações que têm um estado, como uma contagem contínua para uma palavra específica no fluxo de tweets.

Por fim, um sistema de análise em tempo real pode fazer parte de um pipeline maior de análise em uma organização. Por exemplo, é provável que um sistema de análise de blogs tenha uma grande parte orientada a lotes que processe os logs de um serviço Web diariamente. Isso produziria resumos de tráfego de sites e forneceria dados ligeiramente agregados, adequados para a descoberta de padrões por um cientista de dados. Com base nessa análise, a equipe pode decidir criar gatilhos em tempo real para certos comportamentos, como a detecção de falhas do sistema ou o uso mal-intencionado. Essa última parte exigiria a análise em tempo real de fluxos de log ou de telemetria, mas provavelmente dependeria de dados de referência atualizados diariamente pelo sistema em lotes. Esses pipelines maiores exigem uma ferramenta de gerenciamento de fluxo de trabalho que permita a sincronização de tarefas entre diversas tecnologias e modelos de computação. O ADF (Azure Data Factory) fornece um sistema de gerenciamento de fluxo de trabalho que dá suporte nativo à análise e aos serviços de armazenamento do Azure e permite a coordenação entre as tarefas com base na disponibilidade de dados de entrada. O ADF dá suporte ao HDInsight e à Análise Azure Data Lake, bem como à movimentação de dados entre o Armazenamento do Azure, o Armazenamento do Azure Data Lake, o Banco de Dados SQL do Azure e fontes de dados locais.

Outras tecnologias de streaming

Neste artigo, apresentei as noções básicas da análise de streaming em tempo real usando o Storm no HDInsight. Naturalmente, o Storm também pode ser configurado em seu próprio cluster de computadores em seu próprio datacenter ou laboratório. A distribuição do Storm pode ser obtida por meio da Hortonworks, da Cloudera ou diretamente da Apache. Nesses casos, a instalação e a configuração são consideravelmente mais demoradas, mas os conceitos e os artefatos de código são os mesmos.

O Spark (spark.apache.org) é outro projeto da Apache que pode ser usado para análise em tempo real e conquistou grande popularidade. Ele dá suporte ao processamento geral de Big Data, mas seu suporte para o processamento em memória e uma biblioteca de funções de streaming o tornam uma escolha interessante para o processamento em tempo real de alto desempenho. O HDInsight oferece tipos de cluster do Spark, em que você pode experimentar essa tecnologia. O serviço inclui blocos de anotações para Zeppelin e Jupyter, interfaces que permitem criar consultas nessas linguagens e ver resultados interativos. Eles são ideais para a exploração de dados e o desenvolvimento de consultas em relação a conjuntos de Big Data.

O interesse por análise de streaming em tempo real está aumentando à medida que as organizações lidam com cenários cada vez mais complexos para a análise de Big Data. Ao mesmo tempo, as tecnologias nesse setor continuam a crescer e amadurecer, proporcionando novas oportunidades para a obtenção de insights a partir de Big Data. Confira estas páginas para ler artigos futuros sobre o uso de tecnologias como Spark e Análise do Azure Data Lake.

Omid Afnané gerente de programas principal da equipe de Big Data do Azure que trabalha em implementações de sistemas de computação distribuída e cadeias de ferramentas de desenvolvedor relacionadas. Ele mora e trabalha na China. Entre em contato com ele pelo email omafnan@microsoft.com.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Asad Khan e Ravi Tandon
Ravi Tandon (Microsoft), Asad Khan (Microsoft)

Asad Khan é Gerente de Programas Principal no grupo de Big Data da Microsoft e se concentra em experiências habilitadas pelo Hadoop na nuvem por meio do Serviço Azure HDInsight. No momento, ele se concentra no Spark e na análise em tempo real por meio do Apache Storm. Nos últimos anos, ele tem trabalhado nas tecnologias da Microsoft de acesso a dados da próxima geração, incluindo Hadoop, OData e BI sobre big data. Asad é mestre pela Stanford University

Ravi Tandon é Engenheiro de Software Sênior da equipe do Microsoft Azure HDInsight. Ele trabalha nos produtos Apache Storm e Apache Kafka no Microsoft Azure HDInsight.