BR112014016099B1 - método para topologias de borda de nuvem e sistema para topologias de ponta de nuvem - Google Patents

Abstract

MEIO DE ARMAZENAMENTO CONTENDO TOPOLOGIA DE BORDA DE NUVEM. A invenção refere-se a topologias de borda de nuvem (104). Alguns aspectos referem-se a aplicações de borda de nuvem (104) e utilização de recursos em várias topologias de borda de nuvem (104). Outro aspecto das presentes topologias de borda de nuvem (104) pode referir à especificação de aplicações de borda de nuvem (104) que utilizam uma linguagem temporal. Um aspecto adicional pode envolver uma arquitetura que executa máquinas de sistemas de gerenciamento de fluxo de dados (DSMSs) sobre a nuvem (104) e computadores de borda de nuvem (104) para executar partes de consulta.

Description

FUNDAMENTOS

[001] A adoção difundida de dispositivos de computação portáteis 'inteligentes', tal como smartphones, por consumidores e a disponibilidade de vastas quantidades de recursos de computação baseados em nuvem levaram ao que é conhecido como a "topologia de borda de nuvem". Os dispositivos de computação portáteis inteligentes são denominados 'inteligentes pelo fato de que os avanços de processador e memória permitem que estes dispositivos tenham substanciais recursos de computação disponíveis para o usuário. Os dispositivos de computação portáteis inteligentes podem gerar dados em tempo real tal como localização de GPS, consumo de bateria, velocidade etc.. Estes dispositivos de computação portáteis inteligentes podem também ser imaginados como dispositivos de borda de nuvem em que a comunicação entre um dispositivo individual e os recursos baseados em nuvem pode ser imaginada como uma borda.

[002] Dados os substanciais recursos de computação disponíveis sobre o dispositivo de computação portátil inteligente, o usuário pode selecionar várias aplicações para executar no seu dispositivo. Muitas destas aplicações podem ser denominadas como aplicações de borda de nuvem em que uma instância de aplicação executa no dispositivo de computação portátil inteligente e outra instância de aplicação executa nos recursos de computação baseados em nuvem. Existe uma ampla classe de aplicações de borda de nuvem que correlacionam dados através de múltiplos dispositivos de computação portáteis inteligentes e a nuvem para conseguir a funcionalidade da aplicação. Um exemplo é uma aplicação de encontro de amigos que funciona para notificar um usuário se qualquer amigo está próximo. Esta funcionalidade de aplicação depende da correlação de localizações em tempo real e dados de mudança lenta tal como as redes sociais. Apesar de grandes quantidades de recursos de computação serem disponíveis sobre os dispositivos de computação portáteis inteligentes e os recursos baseados em nuvem, a utilização de recursos, tal como os recursos de comunicação, pode ser significativa quando grandes números de dispositivos de computação portáteis inteligentes estão executando aplicações de borda de nuvem.

SUMÁRIO

[003] A descrição refere-se a topologias de borda de nuvem. Alguns aspectos referem-se a aplicações de borda de nuvem e utilização de recursos em várias topologias de borda de nuvem. Um exemplo pode avaliar uma consulta de fluxo de tempo real que utiliza dados de múltiplos diferentes dispositivos de computação de borda. Os múltiplos diferentes dispositivos de computação de borda podem estar configurados para comunicar com recursos baseados em nuvem mas não para comunicar diretamente uns com os outros. Os dispositivos de computação de borda individuais incluem uma instanciação de uma aplicação transportada em uma linguagem temporal declarativa. Este exemplo pode comparar a utilização de recursos entre um primeiro e um segundo cenários. O primeiro cenário envolve carregar dados de consulta dos múltiplos diferentes dispositivos de computação para os recursos baseados em nuvem para processamento. O segundo cenário envolve carregar os dados de consulta de todos menos um nodo dos múltiplos diferentes dispositivos de computação para os recursos baseados em nuvem e descarregar os dados de consulta para aquele nodo dos múltiplos diferentes dispositivos de computação de borda para processamento.

[004] Outro aspecto das presentes topologias de borda de nuvem podem referir à especificação de aplicações de borda de nuvem que utilizam uma linguagem temporal. Um aspecto adicional pode envolver uma arquitetura que executa máquinas de sistemas de gerenciamento de fluxo de dados (DSMSs) sobre a nuvem e computadores de borda de nuvem para executar partes de consulta.

[005] Os exemplos acima listados pretendem prover uma rápida referência para auxiliar o leitor e não pretendem definir o escopo dos conceitos aqui descritos.

BREVE DESCRIÇÃO DOS DESENHOS

[006] Os desenhos acompanhantes ilustram implementações dos conceitos conduzidos no presente pedido. As características das implementações ilustradas podem ser mais prontamente compreendidas por referência à descrição seguinte tomada em conjunto com os desenhos acompanhantes. Os números de referência iguais nos vários desenhos são utilizados sempre que factível para indicar elementos iguais. Ainda, o número mais à esquerda de cada número de referência conduz a figura e a discussão associada onde o número de referência é primeiro introduzido.

[007] A Figura 1 mostra um exemplo de um sistema para o qual os conceitos de utilização de recurso de aplicação de borda de nuvem presentes podem ser aplicados de acordo com algumas implementações.

[008] A Figura 2 mostra um exemplo de uma arquitetura de sistema para o qual os conceitos de utilização de recurso de aplicação de borda de nuvem presentes podem ser aplicados de acordo com algumas implementações.

[009] A Figuras 3 a 9 mostram exemplos de gráficos aos quais os para o quais os conceitos de utilização de recurso de aplicação de borda de nuvem presentes podem ser aplicados de acordo com algumas implementações.

[0010] A Figura 10 mostra um fluxograma de um exemplo de técnicas de utilização de recurso de aplicação de borda de nuvem de acordo com algumas implementações dos presentes conceitos.

DESCRIÇÃO DETALHADA

[0011] Os presentes conceitos referem-se a sistemas baseados em nuvem e processamento ciente de recursos, dinâmico por aplicações que executam em sistemas baseados em nuvem e dispositivos conectados.

[0012] Para os propósitos de explicação considere a Figura 1 introdutória, a qual mostra um exemplo de um sistema 100 o qual pode implementar os presentes conceitos. O sistema 100 inclui três dispositivos de computação de borda de nuvem (daqui em diante, "dispositivos de computação") 102(1), 102(2), e 102(N) (onde N significa que qualquer número de dispositivos de computação poderia ser utilizado). Os dispositivos de computação 102(1)-102(N) podem comunicar com a nuvem 104 através de uma rede 106 como indicado pelas linhas 108(1)-108(3), respectivamente. Neste exemplo, dispositivos de computação individual podem comunicar uns com os outros através da nuvem 104, mas não diretamente com outros dispositivos de computação. A nuvem 104 pode oferecer vastas quantidades de recursos de computação 110, apesar da localização física exata destes recursos de computação poder não ser prontamente aparente. A computação em nuvem continua a ganhar popularidade devido aos recursos de computação relativamente baratos e extensos que esta oferece.

[0013] Os dispositivos de computação 102(1)-102(N) podem ser qualquer tipo de dispositivos de computação. Comumente estes dispositivos de computação são dispositivos de computação portáteis tal como smartphones e computadores tablet. O termo "computador" ou "dispositivo de computação"como aqui utilizado pode significar qualquer tipo de dispositivo que tem alguma quantidade de capacidade de processamento. Apesar de exemplos específicos de tais dispositivos serem ilustrados para propósitos de explicação, outros exemplos de tais dispositivos podem incluir os dispositivos de computação tradicionais, tal como computadores pessoais, telefones celulares, smartphones, assistentes digitais pessoais, ou qualquer de uma miríade de tipos de dispositivos sempre em evolução ou ainda a serem desenvolvidos. Ainda, ao invés de ser independente, um computador pode ser incorporado em outro dispositivo. Por exemplo, um computador de painel pode ser incluído em um carro ou outro veículo.

[0014] Visto de uma perspectiva, os dispositivos de computação 102(1)102(N) podem ser imaginados como 'dispositivos de borda' em uma topologia suportada pela nuvem 104 e a rede 106. Muitos destes dispositivos de borda estão equipados com sensores que produzem fluxos frequentes ou contínuos de dados em tempo real tal como a localização de GPS de um usuário, a velocidade, a atividade corrente, a utilização de bateria do dispositivo etc.. Além disso, pode existir uma quantidade crescente de dados de referência que mudam lentamente, tal como gráficos de rede social e preços de combustível em postos de gasolina sendo tornados disponíveis na nuvem, por exemplo, através de mercados de dados. Esta proliferação de dispositivos de computação e dados alimentaram um interesse crescente em uma classe emergente de aplicações em tempo real de borda de nuvem (ou, aplicativos de borda de nuvem para abreviar). Estes aplicativos de borda de nuvem podem prover serviços, tal como notificações ou recomendações com base em fluxos em tempo real coletados de um grande número de dispositivos de computação de borda e da nuvem.

