GoldBI: uma solução de Business Intelligence como serviço

Texto

(1)Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital Programa de Mestrado Profisional Mestrado Profisional em Engenharia de Software. GoldBI: Uma solução de Business Intelligence como serviço. Arlindo Rodrigues da Silva Neto. Natal-RN Agosto 2016.

(2) Arlindo Rodrigues da Silva Neto. ESIGBI: Uma solução de Business Intelligence como serviço. Defesa de Mestrado apresentada ao Programa Pós Graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software. Linha de pesquisa: Engenharia de Sistemas WEB. Orientador. Dr. Gleydson de Azevedo Ferreira Lima. IMD – Instituto Metrópole Digital UFRN – Universidade Federal do Rio Grande do Norte. Natal-RN Agosto 2016.

(3) Dissertação de Mestrado sob o título GoldBI: Uma solução de Business Intelligence como serviço apresentada por Arlindo Rodrigues da Silva Neto e aceita pelo Programa de Pós Graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:. Gleydson de Azevedo Ferreira Lima (Dr. UFRN, Orientador). Frederico Araujo Da Silva Lopes (Dr. UFRN, Examinador Interno). Francisco Dantas de Medeiros Neto (Dr. UERN, Examinador Externo). Natal-RN, 26 de Agosto de 2016..

(4) Agradecimentos Agradeço inicialmente a minha esposa, Samara Lourenço, por ter me apoiado a ingressar no mestrado, mesmo nos momentos difíceis. A minha sogra Marilú Lourenço, por ter sempre incentivado durante todo o processo. A minha mãe, pois investiu inicialmente nos meus estudos, ainda na minha adolescência, tornando viável minha paixão e curiosidade pela minha profissão atual. Ao meu orientador Gleydson Lima, por ter instruído durante toda a fase de elaboração do trabalho. A ESIG Software, patrocinadora do mestrado e a todos que contribuíram de alguma forma, seja direta ou indiretamente..

(5) GoldBI: Uma solução de Business Intelligence como serviço. Autor: Arlindo Rodrigues da Silva Neto Orientador(a): Dr. Gleydson de Azevedo Ferreira Lima. Resumo Este trabalho consiste em criar uma ferramenta de BI (Business Intelligence) disponível em nuvem (cloud computing) através de SaaS (Software as Service) utilizando técnicas de ETL (Extract, Transform, Load ) e tecnologias de Big Data, com a intenção de facilitar a extração descentralizada e o processamento de dados em grande quantidade. Atualmente, constata-se que é praticamente inviável realizar uma análise consistente sem o auxílio de um software para geração de relatórios e estatísticas. Para tais fins, a obtenção de resultados concretos com a tomada de decisão exige estratégias de análise de dados e variáveis consolidadas. Partindo dessa visão, enfatiza-se neste estudo o Business Intelligence (BI) com o objetivo de simplificar a análise de informações gerenciais e estatísticas para propiciar indicadores através de gráficos ou listagens dinâmicas de dados gerenciais. Assim, é possível inferir que, com o crescimento exponencial dos dados torna-se cada vez mais difícil a obtenção de resultados de forma rápida e consistente, tornando necessário atuar com novas técnicas e ferramentas para tratamentos de dados em larga escala. Este trabalho é de natureza técnica de criação de um produto de Engenharia de Software, fundamentado a partir do estudo da arte da área, e de um comparativo com as principais ferramentas existentes no mercado, evidenciando vantagens e desvantagens da solução criada. Palavras-chave: Business Intelligence, BI, Big Data, ETL, Map Reduce, Hadoop, Spark, SaaS, MongoDB..

(6) GoldBI - A Business Intelligence as a service solution. Author: Arlindo Rodrigues da Silva Neto Supervisor: Dr. Gleydson de Azevedo Ferreira Lima. Abstract This work is to create a BI tool (Business Intelligence) available in the cloud (cloud computing) through SaaS (Software as Service) using ETL techniques (extract, transform, load) and Big Data technologies, with the intention of facilitating decentralized extraction and data processing in large quantities. Currently, it appears that it is practically impossible conduct a consistent analysis without the aid of a software for reporting and statistics. For these purposes, the achievement of concrete results with decision making requires data analysis strategies and consolidated variable. From this view, it is emphasized in this study Business Intelligence (BI) in order to simplify the analysis of management information and statistics to provide indicators through graphs or dynamic lists of data management. Thus, it is possible to infer that with the exponential growth of data becomes increasingly difficult to obtain results quickly and consistently, making it necessary to work with new techniques and tools for large-scale data processing. This work is technical in nature to create a product of Software Engineering, based from the study of art in the area, and a comparison with the main existing tools on the market, showing advantages and disadvantages of the created solution. Keywords: Business Intelligence, Big Data, ETL, Map Reduce, Hadoop, Spark, SaaS, MongoDB..

