Boas práticas de IoT em escala de produção: implementação no Google Cloud (Parte 2/3)

Este post dá sequência à Parte 1, em que mostramos como conectar com segurança uma frota de dispositivos IoT em escala de produção, transmitindo telemetria ao seu ambiente Google Cloud via IoT Core e Pub/Sub.

Parabéns! Você registrou vários dispositivos IoT — e agora?

O próximo passo é desenhar um sistema que dê conta de armazenamento em larga escala, analytics e visualização/dashboarding desses dados.

Para isso, é preciso planejar com antecedência uma arquitetura de fluxo de dados que sustente operações desse porte. Este artigo traz um passo a passo prático para fazer exatamente isso.

Visão geral

Vamos dividir o conteúdo nas seguintes seções:

1. Carregamento em lote para data sinks
2. Armazenamento e análise dos dados
3. Visualização dos dados armazenados

Diferente da Parte 1, tudo o que veremos aqui pode ser feito direto pelo console web do GCP. Basta ter conhecimento básico de SQL.

Vamos abordar os seguintes serviços do Google Cloud, todos totalmente gerenciados e com escalonamento automático:

• Pub/Sub — fila de mensagens serverless
• Dataflow — engine de processamento de dados em stream e em lote
• BigQuery — data warehouse serverless
• Data Studio — serviço de visualização de dados e criação de dashboards

Carregamento em lote para data sinks

Confira se as mensagens estão chegando

Se você conectou os dispositivos ao registro de IoT e começou a transmitir dados ao IoT Core, deve ver um fluxo constante de mensagens chegando no dashboard principal de IoT do GCP:

Três dispositivos conectados transmitindo dados de temperatura a cada cinco segundos

Como vimos na Parte 1, essas mensagens também estão chegando ao seu tópico Pub/Sub 'temperature':

Mensagens Pub/Sub chegando ao tópico 'temperature'

Streaming para o BigQuery

Beleza — as mensagens estão chegando ao Google Cloud. Agora precisamos levar as mensagens do Pub/Sub para um data warehouse, onde os dados ficarão armazenados de forma econômica no longo prazo e ficarão prontos para analytics em escala. Aí entra o BigQuery.

O BigQuery, data warehouse totalmente gerenciado, serverless e com escalonamento automático do Google Cloud, cobra compute e armazenamento em modelo on-demand, o que faz dele um excelente data sink para guardar e analisar nossos dados de IoT.

Mas como transmitir as mensagens do Pub/Sub para o BigQuery? Com o Dataflow.

O Dataflow, versão totalmente gerenciada e com escalonamento automático do Apache Beam no Google Cloud, foi feito para transportar dados de um serviço a outro. Ele permite filtrar e transformar dados (de forma opcional) e também fazer carga em lote de maneira otimizada em serviços com limite de operações de carga, como bancos de dados e soluções de data warehousing.

O Dataflow já vem com vários templates padrão criados pelo Google Cloud, inclusive um template Pub/Sub para BigQuery — ou seja, você não precisa escrever nenhuma linha de código para conectar a ingestão ao armazenamento/analytics.

Como Pub/Sub, Dataflow e BigQuery são todos totalmente gerenciados e com escalonamento automático — e (com exceção do Dataflow) também serverless —, dá para construir um sistema de gerenciamento de dados IoT de ponta a ponta que escala de boa do ambiente de testes a operações na casa dos petabytes, praticamente sem precisar gerenciar infraestrutura conforme o volume cresce.

Vamos ver todos esses serviços conectados na prática!

Configuração da subscription do Pub/Sub

Antes de começar a mover os dados do Pub/Sub para o Dataflow, vamos criar uma subscription do Pub/Sub vinculada ao tópico.

Por quê? As mensagens que chegam a um tópico Pub/Sub são enviadas imediatamente aos assinantes (via estratégia Push) e, em seguida, removidas do tópico. Por outro lado, os assinantes podem reter as mensagens até que algum processo as solicite (via estratégia Pull). Dá para conectar o Dataflow direto a um tópico em vez de a uma subscription, mas, se o job do Dataflow ficar fora do ar, as mensagens que chegarem ao tópico durante a indisponibilidade vão se perder.

Já ao conectar o Dataflow a uma subscription Pub/Sub vinculada ao tópico, você evita perder mensagens em caso de queda. Se o job do Dataflow for interrompido temporariamente, todas as mensagens IoT ainda não processadas continuam na subscription Pub/Sub, esperando o job voltar a coletá-las.