[0015] Em alguns cenários, os dispositivos de computação 102(1)- 102(N) comunicam os seus dados para a nuvem 104 para processamento por um ou mais provedores de serviço que executam nos recursos de computação de nuvem 110. Por exemplo, assuma para propósitos de explicação que um tal serviço é um serviço de encontro de amigos que notifica um usuário sempre que qualquer de seus amigos está próximo de sua localização corrente. Em algumas implementações, o serviço de encontro de amigos pode ser executado por uma aplicação de encontro de amigos que executa nos recursos de computação de nuvem 110 e aplicações de encontro de amigos correspondentes que executam em dispositivos de computação individuais 102(1)-102(N).

[0016] A permissão da aplicação de encontro de amigos permite uma correlação de localizações em tempo real de smartphones dos usuários (por exemplo, os dispositivos de computação 102(1)-102(N)) assim como os dados de referência que mudam lentamente tal como uma rede social (que define a relação de amigo). Para facilidade de explicação considere somente os dispositivos de computação 102(1) e 102(2) e assuma que o dispositivo de computação 102(1) pertence ao User1 e que o dispositivo de computação 102(2) pertence ao User2. Ainda, assuma que o User1 e o User2 foram considerados como 'amigos'. Cada dispositivo de computação de tempos em tempos carrega dados para a nuvem como indicado pelas setas 112(1) e 112(2). Os dados carregados podem ser processados pelo provedor de serviço que opera nos recursos de computação de nuvem 110. O provedor de serviço pode determinar os resultados para cada dispositivo de computação e comunicar estes resultados de volta para os respectivos dispositivos de computação 102(1) e 102(2). Em alguns casos, tal processo pode gerar altos números de comunicações de carregamento e descarregamento sobre a rede 106 entre a nuvem 104 e os dispositivos de computação 102(1) e 102(2). Os presentes conceitos podem permitir uma opção alternativa. Esta opção alternativa pode ser imaginada como uma opção ciente de recurso dinâmico. Na opção ciente de recurso dinâmico, um dos dispositivos de computação 102(1) e 102(2) pode determinar que a utilização de recurso de sistema, tal como aquelas comunicações de rede, podem ser reduzidas pelo dispositivo de computação individual obtendo os dados do outro dispositivo de computação da nuvem e manipulando o processamento localmente no dispositivo de computação individual. (As comunicações de rede podem ser consideradas por número e/ou utilização de largura de banda de rede). Em tal caso, o dispositivo de computação individual não carrega. Os outros dispositivos de computação (restantes) carregam como normal, e o dispositivo de computação individual descarrega. Esta opção ciente de recurso dinâmica pode ser imaginada como dinâmica em que os cálculos de utilização de recurso podem mudar conforme o cenário muda. Um tal exemplo está abaixo descrito em relação a uma taxa na qual um dispositivo de computação está gerando dados de localização. Os cálculos de utilização de recursos podem produzir um diferente resultado quando a taxa de dados de localização muda. Assim, ao invés de ser uma determinação de uma vez, a determinação pode ser repetida em um modo iterativo conforme as condições ou os parâmetros mudam.

[0017] Para ilustrar esta utilização de recursos reduzida, suponha que o dispositivo de computação 102(1) pertença ao User1 e que o dispositivo de computação 102(2) pertença ao User2. Ainda assuma que o User1 está trabalhando em seu escritório (por exemplo, relativamente estacionário) e o User2 está dirigindo em uma vizinhança nas proximidades. Na configuração fixa acima descrita, uma aplicação de encontro de amigos existente requererá que o User2 (dispositivo de computação 102(2) carregue (112(2))) a sua localização frequentemente (digamos, uma vez a cada 10 segundos) de modo que a nuvem saiba a sua localização atualizada para correlacionar com a localização do User1. O User1 (dispositivo de computação 102(1)), no entanto, pode carregar (112(1)) a sua localização infrequentemente (digamos, uma vez por hora) já que ele/ela não está movendo muito. Neste exemplo, o excesso de comunicação total de User1 e User2 será 361 mensagens por hora (ignorando as mensagens de notificação finais) sobre a rede 106. Esta utilização de rede pode ser dispendiosa, especialmente quando um usuário tem muitos amigos ou executa muitos tais aplicativos. Isto pode severamente limitar a utilidade da aplicação já que esta é forçada a limitar quão frequentemente correlacionar os dados dos usuários, o que se traduz em uma alta latência de notificação. Mais ainda, os usuários podem simplesmente desligar a aplicação devido à sua alta utilização de recursos. No entanto, esta ineficiência pode ser resolvida facilmente no exemplo acima com a opção ciente de recurso dinâmica. Ao invés de utilizar uma metodologia de correlacionar na nuvem, a localização do User1 pode ser enviada para o dispositivo de computação 102(2) do User2 (através da nuvem 104 como indicado pelas setas 114 e 116, respectivamente). A correlação pode então ser executada pelo dispositivo de computação do User2. Neste caso, o User2 não precisa enviar a sua localização para qualquer lugar e o custo total se tornaria somente 2 mensagens por hora (uma do User1 para a nuvem, e a outra da nuvem para o User2). Note que em um subsequente ponto no tempo, tal como o User1 está voltando para casa, a opção ciente de recurso dinâmico pode determinar uma diferente proposta, tal como processando na nuvem 104.

[0018] Em suma, a opção ciente de recurso dinâmico pode determinar qual (se alguma) computação empurrar, e para qual dispositivo de computação de borda empurrá-la. A determinação pode ser imaginada como um problema de otimização que depende de vários fatores tais como a topologia de rede, taxas de fluxos de dados, custos de upload e download de dados, pares de fluxos a correlacionar, etc. Mais ainda, como estes parâmetros podem mudar ao longo do tempo (por exemplo, a taxa do User1 pode mudar quando ele/ela começa a viajar após o horário de escritório), a determinação pode ser dinamicamente atualizada. Uma implementação de opção ciente de recurso dinâmico é referida como RACE e está abaixo descrita em detalhes.

[0019] Brevemente, RACE (que significa Aplicações em Tempo Real Sobre Borda de Nuvem), é uma estrutura e sistema para especificar e eficientemente executar os aplicativos de borda de nuvem. RACE pode utilizar técnicas de banco de dados para resolver dois aspectos principais. Primeiro, RACE resolve a especificação de aplicações de borda de nuvem em tempo real. Segundo, RACE resolve a utilização de recurso de sistema associada com a execução das aplicações e borda de nuvem em tempo real. A utilização de recursos de sistema pode ser melhorada e/ou otimizada (daqui em diante, para o bem da brevidade, o termo "otimizado" significa "melhorado e/ou otimizado").

ESPECIFICAÇÃO DE APLICAÇÕES DE BORDA DE NUVEM

[0020] RACE resolve a especificação de aplicações de borda de nuvem em tempo real abstraindo a lógica de núcleo de aplicativos de borda de nuvem como consultas contínuas (CQs) agnósticas de plataforma sobre um conjunto de fontes de dados de fluxo.

[0021] Os aplicativos de borda de nuvem são frequentemente escritos em linguagens imperativas padrão tal como Objective C, Java ou C#. Os desenvolvedores de aplicações são requeridos implementar manualmente mecanismos que lidam com as comunicações de dispositivo cruzado, publicação e subscrição a fluxos de dados, e semânticas relativas ao tempo na lógica de aplicação tal como junções temporais e computações em janela. Este processo é demorado e passível de erro. RACE pode adicionar um suporte de plataforma para as funcionalidades comuns compartilhadas pela maioria dos aplicativos de borda de nuvem. Os projetistas de aplicações podem então focalizar sobre a lógica de aplicação de núcleo, ao invés dos detalhes de implementação.

[0022] As presentes implementações alavancam o fato que apesar de diferentes aplicativos de borda de nuvem terem diversas características específicas de aplicação (por exemplo, visualização e suporte para privacidade), estes podem compartilhar alguns pontos em comum. Por exemplo, tanto os dados quanto a lógica de aplicação de núcleo para os aplicativos de borda de nuvem são frequentemente temporais em natureza. Em outras palavras, os aplicativos de borda de nuvem podem ser vistos como consultas contínuas que continuamente correlacionam dados de referência em tempo real e que mudam lentamente (mas ainda temporais) em um sistema massivamente distribuído.

[0023] Por exemplo, o aplicativo friend-finder pode ser imaginado como uma junção temporal entre as localizações de GPS em tempo real de dispositivos de borda e um fluxo de rede social de mudança lenta. Uma aplicação de cupom ciente de localização correlaciona as informações de localização de usuário correntes com os perfis do usuário (computados sobre uma janela de tempo histórica) e anúncios correntes. Assim, em algumas implementações, a linguagem de especificação para os aplicativos de borda de nuvem devem conter um suporte nativo para a semântica temporal. Tal suporte permite uma limpa expressão de operações orientadas em tempo tal como junções temporais e agregações em janela. Alternativamente ou além disso, a linguagem pode ter outras propriedades. Por exemplo, uma tal propriedade é a natureza declarativa da linguagem de especificação. Isto pode permitir os projetistas de aplicação especificar as aplicações em um modo declarativo e agnóstico de topologia de rede, onde estes podem focalizar sobre "o que" as aplicações são, ao invés de "como" estas são implementadas. Os detalhes de implementação podem ser transparentes para os projetistas de aplicação, e ao invés ser manipulados automaticamente pela plataforma subjacente. Outra propriedade pode referir à concisão. A especificação de aplicações pode ser sucinta, permitindo um protótipo produtivo, desenvolvimento, e depuração pelos projetistas de aplicação. A concisão está alinhada naturalmente com a adoção de especificações declarativas. A flexibilidade pode ser outra propriedade. A linguagem de especificação pode ser flexível, de modo que os projetistas de aplicação possam facilmente customizar a aplicação de acordo com diferentes fontes e configurações de entrada/saída.

