BRPI0805054B1 - método para processamento de dados em paralelo - Google Patents

Abstract

infraestrutura para programação paralela de grupos de máquinas. gridbatch fornece uma estrutura de suporte de infra-estrutura que oculta as complexidades e encargos de lógica de desenvolvimento e aplicação de programação que implementa computações paralelizadas de detalhes de programadores. um programador pode usar gridbatch para implementar operações computacionais paralelizadas que minimizam exigências de largura de banda da rede, e eficientemente dividem e coordenam processamento com putacional em uma configuração do m ultiprocessador. gridbatch fornece uma abordagem eficiente e leve para rapidamente construir aplicações paralelizadas usando configurações de multiprocessador economicamente viáveis que alcançam os mais altos resultados de performance.

Description

Relatório Descritivo da Patente de Invenção para MÉTODO PARA PROCESSAMENTO DE DADOS EM PARALELO.

Antecedentes da Invenção

1. Campo Técnico

Essa descrição refere-se a um sistema e método para paralelizar aplicações através do uso de uma biblioteca de software de operadores projetados para implementar planos de computação paralisada em detalhes. Em particular, essa descrição refere-se a uma maneira eficiente e de custo útil para implementar aplicações paralelizadas.

2. Antecedentes da Invenção

Atualmente existe uma grande disparidade entre a quantidade de organizações de dados necessária para processar em qualquer dado momento e a capacidade de computação disponível para a organização usando sistemas únicos CPU (uniprocessadores). Hoje, as organizações usam aplicações que processam terabytes e até petabytes de dados, de modo a derivar informação válida e insight em negócios. Infelizmente, muitas das aplicações tipicamente operam sequencialmente máquinas uniprocessadoras, e requerem horas e mesmo dias de tempo de computação para produzir resultados utilizáveis. A fenda entre a quantidade de dados que as organizações podem processar e a performance computacional de uniprocessadores disponíveis para as organizações continua a aumentar. A quantidade de dados coletados e processados pelas organizações continua a crescer exponencialmente. As organizações devem endereçar taxas de crescimento da base de dados de empreendimentos de cerca de 125% ano a ano ou o equivalente para dobrar em tamanho cada 10 meses. O volume de dados para outras indústrias ricas de dados também continua a crescer exponencialmente. Por exemplo, a Astronomia tem uma taxa de duplicação de dados de cada 12 meses, cada 9 meses para Biossequências, e cada 6 meses para Genômica Funcional.

Embora a capacidade de armazenagem continue a crescer em uma taxa exponencial, a velocidade de uniprocessadores não mais cresce

Petição 870190077337, de 09/08/2019, pág. 4/13

exponencialmente. Dessa maneira, mesmo que as organizações possam ter a habilidade para continuar a aumentar a capacidade de armazenagem de dados, a performance computacional de configurações de uniprocessador podem não mais manter o passo. As organizações devem identificar uma solução técnica para endereçar tendências divergentes de capacidade de armazenagem e performance de uniprocessadores.

De modo a processar grandes quantidades de dados, as aplicações necessitam grandes quantidades da capacidade de computação e alto rendimento de I/O. Os programadores faceiam os desafios técnicos de for10 mas eficientes de identificação para dividir o processamento computacional e coordenar múltiplas CPUs através da computação para endereçar a crescente fenda entre a demanda e o suprimento de capacidade de computação. Dada a limitada realidade de disponibilidade de largura de banda de rede, os programadores também faceiam o desafio técnico de endereçar as exigên15 cias da grande largura de banda necessárias para distribuir vastas quantidades de dados para CPUs múltiplas executando computações de processamento paralelo. Introduzir meramente uma máquina adicional a um pool de processamento (configuração) não aumenta a largura de banda total na rede da configuração. Embora a largura de banda de I/O do disco local possa 20 aumentar como um resultado. Uma topologia de rede pode ser representada como uma árvore que tem muitas ramificações que representam os segmentos de rede e folhas que representam os processadores. Dessa maneira, um estrangulamento único ao longo de qualquer um segmento de rede pode determinar a capacidade de rede total e a largura de banda de uma configu25 ração. De modo a por em escala a largura de banda, o uso eficiente de aumentos da largura de banda de I/O do disco local deve ser alavancado.

Os extraordinários desafios técnicos associados com operações computacionais de paralelização incluem complexidade paralela de programação, desenvolvimento adequado e ferramentas de teste, limites de colo30 car em escala a largura de banda de rede, as divergentes tendências de capacidade de armazenagem e performances de uniprocessadores, e divisão eficiente de processamento computacional e coordenação em configurações

de multiprocessadores.

Tem existido uma necessidade por um longo período por um sistema e método que de maneira econômica e eficiente implementa soluções de computação paralela e efetivamente libera a carga de desenvolvi5 mento de programas paralelos complexos por programadores.

Sumário

O sistema GridBatch fornece um contexto de infra-estrutura que programadores podem usar para facilmente converter um projeto de alto nível em uma implementação computacional paralelizada. O programador ana10 lisa o potencial de paralelização de computações em uma aplicação, decompõe as computações em componentes discretos e considera um plano de divisão de dados para obter a performance mais alta. GridBatch implementa o plano computacional paralelizado detalhado, desenvolvido pelo programador sem exigir que o programador crie uma lógica de baixo nível para 15 efetuar a execução das computações. GridBatch fornece uma biblioteca de operadores (um primitivo para administração de conjunto de dados) como blocos de construção para implementar a paralelização. GridBatch oculta toda a complexidade associada com programação paralela na biblioteca de GridBatch de modo que o programador precisa somente entender como a20 plicar os operadores para corretamente implementar a paralelização.

Embora GridBatch possa suportar muitos tipos de aplicações, GridBatch fornece um benefício particular para programadores focados em aplicações analíticas de desdobramento, por causa das características únicas de aplicações analíticas e operadores computacionais usados pelas a25 plicações analíticas. Os programadores muitas vezes escrevem aplicações analíticas para coletar estatísticas de um grande conjunto de dados, tal como muitas vezes ocorre um evento particular. As exigências computacionais de aplicações analíticas muitas vezes envolvem dados de correlação de dois ou mais diferentes conjuntos de dados (por exemplo, as demandas compu30 tacionais impostas por uma ligação de tabela expressada em uma declaração SLQ).

GridBatch alavanca técnicas de localização de dados para efici;#^Λ'· _ν-Λ Rub^^Ll.^ K z entemente administrar o disco I/O e eficazmente exigências de largura de‘ banda do sistema em escala. Em outras palavras, GridBatch divide o processamento computacional e coordena a computação através de processadores múltiplos de modo que os processadores executam computações em dados locais. GridBatch minimiza as quantidades de dados transmitidos para processadores múltiplos para executar computações de processamento paralelo.

GridBatch soluciona os problemas técnicos com operações computacionais de paralelização ocultando complexidades de programação paralela, alavancando dados localizados para minimizar as exigências de largura de banda de rede, e administrar a divisão de processamento computacional e coordenação entre configurações de multiprocessador.

Outros sistemas, métodos, e características da invenção estarão, ou tornar-se-ão aparentes para aqueles versados na técnica mediante exame das figuras e da descrição detalhada a seguir. É pretendido que tais sistemas, métodos, características e vantagens adicionais estejam incluídos nesta descrição, estejam dentro do escopo da invenção, e sejam protegidos pelas reivindicações em anexo.

Breve Descrição dos Desenhos

A descrição pode ser mais bem entendida com referência aos desenhos e à descrição a seguir. Os componentes nas figuras não são necessariamente em escala, em ênfase em vez de estarem colocados mediante ilustração dos princípios da invenção. Além disso, nas figuras, os números de referência similares designam partes correspondentes ou elementos por todas as diferentes vistas.

A figura 1 ilustra a configuração do sistema GridBatch.

A figura 2 mostra um exemplo de Nó Máster.

A figura 3 ilustra a configuração do sistema GridBatch durante o processamento de uma chamada da função de distribuir.

A figura 4 mostra a configuração do sistema GridBatch durante o processamento de uma chamada da função de ligação.

A figura 5 mostra a configuração do sistema GridBatch durante o

processamento de uma chamada da função de convolução.

A figura 6 ilustra a configuração do sistema GridBatch durante o processamento de uma chamada da função recursiva.

A figura 7 ilustra que fluxo lógico da configuração do sistema

GridBatch pode obter para executar o operador de distribuir.

A figura 8 mostra que fluxo lógico da configuração do sistema GridBatch pode obter para executar o operador de ligação.

A figura 9 mostra que fluxo lógico da configuração do sistema GridBatch pode obter para executar o operador de convolução.

A figura 10 mostra que fluxo lógico da configuração do sistema

GridBatch pode obter para executar o operador de função recursiva.

A figura 11 ilustra a configuração do sistema GridBatch durante o processamento de uma chamada de função de mapa.

A figura 12 mostra que fluxo lógico GridBatch 100 pode obter para executar o operador de mapa.

Descrição Detalhada

Uma pesquisa anterior em computação paralela focou em automaticamente detectar paralelismo em uma aplicação seqüencial. Por exemplo, os engenheiros desenvolveram técnicas em arquitetura de computador, 20 tal como buffers fora de ordem, projetados para detectar dependências entre instruções e instruções independentes de esquema em paralelo. Tais técnicas-somente examinam fragmentos de código, codificados em uma linguagem de programação seqüencial e não podem explorar nível de aplicação de paralelismo. Dessa maneira, tais técnicas limitam a quantidade de paralelis25 mo que pode ser explorada.

Uma grande classe de aplicações, em particular aplicações de arquivo de lote intensivo de dados, possui paralelismo óbvio no nível de dados. No entanto, existem diversos desafios técnicos para implementar aplicações paralelas. Os programadores devem endereçar questões não triviais 30 com relação às comunicações, coordenação e sincronização entre máquinas e processadores quando os programadores projetam uma aplicação paralelizada. Em absoluto contraste aos programas sequenciais, os programado-

res devem antecipar todas as interações possíveis entre todas as máquinas na configuração de um programa paralelizado, dada a natureza assíncrona inerente de programas paralelos. Também, ferramentas eficientes de depuração para aplicação paralelizada e desenvolvimento de configuração não 5 existem. Por exemplo, o passo a passo através de algum código pode ser difícil de executar em um ambiente onde a configuração tem muitos filamentos operando em muitas máquinas. Também, por causa das interações complexas que resultam em aplicações paralelizadas, os programadores identificam muitas falhas observadas como transitórias por natureza e difí10 ceis de reproduzir. Os desafios técnicos faceados pelos programadores que implementam aplicações paralelizadas traduzem diretamente em maior desenvolvimento de custos e desenvolvimento de ciclos mais longos. Além disso, os programadores muitas vezes não podem migrar ou replicar uma solução paralelizada para outras implementações.