Uma subscription Pub/Sub vinculada a um tópico Pub/Sub cria uma arquitetura de dados resiliente a falhas nos serviços de ingestão a jusante.

Para criar uma subscription no Pub/Sub:

1. Acesse Subscriptions
2. Clique em "Create Subscription" e dê o nome "temperature_sub"
3. Vincule-a ao tópico Pub/Sub "temperature"
4. Mantenha as demais opções nos valores padrão

Criação da subscription Pub/Sub 'temperature_sub' vinculada ao tópico 'temperature'

Depois de criar, clique na subscription e em " Pull" para ver as mensagens começando a chegar:

Exemplos de mensagens chegando à subscription Pub/Sub

Armazenamento e análise dos dados

Agora que temos uma subscription Pub/Sub recebendo mensagens, estamos quase prontos para criar um job do Dataflow que leve essas mensagens até o BigQuery. Antes disso, precisamos criar uma tabela no BigQuery para receber os dados vindos do Dataflow.

Configuração da tabela no BigQuery

Acesse o BigQuery, clique em "Create Dataset" e dê o nome 'sensordata' ao dataset, mantendo as demais opções nos valores padrão:

Tela de criação de Dataset no BigQuery

Depois de criar o dataset, selecione-o, clique em " Create table" e dê o nome "temperature" à nova tabela. Configure o schema, o particionamento e as opções de clustering conforme as capturas de tela abaixo, já que essas opções dão suporte a padrões comuns de consulta:

Schema da nova tabela 'temperature' no BigQueryOpções de particionamento e clustering da tabela 'temperature'

Se tudo estiver certo, sua tabela nova e vazia ficará assim:

Uma tabela 'temperature' vazia dentro do dataset 'sensordata' no BigQuery

Depois de inserir dados na tabela, vamos mostrar um padrão comum de consulta em IoT: rodar analytics sobre dados de uma janela de tempo específica (por exemplo, uma janela de uma hora no dia atual) e para um dispositivo específico.

O design de tabela mostrado acima é ideal para esse tipo de consulta porque:

• O particionamento pelo campo de timestamp UTC faz com que consultas filtradas por data não varram partições DateTime de dias que não interessam
• Dentro de cada partição, o clustering (ordenação) por deviceId e pelo timestamp epoch agiliza a recuperação dos dados de um dispositivo e janela de tempo específicos dentro daquela partição.

Para escrever essas consultas, precisamos ter dados na tabela. Hora de colocar o job do Dataflow para rodar!

Configuração do Dataflow

No momento, temos mensagens em uma subscription Pub/Sub esperando para serem movidas e uma tabela no BigQuery pronta para recebê-las. Falta a "cola" de ETL que liga os dois lados. Como Pub/Sub e BigQuery são totalmente gerenciados, com escalonamento automático e serverless, o ideal é que a ferramenta de ETL também tenha essas características.

O Dataflow atende (em grande parte) a esses requisitos. O marketing do Dataflow afirma que ele tem as três características, mas, na prática, ele não é totalmente serverless. É preciso definir os tipos e tamanhos de instância que serão usados, os limites mínimo e máximo de instâncias do escalonamento automático e quanto espaço temporário em disco cada instância vai precisar. Você nunca gerencia essas instâncias nem decide quando elas escalam, mas precisa fornecer essas especificações. Isso é diferente do Pub/Sub e do BigQuery, que escalam automaticamente sem nenhuma configuração de infraestrutura.

Mesmo não sendo totalmente serverless, o Dataflow é a escolha certa para o nosso ETL Pub/Sub para BigQuery. Também é fácil de usar, ainda mais porque o GCP oferece vários templates padrão de jobs do Dataflow, inclusive um que dá suporte ao fluxo Pub/Sub para BigQuery. Tirando o ajuste do limite máximo de instâncias do escalonamento automático conforme o throughput dos dados de IoT cresce com o tempo, em teoria você nunca vai precisar se preocupar em gerenciar a infraestrutura por trás do Dataflow.

Com o básico entendido, vamos implementar um job do Dataflow. Acesse o Dataflow, clique em " Create Job from Template" e siga os passos:

• Dê o nome 'pubsub-temp-to-bq' ao job
• Use o template padrão de streaming 'Pub/Sub Subscription to BigQuery'
• Informe o nome completo da subscription Pub/Sub
• Informe o ID completo da tabela do BigQuery
• Informe um bucket do Cloud Storage onde os dados temporários poderão ficar como parte do processo de carregamento em lote do Dataflow para o BigQuery
• Mantenha as demais opções nos valores padrão. Normalmente, você abriria as Advanced Options para definir parâmetros como tipo e tamanho de máquina, limites mínimo/máximo de máquinas para o escalonamento automático e tamanho do disco por máquina. Para fins de teste, dá para deixar tudo nos valores padrão.