[0024] O espaço de projeto de linguagem de especificação será agora descrito à luz destas propriedades. As linguagens declarativas tais como SQL e Datalog (e suas variantes, por exemplo, Network Datalog) podem permitir uma especificação sucinta e flexível de consultas contínuas em ambientes distribuídos. No entanto, estas linguagens não têm um suporte nativo para semântica temporal, o que pode ser crucial para a maioria dos aplicativos de borda de nuvem. Por outro lado, os sistemas de gerenciamento de fluxo de dados (DSMSs) utilizam linguagens temporais declarativas que satisfazem as propriedades desejadas. Exemplos incluem LINQ™ para Streamlnsight™, e StreamSQL™ para Oracle® CEP, e StreamBase™. A descrição abaixo utiliza LINQ para Streamlnsight como a linguagem de especificação, mas é aplicável a outras configurações. LINQ permite a especificação declarativa de consultas temporais, e está baseado em uma álgebra e semântica bem definidas que se ajustam bem como a natureza temporal de aplicativos de borda de nuvem.

[0025] A discussão que segue provê um exemplo de uma especificação de aplicativo de borda de nuvem. Lembrar que a consulta de friend-finder encontra todos os pares de usuário (User1, User2) que satisfazem as condições: 1) User2 é um amigo de User1; e 2) os dois usuários estão geograficamente pertos um do outro em um dado tempo. Neste ponto, para propósitos de explicação, assuma que a relação de amigo é assimétrica, isto é, o User2 sendo um amigo do User1 não necessariamente implica o contrário, dado um ponto no tempo. Existem duas entradas para o aplicativo friend-finder, a saber, os fluxos de localização de GPS reportados pelos dispositivos de borda, e os dados de rede social. As localizações de GPS são ativamente coletadas no tempo de execução, enquanto que os dados de rede social são de mudança relativamente lenta e estão geralmente disponíveis na nuvem. Friend-finder pode ser escrito como uma consulta junta temporal de dois estágios como abaixo ilustrado.

[0026] A primeira consulta (query0) junta o fluxo de localização de GPS (localização) com o fluxo de referência de rede social (socialNetwork), e o fluxo de saída resultante é juntado com as localizações de GPS (em query1), para verificar a distância entre cada par de amigos. A saída final é um fluxo de pares (User1, User2) onde os dois usuários são amigos e estão geograficamente pertos um do outro.

[0027] A especificação de consulta acima define a lógica de alto nível da consulta como junções temporais, e referencia os esquemas do fluxo de localização e fluxo de socialNetwork. Esta é escrita sobre o fluxo de rede social e uma entrada de fluxo de localização de GPS conceitualmente unificada, e é assim agnóstica de topologia de rede. Como outro exemplo, assuma que uma função desejada é encontrar amigos que visitaram uma localização específica (digamos um restaurante) dentro da última semana. Para especificar isto, os presentes conceitos podem permitir substituir a entrada de localização em query1 por location.AlterEventDuration(TimeSpan.FromDays(7)). Isto estende o "tempo de vida" de eventos de localização para 7 dias, permitindo a junção considerar eventos de amigos dentro da última semana.

[0028] Em suma, RACE pode utilizar uma especificação declarativa de um aplicativo de nuvem. RACE pode executar a lógica no sistema distribuído compostos dos dispositivos de borda e a nuvem. RACE pode utilizar um DSMS não modificado como uma caixa preta para localmente executar as consultas sobre os dispositivos de borda individuais e a nuvem. Algumas implementações de RACE podem operar na suposição que o DSMS provê uma interface de programa de aplicação de gerenciamento (API) para os usuários submeterem as consultas (que definem as consultas contínuas a serem executadas), tipos de eventos (que especificam o esquema de fluxos de dados de entrada), e adaptadores de entrada e saída (que definem como os dados de fluxo alcançam o DSMS do mundo exterior e vice versa). Ainda, a API também permite os usuários iniciar e parar as consultas sobre o DSMS.

[0029] Apresentado de outro modo, algumas implementações podem mover diferentes fluxos de dados (ou partes de fluxos) para a nuvem e/ou para outros dispositivos de computação de borda através da nuvem. Alguns outros fluxos de dados podem ser retidos localmente no dispositivo e não carregados na nuvem. Ainda, estes vários fluxos (movidos e locais) podem servir como entradas para os segmentos de consulta de aplicação que executam em várias localizações (tal como um subconjunto dos dispositivos ou mesmo na nuvem). Os fluxos de saída de tais consultas estes próprios podem ou ser retidos localmente para computações adicionais ou carregados para a nuvem (e então possivelmente transferidos para outros dispositivos). No geral, a computação especificada pelo usuário final pode ser executada em um modo distribuído.

ARQUITETURA DE RACE

[0030] A Figura 2 mostra um sistema geral ou arquitetura de sistema 200 de uma implementação de RACE. A arquitetura de sistema 200 carrega os dispositivos de computação 102(1)-102(N), a nuvem 104, e a rede 106 da Figura 1. A arquitetura de sistema 200 introduz um servido de gerenciamento de RACE 202 e um processador de RACE 204. O processador de RACE inclui um construtor de gráfico 206, um otimizador 208, e um construtor de consulta 210. A arquitetura de sistema 200 também inclui dados estatísticos 214, dados de referência 216, um plano de controle 218, e um plano de dados 220. Os dispositivos de computação 102(1)-102(N) incluem uma instância de DSMS 222(1)-222(3), respectivamente. Uma instância de DSMS 222(4) também ocorre na nuvem 104.

[0031] A arquitetura de sistema 200 está explicada em relação a uma experiência provida para um desenvolvedor de aplicação 224. O desenvolvedor de aplicação pode interagir com o serviço de gerenciamento de RACE 202 escrevendo uma aplicação em uma linguagem declarativa e temporal, tal como LINQ 226. Assuma para propósitos de explicação que a aplicação é um aplicativo friend-finder 228. A funcionalidade dos aplicativos friend-finder foi introduzida acima com relação à Figura 1. O aplicativo friend-finder 228 pode manifestar sobre os dispositivos de computação individuais 102(1)-102(N) como instanciações de aplicativo friend-finder 228(1)-228(3), respectivamente e sobre a nuvem 104 como instanciações de aplicativo friend-finder 228(4). Ainda, apesar de somente ilustrados em relação ao dispositivo de computação 102(1) para o bem da brevidade, os dispositivos de computação individuais podem incluir vários hardwares 230. Neste exemplo, o hardware ilustrado é um processador 232, um armazenamento 234, e outro 236. Os elementos acima mencionados estão abaixo descritos em mais detalhes.

[0032] O processador 232 pode executar os dados na forma de instruções legíveis por computador para prover uma funcionalidade, tal como uma funcionalidade de friend-finder. Os dados, tal como instruções legíveis por computador, podem ser armazenados no armazenamento 234. O armazenamento pode ser interno ou externo ao dispositivo de computação. O armazenamento 234 pode incluir qualquer uma ou mais de memória volátil ou não volátil, discos rígidos e/ou dispositivos de armazenamento ótico (por exemplo, CDs, DVDs etc..), entre outros.

[0033] O computador 102(1) pode também estar configurado para receber e/ou gerar dados na forma de instruções legíveis por computador do armazenamento 234. O computador 102(1) pode também receber dados na forma de instruções legíveis por computador sobre a rede 106 que são então armazenados no computador para execução por seu processador.

[0034] Em uma configuração alternativa, o computador 102(1) pode ser implementado como um projeto do tipo de sistema em um chip (SOC). Em tal caso, a funcionalidade provida pelo computador pode estar integrada em um único SOC ou múltiplos SOCs acoplados. Em algumas configurações, os dispositivos de computação pode incluir recursos compartilhados e recursos dedicados. Uma(s) interface(s) facilita(m) a comunicação entre os recursos compartilhados e os recursos dedicados. Como o nome implica, os recursos dedicados podem ser imaginados como incluindo porções individuais que são dedicadas a atingir funcionalidades específicas. Os recursos compartilhados podem ser um armazenamento, unidades de processamento etc.. que podem ser utilizados por múltiplas funcionalidades.

[0035] Geralmente, qualquer uma das funções aqui descritas pode ser implementada utilizando software, firmware, hardware (por exemplo, circuito de lógica fixa), processamento manual, ou uma combinação destas implementações. Os termos "ferramenta", "componente", ou "módulo"como aqui utilizado geralmente representa software, firmware, hardware, dispositivos inteiros ou redes, ou uma sua combinação. No caso de uma implementação de software, por exemplo, estes podem representar um código de programa que executa tarefas especificadas quando executados em um processador (por exemplo, CPU ou CPUs). O código de programa pode ser armazenado em um ou mais dispositivos de memória legíveis por computador, tal como uma mídia de armazenamento legível por computador. As características e técnicas do componente são independentes de plataforma, significando que estes podem ser implementados em uma variedade de plataformas de computação comerciais que têm uma variedade de configurações de processamento.

