Análise e Integração de Infraestruturas para Centro de Dados

(1)

FACULDADE DE CI ˆENCIAS DEPARTAMENTO DE INFORM ´ATICA

Análise e Integração de Infraestruturas para Centro de Dados

Ivo Miguel Ferreira da Silva

Mestrado em Engenharia Inform´atica

Especializac¸˜ao em Arquitetura, Sistemas e Redes de Computadores

Dissertac¸˜ao orientada por:

Prof. Doutor Carlos Jorge da Conceic¸˜ao Teixeira

Ana Cristina Branco Guimar˜aes Maia

(2)

(3)

Agradeço ao orientador da faculdade, à co-orientadora da empresa e à equipa que ini-ciou este projeto todo o aux´ılio prestado durante o seu desenvolvimento.

(4)

(5)

O projeto de Análise e Integração de Infraestruturas para Centro de Dados consiste na reunião e uniformização de dados recolhidos de bases de dados de diversos provedo-res. A variedade de bases de dados deve-se à diversidade de sistemas em produção que suportam os serviços prestados por uma multinacional de telecomunicações. Este projeto resulta da procura por uma solução inovadora que possa servir os novos serviços na área das telecomunicações nos próximos anos e permita substituir os sistemas atuais que estão limitados a cada tecnologia de base de dados. Os dados reunidos por este sistema são pu-blicados num intermediário Apache Kafka e persistidos com recurso a tecnologia Apache Hadoop para aumentar a disponibilidade dos dados e possibilitar a realização de análises posteriores. Este relatório descreve a Análise, o Desenho, o Desenvolvimento e os Testes aos conectores para bases de dados SQL Server e MySQL que se baseiam num conector Oracle previamente desenvolvido para funcionar com o sistema descrito acima. Com o trabalho descrito neste documento, o sistema realiza o seu propósito com bases de dados Oracle, SQL Server e MySQL ficando preparado para funcionar também com outros co-nectores de bases de dados caso se considere necessário. Este sistema está preparado para permitir a futura introdução de sistemas inovadores de análise posterior de dados.

Palavras-chave: Captura de dados estruturados, Conversão de dados, Integração de dados, Envio de dados, Bases de Dados.

(6)

Abstract

The project Analysis and Integration of Infrastructures for Datacenter is the reunion and standardization of databases data from different companies. The diversity of databases comes from the kind of prodution systems that backing the telecomunications multina-tional services. This project remains from the search for new solutions to furnish future services developed in the next years in telecomunications area and to replace the running systems that are limited to each database company. The data gathered by this system is published in an intermediary message broker called Apache Kafka and is persisted in Apache Hadoop modules and related projects to increase the data availability and allow posterior analysis. This report describes the analysis, design, development and tests to database conectors for SQL Server and MySQL. These conectors grounds on previous developed Oracle conector to work with the above described system. Using the work de-scribed in this document, the system fulfils your objective and remains adaptable to work with other database conectors in addition to Oracle, SQL Server and MySQL databases, if necessary. This system is already prepared to make data available to new data mining systems.

Keywords: Change Data Capture, Data Conversion and Standardization, Data Integration, Data transmission, Databases.

(7)

Lista de Figuras ix

Lista de Tabelas xii

Glossário xiii 1 Introdução 1 1.1 Enquadramento . . . 1 1.2 Motivação . . . 1 1.2.1 Da empresa de telecomunicações . . . 2 1.2.2 Da consultora . . . 2 1.2.3 Da equipa . . . 2 1.2.4 Individuais . . . 3 1.3 Objectivos . . . 3 1.3.1 Da empresa de telecomunicações . . . 3 1.3.2 Da consultora . . . 4 1.3.3 Da equipa . . . 5 1.3.4 Individuais . . . 5 1.4 Contribuições do autor . . . 7 1.5 Estrutura do documento . . . 8 2 Estado da arte 11 2.1 Conector SQL Server . . . 11 2.1.1 Funcionalidades inclu´ıdas . . . 11 2.1.2 Versões empresariais . . . 11

2.1.3 Vers˜oes empresariais de c´odigo aberto . . . 12

2.1.4 Vers˜oes particulares de c´odigo aberto . . . 12

2.2 Conector MySQL . . . 14

2.2.1 Funcionalidades inclu´ıdas . . . 14

2.2.2 Vers˜oes empresariais . . . 15

2.2.3 Vers˜oes empresariais de c´odigo aberto . . . 15

2.2.4 Vers˜oes particulares de c´odigo aberto . . . 15 v

(8)

2.3 Discuss˜ao . . . 17

3 Análise 19 3.1 Descrição do projeto . . . 19

3.2 Requisitos detalhados . . . 20

3.2.1 Requisitos funcionais . . . 20

3.2.2 Requisitos n˜ao funcionais . . . 21

3.2.3 Requisitos inversos . . . 22

3.3 Casos de uso . . . 22

3.4 Diagramas de fluxos de dados . . . 28

3.5 Diagrama de transic¸˜ao de estados dos conectores . . . 31

3.6 Diagramas de atividades . . . 31 3.7 Diagramas de sequência . . . 35 3.8 Diagramas de classes . . . 35 4 Planeamento 43 4.1 Recursos . . . 43 4.1.1 Recursos humanos . . . 43 4.1.2 Tecnologias envolvidas . . . 44 4.2 Estimação . . . 45 4.2.1 Do esforço dispon´ıvel . . . 45

4.2.2 Modelos emp´ıricos (COCOMO) . . . 45

4.2.3 Dados hist´oricos . . . 47

4.3 Processo de desenvolvimento de software . . . 47

4.4 Planeamento detalhado do projeto . . . 47

4.4.1 Decomposic¸˜ao das tarefas . . . 47

4.4.2 Afetac¸˜ao das tarefas . . . 47

4.4.3 Diagrama Gantt . . . 48

4.4.4 Diagrama da alocac¸˜ao de recursos . . . 48

4.5 Análise cr´ıtica . . . 48 4.5.1 Viabilidade . . . 48 4.5.2 Soluções . . . 48 5 Implementação 51 5.1 Especificação de procedimentos . . . 51 5.2 Organização do conector . . . 52 5.2.1 Conector Oracle . . . 52 5.2.2 Conector SQL Server . . . 52 5.2.3 Conector MySQL . . . 53 5.3 Funcionalidades do sistema . . . 53 vi

(9)

6 Testes 57

6.1 Plano de testes . . . 57

6.1.1 Extens˜ao dos testes unit´arios . . . 57

6.1.2 Testes unit´arios ao conector SQL Server . . . 57

6.1.3 Testes unit´arios ao conector MySQL . . . 60

6.1.4 Extensão dos testes de integração . . . 61

6.1.5 Testes de integrac¸˜ao . . . 62

6.2 Conclus˜oes dos testes . . . 62

6.2.1 Cobertura total . . . 62

6.2.2 Erros detetados no conector SQL Server . . . 62

6.2.3 Erros detetados no conector MySQL . . . 64

6.3 Discuss˜ao . . . 65

7 Conclusões 67 7.1 Decomposição, atribuição e calendarização das tarefas realizadas . . . 67

7.1.1 Medidas do projeto . . . 67

7.2 Planeado vs. executado . . . 68

7.3 Avaliac¸˜ao post-mortem . . . 68

7.3.1 An´alise global do esforc¸o despendido . . . 68

7.3.2 An´alise global do decurso do projeto . . . 69

7.4 S´ıntese cr´ıtica do projeto . . . 69

7.5 Conclus˜ao . . . 70

8 Futuros desenvolvimentos 73 Bibliografia 84 9 Apˆendices 85 .1 Plano de Testes . . . 86

.1.1 Testes unit´arios ao conector SQL Server . . . 86

.1.2 Testes unit´arios ao conector MySQL . . . 142

.1.3 Testes de integrac¸˜ao . . . 168

.2 Exemplos de tabelas de produc¸˜ao . . . 174

.3 Diagrama Gantt . . . 174

(10)

(11)

3.1 Diagrama de Fluxos de Dados do Sistema n´ıvel 0 . . . 28

3.2 Diagrama de Fluxos de Dados do Sistema n´ıvel 1 . . . 29

3.3 Diagrama de Fluxos de Dados da BD Oracle n´ıvel 2 . . . 30

3.4 Diagrama de Fluxos de Dados da BD SQL Server n´ıvel 2 . . . 32

3.5 Diagrama de Fluxos de Dados da BD MySQL n´ıvel 2 . . . 33

3.6 Diagrama de Transic¸˜ao de Estados dos Conectores . . . 34