(7) Lista de figuras 1. Modelo arquitetural de um Data Warehouse (TURBAN E., 2009) . . . .. p. 17. 2. Ferramentas que apoiam o BI (LOPES, 2008) . . . . . . . . . . . . . . .. p. 18. 3. Processo de Criação de um BI. (SENIOR, 2012) . . . . . . . . . . . . . .. p. 19. 4. Quadrante mágico (Fev 2016) (GARTNER, 2016) . . . . . . . . . . . . .. p. 20. 5. Comparativo Tableau x Qlikview (PRAOTICAL, 2011) . . . . . . . . . .. p. 21. 6. Exemplificação do fluxo do MapReduce (SPADOTTO, 2013) . . . . . . .. p. 28. 7. Comparativo do BIG Data (INVESTOR, 2014) . . . . . . . . . . . . . .. p. 30. 8. Exemplos de bancos de dados NoSQL: Cassandra, MongoDB, HBase (ALECRIM, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 31. 9. Arquitetura do HDFS (HANSON, 2013) . . . . . . . . . . . . . . . . . .. p. 32. 10. Ecossistema do Hadoop (SESHACHALA, 2015) . . . . . . . . . . . . . .. p. 33. 11. Arquitetura do Spark (PENCHIKALA, 2015) . . . . . . . . . . . . . . . .. p. 34. 12. Comparativo do movimento dos dados no Hadoop e Spark (HEMSOTH, 2015) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13. p. 35. Modelo Relacional x Modelo de Documento (MongoDB) (STANNARD, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 37. 14. Comparativo: Cassandra x HBase x MongoDB (SVERCHKOV, 2014) . .. p. 41. 15. Organização dos projetos Admin e Extract . . . . . . . . . . . . . . . .. p. 47. 16. Divisão do projeto baseado no ETL.. . . . . . . . . . . . . . . . . . . .. p. 48. 17. Base da arquitetura do Spring Boot. (LOBO, 2015) . . . . . . . . . . . .. p. 49. 18. Modelo da implementação do cálculo utilizando o padrão Strategy. . . .. p. 51. 19. Modelo da implementação dos elementos utilizando o padrão Strategy.. p. 51.

(8) 20. Fluxo proposto com base nas tecnologias utilizadas . . . . . . . . . . .. p. 52. 21. GoldBi Extract (Tela principal) . . . . . . . . . . . . . . . . . . . . . .. p. 53. 22. GoldBi Extract (Cadastro de Fonte de Dados) . . . . . . . . . . . . . .. p. 53. 23. GoldBi Extract (Cadastro de Documentos) . . . . . . . . . . . . . . . .. p. 54. 24. GoldBi Extract (Configurar Servidor) . . . . . . . . . . . . . . . . . . .. p. 54. 25. GoldBi Admin (Tela Principal) . . . . . . . . . . . . . . . . . . . . . .. p. 55. 26. GoldBi Admin (Cadastro de Modelo de Dados) . . . . . . . . . . . . .. p. 56. 27. GoldBi Admin (Cadastro de Dashboard) . . . . . . . . . . . . . . . . .. p. 57. 28. GoldBi Admin (Adicionar Coluna ao Elemento) . . . . . . . . . . . . .. p. 58. 29. GoldBi Admin (Adicionar Condição ao Elemento) . . . . . . . . . . . .. p. 59. 30. GoldBi Admin (Listagem de Dashboards cadastrados) . . . . . . . . . .. p. 59. 31. GoldBi Extract (Cadastro de Documentos) . . . . . . . . . . . . . . . .. p. 60. 32. GoldBi Extrator: Documentos cadastrados para prova de conceito . . .. p. 61. 33. QlikView: Configuração para extração dos dados . . . . . . . . . . . . .. p. 61. 34. GoldBi Admin: Modelo de dados do SIGFundação . . . . . . . . . . . .. p. 63. 35. GoldBi Admin: Cadastro de Dashboard do SIGFundação . . . . . . . .. p. 64. 36. GoldBi Admin (Dashboard do SIGFundação) . . . . . . . . . . . . . . .. p. 65. 37. QlikView: Dashboard do SIGFundação . . . . . . . . . . . . . . . . . .. p. 65. 38. GoldBi Admin: (Definição do Modelo do SIGAA) . . . . . . . . . . . .. p. 66. 39. GoldBi Admin: (Cadastro do Dashboard do SIGAA) . . . . . . . . . . .. p. 67. 40. QlikView: Configuração do SIGAA . . . . . . . . . . . . . . . . . . . .. p. 67. 41. GoldBi Admin: (Dashboard do SIGAA) . . . . . . . . . . . . . . . . . .. p. 68. 42. QlikView: Dashboard do SIGAA . . . . . . . . . . . . . . . . . . . . . .. p. 69. 43. Análise comparativa GoldBI x QlikView . . . . . . . . . . . . . . . . .. p. 69.

(9) Lista de tabelas 1. Ferramentas analisadas . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 23. 2. Comparativo entre componentes gráficos . . . . . . . . . . . . . . . . .. p. 44.

(10) Sumário. 1 Introdução. p. 11. 1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 12. 1.2. Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 13. 1.3. Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 13. 1.4. Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 13. 1.5. Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 14. 2 Referencial Teórico 2.1. 2.2. p. 16. Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 16. 2.1.1. Classificação de Ferramentas de BI . . . . . . . . . . . . . . . .. p. 19. 2.1.2. Técnicas de BI . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 2.1.3. Data warehousing . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 2.1.4. ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 26. Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 29. 2.2.1. Apache Hadoop (HDFS) . . . . . . . . . . . . . . . . . . . . . .. p. 31. 2.2.2. Apache Spark . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 34. 2.2.3. MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 36. 3 Problemas de Pesquisa. p. 39. 4 GoldBI. p. 46. 4.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 46. 4.2. Organização do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 46.

(11) 4.3. Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 48. 4.4. O Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 50. 4.5. A ferramenta (GoldBI) . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 52. 5 Validação da Ferramenta. p. 60. 5.1. SIGFundação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 62. 5.2. SIGAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 66. 5.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 69. 6 Considerações Finais 6.1. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Referências. p. 71 p. 72 p. 73.

(12) 11. 1. Introdução. O processo de tomada de decisão deve ser amparado por informações precisas e que estejam disponíveis rapidamente. Para obter tal objetivo as organizações podem contar com soluções de Business Inteligence (BI). O BI apresenta dados gerenciais consolidados baseado em coleta de informações de áreas operacionais da organização (DALFOVO, 2008). A análise estratégica dos dados vem se tornando cada vez mais importante no mercado, uma vez que podem subsidiar decisões gerenciais a partir da tomada de decisões bem fundamentadas, para qualquer porte de organização. Nesse contexto, as soluções de BI têm conquistado cada vez mais importância. Segundo Turban (TURBAN E., 2009), o principal benefício do BI para uma organização é sua capacidade de fornecer informações precisas quando necessário, incluindo uma visão em tempo real do desempenho corporativo geral e de suas partes individuais. Tais informações representam uma necessidade para todos os tipos de decisões, para o planejamento estratégico ou mesmo para a sobrevivência. Em uma pesquisa realizada entre 510 corporações obteve-se os seguintes resultados como benefícios apontados na utilização de BI: economia de tempo, versão única da verdade, melhores estratégias e planos, melhores decisões táticas, processos mais eficientes e por fim, economia de custos. Muitos destes benefícios citados são intangíveis, é por isso que, tantos executivos não insistirem em uma justificativa de custos rigorosa para os projetos de BI (ECKERSON, 2003). Turban (TURBAN E., 2009) reforça que as áreas mais comuns de aplicação do BI são: relatórios gerais, análise de vendas e marketing, planejamento e previsão, consolidação financeira, relatórios regulamentares, orçamento e análise de rentabilidade. Um dos principais problemas levantados em diversas discussões sobre BI é se estamos com tecnologia capaz de enfrentar gigantescos repositórios de informações, buscando cada vez mais rapidamente um volume maciço de dados, isto por que a todo momento são armazenados grande quantidade de dados em todo os âmbitos, sejam por pessoas, empresas e também grandes indústrias. Tal problema aumenta de complexidade se considerarmos que a ferramenta a ser desenvolvida titulada de GoldBI, se propõe a armazenar e pro-.

(13) 12. cessar dados de diversos clientes em ambiente de nuvem. Em sistemas de software de BI tradicionais, cada empresa utiliza o seu data center para computação dos dados, dividindo assim o problema da complexidade do processamento. O GoldBI, por sua vez, se propõe a processar grande quantidade de dados de um número indeterminado de clientes. Para enfrentar este problema é preciso utilizar tecnologias de Big Data. O Big Data, termo usado para processamento de grandes volumes de dados, vem se tornando cada vez mais comum para resolver questões de análise e processamento de grande quantidade dados. A adoção destas tecnologias em projetos de BI torna-se um diferencial sob aqueles que ainda não o adotaram ou não se prepararam para o crescimento exponencial dos dados (BARBIERI, 2001). Existem diversas ferramentas de BI disponíveis no mercado. A proposta desta dissertação não representa uma solução inédita, no entanto, em termos de projeto, será focado nos pontos negativos de cada solução existente, assim centralizando em uma única ferramenta os pontos fortes dos quais não contemplam nas demais, tornado-se mais atrativa frente aos concorrentes. Este projeto propõe criar uma ferramenta BI que seja disponível em nuvem (SaS – Software as Service). Além disso, simples o suficiente, para que qualquer usuário possa manipula-lo, de forma eficaz e objetiva. Utilizando técnicas de ETL robustas, que facilitará a extração e processamento de grande volume de dados (Big Data), de forma que como resultado uma aplicação intuitiva e eficaz. O fato da ferramenta está disponível em ambiente de nuvem e os dados acessíveis nas redes privadas dos clientes é um desafio para um ETL descentralizado, onde o Extract ocorre na rede do cliente e o Transform e Load na nuvem computacional do GoldBI.. 1.1. Objetivo. O objetivo desse trabalho consiste em desenvolver uma ferramenta de BI (Bussiness Intelligence) que seja disponível na plataforma web (ambiente de nuvem) de fácil manuseio e que proporcione maior produtividade ao usuário final. Em termos de desafios de pesquisa deverá utilizar técnicas de ETL em redes descentralizadas e que permita o processamento de grande quantidade de dados, e de diversos clientes..

(14) 13. 1.2. Motivação. A motivação deste trabalho é a criação de um novo produto para o portfólio da empresa ESIG Software e Consultoria em Tecnologia da Informação e que possa resolver de forma eficiente problemas de pesquisa durante sua construção gerando um produto de nível industrial. O produto em questão agregará o portfólio da empresa possibilitando que os seus diversos sistemas que se focam na visão operacional possam ser complementados com uma ferramenta na visão gerencial. Ou seja, o GoldBI agrega valor a todos os produtos de gestão da empresa bem como permitirá integração com estes produtos.. 1.3. Metodologia. Para o desenvolvimento deste trabalho foi necessário realizar uma pesquisa sobre o estado da arte de Business Intelligence (BI) e também fazer um levantamento das principais ferramentas existentes no mercado, evidenciando quais suas vantagens e desvantagens, podendo assim ter uma visual geral da necessidade do mercado atual. Além disso, foi realizado um estudo das principais técnicas de extração e transformação de dados, tais como ETL, Map Reduce e Data Warehouse, e também quais tecnologias utilizadas para realizar estas operações. Para fins de escolha da arquitetura tecnológica da ferramenta foram realizados testes de desempenho e provas de conceito em alguns bancos de dados e tecnologias disponíveis no mercado. A partir da análise de critérios de performance e facilidade de carregamento e tratamento foi possível identificar quais ferramentas mais apropriadas para a aplicação, bem como as tecnologias de visualização, bibliotecas e frameworks relacionados.. 1.4. Questões de Pesquisa. A criação de um software de Business Intelligence por si só não é uma tarefa simples. A prova desta afirmação é que existem poucos fornecedores no país, sendo a maioria dos produtos de grandes empresas de TI multinacionais. A complexidade do produto tornouse ainda mais evidente com o requisito de Software as Service (SaaS), ou seja, uma visão única de serviço atendendo a diversos clientes e consequentemente tendo que tratar de forma eficiente os dados de todos eles. O primeiro desafio a se destacar é a extração das.

(15) 14. informações em redes distintas, já que a ferramenta proposta estará disponível em nuvem (rede pública) e que não possui a acesso direto a rede privada do cliente. Outra questão é a forma de armazenamento dos dados extraídos, pois tratam-se de grande quantidade de dados e com leitura e escrita concorrentes. Também deve-se levar em consideração a complexidade do tratamento e computação de grande quantidade de dados, para que ocorra em termos aceitáveis e não onere a performance da aplicação e por fim a exibição dos dados computados em dashboards com interfaces ricas e que devam ser passíveis de exibição em qualquer tipo de dispositivo, proporcionando uma maior interação com o usuário. Desta forma, elencou-se um conjunto de questões de pesquisas que representam os principais desafios de pesquisa enfrentados neste trabalho. São elas: • QP1: Como viabilizar que a ferramenta esteja em nuvem e ao mesmo tempo extraia as informações em outros bancos de dados em redes privadas? • QP2: Como enviar grande quantidade de dados da rede da organização para a plataforma em nuvem? • QP3: Qual solução de banco de dados utilizar para armazenar os dados antes e depois de serem calculados? • QP4: Qual estratégia de transformação de dados? • QP5: Quais técnicas e ferramentas de otimização são necessárias para tratar grandes quantidades de dados? • QP6: Quais componentes de geração de gráficos deve-se utilizar para exibição de dashboards? Estas questões serão abordadas ao longo do trabalho e detalhadas no Capítulo 6.. 1.5. Estrutura do Documento. Este trabalho está organizado da seguinte forma: O Capítulo 2 aborda os conceitos de todo referencial teórico levantado durante a elaboração do projeto, desde ferramentas que apoiam o uso massivo do BI, técnicas utilizadas para utilização do BI, e também conceitos de Big Data como também as ferramentas.

(16) 15. disponíveis para computação de dados em larga escala, tais como o Hadoop e Apache Spark; O Capítulo 3 detalha as questões de pesquisa e como cada uma foi resolvida afim de atingir o objetivo específico do presente trabalho; No Capítulo 4 descreve as funcionalidades da ferramenta proposta (GoldBi), exemplificando algumas funcionalidades e sua arquitetura; O Capítulo 5 são expostos alguns experimentos realizados com a ferramenta proposta com o objetivo de prova de conceito para validação da ferramenta; E por fim, o Capítulos 6, que trata-se respectivamente das considerações finais e referências adotadas no presente trabalho..

(17) 16. 2. Referencial Teórico. Para melhor compreensão do conceito de BI é importante analisar a tradução literal e o significado do termo, que representa Business (negócio) e Intelligence (inteligência). O termo negócio refere-se a qualquer tipo de personalidade jurídica, seja ela uma empresa, uma instituição pública, uma escola, ou seja, qualquer tipo de organização. Já a palavra inteligência significa: faculdade de entender, raciocinar, interpretar (JúNIOR, 2007). Ou seja, um BI existe para interpretar, entender, analisar a organização. Antes de aprofundar no processo de BI é preciso entender alguns conceitos importantes, como Data Warehouse, Data Mart, ETL, Data Mining, e como eles são utilizados dentro de um contexto de um BI.. 2.1. Business Intelligence. O conceito de BI (Business Intelligence), de forma mais ampla, pode ser entendido como a utilização de variadas fontes de informação para definir estratégias de competitividade nos negócios da empresa. Podem ser incluídos nessa definição os conceitos de estruturas de dados - representadas pelos bancos de dados tradicionais, data warehouse e data marts - criadas objetivando o tratamento relacional e dimensional de informações. Já as técnicas de data mining são aplicadas sobre estas estruturas de dados buscando correlações e fatos "escondidos". Data warehouse nada mais é que um repositório central de dados históricos, organizado de forma que o acesso seja fácil (usando um navegador da Web, por exemplo) e a manipulação para o suporte a decisões seja conveniente, podendo ser constituído por diversos data marts. O data mart é um subconjunto de um data warehouse, que normalmente consiste a uma única área temática (p. ex., vendas, clientes). Resumindo, um data warehouse une bancos de dados de toda uma empresa, já um data mart normalmente é menor e se concentra em um assunto ou departamento específico. São de fato, os principais componentes de uma estrutura de BI, pois classificaram os dados em outros repositórios.

(18) 17. de rápido acesso e com uma finalidade estratégica. Para Turban (TURBAN E., 2009), data mining é uma classe de análise de informações, baseada em bancos de dados, a qual procura padrões ocultos em uma coleção de dados que podem ser usados para prever comportamentos futuros. As ferramentas de data mining são usadas para substituir ou aprimorar a inteligência humana devido à sua capacidade de verificar enormes repositórios de dados. Desta forma, elas descobrem novas e significativas correlações, padrões e tendências através de tecnologias de reconhecimento de padrões e métodos estatísticos avançados. A Figura 1 mostra a arquitetura para construção de um data warehouse, englobando os três conceitos (data warehouse, data mart e data mining). É possível identificar que a partir da extração das informações através de uma, ou várias, fonte de dados, pode-se criar uma nova fonte de dados (data warehouse), porém, com dados significativos e classificados por tema (data marts).. Figura 1: Modelo arquitetural de um Data Warehouse (TURBAN E., 2009). Business Intelligence é uma estratégia em constante evolução que deve estar sempre.

(19) 18. alinhada aos interesses da organização e caminhando em direção ao alcance das metas estabelecidas ou do seu planejamento estratégico. Para que se tenha sucesso na implantação de um projeto de BI alguns pontos da infraestrutura tecnológica devem ser considerados: (i) a construção de um repositório especifico de dados, como um data warehouse ou data mart e (ii) a definição das ferramentas a serem utilizadas, tais ferramentas de ETL (Extract, Transform and Load ) e (iii) as ferramentas de carregamento de dados, Data Mining, Query Reporting, dentre outras (LOPES, 2008). Na Figura 2 pode-se perceber a interdependência das ferramentas que apoiam o BI.. Figura 2: Ferramentas que apoiam o BI (LOPES, 2008). Segundo Lopes (LOPES, 2008) o fator fundamental é a empresa saber direcionar seu capital intelectual para que o projeto de BI atenda às expectativas. Gerentes, diretores e profissionais de diferentes departamentos poderão ter acesso às informações rapidamente e abreviarão o tempo de resposta, contribuindo para a melhoria dos processos e para a correta análise dos dados. Assim a informação trará conhecimento que permita obter conhecimento, novas práticas comerciais, melhores maneiras de relacionamento com os clientes, novas formas de sobrevivência, enfim usar inteligência nas tomadas de decisão, nos fechamentos de negócios e no planejamento de estratégias. De acordo com Barbieri (BARBIERI, 2001) para resumir o conceito de BI - Business Intelligence, de forma mais ampla, pode ser entendido como a utilização de variadas fontes de informação para se definir estratégias de competitividade nos negócios da empresa. Na.

(20) 19. Figura 3 é possível exemplificar o processo de criação de um BI. A figura ilustra um processo composto por 3 etapas. A fonte de dados é origem da informação, obtida através de diversos meios tais como arquivos de texto, bancos de dados, planilhas eletrônicas, dentre outros meios. A segunda etapa é o ETL, que é etapa fundamental para formação do BI, será nesta etapa onde serão extraídas as informações relevantes e transformadas para formatos consistentes, conforme a necessidade do usuário, e armazenados em data warehouses, subdivididos por data marts, conforme a área fim. Por fim, são carregados em ferramentas de análise, como gráficos, tabelas, dashboards, etc.. Figura 3: Processo de Criação de um BI. (SENIOR, 2012). 2.1.1. Classificação de Ferramentas de BI. As ferramentas para um ambiente de Business Intelligence podem ser classificadas como de (i) Construção, (ii) Gerência, (iii) Uso e Armazenamento. As ferramentas de construção (i) têm o objetivo de auxiliar no processo de Extração de dados das fontes diversas, seu tratamento de preparação, transformação e sua carga nas estruturas finais do DW (data warehouse)/DM(data mart). As ferramentas de Gerência (ii) objetivam auxiliar o processo de armazenamento e utilização dos DW/DM e do repositório, onde residem as informações de meta-dados, responsáveis pela definição das estruturas e dos processos de transformação desejados. As ferramentas de uso e armazenamento (iii) são mecanismos através dos quais os usuários manipulam os dados nos DW/DM e obtém as informações requeridas, elas oferecem um conjunto de operadores, dentre os quais podemos destacar: drill-down (aumentar o nível de detalhes da informação), up (diminui o nível de detalhes da informação), cross (salta um nível intermediário da dimensão), through (altera a dimensão) e trabalham em interfaces web..

(21) 20. Existem diversas ferramentas de BI existentes no mercado responsáveis pela interface que o usuário final terá com as informações armazenadas na estrutura de data warehouse. De certa forma, ela pode ser considerada a vitrine que o analista de negócios ou usuário gestor terá com a ferramenta de BI, por isso a grande importância da ferramenta dentro da solução como um todo, principalmente na estratégia de marketing e comercialização. O Gartner Group avalia constantemente a adesão de todas as ferramentas de BI no mercado e as classifica através de um ranking denominado quadrante mágico. A Figura 4 ilustra este ranking divulgado para o ano de 2016.. Figura 4: Quadrante mágico (Fev 2016) (GARTNER, 2016). O "Quadrante Mágico"da Gartner, exemplificado na Figura 4, é uma representação gráfica onde mensura a qualidade das ferramentas disponíveis do mercado em um determinado período. O quadrante possui dois eixos, no eixo X (horizontal) temos a abrangência da visão da empresa em relação a tecnologia. Já no eixo Y (vertical) temos a capacidade de executar o que se propõem. Cada um dos eixos geram quatro quadrantes, o Challengers, que são empresas com boa capacidade de execução mas que não agrega tanto em inovação, o Leaders, são os líderes, quem possuem boa inovação e entregam o que prometem, o Niche Players, são empresas de nichos de mercado, não possuem grande expressão no mercado geral como um todo e comumente possuem produtos específicos, e por fim.

(22) 21. o Visionaries, que possuem extrema inovação, mas não possuem tanta capacidade para entregar o que prometem. Resumindo, quanto mais a direita e acima, melhor posicionada está a empresa no quadrante. Diante deste resultado do "Quadrante Mágico", foram analisadas as principais ferramentas Leaders, e mais utilizadas disponíveis no mercado, assim, pode-se obter e identificar alguns fatores para contribuir com a elaboração do trabalho e também para garantir o prosseguimento do projeto. Para fins de análise comparativa identificou-se duas soluções consagradas no mercado, a Tableau e o Qlikview. O Tableau é um software de business intelligence que permite a qualquer pessoa se conectar aos dados com apenas alguns cliques e, em seguida, visualizar e criar dashboards interativos e compartilháveis com apenas mais alguns cliques, o Qlikview segue a mesma linha e é um dos principais concorrentes do Tableau. Na Figura 5 abaixo compara os dois produtos em uma série de aspectos.. Figura 5: Comparativo Tableau x Qlikview (PRAOTICAL, 2011). Pode-se perceber que em linhas gerais que o Tableau sai na frente nos itens compara-.

(23) 22. dos, por ter um menor custo e possuir uma boa plataforma web e mobile, em contrapartida o QlikView, tem ótimas avaliações nos critérios de visualização, por ter maior domínio e um tempo maior no mercado, porém precisando melhorar no cliente web. A análise destes comparativos é importante para que o produto a ser construído busque as principais qualidades destas ferramentas, bem como atentar-se as suas falhas para obter um melhor resultado. Na Tabela 1 pode-se visualizar os pontos comparados de cada ferramenta analisada..

(24) 23. Tabela 1: Ferramentas analisadas Nome. Origem. Custo. Características Pontos Positivos: Opensource, desenvolvido em Java, fácil integração com,diferentes fontes de dados;. Pentaho. EUA. http://www.pentaho.com. Free (com imitações). capacidade de usar APIs, serviços web, Multi-plataforma. Pontos Negativos: Necessidade de conhecimento técnico elevado para tilização. Maior parte da aplicação é desktop; Pontos positivos: Boa performance e suporte à grandes volumes de dados, alto nível de satisfação dos clientes quanto à qualidade. Microstrategy. EUA. https://www.microstrategy.com. US$ 600,00. e funcionalidades do produto;. por usuário. Pontos negativos: Dificuldade de uso; algumas funcionalidades são complexas; Baixa qualidade nos componentes. Custo do software: custo por usuário acima da média. Pontos positivos: Ferramenta totalmente web, desenvolvida por empresa brasileira, bom desempenho (com pouca quantidade de dados).. Atom BI. Brasil. Indisponível. http://www.atomsail.com. Pontos negativos: Algumas funcionalidades incompletas, apresentou lentidão e falhas ao carregar dashboard com grande quantidade de dados. Além de pouca documentação. Pontos Positivos: Em comparação as concorrentes, a ferramenta suporta o maior número usuários, o maior volume de dados,. Oracle BI https://www.oracle.com /solutions/business-analytics. EUA. US$1.200,00 por usuário. a mais ampla variedade de funcionalidades e a maior capacidade de carga de trabalho analítica. Pontos Negativos: Falta de inovação no que envolve dispositivos móveis, memória interna e visualização interativa;.

(25) 24. Após análise comparativa entre as ferramentas detalhadas na Tabela 1, foi possível perceber que as melhores ferramentas, Microstrategy e Oracle BI, possuem um alto custo por usuário, tornando bastante inviável para pequenas e médias empresas. O Pentaho apesar de possuir uma opção gratuita, é bem limitada e também possui grande parte das funcionalidades disponíveis apenas em aplicações desktop, que prejudica acesso do usuário. A única ferramenta brasileira analisada foi o Atom BI, que possui uma proposta de SaaS, porém deixa a desejar quando se trata de Big Data. Diante disso fica evidente que o mercado mundial possui boas soluções de BI, porém a grande maioria torna estas soluções bem inacessíveis para o mercado brasileiro, e também algumas delas não atendendo ainda o crescimento dos dados e também a portabilidade.. 2.1.2. Técnicas de BI. Um sistema de BI possui quatro grandes componentes: (i) Data warehouse, (ii) Análise de Negócios, (iii) Gestão do desempenho do Negócio e (iv) interface com o usuário (TURBAN E., 2009). O data warehouse (DW) é o banco ou repositório especial preparado para dar suporte as aplicações de tomada de decisão. A análise de negócios corresponde a uma coleção de ferramentas para manipular e analisar os dados no DW, incluindo processamento analítico, multidimensionalidade, mineração de dados e técnicas de análise avançada. A gestão de desempenho e interface com usuário está diretamente ligado a análise estratégica da empresa, onde serão analisados os dados extraídos de forma que seja possível qualquer tomada de decisão numa corporação. A seguir serão detalhadas as técnicas de Data Warahouse e ETL, que serão essenciais para compor a base estrutural da ferramenta proposta neste trabalho.. 2.1.3. Data warehousing. A elaboração de um ambiente de BI necessita de dados de diversas fontes de dados existentes na empresa. Todos os dados coletados é matéria-prima para uma série de transformações, cujo produto final é armazenado no Data Warehouse. Barry Devlin e Paul Murphy, em 1988, definiram os conceitos usados até hoje nos sistemas de Data Warehouse (DW). Segundo eles DW é um local único de armazenamento lógico de toda a informação utilizada para extrair relatórios sobre um determinado negócio. Inmon (INMON, 1990) por sua vez, contribuiu com sua definição dizendo que o DW é uma coleção de dados que suporta decisões gerenciais e que possui as seguintes características:.

(26) 25. 1. Orientado a Assuntos: Todas as entidades e eventos estão relacionadas a determinado assunto, por exemplo, vendas; 2. Variante com o Tempo: Todas as mudanças nos dados são guardadas para permitir relatórios que mostram mudanças ao longo do tempo; 3. Não volátil: Os dados que entram em um DW nunca são sobrepostos ou eliminados (apenas no caso de falhas); 4. Integrado: contém dado de múltiplas fontes de dados depois de serem limpos e padronizados, mostrando uma visão única sobre determinado assunto "Single version of the truth". Um data warehouse (DW) é um conjunto de dados produzido para oferecer suporte à tomada de decisões. Ele é um repositório de dados atuais e históricos de possível interesse aos gestores de toda a organização. Os dados, normalmente, são estruturados de modo a estarem disponíveis em um formato pronto para atividades de processamento analítico (processamento analítico online, mineração de dados, consultas, geração de relatórios, outras aplicações de suporte à decisão). Portanto, um DW é uma coleção de dados orientada por assunto, integrada, variável no tempo e não-volátil, que proporciona suporte ao processo de tomada de decisões da gerência (LARSON B. E AGARWAL, 2006). Os tomadores de decisão necessitam de informações concisas e confiáveis, sobre operações atuais, tendências e mudanças. As informações de interesse para a empresa são constantemente fragmentadas com o uso de diferentes sistemas operacionais e fontes externas, e assim os gestores tomam decisões com informações parciais, na melhor das hipóteses. O DW supera este obstáculo acessando, integrando e organizando os principais dados operacionais de uma forma consistente, confiável e prontamente disponível, onde for necessário (TURBAN E., 2009). Um data warehouse une bancos de dados de toda uma empresa. Já um Data Mart (DM), normalmente é menor e se concentra em um assunto ou departamento específico. Um Data Mart é um subconjunto de um DW, que normalmente consiste em uma única área temática (ex.: marketing, vendas, operações). Um grande objetivo do DW é integrar dados de múltiplos sistemas. A integração de dados compreende três grandes processos que, quando implementados corretamente, permitem que eles sejam disponibilizados a um conjunto de ferramentas de Extração, Transformação e Carga (ETL), análise e ao ambiente de data warehousing (LANGIT, 2008)..

(27) 26. Já os processos compreendem: (i) acesso aos dados (a capacidade de acessar e extrair dados de qualquer fonte), (ii) federação de dados (a integração das visualizações de negócios em diversos data stores) e (iii) captura de alterações (com base na identificação, captura e entrega das alterações feitas nas fontes de dados da empresa). Existem diversas arquiteturas específicas para um DW. Bouman e Dongen (BOUMAN R.; DONGEN,. 2010) apresentam uma arquitetura genérica explicando cada um de seus. componentes. Estas etapas são detalhadas da seguinte forma (Figura 1): Fonte de dados: Uma ou mais fontes de dados provenientes de diferentes sistemas dentro da empresa; PROCESSO DE ETL: Um processo para extrair, transformar e carregar os dados no DW denominado ETL (Extract, Transform, Loading); Data Warehouse: Composto pelo DW, que consiste em um banco de dados central e zero ou mais Data Marts. Data Marts, segundo Inmon (1990), são um subconjunto de dados presentes no DW que foram modelados de forma a atender as necessidades analíticas de uma determinada área de negócio, por exemplo, vendas; Apresentação: Uma camada composta de várias ferramentas para trabalhar com os dados e exibi-los ao usuário final. Extraindo os dados diretamente do DW. Este tópico, entretanto, estará fora do escopo deste trabalho.. 2.1.4. ETL. O ETL (extração, transformação e carga) é considerado o núcleo tecnológico do processo de data warehousing. Durante esta etapa são definidos os processos necessários para transformar o modelo fonte em um modelo Dimensional (BARBIERI, 2001). Esta etapa é um grande desafio para os gestores de TI, pois os processos de ETL costumam consumir cerca de 70% do tempo de um projeto (TURBAN E., 2009). Para migrar os dados para o DM, o primeiro passo é realizar a extração dos dados fontes, o principal objetivo desta etapa é extrair somente aqueles dados dos sistemas transacionais que serão necessários e prepará-los para as seguintes etapas do processo ETL (CANO, 2007). O ETL é extremamente importante na integração de dados e também no DW, pois seu objetivo é carregar dados integrados e limpos. Os dados usados nestes processos podem ser oriundos de qualquer fonte: uma aplicação de mainframe, uma aplicação ERP (Enterprise Resource Planning), uma ferramenta de CRM (Relationship Management), um arquivo.

(28) 27. texto, uma planilha do Excel ou até uma fila de mensagens (TURLEY P., 2007). O processo de ETL é um componente essencial de qualquer projeto centrado em dados. Langit (LANGIT, 2008) classifica o processo em três etapas: (i) extração, com leitura de uma ou mais fontes de dados; (ii) transformação, onde dados anteriormente extraídos são convertidos na forma em que precisam estar, para que sejam colocados em um DW ou em um banco de dados; (iii) e carga dos dados no DW. É comum que as organizações possuam sistemas transacionais desenvolvidos por diferentes equipes e, que no seu desenvolvimento, tenham adotado diferentes convenções na codificação de variáveis, nomes dos atributos das tabelas, diferentes tipos de dados ou formatos de datas. Ao extrair os dados dos diferentes sistemas, deve ser definido um formato único para o DW e realizar as transformações necessárias em cada caso (TURLEY P.,. 2007). Uma técnica muito utilizada no processo de ETL é o MapReduce, que é um modelo de. programação paralela criada pelo Google, que é utilizada para processamento de grandes volumes de dados. Tem como seu principal objetivo facilitar o desenvolvimento de aplicativos com este perfil. O MapReduce foi inspirado nas primitivas Map e Reduce presentes em algumas linguagens funcionais como Lisp e Haskell. Esta abordagem foi adotada pois verificou-se que, em muitos casos, era necessário mapear fragmentos dos dados de entrada a uma chave identificadora, e então processar todos os fragmentos que compartilhassem a mesma chave (DEAN, 2008). Na Figura 6 é possível exemplificar o fluxo do MapReduce. É possível notar que o fluxo exemplificado na Figura 6, que os dados de entrada são inseridos de forma aleatória e desordenada, o processo de Map os dados são inseridos em uma chave, e ordenados, assim sendo possível "catalogar"todas as incidências do valor informado. No próximo passo, o Reduce, serão agrupados os valores através da chave, assim sendo possível "reduzir"os dados em um único valor..

(29) 28. Figura 6: Exemplificação do fluxo do MapReduce (SPADOTTO, 2013). Este capítulo apresentou uma introdução do BI, além comparativos entre ferramentas disponíveis no mercado. A seção 2.2 abordou também as principais técnicas utilizadas no BI, tais como: Data warehouse, ETL e MapReduce, que servirão como norteamento para o desenvolvimento do referido trabalho. O próximo Capítulo (Capítulo 3 – Big Data) explora os temas relacionados como processamento de grande quantidade de dados e ferramentas quem foram investigados e utilizados neste trabalho..

(30) 29. 2.2. Big Data. Com grandes quantidades de dados disponíveis, empresas de diversos setores estão focadas na exploração de dados para obterem vantagem competitiva. O volume e a variedade de dados têm ultrapassado muito além da capacidade de análise manual, e em alguns casos excedeu a capacidade dos bancos de dados convencionais. Ao mesmo tempo, os computadores tornaram-se muito mais poderosos e algoritmos desenvolvidos que podem se conectar à um conjunto de dados, permitindo análises mais amplas e mais profundas em comparação como era antigamente (PROVOST, 2013). Quando pensamos em Big Data, é comum fazer uma tradução literária do texto e imaginar "Grandes Dados". Mas o termo é um pouco mais abrangente, Big Data é um termo utilizado para descrever grandes volumes de dados e que ganha cada vez mais relevância, à medida que a sociedade se depara com um aumento sem precedentes no número de informações geradas a cada dia. As dificuldades em armazenar, analisar e utilizar grandes conjuntos de dados tem sido um considerável gargalo para as grandes companhias (INVESTOR, 2014). O Big Data é caracterizado em três Vs. Volume (volume), que está relacionado à grande quantidade de dados que se obtém dentro ou fora da empresa; o segundo é a Velocidade (velocity), pois a cada segundo muitos dados novos são criados na internet, e alguns destes dados podem ser interessantes para a empresa; o terceiro e último está relacionado à Variedade (variety), sendo que o dado pode ser um compartilhamento de um texto em uma rede social, um post no blog, ou até mesmo uma avaliação em uma loja virtual. Recentemente foi acrescentado mais dois Vs, Veracidade (veracity), pois não adianta obter os dados sem confiabilidade e também o se mostrará inviável se o resultado não trouxer benefícios significativos e que compensem o investimento. Este é o ponto de vista do Valor (value) (ALECRIM, 2013). Segundo a Hekima (HEKIMA, 2016), a Walmart, rede norte-americana de varejo coleta cerca de 2,5 petabytes de dados a cada hora, por meio da captura de informações das transações de seus clientes. Esse monitoramento permite controlar com precisão os níveis do estoque, prever tendências sazonais de crescimento no consumo de alguns produtos, além de melhorar os processos de trabalho da rede. A empresa também criou ferramentas capazes de interagir e capturar até mesmo nuances do seu público. Hekima (HEKIMA, 2016) ainda reforça o termo Big Data Analytics, que nada mais é que o trabalho analítico e inteligente de grandes volumes de dados, estruturados ou não-.

(31) 30. estruturados, que são coletados, armazenados e interpretados por softwares de altíssimo desempenho. Trata-se do cruzamento de uma infinidade de dados do ambiente interno e externo, gerando uma espécie de "bússola gerencial"para tomadores de decisão. Tudo isso, é claro, em um tempo de processamento extremamente reduzido. Recente estudo realizado pela IBM Investor estima que em 2017 teremos aproximadamente 1 trilhão de dispositivos conectados gerando dados em todo planeta, que isso equivale à 2.5 bilhões de gigabytes de dados todos os dias, gerando um montante de US$ 266 bilhões de dólares, gastos com dados. Na Figura 7 é possível visualizar o comparativo realizado pela IBM Investor (INVESTOR, 2014).. Figura 7: Comparativo do BIG Data (INVESTOR, 2014). Big Data testa os limites das tecnologias disponíveis para utilizá-los. Estas tecnologias podem ser analisadas sob duas óticas (KERNOCHAN, 2011): • As envolvidas com analytics ou analítica, tendo Hadoop e MapReduce como as principais; • As tecnologias de infra estrutura, que armazenam e processam os dados. Neste caso destaca-se o NoSQL, na Figura 8 é possível visualizar exemplos de bancos de dados NoSQL..

(32) 31. Figura 8: Exemplos de bancos de dados NoSQL: Cassandra, MongoDB, HBase (ALECRIM, 2013). Para a Intel (INTEL, 2012), as tecnologias como Hadoop e MapReduce são projetadas para atender os três Vs de grandes volumes de dados. Elas também exigiram mais esforços em infraestrutura para suportar o processamento distribuído de análise de dados não estruturados, incluindo requisitos em infraestrutura para trabalhos distribuídos em larga escala, armazenamento eficiente, infraestrutura de rede e recursos de segurança. No contexto deste trabalho foi utilizado o Apache Hadoop e Apache Spark para processamento dos dados e o MongoDB para armazenamento. Passaremos nas seções seguintes a abordar estas tecnologias.. 2.2.1. Apache Hadoop (HDFS). O Hadoop Distributed File System (HDFS) é um sistema de arquivo distribuído projetado para rodar em dispositivos que são interligados para oferecer melhor poder de processamento. Ele possui muitas semelhanças com os atuais sistemas de arquivos distribuídos. No entanto, as diferenças de outros sistemas de arquivos distribuídos são significativas. HDFS é altamente tolerante a falhas e é projetado para ser implantado em hardware de baixo custo. HDFS oferece alta por meio do acesso ao colocar dados de aplicativos e é adequado para aplicações que têm grandes conjuntos de dados (BORTHAKUR, 2013) Segundo Hanson (HANSON, 2013), o HDFS é composto por clusters de nós interconectados no local onde os arquivos e diretórios residem. Um cluster HDFS consiste em um único nó, conhecido como um NameNode, que gerencia o namespace do sistema de arquivos e regula o acesso do cliente aos arquivos. Além disso, os nós de dados (DataNodes) armazenam dados como blocos dentro dos arquivos..

(33) 32. A Figura 9 abaixo ilustra a arquitetura de alto nível do HDFS.. Figura 9: Arquitetura do HDFS (HANSON, 2013). Para Alecrim (ALECRIM, 2013), o Hadoop é tido como uma das soluções mais adequadas para Big Data pelos seguintes motivos: • É um projeto opensource, fato que permite a sua modificação para fins de customização e o torna suscetível a melhorias constantes graças à sua rede de colaboração. Por causa desta característica, vários projetos derivados ou complementares foram e ainda são criados; • Proporciona economia, já que não exige o pagamento de licenças e suporta hardware convencional, permitindo a criação de projetos com máquinas consideravelmente mais baratas; • O Hadoop conta, por padrão, com recursos de tolerância a falhas, como replicação de dados; • O Hadoop é escalável: havendo necessidade de processamento para suportar maior quantidade de dados, é possível acrescentar computadores sem necessidade de realizar reconfigurações complexas no sistema. O Hadoop ganhou maior popularidade devido à sua capacidade de armazenamento, análise e acesso a grande quantidade de dados, de forma rápida e com baixo custo através.

(34) 33. de distribuição de hardware em nuvem. O Apache Hadoop é uma coleção de vários componentes e não apenas um único produto. O Hadoop conta com um ecossistema onde existem vários outros produtos de código aberto, para facilitar o uso mais profundamente de todo o potencial do Hadoop. Na Figura 10 é possível visualizar a maioria dos componentes que fazem parte do Ecossistema do Hadoop (SESHACHALA, 2015).. Figura 10: Ecossistema do Hadoop (SESHACHALA, 2015). Os componentes mais utilizados são (ALLOUCHE, 2014): • Apache Hive: É uma ferramenta de armazenamento de dados que fornece compactação de dados e consultas ad-hoc. É um sistema que dá aos usuários ferramentas para executar consultas poderosas e obter resultados muitas vezes em tempo real. • Apache Spark: Apache Spark é um mecanismo geral de computação que oferece análise rápida de dados em grande escala. O Spark é construído sobre HDFS mas não utiliza o MapReduce, em vez disso usa sua própria estrutura de processamento de dados. O Apache Spark possui componentes de consultas em tempo real, processamento de fluxo de dados (streaming), algoritmos iterativos, operações complexas e aprendizagem de máquina. • Apache Ambari: Ambari foi criado para ajudar a gerenciar o Hadoop. Ele oferece suporte para muitas das ferramentas no ecossistema Hadoop incluindo Hive, HBase, Piq, Sqoop e Zookeeper. A ferramenta apresenta um painel de gerenciamento que mantém o controle do estado do cluster e pode ajudar a diagnosticar problemas de desempenho..

(35) 34. • Apache Pig: Pig é uma plataforma com uma linguagem de consulta de alto nível construídas para lidar com grandes conjuntos de dados. • Apache HBase: HBase é um sistema de gerenciamento de banco de dados nãorelacional que funciona em cima do HDFS. Ele é construído para lidar com conjuntos de dados esparsos comuns aos projetos de big data.. 2.2.2. Apache Spark. O Spark é um framework para processamento de Big Data construído com foco em velocidade, facilidade de uso e análises sofisticadas. Inicialmente, o Spark oferece um framework unificado e de fácil compreensão para gerenciar e processar Big Data com uma variedade de conjuntos de dados de diversas naturezas (por exemplo: texto, grafos, etc), bem como de diferentes origens (batch ou streaming de dados em tempo real) (PENCHIKALA,. 2015).. O Spark permite que aplicações em clusters Hadoop executem até 100 vezes mais rápido em memória e até 10 vezes mais rápido em disco. Além das operações de MapReduce, suporta consultas SQL, streaming de dados, aprendizado de máquina e processamento de grafos. Na Figura 11 abaixo é possível visualizar a estrutura da arquitetura Spark (PENCHIKALA,. 2015).. Figura 11: Arquitetura do Spark (PENCHIKALA, 2015) O Spark usa a infraestrutura do Hadoop Distributed File System (HDFS), mas melhora suas funcionalidades e fornece ferramentas adicionais. Por exemplo, permite a implantação de aplicativos em cluster Hadoop v1 (com SIMR - Spark Inside MapReduce), ou em Hadoop v2 com YARN ou com Apache Mesos..

(36) 35. Segundo Penchikala, Deve-se olhar para o Spark como uma alternativa para MapReduce do Hadoop em vez de um simples substituto, mas como uma solução abrangente e unificada para gerenciar diferentes casos de uso da Big Data (PENCHIKALA, 2015). O Spark estende o MapReduce evitando mover os dados durante seu processamento, através de recursos como armazenamento de dados em memória e processamento próximo ao tempo real, o desempenho pode ser várias vezes mais rápido do que outras tecnologias de Big Data. Também há suporte para validação sob demanda de consultas para Big Data, o que ajuda com a otimização do fluxo de processamento de dados e fornece uma API de mais alto nível para melhorar a produtividade do desenvolvedor e um modelo consistente para o arquiteto de soluções Big Data. Na Figura 12 nota-se a diferença da utilização da memória e disco entre o Hadoop e o Spark (PENCHIKALA, 2015).. Figura 12: Comparativo do movimento dos dados no Hadoop e Spark (HEMSOTH, 2015). Segundo Hemsoth (HEMSOTH, 2015), o Spark detém resultados intermediários na memória, em vez de escrevê-los no disco, o que é muito útil quando se precisa processar o mesmo conjunto de dados muitas vezes. Seu projeto teve por objetivo torná-lo um mecanismo de execução que funciona tanto na memória como em disco e, por isso, o Spark executa operações em disco quando os dados não cabem mais na memória. Assim, é possível usá-lo para o processamento de conjuntos de dados maiores que a memória agregada em um cluster. Será armazenado a maior quantidade possível de dados na memória e, em seguida, irá persisti-los em disco. Cabe ao arquiteto do sistema olhar para os seus dados e casos de uso para avaliar os requisitos de memória. Com esse mecanismo de.

(37) 36. armazenamento de dados em memória, o uso do Spark traz vantagens de desempenho. Além da API do Spark, existem bibliotecas adicionais que fazem parte da sua arquitetura (Figura 11) e fornecem capacidades adicionais para as áreas de análise de Big Data e aprendizado de máquina. • Spark Streaming: O Spark Streaming pode ser usado para processar dados de streaming em tempo real baseado na computação de microbatch. • Spark SQL: O Spark SQL fornece a capacidade de expor os conjuntos de dados Spark através de uma API JDBC. Isso permite executar consultas no estilo SQL sobre esses dados usando ferramentas tradicionais de BI e de visualização. Além disso, também permite que os usuários usem ETL para extrair seus dados em diferentes formatos (como JSON, Parquet, ou um banco de dados), transformá-los e expô-los para consultas ad-hoc; • Spark MLlib: MLlib é a biblioteca de aprendizado de máquina do Spark, que consiste em algoritmos de aprendizagem, incluindo a classificação, regressão, clustering, filtragem colaborativa e redução de dimensionalidade; • Spark GraphX: GraphX é uma nova API do Spark para grafos e computação paralela. Para apoiar a computação de grafos, o GraphX expõe um conjunto de operadores fundamentais (por exemplo, subgrafos e vértices adjacentes), bem como uma variante optimizada do Pregel. Além disso, o GraphX inclui uma crescente coleção de algoritmos para simplificar tarefas de análise de grafos.. 2.2.3. MongoDB. MongoDB é uma aplicação de código aberto, de alta performance, sem tabelas, esquemas, SQL ou linhas. Não possui operações ACID, joins, chaves estrangeiras. Na Figura 13 é possível perceber a diferença em relação à um banco relacional (STANNARD, 2011)..

(38) 37. Figura 13: Modelo Relacional x Modelo de Documento (MongoDB) (STANNARD, 2011). O MongoDB é um banco de dados caracterizado como NoSQL, um termo usado coletivamente para denotar software de banco de dados que não usa SQL (Structured Query Language) para interagir com o banco de dados. Utiliza-se o conceito orientado a documentos que armazena dados em coleções de documentos semelhantes a JSON. O que distingue o MongoDB de outros bancos de dados NoSQL é a sua poderosa linguagem de consulta baseada em documento, que torna a transição de um banco de dados relacional para o MongoDB fácil, porque as consultas são convertidas com bastante facilidade (LENNON, 2011). Em bancos de dados relacionais define-se o esquema antes de adicionar os dados. Assim, um banco de dados com nome, endereço, número de telefone, etc. possui a estrutura base para receber seus dados. Se for necessário adicionar a idade, o sexo e outro valor, então será necessário construir um novo esquema, com novos "campos"e a inteligência para saber o que esses novos valores significam. Isto consome tempo e se torna mais difícil para manutenção. Com NoSQL os esquemas são dinâmicos, significa que os conjuntos de dados diferentes podem ser armazenados juntos, não sendo necessário criar um esquema para cada tipo de dado (BRIDGWATER, 2015). Este capítulo introduziu a área de Big Data e as tecnologias utilizadas para desenvolvimento de aplicações com grande quantidade de dados, além da integração e utilização do MongoDB. Estes temas são extremamente relevantes para o prosseguimento desta dissertação e que servirão como base para o desenvolvimento deste trabalho. No próximo.

(39) 38. capítulo serão exploradas a arquitetura e como foi estruturado todo o projeto do GoldBi, assim como algumas das funcionalidades criadas para atender inicialmente a proposta inicial da ferramenta..

(40) 39. 3. Problemas de Pesquisa. Durante o desenvolvimento deste trabalho, identificou-se alguns desafios de pesquisa que foram aprofundados para que pudesse chegar a uma solução adequada aos objetivos traçados para o produto. Neste capítulo serão enumerados os principais problemas de pesquisa, organizados através de seis principais questões de pesquisa que foram identificadas. Cada uma das questões de pesquisa passarão a ser enumeradas e abordadas de agora em diante. QP1: Como viabilizar que a ferramenta esteja em nuvem e ao mesmo tempo extraia as informações em outros bancos de dados em redes privadas? A análise deste problema demandou inicialmente uma análise das possibilidades técnicas disponíveis no mercado, bem como a análise de sua viabilidade comercial de implementação. Esperava-se que a opção não trouxesse impacto para estrutura de rede do cliente agindo de forma transparente na comunicação dos dados entre os seus dados localizados em rede privada e o GoldBI na nuvem pública. A primeira opção analisada foi a conexão direta ao banco de dados a partir da rede pública (nuvem) com a rede privada do cliente. Esta opção, traria como pontos positivos o acesso direto ao banco em tempo real, gerando facilidades de implementação, uma vez que seria uma conexão simples com o banco de dados. Como pontos negativos, destaca-se a segurança, já que o cliente deveria expor seu banco de dados em um IP público através do firewall, além de questões de performance devido a latência ao realizar consulta dos dados em redes distintas. A segunda opção estudada foi a disponibilização em uma aplicação in-loco, ou seja, na rede do cliente, que atuasse como um serviço, consultando os dados no banco local do cliente e enviando esses dados para a aplicação remota (web) através de Web Services. Esta solução possui como vantagens que o acesso ao banco de dados ficaria transparente para a aplicação web (nuvem), não expondo o servidor em IP público de forma que pudesse trazer algum problema de segurança. Como ponto negativo destaca-se a necessidade de criação de uma nova aplicação, dados não são enviados em tempo real..

(41) 40. A partir das duas opções analisadas logo se descartou a primeira devido ao a relevância dos seus pontos negativos. Optou-se então pela segunda solução. Neste caso, foi criado o projeto GolbBI Extract que tem por finalidade executar na rede do cliente e obter as informações do banco de dados, fragmentá-las, e enviar, quando necessário, para o lado servidor. Com esta opção não é preciso mudar nada na rede do cliente pois o GoldBI Extract conecta-se a um banco de dados da rede local e envia dados para um IP público através da porta 80 (HTTP) – já comumente liberada em todas as redes. QP2: Como enviar grande quantidade de dados da rede da organização para a plataforma em nuvem? A partir da necessidade de extração dos dados dos clientes e envio para a nuvem pública (questão QP1) verifica-se que se tratam de dados que podem representar uma grande quantidade de dados para utilização da banda de rede dos clientes. Se considerarmos que um determinado cliente possui uma taxa de upload de 10 Mbps, por exemplo, enviar dezenas de megabytes, extraídos de informações do seu banco de dados, pode onerar a sua rede ou mesmo inviabilizar a utilização da ferramenta. A primeira limitação encontrada foi relacionada a questão técnica, pois ao realizar o envio de dados utilizando Web Service, foi identificado que de forma recorrente o envio era interrompido devido a problemas de timeout. Uma vez que a informação a ser enviada é potencialmente grande e sequencial o envio da informação completa seria inviável pelo fato do servidor fechar a conexão ao atingir o limite de timeout. Para resolver essa questão foram adotadas duas medidas. Primeiro, realizou-se a compactação dos dados. O envio dos dados no Web Service foi utilizado a formatação JSON (JavaScript Object Notation), que é uma formatação em texto puro para definição de dados utilizando apenas chave e valor. Deste modo, torna-se altamente passível de compactação, o que foi realizado para diminuição dos dados. Porém, só a compactação não é suficiente, pois os dados podem continuar muito largos e ainda continuar obtendo-se timeout. Para sanar este problema enviou-se a informação em formato fragmentado. Os fragmentos são divididos em tamanhos parametrizáveis (padrão 2 Mb) e cada fragmento é enviado de forma separada para o lado servidor. Ao realizar a compressão e fragmentação a aplicação passa a enviar os dados em formato de Bulk Data (ROUSE, 2006). Com as soluções aplicadas foi possível tornar a ferramenta tecnicamente viável e operacional. No entanto, pesquisas ainda serão desenvolvidas para identificar a melhor técnica para enviar somente os dados modificados, uma espécie de delta de modificação desde a última sincronização, e assim diminuir consideravelmente o fluxo de dados trafegados. A.

(42) 41. solução seria simples se houvesse gestão da base de dados de origem e nela pudessem ser inseridas informações de timestamp, por exemplo, porém o GolbBI Extract conecta-se a bases de dados cuja estrutura é desconhecida e não há permissão (nem viabilidade) para modificação desta estrutura, tornado assim a solução a ser aplicada um desafio. QP3: Qual solução de banco de dados utilizar para armazenar os dados antes e depois de serem calculados? A escolha do banco de dados também foi cuidadosamente pensada, visto que seria um ponto crucial para o andamento do projeto. Desta forma, a escolha da solução deveria atender aos seguintes requisitos não funcionais: leve, rápido, robusto e possibilidade de armazenamento em larga escala (Big Data ready). No Capítulo 3 foram abordados alguns bancos de dados NoSQL que possuem a característica de serem bancos rápidos e preparados para trabalhar com grande quantidade de dados. Os bancos NoSQL disponíveis no mercado que foram levados em consideração, foram: MongoDB, HBase e Cassandra, porém segundo comparativo ilustrado na figura 18 identificou-se uma boa performance de leitura de dados entre MongoDB e Cassandra. Esta ênfase a leitura é importante uma vez que a maior parte das operações que necessitam de maior performance no projeto serão de leitura dos dados para exibição dos dashboards. Optou-se pelo MongoDB uma vez que ele possui alta performance de leitura, existia experiência em projetos anteriores da empresa e também a disponibilidade de conectores que facilita a integração com plataformas de processamento de Big Data, como por exemplo um conector MongoDB e Hadoop.. Figura 14: Comparativo: Cassandra x HBase x MongoDB (SVERCHKOV, 2014).

(43) 42. QP4: Qual estratégia de transformação de dados deve-se utilizar? No Capítulo 2 foram abordadas as técnicas de Data Warehouse e ETL, que são essenciais para criação do núcleo do BI. Durante a fase de ETL foi destacada um modelo de transformação e agregação de dados chamado de MapReduce, que significa um modelo de programação paralela, permitindo distribuição da carga em múltiplos nós de processamentos. Este estudo inicial foi fundamental para identificar qual seria a estratégia de transformação de dados, principalmente quando se trata de Big Data, pois além de existir diversas opções de bancos de dados NoSQL que suportem MapReduce, existe também opções de ferramentas para distribuição de carga no processamento de grande quantidade de dados, onde estes serão tratados na QP5. Ou seja, apesar de no início do projeto ter-se estudado alguns algoritmos para computação dos dados (fase de Transform do ELT) verificou-se que a escolha do MapReduce foi a opção escolhida por existir diversas soluções que à utilizam. QP5: Quais técnicas e ferramentas de otimização são necessárias para tratar grandes quantidades de dados? Tendo a escolha do MapReduce como técnica padrão para computação dos dados dos projetos de BI agora parte-se para analisar como ela será realizada. Inicialmente foi estudada a estratégia de realizar o processamento dos dados utilizando a própria implementação do MapReduce do MongoDB. Porém apesar do MongoDB ser um banco de dados NoSQL bastante ágil e flexível, não atendia os requisitos necessários para distribuição paralela e tratamento de grande quantidade de dados, visto que sua flexibilidade para expandir o processamento do MapReduce em vários nós computacionalmente distribuídos não era uma opção nativa e de fácil implementação. Diante deste fato, passou-se a analisar a implementação do MapReduce em classes Java que executariam na camada de negócio da aplicação. Esta escolha trazia uma maior flexibilidade de manipulação, já que detinha-se o completo controle do algoritmo, porém, similar a opção do MongoDB, trava-se de uma solução com limitações de escalabilidade. A partir de então, partiu-se para avaliar ferramentas de Big Data e o cenário passou a incorporar uma nova ótica de rol de ferramentas. A partir dos estudos realizados sobre a área (explorado no Capítulo 3) a solução mais evidenciada para o problema foi o Hadoop. Trata-se da solução mais popular e com maior aceitabilidade no mercado para processamento distribuído e armazenamento de grande quantidade de dados, além de possuir um vasto ecossistema com diversas soluções para atender várias abordagens. Segundo Karn (KARN, 2013), o MongoDB foi construído.