O Microsoft Azure é uma plataforma criada pela empresa norte-americana Microsoft no âmbito do conceito de computação na nuvem. Antes de mais, interessa entender a que se refere este termo. A computação na nuvem - cloud computing - refere-se à capacidade de usufruirmos de recursos computacionais - servidores, bases de dados, aplicações, etc. - através da nuvem, ou seja, de uma qualquer rede, normalmente a Internet. Este termo já se encontra vulgarizado na realidade tecnológica atual e é adotado por inúmeras empresas, pois acarreta vantagens a vários níveis. Em primeiro lugar, este tipo de arquitetura destaca-se por ser elástica, isto é, adapta-se às necessidades de cada utilizador, alocando apenas os recursos de que este necessita, adaptando-se às necessidades que existem em cada momento e à localização geográfica. Este tipo de computação oferece, por isso, vantagens ao nível do custo, uma vez que não só permite mitigar a necessidade de compra e manutenção de hardware e software, como permite evitar o desperdício, ou sobre- estimação da necessidade deste tipo de recursos, permitindo ao usufrutuário pagar apenas pelo que utiliza - política pay-for-use. Outro dos aspetos que distingue este conceito é o facto de oferecer agilidade e velocidade ao cliente, uma vez que permite que este aceda a grandes quantidades
de recursos computacionais em meros minutos e reduz dramaticamente o tempo necessário para começar a experimentação e o desenvolvimento. Por fim, a computação na nuvem destaca-se por ser fiável, uma vez que dispõe de um sistema de backup e recuperação de dados que evita perdas de informação que poderiam representar graves consequências para as entidades que usufruem destes serviços.
De acordo com o tipo de necessidades do utilizador que visa suprir, a cloud é normalmente encarada como uma stack com três camadas distintas, sendo que cada uma diz respeito a um determinado tipo de serviços:
• Infraestrutura como serviço (IaaS): Visa ajudar o utilizador a suprir a necessidade de ad- quirir e manter as suas próprias estruturas físicas de computação ou capacidade de armaze- namento como servidores, máquinas virtuais, ou bases de dados. Cada recurso é, por isso, disponibilizado como um serviço que podemos alugar durante o tempo necessário.
• Plataforma como serviço (PaaS): Tem o intuito de incluir todos os recursos necessários para suportar o processo de desenvolvimento, teste, deployment e manutenção de software e disponibilizá-los como um serviço para as empresas que procurem um ambiente seguro, eficiente e escalável.
• Software como serviço (SaaS): Serviço no âmbito da computação na nuvem encarregue de hospedar software e disponibilizá-lo ao utilizador final, normalmente através da Internet e de um qualquer browser. O usufrutuário não necessita de se preocupar com a instalação e manutenção do mesmo, ou com a aquisição de licenças. Muitos dos SaaS possuem versões gratuitas, sendo pagas somente opções adicionais, exclusivas ou personalizadas, ou espaço de armazenamento extra (ex: Gmail e Dropbox).
Os conceitos até então abordados podem ser utilizados para caracterizar e distinguir os tipos de serviços que são disponibilizados no mercado da computação na nuvem. Importa, no entanto, abordar ainda outro aspeto que diz respeito às diferentes tipologias das nuvens no que concerne à forma como disponibilizam estes mesmos serviços, sendo possível dividi-las em três tipos distin- tos:
• Cloud Pública: Este tipo de clouds são propriedade de terceiros, responsáveis pela sua ma- nutenção, e os seus serviços e recursos computacionais estão ao dispor de qualquer entidade - empresa ou indivíduo - através da Internet. A Google, a Amazon e a Microsoft são alguns dos provedores cujos serviços na cloud se inserem neste contexto.
• Cloud Privada: Quando os recursos de um serviço de cloud estão exclusivamente dispo- níveis para uma única organização/entidade esta é considerada uma Cloud Privada. Esta entidade pode ser responsável pela manutenção da sua estrutura, ou pode depender de ter- ceiros para o efeito. A acessibilidade dos recursos é limitada a uma rede privada.
• Cloud Híbrida: Por fim, é possível agregar as duas realidades supracitadas num tipo de serviço cloud que permite que os dados e aplicações que gere possam estar quer públicos, quer privados, de acordo com as necessidades da organização.
Entendido o conceito por trás da computação na nuvem e visando especificamente o Azure, podemos caracterizá-lo como sendo um serviço de cloud público que consegue oferecer um con- junto de serviços que se inserem nos três conceitos supramencionados - IaaS, PaaS e SaaS. No contexto desta dissertação, contudo, é de relevar a importância dos seus serviços de Plataforma como Serviço que oferecem uma quantidade considerável de recursos que permitem a programa- dores e profissionais da área das Tecnologias de Informação criar e manter aplicações baseadas na cloud. Neste âmbito, interessa destacar o Azure App Service, um PaaS que visa oferecer um arse- nal considerável de ferramentas que auxiliem na criação de aplicações web, mobile e em cenários de integração. Ainda dentro deste contexto surgem as Azure Mobile Apps3.
3.3.2.1 Azure Mobile Apps
O serviço Mobile Apps - figura3.2- pretende oferecer uma plataforma ágil e facilmente esca- lável para o desenvolvimento de aplicações móveis. Os programadores que o pretendam utilizar ganham uma ferramenta compatível com aplicações nativas ou multiplataforma, que permite que se conectem rapidamente a uma base de dados local ou na nuvem, bem como a capacidade de acrescentarem à sua aplicação funcionalidades de valor acrescentado como:
• Acesso a opções de armazenamento de dados não estruturados - Azure Blob Storage - ou a bases de dados não relacionais como MongoDB
• Push Notifications
• Autenticação através de Azure Active Directory ou entidades como o Facebook e a Google • Possibilidade de funcionamento em modo offline e disponibilização de um mecanismo
de sincronização que inclui suporte para resolução de conflitos
Figura 3.2: Serviço Azure Mobile Apps4 3https://docs.microsoft.com/en-us/azure/app-service-mobile/
Esta última funcionalidade desperta especial interesse no âmbito desta dissertação, uma vez que oferece uma resposta à necessidade de dotar a prova de conceito da capacidade de disponibili- zar as suas funcionalidades, não só num contexto de ligação à rede, mas de igual modo, quanto esta for escassa ou mesmo inexistente. A sua implementação baseia-se na utilização de um módulo do SDK Azure Mobile Apps denominado Offline Data Sync no lado do servidor e do cliente.
Do lado do servidor, o SDK permite a criação de uma webAPI, otimizada para o contexto da computação móvel, recorrendo a .NET ou à framework de JavaScript NodeJS, como foi o caso nesta dissertação. Esta visa expor diferentes endpoints, por omissão sem qualquer camada de autenticação, seguindo o formato /tables/Nome_Tabela, que permitem executar operações nas várias tabelas de uma base de dados, conforme se mostra na tabela3.3. Além destes endpoints podem ainda ser criadas chamadas personalizadas à API.
Tabela 3.3: Mecanismos expostos pela webAPI
Chamada à API Descrição
GET /tables/Nome_Tabela Permite obter todas as linhas numa tabela GET /tables/Nome_Tabela/:id Permite obter uma linha específica da tabela
POST /tables/Nome_Tabela Permite criar uma linha nova na tabela
PATCH /tables/Nome_Tabela/:id Permite atualizar a informação de uma linha da tabela DELETE /tables/Nome_Tabela/:id Permite apagar uma linha da tabela
Para aceder a estes endpoints, o SDK do lado do cliente expõe interfaces que permitem intera- gir com o backend da nossa aplicação. Caso esta suporte um modo de funcionamento offline, deve ser utilizada a API sync table através da interface respetiva, IMobileServiceSyncTable. Os objetos da classe que implementa esta interface permitem representar as tabelas presentes na base de da- dos, de acordo com o modelo de dados definido e invocar métodos que permitem a manipulação de informação gerida pela aplicação e que coincidem com os endpoints correspondentes:
• ToListAsync() - Permite obter todas as linhas de uma tabela. Pode ainda conter uma cláusula Wherecom o intuito de filtrar os dados obtidos de acordo com o valor de um atributo. Os resultados que devolve podem ainda ser sujeitos a ordenação, agregação por páginas, ou conter apenas certas colunas da tabela.
• LookupAsync(id) - Retorna uma determinada linha de uma tabela cujo id coincide com o parâmetro usado.
• InsertAsync(objeto) - Método de inserção de uma nova linha numa tabela. Tal como os restantes dois métodos recebe como parâmetro um objeto .NET que tem de conter, na sua estrutura, um campo id.
• UpdateAsync(objeto) - Permite atualizar uma linha da tabela cujo id seja igual ao do objeto. • DeleteAsync(objeto) - Equivalente ao anterior, mas para a remoção dessa linha.
4Imagem retirada de https://docs.microsoft.com/en-us/azure/app-service-mobile/
As operações CRUD, neste contexto, implicam a existência de algum tipo de armazenamento local, uma vez que, por omissão, a manipulação de dados ocorre localmente sem que antes exista qualquer interação com o servidor. No caso de aplicações construídas em Xamarin, como o é a prova de conceito criada, este armazenamento é baseado em SQLite.
Uma vez que a informação se encontra confinada, de início, ao armazenamento local é ne- cessário, para permitir uma posterior coordenação com o servidor, que todas as operações CUD efetuadas sejam registadas num outro tipo de objeto, denominado de sync context. Consistindo numa instanciação da classe que estende a interface IMobileServiceClient, este objeto mantém uma queue onde estas operações se encontram ordenadas. Quando a ligação com a rede é rees- tabelecida, ou assim que o utilizador o desejar, é possível iniciar um processo de sincronização que possibilite atingir um estado de consistência entre a informação presente localmente e a que se encontra na base de dados do servidor. Este processo baseia-se em duas operações:
• PUSH: Responsável por enviar as operações CUD, efetuadas em todas as tabelas desde o último push, de forma ordenada. Para que tal aconteça são executados vários pedidos REST ao backend da aplicação que por sua vez fica responsável de os propagar e de aplicar as devidas mudanças na base de dados.
• PULL: A utilização desta operação permite a obtenção de informação presente no servidor, de forma a que a mesma possa ser armazenada na base de dados presente no dispositivo. Ao contrário do método supracitado, é invocado para cada tabela individualmente. Tendo em conta que, por vezes, poderá não ser interessante ou viável obter toda a informação pre- sente na tabela de cada vez que executamos um PULL é possível invocar o método com um parâmetro - query name - e efetuar, assim, uma sincronização incremental. Neste tipo de operação, a cada ocorrência é guardado o TimeStamp do tuplo modificado mais recente- mente, o que permite que, na execução seguinte, apenas sejam transferidos os tuplos cujo TimeStampé posterior ao armazenado. É ainda possível filtrar os dados inserindo um parâ- metro na query.
1 await Objeto_SyncTable.PullAsync("query_name" + atributo_valor,
2 syncTable.Where(x => x.Atributo == atributo_valor));
Listagem 3.1: Exemplo de invocação do método PULL
É importante verificar, no entanto, que além do nome do parâmetro query name, foi acres- centado o próprio parâmetro da query a este nome, uma vez que é necessário assegurar que cada invocação deste método tem um nome exclusivo. Para cada método PULL é sempre efetuado um PUSH implícito, caso a tabela para a qual é feita a invocação tenha mudanças locais pendentes.
Este processo de troca de informação entre as cópias locais e a base de dados no servidor permite atingir um estado de eventual consistência. Não obstante, acresce a necessidade de aliar a
estes mecanismos, um outro que vise lidar com os casos em que dois ou mais clientes modificam o mesmo conjunto de informação, sem que haja uma sincronização prévia entre ambos, criando, por isso, conflitos. O Azure suporta um mecanismo otimista, que lida com situações concorrentes, assumindo que uma transação é sempre passível de ser reproduzida no servidor. Antes desta ser executada, é verificado se mais alguma operação modificou os mesmos dados. Se tal se verificar a transação é cancelada e é emitido um erro passível de ser tratado no contexto da aplicação e que deve acionar um mecanismo que reponha a consistência entre as duas versões dos dados. O caso mais simples passa por escolher entre manter a versão do servidor ou a versão do cliente onde foi detetado o erro.
A utilização do serviço Azure Mobile Apps permite então a criação de uma arquitetura Multi- Masterde bases de dados distribuídas, baseada na replicação da base de dados do servidor em cada um dos dispositivos móveis do cliente. Cada uma destas cópias é passível de ser alterada, sendo a propagação de informação feita de forma assíncrona, através de mecanismos já explanados, visando que seja atingido um estado de eventual consistência. No entanto, tal como verificamos ao longo da descrição até então feita, para que seja possível modificar a informação e encetar, posteriormente, tarefas de sincronização e de resolução de conflitos é necessário que o nosso modelo de dados contemple certos atributos:
• Id (uma string - normalmente um GUID5- que deve ser única em todo o sistema) - Obriga-
tório
• CreatedAt (do tipo DateTimeOffset - regista a data e o tempo de criação do tuplo) - Opcional
• UpdatedAt (do tipo DateTimeOffset - suportado automaticamente pelo SDK - utilizado, con- forme supramencionado, para a questão da sincronização incremental, regista a data e o tempo da última atualização) - Opcional
• Version (uma string - utilizado para identificar e resolver conflitos) - Opcional
• Deleted (um booleano - usado para sinalizar a eliminação de um tuplo e removê-lo do ar- mazenamento local - conhecido como soft delete).
5Valor de 128 bits que visa ser único no contexto do sistema em que é criado. Embora o seu processo de geração não
garanta a sua unicidade, o número de valores passíveis de serem gerados é tão grande que a probabilidade se aproxima de zero, sendo por isso insignificante
1 public string Id { get; set; }
2
3 [Version]
4 public string Version { get; set; }
5
6 [CreatedAt]
7 public DateTimeOffset CreatedAt { get; set; }
8
9 [UpdatedAt]
10 public DateTimeOffset UpdatedAt { get; set; }
11
12 [Deleted]
13 public bool Deleted { get; set; }
Listagem 3.2: Atributos do Modelo de Dados - Cliente
Graças à disponibilização destes serviços o Azure tornou-se na plataforma ideal para hospedar não só a base de dados que suporta todo o sistema, mas também a camada de serviços da qual depende a aplicação.
A concretização da prova de conceito resultou então numa aplicação móvel desenvolvida e desenhada utilizando Xamarin.Forms e cujas funcionalidades de acesso à base de dados e funcio- namento offline são suportadas pelo SDK disponibilizado pelo Azure.
Figura 3.3: Esquemática da arquitetura do Sistema - Tecnologias
3.3.2.2 Microsoft Azure Machine Learning Studio
O serviço de computação na nuvem da Microsoft disponibiliza, no contexto da sua oferta de Plataforma como Serviço, mais um produto inovador, o Azure Machine Learning Studio. Criado em 2015, visa oferecer uma plataforma colaborativa para o desenvolvimento de modelos de Ma- chine Learning de uma forma rápida e simples. Para tal, esta ferramenta oferece ao utilizador uma área de trabalho que permite estruturar um modelo através da interação com uma interface dinâmica que se baseia no conceito de drag & drop. O utilizador tem assim a possibilidade de
construir modelos através da simples conexão de vários módulos disponibilizados pelo software, sem qualquer necessidade de programação. Contudo, caso seja útil a utilização de scripts em Pythonou R é possível coadunar as duas realidades.
Figura 3.4: Interface do Azure Machine Learning Studio6
De forma a construir o nosso modelo necessitamos, em primeiro lugar, de dados. Além da pla- taforma de desenvolvimento, o Microsoft Azure Machine Learning Studio providencia múltiplas amostras de datasets de teste para os mais variados problemas, bem como exemplos que fazem uso destes mesmos datasets, presentes na Cortana Intelligence Gallery7. Não obstante, e ainda mais importante, estão, igualmente, ao dispor do utilizador múltiplas ferramentas para a inserção dos seus próprios conjuntos de dados através de ficheiros em formato CSV, Excel, TSV, ARFF, ou ZIP, ou fontes de dados externas como o Apache Hive, o Azure Blob Storage, ou uma base de da- dos Azure SQL. O tipo dos dados importados é automaticamente reconhecido caso sejam strings, inteiros, doubles, booleanos, ou do tipo DateTime e TimeSpan.
Estes dados que são utilizados para a criação dos modelos são frequentemente obtidos através da análise e recolha de observações da realidade e misturam, normalmente, várias fontes, estando, por isso, sujeitos a grandes quantidades de ruído e podendo conter inconsistências, ou valores em falta. A ferramenta da Microsoft também dá resposta a esta questão e oferece múltiplos mecanis- mos de tratamento e preparação dos datasets que permitem nomeadamente:
• Tratamento de incongruências nos valores do dataset, incluindo problemas de alinhamento das várias colunas, ou de text encoding que originam perdas de informação.
6Adaptação da imagem emhttps://azure.microsoft.com/pt-pt/services/machine-learning/ 7https://gallery.cortanaintelligence.com/
• Tratamento de valores em falta, através da sua remoção ou aplicação de técnicas de preen- chimento (ex:Preenchimento com o valor da média dos restantes valores). Permite ainda a deteção e remoção de ruído e de outliers.
• Transformação dos Dados - Mudar a escala dos dados numéricos através da aplicação de técnicas de normalização.
• Aplicação de técnicas que permitam a redução do volume de dados - Data Reduction • Aplicação de técnicas que convertam valores contínuos em valores discretos. Este tipo de
transformação é necessária para a aplicação de certos algoritmos de Machine Learning que necessitam que os valores presentes no dataset se enquadrem num intervalo fixo de valores, de modo a conseguirem detetar padrões e subsequentemente construir o modelo.
Uma vez construído o dataset e analisadas as suas peculiaridades, surge a questão da esco- lha do algoritmo certo, ou seja, daquele que melhor se adeque quer à estrutura do conjunto de dados, quer ao tipo de pergunta que o analista visa ver respondida. O Azure Machine Learning Studiooferece mais de duas dezenas de algoritmos de Machine Learning, otimizados, que podem ser agrupados em cinco categorias distintas: Algoritmos de Clustering, Deteção de Anomalias, Algoritmos de Regressão, Classificação binária (2 Classes) e Classificação Multi-Classe. O leque de opções é ainda alargado pela disponibilização de módulos nas áreas de Visão por Computador, Análise de Texto e Análise Estatística. No contexto desta dissertação, o intuito é prever o valor das vendas de cada produto comercializado pelo Ponto de Venda - problema de regressão - pelo que a oferta recai nos oito métodos seguintes, alguns dos quais já abordados no capítulo anterior (informação baseada na documentação oficial8):
1. Regressão Ordinal - Utilizada para prever valores numéricos que representam uma certa ordem e não uma medida (ex: ordem de chegada de atletas numa corrida)
2. Regressão de Poisson - Este tipo de método deve ser aplicado a valores numéricos, não negativos, que sigam uma distribuição de Poisson. Estes valores representam, normalmente, uma contagem.
3. Regressão Linear - Possivelmente a escolha mais simples para a construção de um modelo de regressão. A regressão linear tenta descobrir uma relação linear que correlacione as variáveis independentes do conjunto de dados e os dados de saída, de modo a conseguir efetuar previsões. Apesar de ser um método rápido e simples, poderá revelar-se, por vezes, demasiado simples.
4. Regressão Linear de Bayes - Variação do método de regressão linear baseado no método estatístico de Bayes. Neste caso, a construção do modelo não tem como output uma única previsão, sendo obtida uma distribuição probabilística que representa o grau de certeza para cada valor que a nossa inferência poderá tomar.
5. Redes Neuronais - No contexto do Azure Machine Learning Studio, as redes neuronais baseiam-se na criação de grafos acíclicos, ou seja, as features de entrada são passadas, sequencialmente, por um conjunto de camadas, nas quais são sujeitas à aplicação de pesos e cujo output é somado, até ser obtido um valor de saída.
6. Decision Forests - Uma de três variações do método tradicional de árvores de decisão. Este baseia-se na criação de um conjunto de árvores de decisão a partir do qual é obtida a pre- visão. Apesar de consumir bastante memória, o resultado previne a criação de modelos demasiado ajustados aos dados - fenómeno de Overfitting.
7. Boosted Decision Tree - Neste caso é construída uma sequência de árvores de decisão. Cada árvore tenta compensar o erro da árvore anterior. O modelo criado apesar de ser bastante