3.7 Diagrama de Atividades Geral do Sistema . . . 36

3.8 Diagrama de Atividades do Conector Oracle . . . 37

3.9 Diagrama de Atividades do Conector SQL Server . . . 38

3.10 Diagrama de Atividades do Conector MySQL . . . 39

3.11 Diagrama de Sequˆencia do Conector Oracle . . . 40

3.12 Diagrama de Sequˆencia do Conector SQL Server . . . 40

3.13 Diagrama de Sequˆencia do Conector MySQL . . . 41

3.14 Diagrama de Classes do Conector Oracle . . . 41

3.15 Diagrama de Classes do Conector SQL Server . . . 42

3.16 Diagrama de Classes do Conector MySQL . . . 42

4.1 Diagrama da Alocac¸˜ao de Recursos . . . 49

6.1 Exemplo de C´odigo de Teste do conector SQL Server . . . 59

1 Tabela de produc¸˜ao com poucas colunas . . . 174

2 Tabela de produc¸˜ao com muitas colunas . . . 175

3 Diagrama Gantt parte 1 . . . 176

4 Diagrama Gantt parte 2 . . . 177

5 Legenda do diagrama Gantt . . . 178

(12)

(13)

2.1 Comparac¸˜ao entre os trabalhos relacionados com o conector SQLServer . 13

2.2 Comparac¸˜ao entre as funcionalidades existentes no SQLServer . . . 14

2.3 Comparac¸˜ao entre os trabalhos relacionados com o conector MySQL . . . 17

2.4 Comparac¸˜ao entre as funcionalidades existentes no MySQL . . . 18

4.1 Competˆencias pr´evias nas linguagens utilizadas . . . 45

4.2 Estimação por decomposição de linhas de código . . . 46

5.1 Convers˜ao entre os tipos das colunas [11] . . . 53

5.2 Convers˜ao para JSON suportar caracteres especiais . . . 54

6.1 Relação entre os tipos das operações e os dados registados . . . 61

1 Plano de testes de caixa preta ao procedimento usp AnalyseStrings . . . . 86

2 Resultados dos testes de caixa preta ao procedimento usp AnalyseStrings 86 3 Plano de testes de caixa preta ao procedimento usp ConvertJSONType . . 91

4 Plano de testes de caixa preta ao procedimento usp DescribeTable . . . . 96

5 Resultados dos testes de caixa preta ao procedimento usp DescribeTable . 97 6 Plano de testes de caixa preta ao procedimento usp FetchTableAlterations 104 7 Resultados dos testes de caixa preta ao proc usp FetchTableAlterations . . 105

8 Plano de testes de caixa preta ao procedimento usp GetCustomResults . . 111

9 Resultados dos testes de caixa preta ao procedimento usp GetCustomRe-sults . . . 111

10 Plano de testes de caixa preta ao procedimento usp GetLastRows . . . 114

11 Plano de testes de caixa preta ao procedimento usp GetTableColsList . . 118

12 Resultados dos testes de caixa preta ao procedimento usp GetTableColsList118 13 Plano de testes de caixa preta ao procedimento usp MakeJSON . . . 121

14 Resultados dos testes de caixa preta ao procedimento usp MakeJSON . . 122

15 Plano de testes de caixa preta ao procedimento usp RegisterTableInCDC . 128 16 Plano de testes de caixa preta ao proc usp SendJSONByHTTPWithSQL-CLR . . . 130

17 Plano de testes de caixa preta ao procedimento usp SyncCDCTable . . . . 136 18 Plano de testes de caixa preta ao procedimento usp UnregisterTableInCDC 139

(14)

19 Plano de testes de caixa preta à função readConfigFile . . . 142 20 Resultados dos testes de caixa preta à função readConfigFile . . . 143 21 Plano de testes de caixa preta à função getLastClosedProcLogFile . . . . 145 22 Resultados dos testes de caixa preta à função getLastClosedProcLogFile . 145 23 Plano de testes de caixa preta à função readLastClosedLogFile . . . 148 24 Resultados dos testes de caixa preta à função readLastClosedLogFile . . . 149 25 Plano de testes de caixa preta à função updateLogPosition . . . 153 26 Plano de testes de caixa preta à função getTimestamp . . . 157 27 Plano de testes de caixa preta à função searchForAlterationsInOpenLogFile160 28 Plano de testes de caixa preta ao procedimento registerTableInCDC . . . 163

(15)

BD base de dados. 1–9, 11, 13, 14, 16–22, 28, 29, 31, 35, 43, 44, 51, 53, 56, 57, 63, 64, 66, 71–73, 75, 107–110, 114, 115, 142, 143, 147–153, 155–170, 173–176

CDC recolha de alterac¸˜oes - change data capture. 5, 8, 11, 12, 15, 19, 31, 35, 52, 55, 65, 131, 135, 136, 140, 142, 143

COCOMO Constructive Cost MOdel. 45, 69

consumidor JSON interface Kafka-REST-Proxy. 20, 44 cURL ferramenta para transferˆencia de dados. 52, 57

Ethernet ligação f´ısica à rede. 21

Gantt diagrama das tarefas do projeto. 9, 10, 44, 48, 69 gatilho trigger. 2, 11, 16

GTID identificador ´unico. 16

Hadoop estrutura (framework) de processamento distribu´ıdo. 44 HDFS sistema de ficheiros Hadoop - Hadoop File System. 44 HIVE armaz´em de dados. 6, 44

HTTP protocolo de transferˆencia de dados - hypertext transfer protocol. 14, 16, 21, 44 HUE interface Web de an´alise de dados. 44

intermediário Kafka intermediário Apache para publicação de alterações. 6–9, 12, 15, 20–22, 28, 29, 31, 35, 44, 57, 64, 67, 75, 173–176

JDBC ligação à base de dados usando java - java database connection. 12 xiii

(16)

xiv

JSON javascript object notation. 6, 7, 11, 16, 17, 20–22, 29, 31, 35, 44, 51–53, 55–57, 62, 63, 72, 91, 95–97, 103–105, 110, 111, 115, 128, 129, 135, 136, 149, 151–154, 161, 173–176

NoSQL base de dados n˜ao relacional. 71, 75 Oozie escalonador de tarefas. 44

prospec¸˜ao de dados Data Mining. 72, 75

RACC Cobertura Restrita da Cl´ausula Ativa - Restricted Active Clause Coverage. 64, 89, 93, 98, 116, 120, 123, 130, 132, 138, 141, 144, 147, 150, 155, 159, 162, 165 SGBD sistema de gest˜ao da base de dados. 2, 5–8, 11, 14, 18, 20, 21, 31, 35, 52, 53, 56,

67, 90

SQL linguagem de consulta estruturada - structured query language. 21, 45, 64, 65, 95–97, 105, 110, 111, 115, 120–122