[0036] Como aqui utilizado, o termo "mídia legível por computador" pode incluir instruções transitórias e não transitórias. Em contraste, o termo "mídia de armazenamento legível por computador" exclui as instâncias transitórias. A mídia de armazenamento legível por computador pode incluir "dispositivos de armazenamento legível por computador". Exemplos de dispositivos de armazenamento legível por computador incluem mídia de armazenamento volátil, tal como RAM, e mídia de armazenamento não volátil, tal como discos rígidos, discos óticos, e memória instantânea, entre outros.

[0037] O outro hardware 236 pode incluir displays, dispositivos de entrada/saída, sensores etc.. que podem ser implementados em vários dispositivos de computação.

[0038] O serviço de gerenciamento de RACE 202 pode executar na nuvem 104 e expor um serviço de gerenciamento que é totalmente compatível com a API de gerenciamento de DSMS. Assim, os dispositivos de computação individuais 102(1)-102(N) podem submeter a sua lógica de aplicativo de borda de nuvem declarativo ao serviço de gerenciamento de RACE 202 como consultas declarativas temporais regulares suportadas pelo respectivo DSMS 222(1)-222(N). Note que da perspectiva do dispositivo de borda (por exemplo, dispositivos de 102(1)-102(N)), estes simplesmente parecem comunicar com uma máquina de DSMS normal.

[0039] Visto de outra perspectiva, o serviço de gerenciamento de RACE 202 pode ser imaginado como sendo configurado para interagir com uma aplicação que executa na nuvem e em dispositivos de computação de borda individuais em comunicação com a nuvem. O serviço de gerenciamento de RACE 202 pode ser configurado para simular uma máquina de DSMS para receber as consultas declarativas temporais dos dispositivos de computação de borda individuais.

[0040] Resumidamente, o processador de RACE 204 pode ser imaginado como interceptando e analisando a consulta que entra, adaptadores, e tipos dos dispositivos de computação individuais 102(1)-102(N) que executar o aplicativo friend-finder 228. O processador de RACE 204 então compila estas entradas em uma representação de objeto da consulta original. A representação de objeto é passada para o módulo de construtor de gráfico 206 que converte a consulta original em um gráfico de consulta maior. Por exemplo, o gráfico de consulta maior pode incluir fluxos de entrada por borda e operadores. O gráfico de consulta é passado para o módulo de otimizador 208 para decidir a colocação de operador ótima. Finalmente o módulo de construtor de consulta 210 pode gerar representações de objeto de tipos, adaptadores, e (sub)consultas a serem executados no dispositivo de computação individual 102(1)- 102(N) ou na nuvem 104. Estes objetos são enviados para os DSMSs individuais (através de suas APIs de gerenciamento) dos respectivos dispositivos de computação para executar a lógica de aplicação em um modo distribuído. Note que enquanto que nesta configuração, o serviço de gerenciamento de RACE 202 e o processador de RACE 204 estão implementados na nuvem 104, em outras implementações, alternativamente ou adicionalmente, o serviço de gerenciamento de RACE e/ou o processador de RACE poderiam ser implementados em um ou mais dos dispositivos de computação 102(1)-102(N). O serviço de gerenciamento de RACE e/ou o processador de RACE implementados nos dispositivos de computação poderiam ser independentes ou funcionarem em um modo cooperativo com as instanciações do serviço de gerenciamento de RACE e/ou do processador de RACE correspondentes na nuvem.

[0041] O construtor de gráfico 206 pode ser imaginado como tomando a representação de objeto de uma consulta como uma entrada, juntamente com estatísticas sobre taxas de fluxo e informações de metadados sobre cada entrada. O construtor de gráfico primeiro pode utilizar a representação de objeto da consulta para gerar um padrão de consulta, o que representa um gabarito ou esqueleto para a geração do gráfico de consulta expandido. Por exemplo, a Figura 3 ilustra o padrão de consulta 302 emitido pelo construtor de gráfico 206 para a consulta de friend-finder acima descrita em relação ao parágrafo 25.

[0042] Alguns dos fluxos de entrada no padrão de consulta 302 referem-se a fluxos de dados por dispositivo tal como fontes de localização de GPS. O construtor de gráfico 206 pode criar múltiplas instâncias do padrão de consulta dividindo tais fluxos em múltiplas entradas, uma por borda. As entradas de dados por referência que mudam lentamente, tal como a rede social, podem ser materializadas para limitar o tamanho do gráfico de consulta gerado. Por exemplo, a Figura 4 mostra uma rede social 400 de quatro usuários P, Q, R, e S. A Figura 5 mostra os padrões de consulta instanciados correspondentes 502(1), 502(2), e 502(3) para a consulta de friendfinder. Note que de modo a permitir o compartilhamento de informações e evitar bordas duplicadas nos padrões de consulta instanciados, a fonte instanciada e os operadores juntos são nomeados cuidadosamente, como mostrado na Figura 5. A etapa final é costurar os padrões de consulta instanciados 502(1)-502(3) em um gráfico de consulta completo.

[0043] A Figura 6 mostra um gráfico de consulta final 602 derivado dos padrões de consulta instanciados mostrados na Figura 5. Note que quando combinando os padrões de consulta instanciados, os vértices (nos padrões instanciados) com o mesmo nome são mapeados para o mesmo vértice no gráfico de consulta final. Por exemplo, o vértice Join<GPS-P, SNP >é compartilhado pelos padrões instanciados para as bordas (P; R) e (P; S).

[0044] Retornando à Figura 2, o módulo de otimizador 208 aceita o gráfico de consulta final 602 como entrada, e decide onde executar cada operador (por exemplo, parte de consulta) no gráfico de consulta de modo que o custo de comunicação total ou coletiva da aplicação é minimizado (ou pelo menos reduzido). Com milhares ou mesmo milhões de usuário participando no sistema de borda de nuvem, o gráfico de consulta final poderia ser enorme - contendo milhões de operadores. Para tal grande gráfico de consulta, a colocação de operador ótima não é trivial. O módulo de Otimizador de RACE pode utilizar várias técnicas para determinar a colocação de operador ótima. Uma tal técnica abaixo descrita sob o cabeçalho "Colocação de Operador Ótima". RACE pode executar uma reotimização periódica para ajustar a colocação a mudanças no gráfico de consulta e/ou estatísticas.