Os programadores reconhecem sistemas de base de dados também adequados para as aplicações analíticas. Infelizmente, os sistemas de base de dados não colocam em escala por grandes conjuntos de dados por pelo menos duas razões. Primeiro, os sistemas de base de dados apresentam um alto nível de SQL (Linguagem de Consulta Estruturada) com o 20 objetivo de ocultar os detalhes da implementação. Embora a SQL possa ser de uso relativamente fácil, a natureza de tal linguagem de alto nível força os usuários a-expressarem computações de uma maneira que resulta em processamento que executa de maneira ineficiente de uma perspectiva de paralelização. Ao contrário da programação em uma linguagem de nível baixo 25 (por exemplo, C++) onde o processo paralelizado somente lê um conjunto de dados uma vez que, o mesmo processamento expressado em SQL pode resultar em diversas leituras sendo executadas. Mesmo que as técnicas tenham sido desenvolvidas para automaticamente otimizar o processamento de consulta, a performance realizada usando uma linguagem de nível baixo 30 para implementar uma computação paralelizada ainda excede a performance da linguagem de nível maior tal como SQL. Segundo, a arquitetura I/O de sistemas de base de dados limita a escalabilidade de implementações para-

an lelizadas distribuídas porque as bases de dados assumem que o acesso ads ¹ dados seja via uma unidade de armazenagem lógica comum na rede, ou através de um sistema de arquivo distribuído ou um hardware SAN (área de armazenamento em rede). As bases de dados não alavancam lógica para mapeamentos físicos de dados e, dessa maneira, não obtêm vantagem de localidade de dados ou da localização física de dados. Mesmo que existam mecanismos sofisticados de ocultação, as bases de dados muitas vezes acessam os dados atravessando a rede desnecessariamente e consumindo preciosa largura de banda de rede.

As aplicações analíticas diferem das aplicações na web em diversos aspectos. As aplicações analíticas tipicamente processam dados estruturados, enquanto que, as aplicações na web frequentemente lidam com dados não estruturados. As aplicações analíticas muitas vezes exigem informação de referência cruzada de diferentes fontes (por exemplo, diferentes tabelas de base de dados). As aplicações analíticas tipicamente focam em estatísticas muito menos do que as aplicações na web. Por exemplo, uma aplicação de contagem de palavras iria exigir estatísticas para todas as palavras em um vocabulário, em que, uma aplicação analítica pode ser somente interessada no número de produtos vendidos.

GridBatch fornece operadores fundamentais que podem ser empregados para aplicações analíticas ou outras aplicações. Uma implementação de-aplicação paralelizada detalhada pode ser expressada como uma combinação de operadores básicos fornecidos pelo GridBatch. O GridBatch economiza tempo considerável do programador com relação à implementação e depuração porque o GridBatch endereça os aspectos paralelos de programação para o programador. Usando o GridBatch, o programador determina a combinação de operadores desejada, a seqüência de operadores, e a programação mínima para desenvolver cada operador.

Embora sejam descritos componentes específicos de GridBatch, métodos e sistemas, e artigos de fabricação consistentes com GridBatch podem incluir componentes adicionais ou diferentes. Por exemplo, um processador pode ser implementado como um microprocessador, micro30

controlador, circuito integrado para aplicação específica (ASIC), lógica discreta, ou uma combinação de outro tipo de circuitos ou lógica. Similarmente, as memórias podem ser DRAM, SRAM, Flash ou qualquer outro tipo de memória. A lógica que implementa o processamento e programas descritos 5 abaixo pode ser armazenada (por exemplo, como instruções executáveis por computador) em um meio legível por computador tal como um disco óptico ou magnético ou outra memória. Alternativa ou adicionalmente, a lógica pode ser realizada em um sinal eletromagnético ou óptico que pode ser transmitido entre entidades. Sinais, dados, bases de dados, tabelas e outras βει 0 truturas de dados podem ser separadamente armazenados e administrados, podem ser incorporados em uma memória única ou base de dados, podem ser distribuídos, ou podem ser logicamente e fisicamente organizados de muitas diferentes maneiras. Os programas podem ser partes de um programa único, programas separados, ou distribuídos através de diversas memó15 rias ou processadores. Além do mais, os programas, ou qualquer porção dos programas, podem em vez disso ser implementados em hardware.

Um exemplo é descrito abaixo em que um varejista baseado na web vende equipamento de computador tal como PCs e impressoras. O varejista usa diversas tabelas exigindo terabytes de armazenagem para rastre20 ar volumes de dados e informação que podem ser usados para derivar informação analítica usando diversas tabelas incluindo: tabela de transação, tabela de cliente.,etabelade distribuidor. A tabela-de transação armazena os registros para a id do produto de cada item vendido e a id do cliente, do comprador. A tabela do cliente armazena informação do cliente para todo 25 cliente, e a tabela do distribuidor armazena informação com respeito a todo distribuidor que está fazendo negócios com o varejista. O varejista pode usar GridBatch para analisar muitos analíticos, alguns dos analíticos incluem estatísticas de contagem simples (por exemplo, quanto de um produto particular foi vendido e identifica os 10 clientes de topo que produzem renda). O 30 varejista pode usar GridBatch para analisar analíticos mais complicados que envolvem múltiplas tabelas e computações complexas. Por exemplo, o varejista pode usar GridBatch para determinar o número de clientes localizados

_em proximidade geográfica para uma facilidade de distribuição do varejista de modo a medir a eficiência da rede de distribuição.

A infra-estrutura de GridBatch opera em um cluster de nós de processamento (nós·). Dois componentes de software operam no ambiente 5 do cluster de GridBatch, nomeado o administrador do sistema de arquivo e o programador de trabalho. O administrador do sistema de arquivo adminrstra arquivos e armazena arquivos através de todos os nós de computação no cluster. O administrador do sistema de arquivo pode segmentar um grande arquivo em blocos menores e armazenar cada bloco em nós separados. En10 tre todos os nós no cluster, GridBatch pode designar, por exemplo, um no para servir como o nó de nome e todos os outros nós servem como nós de dados.

Um nó de dados mantém um bloco de um grande arquivo. Em ‘ uma implementação, dependendo do número de nós no cluster e outras 15 considerações de configuração, um nó de dados pode manter mais de um bloco em um grande arquivo. Um nó de dados responde às exigências do cliente para ler de e escrever para blocos designados ao nó de dados. O nó de nome mantém o espaço de nome para o sistema de arquivo. O nó de nome mantém o mapeamento de um grande arquivo para a lista de blocos, 20 os nós de dados designados para cada bloco, e a localização física e log.ca de cada nó de dados. O nó de nome também responde a consultas de clientes quesolicitam a-localização de um-arquivo e aloca blocos de grandes arquivos para nós de dados. Em uma implementação, GridBatch referência os nós pelos endereços IP dos nós, de modo que GridBatch pode acessar os 25 nós diretamente. O nó master também mantém uma topologia de rede física que mantém informado quais nós estão diretamente conectados. A topologia física da rede pode ser manualmente povoada por um administrador e/ou descoberta através de um algoritmo de descoberta de topologia automatizada A informação de topologia de rede pode aperfeiçoar a performance do 30 operador de funções recursivas pela indicação de nós escravos de vizmhança próxima onde resultados intermediários podem ser enviados e/ou recuperados de modo a reduzir o consumo da largura de banda de rede. Uma bre ,0'

-Mb

ve a descrição da topologia e o seu uso em facilitar a execução do operador de funções recursivas serão discutidos abaixo.

O sistema de arquivo GridBatch distribui grandes arquivos através de muitos nós e informa ao programador de trabalho a localização de cada bloco de modo que o programador de trabalho possa programar tarefas nos nós que hospedam os blocos a serem processados. GridBatch tem como objetivo os problemas de análise de dados em grande escala, tal como depósito de dados, onde uma grande quantidade de dados estruturados necessita ser estruturada. Um arquivo tipicamente armazena uma grande coleção de registros de dados que tem esquema idêntico (por exemplo, proprietário do objeto, ou estrutura, ou família de objetos). Para dados estruturados, GridBatch usa dividir os dados para segmentar os dados em peças menores, similar à divisão de base de dados. O sistema de arquivo do GridBatch armazena arquivos em um número fixado de blocos, cada bloco tendo uma id do bloco (CID). Um programador pode acessar qualquer bloco, independente de outros blocos no sistema de arquivo.

Em uma implementação, o programador pode especificar o número de blocos que o GridBatch pode designar. Em uma outra implementação, um administrador GridBatch especifica o número de blocos que Grid20 Batch pode designar, e/ou GridBatch determina o número de blocos que GridBatch pode designar com base no número de nós disponíveis e/ou ou4ras considerações de-recurso-da-configuração do sistema.-Em uma implementação, o sistema de arquivo GridBatch ajusta a mais alta CID designável para ser muito maior do que N, o números de nós no cluster. GridBatch em25 prega uma tabela de consulta do nível do sistema para prescrever o mapeamento de CID para translação de N. A translação fornece suporte para mudança dinâmica do tamanho do cluster de modo que quando a configuração desativa os nós e os nós adicionais ligam o cluster, o sistema de arquivo GridBatch pode automaticamente reequilibrar a armazenagem e a carga de 30 trabalho. Em outras palavras, o sistema de arquivo mantém um mapeamento de CID para o nó de dados, e move os dados automaticamente para diferentes nós quando a CID para o mapeamento de nó de dados muda (por exem-

pio, quando os nós de dados ligam e/ou deixam o cluster de GridBatch 102).

Em uma implementação, GridBatch processa duas espécies de conjuntos de dados: vetor e vetor indexado. Similar aos registros de uma tabela de base de dados, um vetor inclui um conjunto de registros que Gnd5 Batch considera ser independente um do outro. Os registros em um vetor podem seguir o mesmo esquema, e cada registro pode incluir diversos campos (similar às colunas de base de dados). Ao contrário de um vetor, mas similar a uma tabela de base de dados indexada, cada registro em um vetor indexado também tem um índice associado. Por exemplo, um dos campos 10 do registro no vetor indexado poderia ser o índice associado do vetor indexado e o índice pode ser de qualquer tipo de dados (por exemplo, cadeia ou inteiro).

