Data Lake: Proposta de Arquitetura Big Data para o Projeto Participact Brasil

Prévia do material em texto

Título 
N
om
e do Autor 
O presente trabalho visa propor uma arquitetura de 
Big Data, no conceito de Data Lake, para o projeto 
ParticipAct Brasil, abordando as principais 
dificuldades na operacionalização de pesquisas com 
análises de dados de grande volume, variedade e 
velocidade. O trabalho foi desenvolvido seguindo a 
metodologia Design Science Research, utilizando o 
framework TOGAF ADM para o projeto de 
arquitetura, disposta nas camadas de negócio, 
aplicação, dados e tecnologia. 
Orientador: Carlos Roberto De Rolt 
Florianópolis, 2020 
DISSERTAÇÃO DE MESTRADO 
DATA LAKE: PROPOSTA DE 
ARQUITETURA BIG DATA PARA O 
PROJETO PARTICIPACT BRASIL 
ANO 
2020 
 DEN
ILTO
N
 LU
IZ DARO
LD | DATA LAKE: PRO
PO
STA DE ARQ
U
ITETU
RA BIG DATA 
PARA O
 PRO
JETO
 PARTICIPACT BRASIL 
 
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC 
CENTRO DE CIÊNCIAS DA ADMINISTRAÇÃO E SOCIOECÔNOMICAS – ESAG 
PROGRAMA DE PÓS GRADUAÇÃO EM ADMINISTRÇÃO 
 
DENILTON LUIZ DAROLD 
 
FLORIANÓPOLIS, 2020 
 