[0045] Após as decisões para a colocação de operador melhorada/ótima serem feitas, o processador de RACE 204 tem um conjunto de gráficos de consulta de raiz (cada um consistindo em um gráfico acíclico direcionado (DAG) de operadores temporais. Cada tal gráfico correspondem a alguma localização (borda ou nuvem). O módulo de construtor de consulta 210 pode gerar representações de objeto dos componentes de consulta (incluindo tipos de evento, adaptadores e consultas) para cada gráfico. O módulo de construtor de consulta pode então submeter as representações de objeto ao DSMS correspondente através do plano de controle 218. Note que dois adaptadores adicionais podem ser instalados em cada instância de DSMS - um para enviar os dados de evento para o plano de dados 220, e outro para receber os dados de evento do plano de dados.

[0046] O plano de controle de RACE 218 é utilizado para posicionar os fragmentos de consulta gerados e os metadados na instância de nuvem e as instâncias de borda do DSMS, utilizando a API de gerenciamento de DSMS. Uma complicação é que os dispositivos de borda (por exemplo, telefones) usualmente não são diretamente alcançáveis ou endereçáveis do serviço de gerenciamento de RACE 202. Ao invés, o serviço de gerenciamento de RACE pode manter um servidor para o qual os dispositivos de borda criam e mantêm conexões persistentes de modo a receber comandos de gerenciamento que são transferidos para as instâncias de DSMS sobre as bordas. Durante a execução de consulta, os eventos fluem entre os dispositivos de borda e a nuvem. O serviço de gerenciamento de RACE 202 pode utilizar um plano de dados 220 separado que é exposto como um servidor na nuvem 104, e para o qual os dispositivos de computação de borda 102(1)-102(N) podem conectar através do plano de controle 218. As consultas geradas sobre os dispositivos de computação de borda e a nuvem subscrevem e publicam fluxos nomeados que estão registrados com o plano de dados 220. O plano de dados roteia os eventos da nuvem 104 para os dispositivos de computação de borda 102(1)-102(N) e vice versa.

[0047] Com milhares e até milhões de usuários participando no sistema de borda de nuvem, o gráfico de consulta final poderia ser enorme - contendo milhões de operadores. Como as fontes de dados estão distribuídas (por exemplo, fluxos de dados de GPS de vários usuários são originados de seus dispositivos de borda), a colocação de cada operador tem o seu impacto no overhead de avaliação de consulta. Existem exponencialmente muitas diferentes combinações de colocação de operadores. Uma proposta ingênua que pesquisa por todo o espaço de projeto pode não ser factível. Além disso, considerando o compartilhamento de resultados intermediários torna o problema ainda mais difícil.

[0048] A discussão seguinte refere-se a um exemplo de um algoritmo eficiente para uma ótima colocação de operador, alavancando a topologia em "estrela" especial de sistemas de borda de nuvem. Para algumas implementações, a exatidão do algoritmo pode ser provada dado as duas suposições abaixo mencionadas. Ainda, o overhead de encontrar a colocação ótima pode ser muito baixo.

[0049] Suposição 1. A saída final de consultas é relativamente muito menor do que os dados de fluxo de entrada, e portanto, o seu custo pode ser ignorado.

[0050] Esta suposição é razoável dada a natureza geral dos aplicativos de borda de nuvem, Além disso, com base em considerações de privacidade, algumas implementações podem restringir as localizações permitidas de operadores. Por exemplo, os dados de fluxo podem incluir informações pessoais confidenciais (por exemplo, os rastros de geolocalização de um telefone móvel). Um cliente de borda pode não querer expor as informações brutas, a menos que sejam apropriadamente processadas (excluindo os dados confidenciais dos resultados finais de uma operação de junção), ou se estas forem despachadas somente para nodos que foram autorizados.

[0051] Suposição 2. Para qualquer junção A 1 1B (onde A e B são os fluxos de entrada da junção), a operação de junção é executada ou na nuvem ou nos nodos onde A ou B originaram.

[0052] Note que esta suposição não simplifica o problema de colocação; ainda existe um número exponencial de possíveis colocações de operador. Antes de apresentar o raciocínio e o algoritmo proposto diversas denotações baseadas em gráfico estão descritas.

[0053] Definição (Demanda) Pode ser denotada como um par (v1, v2), que uma fonte de dados de fluxo v2 "demanda" (isto é, precisa correlacionar com) os dados gerados por outra fonte v1.

[0054] Definição (Gráfico de Demanda) Dado um aplicativo de borda de nuvem, o gráfico de demanda G = (V, E) é definido como segue: o conjunto de vértice V = { v/v é uma fonte de dados de fluxo }, e E = {(VI, v2)\( vi, V2) é um par de demandas}. Cada borda e = (i,) e E está associada com uma taxa rij, que indica a taxa do fluxo de vj que é demandado por vj. Algoritmo 1. Gráfico de Gerar Demanda do Gráfico de Consulta

[0055] A Figura 7 mostra o gráfico de demanda correspondente 702 para a consulta de friend-finder, dada a rede social mostrada na Figura 4. As bordas no gráfico de demanda 702 ilustram as relações de demanda. Por exemplo, a borda GPS-P, SNp) indica que a leitura de GPS de P (GPS-P) deve estar correlacionada com a rede social (SNp). Em um gráfico de demanda, os operadores juntos são tratados como fontes de dados virtuais no gráfico de demanda (conforme estes estão produzindo resultados juntos como fluxos). Realmente, existe um mapeamento de um para um entre os gráficos de demanda e os gráficos de consulta. Dado um gráfico de consulta GQ = (VQ, EQ), o Algoritmo i gera o gráfico de demanda correspondente GD = (VD, ED). O gráfico de consulta pode ser reprojetado pelo gráfico de demanda seguindo um algoritmo similar

[0056] Atribuição: Download versus Upload. Em geral, decidir uma colocação de operador ótima para avaliação de consulta distribuída é sabido ser um problema difícil. A essência do algoritmo proposto esta enraizada em alavancar uma propriedade de rede especial da arquitetura de borda de nuvem. Neste caso, os dispositivos de computação de borda não podem comunicar uns com os outros diretamente. Ao invés, para trocar informações, os dispositivos de computação de borda precisam upload ou download dados através dos servidores de lado de nuvem.

[0057] Definição (Upload e Download). Dado um gráfico de demanda G = (V, E), para uma borda (I, j) e E, esta implementação caracteriza vj como "uploading" sobre (I, j), se, independentemente de onde vj está colocado (ou em um dispositivo de computação de borda ou no servidor de nuvem), este sempre faz um esforço para ter o fluxo correspondente (demandado por vj) disponível no servidor de nuvem; de outro modo vi é caracterizado como "downloading" em (i, j).

[0058] Intuitivamente, uma vez que um vértice decide carregar sobre uma borda (a qual representa uma correlação de dados requerida), não há razão para este descarregar nenhum dado para esta correlação do servidor de lado de nuvem, porque a correlação pode simplesmente ser executada no lado de nuvem (conforme os dados já foram tornados disponíveis no lado de nuvem). Considere o seguinte lema.

[0059] Lema 1. Dado um gráfico de demanda G = (V, E), em sua colocação de operador ótima, t/(i,j) e E, (i ,j) deve estar em um dos dois status: ou vi está carregando (mas não descarregando) ou descarregando (mas não carregando) em (i ,j).

[0060] Prova; Suponha que um vértice Vi e V decide tanto carregar quanto descarregar em (i,). O operador junto para a correlação correspondente pode ser colocado em três localizações (de acordo com a Suposição 2), a saber vi, vj, e a nuvem. Neste caso o operador junto não pode ser colocado em vi na colocação ótima: já que vi já está carregando o seu fluxo. A operação junta poderia ser executada na nuvem, em cujo caso, esta economiza o custo de comunicação para baixar os dados de vj para vi. Portanto, vi não está baixando em (i,) (já que nenhum operador junto está colocado em vi)

[0061] O Lema 1 oferece suporte para a conclusão que, dado um gráfico de demanda G = (V,E), existe um mapeamento de sua colocação ótima para um conjunto de decisões de upload vs. download feitas sobre cada vértice em G. Tal conjunto de decisões é definido como uma atribuição.

[0062] Definição (Atribuição). Dado um gráfico de demanda G = (V,E), uma atribuição A : E ^ {D, U} é definida como segue: A, = U se o vértice Vj decidir carregar o seus dados de fluxo sobre a borda (i,j), de outro modo, Ai,j = D.

[0063] A colocação ótima e a sua atribuição correspondente podem ser denotadas como Popt e Aopt. A Figura 8 mostra a colocação ótima (Popt) para o gráfico de demanda 702 da Figura 7. A Figura 9 mostra a atribuição correspondente (Aopt). Na colocação de operador ótima, a junção entre GPS-P e SNP é executada no nodo P, o que significa que o gráfico de rede social particionado SNP deve ser despachado para o nodo P, isto é, SNP é "carregado" para a nuvem, e GPS-P não é. Isto está consistente com a atribuição dada na Figura 9.

[0064] É natural perguntar as questões 1) se existe um mapeamento reverso de Aopt para Popt, e 2) se existe um algoritmo eficiente para encontrar a Aopt, dado um gráfico de demanda. A discussão abaixo inicialmente refere-se à primeira questão, e então gradualmente desenvolve a resposta para a segunda questão.

[0065] Nem todas as atribuições podem ser mapeadas para um plano de avaliação viável. Existe uma restrição fundamental: uma junção requer a co-locação de todas as suas entradas. Portanto, para qualquer junção que toma entradas de diferentes fontes (dispositivos de borda) no máximo um dispositivo está descarregando.

[0066] Definição (Viabilidade e Conflito). Dado um gráfico de demanda G = (V, E), uma atribuição A é viável se esta satisfizer a seguinte condição: /e = (i,) e E, A, ^ D v Aj,i * D. Uma borda que rompe esta condição é denominada uma borda de conflito.

[0067] Por exemplo, a Figura 9 ilustra uma atribuição viável dado o gráfico de demanda mostrado na Figura 7, como para qualquer correlação, no máximo uma fonte de dados está decidindo descarregar. Se o ASNP,GPS-P for mudado para descarregar, este invalidará a atribuição, já que a borda (SN, GPS-C) é uma borda de conflito.

Lema 2. Dado uma atribuição viável A, A podem ser mapeados para uma colocação de operador correspondente.