Quando está usando os vetores indexados, o programador define como os dados devem ser divididos pelos blocos através de uma função 15 de divisão. Quando um novo registro de dados necessita ser escrito, o sistema de arquivo chama a função de divisão para determinar a id do bloco e anexa o novo registro de dados para o fim do bloco correspondendo à id do bloco. Em uma implementação, a função de divisão definida pelo usuário toma a forma: int[] Func.divisão (índice X) onde X representa o índice para o 20 registro a ser escrito e int[] indica uma série de inteiros. A função de divisão aplica uma função unidirecional para converter o índice em um ou mais inteiros na faixa de 1 para-CID que indica a(s) id(s) do bloco designado onde o registro de dados deve ser armazenado. Em uma outra implementação, a função de divisão pode tomar a forma: int[] Func.divisão (chave de distnbui25 ção X) onde X representa o indicador da chave de distribuição para o registro ser escrito para indicar um processador preferido e/ou conjunto de processadores para uso. Quando está usando vetores, o sistema de arquivo GridBatch pode escrever cada novo registro para um bloco escolhido aleatoriamente.

Em uma implementação, quando um usuário solicita um novo arquivo para um novo vetor indexado a ser criado, o usuário fornece ao administrador do sistema de arquivo uma-função unidirecional definida pelo

usuário, que tem a forma de int[] Func.unidirecional (chave de distribuição X). A função unidirecional aceita uma chave de distribuição como entrada, e produz um ou mais inteiros na faixa de 1 para CID. Quando o novo registro é escrito, o administrador do sistema de arquivo invoca a função unidirecional 5 para determinar que divisão para escrever o novo registro. Como resultado,

GridBatch divide o vetor de índice conforme novos registros são processados pelo administrador do sistema de arquivo.

O sistema de programação de trabalho inclui um nó máster e nós escravos múltiplos. O nó máster pode usar a lógica do nó máster para 10 implementar a funcionalidade do nó máster. Um nó escravo administra a execução de uma tarefa designada ao nó escravo pelo nó máster. O nó máster pode usar a lógica do nó máster para quebrar um trabalho (por exemplo, uma computação) em muitas tarefas menores como expressado em um programa por um programador. Em uma implementação, a lógica do nó máster 15 distribui as tarefas através dos nós escravos no cluster, e monitora as tarefas para tornar seguras todas as tarefas completadas com sucesso. Em uma implementação, GridBatch designa nós de dados como nós escravos. Dessa maneira, quando o nó máster programa uma tarefa, o nó máster pode programar a tarefa no nó que também mantém o bloco de dados a ser proces20 sado. GridBatch aumenta a performance computacional através da redução de dependências da largura de banda de rede porque o GridBatch minimiza transferências de dados e executa processamento de dados em local de dados para os nós.

GridBatch fornece um conjunto de operadores chamados primiti25 vos comumente usados que o programador pode usar para implementar paralelização computacional. Os operadores administram os detalhes de distribuição do trabalho para os múltiplos nós, por conseguinte, o programador evita o encargo de endereçar as questões complexas associadas com implementação de uma solução de programação paralela. O programador in30 troduz um conjunto de operadores em um programa, no mesmo padrão como escrevendo um programa seqüencial tradicional.

GridBatch fornece cinco operadores: distribuição, ligação, convo

lução, recursividade, mapa. O operador de distribuição converte um vetor de fonte ou um vetor indexado de fonte para destino do vetor indexado com um índice de destino. A conversão envolve transferir dados de um nó de fonte de dados para um nó de destino de dados. O operador de distribuição toma 5 a seguinte forma: Distribuição do Vetor (vetor V, Func novaFunc.Divisão) onde V representa o vetor onde os dados a serem convertidos residem e novaFunc.Divisão representa a função de divisão que indica o nó de dados de destino onde GridBatch irá gerar um novo vetor. Em uma implementação, a função de divisão definida pelo usuário toma a forma int[] nova10 Func.Divisão(índice X), onde X representa o índice do registro, e int[] denota uma série de inteiros. A função de divisão definida pelo usuário retorna uma lista de números correspondendo à lista de nós de dados de destino. Em uma implementação, o operador de distribuição pode duplicar um vetor em todos os nós, de modo que cada nó tem uma cópia exata para processa15 mento local conveniente. A duplicação do vetor em todos os nós pode resultar quando a novaFunc.Divisão retorna uma lista de todos os nós de dados como nós de destino.

O operador de Ligação obtém dois vetores indexados e une os registros correspondentes onde o campo indexado combina. GridBatch iden20 tifica os registros correspondentes que têm um índice combinado e envolve uma função de ligação definida pelo usuário. A função de ligação definida pelo usuário pode simplesmente unir os dois registros (por-exemplo, similar a uma ligação de base de dados), mas geralmente pode implementar qualquer função desejada. O operador de ligação toma a forma: Ligação do Ve25 tor (Vetor X, Vetor Y, Func Func.ligação) onde X e Y representam os vetores indexados a serem ligados e Func.ligação representa a função de ligação definida pelo usuário para aplicar os registros correspondentes nos vetores indexados. O operador de ligação produz um novo vetor que inclui os resultados de aplicar a função definida pelo usuário. A função de ligação definida 30 pelo usuário toma a seguinte forma: Registro Func.ligação (Registro Z, Registro K) onde Z e K representam um registro do vetor X e Y, respectivamente. Quando GridBatch invoca a função definida pelo usuário, GridBatch pode

garantir que os índices para registro Z e K combinam.

GridBatch pode executar uma operação de distribuição antes de executar a operação de ligação de modo que GridBatch divide o vetor X e Y usando a função de divisão no mesmo campo de índice que a Ligação irá subseqüentemente usar. O operador de ligação executa a ligação em cada nó localmente sem determinar se GridBatch distribuiu ou mandou vir dados para cada nó. Em uma implementação, o operador de ligação automaticamente executa o operador de distribuição antes de executar a ligação.

O operador de ligação pode ser usado quando existe uma com10 binação exata no campo de índice. No entanto, quando um programador deseja identificar o resultado inverso do operador de ligação (por exemplo, identificar registros de não combinação), todo registro Z é checado contra todo registro K. O operador de convolução identifica registros de combinação Z e K e aplica uma função definida pelo usuário para cada combinação. O operador de convolução fornece capacidade adicional e fornece mais opções computacionais para o programador. Em uma implementação, todas as operações computacionais que envolvem dois vetores podem ser efetuadas através do operador de convolução. O operador de convolução pode executar a função de ligação em vetores não indexados usando qualquer campo 20 do vetor, mesmo quando a ligação usa um campo não indexado para a ligação. O operador de convolução toma a seguinte forma: Convolução do vetor (vetor-Xj vetor Y, func Func.conv) onde X -e Y representam os dois vetores de entrada, e o Func.conv representa a função de convolução definida pelo usuário fornecida pelo programador. O operador de convolução produz um 25 novo vetor como resultado. A função definida pelo usuário toma a seguinte forma: Registro Func.conv (registro Z, registro K) onde Z e K representam um registro do vetor X e Y, respectivamente. A função Func.conv determina se qualquer ação deve ser tomada (por exemplo, determina se o registro Z combina com o registro K) e então executa a ação correspondente.

GridBatch pode executar o operador de Distribuição antes de executar o operador de convolução de modo que o GridBatch divide o vetor X e o Y no mesmo campo de índice que a convolução pode subsequente·~ - / 43Γ

J FIs. .ΑΏ^· *ζλ. y 4. ~ H mente usar. 0 operador de convolução executa a computação em cada no localmente sem determinar se o GridBatch distribuiu ou mandou vir dados para cada nó. Em outras implementações, o operador de convolução automaticamente executa o operador de distribuição antes de executar a convo5 lução.

Como um exemplo, um programador pode desejar determinar o número de clientes localizados em proximidade imediata aos distribuidores de um varejista. O sistema de arquivo GridBatch geraria um vetor de cliente que inclui um campo de localização física que indica a localização física de 10 cada cliente, e um vetor de distribuição que inclui um campo de localização física que indica a localização física de cada distribuidor. O programador pode usar o GridBatch para unir o vetor do cliente e o vetor do distribuidor com base no campo de localização física de ambos os vetores. O programador pode usar o Func.conv para avaliar a distância física entre cada cliente e 15 cada distribuidor com base na proximidade especificada pelo programador, e armazena cada registro satisfazendo a proximidade especificada em um vetor de resultados.

Em uma implementação, o operador de funções recursivas executa uma operação reduzida, que toma todos os registros de um vetor e une20 os em um resultado único. A operação lógica real executada nos registros do vetor é definida por uma função especificada pelo usuário. Além disso, é um -exemplo-da operação de redução onde todos-os registros de um vetor são adicionados juntos. Classificando um outro exemplo da operação de redução onde todos os registros de um vetor são checados um contra o outro para 25 produzir uma seqüência desejada. O operador de funções recursivas expande a operação de redução através de muitos nós. As aplicações na web muitas vezes executam freqüentes operações de redução (por exemplo, contagem de palavras, onde cada palavra exige uma operação de redução para somar o número de aparências), ao contrário da maioria das aplicações ana30 líticas que executam poucas operações de redução. O operador de redução da maioria das aplicações analíticas se torna um estrangulador e limita a escalabilidade de uma aplicação quando um programador meramente ne

cessita uma saída classificada para relatório ou umas poucas estatísticas. Muitas operações de redução exibem propriedades comutativas e associativas, e podem ser executadas em ordem independente.

Por exemplo, a contagem do número de ocorrências de um e5 vento envolve o operador comutativo e associativo conhecido como adição.

A ordem em que a adição ocorre não afeta o resultado final. Similarmente, a classificação pode ser independente de ordem. O operador de funções recursivas GridBatch executa operações de redução independente de ordem e toma a seguinte forma: Recursiva de Registro (Vetor X, Func Func.recursiva) 10 onde X representa o vetor de entrada para redução e Func.recursiva representa a função recursiva definida pelo usuário para aplicar. O operador de função recursiva une o vetor em um registro único. A função Func.recursiva definida pelo usuário toma a seguinte forma: Registro Func.recursiva (Registro Z1, Registro Z2) onde Z1 e Z2 representam resultados parciais de uniões 15 de duas sub-partes do vetor X. A função Func.recursiva específica como adicionalmente unir os dois resultados parciais.