Sua tela de criação do job do Dataflow deve ficar parecida com esta:

Depois de clicar em " Create" e esperar alguns minutos para a infraestrutura subir e começar a rodar, você vai ver os dados fluindo da subscription Pub/Sub direto para a tabela de destino no BigQuery.

O script Python de streaming de temperatura disponibilizado na Parte 1 envia um registro por segundo. Assim, no Directed Acyclic Graph (DAG) do Dataflow mostrado abaixo, você verá x elementos sendo transmitidos por segundo, em que x é o número de dispositivos que você está testando. No meu caso, são três dispositivos transmitindo:

Mensagens sendo transmitidas com sucesso do Pub/Sub para o BigQuery via job do Dataflow

Quando o job do Dataflow estiver ativo e transmitindo os dados da subscription Pub/Sub para o BigQuery, você pode rodar uma consulta no BigQuery no formato abaixo e ver os dados em tempo real chegando à tabela:

SELECT *
FROM `iottempstreaming.sensordata.temperature`
WHERE DATE(timestamp_utc) = "2020-12-18"
ORDER BY timestamp_epoch DESC
LIMIT 10

Dá para confirmar que o filtro de partição está funcionando: o volume total de dados varridos aumenta quando tiramos o WHERE que filtra por dia.

No meu dataset de exemplo, são varridos 1,1 MB de dados filtrados (como visto acima) e 1,7 MB de dados sem filtro (mostrado abaixo):

SELECT *
FROM `iottempstreaming.sensordata.temperature`
ORDER BY timestamp_epoch DESC
LIMIT 10

Vamos ver os valores médio, mínimo e máximo de temperatura de cada sensor na última hora:

SELECT
  device_id,
  ROUND(AVG(temp_f), 1) AS temp_f_avg,
  MIN(temp_f) AS temp_f_min,
  MAX(temp_f) AS temp_f_max
FROM `iottempstreaming.sensordata.temperature`
WHERE timestamp_utc > DATETIME_ADD(CURRENT_DATETIME(), INTERVAL -60 MINUTE)
GROUP BY device_id

Várias estatísticas para cada dispositivo de streaming de temperatura

Parabéns! Você acabou de montar um workflow de dados totalmente gerenciado de ponta a ponta, da ingestão ao backend de analytics. Antes de fechar este passo a passo, vamos dar uma olhada rápida em como visualizar esses dados no Data Studio.

Visualização dos dados armazenados

Comece rodando no BigQuery uma consulta parecida com a abaixo, que retorna todas as linhas de dados de um dia específico:

SELECT *
FROM `iottempstreaming.sensordata.temperature`
WHERE DATE(timestamp_utc) = "2020-12-18"
ORDER BY timestamp_epoch DESC

À direita de " Query Results", clique em " Explore Data" e depois em " Explore with Data Studio":

Isso vai carregar uma tabela com o resumo dos dados da consulta. Mas, por padrão, ela mostra um resumo pouco interessante: o total de registros transmitidos por segundo.

Vamos ajustar alguns valores na seção Data, à direita, para deixar tudo mais interessante:

• Selecione "Line Chart" como tipo de visualização em vez de "Table"
• Tire "Record Count" da métrica visualizada e troque por "temp_f". Não esqueça de mudar a métrica padrão "SUM" para "AVG".
• Adicione "device_id" como dimensão de breakout

Suas escolhas devem gerar configurações de layout de dashboard parecidas com estas:

O gráfico gerado vai mostrar os valores de temperatura de cada dispositivo ao longo do tempo, mas pode não estar bem ajustado, já que o valor mínimo padrão do eixo Y é zero. Para corrigir, clique na aba "Style", role até a opção "Left Y-Axis" e ajuste para valores razoáveis:

Você também pode aumentar a quantidade de pontos exibidos no gráfico:

Com esses ajustes, você terá um gráfico bonito e interativo, em que dá para acompanhar a variação da temperatura dos dispositivos ao longo do tempo:

A seguir: Machine Learning

Fique de olho na Parte 3, em que vamos construir um modelo funcional de machine learning sobre este dataset do BigQuery e usá-lo para gerar previsões em tempo real.