SQLCLR SQL common language runtime. 51 SQLCMD acesso SQL `a linha de comandos. 52 YARN gestor de recursos. 44

(17)

Introduc¸˜ao

1.1 Enquadramento

Este projeto está inclu´ıdo num plano de desenvolvimento e atualização dos sistemas internos de uma empresa de telecomunicações europeia. Esta multinacional tem mais de um milhão de clientes particulares e algumas centenas de clientes empresariais. Nos seus projetos tem atualmente mais de dez mil trabalhadores diretos e alguns milhares de parceiros em projetos complementares.

Os projetos de inovação e investigação de novas soluções para os sistemas internos da empresa de telecomunicações estão entregues a alguns parceiros que lhe adjudicam mais de duas centenas de trabalhadores a tempo inteiro. Este projeto está sob a alçada de uma consultora multinacional, com duas centenas de clientes distribu´ıdos por cem pa´ıses onde emprega mais de meio milhar de profissionais da área das tecnologias.

Nestes projetos também estão colocados alguns trabalhadores de uma empresa nacio-nal com algumas dezenas de trabalhadores, a AKTM, à qual pertence a coorientadora da empresa que está a acompanhar este projeto.

Este projeto ficou sob a responsabilidade de uma equipa de dois trabalhadores da consultora multinacional para analisarem, desenharem, desenvolverem e testarem uma soluc¸˜ao que capture, integre e disponibilize os dados das diversas tecnologias de bases de dados.

O autor foi integrado na equipa que iniciou este projeto para continuar o trabalho j´a principiado seguidamente descrito.

1.2 Motivac¸˜ao

Seguidamente descreverei a motivação das várias entidades e intervenientes. 1

(18)

Cap´ıtulo 1. Introduc¸˜ao 2

1.2.1 Da empresa de telecomunicac¸˜oes

• Melhorar a gestão dos recursos da organização de modo a obter informações mais completas e detalhadas sobre o funcionamento das base de dados (BD) em produção. • Complementar e melhorar a oferta de serviços aos clientes colocando em produção

novos sistemas para transmitir fluxos de dados quase em tempo real.

• Descobrir novas oportunidades de negócio utilizando resultados de uma análise pro-funda a grandes conjuntos de dados obtidos dos sistemas em produção.

1.2.2 Da consultora

• Extrair conclusões úteis da análise dos dados obtidos dos sistemas em produção que demonstrem as potencialidades deste projeto.

• Suportar subscritores com uma vasta diversidade de interesses na obtenc¸˜ao de da-dos, em termos de:

– frequência: minuto a minuto, horária ou diária. – atraso: 5 a 10 minutos, 1 hora ou 24 horas. – tipo: caracteres e números, imagens ou v´ıdeo. – quantidade de dados: dezenas de Kb, Mb ou Gb. – largura de banda: dezenas de Mb/s até 1Gb/s.

– multiplicidade dos produtores: 1 produtor ou poucas dezenas. – diversidade de origens: BD Oracle, SQLServer ou MySQL. • Aumentar o n´ıvel de tolerˆancia a faltas dos dados persistidos.

1.2.3 Da equipa

• Manter todos os sistemas em produção da empresa de telecomunicações a funcionar sem constrangimentos apesar de serem:

– alteradas as configurações pré-definidas do sistema de gestão da base de dados (SGBD).

– ativados e utilizados serviços complementares do SGBD. – criados e executados novos procedimentos e funções.

• Evitar incompatibilidades e atrasos introduzidos por módulos externos às BD: – minimizando a utilização de triggers (gatilhos) [12].

(19)

– utilizando procedimentos e funções ass´ıncronas. – otimizando as pesquisas realizadas às BD de produção.

• Suportar a obtenção quase em tempo real de fluxos de dados dos sistemas em produção para:

– viabilizar novos serviços que necessitem de fluxos de texto, imagens e v´ıdeos. – permitir analisar a operação dos sistemas prestadores de serviços para

identi-ficar problemas nos primeiros minutos ap´os a sua ocorrˆencia.

1.2.4 Individuais

• Trabalhar em equipa num projeto real. • Ter contacto com ambientes empresariais.

• Contribuir para uma solução da empresa de telecomunicações. • Aplicar os conhecimentos obtidos durante a formação académica. • Adquirir experiência de programação em PL/SQL e T-SQL.

• Compreender o funcionamento interno das v´arias tecnologias de BD.

• Escolher a forma mais adequada para registar e exportar as alterações das BD em produção.

• Resolver o desafio da integração de dados num sistema com vários provedores de BD.

1.3 Objectivos

Seguidamente descreverei os objetivos das v´arias entidades e intervenientes.

1.3.1 Da empresa de telecomunicac¸˜oes

• Substituir o sistema antigo por um mais atual que satisfac¸a os requisitos dos novos servic¸os prestados aos clientes.

• Definir um novo padrão de integração de dados moderno e dinâmico que possa substituir o padrão utilizado atualmente nos sistemas em produção.

• Alterar paradigma de obtenção de dados da empresa para publicador/subscritor [33] porque este modelo diminui as dependências entre os sistemas e é mais adequado à utilização de dados pretendida.

(20)

• Realizar uma análise profunda dos dados produzidos pelos sistemas em produção que possibilite conhecer todas as potencialidades dos sistemas e otimizá-los. • Armazenar todos os dados obtidos de sistemas em produção por tempo

indetermi-nado mantendo-os acess´ıveis para an´alises posteriores.

• Definir um mecanismo de captura e integração de dados que suporte a transmissão de fluxos de dados (streaming) e se adeque à prestação de serviços da próxima geração.

1.3.2 Da consultora

• Atualizar o paradigma de distribuic¸˜ao de dados:

– de recolha apenas dos dados subscritos para o paradigma Publish/Subscribe comec¸ar a recolher, integrar e armazenar todos os dados produzidos.

– para diminuir a dependˆencia entre os produtores e os consumidores.

– para aumentar a quantidade de informação armazenada de modo a possibilitar uma análise posterior dos dados que não são utilizados atualmente.

– para suportar a integrac¸˜ao com todos os sistemas produtores de dados da em-presa.

• Integrar quase em tempo real dados de sistemas muito distintos como os produtores: – que utilizam provedores de BD distintos.

– de dezenas de Kb de dados por segundo até dezenas de Gb por segundo. – de dados cr´ıticos para a prestação de serviços aos clientes ou os produtores de

registos de operações que apenas interessam à equipa de desenvolvimento. • Persistir os dados recolhidos num repositório Hadoop.

• Distribuir os dados corretamente em func¸˜ao das necessidades do recetor que podem variar:

– na frequˆencia: desde muito reduzida at´e muito elevada. – no atraso: curto ou prolongado.

– no tipo: dados textuais de operação ou multimédia.

– na quantidade de dados: cabeçalhos, metadata ou conteúdos para clientes. – na largura de banda: ADSL, fibra ótica ou bastidor.

– na multiplicidade de produtores: apenas uma amostra como exemplo at´e todos os que pertencem ao sistema.

(21)

– na diversidade de origens: apenas de um at´e todos os provedores de BD. • Aplicar an´alise de grandes conjuntos de dados sobre os dados persistidos dos

siste-mas em produc¸˜ao para:

– aumentar o conhecimento sobre os dados que a empresa de telecomunicac¸˜oes tem ao seu dispor.

– melhorar o acesso aos dados persistidos.

– identificar e catalogar as informac¸˜oes importantes.

– auxiliar a empresa de telecomunicações na tomada de decisões como: ∗ onde devem ser realizados os próximos investimentos.

∗ que servic¸os trazem maiores lucros e preju´ızos.

1.3.3 Da equipa

• Definir um novo mecanismo de captura de alterac¸˜oes que suporte os requisitos dos futuros sistemas da empresa nomeadamente:

– uma maior quantidade de dados.

– a emissão de fluxos de dados com maior frequência. – a obtenção dos dados com atrasos mais reduzidos. – uma maior largura de banda.

• Disponibilizar uma interface para envio e receção de fluxos de dados dos sistemas em produção para o armazenamento persistente.

• Melhorar a eficiência da captura de alterações das BD em operação:

– obtendo alterações das BD em produção de forma estável e retrocompat´ıvel. – utilizando aplicações de captura de dados.

1.3.4 Individuais

• Analisar as diversas abordagens para capturar dados numa BD em produção, como: – as ferramentas de recolha de alterações - change data capture (CDC)

forneci-das pelos SGBD.

– os mecanismos de replicação. – o acesso aos registos de operações.

(22)

• Analisar as diversas alternativas para extrair alterações das BD em produção, como: – a utilização de bibliotecas C#.

– a execução de uma aplicação do sistema operativo pela linha de comandos. – a replicação da BD em produção para comparar o seu conteúdo anterior e

posterior a uma alteração e registar as alterações efetuadas. – a utilização de um programa externo em C.

• Identificar os desafios do desenvolvimento, como: – a periodicidade da obtenção das alterações. – capturar alterações apenas das tabelas indicadas.

– registar apenas as operações que produzem alterações nas tabelas. – o agrupamento das linhas alteradas em cada tabela.

– a formatação do javascript object notation (JSON) [45] das alterações captu-radas.

– a extração das alterações do SGBD.

– o envio para o intermediário Apache para publicação de alterações (inter-mediário Kafka) escolhido previamente pela equipa para reunir, persistir no armazém de dados (HIVE) e distribuir todas as alterações independentemente da sua tecnologia de origem.

– a eliminação das alterações publicadas com sucesso.

• Planear a arquitetura da implementac¸˜ao para cada tecnologia de base de dados com o objetivo de:

– registar as alterac¸˜oes. – formatar o JSON. – enviar o JSON.

– limpar as alterações já enviadas.

• Especificar os contratos dos procedimentos e func¸˜oes.

• Implementar os procedimentos e funções seguindo boas práticas de programação. • Redigir o plano de testes unitários e de integração para garantir uma cobertura de

todas as linhas de c´odigo.

• Executar o plano de testes seguindo os procedimentos recomendados pelas normas internacionais.

(23)

• Realizar o executável para a instalação.

• Redigir o manual de instalação, configuração e manutenção do código desenvolvido para cada tecnologia.

1.4 Contribuic¸˜oes do autor

Esta parte do relat´orio descreve o trabalho atribu´ıdo pela equipa ao seu autor.

Nos próximos cap´ıtulos, o software que obtém as alterações das várias BDs, converte-as para um formato padrão em JSON e envia-converte-as para o intermediário Kafka para que sejam disponibilizadas às aplicações interessadas, será chamado conector.

• Durante a fase de An´alise realizou: – o levantamento de requisitos.

– a comparac¸˜ao entre as tecnologias existentes.

– a investigação das funcionalidades suportadas pelos SGBD. – a identificação de problemas associados.

• Durante a fase de Desenho planeou:

– a arquitetura da soluc¸˜ao para cada tecnologia.

– a integração com o sistema existente em produção na empresa de telecomunicações. • Durante a fase de Desenvolvimento implementou:

– o conector SQL Server p´os-2008. – o conector MySQL p´os v5.1.5.

• Durante a fase de Testes executou os testes: – unitários aos procedimentos e funções.

– de Integrac¸˜ao com o sistema desenvolvido pela equipa. • Ao longo do projeto produziu:

– os comentários adjacentes ao código desenvolvido. – o manual de instalação do conector MySQL [70]. – o manual de instalação do conector SQL Server [71].

• Todas as tarefas referidas anteriormente contribu´ıram para a obtenc¸˜ao do produto final que:

(24)

– publica no intermediário Kafka as alterações captadas das BDs de produção SQL Server e MySQL num formato JSON normalizado que pode ser enviado para os subscritores segundo as suas preferências.

1.5 Estrutura do documento

Em seguida apresentam-se os cap´ıtulos e secções em que este documento está dividido acompanhados de um breve resumo do conteúdo de cada um deles.

Este documento est´a organizado da seguinte forma:

• Cap´ıtulo 2 – Estado da arte: pesquisa sobre os projetos e as funcionalidades dos SGBD que existem atualmente para o registo, obtenção, formatação e publicação de alterações em SQL Server e MySQL.

2.1 - Conector SQL Server: lista das funcionalidades inclu´ıdas na linguagem e dos conectores alternativos para publicar no intermediário Kafka as alterações registadas pelo mecanismo CDC do SQL Server.

2.2 - Conector MySQL: lista das funcionalidades inclu´ıdas na linguagem e dos conectores alternativos que recolham as alterações do registo binário e as publiquem no intermediário Kafka.

2.3 - Discussão: indicação dos motivos para não adotar uma das soluções ana-lisadas.

• Cap´ıtulo 3 – Análise: compreensão, descrição, contextualização e recolha dos re-quisitos do projeto.

3.1 - Descrição do projeto: em que consiste o projeto, missão, criticidade e otimização dos conectores, ciclo de vida dos dados manipulados, tecnologias e sis-temas envolvidos e o que se pretende obter.

3.2 - Requisitos detalhados: levantamento de requisitos funcionais, n˜ao funci-onais, inversos, diagramas dos conectores desenvolvidos e do ambiente em que se inserem.

3.3 - Casos de uso: listam as utilizações mais comuns dos conectores. 3.4 - Diagramas de fluxos de dados: ilustra a manipulação das alterações. 3.5 - Diagrama de transição de estados dos conectores: sintetiza as fases do funcionamento dos conectores.

3.6 - Diagramas de atividades: apresentam as tarefas realizadas pelo sistema e conectores.

(25)

3.7 - Diagramas de sequência: indicam a ordem das chamadas dos procedimen-tos e funções dos conectores.

3.8 - Diagramas de classes: demonstram a organização das tabelas em cada BD. • Cap´ıtulo 4 - Planeamento: enumeração dos recursos humanos associados ao pro-jeto, das tecnologias envolvidas e das previsões para este projeto. Indicação do processo de desenvolvimento adotado e da organização das tarefas.

4.1 - Recursos: descric¸˜ao dos recursos humanos e das tecnologias envolvidas neste projeto.

4.2 - Estimação: do esforço dispon´ıvel, com modelos emp´ıricos e recorrendo a dados históricos.

4.3 - Processo de desenvolvimento de software: descric¸˜ao do modelo cascata utilizado.

4.4 - Planeamento detalhado do projeto: descrição textual do diagrama das tarefas do projeto (Gantt) sua decomposição e afetação.

4.5 - Análise cr´ıtica: considerações sobre a viabilidade do projeto e apresentação de poss´ıveis soluções para os problemas mais prováveis.

• Cap´ıtulo 5 - Implementação: lista dos procedimentos especificados, organização dos conectores e descrição das funcionalidades desenvolvidas.

5.1 - Especificação de procedimentos: lista de soluções para resolver os desa-fios apresentados pelos conectores.

5.2 - Organização do conector: descrição das tarefas espec´ıficas dos vários componentes de cada conector.

5.3 - Funcionalidades do sistema: descrição detalhada das operações realizadas por cada conector.

5.4 - Aspetos significativos da implementação: lista da documentação produ-zida com os detalhes da implementação mais importantes para a instalação, manutenção e futuros desenvolvimentos.

• Cap´ıtulo 6 - Testes: definição da extensão dos testes pretendida e do plano de testes unitários e de integração. Descrição dos testes estruturais (caixa branca) e funcio-nais (caixa preta) aplicados para verificar a correta implementação dos conectores. Apresentação dos resultados da cobertura dos testes e dos erros detetados nos co-nectores.

6.1 - Plano de testes: descrição e categorização dos testes.

6.2 - Conclusões dos testes: indicação da cobertura alcançada e demonstração dos dados obtidos numa lista de erros detetados em cada conector.

(26)

6.3 - Discussão: indicação da criticidade dos erros identificados e avaliação da aptidão dos conectores desenvolvidos.

• Cap´ıtulo 7 - Conclusões: descrição das tarefas realizadas e comparação dos resul-tados obtidos com a organização de tarefas inicial, com o esforço estimado e com o trabalho requerido. avaliação do trabalho desenvolvido, diferenças face às estima-tivas, análise do esforço despendido e do decurso do projeto, indicação de futuros desenvolvimentos e s´ıntese cr´ıtica do projeto

7.1 - Decomposição, atribuição e calendarização das tarefas realizadas: apre-sentadas no diagrama Gantt na figura 3 em anexo.

7.2 - Planeado vs. executado: comparac¸˜ao entre o trabalho planeado e aquele que foi executado.

7.3 - Avaliação post-mortem: lista dos aspetos positivos e negativos do projeto e comparação entre a realidade do projeto e as estimativas iniciais.

7.4 - S´ıntese cr´ıtica do projeto: análise de todo o decurso do projeto e enumeração de problemas identificados no projeto.

7.5 - Conclusão: balanço do projeto e considerações finais.

• Cap´ıtulo 8 - Futuros desenvolvimentos: identificac¸˜ao das funcionalidades que po-dem ser desenvolvidos para complementar o sistema.

(27)

Estado da arte

Neste cap´ıtulo são apresentados os resultados de uma pesquisa por soluções já existen-tes, que procuram resolver problemas de integração de dados similares ao deste projeto.

2.1 Conector SQL Server

Em seguida listam-se as funcionalidades e vers˜oes de conectores relevantes encontra-dos na pesquisa para o conector SQL Server.

2.1.1 Funcionalidades inclu´ıdas

A lista seguinte contém as funcionalides oferecidas pelo SGBD que podem auxiliar na construção de um conector SQL Server.

• O registo das alterações ocorridas nas tabelas (ativar CDC) [61]. • O agendamento de execução de código T-SQL (Schedule Job) [63]. • A conversão de dados relacionais para JSON (SQL Server 2016) [60, 62]. • A execução de ferramentas na linha de comandos (executar na CMDShell) [64]. • A integração de código C# para adicionar funcionalidades (ativar SQL CLR) [44]. • A ativação de eventos gatilho quando se realiza uma determinada operação na BD

em produc¸˜ao [12].

• A convers˜ao do formato de n´umeros e marcas temporais (timestamps) [10].

2.1.2 Vers˜oes empresariais

As vers˜oes seguintes s˜ao alternativas empresariais ao conector SQL Server que se pre-tende desenvolver.

(28)

Cap´ıtulo 2. Estado da arte 12

• Microsoft SQL Server CDC to intermedi´ario Kafka – Striim [73]. • Oracle Goldengate to replicate SQL Server transactions [59]. • IBM InfoSphere Data Replication from SQL Server [16]. • Informatica PowerCenter [49].

• SAP NetWeaver Master Data Management (MDM)[68].

2.1.3 Vers˜oes empresariais de c´odigo aberto

A versão seguinte é uma alternativa empresarial ao conector SQL Server cujo código foi disponibilizado publicamente para permitir o seu desenvolvimento e utilização pela comunidade.

• Pentaho Data Integration (aka Kettle) [15].

2.1.4 Vers˜oes particulares de c´odigo aberto

As versões seguintes são alternativas ao conector SQL Server que se deseja desenvolver e foram realizadas por particulares que as disponibilizaram em código aberto.

• GitHub - No9/sqlcdcstream: A stream of SQL Server Change Events [36].

• Is there a SQL Server CDC connector for intermedi´ario Kafka Connect? - Grupos do Google [26].

• intermediário Kafka connect: connecting ligação à base de dados usando java - java database connection(JDBC) source using Sql server - Grupos do Google [28]. • intermediário Kafka Connect - Is this the expected behavior? - Grupos do Google

[27].

• GitHub - jpalomo/kafka-connect-mssqlserver-cdc [35].

Problemas detetados nos trabalhos relacionados com o conector SQL Server

A lista seguinte apresenta os problemas detetados nos trabalhos referidos anteriormente e que s˜ao comparados na tabela 2.1.

• A: O preço de aquisição da licença de utilização.

• B: O projeto foi desenvolvido por uma empresa de um grupo concorrente.

• C: Não mantém a compatibilidade requerida porque utiliza recursos adicionados após o SQL Server 2008.

(29)

• D: Não mantém a compatibilidade requerida porque utiliza recursos das últimas versões do MySQL

• E: Implica alterações nas BD produtoras. Estas BD não podem ser alteradas porque já estão em produção.

• F: N˜ao garante funcionamento quase em tempo real.

• G: Falta de suporte para os tipos de colunas personalizados utilizados nas BD em produção da empresa de telecomunicações [13].

• H: Acesso restrito ao c´odigo fonte. • I: Utiliza c´odigo Java.

Tabela 2.1: Comparac¸˜ao entre os trabalhos relacionados com o conector SQLServer Problemas Bibliografia A B C D E F G H I [73] X X X X [59] X X [16] X X [49] X X [68] X X X [15] X [36] X X [26] X [28] X X [27] X [35] X X X X

Problemas detetados nas funcionalidades inclu´ıdas no SQL Server

Em seguida estão os problemas que condicionam a utilização das funcionalidades in-clu´ıdas no SQL Server para resolver alguns desafios do conector e a sua comparação na tabela 2.2.

• J: N˜ao mant´em a compatibilidade requerida porque utiliza recursos adicionados no SQL Server 2012.

• L: N˜ao mant´em a compatibilidade requerida porque utiliza recursos adiconados no SQL Server 2016.

• M: Implica alterações nas BD produtoras. Estas BD não podem ser alteradas porque já estão em produção.

(30)

• N: N˜ao garante funcionamento quase em tempo real.

• O: Est˜ao bloqueados pelo administrador das BDs porque originam problemas de seguranc¸a bem conhecidos como a:

O1: execução de programas na linha de comandos do Windows. O2: execução de bibliotecas C# pré-compiladas.

O3: exportação de dados por protocolo de transferência de dados - hypertext transfer protocol(HTTP).

Tabela 2.2: Comparac¸˜ao entre as funcionalidades existentes no SQLServer Problemas Bibliografia J L M N O1 O2 O3 [61] X [63] X [60, 62] X [64] X [44] X X [12] X [10] X

2.2 Conector MySQL

Em seguida listam-se as funcionalidades e vers˜oes de conectores relevantes encontra-dos na pesquisa para o conector MySQL.

2.2.1 Funcionalidades inclu´ıdas

A lista seguinte contém as funcionalidades disponibilizadas pelo SGBD que podem auxiliar na construção de um conector MySQL.

• As colunas podem ser do tipo JSON e podem ser utilizadas as func¸˜oes JSON AR-RAY([val[, val] ...]), JSON OBJECT([key, val[, key, val] ...]) e JSON QUOTE(string) para o formatar [4].

• O registo binário num ficheiro dos dados alterados nas tabelas [5]. • O registo binário num ficheiro das operações realizadas nas tabelas [6].

(31)

2.2.2 Vers˜oes empresariais

As vers˜oes seguintes s˜ao alternativas empresariais ao conector MySQL que se pretende desenvolver.

• MySQL CDC to intermedi´ario Kafka – Striim [74]. • IBM DataStage ODBC to MySQL [58].

2.2.3 Vers˜oes empresariais de c´odigo aberto

As versões listadas em seguida são alternativas empresariais ao conector MySQL que foram disponibilizadas em código aberto para permitir o seu desenvolvimento e utilização pela comunidade.

• GitHub - vmware/tungsten-replicator: Tungsten Replicator [42].

• GitHub - zendesk/maxwell: Maxwell’s daemon, a mysql-to-json intermedi´ario Kafka producer [40, 66].

• GitHub - Yelp/mysql-streamer: MySQLStreamer is a database change data capture and publish system [39, 69].

• GitHub - debezium/debezium: Change data capture for a variety of databases [34, 14].

• GitHub - shyiko/mysql-binlog-connector-java: MySQL Binary Log conector [38]. • Informatica Connector Toolkit: MySQL Connector [48].

2.2.4 Vers˜oes particulares de c´odigo aberto

As versões seguintes são alternativas ao conector MySQL que se deseja desenvolver e foram realizadas por particulares que as disponibilizaram em código aberto.

• GitHub - mardambey/mypipe: MySQL binary log consumer with the ability to o on changed rows and publish changes to different systems with emphasis on Apache intermedi´ario Kafka [41].

• GitHub - whitesock/open-replicator: Open Replicator is a high performance MySQL binlog parser written in Java. It unfolds the possibilities that you can parse, filter and broadcast the binlog events in a real time manner [43].

• GitHub - pyr/recordbus: recordbus: mysql binlog to apache intermedi´ario Kafka [37].

(32)

• GitHub - dan-da/cdc audit: change data capture via audit tables and triggers for mysql [19].

• FlexCDC is a change data capture utility for MySQL 5.1 [75].

• GitHub - mysqludf/lib mysqludf json: A UDF library of functions to map MySQL data to JSON [20].

Problemas detetados nos trabalhos relacionados com o conector MySQL

Em seguida voltam a indicar-se as listas de problemas para facilitar a leitura das tabelas de comparação 2.3 e 2.4. Continua-se a sequência das letras das listas do conector SQL Server porque não se pretende comparar o conector SQL Server com o MySQL uma vez que é necessário integrar dados de ambas as tecnologias.

A lista seguinte apresenta os problemas detetados nos trabalhos referidos anterior-mente e que s˜ao comparados na tabela 2.3.

• P: O preço de aquisição da licença de utilização.

• Q: O projeto foi desenvolvido por uma empresa de um grupo concorrente.

• R: Não mantém a compatibilidade requerida porque utiliza recursos das versões do MySQL pós 5.5, como:

- o identificador ´unico (GTID) [65].

• S: Implica alterações nas BD produtoras. Estas BD não podem ser alteradas porque já estão em produção.

• T: Utiliza recursos da BD em produção que estão bloqueados pelo administrador das BDs porque constituem problemas de segurança, como:

- a execução de programas na linha de comandos do Windows. - a exportação de dados por HTTP.

• U: N˜ao garante funcionamento quase em tempo real. • V: Utiliza c´odigo Java.

• X: Não suporta todas as operações sobre as BD que são utilizadas pelos sistemas em produção.

• Z: Utiliza c´odigo Python. • AA: Utiliza PHP.

(33)

• AC: Não mantém a compatibilidade requerida porque utiliza recursos das versões do MySQL pós 5.1.

• AD: Acesso restrito ao c´odigo fonte.

Tabela 2.3: Comparac¸˜ao entre os trabalhos relacionados com o conector MySQL Problemas Bibliografia P Q R S T U V X Z AA AB AC AD [74] X X X [58] X X [42] X X [40, 66] X X X X [39, 69] X X [14, 34] X X X [38] X X X [48] X [41] X [43] X X [37] X X [19] X X X X [75] X X X [20] X

Problemas detetados nas funcionalidades inclu´ıdas no MySQL

Em seguida estão os problemas que condicionam a utilização das funcionalidades dis-ponibilizadas pelo MySQL para resolver alguns desafios do conector e a sua comparação na tabela 2.4.

• AD: O tipo JSON e as funções que o formatam não permitem a retrocompatibili-dade com as BD com versões anteriores a agosto de 2015. [4].

• AE: O registo binário dos dados alterados nas tabelas não permite a retrocompati-bilidade com as BD com versões anteriores a novembro de 2008. [6].

• AF: O registo binário das operações realizadas nas tabelas não permite a retrocom-patibilidade com as BD com versões anteriores a janeiro de 2001. [5].

2.3 Discuss˜ao

Devido aos problemas identificados nos trabalhos relacionados e nas funcionalida-des existentes conclui-se que ´e necess´ario funcionalida-desenvolver os conectores para SQL Server

(34)

Tabela 2.4: Comparac¸˜ao entre as funcionalidades existentes no MySQL Problemas

Bibliografia AD AE AF

[4] X

[6] X

[5] X

e MySQL. Nem todos os problemas identificados têm a mesma relevância uma vez que o preço de aquisição é suficiente para impedir a sua utilização neste projeto mas a falta de suporte ou de retrocompatibilidade poderá ser adaptada.

Não foi adoptada a solução proposta em nenhum dos trabalhos relacionados mas utilizaram-se e adaptaram-se algumas funcionalidades disponibilizadas pelos SGBD.

No conector SQL Server utilizou-se o registo de alterações nas tabelas, a integração de código C# e a conversão do formato das marcas temporais.

No conector MySQL adaptou-se a funcionalidade de registo binário das alterações [6], convertendo o ficheiro binário que esta produz para texto leg´ıvel utilizando a ferramenta do SGBD mysqlbinlog [3] e pesquisando as alterações nesse texto. Como descrito nos casos especiais de instalação do manual de instalação do conector MySQL [70], também é poss´ıvel implementar o conector tendo apenas o registo binário de operações. Para tal deve ser utilizada uma BD auxiliar que seja uma réplica da que está em produção onde se apliquem todas as operações que surjam no ficheiro de registo binário.

(35)

An´alise

Em seguida é fornecida uma descrição detalhada deste projeto acompanhada pelos re-quisitos que foram identificados para auxiliar a compreensão dos desafios impostos por este projeto.

3.1 Descric¸˜ao do projeto

Neste projeto pretende substituir-se o sistema antigo por um mais atual que satisfaça os requisitos dos novos serviços. Como os sistemas produtores já possuem os próprios mecanismos de deteção e tolerância a faltas o mais importante é disponibilizarem-se os fluxos de dados recolhidos quase em tempo real, preferencialmente entre dez a quinze minutos.

Apesar de serem recolhidos dados provenientes de sistemas cr´ıticos para a prestação de serviços de telecomunicações aos clientes, é suficiente obtê-los, integrá-los e publicá-los em intervapublicá-los de dez a quinze minutos pois a sua utilização resume-se ao processa-mento por consumidores antigos e por novos consumidores que venham a ser desenvolvi-dos.

Prevê-se que os novos consumidores poderão alimentar um sistema complementar de diagnóstico quase em tempo real da qualidade do serviço prestado aos clientes e armaze-narão todos os dados recolhidos para criar um armazém de dados onde se possam aplicar técnicas de prospeção de dados. Os sistemas que subscrevem e analisam os dados inte-grados não foram desenvolvidos neste projeto estando portanto para além do âmbito deste documento.

Para cumprir o propósito do sistema é necessário desenvolver conectores CDC (Change Data Capture) para Oracle, SQL Server e MySQL porque neste momento a empresa multi-nacional de telecomunicações não utiliza outras tecnologias de BD. Estes deverão funcio-nar em segundo plano para não afetar os sistemas em operação e ser pouco intrusivos para evitar alterações frequentes. Para cumprir estes requisitos, os procedimentos e as funções desenvolvidos foram otimizados para realizarem apenas as operações estritamente

(36)

Cap´ıtulo 3. An´alise 20

cess´arias e sempre que poss´ıvel foram utilizados os mecanismos disponibilizados pelos SGBD.

A missão de cada conector é detetar todas as alterações que ocorrerem nas tabelas em produção que lhe sejam indicadas. Por último, convertem os dados alterados para formato JSON e publicam-nos no intermediário Kafka considerando as várias especifici-dades de cada SGBD descritas neste relatório. Para realizar estas publicações a equipa de desenvolvimento escolheu o interface Kafka-REST-Proxy (consumidor JSON). Esta foi considerada a alternativa mais estável que cumpria os requisitos identificados para este projeto evitando assim alocar mais tempo para desenvolver uma nova interface com o intermediário Kafka.

3.2 Requisitos detalhados

Em seguida listam-se os requisitos para os conectores. Foram identificados e siste-matizados com a equipa que iniciou este projeto pois o modelo em cascata seguido n˜ao previa mais fases de an´alise com o cliente.

3.2.1 Requisitos funcionais

Estes s˜ao os requisitos funcionais dos conectores: C-Requisitos

Esta ´e a lista dos requisitos dos clientes:

• CRF1 - Manter a retrocompatibilidade do conector com as BD em produção. - Pós SQL Server 2008.

- P´os MySQL 5.1.5.

• CRF2 - Detetar alterações nas BD em produção.

• CRF3 - Obter alterações sem interferir com o funcionamento dos sistemas em produção.

D-Requisitos

Esta ´e a lista dos requisitos dos programadores:

• DRF1 - Converter alterações para um formato padrão (JSON) escolhido pela equipa que considerava o XML muito prolixo.

(37)

• DRF3 - Testar o funcionamento de todo o sistema de integração e análise com os conectores desenvolvidos:

- Utilizar dados open source num ambiente muito dinâmico com milhares de operações por segundo em centenas de tabelas.

3.2.2 Requisitos n˜ao funcionais

Estes s˜ao os requisitos n˜ao funcionais dos conectores: 1. Referentes ao seu desempenho:

• RNF1 - a velocidade: para obter, analisar e persistir milhares de operações em poucos minutos (de preferência 5 a 10 minutos).

• RNF2 - a capacidade: para exportar as alterações detetadas em quantidades indexadas à capacidades restritas dos sistemas em produção.

• RNF3 - a utilização de memória: deve ser minimizada utilizando mecanismos de registo de alterações embutidos nas BD em produção.

• RNF4 - o tempo de resposta: deve suportar a transmissão de fluxos de dados em poucos minutos e possibilitar a satisfação de requisitos próximos de tempo real.

2. Referentes `as suas interfaces:

• RNF5 - de hardware: devem ser configuradas para utilizar uma ligação f´ısica à rede (Ethernet).

• RNF6 - de software: devem comunicar por HTTP usando JSON e o protocolo intermedi´ario Kafka.

• RNF7 - do SGBD: para receber comandos linguagem de consulta estrutu-rada - structured query language (SQL) enviados por um operador e executar PL/SQL para registar e exportar as alterac¸˜oes ocorridas.

• RNF8 - de armazenamento: para receber as alterações por HTTP. • RNF9 - de comunicações: devem ser realizadas por HTTP via Ethernet. 3. Referentes à utilização dos recursos dispon´ıveis, estes são os limites máximos que

não deve ultrapassar num sistema em produção: • RNF13 - Processamento: 10% do CPU. • RNF14 - Memória: 10% da RAM. • RNF15 - Disco: 10% do HDD.

(38)

3.2.3 Requisitos inversos

Estes são os requisitos inversos dos conectores, que referem aquilo que não é da res-ponsabilidade deles:

1. Não conhecem o destino final das alterações pois apenas as publicam no inter-mediário Kafka definido.

2. Não analisam as alterações detetadas nas BD em produção para o qual foram de-senvolvidos.

3.3 Casos de uso

Em seguida apresentam-se os casos de uso mais comuns em que o sistema utiliza os conectores para formatar o JSON das alterações das BD em produção.