Por exemplo, onde o vetor X representa um vetor de inteiros e o programador deseja computar a soma dos inteiros então o programador usará a função de adição como a função Func.recursiva definida pelo usuário 20 expressada: Adição de registro(Registro Z1, Registro Z2) {retorno de novo Registro(valor.Z1 () + valor.Z2())}. O GridBatch irá aplicar a função de adição recursivamente sobre os registros do vetor X para eventualmente computar a soma total dos inteiros no vetor.

Em um outro exemplo, o vetor X inclui registros que representam 25 listas classificadas de restrições e o programador deseja classificar as restrições para o relatório finai. A Tabela 1 ilustra como GridBatch pode implementar a função definida pelo usuário para classificar as restrições. A função definida pelo usuário une duas listas classificadas de restrições em uma restrição classificada e quando o programador implementa a função definida 30 pelo usuário para ser chamada recursivamente, a função definida pelo usuário implementa o algoritmo de classificar a união.

Tabela 1 - Função Definida pelo Usuário para Classificação.

Registro Class.unir (Registro Z1, Registro Z2) {novo Registro Z;

// a seguir restrição do registro Z1

Restrição a = Z1 .seguinte();

// a seguir restrição de registro Z2

Restrição b = Z2.seguinte();

fazer{ se ( a < b ) {

Z.anexo(a);

a = Z1 .seguinte();

} mais {

Z.anexo(b);

b = Z2.seguinte();

} } enquanto (!Z1 .vazio () &&

!Z2.vazio());

retorno x;

J_________________

----- A função recursiva paraleliza a operação de redução por muitos nós. Além disso, a função Recursiva minimiza o tráfego na rede para operações que necessitam resultados parciais. Por exemplo, onde um programa5 dor necessita identificar os 10 clientes de topo que produzem renda, cada nó computa os 10 clientes de topo locais e envia os resultados (por exemplo, resultados parciais) para nós adjacentes que por sua vez unem os resultados parciais com o resultado local do nó de recepção para produzir os 10 de topo. Cada nó somente passa os registros dos 10 de topo para nós adjacen10 tes particulares, em vez de passar todo registro de cada nó para um nó único executando a operação de redução. Dessa maneira, o operador de funções recursivas evita exigências de grandes larguras de banda e tráfego de

rede indesejável, e fornece maior performance computacional.

O operador de mapa aplica uma função de mapa definida pelo usuário a todos os registros de um vetor. O operador de mapa toma a seguinte forma: Mapa do Vetor (vetor V, Func Func.mapa) onde V representa o vetor, mais especificamente os registros do vetor, para o que a Func.mapa será aplicada. A função de mapa definida pelo usuário pode tomar a seguinte forma: Registro Func.mapa(Registro X). A função definida pelo usuário, Func.mapa, aceita um registro do vetor de entrada como um argumento e produz um novo registro para o vetor de resultado.

Em uma implementação, GridBatch tolera as falhas e erros do nó escravo pela reexecução de tarefas quando os nós escravos falham para completar tarefas. Cada bloco do vetor de um vetor é duplicado X vezes em X diferentes nós escravos designados nós de backup, onde X é uma constante que pode ser especificada pelo usuário e/ou determinada por GridBatch com base na configuração, recursos disponíveis e/ou observações históricas. Durante a computação de qualquer operador, se um nó escravo falha antes do nó escravo completar a tarefa designada, o nó máster é informado e o nó máster inicia um outro processo em um nó escravo que mantém uma cópia do backup do bloco do vetor. O nó máster identifica um nó escravo como um nó escravo falhado quando o nó máster não recebe uma pulsação periódica do nó escravo.

________________A figura 1 ilustra a configuração do-sistema GridBatch 100 (GridBatch) que inclui um cluster de GridBatch 102, uma aplicação 104 e interface do usuário 106. Os componentes do GridBatch 100 se comunicam 25 através de uma rede 108 (por exemplo, a Internet, uma rede de área local, uma rede de área ampla, ou qualquer outra rede). O cluster de GridBatch 102 inclui múltiplos nós (por exemplo, nó máster 116 e nó escravo 120). Cada nó escravo 120 pode incluir uma interface de comunicações 113 e memória 118. O GridBatch 100 designa um nó máster 116, e os nós remanescen30 tes, nós escravos (por exemplo, nó escravo 120). O GridBatch 100 pode designar nós escravos como nós de dados (por exemplo, nó de dados 134), descritos adicionalmente abaixo. O nó escravo 120 usa lógica de nó escravo

160 para administrar a execução de tarefas escravas 158 designadas áóíffô ' escravo 120 pelo nó máster 116.

A figura 2 mostra um exemplo de Nó Máster 116. O nó máster

116 pode incluir uma interface de comunicações 211 e memória 215. O 5 GridBatch 100 usa lógica de administração do sistema do arquivo 222 para administrar e armazenar arquivos através de todos os nós no cluster de GridBatch 102. Em uma implementação, a lógica de administração do sistema do arquivo 222 segmenta um grande arquivo em pequenos blocos e armazena os blocos entre os nós escravos. A lógica de administração do sis10 tema do arquivo 222 mantém um mapeamento de CID para o nó de dados, e move os dados automaticamente para diferentes nós quando a CID para mapeamento de nó de dados muda (por exemplo, quando o nó de dados se une ao e/ou deixa o cluster de GridBatch 102). O GridBatch 100 usa lógica de programador de trabalho 230 para coordenar operações entre todos os 15 nós no cluster de GridBatch 102.

Entre todos os nós no cluster de GridBatch 102, o GridBatch 100 pode designar o nó máster 116 como o nó de nome 232, e designa todos os outros nós para servirem como nós de dados (por exemplo, nó de dados 134). O nó de nome 232 mantém o espaço de nome 238 do sistema de ar20 quivo 240. O nó de nome 232 mantém os mapeamentos do vetor 242 de arquivos para a lista de blocos do vetor correspondentes, os nós de dados designados para cada-bloco, e o local físico e lógico de cada nó de dados. O nó de nome 232 também responde às solicitações de tarefa 244 para a localização de um arquivo. Em uma implementação, o nó de nome 232 aloca 25 blocos de grandes arquivos para nós de dados.

O nó máster 116 falha uma tarefa 252 (por exemplo, uma computação) como expressado em um programa por um programador em tarefas escravas (por exemplo, tarefa escrava 158) que a lógica de programador de trabalho 230 distribui entre os nós escravos. Em uma implementação, o 30 nó máster 116 distribui as tarefas escravas através dos nós escravos no cluster de GridBatch 102, e monitora as tarefas escravas para tornar seguras todas as tarefas completadas com sucesso. Dessa maneira, quando o nó

máster 116 programa uma tarefa 252, o nó máster 116 pode programar as tarefas escravas (por exemplo, tarefa escrava 158) no nó escravo que também mantém o bloco de dados a ser processado. Por exemplo, o nó máster

116 pode decompor a tarefa 252 em tarefas escravas correspondendo aos nós escravos onde os dados a serem processados residem localmente em blocos do vetor, de modo que o GridBatch 100 aumenta a performance computacional por redução das dependências da largura de banda da rede minimizando transferências de dados e executando processamento de dados no local de dados para os nós.

Em uma implementação, o GridBatch 100 implementa a lógica de nó máster 260 no nó máster 116 que coordena a comunicação e interação entre o cluster de GridBatch 102, a aplicação 104 e a interface do usuário 106. A lógica de nó máster 260 pode coordenar e controlar a lógica de administrador do sistema 222 e a lógica de programador de trabalho 230. A lógica de nó máster 260 pode manter a biblioteca de software de GridBatch 262 que inclui a lógica de operador de distribuição 264, a lógica do operador de ligação 266, a lógica do operador de convolução 268, a lógica do operador recursive 270 e a lógica do operador de mapa 278. O nó máster 116 pode receber solicitações de tarefa 244 e coordena a execução das solicitações de tarefa 244 através dos nós escravos e da lógica de nó escravo 160.

A figura 3 mostra o GridBatch 100 durante o processamento de uma chamada de função de distribuição 300 (por exemplo,-solicitação de tarefa 244) e exercício da lógica do operador de distribuição 264. Em uma implementação, o nó máster 116 recebe a chamada da função de distribuição 300 para executar o operador de distribuição com parâmetros que incluem um identificador do primeiro vetor 272 que identifica um primeiro vetor para redistribuir para obter blocos do vetor redistribuídos, redistribuídos entre um conjunto de nós. Por exemplo, o primeiro vetor pode representar um vetor previamente distribuído com blocos do vetor distribuídos V1C1 308, V1C2 310, e V1C3 312 entre um conjunto de nós (por exemplo, nó escravo 1 328, nó escravo 3 330, e nó escravo 6 332, respectivamente). Os blocos do vetor V1C1 308, V1C2 310, e V1C3 312 incluem registros de bloco do vetor cor-

respondentes V1C1R1-V1C1RX 322, V1C2R1-V1C2RY 324 e V1C3R1V1C3RZ 326, respectivamente.

A lógica de nó máster 260 inicia a execução de uma função de divisão gerando tarefas de divisão 334 em cada conjunto de nós (por exem5 pio, o nó escravo 1 328, o nó escravo 3 330, e o nó escravo 6 332, respectivamente) com blocos de primeiro vetor. A seta 336 representa uma transição para um estado de nó onde cada nó com blocos de primeiro vetor executa tarefas de divisão 334. Os registros de cada bloco do vetor V1C1 308, V1C2 310 e V1C3 312 do bloco de primeiro vetor podem ser avaliados pelas tare10 fas de divisão 334 correspondentes para determinar o destino das designações de bloco do vetor. Por exemplo, cada tarefa de divisão 334 pode avaliar os registros de bloco do primeiro vetor residindo no nó escravo correspondente para determinar um destino da localização do bloco do vetor para redistribuir cada registro de bloco do primeiro vetor. Cada tarefa de divisão 334 15 pode criar o destino de arquivos de designação de bloco do vetor (por exemplo, V1C1F1 338, V1C2F1-V1C2F4-V1C2F3-V1C2F6 340 e V1C3F1V1C3F2- V1C3F5-V1C3F6 342) no nó escravo correspondente a cada destino da localização do bloco do vetor (por exemplo, destino da designação do bloco do vetor) onde os registros do bloco do primeiro vetor serão redistribu idos.

O nó máster 116 pode receber notificações de conclusão de tarefa-de-cada-tarefa de divisão 334 conforme cada tarefa de divisão 334 é completada. O nó máster 116 inicia a execução de uma tarefa de redistribuição através da geração de tarefas de redistribuição 344 em cada nó escravo 25 (por exemplo, o nó escravo 1 328, nó escravo 3 330, nó escravo 4 346, nó escravo 5 348, nó escravo 6 332 e o nó escravo 8 350). A seta 346 representa uma transição para um estado de nó em que cada nó que corresponde ao destino dos blocos do vetor executa tarefas de redistribuição 344. O destino dos blocos do vetor (por exemplo, V1C1 352, V1C2 354, V1C3 356, 30 V1C4 358, V1C5 360 e V1C6 362) indicado pelas localizações do bloco do vetor identificado pelos arquivos de designação de bloco do vetor (por exemplo, V1C1F1 338, V1C2F1-V1C2F4-V1C2F3-V1C2F6 340 e V1C3F1-

V1C3F2- V1C3F5-V1C3F6 342). As tarefas de redistribuição 344 iniciam a reprodução remota dos arquivos de designação de bloco do vetor para nós escravos de destino correspondente para colocar os arquivos de designação do bloco do vetor no nó escravo correspondente ao bloco do vetor designado ao nó escravo (por exemplo, V1C1F1-V1C3F1-V1C2F1 364, V1C3F2 368, V1C2F3 370, V1C2F4 372, V1C3F5 374, e V1C3F6-V1C3F6 376).

As tarefas de redistribuição 344 iniciam uma união 378 dos registros (por exemplo, V1C1R1-V1C1RX 382, V1C2R1-V1C2RY 384, V1C3R1-V1C3RZ 386, V1C4R1-V1C4RQ 388, V1C5R1-V1C5RS 390 e V1C6R1-V1C6RT 392) localizados em cada arquivo de designação de bloco do vetor correspondendo a um destino particular do bloco do vetor. A seta 380 representa uma transição para um estado de nó em que cada nó correspondendo ao destino dos blocos do vetor executa uma união 378. A união 378 resulta nos blocos do vetor redistribuídos do primeiro vetor, redistribuídos entre o conjunto de nós. A lógica de nó escravo 160 de cada nó escravo envia ao nó máster 116 uma comunicação de conclusão que indica o status de conclusão da união 378.

A figura 4 mostra o GridBatch 100 durante o processamento de uma chamada de função de ligação 400 (por exemplo, solicitação de tarefa 244) e exercício da lógica do operador de ligação 266. Em uma implementação, o nó máster 116 recebe a chamada de função de ligação 400 com parâmetros que incluem-o-identificador-do-primeiro vetor-272 e um-identificador do segundo vetor 274, e uma função de ligação definida pelo usuário (por exemplo, uma função definida pelo usuário 276). O identificador do primeiro vetor 272 e um identificador do segundo vetor 274 identificam o primeiro vetor e um segundo vetor divididos em blocos do primeiro vetor (por exemplo, V2C1 410, V2C2 412 e V2C3 414). Os blocos do primeiro vetor e os blocos do segundo vetor incluem registros do primeiro vetor (por exemplo, V1C1R1V1C1RZ 416, V1C2R8-V1C2RJ 418 e V1C3R4-V1C3RL 420) e registros do segundo vetor (por exemplo, V2C1R3-V2C1RY 422, V2C2R7-V2C2RK 424 e V2C3R4-V2C3RM 426), respectivamente.

O nó máster 116 inicia a geração de tarefas de classificação (por

exemplo, tarefas escravas 158) localmente no conjunto de nós (por exemplo, nó escravo 1 428, nó escravo 4 430 e nó escravo 6 432) correspondendo à localização dos blocos do primeiro vetor e blocos do segundo vetor para classificar cada dos blocos do primeiro vetor e blocos do segundo vetor para o segundo vetor localizado em cada do conjunto de nós. Em uma implementação, a tarefa de classificar 434 classifica os registros do primeiro vetor e os registros do segundo vetor de acordo com um valor de índice do campo de índice de ligação presente em cada registro do primeiro vetor, do primeiro vetor (por exemplo, V1C1R1IF-V1C1RZIF 438, V1C2R8IF-V1C2RJIF 440 e V1C3R4IF-V1C3RLIF 442) e cada registro do segundo vetor, do segundo vetor (por exemplo, V2C1R3IF-V2C1RYIF 444, V2C2R7-V2C2RKIF 446 e V2C3R4-V2C3RMIF 448), respectivamente. A seta 436 representa uma transição para um estado de nó em que cada nó com blocos do vetor execu ta tarefas de classificação 434.

Em uma implementação, a tarefa de classificação 434 compara o valor de índice do campo de índice presente nos registros do primeiro vetor e os registros do segundo vetor para determinar os registros do primeiro vetor e registros do segundo vetor que inclui combinar valores de índice e aplicar a função definida pelo usuário 276 (por exemplo, uma função de liga20 ção definida pelo usuário) para registros do primeiro vetor e registros do segundo vetor com combinação dos valores do campo de índice. A tarefa de classificação 434 executa- uma tarefa de combinação 450 que compara os valores do campo de índice dos campos de índice dos registros do primeiro vetor e registros do segundo vetor. A seta 452 representa uma transição pa25 ra um estado de nó em que cada nó com blocos do vetor executa tarefas de combinação 450. A tarefa de combinação 450 aplica a função definida pelo usuário 276 (por exemplo, uma função de ligação definida pelo usuário) para registros do primeiro vetor e registros do segundo vetor com combinação de valores do campo de índice para blocos do vetor correspondentes (por e30 xemplo, V1C2RBIF 454 e V2C2RPIF 456, e V1C2RBIF 458 e V2C2RPIF 460) para obter um resultado de bloco de função de ligação (e.g., NO JFC1R 462, JFC2R 464 e JFC3R 466). A tarefa de combinação 450 não

aplica a função de ligação definida pelo usuário para registros do primeiro vetor e registros do segundo vetor quando os valores do campo de índice para blocos do vetor correspondentes não combinam (por exemplo, V1C1RXIF 468 e V2C1RYIF 470).

Os resultados do bloco de função de ligação formam um resultado do vetor de função de ligação que identifica blocos do vetor de função de ligação (por exemplo, JFVC1 476 e JFVC2 478) que inclui registros de bloco do vetor de função de ligação (JFVC1RT 480 e JFVC2R3-JFVC2RN 482) obtida dos resultados de bloco de ligação (por exemplo, JFC2R 464 e 10 JFC3R 466). Em uma implementação, a lógica de nó escravo 160 de cada nó escravo envia ao nó máster 116 uma comunicação de conclusão que indica o status de conclusão da tarefa de classificação 434.

Por exemplo, em uma implementação, um programador pode usar o GridBatch 100 para indexar dois vetores, um vetor de produto (por 15 exemplo, primeiro vetor identificado pelo identificador do primeiro vetor 272) indexado por um campo da id do produto (por exemplo, V1C1R1IFV1C1RZ1F 438, V1C2R8IF-V1C2RJIF 440 e V1C3R4IF-V1C3RLIF 442) e o vetor do cliente (por exemplo, segundo vetor identificado pelo identificador do segundo vetor 274) indexado pelo campo de id do cliente (por exemplo, 20 campos de índice V2C1R3IF-V2C1RYIF 444, V2C2R7-V2C2RKIF 446 e V2C3R4-V2C3RMIF 448). O vetor do produto inclui a id do produto e a id do cliente -correspondendo aos -produtos comprados-(por exemplo_?-valores do campo de índice). O vetor do cliente mantém a id do cliente e a informação demográfica dos clientes (por exemplo, valores do campo de índice tais co25 mo idade, endereço, sexo). No evento o programador deseja saber quantas pessoas em cada grupo de idade comprou um produto em particular, o programador invoca uma chamada de função de ligação com o vetor do produto e o vetor do cliente como parâmetros para obter um resultado de ligação que liga a informação da ID do produto com a informação demográfica do cliente. 30 Em uma implementação, de modo a assegurar uma performance maior pelo GridBatch 100 em processar a função de ligação 400 do vetor do produto e o vetor do cliente com base no campo da id do cliente (por exemplo, campo de

índice), o programador invoca a chamada de função de distribuição 300 para indexar o vetor do produto pela id do cliente em vez da id do produto. A chamada de função de distribuição assegura que GridBatch 100 distribua os registros do vetor do produto aos nós no cluster de GridBatch 102 de acordo com o campo da id do cliente. GridBatch 100 então pode aplicar a função definida pelo usuário 276 (por exemplo, uma função de ligação definida pelo usuário) para cada registro do vetor do produto e do vetor do cliente onde os valores do campo da id do cliente tanto do vetor do produto quanto do vetor do cliente se igualam para obter o resultado do vetor da função de ligação.

1θ A figura 5 mostra o GridBatch 100 durante o processamento de uma chamada da função de convolução 500 (por exemplo, solicitação de tarefa 244) e exercício da lógica do operador de convolução 268. Em uma implementação, o nó máster 116 recebe a chamada da função de convolução 500 com parâmetros que incluem o identificador do primeiro vetor 272 e o identificador do segundo vetor 274, e uma função de convolução definida pelo usuário (por exemplo, uma função definida pelo usuário 276). O identificador do primeiro vetor 272 e um identificador do segundo vetor 274 identificam o primeiro vetor e um segundo vetor divididos em blocos do primeiro vetor (por exemplo, V1C1 504 e V1C2 506) e os blocos do segundo vetor (por exemplo, V2C1 508 e V2C2 510) correspondem a blocos do vetor divididos distribuídos através de nós do cluster de GridBatch 102. Os blocos do

-primeiro vetor e os blocos do segundo vetor- incluem registros de bloco do primeiro vetor (por exemplo, V1C1R1 -V1C1RZ 512 e V1C3R4-V1C3RL 514) e registros de bloco do segundo vetor (por exemplo, V2C1R3-V2C1RY 516 e 25 V2C3R4-V2C3RM 518), respectivamente.

O nó máster 116 inicia a geração de tarefas de convolução (por exemplo, tarefas escravas 158) localmente no conjunto de nós (por exemplo, nó escravo 1 520 e nó escravo 8 522) correspondendo à localização dos blocos do primeiro vetor e dos blocos do segundo vetor. A seta 526 repre30 senta uma transição para um estado de nó para cada nó onde o nó máster 116 gera as tarefas de convolução 524. As tarefas de convolução 524 aplicam a função definida pelo usuário 276 (por exemplo, uma função de con-

clusão definida pelo usuário) localmente para as permutações dos registros de bloco do primeiro vetor e dos registros de bloco do segundo vetor (por exemplo, 528 e 530). A função de convolução definida pelo usuário avalia cada permutação correspondente de registros de bloco do primeiro vetor e de registros de bloco do segundo vetor (por exemplo, 528 e 530) para obter resultados de avaliação da função de convolução (por exemplo, 536, 538, 540 e 542). A seta 534 representa uma transição para um estado de nó para cada nó onde a função de convolução definida pelo usuário avalia cada permutação de registros de bloco do primeiro vetor e de registros de bloco do segundo vetor correspondentes. Os resultados de avaliação da função de convolução podem indicar quando uma permutação dos registros de bloco do primeiro vetor e dos registros de bloco do segundo vetor correspondentes resulta em registros de resultado de bloco de função de convolução (por exemplo, CFC1R1-CFC1R3-CFC1R4-CFC1RZ 536 e CFC2R3-CFC2RK 540). Os resultados de avaliação da função de convolução podem indicar quando uma permutação dos registros de bloco do primeiro vetor e dos registros de bloco do segundo vetor correspondentes resulta em nenhum registro de resultado de bloco de função de convolução (por exemplo, NO CFC1RX 538 e NO CFC2RY 542). A função de convolução definida pelo usuário pode transformar os resultados da função de convolução em registros de resultado de bloco da função de convolução (por exemplo, CFVC1R1-CFVC1R3GFVG1R4-GFVC1RZ 548 e CFVC2R3-CFVC2RK 550) para obter resultados da função de convolução para cada nó (por exemplo, nó escravo 1 520 e nó escravo 8 522).

Por exemplo, em uma implementação, um programador pode invocar a chamada da função de convolução 500 para determinar o número de clientes localizados em proximidade imediata aos distribuidores de um varejista. A lógica de administração do sistema do arquivo 222 pode incluir um vetor de cliente (por exemplo, primeiro vetor identificado pelo identificador do primeiro vetor 272) que inclui um campo de localização física que indica a localização física de cada cliente e um vetor de distribuidor (por exemplo, segundo vetor identificado pelo identificador do segundo vetor 274)

que inclui um campo de localização física que indica a localização física de cada distribuidor. O programador pode invocar a chamada da função de convolução 500 para aplicar uma função de convolução definida pelo usuário (por exemplo, função definida pelo usuário 276) para o vetor do cliente e ve5 tor do distribuidor com base no campo de localização física para avaliar a distância física entre cada cliente e cada distribuidor e obter um vetor de resultados da função de convolução. Em uma implementação, a função de convolução definida pelo usuário pode ser expressada como Func.conv. Antes da chamada de convolução, o vetor do cliente pode ser dividido em blo10 cos do vetor do cliente (por exemplo, blocos do primeiro vetor - V1C1 504 e

V1C2 506) divididos através dos nós de cluster de GridBatch 102 de acordo ' com o campo de localização física (por exemplo, campo de índice) presente em cada dos registros do vetor do cliente. Os blocos do vetor do distribuidor (por exemplo, blocos do segundo vetor - V2C1 508 e V2C2 510) podem ser 15 copiados para todos os nós do cluster. Isso pode ser alcançado por suprimento de uma função de divisão que sempre retorna uma lista de todos os nós para o operador de distribuição. A função de convolução definida pelo usuário avalia as permutações de registros do vetor do cliente e os registros do vetor do distribuidor residindo em nós escravos correspondentes, para 20 obter registros de resultados de bloco de função de convolução. Em outras palavras, onde o bloco do vetor do cliente tem o número Z de registros e o bloco do vetor do-distribuidor tem o número K de registros,-a função de convolução definida pelo usuário pode avaliar o número de permutações Z x K onde para cada registro 1 a Z do bloco do vetor do cliente GridBatch 100 25 aplica a função de convolução definida pelo usuário para todo registro 1 a K do bloco do vetor do distribuidor. O resultado da chamada da função de convolução executada por cada nó escravo de cluster de GridBatch 102 resulta em blocos do vetor da função de convolução correspondente para obter resultados da função de convolução (por exemplo, nó escravo 1 520 e nó es30 cravo 8 522).

A figura 6 ilustra GridBatch 100 durante o processamento de uma chamada de função recursiva 600 (por exemplo, solicitação de tarefa

244) e exercício da lógica do operador recursive 270. Em uma implementação, o nó máster 116 recebe a chamada de função recursive 600 com parâmetros que incluem o identificador do primeiro vetor 272 e uma função recursiva definida pelo usuário (por exemplo, função definida pelo usuário 5 276). O identificador do primeiro vetor 272 identifica o primeiro vetor dividido em blocos do primeiro vetor (por exemplo, V1C1 604, V1C2 606 e V1C3 610) correspondendo aos blocos do vetor dividido distribuídos através dos nós do cluster de GridBatch 102. Os blocos do primeiro vetor incluem registros de bloco do primeiro vetor (por exemplo, V1C1R1-V1C1 RX 616, 10 V1C1R3-V1C1 RJ 618, V1C2R1-V1C2RY 620, V1C2RK-V1C2RN 622, V1C3R4-V1C3RZ 624 e V1C3RG-V1C3RM 626).

O nó máster 116 inicia a geração de tarefas recursivas 634 (por exemplo, tarefas escravas 158) localmente no conjunto de nós (por exemplo, nó escravo 1 628, nó escravo 4 630 e nó escravo 6 632) correspondendo à 15 localização dos blocos do primeiro vetor. A seta 636 representa uma transição para um estado de nó em que cada nó com blocos do primeiro vetor executa as tarefas de função recursive 634. As tarefas de função recursive 634 inicialmente aplicam a função recursiva definida pelo usuário para os registros de bloco do primeiro vetor para produzir resultados de bloco do ve20 tor recursive imediato para cada bloco do primeiro vetor (por exemplo, IRV1C1R1 638, IRV1C1R2 640, IRV1C2R1 642, IRV1C2R2 644, IRV1C3R1 646 e IRV1G3R2648). As tarefas recursivas invocam a função recursiva definida pelo usuário nos resultados de bloco do vetor recursive imediatos para produzir resultados de nó escravo recursive imediato (por exemplo, IRSN1R 25 650, IRSN4R 652 e IRSN6R 654).

As tarefas recursivas comunicam um subconjunto dos resultados de nó escravo recursive intermediário (por exemplo, IRSN1R 650) para um subconjunto do conjunto de nós (por exemplo, nó 4 630) e a invocação itera as tarefas recursivas da função recursiva definida pelo usuário nos resulta30 dos intermediários (por exemplo, IRSN1R 650 e IRSN4R 652) para produzir resultados de nó escravo intermediário progressivamente menos (por exemplo, IFIRSN4R 660). As tarefas recursivas comunicam um subconjunto dos

resultados intermediários progressivamente menos (por exemplo, IFIRSN4R 660) para um subconjunto progressivamente menor do conjunto de nós (por exemplo, nó escravo 6 632) até GridBatch 100 obter um resultado recursivo final (por exemplo, FRR 668) em um nó final no conjunto de nós.

Em uma implementação, um subconjunto dos resultados intermediários comunicados pelas tarefas recursivas para um subconjunto do conjunto de nós inclui uma metade dos resultados intermediários que produzem um subconjunto de resultados intermediários progressivamente menores. Similarmente, cada subconjunto de resultados intermediários progressivamente menos subsequentemente comunicados pelas tarefas recursivas para um subconjunto do conjunto de nós inclui uma metade dos resultados intermediários progressivamente menos. Em uma implementação, a lógica do operador recursivo 270 usa informação de topologia de rede para aperfeiçoar a performance de computação do operador recursivo identificando nós escravos vizinhos próximos onde os resultados intermediários podem ser enviados e/ou recuperados de modo a reduzir o consumo da largura de banda da rede. O programador, o usuário e/ou 10 podem definiri os fatores que determinam se um nó escravo constitui um nó escravo vizinho próximo para um outro nó escravo. Os fatores que podem ser usados para determinar se um nó escravo é designado um nó escravo vizinho próximo pode incluir tempos de transmissão de dados entre os nós escravos, o número de hops da rede (por-exemplo, número de roteadores da rede) entre nós escravos, ou uma combinação de tempos de transmissão de dados e hops da rede.

A figura 6 ilustra como a lógica do operador recursivo 270 de GridBatch distribui resultados intermediários entre os nós escravos do cluster de GridBatch 102. Os nós escravos podem computar um resultado recursivo intermediário local (por exemplo, IRSN1R 650, IRSN4R 652 e IRSN6R 654). Um subconjunto dos nós escravos (por exemplo, nó escravo 1 628) pode transmitir o resultado recursivo intermediário local (por exemplo, IRSN1R 650) para um subconjunto dos nós escravos (por exemplo, nó escravo 4 630). Os nós escravos que recebem resultados recursivos interme30 .-M íc I <·$$ - ^;h diários de outros nós escravos podem iterativamente aplicar os resultados intermediários transmitidos (por exemplo, IRSN1R 650) com os resultados intermediários locais (por exemplo, IRSN4R 652). Iterativamente, até um nó escravo único (por exemplo, nó escravo 6 632) produz o resultado recursivo final (por exemplo, FRR 668), um subconjunto (por exemplo, metade) dos nós escravos transmite resultados intermediários para a outra metade de nós com resultados intermediários locais (por exemplo, resultados intermediários de desdobramento transmitidos em resultados intermediários locais).

Em uma implementação, o nó máster determina o esquema para passar resultados intermediários para nós escravos no conjunto de nós e o número de iterações de desdobramento requerido para produzir um resultado recursivo final (por exemplo, FRR 668).

A figura 7 ilustra o fluxo lógico que GridBatch 100 pode obter para executar o operador de distribuição. Em uma implementação, o nó máster 116 recebe a chamada de função de distribuição 300 para executar o operador de distribuição. Em uma implementação, a chamada de função de distribuição 300 pode ser expressada como Distribuição (vetor V, func. novaFunc.Divisão) O vetor V representa o vetor de fonte e novaFunc.Divisão representa uma função que determina a localização de novos nós para dados no vetor V. A figura 7 e a discussão aqui usa o vetor U como uma ajuda notacional para explanar a redistribuição dos dados no vetor V. O vetor V eontém os mesmos dados que o vetor U. A chamada de função-de distribuição 300 resulta em um vetor remanescente, possivelmente dividido em novos blocos que podem ser distribuídos para um diferente conjunto de nós. A lógica de nó máster 260 gera uma tarefa escrava (por exemplo, tarefa escrava 158) correspondendo a cada bloco do vetor do vetor V (702). Em uma implementação, o número de tarefas escravas é igual ao número de blocos de vetor do vetor V. As tarefas escravas residem nos nós escravos onde residem os blocos do vetor correspondentes (704). Localizar as tarefas escravas para os nós escravos onde os blocos do vetor correspondentes residem minimiza a transferência de dados e evita questões de escala na largura de banda da rede. Os nós escravos invocam a lógica de nó escravo 212 para

gerar arquivos de saída que correspondem a blocos do vetor de vetor U onde GridBatch 100 irá redistribuir registros do vetor V (706). A lógica de nó escravo 160 avalia cada registro do bloco do vetor correspondente de V para determinar o identificador de bloco do vetor U onde GridBatch 100 irá redistribuir o registro. A lógica de nó escravo 160 escreve o registro para o arquivo de saída que corresponde ao bloco do vetor do vetor U onde GridBatch 100 irá redistribuir o registro do vetor V.

Conforme cada tarefa escrava completa a avaliação dos registros dos blocos do vetor correspondentes de V, cada tarefa escrava notifica a lógica de nó máster 260 do status de conclusão da tarefa escrava e a localização dos arquivos de saída correspondentes aos blocos do vetor do vetor U (708). A lógica de nó máster 260 gera novas tarefas escravas em nós escravos onde GridBatch 100 irá redistribuir blocos de vetor do vetor V para blocos de vetor do vetor U (710). Cada tarefa escrava recebe uma lista das localizações de arquivos de saída que incluem blocos do vetor de U que correspondem ao nó escravo correspondendo à tarefa escrava e recupera os arquivos de saída para o nó escravo (por exemplo, usando uma operação de cópia remota, ou outra transferência de arquivo). Cada tarefa escrava une os arquivos de saída em blocos do vetor correspondentes de U e notifica a lógica de nó máster 260 do status de conclusão da tarefa escrava (712). Em uma implementação, a chamada de função de distribuição 300 distribui to-dos osregistro do-primeiro vetor para todos os nós escravos disponíveis. Por exemplo, a novaFunc.Divisão da chamada de função de distribuição 300 expressada como Distribuição (vetor V, func. novaFunc.Divisão) pode direcionar GridBatch 100 para distribuir cada registro do vetor V para todos os nós escravos disponíveis para duplicar o vetor V em todos os nós escravos disponíveis.

A figura 8 mostra o fluxo lógico que GridBatch 100 pode obter para executar o operador de ligação. Em uma implementação, a lógica de nó máster 260 recebe a chamada de função de ligação 400 para ligar o vetor X e o vetor Y. Em uma implementação, a chamada de função de ligação 400 pode ser expressada como ligação do Vetor (vetor X, vetor Y, Func.

Func.ligação) (802). A lógica de nó máster 260 gera uma tarefa escrava que corresponde a um número de bloco do vetor (por exemplo, id do bloco do vetor), onde a lógica de administração do sistema do arquivo 222 divide o vetor X e o vetor Y em um número igual de blocos do vetor e a lógica de administração do sistema do arquivo 222 designa blocos do vetor de X e blocos do vetor de Y com números de bloco correspondentes ou ids de bloco do vetor (804). Por exemplo, a lógica de administração do sistema do arquivo 222 pode designar uma id de bloco particular tanto para um bloco do vetor de X quanto para um bloco do vetor de Y residindo em um nó escravo correspondente. Em uma implementação, a tarefa escrava classifica, de acordo com um valor de campo indexado, os registros do bloco do vetor de X e registros do bloco do vetor de Y residindo no nó escravo correspondente (806). A tarefa escrava invoca a lógica de nó escravo 160 e avalia o valor do campo indexado dos registros do bloco do vetor de X e registros do bloco do vetor de Y. Se os valores de campo indexados dos registros do bloco do vetor de X e registros do bloco do vetor de Y são iguais (808), GridBatch 100 invoca uma função de ligação definida pelo usuário (por exemplo, função definida pelo usuário 276). Em uma implementação, a função de ligação definida pelo usuário pode ser expressada como Registro Func.ligação (Registro Z, Registro K) que liga os registros do bloco do vetor de X e registros do bloco do vetor de Y (814). Se a lógica de nó escravo 160 avalia o valor do campo indexado de registro Z do bloco do vetor X-ser menor do que o valor do campo indexado de registro K do bloco do vetor de Y então a lógica de nó escravo 160 avalia o próximo registro Z do bloco do vetor X com o valor do campo indexado de registro K do bloco do vetor de Y (810). Se a lógica de nó escravo 160 avalia o valor do campo indexado de registro Z do bloco do vetor X ser maior do que o valor do campo indexado de registro K do bloco do vetor de Y então a lógica de nó escravo 160 avalia o próximo registro K do bloco do vetor de Y com o valor do campo indexado de registro Z do blo30 co do vetor de X (812). A lógica de nó escravo 160 avalia todo registro Z do bloco do vetor de X e registro K do bloco do vetor de Y (816).

A figura 9 mostra o fluxo lógico que GridBatch 100 pode Obter

para executar o operador de convolução. Em uma implementação, a lógica de nó máster 260 recebe a chamada da função de convolução 500 para pro10 cessar o vetor X e o vetor Y (902). Em uma implementação, a chamada da função de convolução 500 pode ser expressada como Convolução do vetor (vetor X, Vetor Y, Func Func.conv), onde Func.conv é a função de convolução especificada pelo usuário. Para cada registro 1 a Z dos blocos de vetor do vetor X a lógica de nó máster 260 aplica uma função de convolução definida pelo usuário (por exemplo, função definida pelo usuário 276), expressada como Registro Func.ligação (Registro Z, Registro K) para registros 1 a K de blocos de vetor do vetor Y (904). Em outras palavras, se um bloco de vetor do vetor X tem o número Z de registros e um bloco de vetor do vetor Y tem o número K de registros, a função de convolução definida pelo usuário avalia o número de permutações Z x K de pares de registro. A lógica de nó escravo 160 aplica a função de convolução definida pelo usuário para cada registro 1 a K do vetor Y (906) com todo registro 1 a Z do bloco do vetor X (908).

A figura 10 mostra o fluxo lógico que GridBatch 100 pode obter para executar o operador recursive. Em uma implementação, a lógica de nó máster 260 recebe a chamada de função recursive 600 para o vetor recursi20 vo X. Em uma implementação, a chamada de função recursiva 600 pode ser expressada como Recursiva de Registro (Vetor X, Func Func.recursiva). A lógica-de-no máster-2-60 gera tarefas escravas de-operação recursiva correspondendo a cada bloco do vetor residindo em nós escravos correspondentes (1002). As tarefas escravas invocam a lógica de nó escravo 160 para 25 reduzir (por exemplo, unir) o primeiro registro e o segundo registros de bloco de vetor do vetor X residindo em nós escravos correspondentes. A lógica de nó escravo 160 armazena o resultado recursive intermediário (por exemplo, unir) (1004). A lógica de nó escravo 160 avalia se mais registros de bloco de vetor do vetor X existem (1006) e une o próximo registro do bloco de vetor 30 do vetor X para o resultado de união intermediaria (1008). Uma vez que a lógica de nó escravo 160 obtém o resultado de união intermediária dos blocos de vetor do vetor X, cada tarefa escrava notifica a lógica de nó máster

260 do status de conclusão da tarefa escrava (1010). Um subconjunto de tarefas escravas (por exemplo, metade) envia resultados de união intermediária para as tarefas escravas remanescentes (por exemplo, a outra metade) com resultados intermediários locais. O subconjunto de tarefas escravas 5 que recebe os resultados de união intermediária une as tarefas de união intermediária com os resultados de união intermediária local (1012). Os nós escravos com resultados de união intermediária iterativamente dobram os resultados de união intermediária em menos nós escravos, até os nós escravos unirem o número progressivamente menor de resultados de união 10 intermediária em um resultado de união final residindo em um nó escravo (1014).

A figura 11 ilustra o GridBatch 100 durante o processamento de uma chamada de função de mapa 1100 (por exemplo, solicitação de tarefa 244) e exercício da lógica do operador de mapa 278. O operador do mapa 15 pode ser expressado como Mapa do Vetor(vetor V, Func Func.mapa) onde V representa o vetor, mais especificamente os registros do vetor, para o que a Func.mapa será aplicada para obter um novo vetor de registros mapeados de vetor V. O operador de mapa permite que o usuário aplique uma função definida pelo usuário para todos os registros de um vetor. Em uma imple20 mentação, a lógica de nó máster 260 recebe a chamada de função de mapa 1100 com parâmetros que incluem um identificador do primeiro vetor 272 e uma função-de mapa-definida pelo- usuário-(por exemplo, uma função definida pelo usuário 276). O identificador do primeiro vetor 272 identifica o primeiro vetor dividido em blocos do primeiro vetor (por exemplo, V1C1 25 1104, V1C2 1108 e V1C3 1110) correspondendo a blocos de vetor divididos distribuídos através dos nós do cluster de GridBatch 102. Os blocos do primeiro vetor incluem registros de bloco do primeiro vetor (por exemplo, V1C1R1 1116, V1C1RX 1118, V1C2R1 1120, V1C2RY 1122, V1C3R4 1124, e V1C3RZ 1126).

O nó máster 116 inicia uma geração de tarefas de mapa 1134 (por exemplo, tarefas escravas 158) localmente no conjunto de nós (por exemplo, nó escravo 1 1128, nó escravo 4 1130 e nó escravo 6 1132) corres-

pondendo à localização dos blocos do primeiro vetor. A seta 1136 representa uma transição de um estado de nó em que cada nó com blocos de primeiro vetor executa tarefas de mapa 1134 (por exemplo, tarefas de mapa executando em paralelo 1150, 1152 e 1154). As tarefas de mapa 1134 aplicam a função de mapa definida pelo usuário a cada registro de bloco do vetor para produzir os registros de bloco do vetor mapeados que formam blocos do vetor mapeados do vetor Μ. A seta 1158 representa uma transição para um estado de nó em que cada nó com blocos do primeiro vetor inclui blocos de vetor mapeados correspondentes (por exemplo, VMC1 1160, VMC2 1162, e VMC3 1164) com registros de bloco do vetor mapeado correspondente (por exemplo, VMC1R1 1166, VMC1RX 1168, VMC2R1 1170, VMC2RY 1172, VMC3R4 1174, e VMC3RZ 1176).

Por exemplo, um vetor de registro de vendas 1180 pode incluir uma ID do cliente, ID do produto, e data de campo de compra, junto com diversos outros campos. No entanto, para uma análise particular, somente dois campos do vetor de registro de vendas pode ser de interesse, tal como a ID do cliente e a ID do produto. Para uma performance de processamento eficiente, um programador pode invocar a chamada de função de mapa 1100 para executar o operador de mapa para extrair justo os campos da ID do cliente e da ID do produto do vetor de registro de vendas; a chamada de função de mapa 1100 pode ser expressada na seguinte forma: Vetor Ve4or.novo·= Mapa(Vetor.RegistroA/enda, fender). A função de fender definida pelo usuário analisa cada registro do vetor de registro de venda 1180 para produzir novos registros que somente incluem campos da ID do cliente e ID do produto nos registros Vetor.novo 1182.

A figura 12 mostra o fluxo lógico que GridBatch 100 pode obter para executar o operador de mapa. A lógica de nó máster 260 recebe a chamada de função de mapa 1100 para o vetor de mapa V (1202). A lógica de nó máster 260 gera tarefas escravas correspondentes para cada bloco de vetor do vetor V (1204). As tarefas escravas invocam a lógica de nó escravo 160 para localizar cada bloco de vetor do vetor V designado para nós escravos correspondentes (1206). Para cada bloco de vetor do vetor V, a lógica

de nó escravo 160 aplica a Func.mapa definida pelo usuário para cada registro de bloco do vetor para obter registros de bloco do vetor mapeado que formam um bloco de vetor mapeado do vetor M (1208). Uma vez que a lógica de nó escravo 160 aplicou a Func.mapa a cada registro de bloco do vetor do vetor V, cada tarefa escrava notifica à lógica de nó máster 260 do status de conclusão da tarefa escrava e a localização do bloco do vetor mapeado correspondente de Μ. O operador de mapa termina com sucesso quando os nós escravos notificam o nó máster que todas as tarefas escravas terminaram (1210). Os blocos de vetor mapeado do vetor M combinam para formar um novo vetor M.

Os operadores adicionais que GridBatch fornece produzem resultados inesperadamente bons para técnicas de programação paralelas. Em particular, cada operador fornece vantagens significantes sobre as tentativas anteriores em paralelização de aplicação. Os inesperados bons resultados incluem significante flexibilidade, eficiência e aplicabilidade de programação, adicionais para problemas extraordinariamente difíceis faceados por modernos negócios, particularmente com enormes quantidade de dados que devem ser processados em uma estrutura de tempo realística para alcançar resultados significativos.

O modelo de programação Redução.mapa implementa uma construção de programação unitária. Em particular, uma função de Mapa é sempre emparelhada com uma função de Redução. Por outro lado, GridBatch fornece múltiplos operadores independentes: Recurso, Convolução, Ligação, Distribuição e Mapa que um programador pode usar virtualmente em qualquer ordem ou seqüência para construir uma aplicação complexa que executa em paralelo através de muitos nós. Além do mais, a estrutura de suporte GridBatch implementa o usuário com funções definidas especificadas para os operadores independentes através do que o programador pode conferir um grau imenso de funcionalidade especial. Tais funções definidas pelo usuário incluem uma função de divisão para determinar como quebrar um vetor em blocos, uma função unidirecional para distribuir blocos de vetor - entre os nós, uma função de ligação para especificar como combinar recur/ 4 d .

Ή sos, uma função de convolução para suportar o operador de ligação, uma função recursiva que especifica como unir resultados parciais do operador recursivo, e uma função de mapa para aplicação a registros de um vetor.

Um número de implementações foi descrito. Apesar disso, será entendido que várias modificações podem ser feitas sem se afastar do espírito e escopo da invenção. Dessa maneira, outras implementações estão dentro do escopo das reivindicações em anexo.

Claims (12)

1. REIVINDICAÇÕES

   1. Método para processamento de dados em paralelo caracterizado pelo fato de que compreende:

   iniciar a execução de uma primeira operação predeterminada de processamento de dados em paralelo sobre múltiplos nós de processamento (116, 118) por meio do uso de um primeiro operador primitivo, a primeira operação predeterminada de processamento de dados (252) customizada com uma primeira função definida pelo usuário (272) executada nos múltiplos nós de processamento(116, 118); e iniciar a execução de uma segunda operação predeterminada de processamento de dados (252) em paralelo sobre os múltiplos nós de processamento (116, 118) por meio do uso de um segundo operador primitivo, a segunda operação predeterminada de processamento de dados (252) customizada com uma função definida pelo usuário (276) executada nos múltiplos nós de processamento.
2. 2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente:

   designar blocos de vetor de um primeiro vetor (272) entre os múltiplos nós de processamento (116, 118) de acordo com uma função unidirecional definida pelo usuário (276).
3. 3. Método de acordo com a reivindicação 2, caracterizado pelo fato de que compreende adicionalmente:

   fornecer informação da localização de nó do bloco do vetor (242) para os blocos do vetor a um programador de trabalho (230).
4. 4. Método de acordo com a reivindicação 2, caracterizado pelo fato de que compreende adicionalmente:

   rearranjar os blocos de vetor.
5. 5. Método de acordo com a reivindicação 1, caracterizado pelo fato de que:

   a primeira ou segunda lógica do operador compreende lógica do operador de ligação (266);

   a primeira ou segunda função definida pelo usuário compreende

   Petição 870190077337, de 09/08/2019, pág. 5/13 uma função de ligação definida pelo usuário; e onde a lógica do operador de ligação invoca a função de ligação definida pelo usuário em um primeiro registro combinado em um primeiro vetor (272) e um segundo registro combinado em um segundo vetor (274) distribuído entre os múltiplos nós de processamento (428, 430, 432) quando um campo de índice de ligação presente no primeiro e no segundo vetor combina com o primeiro registro de combinação e o segundo registro de combinação, para obter um resultado de ligação (462, 464, 466).
6. 6. Método de acordo com a reivindicação 5, caracterizado pelo fato de que compreende adicionalmente:

   receber uma chamada de função de ligação (400); e iniciar rearranjo de tarefas de ligação (158) localmente entre os múltiplos nós de processamento (428, 430, 432), cada tarefa de ligação operável para seletivamente iniciar a execução da função de ligação definida pelo usuário (276).
7. 7. Método de acordo com a reivindicação 1, caracterizado pelo fato de que:

   a primeira ou segunda lógica do operador compreende lógica do operador recursivo (276);

   a primeira ou segunda função definida pelo usuário compreende uma função recursiva definida pelo usuário; e onde a lógica do operador recursivo invoca a função recursiva definida pelo usuário iniciando sobre os blocos do vetor (604, 608, 610) localmente nos múltiplos nós de processamento (628, 630, 632) para produzir resultados intermediários (650, 652, 654), comunica um subconjunto dos resultados intermediários (650) para um subconjunto dos múltiplos nós de processamento (630), e itera:

   invocar a função do recurso definido pelo usuário nos resultados intermediários (650, 652) para produzir progressivamente menos resultados intermediários (660); e comunicar um subconjunto dos progressivamente menos resultados intermediários para um subconjunto progressivamente menor dos múlPetição 870190077337, de 09/08/2019, pág. 6/13 tiplos nós de processamento (632);

   até um resultado recursivo final (668) ser obtido sobre o primeiro vetor em um nó final no primeiro conjunto de nós.
8. 8. Método de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente:

   receber uma chamada de função recursiva (600); e iniciar a geração de tarefas de operação recursiva (634) localmente entre os múltiplos nós de processamento (628, 630, 632), cada tarefa de operação recursiva operável para seletivamente iniciar a execução da função recursiva definida pelo usuário para os blocos de vetor.
9. 9. Método de acordo com a reivindicação 1, caracterizado pelo fato de que:

   a primeira ou a segunda lógica do operador compreende lógica do operação de convolução (268);

   a primeira ou a segunda função definida pelo usuário compreende uma função de convolução definida pelo usuário (276); e onde a lógica do operador de convolução (268) invoca a função de convolução definida pelo usuário para cada registro (512, 514) em um primeiro vetor (272) em todo registro (274) em um segundo vetor, para obter um resultado da função de convolução.
10. 10. Método de acordo com a reivindicação 9, caracterizado pelo fato de que compreende adicionalmente:

    receber uma chamada da função de convolução (500); e iniciar geração de tarefas de operação de convolução (524) localmente entre os múltiplos nós de processamento (520, 522), cada tarefa de operação de convolução operável para seletivamente iniciar a execução da função de convolução definida pelo usuário.
11. 11. Método de acordo com a reivindicação 1, caracterizado pelo fato de que:

    a primeira ou a segunda lógica do operador compreende distribuir lógica do operador;

    a primeira ou a segunda função definida pelo usuário compreen

    Petição 870190077337, de 09/08/2019, pág. 7/13 de uma função de divisão definida pelo usuário (276); e onde a lógica do operador de distribuição (264) redistribui, de acordo com a função de divisão definida pelo usuário, um primeiro vetor (272) previamente distribuído como blocos do primeiro vetor (308, 310, 312) 5 entre os múltiplos nós de processamento (328, 330, 332), para obter blocos de vetor (338, 340, 342) redistribuídos do primeiro vetor redistribuído entre os múltiplos nós de processamento.
12. 12. Método de acordo com a reivindicação 1, caracterizado pelo fato de que:

    10 a primeira ou a segunda lógica do operador compreende lógica do operador de mapa (292);

    a primeira ou a segunda função definida pelo usuário compreende uma função definida pelo usuário (276); e onde a lógica do operador do mapa aplica a função do mapa 15 definida pelo usuário para registros (1116, 1118, 1120, 1122, 1124, 1126) de um vetor distribuído entre os múltiplos nós de processamento.