[0068] Prova. Prova por construção. A colocação de operador é decidida em um modo de baixo para cima (mostrado como Algoritmo 2). Como o caso de base, as localizações dos vértices de folha em um gráfico de consulta são conhecidas (trivialmente as fontes de fluxo). Para um vértice interno (isto é, um vértice virtual que representa um operador junto), de acordo com a suposição 2, este pode ou ser colocado no servidor de lado de nuvem, ou co-locado com uma de suas entradas. Se todas as fontes de entrada decidirem carregar, então o operador junto deve ser colocado na nuvem; de outro modo, existe uma e somente uma fonte de entrada (dado a atribuição A ser viável, decidindo descarregar, então o operador junto deve ser colocado com aquela fonte de entrada.

[0069] Teorema 4.5 O problema de colocação de operador ótimo pode ser reduzido a encontrar uma atribuição viável com um custo ótimo (diretamente derivado do Lema 1 e Lema 2).

Consultas de Junta de Nível Único

[0070] Esta discussão começa com um cenário simples, onde as aplicações são especificadas como consultas de junta de nível único. A discussão será estendida a consultas de junta de múltiplos níveis na discussão que segue.

Mesma Taxa de Demanda

[0071] A discussão primeiro considera um caso especial das consultas de junta de nível único, nas quais, para qualquer vértice i em um gráfico de demanda, as taxas de fluxo para todas as bordas que saem são as mesmas, a saber, V(i,j) e E; ri.j = ri. Basicamente, um operador junto requer os dados de fluxo totais de cada fluxo de entrada para executar a operação junta. Isto corresponde às consultas onde nenhuma filtragem (tal como projeção ou seleção) é executada antes da junta.

[0072] Ao invés de considerar diretamente o custo de uma atribuição, algumas implementações podem computar o ganho de mudar carregamento e descarregamento (os quais poderiam ser positivos ou negativos comparado com uma atribuição viável de base - uma solução ingênua que todos os vértices decidem carregar os seus dados de fluxo. Mudando um vértice i de carregar para descarregar, o ganho pode ser computado como segue: gain,

[0073] Definição (Grau Ótimo Global). Dado um gráfico de demanda G = (V, E), para a atribuição ótima global é uma atribuição viável A que maximiza os ganhos totais.

[0074] A técnica seguinte para encontrar uma atribuição Aopt que torne o grau ótimo global considera uma proposta gananciosa onde cada vértice no gráfico de demanda localmente toma a decisão de atribuição com base em seu próprio benefício.

[0075] Definição (Grau Ótimo Local). Dado um gráfico de demanda G = (V, E), para cada vértice v e V, a atribuição ótima local para v é uma decisão local sobre Av que maximiza o ganho local. Especificamente, Av = D se e somente se gainv > 0.

[0076] Pode ser provado que o grau ótimo local é realmente consistente com o grau ótimo global, o que tem duas implicações: Primeiro, o overhead para computar o grau ótimo local é baixo, o qual é linear ao número de graus do vértice no gráfico de demanda. Segundo, significa que o problema de atribuição pode ser particionado e resolvido em paralelo. Isto é especificamente importante em casos onde o gráfico de demanda é enorme, já que esta técnica pode alavancar os vastos recursos de computação na nuvem para resolvê- lo eficientemente.

[0077] Teorema 1. Dado um gráfico de demanda a G = (V, E), a atribuição A = {Av \ Av = atribuição [ótima local em v, v eV} é viável.

[0078] Prova. Prova por contradição. Suponha que exista uma borda de conflito e = ( i,j), o que significa que Ai = D e Aj = D. Ai = D provê que gain, = ri - ∑(i,j)eE rj > 0. Portanto, ri >j Similarmente, rj > ri pode ser derivado de Aj = D. Contradição.

[0079] Teorema 2. Grau ótimo Local é consistente com o grau ótimo global, a saber, o grau ótimo global pode ser derivado aplicando individualmente o grau ótimo local.

[0080] Prova. 1) O Teorema 1 mostra que a atribuição derivada aplicando individualmente o grau ótimo local é viável. 2) Cada grau ótimo local está computando o ganho máximo para uma conexão física isolada, e o grau ótimo global é simplesmente a adição dos ganhos sobre as conexões físicas.

Diferentes Taxas de Demanda

[0081] A discussão é agora estendida para considerar o cenário onde, para um dado vértice i, as taxas de fluxo demandadas por cada um dos outros vértices podem ser diferentes. Por exemplo, no caso do aplicativo friend-finder, a taxa de eventos para um usuário específico pode ser diferente com relação a cada um de seus amigos. Aqui, é assumido que o fluxo com uma taxa mais baixa pode ser construído utilizando um com uma taxa mais alta, o que corresponde a consultas que aplicam filtros de amostragem. Em outras palavras, um filtro que precisa amostrar x eventos/segundo pode ser provido por outro filtro que amostra y eventos/s, para qualquer y >x. Em tal cenário, as decisões de carregar versus descarregar precisam ser feitas para cada borda (ao invés de cada vértice) no gráfico de demanda.

[0082] Assumindo que as taxas ri,vj são classificadas no vértice i, de modo que ri,v1 < ri,v2 < ... < ri,vp não é difícil ver que uma atribuição ótima para as p bordas classificadas deve ter o padrão [U, ..., U, D, ..., D].

[0083] Definição (Grau ótimo local). Considere o ganho de uma atribuição vj < k, Ai,v = U, Vj > k, Ai,v = D: gaini,vk = n,vp - n,vk - ∑k+i<s<pRs,i. Algumas implementações podem selecionar k = argmaxi<j<pgaini,vk, e configurar a atribuição no padrão acima descrito.

[0084] Lema 4.8. Após aplicar o grau ótimo local no vértice i, que

[0085] Prova. Prova por contradição. Suponha ri,vj>rvj,i. De acordo com a definição de grau ótimo local:

[0086] Note que j > k, já que Ai,vj = D. Também gaini,vj - gainiv,k = riv,k + ∑k+i<s<j-1rvs,i + (rvj'- ri,vj) > 0. Isto cria uma contradição já que gaini,vk é ótimo).

[0087] Teorema 3. O teorema de viabilidade (Teorema 1) ainda é verdadeiro.

[0088] Prova. Prova por contradição. Suponha que existe uma borda de conflito é (v1, v2). Aplicando o Lema 3, supre rv1,v2 > rv2,v1 de Av1,v2 = D, e rv2,v1, > rv1,v2 de Av2,v1 = D, o que produz uma contradição.

Consultas Juntas de Múltiplos Níveis

[0089] Quando considerando as consultas juntas de múltiplos níveis, podem existir dificuldades que impedem ingenuamente aplicar o algoritmo desenvolvido para as consultas juntas de único nível. Por exemplo, para as consultas juntas de único nível, o custo dos fluxos de saída para os operadores juntos não é considerado (já que é assumido que a saída final é insignificante comparada com os fluxos de entrada). No entanto, este não é o caso para as consultas juntas de múltiplos níveis. Por exemplo, quando ingenuamente aplicando o algoritmo apresentado na seção anterior, um dispositivo de borda pode individualmente decidir descarregar outros fluxos e executar a computação localmente. No entanto, se o dispositivo de borda estiver ciente do fato que o fluxo de saída é então requerido para um operador junto de nível mais alto (cuja colocação ótima está no lado de nuvem), este pode tomar uma decisão diferente. A discussão abaixo refere-se a como este desafio é resolvido estendendo o algoritmo para as juntas de único nível.

[0090] Suposição 3. Um fluxo de dados de uma dada borda aparece em não mais do que uma subárvore filha de qualquer operador no gráfico de consulta.

[0091] Esta é uma suposição razoável, já que pode-se simplesmente combinar os fluxos do mesmo dispositivo de borda em um único fluxo, ou localmente executar a computação necessária nas quais estes fluxos estão envolvidos. Note que esta suposição não exclui o compartilhamento de fonte ou resultados intermediários, e especificamente, é sempre verdadeira no caso em que o padrão de consulta é uma árvore profunda esquerda sobre diferentes fontes de dados.

Colocação de Operador Em Um Modo de Cima Para Baixo

[0092] Os operadores juntos internos no gráfico de consulta podem ser vistos como fontes de fluxo virtuais, exceto que as suas localizações precisam ser decididas. Intuitivamente, dado um gráfico de consulta, as presentes técnicas podem tomar as decisões de carregar versus descarregar para os operadores no modo de cima para baixo. Por exemplo, a decisão pode ser tomada para um dado vértice vi que corresponde a um operador junto, desde que a localização para onde a sua saída deve ser despachada (com base na decisão de colocação feita por seu operador pai) seja conhecida. O algoritmo para as consultas unidas de único nível pode ser diretamente estendido adicionalmente incluindo o custo de despacho do fluxo de saída para o destino.

[0093] Note que o único destino considerado é o lado de nuvem. Por exemplo, mesmo se o destino for outro dispositivo de borda (já que o fluxo de saída é requerido por outro vértice v2 localizado no dispositivo de borda), a técnica não precisa considerar a parte de descarregamento do custo de despacho (isto é, o custo de enviar o fluxo de saída do lado de nuvem para aquele dispositivo de borda), já que este custo de descarregamento já esta considerado no cálculo do ganho para v2. Note que as Suposições 1 e 3 asseguram que quando considerando o vértice v1, a decisão de colocação real pode ser desconsiderada para o seu destino, já que este definitivamente será colocado ou na nuvem ou em alguma outra borda do que v1 (ou sua subárvore) não sobrepõe. Esta observação chave torna a extensão do algoritmo possível, e pode ser facilmente mostrado que o algoritmo estendido ainda garante uma atribuição viável e ótima.

Carregamento Versus Descarregamento Em Um Modo de Cima Para Baixo

[0094] Note que a proposta anterior (para as consultas juntas de único nível) deriva a colocação de operadores no modo de baixo para cima após as decisões de carregamento versus descarregamento serem feitas. O algoritmo 3 pode ser refinado para decidir a atribuição de carregamento versus descarregamento com base na atribuiçãodos operadores pais ao invés de sua colocação (já que a colocação não é viável).

[0095] Uma vez que a decisão do vértice pai v1, é conhecida, algumas implementações podem considerar que a decisão deve ser feita para um vértice filho v2. Novamente, v2 tem duas escolhas - ou carregar ou descarregar.

[0096] Em um cenário, se a decisão do vértice pai v1 for descarregar, isto significa que não há necessidade de fazer o esforço para ter a saída disponível no servidor de nuvem. Portanto, quando encontrando o grau ótimo local para v2, o custo do fluxo de saída não é considerado na computação dos ganhos.

[0097] Em outro cenário, se a decisão vértice pai v1 for carregar, isto significa que o fluxo de saída v2 deve ser tornado disponível no servidor de nuvem. Portanto, quando encontrando o grau ótimo local para v2, o custo do fluxo de saída deve ser considerado.

[0098] O Algoritmo 3 toma o gráfico de demanda G = (V, E) como a entrada, e computa a colocação de operador ótima. O algoritmo aplica a um cenário genérico onde este assume uma consulta junta de múltiplos níveis, e taxas de demanda por borda (isto é, as taxas associadas com as bordas de demanda começando de um dado vértice podem ser diferentes). De acordo com os Teoremas 1 e 2, não é difícil ver que a atribuição derivada é viável e ótima. Algoritmo 3. Computar Atribuição Ótima

Custos de Carregamento/Descarregamento Assimétrico

[0099] Até agora, as técnicas acima operaram na suposição que o custo de carregamento e o custo de descarregamento são os mesmos. No entanto, na realidade, este pode não ser o caso. Por exemplo, os preços por unidade de utilização de largura de banda para carregamento e descarregamento podem ser diferentes (por exemplo, um provedor de serviço de nuvem pode introduzir custos assimétricos para encorajar os usuários para alimentar dados na nuvem). Como outro exemplo, um dispositivo de borda poderia exibir diferentes consumos de bateria para carregar e descarregar.

[00100] A discussão que segue considera custos de carregamento/descarregamento assimétricos. O custo por unidade para carregamento e descarregamento estão denotados como Cu e Cd. Para os cenários onde Cu< Cd, os resultados para Cu = Cd apresentados nas seções anteriores ainda valem. Basicamente, o raciocínio do teorema de viabilidade de chave (Teorema 1) é verdadeiro.

[00101] Por outro lado, decidir a colocação de operador ótima é um problema mais difícil para os casos onde Cu> Cd. Para um caso especial onde Cd = 0, pode ser mostrado que o problema de colocação de operador ótimo se mostra difícil pela redução do problema de cobertura de vértice mínimo ponderado (WMVC) clássico. Essencialmente, o teorema de viabilidade quebra nestes casos, portanto, tendo os dispositivos de borda aplicando individualmente o grau ótimo local pode resultar em conflitos. Em tais casos, uma atribuição viável pode ainda ser obtida resolvendo os conflitos ajustando alguns vértices no gráfico de demanda para carregamento com taxas mais altas. Portanto, o problema reduz ao problema de WMVC no gráfico residual, o que falta uma solução geral eficiente. A discussão seguinte refere-se a uma condição. Se a condição for satisfeita, o problema de colocação de operador ótimo pode ser resolvido eficientemente.

[00102] Definição. Dado um gráfico de demanda G = (V, E), a inclinação de um vértice v G V, Sv é definida como a razão entre a taxa máxima e mínima associada com as bordas que saem de v. A saber, Sv = max(v,i)gEi)rv,i/min(v,j)gE)rv,j.