Todos os fluxos principais de eventos terminam com:

• o sistema a guardar os dados resultantes do pedido realizado pelo ator numa BD em produc¸˜ao.

• o conector a capturar, formatar e publicar as alterações registadas no intermediário Kafka.

• um sistema recetor a obter as alterações do intermediário Kafka segundo as suas configurações personalizadas.

1. Efetuar uma chamada • Atores:

– o cliente. • Pré-condições:

– o cliente possui telefone ou telem´ovel.

– o cliente subscreveu um servic¸o que lhe permite utilizar esse equipamento para realizar chamadas.

• Fluxo principal de eventos:

– o cliente telefona para um n´umero. – o sistema realiza a chamada. 2. Aceder a uma p´agina na internet

(39)

– o cliente possui um dispositivo que lhe permite aceder `a internet.

– o cliente subscreveu um servic¸o que lhe permite utilizar esse dispositivo para aceder `a internet.

– o cliente tem o seu dispositivo ligado `a internet. • Fluxo principal de eventos:

– o cliente abre um navegador da internet no seu dispositivo. – o cliente pede para aceder a uma página na internet. – o sistema permite ao cliente aceder à página.

3. Adquirir pacotes de dados m´oveis • Atores:

– o cliente possui um dispositivo m´ovel. • Fluxo principal de eventos:

– o cliente liga para o atendimento automático. – o sistema apresenta as opções ao cliente.

– o cliente indica qual o pacote m´ovel que pretende adquirir. 4. Assistir a um canal transmitido em direto

• Atores: – o cliente. • Pré-condições:

– o cliente possui um dispositivo que reproduz v´ıdeo.

– o dispositivo está ligado à rede da empresa de telecomunicações. • Fluxo principal de eventos:

– o cliente pede a lista de canais dispon´ıveis. – o sistema apresenta a lista de canais.

– o cliente seleciona o canal a que pretende assistir. 5. Rever um programa transmitido nos ´ultimos dias

(40)

– o cliente possui um dispositivo que recebe programas transmitidos. – o cliente subscreveu um servic¸o que lhe permite assistir aos programas

transmitidos nos ´ultimos dias.

– o dispositivo está ligado à rede da empresa de telecomunicações. • Fluxo principal de eventos:

– o cliente pede a lista de programas dispon´ıveis. – o sistema apresenta a lista de programas.

– o cliente seleciona o programa a que pretende assistir.

6. Sincronizar conte údos multimédia entre a televisão e um dispositivo móvel • Atores:

– o cliente possui uma televisão e um dispositivo móvel. – o cliente subscreveu um pacote de canais para a televisão. – o dispositivo móvel está junto à televisão.

– o cliente pede a lista de conteúdos dispon´ıveis na televisão. – o sistema apresenta os conteúdos armazenados.

– o cliente seleciona o conteúdo que pretende sincronizar. 7. Mudar o tarifário do telemóvel na área de cliente

– o cliente possui um dispositivo que pode aceder `a internet.

