análise e visualização de dados
TRANSCRIPT
Universidade Federal do Rio Grande do NorteInstituto Metrópole Digital
SmartMetropolis – Plataforma e Aplicações para Cidades Inteligentes
WP6 – Análise e Visualização de Dados
Relatório de Atividades do Segundo Trimestre do WP6 -Análise e Visualização de Dados
Natal-RN, Brasil[Julho de 2016]
Equipe TécnicaProf. Dr. Daniel Sabino Amorim de Araújo (Coordenador) – [IMD/UFRN]
Prof. Dr. Allan de Medeiros Martins - DEE/UFRNProf. Dr. Adrião Duarte Dória Neto - DCA/UFRNProf. Dr. Nélio Alessandro Azevedo Cacho - DIMAp/UFRN
DiscentesAdelson Dias de Araújo Júnior - Iniciação Científica (Engenharia de Computação)Camila Nascimento dos Santos - Mestrado (Pós-graduação em Eng. Elétrica e de Computação)Felipe de Souza Pinheiro - Mestrado (Pós-graduação em Eng. Mecatrônica)Jhoseph Kelvin Lopes de Jesus - Iniciação Científica (Tecnologia da Informação)Leandro Albino Ferreira - Iniciação Científica (Engenharia de Computação)Maximiliano Araújo da Silva Lopes - Doutorado (Pós-graduação em Eng. Elétrica e de Computação)Mickael Raninson Carneiro Figueredo - Iniciação Científica (Ciência e Tecnologia)
Sumário1 Introdução 6
2 Metodologia 6
3 Andamento das Atividades e Resultados Obtidos 73.1 Mineração de Textos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Aplicação de Limpeza de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Identificação e Classificação de Ocorrências Policiais . . . . . . . . . . . . . . . 10
3.2 Técnicas de Visualização e Exploração do FIWARE . . . . . . . . . . . . . . . . . . . . 123.2.1 Aplicação de Lavagem de Dinheiro . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Componentes do FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Complex Event Processing (CEP) GE . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3.2 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.3.3 Exemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3.4 Problemas Encontrados . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3.5 Próximos passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4 Big Data Analysis (Cosmos) GE . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.4.2 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.4.3 Exemplo de uso e Problemas Encontrados . . . . . . . . . . . . . . . 253.2.4.4 Próximos passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Redução de Dimensionalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.1 Abordagem baseada em Information Theoretic Learning . . . . . . . . . . . . . 273.3.2 Abordagens de Seleção de Atributos para problemas de classificação em Big Data 32
3.3.2.1 Abordagens de combinação propostas . . . . . . . . . . . . . . . . . . 333.3.2.2 Materiais e Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.2.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Processamento de Sinais e Análise de Séries Temporais . . . . . . . . . . . . . . . . . . 363.4.1 Identificação de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.2 Determinando os coeficientes . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.3 Determinando a ordem do sistema . . . . . . . . . . . . . . . . . . . . . . . . . 373.4.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.4.5 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5 Análise geoespacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.5.1 A plataforma ROTA-Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 413.5.2 Consultas em banco de dados geográficos e resultados . . . . . . . . . . . . . . 43
4 Considerações Finais 47
Lista de Figuras1 Arquivo Antes do Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Arquivos Após a Utilização da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 93 Tamanho do Arquivo antes do Processamento . . . . . . . . . . . . . . . . . . . . . . . 94 Tamanho do Arquivo após o Processamento . . . . . . . . . . . . . . . . . . . . . . . . 95 Cálculo da Probabilidade de Línguas usando o NLTK . . . . . . . . . . . . . . . . . . . 106 Configuração do Weka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Número de Instâncias de Saída . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Exemplos de 2-Grams Gerados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Tela Inicial da Aplicação de Lavagem de Dinheiro . . . . . . . . . . . . . . . . . . . . . 1310 Tela de Relaçãod e Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311 Arquivo Contendo Relações do Grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412 Ilustração de uma rede EPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513 Interface Web - CEP AuthoringTool para definição do projeto . . . . . . . . . . . . . . . 1814 Ilustração do paradigma MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315 Representação de amostras de duas variáveis x e y . . . . . . . . . . . . . . . . . . . . . 2816 (a) A reta x = y, primeiro componente principal (b) Os dados originais projetados no
eixo do primeiro componente principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 2817 (a)Representação original dos dados nos eixos x e y (b) Os eixos dos componentes prin-
cipais x1 y1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2818 Fusão dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3319 Fusão dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3420 Captura de tela do ROTA-Dashboard na aplicação Mapas . . . . . . . . . . . . . . . . . 4221 Captura de tela do ROTA-Dashboard na aplicação Gráficos . . . . . . . . . . . . . . . . 4322 As 5 AISPs com menores distâncias médias entre as ocorrências, em metros. . . . . . . . 4423 AISPs com maiores porcentagens de ruas com ocorrências. . . . . . . . . . . . . . . . . 4424 Cobertura em porcentagem (à esquerda) e efeito visual da cobertura(à direita). . . . . . . 4425 Parcela em porcentagem de ocorrências na AISP do total (à esquerda) e ( Métrica de
ocorrências por km2 na AISP (à direita). . . . . . . . . . . . . . . . . . . . . . . . . . . 4526 Ocorrências incidentes e viaturas que por ali passaram, por rua e bairro. . . . . . . . . . 4527 Comprimento e velocidade das subtrajetórias das viaturas. A coluna intervalo se refere
ao tempo de atividade daquela subtrajetória. . . . . . . . . . . . . . . . . . . . . . . . . 4628 Maiores valores de dissimilaridade entre trajetórias. . . . . . . . . . . . . . . . . . . . . 47
Lista de Tabelas1 Tabela de Palavras lemmatizadas e Stemetizadas . . . . . . . . . . . . . . . . . . . . . . 82 Operações da API para receber eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Operações da API para enviar eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Operações da API para gerenciar as definições . . . . . . . . . . . . . . . . . . . . . . . 175 Descrição das Bases de Dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6
1 Introdução
O ‘WP6 - Análise e Visualização de Dados’, doravante denominado apenas por WP6, é parte integrantedo projeto SmartMetropolis que tem como objetivo geral desenvolver soluções de tecnologia da informa-ção que ajudem a resolver problemas das cidades e regiões metropolitanas atuais. Ou seja, o SmartMe-tropolis trata do desenvolvimento de soluções inteligentes para resolver problemas, principalmente, empontos críticos de regiões urbanas e em crescimento, como segurança pública, saúde, educação, trânsitoe qualidade de vida.
O WP6, por sua vez, é um dos seis grupos de trabalho que compõem o SmartMetropolis. Ele é res-ponsável por realizar análises profundas nas massas de dados geradas por aplicações desenvolvidas pelosdemais grupos de trabalho. Essa análise pode fazer parte do foco principal da aplicação ou ser secundá-ria e tratar dos dados gerados por ela. Em ambos os casos, a análise tem como objetivo principal extrairinformações úteis que estejam “embutidas” nos dados para ajudar na tomada de decisão.
As análises de dados são realizadas, principalmente, por técnicas das áreas de Aprendizado de Má-quina e Estatística. No entanto, o grupo não fica restrito somente a essas áreas e também utilizam dentrodo processo de análise a Visão Computacional, Teoria da Informação, Processamento de LinguagemNatural, entre outras.
O restante deste relatório é composto pela Seção 2, que detalha a forma que o grupo vem trabalhando;a Seção 3, que expõe as atividades realizadas até o momento pelos membros do WP e, por fim, a Seção4, que traz as principais condireções sobre o primeiro trimestre de trabalho do WP6.
2 Metodologia
Com o objetivo de organizar as atividades do WP6, decidimos por dividir as principais áreas de estudoentre os integrantes do grupo. Para isso, foram coletadas as áreas de atuação que teriam prioridade paraanálise de dados e atribuímos a cada membro discente do WP6. Dessa forma, cada integrante deve setornar especialista em uma dessa áreas e conseguir canalizar as demandas para si, tornando o processo dedesenvolvimento mais rápido. Os docentes, de uma maneira geral, estão envolvidos em todas as frentesde trabalho do WP.
A realização de reuniões periódicas do grupo e apresentação dos trabalhos faz com que, apesar deespecialistas em uma das áreas, todos os membros tenham conhecimento sobre as atividades dos ou-tros. Dessa forma, em casos de atividades que exijam mais de uma especialidade, os integrantes podemtrabalhar em conjunto sem maiores problemas.
Diante disso, o grupo adotou as seguintes linhas de trabalho:
• Mineração de textos (Mickael Figueiredo)
• Técnicas de visualização e Exploração do FIWARE (Leandro Ferreira)
• Processamento de sinais e Análise de Séries Temporais (Felipe Pinheiro / Remi)
• Processamento de imagens (Camila Santos)
• Redução de dimensionalidade (Maximiliano Lopes / Jhoseph Jesus)
• Análise geoespacial (Adelson Dias)
7
3 Andamento das Atividades e Resultados Obtidos
3.1 Mineração de Textos
No segundo semestre do ano houveram uma série de metas estabelecidas na área da mineração de textos.Os principais deles: a criação de uma aplicação voltada para limpeza de arquivos utilizados no proces-samento de linguagem natural, um novo treinamento com o classificador de crimes criado no primeirosemestre do ano e criação de uma aplicação para o Laborátio Contra Lavagem de Dinheiro da PolíciaCivíl. Tais trabalhos são descritos nos seguites subtóticos das atividades relacionadas à mineração detexto.
3.1.1 Aplicação de Limpeza de Arquivos
É importante ressaltar que a limpeza de dados é um passo fundamental quando se trabalha com algo-ritmos de aprendizado de máquina. Muitos deles são extremamente sensíveis a variações atípicas nosdados e escala desses valores, tornando o pré-processamento uma etapa fundamental para atingir níveisde acurácia elevados. Diante disso, nossa aplicação é voltada para tratar textos extraídos de redes sociaise possui uma série de processos para realizar a limpeza dos dados:
• Retirada de caracteres atípicos.
• Retirada de URLS.
• Retirada de palavras que não pertecem a língua definida pelo o usuário.
• Stemmetização do arquivo.
• Retirada de Stop Words.
• Criação do arquivo Lematizado.
Na primeira etapa do processo, usa-se um código para a identificação de URLs e caracteres estranhos,tais como emoticons. Após essa identificação, os mesmos são retirados. Em aplicações de análise detexto que envolvem redes sociais é de extrema importância a retirada desses tipos de dados, pois, além derepresentam um consumo de memória para o processamento, esses tipos de dados geram uma quantidadegrande de ruído que acaba por prejudicando a criação de ferramentas relacionadas a mineração de texto,como é o caso do nosso classificador de crimes, criado no primeiro semestre do ano.
Após essa limpeza inicial, incia-se o processo de uso de bibliotecas já existentes (e abertas) para ques-tões que demandam mais robustez no contexto de processamento de linguagem natural. Primeiramente,a retirada das chamadas Stop Words [10], que são palavras que não possuem valor semântico algum parao processo de analise to texto. São consideradas dessa categoria na língua portuguesa artigos definidose indefinidos com "a","o", "uns", "uma"ou preposições, tais como "para","por"e "pelo", por exemplo.Percebe-se, que em termos computacionais palavras como essas não irão adicionar semântica muito im-portante para que sejam consideradas na análise de aprendizado de máquinas.
Posteriormente, inica-se o que é considerado a etapa mais importante feita pelo aplicativo de limpezados dados: A Stemmetização ou Lemmatização. Esses processos tem como [10] principal objetivo re-duzir uma palavra ou frase para formas não flexionadas ou conjugadas de maneira deliberada para umabase e forma comum. Para um exemplificação, podemos ver na tabela 3.2.3.2 os efeitos desses doisprocessamentos em algumas palavras da língua portuguesa.
8
Palavra Stemmer LemmaCarros Carr CarroMataram Mat MatarViveu Viv Viver
Tabela 1: Tabela de Palavras lemmatizadas e Stemetizadas
A nossa aplicação é capaz de realizar os dois tipos de redução textual através da utilização de umabiblioteca Python 1 2 que auxilia muito no processo. No primeiro trimestre do ano, todo esse processoera feito manualmente com a linguagem Java, o que demandava muito mais tempo e processamento.Com essa nova aplicação, o serviço de limpeza e estruturação de um arquivo para o processamento emlinguagem natural está sendo feito totalmente em Python, o que reduziu o tempo gasto na limpeza emarquivos grandes em aproximadamente 90%. Os efeitos do aplicativo de limpeza de arquivo podem servisualizados nas Figuras 1 e 2.
Figura 1: Arquivo Antes do Processamento
9
Figura 2: Arquivos Após a Utilização da Aplicação
Também podemos perceber impactos da nova implementação no tamanho dos arquivos ( figuras 3 e 4 ).Isso é de grande importância quando se trata de processamento de linguagem natural, pois os algoritmosutilizados no treinamento exigem grande capacidade de processamento e memória das máquinas nasquais eles rodam. Desta forma, arquivos menores levam a economizar recursos computacionais.
Figura 3: Tamanho do Arquivo antes do Processamento
Figura 4: Tamanho do Arquivo após o Processamento
Por último, podemos ainda citar a capacidade da ferramenta de detectar a língua presente em umafrase ou palavra. O algoritmo utilizado é baseado em probabilidade e na utilização do NTLK [4], paraque seja possível essa classificação. Primeiramente, precisamos de uma lista de Stop Words de diversaslínguas diferentes. Desta forma podemos eliminar todas as palavras de determinada frase que não estãopresentes na base de dados do NLTK. Tendo um vetor contendo esses dados, podemos então calculara probabilidade de uma palavra de uma determinada língua através de um função documentada pelabiblioteca Python.
10
Figura 5: Cálculo da Probabilidade de Línguas usando o NLTK
É importante destacar que a aplicação está funcional, otimizada e disponível para utilização de outraspessoas.
3.1.2 Identificação e Classificação de Ocorrências Policiais
Durante o primeiro trimestre do ano, como já descrito no primeiro relatório, foi criado um classificadorde crimes utilizando ocorrências oriundas da Polícia Militar. A ideia central da análise é identificar eclassificar textos em redes sociais como ocorrências policiais baseado nos registros de ocorrências cedi-dos pela Polícia Militar. A tarefa de identificação de possíveis crimes em redes sociais possui uma sériede desafios. Muitos deles estão atrelados ao processamento da linguagem natural, motivo pelo qual foidesenvolvida uma aplicação para realizar o tratamento de textos apresentada na seção anterior.
Sendo assim, usamos uma base de dados contendo mais 500.000 ocorrências registradas pelo CIOSPpara construir treinar um algoritmo de aprendizado de máquina com o intuito de gerar um modelo capazde identificar postagens em redes sociais como possíveis crimes descritos pelas categorias usadas pelapolícia. Para tanto, foram usadas técnicas de processamento de linguagem natural, redução de dimensio-nalidade e algoritmos de classificação para gerar tal modelo.
Em seus primeiros experimentos, os resultados foram promissores, com índices de classificação supe-riores a 70%. Considerando a quantidade de ruídos presentes nos dados, a quantidade muito grande decategorias de ocorrências e a semelhança entre muitas das categorias, esse resultado pode ser conside-rado muito bom. A publicação de artigo com essa análise no IEEE International Smart Cities Conference(ISC2) corrobora com isso.
No segundo semestre, iniciou-se o aprimoramento da aplicação com a utilização de técnicas mais ro-bustas para tratar o texto. Na versão inicial, a frequência com que determinadas palavras ocorriam eram ofator crucial para determinar a categoria de um texto. No entanto, em muitas situações a presença simul-tânea de duas ou mais palavras possuem significado semântico mais elevado. Nesse sentido, buscou-se
11
utilizar o divisão do texto em ’N-Grams’, que são sequências contíguas de ’N ’ palavras. Essa estratégiaé bastante utilizada em mecanismos de busca para predição de palavras seguintes.
Para os testes iniciais, estamos trabalhando com versões de 2-grams e 3-grams. O software WEKA[13] possui implementações livres desse tipo de estratégia. A seguir, na Figura 6 podemos ver a interfacedo software com uma série de opções para processamento de texto, incluindo o tratamento de palavrascontíguas. Nesse contexto, os campos que merecem atenção são IDFT Transform e TFT Transform, quesão responsáveis por dar pesos aos pares de palavras, considerando o tamanho do texto, OutPutWords-Count, que nos mostra os pares de palavras mais recorrentes, e por fim o Tokenizer, que é onde se defineo tipo de N-Grams utilizado.
Figura 6: Configuração do Weka
As Figuras 7 e 8 mostram dados referentes a saída do software. Nos testes iniciais com computadorpessoal (um arquivo com tamanho de 200 MB, computador com processador Intel i3 e sistema operacio-nal Linux) o processamento inicial para gerar uma base de dados a partir do processamento do texto levouduas horas. Podemos notar que a utilização de pares de palavras traz informações mais significativas paraencontrar relações entre a presença delas e uma possível ocorrência policial. Além disso, o número decaracterísticas usadas pelo algoritmos de aprendizado de máquina se torna menor, o que leva a melhoresdesempenhos na execução. Por exemplo, com o uso dessa estratégia, o número de características usadaspara gerar um modelo classificador foi 8 vezes menor (10755 instâncias) que a versão anterior anterior,que considerava as palavras individualmente.
12
Figura 7: Número de Instâncias de Saída
Figura 8: Exemplos de 2-Grams Gerados
Essa fase da aplicação ainda está em execução e deve gerar resultados em breve.
3.2 Técnicas de Visualização e Exploração do FIWARE
3.2.1 Aplicação de Lavagem de Dinheiro
No final do segundo trimestre uma nova demanda foi adicionada a responsabilidade do WP6. Foi so-licitada a criação de um dashboard de visualização para a polícia civil que substituiria o i2 Analyst’sNotebook. Esse software tem como função relacionar dados oriundos de diferentes fontes e cruza-laspara obter diversas informações sobre um ou vários indivíduos. O polícia civil tem intenção de substituirtal software devido ao seu alto preço e pelo hardware que o mesmo exige para um bom funcionamento.A implantação de uma nova aplicação, além de reduzir os custos, visa atender a necessidade de umainterface Web, para acesso remoto em múltiplas delegacias do estado simultaneamente para tratar, prin-cipalmente, casos de lavagem de dinheiro.
O primeiro passo para iniciar o processo de criação foi achar uma ferramenta livre de qualidade para acriação de interface gráfica de análises relacionais. Após pesquisa, optou-se por utilizar o Cytoscape [2],ferramenta que possui extensão de alto desempenho e qualidade para Web: o Cytoscape js [3]. De posseda plataforma sobre a qual seria desenvolvido a aplicação, inciamos o processo de convênio com órgãospúblicos para adquirir dados que contenham informações apropriadas para o dashboard em questão.Atualmente, foi possível adquirir as bases de dados da CAERN e do Tribunal de Contas do Estado para
13
serem utilizados.No estado inicial da aplicação, foi feita uma demonstração para a Polícia Civil utilizando dados da
rede social Twitter, mostrando como os usuários se relacionam com seus seguidores. A tela inicial daaplicação inicial e o resultado do processamento são mostrados nas Figuras 9 e 10.
Figura 9: Tela Inicial da Aplicação de Lavagem de Dinheiro
Figura 10: Tela de Relaçãod e Usuários
A tela mostrada na figura 10 é resultado de uma consulta pelo usuário "m_rfigueredo". O Cytoscapeconstrói a partir do aquivo criado durante a requisição aos servidores do twitter (Figura 11), a rede de
14
relações do usuário em forma de um grafo.
Figura 11: Arquivo Contendo Relações do Grafo
Nos próximos meses, pretende-se criar uma plataforma mais robusta e com capacidade de utilizartodos os dados disponíveis e com interface aprimorada. Essa aplicação tende a ser de extrema importânciapara a polícia civil nos seus trabalhos contra a lavagem de dinheiro.
3.2.2 Componentes do FIWARE
Ao longo do trimestre, o bolsista Leandro Albino, responsável pela linha de trabalho de Técnicas de Visu-alização, foi designado a trabalhar juntamente ao WP5 (Middleware) para o estudo acerca da plataformaFIWARE e seus GEs (Generic Enables). Essa integração entre os WPs tem o objetivo de facilitar o pos-terior desenvolvimento de atividades do WP6 (Análise e Visualização de dados) utilizando a plataformacitada.
O FIWARE contém diversas GEs (ferramentas de software) que permitem aos desenvolvedores a im-plantação de variadas funcionalidades, como a conexão com a Internet das coisas ou de análise de BigData, tornando a programação mais fácil. Todos esses recursos são públicos e de código aberto. No en-tanto, dentre todas as funcionalidades disponíveis, ficamos responsáveis pelo capítulo Data/Context Ma-nagement, mais especificamente o CEP (Complex Event Processing) GE e o Cosmos (Big Data Analysis)GE, das quais falaremos com mais detalhes nas seções subsequentes.
3.2.3 Complex Event Processing (CEP) GE
3.2.3.1 Objetivos
O CEP (do inglês, Complex Event Processing) é um GE disponível no Data/Context Management daplataforma FIWARE, e tem como objetivo dar suporte ao desenvolvimento, implantação e manutençãode aplicações que envolvam o processamento de eventos (acontecimentos de interesse em um sistema oudomínio) complexos, assim como proporcionar meios para definir e manter a lógica de processamento
15
desses eventos de forma flexível e consistente. O CEP trabalha analisando, em tempo real, os dadosdos diversos eventos das aplicações, e, com isso, gerando uma visão imediata e permitindo tomada dedecisões mais rápidas com base nas novas condições. Basicamente, o CEP, projetado para atender tantorequisitos funcionais como não funcionais, realiza o processamento de vários eventos a partir de umanuvem de eventos, objetivando a identificação dos eventos mais significativos dentro desta nuvem, demaneira que não se tenha um alto custo no desempenho do aplicação.
3.2.3.2 Descrição
As funções que realizam o processamento dos eventos, no CEP, são implementadas com base naforma e execução das EPNs (do inglês, Event Processing Networks), estas são compostas de nós deprocessamento EPAs (do inglês, Event Processing Agents), que por sua vez são compostos por agentede processamento. Através de uma rede EPN, pode-se descrever o fluxo de eventos, originado nos pro-dutores (fonte) de eventos, passando através de vários agentes de processamento e ao fim atingindo osconsumidores de eventos, que são o ponto de destino de eventos. A figura 12 ilustra esse processo.
Figura 12: Ilustração de uma rede EPN
Podemos observar que um único agente de processamento pode receber um ou vários eventos de oumais produtores. Percebemos também que o resultado (saída) do processamento de um agente pode serenviado diretamente ao consumidor ou pode ser processado por outros agentes até que seja direcionadoaos consumidores. Cada rede EPN poderá ter uma configuração diferente, permitindo um fluxo de even-tos diferente e adequado a aplicação. O processamento feito pelos agentes é composto de várias funçõese, muitas vezes a mesma função é aplicada a diferentes eventos para fins diferentes em diferentes fasesdo processamento.
Esta abordagem permite, em tempo real, uma repartição flexível dos agentes nas EPAs, concedendomelhores fatores de escalabilidade, desempenho, otimização e distribuir o poder de processamento. En-tidades de aplicação ou alguns outros GEs do FIWARE ligados ao CEP GE podem desempenhar apenaso papel de produtor de eventos (e.g., sensores de comunicação), apenas o papel de consumidor (e.g.,Dashboard, processos de tratamento) ou ambos os papéis (e.g., Context Broker GE).
O comportamento de um agente de processamento de eventos é especificado usando uma linguagemorientada a regra, o PCA (do inglês, Pattern-Condition-Action), que é composta de três partes.
• A detecção de padrões que são associados ao contexto de processamento de eventos;
• Definição de condições (testes lógicos) formulado com base nos eventos; e
16
• Definição de ações a serem realizadas quando todas as condições estabelecidas forem satisfeitas.
Os desenvolvedores da aplicação podem programar padrões a partir de eventos selecionados dentro deum contexto de processamento (e.g., janela de tempo, segmentação) e, apenas se o padrão satisfazer àscondições da regra, há a detecção e a ação correspondente será executada. Alguns exemplos de padrõesutilizados:
• Sequence: os eventos precisam ocorrer em uma ordem específica para o padrão ser correspondido;
• Aggregate: um conjunto de eventos de entrada é usado para calcular funções de agregação e apartir destas funções identifica-se o padrão. Por exemplo, em um determinado período de tempo,calcula-se a porcentagem de falha na leitura de diversos sensores. É emitido alerta caso essa por-centagem seja maior do que 10
• Absent: nenhum evento atrelado a alguma condição chegou dentro da janela de tempo para opadrão a ser correspondido; e
• All: todos os eventos especificados devem chegar para o padrão ser correspondido, independente-mente da ordem.
CEP fornece três interfaces principais: a primeira para receber eventos brutos de produtores de eventos,a segunda para enviar eventos de saída para os consumidores de eventos e a terceira para administrar oestado do CEP e o seu repositório de definições. Todas as operações a seguir devem ser acessadas pormeio do protocolo HTTP, através dos verbos GET, POST, PUT e DELETE. Para as duas primeirasinterfaces, o CEP GE oferece suporte às operações no formato JSON, XML/NGSI ou delimitado por tag.As tabelas a seguir descrevem os modelos de uso dessas APIs.
• API para receber eventos:
Verbo HTTP Exemplo URI DescriçãoPOST {/instance_name}/rest/events Receber eventos externos na instância especificada
Tabela 2: Operações da API para receber eventos
Exemplo no formato JSON/curl:
1 POST http://{server}:{port}/ProtonOnWebServer/rest/events
2 Content-Type: application/json
3 {"Name":"TrafficReport", "volume":"1000"}
• API para enviar eventos:
17
Verbo HTTP Exemplo URI DescriçãoPOST /application-name/consumer Enviar evento para um consumidor
Tabela 3: Operações da API para enviar eventos
Exemplo no formato JSON/curl:
1 POST http://{server}:{port}/application-name/consumer
2 Content-type: application/json
3 {"Cost":"0.0","Certainty":"0.0","Name":"TrafficReport",
4 "EventSource":"","Duration":"0.0","Annotation":"",
5 "volume":"1000","EventId":"e206b5e8-9f3a-4711-9f46-d0e9431fe215",
6 "DetectionTime":"1350311378034"}
• API para gerenciamento do repositório de definições:
Verbo HTTP Exemplo URI DescriçãoGET /{CEP_Admin}/resources/definitions Recuperar todas as definições existentes no repositórioPOST /{CEP_Admin}/resources/definitions Adicionar uma nova definiçãoGET /{CEP_Admin}/resources/definitions/{definition_name} Recuperar a definição completa no formato JSONPUT /{CEP_Admin}/resources/definitions/{definition_name} Substituir o conteúdo de uma definição existente por novos conteúdosDELETE /{CEP_Admin}/resources/definitions/{definition_name} Remover uma definição do repositório
Tabela 4: Operações da API para gerenciar as definições
3.2.3.3 Exemplo de uso
A seguir será apresentado o exemplo de uso do CEP, onde faremos um novo projeto (definição), carre-garemos no servidor CEP e simularemos o envio de alguns eventos para produzir uma saída num arquivotxt. Nosso cenário é bastante simples. Temos alguns sensores de temperatura que iremos monitorar eenviar alertas quando esta temperatura ultrapassar um limite inferior e superior. Todas as requisiçõesHTTP desde exemplo foram criadas utilizando curl, conforme encontrado no fiware-tourguide. Alémdisso, utilizamos também apenas o formato JSON.
Criação da definição do projeto:
O primeiro passo é criar um novo projeto com a ajuda da interface gráfica AuthoringTool (disponívelem http://{server}:{port}/AuthoringTool, no nosso caso http://10.7.31.32:8888/AuthoringTool/) ou atra-vés de solicitação HTTP POST na url base http://{server}:{port}/{CEP_Admin}/resources/definitions/definition_name}. Fazendo uso da interface, o usuário desenvolvedor poderá construir a definição de seuprojeto através do preenchimento de formulários sem a necessidade de escrever código, conforme ilustraa figura 13.
Neste exemplo, criamos nossa definição de projeto através da opção Import Project e selecionando o ar-quivo TemperatureExample.json, disponível em https://github.com/Fiware/tutorials.TourGuide-App/blob
18
Figura 13: Interface Web - CEP AuthoringTool para definição do projeto
/master/docker/images/tutorials.tourguide-app/TemperatureExample.json. A interface também forneceoutras funções como o Verify, para ver se o projeto de definição criado possui algum erro e Save andExport, para salvar uma representação do projeto CEP em formato JSON no repositório ou em um ar-quivo local e o Delete Project, para deletar uma definição.
Para que a aplicação CEP funcione, precisamos definir:
1. Producers: são utilizados para introduzir os eventos externos ao sistema e definir a maneira comoo CEP os recebem. Neste exemplo nós não definimos um produtor explicitamente no projeto. Emvez disso, vamos usar os dados enviados via API através de uma solicitação HTTP POST.
2. Events: são os diferentes eventos que se pretende processar. Uma definição de evento inclui onome do evento e uma lista de seus atributos. Neste exemplo, temos definidos três eventos, noentanto o thingContextUpdate não será necessário, pois não utilizamos o Orion Context Broker(CB) como produtor (para o envio de eventos), são eles:
• HighTemperatureAlert: este alerta vai ser gerado cada vez que a EPA WarningHighTempe-ratureRule desencadear um evento. Definimos os atributos de temperatura e entityId.
• LowTemperatureAlert: este alerta vai ser gerado cada vez que a EPA WarningLowTempe-ratureRule desencadear um evento. Definimos os atributos de temperatura e entityId.
3. EPAs: são utilizadas para processar e aplicar as regras dos eventos de entrada em um contextoespecífico. Neste exemplo, as regras que irão acionar os alertas são as seguintes:
• WarningHighTemperatureRule: Emitir um alerta quando a temperatura sobe acima de umdado limiar (50 graus Celsius) durante 30 segundos.
19
• WarningLowTemperatureRule: Emitir um alerta quando a temperatura cai abaixo de umdeterminado limiar (30 graus Celsius) durante 30 segundos.
4. Temporal Contexts: são janelas de tempo em que as EPAs estão ativos. Neste exemplo, temosduas janelas temporais:
• WarningHighTempWindow: terá como finalidade definir a janela temporal para a o War-ningHighTemperatureRule, ou seja, quando a temperatura ultrapassar os 50 graus Celsius emum intervalo de 30 segundos.
• WarningLowTempWindow: terá como finalidade definir a janela temporal para a o Warnin-gLowTemperatureRule , ou seja, quando a temperatura ficar abaixo de 30 graus Celsius emum intervalo de 30 segundos.
5. Segmentation Contexts: são usados para agrupar vários eventos a serem usados pelas EPAs. Nesteexemplo, temos:
• thingID: usado para definir o atributo (no caso entityID) usado para segmentar os eventos.
6. Composite Contexts: utilizado para agrupar um ou mais contextos. Neste exemplo, temos:
• WarningHighTempComp: irá combinar os contextos thingID e WarningHighTempWindowpara ser usado na EPA WarningHighTemperatureRule.
• WarningLowTempComp: irá combinar os contextos thingID e WarningLowTempWindowpara ser usado na EPA WarningLowTemperatureRule.
7. Consumers: responsável pelo consumo dos eventos e pelo envio para o mundo exterior. Nesteexemplo, temos:
• SensorTempConsumer: é o consumidor para os eventos HighTemperatureAlert e LowTem-peratureAlert. Ele irá criar o arquivo JSON SensorTemp.txt, onde o CEP irá escrever osalertas.
Descoberta das definições criadas:
É possível verificar todas definições que já foram criadas e que estão no repositório CEP. Para isso foiutilizada a seguinte requisição: http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/definitions/Para verificar uma definição específica, basta seguir o modelo: http://{server}:{port}/{CEP_Admin}/ re-sources/definitions/{definition_name} http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/ de-finitions/TemperatureExample.
Iniciando uma instância:
Após a criação da definição do projeto, deve-se criar uma instância da mesma para que se possa enviaros eventos. Para isso, foi utilizada a seguinte requisição HTTP PUT curl:
20
1 curl http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/
2 instances/ProtonOnWebServer \
3 -X PUT -s -S --header ’Content-Type: application/json’ \
4 -d @- <<EOF
5 {
6 "action": "ChangeDefinitions",
7 "definitions-url": "/ProtonOnWebServerAdmin/resources/
8 definitions/TemperatureExample"
9 }
10 EOF
Logo após mudamos o status da instância para start. Se o usuário desejar parar a instância, troca-sepor stop.
1 curl http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/
2 instances/ProtonOnWebServer \
3 -X PUT -s -S --header ’Content-Type: application/json’ \
4 -d @- <<EOF
5 {"action":"ChangeState","state":"start"}
6 EOF
Descoberta das instâncias criadas:
É possível verificar todas as instâncias que já foram criadas e que estão no repositório CEP. Para isso foiutilizada a seguinte requisição: http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
Enviando eventos externos para o CEP:
Após a criação da instância do projeto, a aplicação já está funcionando e pronta para que se possaenviar os eventos. Para isso, foram utilizados os seguintes exemplos de requisição HTTP PUT curl:
• Temperatura baixa:
1 curl http://10.7.31.32:8888/ProtonOnWebServer/rest/events -X
2 POST -s -S \
3 --header ’Content-Type: application/json’ -d @- <<EOF
4 {"Name":"LowTemperatureAlert", "temperature":"25"}
5 EOF
21
• Temperatura alta:
1 curl http://10.7.31.32:8888/ProtonOnWebServer/rest/events -X
2 POST -s -S \
3 --header ’Content-Type: application/json’ -d @- <<EOF
4 {"Name":"HighTemperatureAlert", "temperature":"69"}
5 EOF
Verificar a saída:
Uma vez que definimos e carregamos o projeto, executamos a instância e enviamos os eventos, deve-mos ver os resultados no arquivo /tmp/SensorTemp.txt dentro do container onde o CEP foi instalado. Oarquivo de saída deverá ser como as seguinte:
• Temperatura baixa:
1 {"Cost":"0.0","Certainty":"0.0","Name":"LowTemperatureAlert",
2 "EventSource":"","OccurrenceTime":"29\/02\/2016-19:10:45",
3 "Duration":"0.0","Annotation":"","entityId":
4 "SENSOR_TEMP_ul20client_ACPI_0_Thermal",
5 "EventId":"857e6f02-95ab-41e4-9844-8605c24bcf21",
6 "DetectionTime":"19\/07\/2016-19:10:45",
7 "temperature":"25"}
• Temperatura alta:
1 {"Cost":"0.0","Certainty":"0.0","Name":"HighTemperatureAlert",
2 "EventSource":"","OccurrenceTime":"29\/02\/2016-19:13:31",
3 "Duration":"0.0","Annotation":"","entityId":
4 "SENSOR_TEMP_ul20client_ACPI_1_Thermal",
5 "EventId":"65367f5b-775a-4c01-8cb9-c444fd84d66e",
6 "DetectionTime":"19\/07\/2016-19:13:31",
7 "temperature":"69"}
3.2.3.4 Problemas Encontrados
No exemplo realizado, não foi possível obter acesso ao container onde o CEP foi instalado. Com isso,também não tivemos acesso ao arquivo de saída /tmp/SensorTemp.txt do teste realizado.
22
3.2.3.5 Próximos passos
Pretende-se utilizar o CEP GE em conjunto com o Orion, a fim de monitorar mudanças nos valores deatributos de entidades de contexto para gerar eventos específicos. Além disso, aprofundar mais o estudoda mesma no intuito de se trabalhar no desenvolvimento de aplicações mais robustas.
3.2.4 Big Data Analysis (Cosmos) GE
3.2.4.1 Objetivos
O Cosmos, também chamado de Big Data Analysis, é um GE disponível no Data/Context Manage-ment da plataforma FIWARE, e tem como objetivo a implantação de meios que permitam a análise eprocessamento de dados através de um lote de tarefas (do inglês, batch) e/ou através de um fluxo dedados estruturados ou não estruturados em um sistema computacional (do inglês, data stream), a fimde se obter, posteriormente, uma melhor compreensão sobre tais dados, os quais poderão revelar infor-mações úteis e inteligentes, além de oportunidades até então escondidas, podendo levar à tomada demelhores decisões e com mais confiança. Além disso, melhores decisões podem significar maior eficiên-cia operacional, redução de risco e redução de custos, potencializando a apropriação da informação peloconsumidor.
Os dados a serem analisados no contexto de Big Data podem sempre ser classificados em dois grupos:
• Processamento batch (Lote de tarefas): processamento de dados que ocorre através de um lotede tarefas enfileiradas, de modo que só se processa a próxima tarefa após o término completoda tarefa anterior. Neste tipo de processamento, os dados são armazenados com antecedência e otempo de resposta não é de extrema importância. Por exemplo, alimentação de um banco de dadoslocal durante o dia e envio de um arquivo sequencial contendo todos os registros para atualizaçõesno período noturno nos sistemas centrais.
• Processamento Data Stream (Fluxo de dados): os dados são recebidos e processados em tempoquase real. Os resultados e tomadas e decisão precisam ser obtidos de maneira rápida. Neste tipode processamento, os dados não são previamente armazenados.
3.2.4.2 Descrição
O Cosmos GE também dá suporte à comunicação do padrão NGSI com outros tipos de GEs doFIWARE como o Publish-Subscribe Context Broker GE e Open Data Portal GE, além de permitir aimplementação de computação privada em clusters baseados no ecossistema Hadoop, proporcionandoserviços tanto de computação como de armazenamento:
• Serviços de computação: permitem criar e configurar clusters de máquinas de forma rápida, pormeio de linha de comando ou através da API REST (do inglês, Representational State Transfer).Além disso, permitem também selecionar um subconjunto a partir de uma ampla gama de proces-samento em tecnologias pré-configuradas (e.g., Hadoop, Hive, Oozie, HBase, Sqoop, PIG);
• Serviços de armazenamento: permitem alimentar os clusters com uma enorme quantidade e vari-edade de dados sem haver a necessidade de fazer adaptações ou configurações prévias nos mesmos.Da mesma forma, os serviços de armazenamento podem ser utilizados via linha de comando oupor meio da API REST.
23
O ecossistema Hadoop do Cosmos GE é composto de duas partes essenciais, o Hadoop DistributedFilesystem (HDFS) e o Hadoop MapReduce, ambos são altamente confiáveis e robustos para aplicaçõesque envolvem grande quantidade de dados. O HDFS é um sistema de armazenamento de dados que operade forma distribuída (a informação é armazenada em mais de um nó, onde cada um possui certa parte dainformação original, podendo haver replicações de dados afim de haver recuperação de dados quando umnó falhar), podendo ser utilizado via linha de comando. O HDFS fornece interfaces para as aplicaçõescom o objetivo de movê-los para perto de onde estão localizados os dados. Ele possui 2 tipos de nós:
• Master (ou Namenode): armazena informações da distribuição de arquivos e metadados. É neces-sário que esteja sempre disponível e para garantir a isso pode-se ter um Master Secundário em umoutro servidor para que, em caso de falha do primário, ele possa assumir o controle rapidamente; e
• Worker (ou Datanode): armazena os dados propriamente ditos. Podem criar, excluir e replicarblocos de dados de acordo com as instruções do Nó master dominante.
Dentre as principais características do HDFS, estão a tolerância, detecção e correção rápida de fa-lhas de maneira automática, portabilidade entre sistemas operacionais e hardware, economia e eficiênciaatravés da distribuição de dados e por meio do processamento paralelo entre os clusters, escalabilidadee confiabilidade no armazenamento, processamento e manutenção das grandes quantidades de dados elógica de processamento próxima aos dados.
Já o Hadoop MapReduce é um framework que possui um conjunto de bibliotecas que permite realizarprocessamento e análise de grandes quantidades de dados em paralelo, usando todo o hardware disponí-vel no cluster Hadoop. O processamento é feito utilizando pares de valores de chaves e é dividido em 2etapas principais.
A primeira é chamada de Map, onde ocorre o mapeamento e validação dos dados. Os tipos de entradae de saída do Map geralmente são diferentes umas das outras. A segunda etapa é chamada de Reduce,onde cada resultado da função Map é alocada para um redutor determinado pela função de partição,agregando e sumarizando os resultados obtidos no mapeamento para gerar o resultado final, que é escritono sistema de arquivos distribuídos, através do Escritor de saída.
A técnica de MapReduce é bastante indicado para algoritmos que exigem um alto custo de processa-mento para ser executado em uma única máquina A figura 14 ilustra esse processo.
Figura 14: Ilustração do paradigma MapReduce
24
Anteriormente à fase Map, o leitor de entrada divide o aglomerado de dados em "blocos"de tama-nhos adequados à aplicação e o framework Hadoop atribui um bloco para cada nó de processamento earmazenamento, através de função de mapeamento.
Ciclo de vida dos dados:
A utilização dos dados no Cosmos GE pode ser dividida em 4 fases de vida distintas, são elas:
• Injeção: alimentação do banco do ambiente Big Data através das fontes que geram uma grandequantidade de informação. Pode implicar em outros processos como a normalização (reduzem aredundância de dados e as chances dos dados se tornarem inconsistentes), criptografia (segurançae privacidade), filtragem e compressão dos dados.
• Ingestão: dentro desta fase deve ser garantida a capacidade necessária para absorver o volumede dados vinda durante a injeção. É o processo que cobre o ajuste dos dados (que podem serde natureza muito diferente) obtidos ao formato apropriado que se irá trabalhar e seu posteriorarmazenamento, caso a capacidade seja garantida.
• Processamento: análise propriamente dita dos dados. A arquitetura deve ser facilmente escalávelpara atender um possível aumento das demandas de computação durante a realização das tarefas.
• Consumo: os dados de saída (resultados do processamento) são consumidos e se tornam novosdados de entrada para outra nova análise, ferramentas de visualização, sistemas de consulta, etc.Os resultados podem ser armazenadas num repositório externo diferente, a fim de assegurar adurabilidade e tempos de acesso maiores.
Ecossistema Cosmos:
O Cosmos GE tem, em seu ecossistema, quatro principais ferramentas que irão auxiliar o usuáriodesenvolvedor a implantar meios de análise Big Data. Essas ferramentas são:
• Cygnus: ferramenta que faz a conexão entre o Orion Context Broker e o sistema de arquivosdistribuídos do Cosmos, o HDFS, para alimentar (persistir dados) o cluster de armazenamentopermanente com dados de contextos que estão registrados no Orion Context Broker. Permitindoassim a criação de uma base de dados que irá conter o histórico dos dados de contexto, que poderãoser utilizados numa futura análise BigData. Em outras palavras, o Orion armazena apenas o últimovalor em relação a um dado atributo de uma entidade, e se caso algum valor passado for necessário,então será preciso persisti-los, a cada mudança dessa variável (cada valor), no HDFS, usando oCygnus;
• Tidoop MR Library: biblioteca utilizada na criação de trabalhos MapReduce. Os trabalhos Ma-pReduce disponíveis dentro desta biblioteca podem ser combinados em uma cadeia de execuções,ligando a saída de um trabalho à entrada de outro. Esse encadeamento pode ser feito via linha decomando, manualmente executando as tarefas sequencialmente, usando a API tidoop-mr-lib-apiou a Apache Oozie. Além disso, essa ferramenta inclui meios que permitem a utilização de dadosprovinientes do CKAN;
25
• Extensões Hadoop Tidoop: normalmente, nas aplicações MapReduce no Hadoop, os dados sãolidos e analisados a partir do HDFS, o Hadoop Distributed File System. Porém, é possível que osdados a serem analisados não estejam no HDFS, mas numa memória remota não-HDFS. Nessecaso, usando tidoop-hadoop-ext, será possível ler esses dados ao apontar para essa memória re-mota. Os dados poderão ser armazenados no CKAN ou no NGSI Short-Term Historic; e
• Wilma PEP Proxy e Cosmos Auth: ferramenta para implementar a autenticação e autorizaçãobaseada em OAuth2 em suas APIs REST. Através desses componentes, o desenvolvedor poderáadicionar autenticação e segurança nos aplicativos de back-end. Assim, apenas usuários FIWAREautorizados serão capazes de acessar seus GEs ou serviços REST. Além disso, permite a gestão depermissões e políticas específicas para os recursos, permitindo diferentes níveis de acesso para osusuários.
3.2.4.3 Exemplo de uso e Problemas Encontrados
Inicialmente pensamos em um exemplo em que faríamos o download de algum arquivo .txt e emseguida o upload do mesmo no sistema de armazenamento de arquivos distribuídos, o HDFS Hadoop.Posteriormente, iríamos executar dois trabalhos MapReduce: o primeiro com o objetivo de contar aocorrência de cada palavra do texto e o segundo para ordenar, de forma decrescente, a lista de palavraspor quantidade de ocorrências das mesmas no texto. No entanto, não foi possível executar este exemplopois os recursos do Cosmos necessários para seu desenvolvimento ainda não foram instalados. Das quatroprincipais ferramentas do ecossistema Cosmos anteriormente citadas, apenas o Cygnus foi instalado nomomento.
Pensamos então em outro exemplo que pudéssemos utilizar o Cygnus. O exemplo consiste em utilizara ferramenta Cygnus para fazer a conexão com o Orion Context Broker. Primeiramente deve-se criara entidade de contexto no Orion e seus respectivos atributos. Posteriormente, é preciso criar a conexãoOrion-Cygnus a partir do mecanismo de subscrição de notificação do Orion CB. Através dessa subscri-ção, o Cygnus é notificado cada vez que determinados atributos da entidade de contexto criada mudarem.Para fazer essa subscrição, o desenvolvedor pode usar qualquer cliente REST ou uma requisição HTTPCurl.
No modelo de subscrição descrito abaixo, será enviada uma notificação cada vez que o atributo speed,da entidade car1 e tipo car, muda o seu valor. A notificação será enviada para o link contido em refe-rence (http://{Cygnus_SERVER}:{Cygnus_PORT}/notify) e irá conter os valores dos atributos speed eoil_level. Esta subscrição terá uma duração de um mês (P1M), e só será possível o envio de uma notifi-cação por segundo (PT1S). Após a criação da subscrição, deve-se modificar, no Orion (através de outrarequisição), o(s) atributo(s) que estão sendo monitorados na mesma para testar se as notificações serãoenviadas ao Cygnus com sucesso.
26
1 (curl localhost:1026/v1/subscribeContext -s -S --header ’Content
2 -Type: application/json’ --header ’Accept: application/json’
3 --header ’Fiware-Service: vehicles’
4 --header ’Fiware-ServicePath: /4wheels’ -d @- |
5 python -mjson.tool) <<EOF
6 {
7 "entities": [
8 {
9 "type": "car",
10 "isPattern": "false",
11 "id": "car1"
12 }
13 ],
14 "attributes": [
15 "speed",
16 "oil_level"
17 ],
18 "reference": "http://{Cygnus_SERVER}:{Cygnus_PORT}/notify",
19 "duration": "P1M",
20 "notifyConditions": [
21 {
22 "type": "ONCHANGE",
23 "condValues": [
24 "speed"
25 ]
26 }
27 ],
28 "throttling": "PT1S"
29 }
30 EOF
No entanto, também não foi possível executar este exemplo, pois foi feita apenas a instalação brutado Cygnus e não conseguimos criar a subscrição com sucesso. Seria necessário fazer a configuraçãoprévia do chamado test agent (/usr/cygnus/conf/agent_test.conf) no local onde foi instalado o Cygnus,para fazer a configuração da porta e do link em que se irá receber as notificações, e como não temosacesso ao servidor onde foi instalado, não pudemos assim fazê-lo. A configuração do test agent pode serencontrada no link: http://fiware-cygnus.readthedocs.io/en/release-0.13.0/quick_start_guide/.
3.2.4.4 Próximos passos
Após concluída a instalação de todas as ferramentas do ecossistema Cosmos, pretende-se dar continui-dade ao desenvolvimento do exemplo da contagem e ordenamento de palavras citado na seção anterior.Além disso, iremos aprofundar mais o estudo do Cosmos com o objetivo de desenvolver uma aplicação
27
mais robusta que abranja a comunicação com outras GEs (CKAN, por exemplo).Por fim, além da continuidade nos estudos dos assuntos relacionados à plataforma FIWARE, tam-
bém pretende-se, no próximo trimestre, dar início, no que diz respeito às técnicas de visualização, aodesenvolvimento da aplicação da Lavagem de dinheiro da policia civil citada anteriormente.
3.3 Redução de Dimensionalidade
3.3.1 Abordagem baseada em Information Theoretic Learning
O volume de dados utilizado por ambientes de Big Data normalmente é muito grande, vinculado a issoainda possuem outras características que dificultam o trabalho e a visualização dos mesmos, já que elessão dinâmicos e não estruturados. A Redução da dimensionalidade, por ser uma operação que facilitaviabilizar a visualização desses dados, e ainda, possibilita processos de descobertas do conhecimento emineração de dados é muito importante para o processamento desses dados.
Referente à área de Redução da Dimensionalidade dos Dados, no segundo trimestre do projeto, fo-ram realizadas pesquisas com o intuito de entender e selecionar técnicas de Redução da Dimensiona-lidade, que posteriormente serão desenvolvidas. Durante a pesquisa foram estudadas técnicas lineares,tais como o Principal Component Analysis (PCA) e Multidimensional Scaling (MDS), que são técnicasque mantem as representações dos pontos de dados diferentes distantes entre si nas representações debaixa dimensionalidade, bem como técnicas não lineares como, Sammon Mapping, Stochatic NeighborEmbedding (SNE), t-distributed Stochatic Neighbor Embedding (t-SNE), Kernel Principal ComponentAnalysis (KPCA), Locally Linear Embedding (LLE), Laplacian Eingenmaps, dentre outras. As técnicaslineares tentam manter a mesma estrutura dos dados de alta dimensão na baixa dimensão.
Para efeito de melhor entendimento das técnicas de Redução de Dimensionalidade o estudo foi apro-fundado em 3 (três) delas: PCA, SNE e o t-SNE que serão melhor detalhados a seguir.
O Principal Componente Analysis, ou simplesmente PCA, é um dos métodos mais conhecidos e utili-zados para a redução de dimensionalidade. Ele é simples de implementar, computacionalmente eficientee garante a descoberta de uma estrutura de dados próxima do subespaço linear do espaço de entrada dealta dimensão.
O principal problema do PCA é o fato de só trabalhar com classes linearmente separáveis e a maioriados conjuntos de dados conter essencialmente estruturas não-lineares, que são invisíveis ao PCA e aosoutros métodos lineares para a redução da dimensionalidade.
O PCA consiste em extrair de um conjunto de dados com muitas variáveis relacionadas entre si os seusprincipais componentes, reduzindo assim a sua dimensionalidade e mantendo ao máximo a variação doconjunto de dados.
A redução da dimensionalidade se dá quando existe a seleção dosm primeiros componentes principaisdo conjunto de dados, com m < n, e o descarte dos demais. O cálculo dos componentes principais serefere ao problema de autovalores e autovetores para uma matriz simétrica positiva, chamada de matrizde variância e covariância dos dados.
[20] apresenta um exemplo para um melhor entendimento do PCA analisando dois problemas. Noprimeiro, temos uma distribuição de duas variáveis, x e y, onde existe uma certa semelhança entre osvalores delas, como mostra a Figura 15.
A partir da figura, é possível notar que existe uma correlação muito forte entra as duas variáveis.Como o valor da variável x é aproximadamente igual a variável y em todas as amostras, observa-se quequalquer uma das variáveis traria praticamente o mesmo resultado. Sendo assim, não seria necessário
28
Figura 15: Representação de amostras de duas variáveis x e y
armazenar os valores das duas, mas sim condensar as variáveis em um só eixo, correspondente a x = y.Um exemplo disso pode ser visto na Figura 16.
Figura 16: (a) A reta x = y, primeiro componente principal (b) Os dados originais projetados no eixo doprimeiro componente principal
No segundo problema se tem uma situação semelhante ao primeiro, com a diferença que x e y nãopossuem uma forte correlação, como mostra a figura 17.
Figura 17: (a)Representação original dos dados nos eixos x e y (b) Os eixos dos componentes principaisx1 y1
Calculando uma mudança de eixos, fazendo com que a primeira coordenada nova se torne a respon-sável pela maior variação, ou dispersão, possível dos dados, a segunda coordenada pela segunda maior
29
variação e assim por diante, quando existem n variáveis, no caso geral.No caso da figura 17 pode-se perceber que o eixo x1 possui a maior dispersão nos dados, enquanto
que o eixo y1 possui uma aglomeração de dados em torno de sua origem. Dessa forma o eixo x1 se tornao primeiro componente principal para essa amostra de dados.
A partir desse exemplo é possível generalizar o problema para n amostras de p variáveis.Geometricamente falando sobre o PCA, o primeiro autovalor representa o eixo principal de maior
comprimento; o segundo autovalor, um segundo vetor em comprimento, situado em posição ortogonalao primeiro e assim sucessivamente.
O Stochastic Neighbor Embedding (SNE) inicia convertendo as distâncias euclidianas entre os pontosde dados na alta dimensão em probabilidades condicionais que representam semelhança. A similaridadeente os pontos de dados xi e xj é a probabilidade condicional pj|i, onde xi escolhe xj como vizinho.
Matematicamente essa probabilidade condicional é dada por:
Onde σ é a variância da Gaussiana centrada no ponto xi. Em regiões mais densas, usualmente se usaum valor baixo para σi, em regiões mais esparsas o valor de σi normalmente é mais alto, sendo assim,não existe um valor ótimo para σi em todo o mapa de dados.
Para a baixa dimensionalidade os pontos yi e yj que representam, respectivamente, xi e xj na altadimensão, tem a sua probabilidade condicional calculada por:
Como o intuito nas duas probabilidades condicionais é de apenas apontar as similaridades entre ospontos, então pi|i = qi|i = 0.
Caso os mapas de dados na baixa e na alta dimensão tenham similaridade, então as probabilidadescondicionais p e q para os pontos j e i sempre serão iguais. A medida de divergência de Kullback-Leibler é a medida de fidelidade utilizada pela técnica SNE, nesse caso a divergência é igual à entropiacruzada aditivado de uma constante.
SNE minimiza a soma da divergência de Kullback-Leibler sobre cada um dos pontos usando o métododo gradiente descendente, onde a sua função de custo é:
Aqui Pi representa a distribuição da probabilidade condicional sobre todos os pontos de dados sobre oponto xi e Qi representa a distribuição da probabilidade condicional de todos os outros pontos de dadossobre o ponto yi. Como a divergência de Kullback-Leibler não é simétricos erros nas distâncias na baixadimensão não são ponderados de forma igual, assim a função de custo do SNE foca em reter a estruturalocal dos dados na sua representação. A distribuição de probabilidade possui uma entropia que aumentacom o aumento de σi.
O algoritmo SNE realiza uma busca binária ao valor de σi que produz um Pi com uma perplexidadeespecificada pelo usuário. A definição da perplexidade é dada por:
30
Onde H(Pi) é a entropia de Shannon de Pi medida em bits:A minimização da função de custo da equação da divergência de Kullback-Leibler é realizada usando
o método do gradiente descendente:
Onde esse gradiente pode ser interpretado como a força resultante criada por um conjunto de energiasentre o ponto yi e todos os pontos yj , essas energias atraem ou repelem os pontos, dependendo dadistância entre eles.
O gradiente é inicializado com pontos randômicos na gaussiana, com uma pequena variância e cen-trado em torno da origem. Para acelerar a otimização e evitar mínimos locais um termo de momento éadicionado ao gradiente, matematicamente:
Onde Υ(T ) indica a solução na iteração t, η indica a taxa de aprendizado eα(t) representa o momentumda iteração t.
Ainda, nas iterações iniciais, um ruído gaussiano é adicionado ao mapa de dados após cada iteração.Dessa forma o SNE tende a achar mapas com a melhor organização global, mas para isso requer umaescolha bastante acurada dos parâmetros iniciais.
Já o t-SNE foi desenvolvido para tentar resolver os principais problemas do SNE que possui umafunção de custo difícil de otimizar, além de apresentar o problema da aglomeração dos dados.
A função de custo do t-SNE difere da utilizada no SNE em dois pontos: primeiro que o t-SNE usauma versão simétrica da função do SNE, minimizando a soma da divergência de Kullback-Leibler entreas probabilidades condicionais pj|i e qj|i através da função:
Onde pii e qii são zero. Esse modelo de SNE é chamado de simétrico, pois pij = pji e qij = qji paraquaisquer i, j. Aplicando essas alterações no SNE se consegue visualizações tão boas quanto às do SNE,conseguindo algumas vezes visualizações um pouco melhores (MAATEN, 2008).
A similaridade dos pares no mapa de baixa dimensão qij do t-SNE é dado por:
E a similaridade dos pares no espaço de alta dimensão pij é dado por:A segunda diferença das funções de custo ocorre porque o t-SNE usa a distribuição Student-t no lugar
da Gaussiana para calcular a similaridade entre os pontos no espaço de baixa dimensão. A distribuição
31
Student-t é simétrica, campaniforme e bem semelhante à gaussiana normal, possuindo caudas mais lar-gas, tendo como único parâmetro que define a sua forma a quantidade de graus de liberdade, sendo quequanto maior os graus de liberdade mais próxima da gaussiana a distribuição vai se encontrar. No t-SNEa distribuição Student-t alivia os problemas da aglomeração e da otimização dos problemas.
Como mostrado anteriormente, um dos problemas do SNE é a questão da aglomeração dos pontos,onde em uma área de duas dimensões a área disponível para acomodar os pontos de dados distantes nãoé tão maior do que a área para representar os pontos próximos, fazendo com que haja a tal aglomera-ção. Na tentativa de resolver o problema da aglomeração, além da força de atração, que já existe, foiimplementada também uma força de repulsão entre os pontos.
[21] usou o que ele chamou de “caminho natural” para aliviar o problema da aglomeração. No espaçode alta dimensão as distâncias foram convertidas em probabilidades usando uma distribuição gaussiana,já no espaço de baixa dimensão foi utilizada a distribuição student-t com um grau de liberdade para amesma função, para isso foi utilizada como probabilidade qij :
A justificativa para o uso da distribuição student-t é por ela ser muito próxima da distribuição gaussi-ana, sendo uma mistura de infinitas gaussianas. O gradiente da divergência de Kullback-Leibler entre Pe a probabilidade de distribuição Q, baseada na student-t é:
A seguir segue o algoritmo do t-SNE:
Segundo [21] existem duas vantagens que podem ser visualizadas ao e usar o t-SNE em função doSNE, a primeira é que o t-SNE repele os pontos de dissimilaridade com uma maior intensidade para
32
pequenas distâncias na representação de baixa dimensão e segundo uma forte repulsão entre pontos dedados dissimilares que são modeladas por pequenas distâncias não vão para o infinito.
Dado este estudo preliminar, os próximos passos para o projeto serão dados no desenvolvimento, testese validação destas 3 (três) técnicas, bem como a aplicação delas em bases de dados reais vinculados aoprojeto Smart Metropolis, para possibilitar a visualização dos dados de alta dimensão de uma maneiramais simples.
3.3.2 Abordagens de Seleção de Atributos para problemas de classificação em BigData
Associado ao SmartMetropolis - WP6 de Análise e Visualização de Dados, o projeto de pesquisa: Imple-mentação de Algoritmos para Redução de Dimensionalidade Usando os Conceitos da Teoria da Infor-mação (PIT12446-2013) da UFRN/IMD, com apoio do discente Jhoseph Kelvin Lopes de Jesus, alunodo Bacharelado em Tecnologia da Informação - UFRN/IMD, contribuiu diretamente para linha de atu-ação de Redução de Dimensionalidade através do desenvolvimento de abordagens de combinação deseletores de atributos para redução de dimensionalidade de dados no contexto de Cidades Inteligentes.
Dados dos mais diversos cenários do mundo real tendem a ter alta complexidade e, afim de construirum modelo computacional que represente esses cenários, uma grande quantidade de variáveis (caracte-rísticas) precisam ser levadas em consideração. Problemas nos campos de bioinformática, por exemplo,precisam de milhares de medidas de expressão gênica para descrever pouco mais de dezenas de pacientes.Na área de processamento de imagens, como segmentação ou reconhecimento de padrões, utiliza os pi-xels como características das imagens, resultando num número elevado de características para descreveruma única imagem.
Ao lidar com Big Data no contexto de Cidades Inteligentes, estamos trabalhando com uma quantidadeexpressiva de características, logo a maioria dos algoritmos de aprendizado de máquina sofrem em acharboas soluções devido ao problema da maldição da dimensionalidade ou a falta de amostras de um deter-minado problema. Por sua vez, uma solução adequada é reduzir a quantidade de características. Diversostrabalhos mostram que vários algoritmos de seleção de atributos são eficientes para tipos de problemasdiferentes, possuindo vantagens e desvantagens. Com o intuito de produzir uma solução eficiente ondeseja otimizado o tempo de processamento e que ao final seja obtido um modelo estável e próximo de umasolução ótima, propomos duas abordagens de combinação de algoritmos de seleção de atributos. Essasabordagens permitem que o profissional de Análise e Visualização de dados não tenha que realizar testesexaustivos em busca de um algoritmo que melhor se encaixe em determinado problema, uma vez que asabordagens de combinação realizam a fusão em nível de dados ou de decisão, como seram mostrados aseguir, combinando as soluções produzidas por n algoritmos em uma única solução.
As atividades realizadas durante o trimestre contaram com:
• Revisão da literatura acerca dos principais métodos de seleção de atributos no campo de aprendi-zado de máquina, métodos supervisionados e não-supervisionados;
• Estudo sobre os principais descritores da Teoria da Informação;
• Estudo sobre os principais trabalhos de seleção de atributos baseados em Teoria da Informação(Informação Mútua);
• Criação das abordagens de combinação de algoritmos de seleção: Fusão de Dados e Fusão deDecisão;
33
• Realização de experimentos utilizando bases de dados reais e sintéticas de alta dimensionalidadepara validação do estudo empírico comparativo entre as abordagens propostas e os principais mé-todos da literatura;
• Produção de artigos cientfícos.
3.3.2.1 Abordagens de combinação propostas
Fusão de Dados: Um modo de combinar atributos obtidos por algoritmos de seleção de atributosé através do uso de um esquema de votação para escolher os atributos mais relevantes, baseados nasaída de cada algoritmo de seleção de atributos. Em outras palavras, essa abordagem provê a fusão dosatributos selecionados por diferentes técnicas de seleção de atributos e usa uma estratégia de votação paraselecionar os atributos mais importantes. O esquema de votação é baseado na relevância que os atributosaparecem nas saídas de cada algoritmo. Uma visão geral da abordagem de fusão de dados pode ser vistana figura 18.
Figura 18: Fusão dos Dados
Fusão de Decisão: A ideia é usar uma estrutura de comitê de classificadores como uma abordagem defusão, onde a decisão de cada algoritmo de classificação é combinada por um método de combinação docomitê (Fusão de Decisão). O conceito de comitê de classificadores surgiu nas últimas décadas como umaestratégia para combinar classificadores, visando prover uma solução que é potencialmente mais eficienteque soluções individuais [16]. Nesse contexto, a ideia dessa abordagem consiste em combinar algoritmosde seleção de atributos usando um comitê de classificadores homogêneo. Logo, nós não combinanos assaídas geradas por cada algoritmo de seleção, mas a decisão provida pelos algoritmos de classificaçãotreinados com os conjuntos de dados reduzidos pelos algoritmos de seleção de atributos. Uma visão geralda abordagem de comitê (Fusão de Decisão) pode ser vista na figura 19.
34
Figura 19: Fusão dos Dados
Para um detalhamento maior acerca das abordagens, como formalismos e definições, ver o artigo [12].
3.3.2.2 Materiais e Métodos
Para compor as abordagens de combinação foram utilizadas os algoritmos utilizados em [15] e [9].Selecionamos cinco algoritmos de redução baseados em Informação Mútua, incluindo o algoritmo doautor, Spectral relaxation global Conditional Mutual Information (SPEC_CMI). Algoritmos baseadosem informação mútua tem alto potencial de realizar seleção de atributos quando comparados com mé-todos tradicionais, isso se deve ao fato de que informação mútua, assim como outros descritores deTeoria da Informação, utilizam a informação dos próprios dados para quantificar e selecionar os "melho-res"atributos. Algoritmos utilizados:
• Quadratic programming feature selection (QPFS) [19];
• Spectral Relaxation Global Conditional Mutual Information (SPEC_CMI) [15];
• Maximum Relevance Minimum Total Redundancy (MRMTR) [18];
• Conditional Mutual Information Maximization (CMIM) [11];
• Mutual Information Feature Selection (MIFS) [8];
As implementações dos algoritmos de seleção de atributos baseados em informação mútua são pú-
35
blicas e estão disponíveis em toolboxes do Matlab1 2. O detalhamento acerca dos algoritmos utilizadosestão detalhados nos trabalhos citados acima.
Para validar a performance das abordagens propostas, utilizamos três algoritmos de classificação, quesão: Árvore de Decisão, Naive Bayes e k-NN (Nearest Neighbor). Estes algoritmos foram escolhidos porserem amplamente utilizados pela comunidade de aprendizado de máquina e cada um possui uma formadistinta de obter as soluções. Com esse objetivo, tentamos cobrir uma grande diversidade de heurísticasde classificação para evitar viés tendenciosos para alguma das abordagens.
Como ferramentas, utilizamos os softwares: Matlab[14] e Weka [13], com todos os parâmetros defini-dos como padrão. Estamos cientes que a configuração dos parâmetros leva a melhores resultados, mas otamanho do experimento realizado foi muito grande. Nossos experimentos iniciais visaram obter análi-ses iniciais em relação a ambas as abordagens de combinação, então parâmetros definidos como padrãoforam suficientes.
Para obter resultados mais robustos, utilizamos o 10-fold cross validation para ambas as abordagensde fusão de dados e de decisão. Adicionalmente, todos os algoritmos foram executados 10 vezes, logoobtemos os resultados referentes as médias da acurácia e seus respectivos desvios-padrões. Comparamosos resultados obtidos com o desempenho original das bases e com o extrator de características PCA.
Utilizamos 10 bases de dados em nossos experimentos, essas bases de dados podem ser divididas emdois grupos: real e artificial. As bases de dados reais, dizem respeito a informações coletadas de cenáriosreais de diversas aplicações. Tentamos cobrir um número de aplicações diferentes, da mesma forma queserão apresentados dados de fontes diferentes em relação ao projeto de cidades inteligentes. As bases re-ais utilizadas foram: LSVT - Reconhecimento de Fonemas/Doença de Parkinson , Lung Cancer - Ex-pressão Gênica, Breast Cancer Diagnostic - Processamento de Imagens, ConnectionistBench - Sonares, Ionosphere - Ondas de Raio, Jude - Expressão Gênica and Colon Cancer -Expressão Gênica. E as bases de dados artificiais: Gaussian, Simulated and Friedman.
As bases de dados foram selecionadas visando cobrir diferentes números de amostras e características.As principais características de cada base de dados é apresentada na tabela 5, onde n é o número deamostras, C o número de classes e d é o número de características (dimensionalidade).
Dataset n C Dist.of Classes d
LSVT 126 2 42,84 310Lung Cancer 181 2 31,150 12533Breast Cancer Diagnostic 569 2 212,357 30Connectionist Bench 208 2 97,111 60Ionosphere 351 2 126,225 32St Jude Leukemia 248 6 15,27,64,20,40,79 985Gaussian 60 3 20,20,20 600Simulated 60 5 8,12,10,15,5,10 600Friedman 1000 2 436,564 100Colon Cancer 62 2 22,40 2000
Tabela 5: Descrição das Bases de Dados.
1disponível em http://www.mathworks.com/matlabcentral/fileexchange/
47129-information-theoretic-feature-selection2disponível em http://www.mathworks.com/matlabcentral/fileexchange/
26981-feature-selection-based-on-interaction-information
36
3.3.2.3 Conclusões
Os resultados obtidos pelos experimentos se mostraram promissores, nossos experimentos e análisesgeraram a publicação de dois artigos em conferências importantes na área de Inteligência Computacional.O primeiro: 25th International Conference on Artificial Neural Networks (ICANN/2016 - Barcelona) eo segundo: 5th Brazilian Conference on Intelligent System (BRACIS/2016 - Refice). Obtemos soluçõesmais enxutas com o uso de ambas as abordagens propostas em comparação com métodos tradicionais namaioria das bases de dados utilizadas. Para validar a efetividade das nossas abordagens, utilizamos testesestatísticos (one-tailed student t-test) com um nível de confiança de 95%. Nos nossos trabalhos futurosconsideramos avaliar o uso de outros algoritmos de seleção de atributos afim de tornar as abordagens decombinação mais robustas. Os resultados obtidos pelos experimentos podem ser observados com detalhenos artigos [12] e [7].
3.4 Processamento de Sinais e Análise de Séries Temporais
3.4.1 Identificação de sistemas
A aplicação de identificação de sistemas é amplamente aplicada nos mais diversos campos da ciência,desde que seja possível aplicar modelos autorregressivos. Modelos autorregressivos são sistemas discre-tos cujo valor atual depende de n valores anteriores ponderados por seus respectivos coeficientes.
y[k] = a1y[k − 1] + a2y[k − 2] + ...+ any[k − n]
Dentro da ideia de aplicar um modelo autorregressivo para predizer, ou estimar, valores futuros de umsistema, em primeiro lugar é necessário determinar qual o grau para o sistema e em seguida calcular ovalor de cada coeficiente associado às amostras anteriores.
3.4.2 Determinando os coeficientes
Em uma situação ideal, em que não existe ruido e que o sistema seja de fato um sistema autorregres-sivo. Nesse caso, para determinar os coeficientes é necessária uma pequena quantidade de amostras parasolucionar o sistema de equações. Para facilitar a visualização do método será adotado um sistema desegunda ordem, mas pode ser ampliado para modelos de qualquer ordem.
y[k] = a1y[k − 1] + a2y[k − 2]
y[k − 1] = a1y[k − 2] + a2y[k − 3]
Reformulando em uma equação matricial:
Y = AX
Em que:
Y =
[y[k]
y[k − 1]
]
A =
[y[k − 1] y[k − 2]
y[k − 2] y[k − 3]
]
37
X =
[a1
a2
]Dessa forma, a melhor maneira de encontrar o vetor X é aplicando a inversa na matriz A:
X = A−1Y
Para modelos que apresentam componentes imprevisíveis é possível aproximar o comportamento dosistema utilizando mais amostras, isso resulta em uma equação matricial cuja solução não é tão simplesquanto no caso anterior pois a matriz A não é quadrada. Para encontrar a solução da equação Y = AX énecessário manipular a equação matricial de maneira mais elaborada:
AtY = AtAX
X = (AtA)−1AtY
Essa operação (AtA)−1At é chamada de pseudoinversa e assim é possível encontrar os coeficientesque melhor se enquadram no modelo em questão.
3.4.3 Determinando a ordem do sistema
Tendo em vista que para poder determinar os coeficientes do sistema é necessário um extenso banco dedados, é possível testar a predição do sistema utilizando amostras do próprio banco de dados.
Utilizando somente a metade do banco de dados, determina-se modelos de varias ordens e calcula-seo erro baseado no valor estimado e no valor real utilizando a distância euclidiana , o modelo que resultarem um erro menor será o ideal.
ε =√
(y[k]− y[k])2
Na equação acima, ε representa o erro calculado pela distância euclidiana, y[k] é o vetor com os valoresestimados e y[k] é o vetor com os valores reais.
3.4.4 Resultados
A estratégia exposta foi aplicada em um banco de dados de boletins de ocorrência registrado nos anos de2006 à 2016. Para um melhor desempenho da estratégia o banco de dados, foram feitas séries temporaisonde cada amostra equivale ao número de ocorrências registradas no período de uma semana.
Para testar a os valores estimados, a técnica foi feita somente na primeira metade dos dados e a segundametade serviu para comparar os valores estimados.
Aplicando diretamente na série temporal utilizando modelos autorregressivos de ordem 1 até 35, obti-vemos os seguintes erros de estimação:
38
Analisando o gráfico do erro de estimação, podemos perceber que o modelo de ordem 4 foi o de menorerro e para esse modelo temos a seguinte estimativa.
Em uma análise comparativa, nota-se que o modelos falha ao estimar picos do gráfico. Esse picosrepresentam semanas em que o número de ocorrências registradas é muito maior que a média, de maneiraque são o que o modelo idealmente estimaria. Assim, esse modelo não é ideal para estimar futurasocorrências policiais.
Uma forma de melhorar a estimação é estimar a derivada do sinal e em seguida integrá-lo, pois,uma vez que derivamos o sinal, a componente constante é cancelada melhorando sua estimação. Como
39
estamos tratando de um caso discreto a derivada é escrita como a diferença entre amostras subsequentesx[k] = x[k + 1] − x[k] e como desejamos a amostra x[k + 1], simplesmente reorganizamos a equaçãode diferenças para obter x[k + 1] = x[k] + x[k].
Para comprovar a melhoria da estimação quando trabalhamos com estimação da derivada, foi feita umacomparação do erro para a estimação direta e para a estimação da derivada para modelos de diferentesordens.
Nesse gráfico, podemos constatar que estimar a derivada e em seguida integrar o resultado é umaopção mais precisa de maneira geral. Entretanto o gráfico seguinte mostrará que o resultado ainda não ésatisfatório.
40
De maneira semelhante ao caso de aplicação do método nos dados, a estimação da derivada não con-segue estimar os pontos de pico de forma eficiente. Entretanto O modelo consegue seguir as tendênciasde de aumento e diminuição do número de ocorrências ao longo das semanas.
3.4.5 Trabalhos futuros
Tendo em vista que a aplicação de modelos autorregressivos não obteve sucesso ao estimar com precisãoos picos de ocorrências policiais, será testada outra forma de estimar o número de ocorrências aindabaseado no banco de dados.
O método em questão será o Mean Square Estimation (MSE). O objetivo do MSE é estimar processosestocásticos s(t) baseado em um outro processo estocástico x(ξ) em que ξ está dentro do intervalo (a, b)
e esse intervalo pode ser finito ou infinito.
s(t) = E{s(t)|x(ξ), a < ξ < b}
=
∫ b
ah(α)x(α) dα
Em se tratando de um processo estocástico, a probabilidade de estimar com perfeição os próximosvalores é muito pequena. Logo, o objetivo é encontrar um h(α) que minimize o erro médio quadráticodado por P :
P = E{[s(t)− s(t)]2} = E
{[s(t)−
∫ b
ah(α)x(α) dα
]2}A função h(α) possui incontáveis incógnitas, dado que, seu valor muda para cada α no intervalo (a, b).
Assim, para determinar h(α) será utilizado uma extensão do princípio da ortogonalidade: O erro médioquadrático P dos valores estimados para o processo s(t) é mínimo se o processo x(ξ) é ortogonal ao erros(t)− s(t):
E
{[s(t)−
∫ b
ah(α)x(α) dα
]x(ξ)
}= 0 a ≤ α ≤ b
41
Se h(α) é solução da integral:
Rsx(t, ξ) =
∫ b
ah(α)Rxx(α, ξ) dα a ≤ ξ ≤ b
Em queRsx representa a função de correlação cruzada eRxx a função de autocorrelação. A correlaçãomostra a como as amostras se relacionam entre si, onde a autocorrelação Rxx mostra a correlação entreuma sequência de números x(t) com ela mesma e a correlação cruzada Rsx mostra a correlação entreduas sequências distintas, s(t) e x(t).
Dentro do MSE, existem três seguimentos baseados em como a sequência se comporta e se os valoresestimados estão dentro ou fora do intervalo (a, b).
O primeiro seguimento é chamado de smoothing que visa estimar os valores dentro do intervalointervalo(a, b). Esse processo pode ser, a primeira vista, desnecessário, mas com a presença de ruidoé crucial estimar os valores reais dentro da sequência numérica para melhor utilizar os dados. O se-gundo seguimento estima valores fora do intervalo (a, b) considerando que não há ruido ruido, assims(t) é chamado de predictor, caso a estimativa seja para valores anteriores ao intervalo será chamadode backward predictor e para valores posteriores ao intervalo forward predictor. O terceiro seguimentotambém estima valores fora do intervalo (a, b), mas considera que existe ruido dentro das amostras, logoesse seguimento é chamado de filtering and prediction.
3.5 Análise geoespacial
Com o intuito de processar informações dentro dos dados da segurança pública, técnicas de análisegeoespacial em banco de dados relacionais foram desenvolvidas no contexto dos dados das trajetóriasdas viaturas e das ocorrências policiais. As análises feitas no SGBD PostgreSQL podem, de fato, tomarproporções espaço-temporais quando utilizamos da sua extensão geoespacial PostGIS[5], que possuifunções específicas de análise, a partir das quais, pode-se analisar dissimilaridades entre as trajetórias eidentificar os clusters de ocorrências, por exemplo.
Essas análises, escritas em SQL, podem gerar informações relevantes no contexto de cidades inteli-gentes, no sentido que pode propiciar o contato próximo entre uma aplicação, devido à própria utilizaçãode um banco de dados comum nas aplicações, e um sistema analítico das informações da cidade. Mesmocom suas limitações, o SGBD pode suportar, então, uma prospecção ativa de dados exploratórios, fa-zendo a aplicação conter estatísticas espaciais relevantes numa aplicação de monitoramento e gestão defatores como mobilidade, segurança, entre tantos outros.
3.5.1 A plataforma ROTA-Dashboard
A plataforma ROTA-Dashboard surgiu com a necessidade de trazer todo o escopo da análise dos dadosda segurança pública e expô-las sob ângulos menos óbvios de mapas e gráficos em um ambiente web.
Utilizando, então, dos conceitos de banco de dados geoespaciais e de objetos móveis[17], o Dashboardoferece a perspectiva da análise das trajetórias e ocorrências em relação à logradouros e AISPs, regiõesestratégicas da segurança da cidade. Na figura 20, pode-se ter noção do ambiente de camadas temáticasda plataforma. Nela, pode-se visualizar um mapa de calor das ocorrências sob os polígonos das AISPs,os quais estão coloridos de acordo com a quantidade de veículos presentes naquele momento de rastreio.Esses e outros recursos de mapas temáticos podem ser indexados na plataforma para visualização dessesestudos.
42
Figura 20: Captura de tela do ROTA-Dashboard na aplicação Mapas
Como seu viés é puramente analítico, o suporte para gráficos estatísticos também é de fundamentalimportância. Para isso, foram desenvolvidas informações relevantes as quais relacionam os dados espaci-ais entre si (trajetórias, ocorrências, logradouros e AISPs) de modo que seja possível retirar prognósticosmenos intuitivos da situação das patrulhas, como padrões de dispersão das ocorrências, similaridadesentre trajetórias e distribuição das patrulhas entre as ruas e avenidas.
O estado atual da aplicação permite que boa parte dessas camadas temáticas (mapas) e gráficos jáestejam funcionando de maneira síncrona com a base de dados. Para tanto, nesse período, além da suafolha de estilo ter sido organizada e aprimorada, foi desenvolvido em PHP o código-fonte que ofereceessa dinamicidade à aplicação que antes funcionava de maneira estática; ou seja, agora ela tem os recursospara através da base de dados exibir camadas e gráficos de maneira sincronizada, mas ainda há muito dese avançar.
Ainda, nesse trimestre começou-se a ser implementado a parte dos gráficos que o Dashboard utilizarápara mostrar estatísticas pertinentes. Após algumas buscas, decidiu-se usar o Chart.js[1] como ferramentade visualização dessas estatísticas, devido às fácil utilização e ótima funcionalidade, além de ter uma boadocumentação disponível na sua página na web de referência. Funciona parecido com vários outrasAPIs em JavaScript, ela trata com os dados em um formato similar à um JSON para exibir gráficos embarra, pizza, linear, radar, polar e de bolha. Na figura 21, pode-se perceber uma rápida implementação doChart.js no Dashboard.
43
Figura 21: Captura de tela do ROTA-Dashboard na aplicação Gráficos
Muitas outras análises implementadas no banco de dados geoespacial ainda estão por ser desenvolvidasdessa forma, no entanto, essas análises já representam funcionalidades notáveis da plataforma, outras,ficaram para implementação nos próximos trabalhos, mas boa parte delas foram desenvolvidas e sãodescritas nas próximas seções.
3.5.2 Consultas em banco de dados geográficos e resultados
Para dar suporte ao desenvolvimento de dados relevantes a serem exibidos no Dashboard, foram desen-volvidas consultas no banco de dados com suporte geoespacial PostGIS, que é uma extensão do SGBDrelacional PostgreSQL. Abaixo são listados e descritos as consultas e resultados feitas até então.
O foco das análises se fez nas feições de trajetórias e ocorrências, contrapondo-os em outras geo-metrias da própria cidade. Uma trajetória, por definição [17] se constitui como uma tupla de pontos etempos, os quais se referem à amostragem de uma posição no tempo de um corpo específico. Uma ocor-rência, por fim, trata-se de um evento relacionado à um crime ou problemática própria dos cidadãos composição espacial e temporal.
Primeiro, se fez a importação dos dados para o banco. As trajetórias das viaturas e ocorrências poli-ciais, em formato CSV, foram importadas para o banco de maneira comum, com um CREATE TABLEe um COPY, mas houve de se fazer a adaptação das latitudes e longitudes para o tipo geometria, nocaso dos tipos Point e Linestring. Para os dados de logradouros, os dados foram importados com o plu-gin PostGIS Shapefile and DBF loader. Ainda, os dados das AISPs tiveram de ser pré-processados paraobter as latitudes e longitudes dos polígonos, que estavam em formato KML, esse pré-processamentoconsiste simplesmente em retirar do KML essas coordenadas e convertê-las para o formato adequado.
Definidas as granularidades espaciais (AISPs, poligonos e logradouros, linhas), e as feições espaciais(ocorrências, pontos e trajetórias, linhas); as granularidades temporais dos set de dados, no entanto,precisam ser definidos previamente para mostrar os resultados. Assim foram utilizados 2 semanas dedados de trajetórias, e um grande set de dados de ocorrências de cerca de 10 anos. Para facilitar asanálises, a granuralidade temporal básica é de 1 dia, mas quando esse período for maior, haverá de ter essedestaque na sua descrição, as distâncias são medidas todas em metros, ou quando não, são especificadasna sua descrição.
44
Para começar, pode se consultar o grau de dispersão das ocorrências policiais entre si, calculando adistância média (em metros) entre as ocorrências por AISP. A figura 22 reflete o resultado.
Figura 22: As 5 AISPs com menores distâncias médias entre as ocorrências, em metros.
A segunda consulta (figura 23) se refere à porcentagem absoluta de ruas com ocorrência por AISP. Emum dia, por exemplo 0.72% das ruas da AISP 15 tiveram ocorrências.
Figura 23: AISPs com maiores porcentagens de ruas com ocorrências.
A terceira consulta é mais interessante e funciona como um teste de cobertura para as viaturas patru-lhadas, mostrada na figura 24. A consulta retorna a porcentagem absoluta de ruas patrulhadas por AISP.à direita, mostra-se o resultado visual da cobertura, com ruas em vermelho sendo as não patrulhadas,consequentemente as verdes as patrulhadas.
Figura 24: Cobertura em porcentagem (à esquerda) e efeito visual da cobertura(à direita).
A próxima consulta conta as ocorrências em termos de AISPs. À esquerda da figura 25, mostra-se aporcetagem bruta de ocorrências por AISP, com as 5 mais expressivas. À direita, mostra-se o índice deocorrências por km2 como uma métrica de contraste com a primeira. Poderia ser feito da mesma maneira
45
trocando a granularidade de AISP por bairros, seria uma visualização ainda melhor para os cidadãos seeste fosse o caso.
Figura 25: Parcela em porcentagem de ocorrências na AISP do total (à esquerda) e ( Métrica de ocorrên-cias por km2 na AISP (à direita).
Então, para utilizar a granularidade de bairros e logradouros, a próxima consulta conta quantas ocor-rências aconteceram lá e exibe, também, quantas trajetórias de viaturas por ali passaram. Essa consultatrata-se de um join entre duas outras, as quais calculam a primeira e a segunda coluna separadamente.No caso da AISP que engloba o bairro de Ponta Negra, por exemplo, durante uma semana de análise,pode-se notar o que se vê na figura 26.
Figura 26: Ocorrências incidentes e viaturas que por ali passaram, por rua e bairro.
Assim, para analisar um pouco mais das trajetórias, tentou-se capturar o comprimento das trajetórias,tarefa difícil pelo fato de o intervalo de tempo da amostragem dos pontos que as compõem é variável e,com isso, apresenta-se o perigo de essas trajetórias possuírem distorção considerável em seus compri-mentos.
Para tentar resolver esse e outros problemas, fez-se uma consulta para partição da trajetória em sub-trajetórias, e com isso, diminuir o erro de quando uma amostragem demora muito em relação à anterior.Essa partição constituiu-se em uma indexação das trajetórias de acordo com o intervalo entre a próximaamostragem, se esta passar de um valor de tempo definido, define-se uma nova subtrajetória.
46
Feito a partição das trajetórias, a abordagem ordinária de análise do comprimento das trajetórias foiutilizada, medindo o comprimento da geometria das linhas. Para desvalidar os absurdos, ainda pode-semostrar a velocidade média daquela subtrajetória. O exemplo abaixo mostra a consulta ordenada pelavelocidade média, a qual comparada com o intervalo em que aquela subtrajetória aconteceu, pode-se teruma estimativa da veracidade da informação. No exemplo da figura 27, o resultado de número 1 comcerteza pode ser eliminado da análise.
Figura 27: Comprimento e velocidade das subtrajetórias das viaturas. A coluna intervalo se refere aotempo de atividade daquela subtrajetória.
Continuando na análise das trajetórias, pode-se ainda estudar o grau de dissimiralidade entre as traje-tórias e assim conhecer o quão destoantes elas são entre si. Uma métrica já implementada no PostGIS éa da distância de Hausdorff [6], que trabalha com pares de geometrias do tipo ponto (ou conjunto deles).Essa métrica calcula a maior distância de um ponto de uma trajetória até o ponto mais próximo da outratrajetória. É melhor definida por :
Sua implementação no PostGIS é bastante trivial, pois já está implementada na biblioteca padrão .O resultado (figura 28 para nosso set de dados de trajetórias em um dia possui 210 linhas, comparandotrajetória com trajetória para obter um grau de dissimilaridade anteriormente definido.
47
Figura 28: Maiores valores de dissimilaridade entre trajetórias.
Para os futuros trabalhos referentes ao Dashboard, o principal foco será torná-lo 100% dinâmico, to-talmente integrado ao banco de dados para que o usuário possa decidir o que quer visualizar na seção dosgráficos, e decidir a granularidade de tempo das camadas temáticas na seção dos mapas. Ainda, outrasanálises poderão ser trazidas, como análise em clusters de ocorrências policiais e trajetórias das viaturas,trazendo informações relevantes visando a melhoria no patrulhamento de uma cidade inteligente e hu-mana. Por fim, espera-se começar a trabalhar com o módulo de predição de ocorrências no Dashboard,em que poderá trabalhar com patrulhamento preditivo através da plataforma, fazendo com que ela tenhauma importância muito maior para o usuário final, que é a segurança pública da cidade.
4 Considerações Finais
Durante o segundo trimestre de funcionamento do SmartMetropolis o WP6 conseguiu evoluir conside-ravelmente em suas atividades. Diferentemente do primeiro trimestre, onde a maior parte das pesquisasse desenvolviam sob temas genéricos relativos a análise de dados, a solicitação de demandas geradas,principalmente, por aplicações geradas pelo prof. Nélio direcionou as atividades para fins específicos.
Com isso, as atividades de mineração de texto, visualização de dados e análise de séries temporaisforam bastante exploradas durante o período, trazendo respostas interessantes para as solicitações feitas.Em sua grande maioria, essas respostas se referem ao setor de segurança pública, que vem sendo o maispresente nas análises.
Vale ainda salientar que três publicações foram aceitas em conferências, sendo duas internacionais.Um outro artigo ainda foi submetido e a resposta sobre a aceitação ainda não foi publicada. Com o anda-mento das atividades, no segundo semestre do ano, pretende-se submeter trabalhos para dois periódicosinternacionais.
Aliado a publicação de trabalhos para divulgação dos resultados obtidos, estão sendo produzidos apli-cações que podem ser usadas pelos demais membros do projeto. As implementações estão sendo feitasem diferentes linguagens, uma vez o aprofundamento sobre a plataforma FIWARE, apesar do avanço,ainda não aconteceu de maneira completa.
Vale a pena mencionar que, apesar do aumento na comunicação com outros WPs, o nosso grupo aindadepende, basicamente, de iniciativa própria para definir os temas e desenvolver muitas das pesquisas. Éesperado que os demais grupos aumentem a interação com o WP6 nas próximas etapas do projeto.
48
Referências
[1] Chart Js. chartjs.org. [Online; accessed 12-Julho-2016].
[2] Cytoscape : Network Data Integration, Analysis, and Visualization in a Box . http://www.
cytoscape.org/. [Online; accessed 19-Julho-2016].
[3] Cytoscape Js. js.cytoscape.org/. [Online; accessed 19-Julho-2016].
[4] Natural Language Tookit. http://www.nltk.org. [Online; accessed 19-Julho-2016].
[5] PostGIS, Spatial and Geographic objects for PostgreSQL. http://postgis.net. [Online;accessed 19-Julho-2016].
[6] The Hausforff Distance. http://www.ceng.metu.edu.tr/~e1202654/report/
node2.html. [Online; accessed 10-Julho-2016].
[7] D. Araújo, J. Jesus, A. D. Neto, and A. Martins. A combination method for reducing dimensionalityin large datasets. In LNCS of ICANN 2016 Proceedings, sept 2016.
[8] R. Battiti. Using mutual information for selecting features in supervised neural net learning. Trans.Neur. Netw., 5(4):537–550, July 1994.
[9] G. Brown. A new perspective for information theoretic feature selection. In D. V. Dyk and M. Wel-ling, editors, Proceedings of the Twelfth International Conference on Artificial Intelligence andStatistics (AISTATS-09), volume 5, pages 49–56. Journal of Machine Learning Research - Procee-dings Track, 2009.
[10] P. R. Christopher D. Manning and H. Schütze. Introduction to Information Retrieval. CambridgeUniversity Press, 2008.
[11] F. Fleuret. Fast binary feature selection with conditional mutual information. J. Mach. Learn. Res.,5:1531–1555, Dec. 2004.
[12] J. Jesus, D. Araújo, and A. Canuto. Fusion approaches of feature selection algorithms for classifi-cation problems. In BRACIS 2016 (), oct 2016.
[13] I. W. Mark Hall and E. Frank. Data Mining:Practical Machine Learning Tools and Techniques.2002.
[14] MATLAB. version 7.10.0 (R2010a). The MathWorks Inc., Natick, Massachusetts, 2010.
[15] X. V. Nguyen, J. Chan, S. Romano, and J. Bailey. Effective global approaches for mutual informa-tion based feature selection. In Proceedings of the 20th ACM SIGKDD International Conferenceon Knowledge Discovery and Data Mining, KDD ’14, pages 512–521, New York, NY, USA, 2014.ACM.
[16] R. R. Parente, A. M. P. Canuto, and J. C. X. Jr. Characterization measures of ensemble systemsusing a meta-learning approach. In The 2013 International Joint Conference on Neural Networks,IJCNN 2013, Dallas, TX, USA, August 4-9, 2013, pages 1–8, 2013.
[17] N. Pelekis, E. Frentzos, N. Giatrakos, and Y. Theodoridis. HERMES: A trajectory DB engine formobility-centric applications. IJKBO, 5(2):19–41, 2015.
[18] H. Peng, F. Long, and C. Ding. Feature selection based on mutual information: Criteria ofmax-dependency, max-relevance, and min-redundancy. IEEE Trans. Pattern Anal. Mach. Intell.,
49
27(8):1226–1238, Aug. 2005.
[19] I. Rodriguez-Lujan, R. Huerta, C. Elkan, and C. S. Cruz. Quadratic programming feature selection.J. Mach. Learn. Res., 11:1491–1516, Aug. 2010.
[20] V. F. TINO. Utilização de Ánalise de componentes principais na regulagem de máquinas de injeçãoplástica. Master’s thesis, UFRJ, Rio de Janeiro, Brasil, 2005.
[21] L. van der Maaten and G. Hinton. Visualizing Data using t-SNE. Journal of Machine LearningResearch, 9:2579–2605, Nov. 2008.