Denilton Luiz Darold
Data Lake: Proposta de Arquitetura Big Data para o
Projeto ParticipAct Brasil
Dissertação apresentada ao Curso de Pós-
graduação em Administração, da Universi-
dade Estadual de Santa Catarina, como re-
quisito parcial para a obtenção do grau de
Mestre em Administração.
Orientador: Prof. Dr. Carlos Roberto De Rolt
Florianópolis
2020
Ficha catalográfica elaborada pelo programa de geração automática da
Biblioteca Setorial do ESAG/UDESC,
com os dados fornecidos pelo(a) autor(a)
Darold, Denilton Luiz
Data Lake: Proposta de Arquitetura Big Data para o Projeto
ParticipAct Brasil/ Denilton Luiz Darold. – 2020.
146 p.
Orientador: Carlos Roberto De Rolt
Dissertação (Mestrado) – Universidade do Estado de Santa Catarina,
Centro de Ciências da Administração e Socioeconômicas - ESAG, Pro-
grama de Pós-Graduação Profissional em Administração, Florianópolis,
2020.
1. Data Lake 2. Big Data 3. Arquitetura I. De Rolt, Carlos Roberto
II. Universidade do Estado de Santa Catarina, Centro de Ciências
da Administração e Socioeconômicas - ESAG, Programa de Pós-
Graduação Profissional em Administração. III. Título.
Denilton Luiz Darold
Data Lake: Proposta de Arquitetura Big Data para o
Projeto ParticipAct Brasil
Dissertação apresentada ao Curso de Pós-
graduação em Administração, da Universi-
dade Estadual de Santa Catarina, como re-
quisito parcial para a obtenção do grau de
Mestre em Administração.
Aprovado em 20 de Maio de 2020.
BANCA EXAMINADORA:
Prof. Dr. Carlos Roberto De Rolt
Orientador
Prof. Dr. Mario A. R. Dantas – UFSC
Avaliador
Prof. Dr. Luca Foschini – UNIBO
Avaliador Externo
Visto e permitida a impressão
Florianópolis 2020
Carlos Roberto De Rolt (Jul 3, 2020 10:47 ADT)
Luca Foschini (Jul 6, 2020 11:58 GMT+2)
Mario Dantas (Jul 6, 2020 08:33 ADT)
https://adobefreeuserschannel.na2.documents.adobe.com/verifier?tx=CBJCHBCAABAA3UZhmn1KjNbTmwBOlfmwaVhbXeFQfAZ-
https://adobefreeuserschannel.na2.documents.adobe.com/verifier?tx=CBJCHBCAABAA3UZhmn1KjNbTmwBOlfmwaVhbXeFQfAZ-
https://adobefreeuserschannel.na2.documents.adobe.com/verifier?tx=CBJCHBCAABAA3UZhmn1KjNbTmwBOlfmwaVhbXeFQfAZ-
Assinatura digital de ficha de aprovação de
dissertação de Mestrado
Final Audit Report 2020-07-06
Created: 2020-07-03
By: denilton darold (denilton.d@gmail.com)
Status: Signed
Transaction ID: CBJCHBCAABAA3UZhmn1KjNbTmwBOlfmwaVhbXeFQfAZ-
"Assinatura digital de ficha de aprovação de dissertação de Mes
trado" History
Document created by denilton darold (denilton.d@gmail.com)
2020-07-03 - 0:47:53 AM GMT- IP address: 189.34.9.149
Document emailed to Carlos Roberto De Rolt (crderolt@gmail.com) for signature
2020-07-03 - 0:49:51 AM GMT
Email viewed by Carlos Roberto De Rolt (crderolt@gmail.com)
2020-07-03 - 2:27:07 AM GMT- IP address: 66.102.8.208
Document e-signed by Carlos Roberto De Rolt (crderolt@gmail.com)
Signature Date: 2020-07-03 - 1:47:35 PM GMT - Time Source: server- IP address: 189.112.62.214
Document emailed to Luca Foschini (luca.foschini@unibo.it) for signature
2020-07-03 - 1:47:36 PM GMT
Email viewed by Luca Foschini (luca.foschini@unibo.it)
2020-07-06 - 9:49:11 AM GMT- IP address: 151.46.89.238
Document e-signed by Luca Foschini (luca.foschini@unibo.it)
Signature Date: 2020-07-06 - 9:58:14 AM GMT - Time Source: server- IP address: 151.46.89.238
Document emailed to Mario Dantas (dantasmar@gmail.com) for signature
2020-07-06 - 9:58:16 AM GMT
Email viewed by Mario Dantas (dantasmar@gmail.com)
2020-07-06 - 11:30:13 AM GMT- IP address: 66.249.88.105
Document e-signed by Mario Dantas (dantasmar@gmail.com)
Signature Date: 2020-07-06 - 11:33:07 AM GMT - Time Source: server- IP address: 189.27.10.16
Signed document emailed to denilton darold (denilton.d@gmail.com), Luca Foschini (luca.foschini@unibo.it),
Carlos Roberto De Rolt (crderolt@gmail.com), and Mario Dantas (dantasmar@gmail.com)
2020-07-06 - 11:33:07 AM GMT
AGRADECIMENTOS
À minha esposa, Elsie Gatiboni Escarrone, e minha filha Eva Escarrone Darold
pelo carinho e apoio mesmo nos momentos de ausência.
Aos meus pais, Deonir Luiz Darold e Geni Darold, pelo incentivo e suporte nos
momentos de decisão.
Ao Prof. Dr. Carlor Roberto De Rolt pela sua dedicação no papel de orientador.
Seu conhecimento, experiência e pragmatismo serviram não somente à construção dessa
dissertação, mas como inspiração profissional.
À Eliza Gomes pela troca de conhecimento e contribuição final na dissertação.
À banca examinadora na qualificação, composta pelo Prof. Dr. Denilson Sell e Prof.
Dr. Nério Zamboni, por todas as contribuições e direcionamentos para a elaboração dessa
dissertação.
Ao corpo docente da ESAG pelo aprendizado ao longo do mestrado.
À coordenação do programa de pós graduação, em especial à Prof. Dr. Micheline
Gaia Ho�mann, pela prestatividade e atenção despendida.
Aos colegas de turma, e, em especial, aos amigos do LabGes pela troca de experi-
ências e conhecimento.
A todos que direta e indiretamente colaboraram em minha trajetória no período
do mestrado.
“You can have brilliant ideas, but if you can’t get them across, your ideas won’t get you
anywhere."
(Lee Iacocca)
RESUMO
A aplicação da inteligência humana potencializada pelas tecnologias de informação e
comunicação(TIC) possibilita a melhoria da qualidade de vida em ambientes urbanos nas
cidades inteligentes. A crescente urbanização acompanhada da intensificação de sensores
fixos produzem grandes quantidade de dados que tem o potencial de serem utilizados para
gestão de eventos. A solução técnica para gerir esses dados depende da capacidade de
armazenamento flexível e robusta que encontrou resposta nas tecnologias de Big Data. Um
dos grandes desafios é a coleta desses dados. Dada a variedade das fontes e formatos de
dados, a manipulação destes até o seu armazenamento, nos processos de ETL(Extraction-
Transform-Load), podem representar um gargalo, pois demandam modelagem dos dados a
priori. O conceito de Data Lake aborda esse problema permitindo uma recepção de dados
sem prévia estruturação, para posterior tratamento e modelagem, transformando ETL em
ELT(Extraction-Load-Transform), aumentando, assim, a capacidade de recepção de dados.
Além da eliminação da barreira na coleta, outro benefício é a disponibilidade dos dados em
um repositório central que permite análise de dados com cruzamentos de fontes diversas e
a diminuição no custo de infraestrutura. O presente trabalho visa propor uma arquitetura
de Big Data, no conceito de Data Lake, para o projeto ParticipAct Brasil, abordando as
principais dificuldades na operacionalização de pesquisas com análises de dados de grande
volume, variedade e velocidade. O trabalho foi desenvolvido seguindo a metodologia Design
Science Research, utilizando o framework TOGAF ADM para o projeto de arquitetura,
disposta nas camadas de negócio, aplicação, dados e tecnologia. A avaliação do artefato foi
realizada com demonstração em cenário de uso no estudo população flutuante na cidade
de Florianópolis, onde foiimplementado algoritmo de machine learning para estimar
a variação populacional. Na demonstração foi evidenciado o atendimento dos objetivos
previstos. As contribuições do trabalho estão no artefato documental desenvolvido que
pode servir de guia para implantação de arquitetura computacional de Big Data no projeto
ParticipAct.
Palavras-chaves: Data lake. Big data. Architecture. Smart cities
ABSTRACT
The use of technologies has boosting human intelligence and allowing the improvement of
the quality of life in urban spaces in smart cities. The increasing urbanization combined
with the growing adoption of sensors produces a massive volume of data that could be
applied in events management. The technical solution to handle this data depends on
flexible and robust storage structures, made available with Big Data technologies. One of
the biggest challenges is to collect the data. Due to the heterogeneity of data sources and
formats, a matter of concern is to handle an immense amount of data in a timely manner,
in ETL (Extraction-Transform-Load) processes. The concept of Data Lake addresses this
problem providing an alternative approach, allowing the data ingestion without prior data
modeling, into a staging area. The advantage, besides this flexibility on reception, is to
provide a centralized repository that allows data analysis combining di�erent datasets in
the same sight. On top of that, this solution is supposed to reduce the infrastructure cost
due to the distributed nature of its main technology, the Apache Hadoop. The present thesis
aims to propose a big data architecture, using the Data Lake concept, for the ParticipAct
Brazil project, addressing the known hardships on data analysis operations of data of
great volume, variety, and velocity in academic research. The thesis was developed under
the Design Science Research methodology, applying the TOGAF ADM to architecture
project, including the layers of business, application, data, and technology. The assessment
of artifact created was through a demonstration in a case scenario, the study of the floating
population in the Florianópolis municipality, in which was implemented a machine-learning
algorithm to estimate the variation in the population in the municipality abovementioned.
The demonstration showed the achievement of the objectives. The contributions of this
thesis lie on the artifact developed that serves as a guideline for future implementation of
the Big Data computational architecture in the ParticipAct project.
Key-words: Data Lake. Big Data. Architecture. Smart Cities.
LISTA DE FIGURAS
Figura 1 – Publicações sobre Data Lake. . . . . . . . . . . . . . . . . . . . . . . . 22
Figura 2 – Arquitetura Funcional de Um Data Lake. . . . . . . . . . . . . . . . . 26
Figura 3 – 3Vs de Big Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – Técnicas de Big Data Analytics . . . . . . . . . . . . . . . . . . . . . . 30
Figura 5 – Áreas de Governança de Dados . . . . . . . . . . . . . . . . . . . . . . 33
Figura 6 – Fluxo de Governança de Dados . . . . . . . . . . . . . . . . . . . . . . 35
Figura 7 – Arquitetura de Referência para Smart Cities . . . . . . . . . . . . . . 39
Figura 8 – Pontuação das cidades no ODI . . . . . . . . . . . . . . . . . . . . . . 43
Figura 9 – Fases do TOGAF ADM. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 10 – Visão Geral do O-BDL . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 11 – Visão Geral da Arquitetura de Referência do NIST. . . . . . . . . . . . 52
Figura 12 – Fases do Processo de DSR . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 13 – Ocorrências de palavras chave da RL. . . . . . . . . . . . . . . . . . . . 60
Figura 14 – Customização TOGAF ADM. . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 15 – Archimate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 16 – Infraestrutura do projeto ParticipACT Brasil . . . . . . . . . . . . . . 66
Figura 17 – Modelo de Big Data no ParticipACT Brasil . . . . . . . . . . . . . . . 67
Figura 18 – Exemplo de arquitetura Data Lake. . . . . . . . . . . . . . . . . . . . . 68
Figura 19 – Objetivos e motivações de negócio. . . . . . . . . . . . . . . . . . . . . 76
Figura 20 – Capacidades de Negócio. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 21 – Visão da Arquitetura. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figura 22 – Arquitetura de Negócio do ParticipAct Brasil. . . . . . . . . . . . . . . 80
Figura 23 – Arquitetura de Dados do ParticipAct Brasil. . . . . . . . . . . . . . . . 83
Figura 24 – Arquitetura de Aplicação do ParticipAct Brasil. . . . . . . . . . . . . . 85
Figura 25 – Arquitetura de Tecnologia. . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figura 26 – Arquitetura de Segurança. . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 27 – Fluxo de Segurança. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figura 28 – Turistas por País de Origem. . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 29 – Linearidade e Correlação. . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 30 – Componentes do sandbox do Data Lake. . . . . . . . . . . . . . . . . . 102
Figura 31 – Workflow Oozie com paralelismo. . . . . . . . . . . . . . . . . . . . . . 103
Figura 32 – Interface de Administração Ambari. . . . . . . . . . . . . . . . . . . . . 106
Figura 33 – Fluxograma de análise de dados no Data Lake. . . . . . . . . . . . . . 107
Figura 34 – UC01 - Caso de Uso Pesquisador . . . . . . . . . . . . . . . . . . . . . 127
Figura 35 – UC02 - Caso de Uso Gestor de Dados . . . . . . . . . . . . . . . . . . 128
Figura 36 – UC03 - Caso de Uso Fornecedor de Dados . . . . . . . . . . . . . . . . 129
Figura 37 – UC04 - Caso de Uso Administrador de TI . . . . . . . . . . . . . . . . 130
LISTA DE TABELAS
Tabela 1 – Matriz de Correlação PEARSON. . . . . . . . . . . . . . . . . . . . . . 98
Tabela 2 – Quadrados Mínimos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Tabela 3 – População Estimada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
LISTA DE QUADROS
Quadro 1 – Comparação DataWarehouse vs Data Lake . . . . . . . . . . . . . . . 29
Quadro 2 – Publicações correlatas sobre arquitetura de referência . . . . . . . . . 38
Quadro 3 – Componentes Comuns . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Quadro 4 – Métodos de Avaliação de DSR . . . . . . . . . . . . . . . . . . . . . . 55
Quadro 5 – Fases do DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Quadro 6 – Consulta em bases de pesquisa . . . . . . . . . . . . . . . . . . . . . . 59
Quadro 7 – Papéis na Governança de Dados . . . . . . . . . . . . . . . . . . . . . 73
Quadro 8 – Mapa de Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Quadro 9 – Zonas de um Data Lake . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Quadro 10 – Forma de coleta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Quadro 11 – Requisitos de Caso de Uso - População Flutuante . . . . . . . . . . . 123
Quadro 12 – Requisitos de Caso de Uso - Mobilidade Urbana . . . . . . . . . . . . 124
Quadro 13 – Requisitos de Caso de Uso - Acessibilidade Inteligente . . . . . . . . . 125
Quadro 14 – Requisitos de Caso de Uso - Gerenciamento Dinâmico de Eventos . . . 126
Quadro 15 – UC01 - Uso de Caso Pesquisador . . . . . . . . . . . . . . . . . . . . 127
Quadro 16 – UC02 - Uso de Caso Gestor de Dados . . . . . . . . . . . . . . . . . . 128
Quadro 17 – UC03 - Uso de Caso Fornecedor de Dados . . . . . . . . . . . . . . . 129
Quadro 18 – UC04 - Uso de Caso Administrador de TI . . . . . . . . . . . . . . . 130
Quadro 19 – PAN01 - Alinhamento Estratégico . . . . . . . . . . . . . . . . . . . . 131
Quadro 20 – PAN02 - Gerenciamento da Informação . . . . . . . . . . . . . . . . . 131
Quadro 21 – PAN03 - Organização de TI . . . . . . . . . . . . . . . . . . . . . . . 131
Quadro 22 – PAD01 - Dadoscomo Ativos . . . . . . . . . . . . . . . . . . . . . . . 132
Quadro 23 – PAD02 - Dados acessíveis . . . . . . . . . . . . . . . . . . . . . . . . . 132
Quadro 24 – PAD03 - Dados protegidos . . . . . . . . . . . . . . . . . . . . . . . . 132
Quadro 25 – PAA01 - Independência Tecnológica . . . . . . . . . . . . . . . . . . . 133
Quadro 26 – PAA02 - Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Quadro 27 – PAA03 - Modularidade . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Quadro 28 – PAT01 - Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . 134
Quadro 29 – PAT02 - Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Quadro 30 – RF01 - Ambiente gráfico destinado ao usuário final . . . . . . . . . . . 135
Quadro 31 – RF02 - Área pessoal de trabalho . . . . . . . . . . . . . . . . . . . . . 135
Quadro 32 – RF03 - Área de armazenamento da equipe . . . . . . . . . . . . . . . 135
Quadro 33 – RF04 - Realizar upload de arquivos de dados . . . . . . . . . . . . . . 135
Quadro 34 – RF05 - Realizar download de arquivos de dados . . . . . . . . . . . . 136
Quadro 35 – RF06 - Capacidade de executar consultas SQL sobre o Data Lake . . 136
Quadro 36 – RF07 - Criação de criar JOBs via Apache Oozie . . . . . . . . . . . . 136
Quadro 37 – RF08 - Agendamento de JOBs via Apache Ooozie . . . . . . . . . . . 136
Quadro 38 – RF09 - Criação de algoritmos de Machine Learning . . . . . . . . . . . 136
Quadro 39 – RF10 - Criação de notebooks para análise de dados . . . . . . . . . . 137
Quadro 40 – RF11 - Tratamento de dados para algoritmos de Machine Learning . . 137
Quadro 41 – RD11 - Execução dos algoritmos em ambiente distribuído . . . . . . . 137
Quadro 42 – RD12 - Gestão de recursos de processamento e de memória . . . . . . 137
Quadro 43 – RD13 - Quotas de armazenamento . . . . . . . . . . . . . . . . . . . . 138
Quadro 44 – RS14 - Controle do acesso às bases de dados . . . . . . . . . . . . . . 138
Quadro 45 – RS15 - Mascaramento de dados sensíveis . . . . . . . . . . . . . . . . 138
Quadro 46 – RS16 - Proteção contra carga de dados de origem desconhecida . . . . 138
Quadro 47 – RS17 - Proteção contra carga de dados de origem desconhecida . . . . 138
CÓDIGOS-FONTE
6.1 Separação de conjunto teste e treino . . . . . . . . . . . . . . . . . . . . . . 99
6.2 Treino do modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
E.1 Propriedades de conexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
E.2 Workflow de orquestracao da extração . . . . . . . . . . . . . . . . . . . . 140
E.3 Workflow de extracao por base . . . . . . . . . . . . . . . . . . . . . . . . 142
E.4 Workflow de copia por base . . . . . . . . . . . . . . . . . . . . . . . . . . 144
E.5 Script SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
E.6 Script PYSPARK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
BI Business Intelligence
CKAN Comprehensive Knowledge Archive Network
CSV Comma separated values
DAPP Diretoria de Análise de Políticas Públicas da FGV
EDW Enterprise Data Warehouse
ETL Extraction-Transform-Load
FOSS Free and Open-Source Software
HDFS Hadoop comprise of Hadoop Distributed File System
IoT Internet of Things
JDBC Java Database Connectivity
JMS Java Message Service
LAI Lei de Acesso à Informação
LGDP Lei Geral de Proteção de Dados
NIST National Institute of Standards and Technology
ODBC Open Database Connectivity
OLAP Online analytical processing
POSIX Portable Operating System Interface
PSI Public Sector Information
SQL Structured Query Language
TOGAF The Open Group Architecture Framework
YARN Yet Anoter Resource Negotiator
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1 Delimitação da situação problema . . . . . . . . . . . . . . . . . . 21
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.1 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 24
2.1 Data Lake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2 Apache Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3 Data warehouse vs Data Lake . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 Big Data Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.5 Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.6 Governança de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.7 Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Smart Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Estudos correlatos de Arquiteturas de Referência em Smart Cities . . 37
2.3 Fontes de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.1 Dados Abertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Arquitetura de Sistemas de Informação . . . . . . . . . . . . . . 44
2.4.1 Arquitetura Corporativa . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.1.1 Métodos de Desenvolvimento de Arquiteturas Corporativa . . . . . . . 45
2.4.1.2 TOGAF ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4.2 Arquiteturas de Referência para Big Data . . . . . . . . . . . . . . . . 48
2.4.2.1 O-BDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.2.2 NIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3 PROCEDIMENTOS METODOLÓGICOS . . . . . . . . . . . . 53
3.1 Caracterização da Pesquisa . . . . . . . . . . . . . . . . . . . . . . 53
3.2 Design Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3 Design Science Research . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.1 Revisão da Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4 TOGAF ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.1 Customização do TOGAF ADM . . . . . . . . . . . . . . . . . . . . . 62
3.4.2 Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4 PARTICIPACT BRASIL E REQUISITOS . . . . . . . . . . . . 66
4.1 Requisitos Comuns . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1 Fase Preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.1 Princípios de Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.2 Customização do TOGAF ADM . . . . . . . . . . . . . . . . . . . . . 71
5.2 Fase A: Visão de Arquitetura . . . . . . . . . . . . . . . . . . . . 72
5.2.1 Identificação de Stakeholders e Requisitos de Negócio . . . . . . . . . 72
5.2.2 Objetivos de Negócio, Motivações e Restrições . . . . . . . . . . . . . 75
5.2.3 Capacidades de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.4 Definição do Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3 Fase B: Arquitetura de Negócio . . . . . . . . . . . . . . . . . . 79
5.4 Fase C: Arquitetura de Sistemas de Informação . . . . . . . . . 82
5.4.1 Arquitetura de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.2 Arquitetura de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.5 Fase D: Arquitetura de Tecnologia . . . . . . . . . . . . . . . . . 86
5.6 Arquitetura de Segurança . . . . . . . . . . . . . . . . . . . . . . . 89
5.6.1 Fluxo Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6 DEMONSTRAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.1 Estudoda População Flutuante . . . . . . . . . . . . . . . . . . . 94
6.1.1 Fontes de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.1.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.1.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.1.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.5 Avaliação da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . 102
7 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . 108
7.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
APÊNDICES 121
APÊNDICE A – REQUISITOS DE BIG DATA NIST . . . . 123
A.1 População Flutuante . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.2 Mobilidade Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A.3 Acessibilidade Inteligente . . . . . . . . . . . . . . . . . . . . . . . 125
A.4 Gerenciamento Dinâmico de Eventos . . . . . . . . . . . . . . . 126
APÊNDICE B – CENÁRIOS DE USO . . . . . . . . . . . . . 127
B.1 UC01 - Caso de Uso Pesquisador . . . . . . . . . . . . . . . . . . 127
B.2 UC02 - Caso de Uso Gestor de Dados . . . . . . . . . . . . . . . 128
B.3 UC03 - Caso de Uso Fornecedor de Dados . . . . . . . . . . . . 129
B.4 UC04 - Caso de Uso Administrador de TI . . . . . . . . . . . . 130
APÊNDICE C – PRINCÍPIOS ARQUITETURAIS . . . . . 131
C.1 Princípios de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . 131
C.2 Princípios de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 132
C.3 Princípios de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . 133
C.4 Princípios de Tecnologia . . . . . . . . . . . . . . . . . . . . . . . 134
APÊNDICE D – REQUISITOS . . . . . . . . . . . . . . . . . 135
D.1 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 135
D.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . 137
D.2.1 Requisitos de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . 137
D.2.2 Requisitos de Segurança . . . . . . . . . . . . . . . . . . . . . . . . . 137
APÊNDICE E – SCRIPTS . . . . . . . . . . . . . . . . . . . . 139
18
1 INTRODUÇÃO
A evolução das tecnologias de informação e comunicação(TIC) possibilitam um
crescimento exponencial no uso de dados, de modo a alterar significativamente o modo de
vida contemporâneo. A sociedade está conectada e dados são produzidos – e consumidos -
constantemente, gerando um enorme volume de dados, de grande variedade e velocidade,
no fenômeno que é conhecido como Big Data. Gantz (2011) conceitua Big Data como uma
nova geração de tecnologias e arquiteturas, projetadas para, de forma economicamente
eficiente, extrair valor de um grande volume de dados de ampla variedade possibilitando a
captura, descoberta e análise de dados em alta velocidade.
Com enfase na análise, Big Data Analytics(BDA) tem foco na geração de valor,
com descoberta, insights, através de técnicas avançadas de análise, estatística, mineração
de dados, machine learning e deep learning. BDA vem sendo adotado amplamente em
várias vertentes, como agricultura, saúde, varejo, governos, e smart cities (SAGGI; JAIN,
2018).
Nas Smart Cities, seus mentores buscam aplicar as tecnologias de informação e
comunicação para melhorar a qualidade de vida dos cidadãos urbanos em áreas como
transporte, trânsito, economia, meio-ambiente, interação com o governo, dentre outros
(ISMAGILOVA et al., 2019).
A crescente urbanização sobrecarrega a infraestrutura, a prestação de serviços e
intensificam problemas urbanos. Em 2050, aproximadamente dois terços da população
mundial viverão nas cidades. No Brasil, esse percentual, de acordo com o Censo Demográfico
de 2010, já atinge 84% da população total (IBGE, 2019). Nesse contexto, as iniciativas de
Smart Cities vem se popularizando, intensificando tanto a produção acadêmica (ALBINO;
BERARDI; DANGELICO, 2015) quanto nas iniciativas executadas, como mostra o relatório
da IBM, com mais de 100 projetos entre 2010 e 2017 (IBM, 2019).
A expansão do uso da Internet das coisas(IoT) tem tido papel importante nas
Smart Cities, viabilizando novos projetos com a geração de dados de dispositivos físicos
(ABAKER et al., 2016). Relatórios estimam que o número de dispositivos conectados em
2016 eram de 22.9 bilhões e devem atingir a marca de 50 bilhões em 2020 (AHMED, 2017).
Sensores, eletrodomésticos, acessórios vestíveis são alguns exemplos de IoT que juntamente
com smartphones e mídias sociais geram uma grande variedade de dados, de diferentes
formatos que, relacionados, podem gerar valor (JANSSEN; KUK, 2016).
Contudo, são os governos os maiores geradores de dados (JANSSEN, 2011). São
as bases de dados do governo que contém as informações mais relevantes dos cidadãos
em diferentes domínios, como energia, segurança pública, tráfico, entre outros. Estes
Capítulo 1. Introdução 19
dados podem ser enriquecidos ou combinados com dispositios IoT e outros como mídias
socias, possibilitando correlações e aplicação de técnicas de ciência de dados (MATHEUS;
JANSSEN; MAHESHWARI, 2018).
Porém, existem barreiras quanto ao acesso dos dados abertos governamentais. Em
que pese a crescente abertura de dados, muitos dos portais disponibilizam os dados fora
do padrões convencionados, o que impedem a reutilização do dado, e com interfaces pouco
amigáveis ao usuário o que dificulta a busca pelas informações (DESSI et al., 2016). Além
dos desafios tecnológicos, há barreiras políticas e culturais na efetiva disponibilização dos
dados abertos governamentais (BENO et al., 2017).
No Brasil, com a Lei de Acesso à Informação(LAI), de 2011 (Lei no 12.527, de 18
de novembro de 2011), instituiu-se o instrumento legal e desde então as agências em esfera
federal vêm disponibilizando dados (BRASIL, 2011). Em 2016 o Decreto 8.777/16 instituiu
a Política de Dados Abertos do Governo Federal fornecendo diretrizes e regulamentações
unificando o entendimento sobre os procedimentos de abertura (BRASIL, 2016). Os estados
e municípios estão elaborando suas próprias políticas de dados abertos em consonância
com o dispositivo federal. O município de Florianópolis instituiu política de dados abertos,
com a Lei No 10.584, de 02 de agosto de 2019 (FLORIANÓPOLIS, 2019).
Em relatório produzido pela FGV DAPP1 em 2018 sob título "Índice de dados
abertos para cidades", os problemas mais comuns identificados nas bases de dados abertos
são: dificuldade de trabalhar dados (metadados insuficientes), indisponibilidade de down-
load da base completa, dataset incompleto e ausência de informação em formato aberto.
No total, apenas 25% das bases analisadas estão 100% de acordo com a definição de dados
abertos (RUEDIGER M. A.; MAZOTTE, 2018).
Contudo, as análises de problemas urbanos não se limitam ao compartilhamento
de bases governamentais. Demandam o cruzamento com os dados gerados pelos cidadãos
via smartphones e dispositivos IoTs que possuem formatos e estruturas diferentes. Para
esse cenário não existem modelos de referência ou arquiteturas definidas (GEROSA et al.,
2017) e a este desafio se direciona a presente dissertação.
Considerando esse contexto, de barreiras na disponibilização de dados abertos
supracitadas e de crescente adoção de tecnologias de Big Data (NUAIMI et al., 2015),
verificou-se a oportunidade de analisar o tema. Na revisão bibliográfica identificiou-se a
falta de padronização das soluções de Big Data para Smart Cities (LIM; KIM; MAGLIO,
2018) e a dificuldade de reutilização de arquitetura de Big Data Analytics de forma geral,
por serem geralmente específicas aos domínios a que se destinam (GEROSA et al., 2017).
Ainda, verificou-se que um dos maiores desafios na criação de padrões e/ou arquiteturas
de referência é a variedade das fontes de dados. A alta diversidade resulta em silos de
1 Diretoria de Análise de Políticas Públicas da FGV
Capítulo 1. Introdução 20
informação, com sistemasnão integrados, com estrutura de dados distintos que dificultam
a interoperabilidade. Uma solução recente para esse problema é o conceito de Data Lake,
que contempla um repositório sem restrições de estrutura na ingestão do dado (schema
on-read2) armazenando os dados em seu formato original (MORRIS, 2018).
Diante do exposto é proposto nessa dissertação uma arquitetura para um Data
Lake urbano tomando como caso de uso o projeto ParticipAct Brasil com aplicação na
análise de dados no estudo da população flutuante no município de Florianópolis. Este
Data Lake urbano tem o propósito de utilizar as tecnologias de coleta e tratamento de
dados de grande volume e variedade para compor um repositório alimentado por variadas
fontes de dados, em seu formato original. Tais fontes são primordialmente dados abertos
governamentais, crowdsensing (sensoriamento coletivo), mídias sociais, observatórios e
demais organizações conveniadas. A constituição deste visa facilitar a coleta de dados,
uma vez que não depende de prévia transformação do dado para ingestão, diminuindo
sensivelmente a barreira tecnológica de recebimento. Uma vez armazenado, este dado
fica disponível para ser tratado, formatado e analisado. A partir deste momento o dado
pode ser cruzado, correlacionado e transformado em informação útil. Em última análise,
possibilita a geração de valor através dos dados, viabilizando a descoberta de padrões, a
utilização de ferramentas de aprendizado de máquina e inteligência artificial em direção ao
propósito maior de transformar dados em benefícios aos residentes dos espaços urbanos.
Sobre o caso de uso, o ParticipACT Brasil é um projeto de pesquisa acadêmica
que busca a gestão eficiente e participativa de cidades inteligentes por meio de uma
plataforma de Tecnologias de Informação e Comunicação (TICs) (UDESC, 2019). O
projeto é conduzido pelo grupo de pesquisa LABGES (Laboratório de Tecnologias de
Gestão), cujo foco é o estudo de inovações tecnológicas proporcionadas pela computação
ubíqua, na nuvem, big data, crowdsensing, smart city e sua aplicação nas organizações
(PEÑA, 2016).
O estudo proposto nesta dissertação tem o potencial de contribuir em duas frentes:
01) na proposição de arquitetura de Big Data na forma de um Data Lake para o Projeto
ParticipAct Brasil contribuindo para sua evolução e expansão, e em sua avaliação, na
02) análise de dados da população flutuante no município de Florianópolis. Os dados
são, inicialmente, oriundos das bases existentes no catálogo do projeto (ESAG, 2019), e
parcerias firmadas com empresas públicas durante o desenvolvimento deste estudo, para
coletar os dados de consumo de energia elétrica, da Celesc (CELESC, 2020), do consumo
de água, da Casan (CASAN, 2020) e da coleta de resíduos, da Comcap (COMCAP, 2020).
2 Schema on-read: Modelagem de dados feita no momento de leitura.
Capítulo 1. Introdução 21
1.1 Delimitação da situação problema
O problema identificado é a dificuldade de operacionalização de pesquisas acadêmi-
cas orientadas a dados no projeto ParticipAct Brasil. A ausência de uma plataforma que
disponibiliza os dados de forma centralizada demanda dos pesquisadores e analistas de
dados não apenas a expertise técnica, mas o provisionamento de uma infraestrutura para
coleta e armazenamento de dados dedicados ao projeto em questão. A heterogeneidade das
fontes de dados, dos formatos dos dados, e a dispersão na publicação dos dados abertos
governamentais representa uma barreira ao trabalho de análise. PEÑA (2016) identificou
como as principais dificuldades encontrados pelos pesquisadores do ESAG/UDESC, as
seguintes:
• Dificuldade de acesso aos dados;
• Armazenamento de dados;
• Relutância das organizações em participar de projetos de pesquisa;
Adicionalmente, pode-se citar a dificuldade no cruzamento dos dados, tratamento
e implementação de algoritmos de machine learning, que podem ser atenuados com a
existência de uma plataforma que contemple o armazenamento centralizado de dados, um
Data Lake, objeto deste trabalho.
1.2 Objetivos
1.2.1 Objetivos Gerais
Propor uma arquitetura de Data Lake para o Projeto ParticipAct Brasil.
1.2.2 Objetivos Específicos
• Apresentar o contexto do problema identificado, descrevendo o Projeto ParticipAct,
seus casos de uso e requisitos;
• Apresentar os objetivos da arquitetura, com base no contexto e na revisão de
literatura realizada sobre Data Lake, Big Data, Smart Cities e Arquitetura;
• Projetar e desenvolver arquitetura de Data Lake em camadas de negócio, aplicação,
dados e tecnologia;
• Demonstrar as capacidades da arquitetura em caso de uso no cálculo da população
flutuante no município de Florianópolis.
Capítulo 1. Introdução 22
1.3 Justificativa
Observou-se na revisão da literatura uma lacuna entre as iniciativas de mercado
referentes a Data Lake e o escasso material acadêmico relacionado, em especial no contexto
de smart cities, foco do ParticipAct Brasil. Diante disso, e da previsão de expansão do
projeto, que inclui adequação tecnológica ao modelo de Big Data, descrito por PEÑA
(2016), encontra-se a justificativa para o estudo, que visa o desenho de uma arquitetura
multi-camadas para habilitar a operacionalização de pesquisas de Big Data e Machine
Learning no projeto ParticipAct Brasil.
Identificou-se também um crescente número de publicações sobre Data Lake nos
últimos cinco anos, evidenciando a incipiência da matéria no campo acadêmico. Na base
de dados SCOPUS (2019), a busca com os termos Data Lake e Big Data combinados
(operação lógica E) evidenciou a evolução da produção, demonstrada no gráfico 1.
Figura 1 – Publicações sobre Data Lake.
Fonte: (SCOPUS, 2019)
O momento é oportuno pela crescente abertura de dados governamentais. No
município foi aprovada recentemente Lei No 10.584, de 02 de Agosto de 2019 que institui
a Política de Dados Abertos no município de Florianópolis (FLORIANÓPOLIS, 2019). O
desenvolvimento de uma plataforma de pesquisa orientada a dados, bem documentada,
que contemple uma armazenamento massivo de dados pode contribuir na construção de elo
entre acadêmia e entes públicos no compartilhamento de dados, promovendo a participação
em pesquisas acadêmicas.
Capítulo 1. Introdução 23
Além da coleta de dados, para efetiva geração de valor, faz-se necessário os adequa-
dos meios tecnológicos. Conforme Janssen, Charalabidis e Zuiderwijk (2012), a geração
de valor com dados abertos depende diretamente de sua utilização, e nesse sentido esse
estudo contribui com os esforços do grupo de pesquisa Laboratório de Tecnologias de
Gestão(LabGes), que estuda a aplicação e os impactos das tecnologias computacionais no
estudo dos problemas urbanos (LABGES, 2019).
O legado da pesquisa poderá, ainda, ser utilizado como referencial teórico na cons-
trução de arquiteturas para projetos de Big Data em institutos de pesquisa e universidades.
Em governos municipais com iniciativas de Smart Cities e política de abertura de dados,
pode servir como guia de arquitetura de solução e ser incorporado à Plano de dados
abertos.
24
2 FUNDAMENTAÇÃO TEÓRICA
A fundamentação teórica visa explorar os conceitos fundamentais para explorar
o estado da arte e contribuir na compreensão do contexto alvo. Inicia-se com o conceito
de Data Lake, sua evolução e relação com demais tecnologias de Big Data. Na sequência
aborda-se o tema Smart Cities, seguida de contextualização sobre Dados Abertos. Conclui-
se com a revisão teórica sobre modelos de arquitetura corporativa e de Big Data.
2.1 Data Lake
O Data Lake pode ser definido como um conceito de armazenamento que abarca a
coleta, o refinamento, arquivo e a exploração de dados em seu formato original em uma
organização (FANG, 2015). É caracterizado por um repositório central que permite o
armazenamento de dados estruturados e não-estruturados, eliminando assim a necessidade
prévia de um modelo e um tratamento de dados no momento da coleta. O termo Data
Lake é relativamente novo, e foi cunhado pelo então CTO da Pentaho1, James Dixon, ao
ilustrar as diferenças e adinâmica entre Data Mart e Data Lake, onde, em perspectiva,
o primeiro seria uma garrafa de água pronta para consumo e o segundo a água em seu
estado natural (PHYU; SHUN, 2018).
"If you think of a datamart as a store of bottled water cleansed and packaged
and structured for easy consumption the Data Lake is a large body of water in
a more natural state. The contents of the Data Lake stream in from a source
to fill the lake, and various users of the lake can come to examine, dive in, or
take samples" (DIXON, 2010).
O princípio é a flexibilidade na coleta dos dados. Todo dado relevante à uma empresa
ou organização é armazenado em uma única infraestrutura de dados, de baixo custo, em
seu formato nativo eliminando barreiras na coleta e reduzindo custo na sanitização e
agilizando a ingestão. Uma vez armazenado, o dado fica disponível para futuras análises.
A necessidade por agilidade e disponibilidade para análise de dados é um motivador deste
conceito. Em termos práticos, um Data Lake pode ser caracterizado por:
• Coleta ampla: Um Data Lake contém tudo, desde dados crus, em longas séries
históricas até dados processados;
1 Pentaho é uma empresa de data analytics baseada nos Estados Unidos adquirida pela Hitachi em 2015
Capítulo 2. Fundamentação Teórica 25
• Transversalidade: Um Data Lake habilita usuários de diferentes unidades de negócio
consumir e cruzar dados conforme sua necessidade;
• Acesso flexível: Um Data Lake habilita diversos padrões de acesso em uma infraes-
trutura compartilhada: batch, online, in-memory e outras formas de processamento
(CONOLLY, 2019).
As iniciativas tradicionais de armazenamento centralizado, os data warehouses
e data marts, eram utilizados largamente em sistemas de suporte à decisão. Mas estes
modelos apresentam uma limitação importante que é a rígida estruturação do dado. Com
o volume de dados gigantesco gerados devido especialmente a Internet, o desafio era
encontrar uma forma de receber dados heterogêneos, imprevisíveis e processá-los em uma
velocidade razoável. Empresas "ponto com"2 buscaram, então, soluções para lidar com
essa larga escala de dados e otimizar funções chave para o seu negócio, como indexação
e sistema de busca. A esse cenário e as respostas encontradas foi cunhado um novo
termo: Big Data. Adicionado em 2013 no dicionário Oxford, é conceituado por este como
dados de grande volume, tipicamente na proporção que sua manipulação e gerenciamento
apresentam significativos desafios (OXFORD, 2019). Existem diversas definições para
Big Data, algumas mais abrangentes, mas é recorrente a caracterização dos 3Vs, volume,
variedade e velocidade. Posteriormente foram agregados outros Vs, como variabilidade,
veracidade, visualização e valor. O conceito Data Lake surgiu dessa onda Big Data, com
a criação de implementação de projetos Apache Hadoop, em meados de 2014. Diversos
fornecedores aderiram ao conceito para destacar suas implementaçõees de Hadoop, mas sem
um consenso sobre o que realmente significa o termo Data Lake(MADERA; LAURENT,
2016). A literatura neste domínio é incipiente, e ainda hoje as definições apresentam
variações.
Um Data Lake, em essencia, é uma solução de Big Data Analytics que permite
a (1)ingestão de dados de formatos e fontes diferentes armazenando-os em seu formato
original, permite o (2)processamento de acordo com diferentes requisitos, (3) fornece
acesso à diferentes perfis de usuários e (4) aplica governança sobre os dados para garantir
qualidade, ciclo de vida segurança, detalhados a seguir e representados graficamente na
Figura 2 (RAVAT; ZHAO, 2019):
• Ingestão: Todos os dados são carregados sem tratamento prévio e armazenados em seu
formato original. A ingestão pode ser proveniente de arquivos em lote(Batch), tempo-
real/movimento (streaming) ou híbrido. Essa zona de recepção permite consultas
posteriores aos dados no formato que foram ingeridos;
2 Empresas que exploram a comercialização de serviços ou produtos na Internet
Capítulo 2. Fundamentação Teórica 26
• Processamento: Nessa etapa os dados passam por tratamentos tanto de requisitos
técnicos, quanto de negócios, sendo posteriormente armazenado em área intermediá-
ria;
• Acesso: Os dados ficam acessíveis para serem consumidos por aplicações de Analytics,
Machine Learning e relatórios em geral;
• Governança: A Governança é aplicada em todas as zonas, sendo responsável pela
segurança, qualidade, controle de ciclo de vida e gerenciamento dos metadados.
Figura 2 – Arquitetura Funcional de Um Data Lake.
Fonte: (RAVAT; ZHAO, 2019)
Uma vez abordado o conceito e principais funções de um Data Lake, busca-se, na
próxima seção, recuperar o conceito de Big Data, seu surgimento e principais características.
2.1.1 Big Data
Big Data, como visto na seção anterior, é o termo comumente atribuído a grandes
quantidades de dados geradas continuamente e que necessitam de tecnologias apropriadas
para o seu devido processamento. Chang (2014), conceitua como :
"Big Data consists of extensive datasets primarily in the characteristics of
volume, variety, velocity, and/or variability e that require a scalable architecture
for e�cient storage, manipulation, and analysis."
O termo "Big Data"foi utilizado pela primeira vez em 2008 por Lynch (2008), no
Journal Nature. Segundo Smorodin e Kolesnichenko (2015), Big Data é o fenômeno da
Era da Informação que foi nomeado como "Terceira onda"por To�er, muito antes, nos
anos 1980. To�er, referindo-se aos processos globais na Era da Informação, fala sobre
Capítulo 2. Fundamentação Teórica 27
muitas decisões(Volume), a serem tomadas muito rapidamente(Velocidade) sobre muitos
problemas distintos(Variedade) (TOFFLER, 1981).
Ao longo dos anos, outros V vem sendo incorporados como características de Big
Data. Khan, define sete V’s como (KHAN; UDDIN; GUPTA, 2014):
1. Volume: refere-se ao tamanho dos dados sendo gerados a partir de várias fontes de
dados;
2. Velocidade: refere-se a velocidade, cada vez mais alta, em que os dados são gerados
e transmitidos para as soluções de armazenamento;
3. Variedade: refere-se aos diferentes tipos de dados, como texto, imagem, vídeo;
4. Veracidade: refere-se a confiabilidade do dado;
5. Validade: trata-se da correção e precisão do dado aliada com sua utilidade no contexto
aplicado;
6. Volatilidade: refere-se a política de retenção dos dados, relacionado ao ciclo-de-vida;
7. Valor: refere-se ao resultado desejado, com objetivo de extrair o máximo valor do
conjunto de dados explorado.
Na Figura 3 há uma compilação dos 3Vs fundamentais de Big Data, colocando-os
em perspectiva de grandeza, dado ao seu tipo e/ou categoria.
Capítulo 2. Fundamentação Teórica 28
Figura 3 – 3Vs de Big Data.
Fonte: (KADENIC, 2015)
Com as características de Big Data revisadas, parte-se para a descrição de sua
principal tecnologia, Hadoop, que teve papel habilitador no desenvolvimento das soluções
de Big Data subsequentes.
2.1.2 Apache Hadoop
A adoção do conceito de Data Lake é diretamente relacionado à tecnologia Hadoop.
Seu ecossistema de projetos de código aberto se tornou popular por fornecer uma alternativa
inovadora de baixo custo e que atende aos desafios do Big Data(FANG, 2015). Hadoop é
uma plataforma que suporta o armazenamento e processamento de grande quantidade de
dados. Baseia-se em hardware distribuído para armazenar e processar, o que possibilita
o processamento em clusters distribuídos em servidores por demanda (Apache Software
Foundation, n).
O núcleo consiste em dois componentes: armazenamento com o HDFS3 e proces-
samento com MapReduce4. HDFS, de forma simplificada, divide um arquivo em blocos
3 Sistema de Arquivos Distribuídos (Apache Software Foundation, n)
4 Modelo de processamento paralelo (Apache Software Foundation, n)
Capítulo 2. Fundamentação Teórica 29
que são armazenados em DataNodes5, gerenciados por um NameNode6. Cada bloco tem
diversas replicações distribuídas em diferentes DataNodes para aumentar a resiliência
(MUNSHI; MOHAMED, 2018). MapReduce é o componente de processamento do Hadoope consiste em nós mestres(JobTracker) e escravos(TaskTracker), gerenciando e executando
tarefas no mesmo conjunto de nós do HDFS. Em 2013, Hadoop foi lançado com Yarn(Yet
Anoter Resource Negotiator), cujo ideia fundamental é otimizar o gerenciamento de recursos
na execução do processamento (Apache Software Foundation, n).
2.1.3 Data warehouse vs Data Lake
O Data Lake, embora com objetivo semelhante, o de possibilitar análise de dados,
difere fundamentalmente do Data Warehouse. Este último refere-se a um conceito maduro
e bastante explorado comercialmente desde os anos 1980 em sistemas de suporte à decisão.
Embora represente, assim como o Data Lake, uma base centralizada, possui estrutura
definida, com modelagem de dados OLAP (Online analytical processing), desenhadas para
responder à questões de negócio, servindo de apoio à propósitos analíticos estratégicos.
Os requisitos de negócio são o principal fator no projeto do data warehouse. Os dados
relevantes são identificados, coletados, tratados e finalmente agregados para entregar os
indicadores desejados. Entretanto, nem sempre se conhece quais indicadores são relevantes
a priori. A imprevisibilidade dos dados oriundos de diferentes fontes e seu imenso volume
dificulta a adoção em projetos de larga escala, com a previsão de inclusão de novos conjunto
de dados frequentemente (MADERA; LAURENT, 2016). Neste contexto o Data Lake se
apresenta promissor, pois, devido a sua flexibilidade e capacidade de armazenamento e
processamento, atende a esses cenários. Contudo, não é possível afirmar que Data Lake
seja um substituto. Embora seja uma evolução, há características distintas que demandam
uma análise detalhada do domínio a ser aplicado, sendo muitas vezes aplicados de forma
complementar, tendo o Data Lake o perfil de fonte de dados para um Data Warehouse
que recebe o dado destilado e modelado para o objetivo de negócio. No Quadro 1 há um
comparativo das principais características entre os dois conceitos.
Quadro 1 – Comparação DataWarehouse vs Data Lake
Comparação Data Warehouse Data Lake
Dados Estruturado, Processado Estruturado, Semi-Estruturado e não EstruturadoDado em formato original, sem processamento
Processamento Esquema em tempo de escrita Esquema em tempo de leitura
Armazenamento Caro, Confiável Barato e redundante
Agilidade Baixa Agilidade. Configuração fixa. Alta agilidade. Configuração flexível
Segurança Maduro Em Maturação
Usuários Analista de Dados/BI Cientista de Dados
Fonte: Adaptado de (PHYU; SHUN, 2018)
5 DataNoe armazenam os dados (Apache Software Foundation, n)
6 NameNode executa operações no sistema de arquivos como abrir, fechar e renomear arquivos e diretórios.
(Apache Software Foundation, n)
Capítulo 2. Fundamentação Teórica 30
2.1.4 Big Data Analytics
Os avanços nas técnicas e tecnologias tem habilitado empresas e organizações a
lidar com dados de maneira mais eficientes. As principais técnicas de Análise de Dados são:
machine learning, data mining, estatística, redes neurais e processamento de linguagem
natural. Na Figura 4 é exibida a linha de tempo do surgimento das principais técnicas
(SAGGI; JAIN, 2018).
Figura 4 – Técnicas de Big Data Analytics
Fonte: (SAGGI; JAIN, 2018)
BDA tem como principal objetivo oferecer suporte para a tomada de decisão nas
organizações. As técnicas supracitadas tem como benefício fornecer evidências através dos
dados, descobrindo padrões e criando insights úteis para a geração de valor. Em essência,
visa transformar dados em informações e este em conhecimento, combinando diferentes
técnicas e abordagens. Os principais modelos de tomada de decisão nas organização, através
de BDA são descritos por Tavana (2014) como:
• Data mining: Extrai dados relevantes empregando uma variedade de técnicas estatís-
ticas, reconhecimento de padrões e visualização de dados;
• Modelo preditivo: É utilizado para reconhecer ameaças e oportunidades identificando
padrões encontrados em uma série temporal;
• Modelo de simulação: É usado para analisar e comparar cenários através da simulação
no contexto organizacional;
• Modelo de otimização: É utilizado para definir a melhor decisão por meio de vários
modelos de otimização;
• Métodos prescritivos: É usado para gerar melhores soluções combinando os modelos
preditivos e de otimização;
• Business intelligence: Através de técnicas de data mining e gerenciamento de desem-
penho, visa aumentar a competitividade da organização.
Capítulo 2. Fundamentação Teórica 31
Na próxima seção será abordado a técnica de BDA utilizado neste trabalho, machine
learning, seu conceito, principais algoritmos e aplicações.
2.1.5 Machine Learning
O uso de algoritmos de machine learning acompanham o crescimento das soluções
de Big Data, a ponto de serem comumente relacionados. Contudo, o último, refere-se
ao tratamento de dados, enquanto o primeiro trata da análise dos dados através de
algoritmos para reconhecimento de padrões e predição de valores. Sua grande vantagem é
a característica de aprendizado e auto-ajuste sem intervenção humana. Como disciplina
de Inteligência Artificial(IA), o termo machine learning é explorado desde a década
de 1950, ganhando popularidade com a onda Big Data, que trouxe a possibilidade de
aplicação efetiva em soluções de mercado, para extração de valor de negócio, em processos
denomidados mineração de dados(Data Mining)(ELVOV, 2018).
De forma geral, algoritmos de Machine Learning resolvem dois problemas: Clas-
sificação e Regressão. No primeiro o objetivo é classificar uma variável em determinada
categoria, por exemplo, se uma reivindicação de indenização de seguro é fraudulenta ou
não. No segundo, Regressão, o objetivo é prever um valor, como, por exemplo, o valor de
uma ação no mercado de ações (BA�TANLAR; OZUYSAL, 2014).
Os algoritmos de machine learning podem ser divididos em duas categorias: Su-
pervisionados e Não-supervisionados. Os supervisionados tem seus dados previamente
identificados, com categorização definida. Problemas de Regressão e Classificação podem
ser ambos resolvidos nessa categoria. Os Não-supervisionados não tem prévia identificação,
é o objetivo passa a ser justamente reconhecer padrão e criar as categorias por si só.
Para isso, os dados são agrupados em grupos e segmentos através do processo chamado
Estimativa de Densidade (BA�TANLAR; OZUYSAL, 2014).
Os principais algoritmos de machine learning podem ser classificados em:
• Modelos Lineares: São usados para prever uma saída usando uma fórmula e parâ-
metros relevantes que combinados entre si são utilizados para treinar e prever um
indicador, a saber:
– Regressão Linear: Neste modelo o objetivo é predizer o valor da variável depen-
dente analisando a influência das variáveis explanatórias. Quando há mais de
uma variável explanatória, é denominada Regressão Linear múltipla;
– Regressão Logística: Segue a mesma lógica da Regressão Linear, porém se aplica
somente a problemas de classificação, predizendo valores Verdadeiro ou Falso;
• Baseados em Árvores: Modelos usados para visualizar regra de decisão no formato de
galhos de árvore e pode ser aplicada para predizer a saída em um cenário não-linear:
Capítulo 2. Fundamentação Teórica 32
– Árvores de Decisão: Os valores possíveis são visualizados em segmentos, segregando-
os em uma árvore, como galhos. Nesse modelo, o treinamento visa analisar a
árvore de decisão para encontrar o melhor ponto;
– Random Forest: Trata-se da combinação de várias árvores de decisão com o
resultado sendo a média de todas as árvores utilizadas no modelo;
– Gradient Boosting: Assim como Random Forest também combina a decisão de
várias árvores, com diferença de que as árvores são treinadas uma após a outra.
• Redes Neurais: Conceito da inteligência artificial que representa a emulação do
comportamento do cérebro humano, na transmissão de mensagens entre neurônios.
Redes Neurais demandam grandes capacidades computacionais e são aplicados,
geralmente, em problemas com dados não estruturados, como Processamento de
Linguagem Natural(PLN).O termo Deep Learning refere-se ao treino de redes neurais
em várias camadas.
2.1.6 Governança de dados
Um dos maiores riscos na adoção de Data Lakes é perda de controle da informação,
convertendo o lago de dados em um pântano (Data Swamp), com dados não identificados
e que jamais serão utilizados. Dada sua flexibilidade quanto a modelagem do dado, ou
mais precisamente sobre a sua não obrigatoriedade, não haveriam barreiras para evitar
a inserção de dados incorretos, repetidos, ou sem a devida identificação (PHYU; SHUN,
2018). Logo, para mitigar esses riscos, a governança de dados se faz fundamental no projeto
de um Data Lake.
A disciplina de Governança de Dados pode ser o estudo sobre sobre a estrutura
que coordena, orienta e define regras para criação, reuso e consumo dos dados.
Segundo DAMA DMBOK R• (Data Management Body of Knowledge), governança de
dados é o “Exercício de autoridade, controle, planejamento, monitoramento, disponibilidade,
segurança e execução dos ativos de dados e seu respectivo consumo” (DAMA, 2009).
O DAMA DMBOK R• (Data Management Body of Knowledge) é um framework
de boas práticas de gestão de dados, que tem como intuito transmitir a importância da
gestão de dados. Entre a 10 funções de gestão de dados, representadas na Figura 5, o
ponto abordado nessa dissertação será na Gestão de metadados.
Capítulo 2. Fundamentação Teórica 33
Figura 5 – Áreas de Governança de Dados
Fonte: (DAMA, 2009)
2.1.7 Metadados
Metadados são comumente chamados de dados sobre dados ou informação sobre
informação. Segundo Turban, os metadados descrevem a estrutura e significados a respeito
de dados e contribuindo para a sua utilidade, oferecendo contexto aos dados relacionados
(TURBAN EFRAIM; ARONSON, 2009).
De acordo com o DAMA-DMBOK R• Gestão de metadados “é a função responsável
por gerir e armazenar metadados de uma organização, além de viabilizar formas de acesso”.
Portanto, a gestão dos Metadados é fundamental na recuperação da informação
correta. Os Metadados podem ser Técnicos ou de Negócio. Os técnicos referem-se à
estrutura de armazenamento segundo as práticas de modelagem de dados:
• Modelo Lógico: Entidades, atributos e relacionamentos;
• Modelo Físico: Bancos de dados e suas tabelas;
Capítulo 2. Fundamentação Teórica 34
• Integração de dados: Fluxo de dados e transformação.
Os metadados de negócio funcionam como glossário, contendo os termos de negócio,
sinônimos, definições, taxonomias e as classificações e categorizações de contexto.
Sobre a qualidade dos metadados, o DAMA BMBOK, define:
1. Aderência ao negócio: Deve ser aderente aos requisitos e regras de negócio da empresa;
2. Unicidade — Deve ser único na empresa, sem duplicidade de conteúdo ou conceitos;
3. Manutenibilidade — Baixo custo de atualização dos metadados;
4. Confiabilidade — Indica a corretude do Metadado;
5. Desempenho — Tempo gasto para localizar e acessar deve ser razoável;
6. Legibilidade — Inteligível, deve ser de fácil leitura e compreensão;
7. Disponibilidade — Disponível para quer possuir a devida autorização.
Para a implementação de sistema de gestão de Metadados em um Data Lake,
Costa sugere (COSTA, 2018) que a operacionalização demanda os itens abaixo, também
representados na Figura 6.
1. Interface de cadastro de Metadados: Formulário para inserção do metadado, coerente
com o glossário de negócio;
2. Fluxo de aprovação de Metadados: Deve possuir ao menos uma camada de aprovação,
para revisão por parte do Gestor de Dados;
3. Motor de Busca: Ferramenta que possibilite a indexação e recuperação dos metadados,
com filtros de acordo com a taxonomia;
4. Gestão: Procedimentos de gestão de processos para regular a criação e manutenção
das atividades relacionadas.
Capítulo 2. Fundamentação Teórica 35
Figura 6 – Fluxo de Governança de Dados
Fonte: (COSTA, 2018).
Com essa seção, sobre o gerenciamento de metadados, encerra-se a fundamentação
teórica referente às tecnologias chave utilizadas na dissertação. Foram abordados até
aqui os conceitos de Data Lake, Big Data, Machine Learning, sua evolução histórica e
principais características. Recuperou-se o conceito e a importância da governança de dados
no contexto de big data e sua disciplina de gerenciamento de metadados. A próxima seção
trata do contexto alvo, smart cities.
2.2 Smart Cities
Neste capítulo será abordado o tema Smart Cities, recuperando o conceito, histórico,
categorias de problemas urbanos e infraestrutura computacional. Encerra-se com estudos
sobre arquiteturas e modelos de referência de Big Data para Smart Cities, elo com o
projeto ParticipAct Brasil.
Smart Cities, ou cidade inteligentes, são cidades inovadores que utilizam tecnologias
de informação e comunicação para melhorar a qualidade de vida de seus habitantes. Essa
melhoria se dá através da oferta de serviços desenvolvidos com o uso da tecnologia da
informação (POURZOLFAGHAR et al., 2018).
O termo “smart” é atribuído ao inglês americano, usado em conversas informais
para caracterizar inteligência. De acordo com o dicionário OXFORD (2019), smart pode
ser entendido como “possuindo ou apresentando uma penetrante inteligência” ou, no caso
de um dispositivo, como “assumindo ação independente” (LYONS, 2018).
Cocchia afirma que a noção de smart city surgiu como resultado dos objetivos
estabelecidos pelo Protocolo de Kyoto, em 1997, no qual algumas das iniciativas e projetos
foram rotulados como “smart” (COCCHIA, 2014) . Greenfield entende a noção de smart city
como um fenômeno da vida urbana que segundo ele agora cresce “everyware”. Em sua mescla
Capítulo 2. Fundamentação Teórica 36
de “every” e “ware”, indica que a fundação de uma smart city inclui uma infraestrutura física
conectada e inteligente, infraestrutura social e estrutura de negócios, os quais combinados
usam a inteligência coletiva na melhor forma possível para melhor a habitabilidade
(GREENFIELD, 2006). Uma rede interconectada permite o monitoramente e integração de
todos os elementos críticos, otimização do uso de recursos, planejamento de manutenções
e aumento de segurança. A análise dos dados coletados nesta infraestrutura tecnológica
fornece um entendimento mais abrangente e coeso dos espaços urbanos, contribuindo para
melhorar a eficiência e a sustentabilidade da vida urbana (KUDVA; YE, 2017).
Em 2007, Rudolph Gi�nger com a Edinburgh Napier University criaram um
ranking das 70 cidades na União Europeia baseado nas características urbanas e criando
perfis. Os perfis consistiam em seis características consideradas “smart”: economia, pessoas,
governança, mobilidade, meio-ambiente e modo de vida. Este índice resultou na criação de
uma comissão que definiu objetivos de médio e longo prazo, como a redução de 20 porcento
do consumo de energia até 2020 e o desenvolvimento de uma economia com dióxido de
carbono até 2050 (TOWNSEND, 2013).
Segundo a Smart Cities Council (2019), o conceito de smart cities sustenta-se no
uso de tecnologias em três aspectos: a qualidade de vida, as condições de trabalho e a
sustentabilidade. Para OSTI (2019), o foco está nas infraestruturas físicas críticas, meios
de transporte, fornecimento de água e energia, que devem estar integradas visando o
desenvolvimento sustentável da cidade (PEÑA, 2016).
Para suportar as smart cities, tecnologias de informação e comunicação inovadoras
vem sendo desenvolvidas. Big Data, Big Data Analytics, Cloud Computing, IoT (Internet
of Things) e Crowdsensing são tecnologias recentes que contribuem para as implementações
de smart cities (BUOSI, 2018).
A difusão das TICs e seu caráter pervasivo, possibilita a coleta de dados distribuídos,
oriundos de diversas fontes, sejam dados transacionais de agências governamentais, IoT ou
crowdsensing. Com o imenso volume de informação gerada, tecnologias de Big Data, como
visto anteriormente nesse capítulo, são necessárias para armazenar adequadamente o dado
e servir de base de conhecimento e desenvolvimento de soluções. As principais fontes de
dados em uma smart city são:
• Dados administrativos:Em um esforço para aumentar a transparência e accoun-
tability, muitas cidades estão aderindo à cultura de dados abertos. Através da
digitalização de serviços e a interoperabilidade de bases de dados, conjuntos de
dados ricos em informação são disponibilizados livremente. Portais de transparência
aumentam o engajamento do cidadão, melhoram a prestação de contas e geram
economia de recursos com operações mais eficientes, melhor comunicação e menor
risco de fraudes (BARKHAM SHEHARYAR BOKHARI, 2018);
Capítulo 2. Fundamentação Teórica 37
• IoT e sensores: Dispositivos conectados a internet oferecem dados em tempo real
e com posicionamento geospacial, extramamente imporantes no mapeamento da
cidade. Sensores representam a forma mais conhecida de coleta de dados urbanos. São
colocados em estruturas físicas e edifícios para medir uma variedade de indicadores,
como luz, temperatura, qualidade do ar, fluxo de pessoas, entre outros. Essa coleta em
tempo real auxilia não só no monitoramento, mas servindo de base para descoberta
de padrões de comportamento e desenvolvimento de soluções automatizadas;
• Aplicativos de smartphones: Aplicativos tem emergido como nova e poderosa fonte
de dados. Usuário podem autorizar aplicativos a enviar dados dos sensores embar-
cados nos aparelhos e assim contribuir no mapeamento do hábito do cidadão, no
que é chamada crowdsensing. O principal objetivo dos serviços participativos de
crowdsensing e fechar o ciclo entre os mundos virtual e físico no novo cenário da
próxima geração das Smart City;
• Crowdsourcing: Movimento onde um grande número de pessoas, geralmente vo-
luntários, produzem dados coletivamente para determinados fins. Uma forma de
crowdsourcing é conhecida como ciência cidadã, onde voluntário geram, preparam e
processam observações e indicadores de determinado fenômeno. Estudos mostram
que esse tipo de iniciativa que envolve o cidadão promove o engajamento cívico e
aumenta a confiança entre o governo e cidadãos;
• Mídias sociais: Através do engajamento social, as mídias socias possibilitam aos
usuários inserir dados como vídeos, imagens, aúdios, hashtags que são centralizados
em bases de dados e podem ser utilizados para mapeamento comportamental.
Os dados coletados permitem o estudo de vários tipos de problemas que podem ser
agrupados e categorizados, segundo Lim, Kim e Maglio (2018), em: “smart device”, “smart
environment”, “smart home”, “smart energy”, “smart building”, “smart transportation”,
“smart logistics”, “smart farming”, “smart security”, “smart health”, “smart hospitality” e
“smart education”.
Para atender essa variedade de problemas, com diferentes formas de geração e
coleta dos dados, é necessário entender estudar as forma de arquitetura dos sistemas de
informação para esse fim. Na próxima seção são descritos os estudos correlatos encontrados.
2.2.1 Estudos correlatos de Arquiteturas de Referência em Smart Cities
Embora não haja padrão ou consenso de estrutura para arquiteturas de Big Data
para Smart Cities (LIM; KIM; MAGLIO, 2018), há estudos que descrevem arquitetura
para domínios específicos e com pontos focais distintos. No quadro (LIM; KIM; MAGLIO,
2018) há uma relação dos estudos identificados na pesquisa.
Capítulo 2. Fundamentação Teórica 38
Quadro 2 – Publicações correlatas sobre arquitetura de referência
Publicações correlatas
Lusa, Rabello e Cervi (2015) Open smart city view - An architecture for open go-
vernment data manipulation and presentation at city
level
He et al. (2018) QoE-Driven Big Data Architecture for Smart City
Costa e Santos (2016) BASIS : A Big Data Architecture for Smart Cities
Bergamini et al. (2018) LocalFocus: A Big Data Service Platform for Local Com-
munities and Smarter Cities
Pan et al. (2016) Urban Big Data and the Development of City Intelligence
An et al. (2017) An Urban Building Database (UBD) supporting a Smart
City Information System
Lim, Kim e Maglio (2018) Smart cities with big data: Reference models, challenges,
and considerations
Osman (2019) A novel big data analytics framework for smart cities
Abaker et al. (2016) The role of big data in smart city
Gerosa et al. (2017) Software Platforms for Smart Cities
Fonte: Produzido pelo autor
Dentre os supracitados no quadro 2 destaca-se a publicação de (GEROSA et al.,
2017), o qual descreve pesquisa sobre plataformas de software para smart cities sob quatro
categorias de análise: Cyber-security, IoT, Big Data e Cloud Computing. São identificados
pelos autores 23 iniciativas e comparadas. O resultado do estudo dos mesmos propõe a
arquitetura descrita na Figura 7.
Capítulo 2. Fundamentação Teórica 39
Figura 7 – Arquitetura de Referência para Smart Cities
Fonte: (GEROSA et al., 2017).
Na camada inferior da arquitetura está o componente nomeado Cloud e Networ-
king que é responsável pelo gerenciamento e comunicação da rede na cidade. Acima, há
a camada de gerenciamento de serviços englobando Service Middleware, IoT Mid-
dleware, Social Network Gateway e User Management. Um nível acima há a
camada de gerenciamento de Big Data, segregada pelo autor em três repositórios: App
repository que armazena os códigos fontes dos aplicativos, Model repository, responsá-
vel por armazenar os modelos, como modelo de dados, mapas e por fim Data repository
que armazena os dados. Na camada superior há os usuários com diferentes perfis. Comum
a todas as etapas e representado na coluna à direita da Figura 2 estão representadas as
ferramentas de desenvolvimento e os requisitos não-funcionais de segurança.
O estudo desta arquitetura fornece uma visão geral dos principais componentes
envolvidos no fluxo de dados em um contexto de smart cities, que é importante na
compreensão das funcionalidades necessárias e serve de base para comparação com os
objetos de estudo do ParticipAct, abordados no Capítulo IV.
Nessa seção, referente à Smart Cities, foram abordados conceitos, categorias de
problemas urbanos e arquitetura computacional. Conclui-se com estudos sobre arquiteturas
e modelos de referência de Big Data para Smart Cities, elo com o projeto ParticipAct e
portanto essencial para o desenvolvimento de um arquitetura de big data, objetivo deste
trabalho. Na próxima seção serão explorados as fontes de dados relevantes ao trabalho.
Capítulo 2. Fundamentação Teórica 40
2.3 Fontes de Dados
Como visto na Introdução e também na fundamentação teórica de Big Data, a
variedade é um dos grandes desafios enfrentados na análise de dados. Diferentes formatos
e diferentes fontes demandam estruturas flexíveis para a manipulação dos dados. Nessa
seção será abordada a principal fonte de dados em projeto de Big data, a nomear Dados
Abertos, e sua evolução histórica e legal.
2.3.1 Dados Abertos
Embora o contexto de Smart Cities apresente grande variedade de fontes de dados,
são os governos os maiores geradores de dados (JANSSEN, 2011). Nas bases de dados
do governo residem as informações mais relevantes dos cidadãos em diferentes domínios,
como energia, água, segurança pública, etc., que podem ser combinados com dispositivos
IoT e outros, como mídias sociais, possibilitando aplicação de técnicas de ciência de
dados (MATHEUS; JANSSEN; MAHESHWARI, 2018). Desta forma, precedendo o estudo
arquitetural, dedica-se essa seção ao estudo dos dados abertos, seu atual contexto e desafios
em sua utilização no estudo de problemas urbanos, objetivo do projeto ParticipAct Brasil.
A definição de Open Data, ou dados abertos, compreende três princípios funda-
mentais (OKF, 2020):
• Disponibilidade e acesso: Dado está disponível;
• Re-uso e distribuição: O dado pode ser reutilizado e compartilhado;
• Participação universal: Qualquer pessoa pode utilizar o dado.
Segundo Attard, esses princípios qualificam o dado como aberto, visando garantir
o seu livre uso, reuso e distribuição, sem discriminação de qualquer pessoa e restrição
quanto a finalidade (ATTARD et al., 2015). Quanto a publicação, deve ser em "plataforma
aberta, legível por máquina e disponibilizado ao público sem restrições queimpeçam o
reuso da informação"(HOUSE, 2019).
Na administração pública a abertura de dados segue o mesmo princípio mas com
os objetivos próprios de governo, de promover a transparência, participação, aprimorar a
governança e gerar valor social e comercial (DATA, 2019). Os dados abertos governamentais
são gerados em grandes quantidades e através de múltiplas fontes, carecendo, portanto, de
técnicas de Big Data para manipular e integrar essa massa de dados. A coleta, processa-
mento e distribuição é um desafio que envolve tecnologia, colaboração organizacional e
processos de gerenciamento de negócio. Para atender as demandas da crescente abertura
de dados, plataformas são desenvolvidos para habilitar a interoperabilidade e fornecer
Capítulo 2. Fundamentação Teórica 41
espaço no qual usuários possam utilizar os dados abertos e desenvolver soluções através do
cruzamento de informações antes isolados (ZUIDERWIJK; JANSSEN, 2014).
O Open Data teve a primeira legislação/regulação sobre o tema data da década de
1960 com FOIA(Freedom of Information Act), nos Estados Unidos. Em 2003, A EU(União
Europeia) lançou a diretiva PSI(Public Sector Information) baseada em dois princípios
gerais:
1. Habilitar os dados do setor público para serem disponibilizados a baixo custo e uso
irrestrito;
2. Garantir mesmo nível de acesso a todos os usuários.
Desta forma, a EU promovia a abertura de seus dados governamentais de forma
ampla e irrestrita, inclusive instruindo governos a não usar dados públicos em acordos
sigiliosos com empresas privadas que pudessem criar monopólios de informação. Em 2011,
a Comissão Europeia publica a primeira estratégia de dados abertos.
Em 2009, no Estados Unidos, o presidente Barack Obama, assina o "Memorandum
on Transparency and Open Government". Em 2011, a Administração Obama publica
memorando criando a Estratégia de Governo Digital, que visa fornecer aos cidadãos dados
do governo de forma digital para estimular a inovação e melhorar a qualidade dos serviços.
Em maio de 2013, nos EUA, é publicada novo memorando regulando a abertura de dados
históricos (Historic Open Data Rules to Enhance Government E�ciency and Fuel Economic
Growth) (JANSSEN; ZUIDERWIJK, 2014).
No Brasil, a abertura de dados foi regulamentada pela Lei de Acesso à Informação,
a Lei 12.527/2011 (BRASIL, 2011), que garante o acesso a qualquer pessoa física ou
jurídica o recebimento de informações públicas. Em 2016 foi instituída a Política de Dados
Abertos, através do Decreto n. 8.777/2016(BRASIL, 2016).
Uma das principais motivações para a abertura de dados é o potencial de auxiliar
gestores públicos na análise de problemas complexos (ARZBERGER et al., 2004), o
impacto na transparência e accountability e a criação de serviços inovadores promovendo
o crescimento econômico (ATTARD; ORLANDI; AUER, 2016). Contudo a avaliação
do efetivo valor gerado envolvem fatores de difícil mensuração e não há consenso sobre
como aferir os benefícios econômicos dos dados abertos governamentais (EIBL, 2013).
Segundo Janssen, o principal desafio em realizar o valor social e comercial dos dados
abertos, é por ele não tem valor nele mesmo e sim quando de fato utilizado (JANSSEN;
CHARALABIDIS; ZUIDERWIJK, 2012). Em relatório da McKinsey, é descrita estimativa
de valor econômico em escala global superior U$ 3 trilhões anuais. O valor considera
aumento de receita, economia de recursos e superafit econômico em sete domínios: financeiro,
varejista, educacional, elétrico, saúde, óleo e gás e transporte. Conclui ressaltando que
Capítulo 2. Fundamentação Teórica 42
o sucesso de programas de dados abertos não são garantidos e que o desafio está no
engajamento da comunidade no real uso dos dados disponibilizados (MCKINSEY, 2019).
Existem diversas ferramentas de avaliação dos dados abertos, sendo os mais refe-
renciados:
• Open Data Barometer7;
• Open Data Monitor 8;
• Open Data Inventory9;
• Open Data Institute 10.
O mais abrangente referenciado é o Open Data Index, que avalia o Brasil com um
índice de abertura de 68%, posicionado em oitavo lugar no ranking dos países avaliados.
O índice considera a disponibilidade e acessibilidade dos dados nas categorias: orçamento,
eleições, compras, níveis de poluição, dados de qualidade da água, propriedade de terras,
dados do clima, entre outros (OKF.BR, 2019).
Após a regulamentação legal, foi criado o portal de dados abertos, o DADOS.GOV.BR11,
como um catálogo federado, disponibilizando dados em 4 formatos CSV, XML, JSON,
facilmente manipulados por qualquer linguagem de programação, com a exceção de PDFs.
Porém a informação é atualizada via extrações, conforme cronogramas estabelecidos em
seus PDAs (Planos de Dados Abertos) e não em tempo real.
Em 2017, foi publicado estudo pela Diretoria de Análise de Políticas Públicas da
Fundação Getulio Vargas (FGV DAPP), com o objetivo de medir a abertura de dados nas
cidades brasileiras. A pontuação foi definida através do escore, que avalia a adequação dos
dados disponibilizados pelo governo aos critérios de transparência utilizados em diversos
países do mundo e através do “%open”, que calcula qual o percentual dos conjuntos de
dados avaliados que atende a todos os critérios da metodologia. Os resultados estão na
Figura 8.
7 http://opendatabarometer.org/
8 https://opendatamonitor.eu
9 https://odin.opendatawatch.com/
10 https://theodi.org/knowledge-opinion/reports/
11 http://dados.gov.br/
Capítulo 2. Fundamentação Teórica 43
Figura 8 – Pontuação das cidades no ODI
Fonte: (RUEDIGER M. A.; MAZOTTE, 2018).
A média geral entre as cidades foi de 65%, com resultados individuais variando
entre 43% e 84%. O estudo avaliou 17 dimensões. Das 136 bases de dados avaliadas
(17 por cidade, 8 cidades), 25% (ou 34) estavam plenamente abertas (RUEDIGER M.
A.; MAZOTTE, 2018).
Segundo o relatório, os resultados permitem constatar que há uma intenção dos
mecanismos governamentais de trazerem ao cidadão informações pertinentes à vida pública,
com a criação de portais de transparência aderentes à Lei de Acesso à Informação, tornando
os dados públicos. Contudo, ainda há muito a avançar no sentido desses dados públicos
se tornarem, de fato, abertos, além de desafios na qualidade dos dados, nos formatos
disponibilizados e na estabilidade dos sites governamentais. Durante o processo de pesquisa,
diversos sites utilizados apresentaram falhas ou estiveram fora do ar durante algumas
horas ou até mesmo dias (RUEDIGER M. A.; MAZOTTE, 2018).
Nesse sentido, a viabilização de uma plataforma para armazenamento e compar-
tilhamento de dados habilita o uso destes dados de maneira mais rápida e estruturada,
contribuindo para a geração de valor através dos dados que são de todos.
Nessa seção foram abordados os conceitos, barreiras e os índices de abertura dos
dados, o que sinaliza a dimensão do potencial a ser explorado com a aplicação de novas
tecnologias. Na próxima seção são descritos conceitos, métodos e modelos de arquitetura
de big data.
Capítulo 2. Fundamentação Teórica 44
2.4 Arquitetura de Sistemas de Informação
O termo arquitetura, inicialmente atribuído a projetos de construção, é hoje
amplamente utilizado em projetos de tecnologia de informação, não se limitando ao escopo
tecnológico das soluções. O conceito de arquitetura varia de acordo com as diferentes escolas
de pensamento, mas no contexto deste trabalho, entende-se a definição da ISO/IEC/IEEE
42010:2007 como a mais aderente: "arquitetura é a organização fundamental de um sistema
e seus componentes, seus relacionamentos entre si e com o ambiente, e o princípio guiando
sua construção e evolução"(ISO/IEC/IEEE, 2011).
Ainda, segundo a norma supracitada, as descrições de arquitetura são artefatos
usados pelos Stakeholders para criar, utilizar e gerenciar sistemas com o propósito de
aprimorar a comunicação e cooperação, habilitando-os para trabalhar de uma forma
conjunta e coerente. Os frameworks de arquitetura e as linguagens de descrição arquitetural
são classificados como representações que codificam as convenções