– o cliente subscreveu um servic¸o que lhe permite utilizar esse dispositivo para aceder `a internet.

– o cliente tem o seu dispositivo ligado `a internet. – o cliente possui telefone ou telem´ovel.

– o cliente subscreveu um tarif´ario que lhe permite utilizar esse equipa-mento para realizar chamadas.

(41)

– o cliente tem acesso a uma área de cliente disponibilizada pela empresa de telecomunicações.

– o cliente abre um navegador da internet no seu dispositivo.

– o cliente acede à sua área de cliente na página da empresa de telecomunicações. – o cliente escolhe outro tarifário na lista de tarifários dispon´ıveis.

– o sistema confirma a mudança do tarifário do cliente. 8. Adquirir um filme na aplicação doméstica ou móvel

– o cliente possui um aparelho que lhe permite assistir a televis˜ao digital. – o cliente subscreveu um servic¸o que lhe permite utilizar esse aparelho

para adquirir filmes num videoclube digital. • Fluxo principal de eventos:

– o cliente abre uma lista de filmes no seu aparelho. – o cliente escolhe e compra um filme da lista. – o sistema disponibiliza o filme.

9. Registar uma nova instalac¸˜ao • Atores:

– um técnico de telecomunicações. • Pré-condições:

– o técnico instalou um serviço da empresa de telecomunicações a um cli-ente.

