Nos últimos anos, diversas cidades passaram a disponibilizar e a fazer uso de seus dados de forma eficiente, possibilitando a criação de soluções tecnológicas para cidades inteligentes. Essas soluções podem ser desenvolvidas de uma maneira específica e adhoc, ou podem ser apoiadas sobre uma plataforma de cidades inteligentes, que são mais interoperáveis e padronizadas. Na prática, uma aplicação utiliza a API de uma plataforma de cidades inteligentes para ter garantias de requisitos não-funcionais, como desempenho, escalabilidade e tolerância a falhas. Contudo, quando várias aplicações utilizam a plataforma, o fluxo de dados gerado e consultado é grande e só pode ser atendido com grande poder computacional. Atualmente, uma forma acessível de atingir o poder computacional necessário é aumentar os recursos computacionais horizontalmente, adicionando mais computadores para distribuir as tarefas de processamento. Nesse contexto, as plataformas devem utilizar ferramentas de processamento distribuído para lidar com aplicações intensivas em dados. Porém, a maior parte das plataformas não integram essas ferramentas, e as que integram, não disponibilizam uma forma facilitada de uso. Neste trabalho, apresentamos uma arquitetura que faz a integração entre ferramentas de processamento distribuído e plataformas de cidades inteligentes com ênfase em usabilidade sem gradação de desempenho. Implementamos a arquitetura como um microsserviço chamado DataProcessor, responsável tanto por integrar a ferramenta de processamento em cluster Apache Spark e a plataforma de cidades inteligentes InterSCity, quanto por disponibilizar essa integração através de uma API REST. Assim, desenvolvedores da plataforma InterSCity podem criar novas tarefas de processamento que utilizam os recursos disponíveis de maneira efetiva, mas sem a necessidade de conhecimento específico sobre a ferramenta de processamento em cluster. Avaliamos o DataProcessor em um experimento que utilizou o simulador de larga escala InterSCSimulator para simular dados de trânsito, que nos permitiu concluir que: (1) o uso do DataProcessor para facilitar o uso do Spark não traz perda de eficiência; (2) embora o DataProcessor disponibilize uma API REST, que é uma opção mais difundida que a API do Spark, a quantidade de código necessário é semelhante; e (3) é possível adicionar novas funcionalidades ao DataProcessor facilmente com a adição de poucas linhas de código.

In recent years, cities started to provide and use data more efficiently, allowing the creation of new smart cities soluitions. Such solutions can be created either in a more specific and ad hoc way or can be supported by a smart cities platform, which is more interoperable and standardized. In practice, an application should use a smart cities platform API to achieve non-functional requirements needs, such as performance, scalability, and fault tolerance. However, when many applications make use of a platform, the data flow is massive and requires large computational resources. Currently, an effective way to achieve the required power is to increase the computational resources in a horizontal way, through the addition of more computers, to be able to better distribute the processing tasks. In this sense, platforms should use cluster processing tools to better deal with data-intensive applications, yet the majority of smart cities platforms do not integrate such tools. Moreover, the platforms that integrates cluster processing tools do not provide an easy way to use. In this work, we present an architecture that integrates cluster processing tools and smart cities platforms with usability in mind without bringing noticeable performance overhead. We implemented the architecture as a microservice called DataProcessor, which integrates the Apache Spark cluster processing tool and the InterSCity smart cities platform. The DataProcessor also provides the usage of this integration through a REST API. Therefore, InterSCity developers may create new data processing tasks that use available computational resources effectively, without a deep knowledge of cluster processing tools. We evaluated DataProcessor in an experiment that used InterSCSimulator, a large scale simulator, to simulate traffic data, which allowed us to conclude that: (1) DataProcessor usage does not bring noticeable performance degradation; (2) even though the DataProcessor API is easier to use, the required number of lines of code is pretty much the same; and (3) it is possible to add new features to the DataProcessor with a few lines of code.