[00103] Definição. Dado um gráfico de demanda G = (V, E), a inclinação de G é definida como a inclinação máxima entre os nodos em G. A saber, S = maxvgVSv.

Tabela 1: Mostra um sumário do algoritmo de colocação de operador. O grau ótimo global é conseguido em todos os casos.

[00104] Lema 4. Dada a inclinação S de um gráfico G, se Cd< Cu< (1 + 1/S) . Cd, após aplicar o grau ótimo local sobre todos os vértices, o gráfico residual G' que consiste nas bordas de conflito é acíclico (isto é, árvores separadas).

[00105] Prova. Prova por contradição. Suponha que exista um ciclo (Vi, V2), (V2, V3),..., (V(p-1), Vp), (Vp, VI) no gráfico residual G'. Para o propósito de apresentação, denote que vo = Vp e v(p+i) = vi. Como cada borda no ciclo é uma borda de conflito, V1 < i < p, existe uma ligação solta que

[00106] Portanto, esta implementação pode derivar a seguinte contradição:

[00107] Teorema 4. Se Cd< Cu< (i+ i/S) . Cd, a colocação de operador ótima pode ser encontrada no tempo P.

[00i08] Prova. Pode ser concluído aplicando o Lema 4 que G' é acíclico. Esta discussão mostra que, para cada árvore no gráfico residual G', a sua cobertura de vértice mínima ponderada pode ser encontrada em tempo linear, utilizando um algoritmo de programa dinâmico.

[00i09] Começando dos vértices de folha, para cada vértice v, considere o custo da cobertura de vértice para a subárvore (em raiz por v), tendo (ou não tendo) v, no conjunto de cobertura. Para qualquer vértice interno v, se v não estiver dentro do conjunto de cobertura, então todos os filhos de v devem estar no conjunto de cobertura . Portanto, Cost-v = ∑kchild(v) Cost+v. Por outro lado, se v estiver no conjunto de cobertura, então cada subárvore pode independentemente escolher a sua cobertura de vértice: Cost+v = cv + miniechild(v) (Cost-v, Cost+v).

[00110] Note que para um caso especial onde as taxas de fluxo requeridas por diferentes amigos são as mesmas, a colocação ótima pode ser encontrada no tempo P, se Cd< Cu< 2 . Cd (o qual é verdadeiro nos cenários mais práticos). Empiricamente, mesmo se Cu >2 . Cd, as bordas conflitantes ainda formam árvores isoladas.

SUMÁRIO

[00111] A Tabela 1 sumariza os resultados teóricos e a complexidade de tempo do algoritmo de colocação de operador proposto, dadas várias combinações de complexidades de consulta, condições de seleção, e razões de custo de carregamento/descarregamento.

[00112] O algoritmo de colocação de operador computa a solução globalmente ótima considerando individualmente o grau ótimo local para cada vértice no gráfico de demanda. Esta discussão prova que o grau ótimo local é consistente com o grau ótimo global (se Cu < Cd). Um algoritmo ganancioso eficiente é proposto para computar o grau ótimo local. Com este algoritmo ganancioso eficiente cada nodo individualmente escolhe a solução que maximiza o ganho local.

[00113] O algoritmo lida com ambas as consultas de único nível e múltiplos níveis mais complexas. No caso de consultas juntas de múltiplos níveis os operadores juntos internos em um gráfico de consulta são tratados como vértices virtuais.

[00114] O grau ótimo local pode ser computado para cada vértice individual em um modo de cima para baixo. Além disso, no caso comum onde o gráfico residual é acíclico (para Cu> Cd), existe um algoritmo de programação dinâmico (DP) eficiente para encontrar a atribuição ótima para o gráfico de demanda. Portanto, uma colocação de operador ótima para o gráfico de consulta pode ser determinada. A extensão destes conceitos para os gráficos de consulta gerais com operadores de caixa preta está também explicada.

[00115] Dada a natureza dos aplicativos de borda de nuvem (os quais são usualmente correlações através de dados em tempo real), a discussão acima focalizou principalmente sobre as consultas juntas (com filtros de amostragem). A discussão que segue refere-se a como o algoritmo proposto pode ser aplicado para suportar gráficos de consulta gerais em uma topologia de borda de nuvem. A discussão ainda explica como o dinamismo de tempo de execução tal como mudanças no gráfico de consulta e taxas de evento pode ser manipulado.

Manipulando Gráficos de Consulta Gerais

[00116] Um gráfico de consulta G é definido como um gráfico acíclico direcionado (DAG) sobre um conjunto de operadores de caixa preta (denotados como O), onde as folhas em G são denominadas fontes, e as raízes são denominadas mergulhos. Cada operador em O pode tomar zero (para as fontes) ou mais entradas, e a sua saída pode ser utilizada como uma entrada para outros operadores. Uma seleção e projeção são exemplos de operadores de uma entrada, enquanto que uma operação junta é um exemplo de operadores de duas entradas (ou um operador de múltiplas entradas para juntas frondosas). As intuições de alto nível do algoritmo de colocação de operador ainda valem em que cada operador pode individualmente decidir (em uma ordem de cima para baixo) se este deve carregar (ou descarregar) a sua saída para otimizar o seu custo local. Neste caso, a viabilidade de atribuição é ainda garantida como antes. Mais ainda, dado que os operadores são considerados como caixas pretas, não há mais oportunidade de explorar o compartilhamento através da entrada de diferentes operadores. Neste caso, a consistência entre o ótimo local e o ótimo global ainda vale, seguindo um raciocínio similar ao Teorema 2. Portanto, o problema pode novamente ser reduzido encontrando as atribuições de carregamento/descarregamento ótimas, e os algoritmos de grau ótimo local eficientes propostos podem ser utilizados.

Manipulando Dinamismo

[00117] Algumas instâncias do algoritmo assumem a disponibilidade do gráfico de consulta, e as estatísticas de taxa para todos os fluxos. A colocação ótima é computada com base nestas informações coletadas no estágio de otimização. No entanto, o gráfico de consulta pode mudar ao longo do tempo, por exemplo, devido à adição e remoção de bordas na rede social. Similarmente, as taxas de evento podem também mudar ao longo do tempo. Assim, pode ser necessário adaptar a estas mudanças durante o tempo de execução. Dado que o algoritmo de otimização proposto é muito eficiente, a reotimização periódica é uma solução viável. No entanto, a reotimização pode encontrar um overhead de posicionamento (por exemplo, enviando mensagens de plano de controle tais como definições de consulta). Se as implementações reotimizarem muito frequentemente, o overhead de reotimização pode obscurecer os benefícios da otimização.