– o técnico tem o seu dispositivo móvel ligado à internet.

– o técnico tem acesso ao sistema de registo de novas instalações. • Fluxo principal de eventos:

– o técnico preenche os dados de uma nova instalação. – o técnico regista uma nova instalação no sistema. – o sistema confirma o registo da nova instalação. 10. Registar um novo cliente

(42)

– um assistente. • Pré-condições:

– o assistente trabalha numa loja f´ısica da empresa de telecomunicações. – o assistente tem um computador ligado à internet.

– o assistente tem acesso ao sistema de registo de novos clientes. • Fluxo principal de eventos:

– o assistente preenche os dados do novo cliente. – o assistente regista um novo cliente no sistema. – o sistema confirma o registo do novo cliente. 11. Atualizar uma instalação doméstica pré-existente

• Atores:

– um técnico de telecomunicações. • Pré-condições:

– o técnico alterou os serviços prestados pela empresa de telecomunicações a um cliente.

– o técnico tem o seu dispositivo móvel ligado à internet. – o técnico tem acesso ao sistema de registo de alterações. • Fluxo principal de eventos:

– o t´ecnico pesquisa o cliente.

– o sistema apresenta os dados da instalac¸˜ao antiga.

– o técnico atualiza os dados com as alterações que realizou. – o sistema confirma a atualização dos serviços do cliente. 12. Disponibilizar o v´ıdeo de várias câmaras num evento

• Atores:

– um técnico de telecomunicações. • Pré-condições do técnico:

– verificou o funcionamento das várias câmaras. – tem uma ligação à internet de última geração. – tem o seu dispositivo móvel ligado à internet. – tem acesso ao sistema de transmissão de v´ıdeo. • Fluxo principal de eventos:

(43)

– o sistema verifica as condições da rede. – o técnico inicia a transmissão.

– o sistema confirma que a transmissão se está a realizar com sucesso. – o técnico termina a transmissão.

13. Mudar o tarif´ario de um cliente por telefone • Atores:

– um cliente. – um telefonista. • Pré-condições:

– o telefonista trabalha numa central de atendimento. – o telefonista tem um computador ligado `a internet.

– o telefonista tem acesso ao sistema com as áreas dos clientes. – o cliente subscreveu um serviço da empresa de telecomunicações. • Fluxo principal de eventos:

– o cliente telefona para a central de atendimento. – o cliente fornece os seus dados pessoais ao telefonista. – o telefonista pesquisa a conta do cliente.

– o cliente indica o tarif´ario que pretende.

– o telefonista muda o tarifário do cliente no sistema. – o sistema confirma a mudança do tarifário do cliente. 14. Adicionar um novo tarifário

• Atores:

– um técnico de suporte. • Pré-condições:

– o técnico trabalha na equipa de suporte da empresa de telecomunicações. – o técnico tem acesso ao sistema para realizar a sua manutenção.

– o t´ecnico recebe os dados do novo tarif´ario. • Fluxo principal de eventos:

– o técnico insere os dados do novo tarifário. – o técnico adiciona o novo tarifário ao sistema. – o sistema confirma a adição do novo tarifário.

(44)

3.4 Diagramas de fluxos de dados

Estes diagramas permitem observar as transformac¸˜oes realizadas sobre os dados cap-turados pelos conectores.

Os produtores de dados representados nos diagramas são os aparelhos domésticos de telecomunicações e as lojas de vendas ou apoio ao cliente. Estes alteram dados nas BDs em produção e são maioritariamente sistemas proprietários da empresa de telecomunicações ou sistemas adquiridos à Ericsson1_{, Cisco}2_{e CGI}3_.

O intermediário Kafka situa-se entre publicadores e subscritores permitindo-lhes res-petivamente escrever e ler fluxos de dados. Os dados publicados são armazenados de forma persistente e tolerante a faltas. O seu funcionamento num grupo de máquinas (cluster) permite-lhe oferecer uma boa escalabilidade e suportar fluxos de comunicação em tempo real.

Figura 3.1: Diagrama de Fluxos de Dados do Sistema n´ıvel 0

1_{Communication Services - Ericsson,} https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services

2_{Managed Services - Cisco,} https://web.archive.org/web/20180730203455/https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services

3_Customer _Service _and _Billing: _Telco _and _Media _- _CGI _UK,

(45)

No diagrama de fluxos de dados de n´ıvel 0, figura 3.1, é poss´ıvel observar que as alterações provenientes dos produtores são convertidas para o formato JSON e publicadas no intermediário Kafka.

Figura 3.2: Diagrama de Fluxos de Dados do Sistema n´ıvel 1

No diagrama de fluxos de dados de n´ıvel 1, figura 3.2, está representada a captura das alterações das BDs de produção, a utilização de uma base de dados auxiliar para cada conector para estes obterem parâmetros de configuração e manterem os dados das últimas alterações sem sobrecarregarem as BDs de produção, e a publicação do JSON no intermediário Kafka depois de formatado.

Com a continuação do funcionamento dos conectores espera-se que, quando tiverem sido capturadas alterações em todas as linhas, as tabelas auxiliares se tornem réplicas das que estão em produção.

(46)

(47)

realizadas pelo conector desenvolvido pela equipa, desde a receção das notificações das alterações, à obtenção das mesmas seguida do seu registo numa tabela auxiliar e posterior conversão para publicação no intermediário Kafka.

O conector Oracle foi desenvolvido pela equipa mas foi analisado neste projeto como parte do sistema e inspiração para a realização dos outros conectores.

No diagrama de fluxos de dados SQL Server, figura 3.4, é descrito o funcionamento interno do conector com maior detalhe, nomeadamente a captura de dados a partir das tabelas auxiliares preenchidas pelo mecanismo de CDC integrado e a sua formatação em JSON antes de ser publicado no intermediário Kafka.

No diagrama de fluxos de dados MySQL, figura 3.5, descrevem-se as operações inter-nas do conector que obtém as alterações a partir do ficheiro de registo binário atualizado pelo SGBD.

3.5 Diagrama de transic¸˜ao de estados dos conectores

O diagrama na figura 3.6 apresenta as diversas fases do funcionamento dos conectores: desde a captura de alterações, à sua obtenção, conversão e publicação. O estado em que se obtém as alterações inclui as pesquisas para as completar e a sua inserção nas tabelas auxiliares. Estas interações com as BDs não foram representadas como estados pois são realizadas quando o conector está a obter alterações. Como a publicação de alterações no intermediário Kafka não bloqueia os conectores, eles podem esperar mais alterações sempre que existam atrasos.

3.6 Diagramas de atividades

O diagrama de atividades geral, na figura 3.7, ilustra as atividades realizadas pelo sis-tema para receber as publicações dos conectores e entregá-las aos subscritores conforme as suas preferências. Nos diagramas seguintes que são espec´ıficos de cada tecnologia de base de dados é poss´ıvel observar as atividades realizadas por cada um dos conectores antes de formatarem e publicarem o JSON.

No diagrama de atividades do conector Oracle desenvolvido pela equipa, figura 3.8, é poss´ıvel observar a utilização da funcionalidade disponibilizada pelo SGBD Oracle Noti-fications para conhecer que linhas são alteradas.

No diagrama de atividades do conector SQL Server, figura 3.9, observa-se a im-portância das atividades realizadas pelo mecanismo de captura de dados (CDC) disponi-bilizado pelo SGBD para detetar e registar as alterações em tabelas auxiliares. O conector tem a responsabilidade de identificar as que ainda não foram enviadas para o intermediário Kafka, formatar o JSON e publicá-las.

(48)

(49)

(50)

(51)

as alterações previamente registadas pelo SGBD no ficheiro de log binário e consulta as BD para completar os dados recolhidos.

O diagrama do conector Oracle foi inclu´ıdo para realçar as diferenças entre os vários conectores que resultaram das especificidades de cada tecnologia de base de dados.

3.7 Diagramas de sequˆencia

Nos diagramas de sequência é poss´ıvel observar a ordem das chamadas executadas pelos procedimentos e funções de cada conector que culminam no envio das alterações em formato JSON para o intermediário Kafka.

O diagrama do conector Oracle, figura 3.11, foi inclu´ıdo para realçar as diferenças en-tre as chamadas espec´ıficas de cada conector e permite observar as notificações enviadas pelo SGBD ao conector PL/SQL desenvolvido pela equipa.

O diagrama do conector SQL Server, figura 3.12, ilustra a pesquisa de alterações nas tabelas auxiliares preenchidas pelo SGBD enquanto o do MySQL apresenta a pesquisa no ficheiro de log binário e na BD para reunir todos os dados sobre as alterações.

O diagrama do conector MySQL, figura 3.13, permite observar que o conector pes-quisa o registo binário de alterações, que já é realizado por defeito nas versões mais recen-tes, para obter as últimas alterações que depois completa com uma pesquisa nas tabelas.

3.8 Diagramas de classes

Estes diagramas permitem observar a organização das tabelas em cada BD. • Os diagramas UML das tabelas nas BDs são:

- o diagrama da BD auxiliar dos conectores, figuras 3.14, 3.15, 3.16 onde estes guardam:

- as linhas alteradas.

- as informações do mecanismo de captura de dados (CDC). - os parâmetros de configuração dos conectores.

- os diagramas de exemplo das tabelas existentes nas BDs em produc¸˜ao nas figuras 1 e 2 em anexo.

• Nas tabelas onde existem reticências após o nome das colunas [67], a quantidade total de colunas é variável pois depende das colunas da tabela de produção onde se detetam alterações.

(52)

(53)

(54)

(55)

(56)

Figura 3.11: Diagrama de Sequˆencia do Conector Oracle

(57)

Figura 3.13: Diagrama de Sequˆencia do Conector MySQL

(58)

Figura 3.15: Diagrama de Classes do Conector SQL Server

(59)

Planeamento

Seguidamente será apresentado o planeamento do projeto, desde os recursos humanos e as tecnologias envolvidas até ao modelo de desenvolvimento utilizado e a distribuição de tarefas.

4.1 Recursos

Os recursos associados ao projeto são os mencionados nas próximas secções.

4.1.1 Recursos humanos

• As pessoas envolvidas foram:

– o autor que ficou respons´avel pelo desenvolvimento dos conectores SQL Ser-ver e MySQL e testes do sistema.

– os membros da equipa de desenvolvimento do sistema.

• O esforço do autor iniciou-se em janeiro e terminou em setembro: 8h por dia e 5 dias por semana durante 9 meses, como vis´ıvel no diagrama de alocação de recur-sos, figura 4.1.

• A organizac¸˜ao da equipa foi:

– o autor que desenvolveu os conectores para as BD SQL Server e MySQL e re-alizou os testes ao sistema seguindo as indicac¸˜oes da equipa que desenvolveu o conector para as BD Oracle e os outros componentes do sistema.

• As justificações para o esforço do autor e para a organização já referida resultam: – da candidatura a este projeto apenas na segunda fase.

– da equipa de desenvolvimento do sistema já não estar alocada a este projeto a tempo inteiro porque já conclu´ıram a sua parte do trabalho.

(60)

Cap´ıtulo 4. Planeamento 44

– na lista das tarefas em que se divide este trabalho e no tempo previsto para cada uma que est˜ao apresentados no diagrama Gantt, figura 3 em anexo no final deste documento.

4.1.2 Tecnologias envolvidas

Na próxima lista estão presentes todas as tecnologias envolvidas no trabalho. No âmbito do projeto

• Os servidores que contribuem para a persistˆencia dos dados capturados pertencem a uma estrutura (framework) de processamento distribu´ıdo (Hadoop) :

– consumidor JSON: que estabelece a ligação entre PL/SQL e o intermediário Kafka traduzindo JSON enviado por HTTP para o protocolo do intermediário Kafka.

– intermediário Kafka: que é o local onde se publicam, subscrevem, processam e persistem as alterações convertidas para JSON pelo conector.

– escalonador de tarefas (Oozie): que ´e a agenda de trabalhos Hadoop.

– sistema de ficheiros Hadoop - Hadoop File System (HDFS): que ´e o sistema utilizado para guardar os ficheiros.

– HIVE: que ´e o local onde se persistem todos os dados publicados pelos conec-tores.

– interface Web de an´alise de dados (HUE): que ´e a interface web para analisar os dados integrados.

– gestor de recursos (YARN) com MapReduce2: que ´e o gestor de recursos e a agenda de trabalhos Hadoop com biblioteca de processamento de grandes quantidades de dados.

– serviço de informações de configuração (ZooKeeper): que é o serviço de informações de configuração, sincronização e registo de nomes.

No ˆambito do conector

• Os servidores de BDs em produção são: – Oracle SQL: BD Oracle.

– SQL Server: BD Microsoft. – MySQL: BD OpenSource/Oracle. • As linguagens utilizadas nos conectores s˜ao:

(61)

– SQL. – PL/SQL. – T-SQL. – C#. – C.

• Os ambientes de desenvolvimento onde se implementaram os conectores s˜ao: – Oracle SQL Developer.

– Microsoft SQL Server Management Studio. – MySQL Workbench.

– Visual Studio. – CodeBlocks.

Tabela 4.1: Competˆencias pr´evias nas linguagens utilizadas

Linguagem SQL PL/SQL e T/SQL Java C# C

Dom´ınio Bom Muito reduzido Bom Muito reduzido Bom

4.2 Estimac¸˜ao

Em seguida são apresentadas as estimações para este trabalho.

4.2.1 Do esforc¸o dispon´ıvel

O autor deste projeto est´a dispon´ıvel:

8(horas) ∗ 22(dias) ∗ 9(meses) = 1584(horas)

4.2.2 Modelos emp´ıricos (COCOMO)

Esta é a estimação utilizando o modelo emp´ırico Constructive Cost MOdel (COCOMO): • num Projeto Orgânico a equipa e a dimensão do projeto são reduzidas.

- Estas s˜ao as constantes caracter´ısticas deste tipo de projeto: a = 2.4; b = 1.05; c = 2.5; d = 0.38