[00118] Para resolver este dilema, uma solução é utilizar um algoritmo online baseado em custo. Por exemplo, tal algoritmo pode estimar e manter a perda acumulada devido a não executar a reotimização, e escolher executar a reotimização se a perda acumulada exceder o overhead de reotimização. Uma propriedade potencialmente benéfica desta proposta é que está é tricompetitiva - é garantido que o custo total seja limitado por 3 vezes o ótimo (mesmo com um conhecimento a priori das mudanças).

[00119] A discussão acima oferece grandes detalhes de implementações de RACE específicas. RACE pode suportar uma ampla classe de aplicações de borda de nuvem em tempo real. RACE resolveu dois desafios técnicos principais: (1) a especificação de tais aplicações; e (2) a sua execução otimizada na topologia de borda de nuvem. para (1), a discussão mostra que utilizando uma linguagem de consulta temporal declarativa (tal como LINQ para Streamlnsight) para exprimir estas aplicações é muito poderosa e intuitiva. Para (2) a utilização de máquinas de DSMS é proposta para compartilhar o processamento e executar diferentes porções da lógica de aplicação nos dispositivos de borda e na nuvem. Aqui, os novos algoritmos são altamente eficientes porem provavelmente minimizam o custo de rede global, enquanto manipulando redes assimétricas, gráficos de consulta gerais, e compartilhamento de resultados intermediários. As implementações de RACE acima estão configuradas para funcionar com Microsoft® Streamlnsight®, um DSMS comercialmente disponível. Outras implementações podem ser configuradas para utilizar outras opções de DSMS.

[00120] Experimentos sobre conjuntos de dados reais indicaram que o otimizador de RACE é ordens de magnitude mais eficiente do que as técnicas de colocação ótimas do estado da técnica. Ainda, as colocações conseguidas pelas presentes implementações incorreram diversos fatores de custo mais baixo do que esquemas mais simples para um aplicativo friend-finder sobre um gráfico de rede social realista com 8:6 milhões de bordas. RACE é facilmente paralelizável com a nuvem. Este também escala bem utilizando apenas uma única máquina em posicionamentos reais com até 500 clientes de borda. Detalhes de algumas implementações estão acima descritos em um fino nível de granularidade. A discussão abaixo oferece uma discussão mais ampla que pode referir às implementações acima mencionadas e/ou a outras implementações.

EXEMPLOS DE MÉTODOS ADICIONAIS

[00121] A Figura 10 ilustra um fluxograma de uma técnica ou método 1000 que é consistente com pelo menos algumas implementações dos presentes conceitos.

[00122] No bloco 1002, o método pode obter uma consulta de fluxo declarativa em uma topologia de borda de nuvem que inclui múltiplos dispositivos de borda e recursos baseados em nuvem.

[00123] No bloco 1004, o método pode converte a consulta de fluxo declarativa em um gráfico de consulta que reflete os múltiplos dispositivos de borda.

[00124] No bloco 1006, o método pode determinar se executar os operadores do gráfico de consulta sobre dispositivos de borda individuais ou sobre os recursos baseados em nuvem quando da utilização de recursos para a topologia de borda de nuvem.

[00125] A ordem na qual os métodos acima mencionados estão descritos não pretende ser considerada como uma limitação, e qualquer número dos blocos descritos pode ser combinado em qualquer ordem para implementar o método, ou um método alternativo. Mais ainda, o método pode ser implementado em qualquer hardware, software, firmware adequado, ou sua combinação, de modo que um dispositivo de computação possa implementar o método. Em um caso, o método está armazenado em um meio de armazenamento legível por computador como um conjunto de instruções de modo que a execução por um dispositivo de computação faz com que o dispositivo de computação execute o método.

CONCLUSÃO

[00126] Apesar de técnicas, métodos, dispositivos, sistemas etc., referentes a recursos de borda de nuvem e sua alocação serem descritos em uma linguagem específica para características estruturais e/ou atos metodológicos, é compreendido que o assunto definido nas reivindicações anexas não está necessariamente limitado às características ou atos específicos descritos. Ao invés, as características e atos específicos estão descritos como formas exemplares para implementar os métodos, dispositivos, sistemas etc. reivindicados.

Claims (11)

1. Método para topologias de borda de nuvem (1000), compreendendo as etapas de: obter (1002) uma consulta de fluxo declarativa em uma topologia de borda de nuvem que inclui múltiplos dispositivos de borda (102) e recursos baseados em nuvem (110); converter (1004) a consulta de fluxo declarativa em um gráfico de consulta que reflete os múltiplos dispositivos de borda (102) gerando um padrão de consulta a partir de uma representação de objeto da consulta e gerando o gráfico de consulta usando o padrão de consulta como um modelo; e, caracterizado pelo fato de que compreende ainda: determinar (1006) se os operadores do gráfico de consulta devem ser executados em dispositivos de borda individuais (102) ou nos recursos baseados em nuvem (110) com base no uso de recursos para a topologia de borda em nuvem.

2. Método (1000), de acordo com a reivindicação 1, caracterizado pelo fato de que os dispositivos de computação de ponta (102) compreendem dispositivos de computação inteligentes (102) que são configurados para se comunicarem diretamente com os recursos baseados em nuvem (110) através de uma rede (106) e em que a rede (106) está desconfigurada no sentido de permitir que dispositivos de computação inteligente individuais (102) se comuniquem diretamente uns com os outros, em vez disso, os dispositivos de computação inteligente individuais (102) se comunicam uns com os outros indiretamente por meio dos recursos baseados em nuvem (110).

3. Método (1000), de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a determinação (1006) compreende determinar um ótimo global em relação aos recursos baseados em nuvem (110) relacionados ao uso de recursos de largura de banda de rede.

4. Método (1000), de acordo com a reivindicação 3, caracterizado pelo fato de que determinar um ótimo global compreende permitir que nós do gráfico de consulta tomem decisões locais de forma gananciosa e em que as decisões locais, quando vistas cumulativamente, produzem o ótimo global.

5. Sistema (200) para topologias de ponta de nuvem que compreende um processador configurado para: obter (1002) uma consulta de fluxo declarativa em uma topologia de borda de nuvem que inclui vários dispositivos de borda (102) e recursos baseados em nuvem (110); converter (1004) a consulta de fluxo declarativa em um gráfico de consulta que reflete os múltiplos dispositivos de borda (102), gerando um padrão de consulta a partir de uma representação de objeto da consulta e gerando o gráfico de consulta usando o padrão de consulta como um modelo; e, caracterizado pelo fato de que o processador é ainda configurado para: determinar (1006) se os operadores do gráfico de consulta devem ser executados em dispositivos de borda individuais (102) ou nos recursos baseados em nuvem (110) com base no uso de recursos para a topologia de borda em nuvem.

6. Sistema, de acordo com a reivindicação 5, caracterizado pelo fato de que compreende um serviço de gerenciamento baseado em nuvem (202) configurado para interagir com um aplicativo em execução na nuvem (104) e em dispositivos de computação de borda individuais (102) em comunicação com a nuvem (104), a nuvem serviço de gerenciamento baseado em (202) configurado para imitar um mecanismo de sistema de gerenciamento de fluxo de dados, DSMS, para obter as consultas de fluxo declarativo temporais dos dispositivos de computação de borda individuais (102); e, em que o processador está configurado para obter a consulta de fluxo declarativa interceptando as consultas declarativas temporais, e em que o processador é configurado para converter a consulta de fluxo declarativa analisando e compilando consultas declarativas temporais individuais em uma representação de objeto.

7. Sistema (200), de acordo com a reivindicação 6, caracterizado pelo fato de que o processador (204) compreende um construtor de gráfico (206), e em que o construtor de gráfico está configurado para converter a consulta de fluxo declarativa gerando um padrão de consulta (302) a partir da representação do objeto.

8. Sistema (200), de acordo com a reivindicação 7, caracterizado pelo fato de que, em uma instância em que o padrão de consulta (302) inclui fluxos de entrada que se referem a fluxos de dados de cada dispositivo de computação de borda (102), o construtor de gráfico (206) converte a consulta de fluxo declarativa criando um gráfico de consulta que inclui várias instâncias do padrão de consulta (302), dividindo os fluxos de dados em várias instâncias do padrão de consulta (302) com um fluxo de entrada por borda do gráfico de consulta.

9. Sistema (200), de acordo com a reivindicação 8, caracterizado pelo fato de que o processador (204) compreende um otimizador (208) configurado para determinar onde executar operadores individuais do gráfico de consulta para reduzir os custos totais de comunicação entre os dispositivos de computação de borda (102) e o recursos baseados em nuvem (110).

10. Sistema (200), de acordo com a reivindicação 9, caracterizado pelo fato de que o otimizador (208) é configurado para determinar onde executar os operadores individuais do gráfico de consulta para minimizar os custos totais de comunicação entre os dispositivos de computação de borda (102) e os recursos baseados em nuvem (110).

11. Sistema (200), de acordo com qualquer uma das reivindicações 6 a 10, caracterizado pelo fato de que o processador (204) compreende um construtor de consulta (210) configurado para gerar representações de objetas de tipos, adaptadores e subconsultas a serem executadas em cada dispositivo de computação de borda (102) ou na nuvem (104).

Images