BR112016010555B1 - Métodos e sistemas de serviço gerenciado para aquisição, armazenamento e consumo de fluxos de dados em grande escala, e mídias de armazenamento acessíveis por computador não transitório - Google Patents

Abstract

SERVIÇO GERENCIADO PARA AQUISIÇÃO, ARMAZENAMENTO E CONSUMO DE FLUXOS DE DADOS EM GRANDE ESCALA. Um nó de controle de um serviço de gerenciamento de fluxo multilocatário recebe uma solicitação para inicializar um fluxo de dados que deve ser constituído por uma pluralidade de registros de dados. O nó de controle determina, com base em uma política de particionamento, parâmetros que devem ser usados para configurar subsistemas para ingestão, armazenamento e recuperação dos registros. O nó de controle identifica recursos que devem ser usados para um nó do subsistema de recuperação. O nó de recuperação é configurado para implementar interfaces programáticas de recuperação de registro, incluindo interfaces respectivas para implementar padrões de acesso sequenciais e não-sequenciais. O nó de controle configura o nó de recuperação que usa recursos selecionados.

Description

FUNDAMENTOS

[001]À medida que os custos de armazenamento de dados vêm diminuindo ao longo dos anos, e conforme a capacidade para interconectar vários elementos da infraestrutura de computação melhoraram, mais e mais dados referentes a uma grande variedade de aplicações podem ser potencialmente coletados e analisados. Por exemplo, os telefones móveis podem gerar dados que indicam a sua localização, as aplicações a serem usadas pelos usuários de telefones, e assim por diante, pelo menos algumas das quais podem ser recolhidas e analisadas de modo a apresentar cupons personalizados, publicidades e similares aos usuários. A análise dos dados recolhidos por câmeras de vigilância pode ser útil na prevenção e/ou resolução de crimes e os dados recolhidos dos sensores embutidos em diversos locais dentro dos motores de avião, automóveis ou máquinas complexas podem ser usados para diversos fins, tais como manutenção preventiva, melhorando a eficiência e reduzindo custos.

[002]O aumento no volume de dados de streaming foi acompanhado pela (e em alguns casos possível devido a) crescente uso de hardware commodity. O advento das tecnologias de virtualização para hardware commodity forneceu benefícios em relação à gestão dos recursos de computação em grande escala para muitos tipos de aplicações, permitindo que vários recursos de computação sejam eficiente e seguramente compartilhados por vários clientes. Por exemplo, as tecnologias de virtualização podem permitir que uma única máquina de computação física seja compartilhadas entre vários usuários, fornecendo cada usuário com uma ou mais máquinas virtuais hospedadas pela única máquina de computação física, sendo que cada máquina virtual é uma simulação de software agindo como um sistema de computação lógico distinto que fornece aos usuários uma ilusão de que os mesmos são os únicos operadores e administradores de um dado recurso de computação de hardware, enquanto também fornece isolamento e segurança de aplicação entre as várias máquinas virtuais. Além disso, algumas tecnologias de virtualização são capazes de fornecer recursos virtuais que abrangem dois ou mais recursos físicos, tais como uma única máquina virtual com múltiplos processadores virtuais que abrange vários sistemas de computação físicos distintos. Em adição às plataformas de computação, algumas grandes organizações também oferecem vários tipos de serviços de armazenamento construídos usando as tecnologias de virtualização. Usando esses serviços de armazenamento, grandes quantidades de dados podem ser armazenadas com níveis desejados de durabilidade.

[003]Apesar da disponibilidade de recursos de computação e/ou armazenamento virtualizados em um custo relativamente baixo a partir de vários fornecedores, no entanto, o gerenciamento e orquestração da coleta, armazenamento e processamento de grandes fluxos dinamicamente flutuantes de dados permanecem uma proposta desafiadora para uma variedade de razões. À medida que mais recursos são adicionados a um sistema configurado para manusear com grandes fluxos de dados, por exemplo, os desequilíbrios na carga de trabalho entre as diferentes partes do sistema podem surgir. Se não for tratado, tais desequilíbrios podem levar a severos problemas de execução em alguns recursos, em adição o sub- uso (e, portanto, desperdício) de outros recursos. Os clientes também podem estar preocupados com a segurança de seus dados de streaming, ou os resultados de análise de dados de streaming, se tais dados ou resultados forem armazenados em instalações que os clientes não controlam. As falhas que naturalmente tendem a ocorrer com frequência crescente conforme os sistemas distribuídos crescem em tamanho, como a perda ocasional de conectividade e/ou falha de hardware, também pode ter de ser abordado de forma eficaz para evitar interrupções onerosas da coleta de dados de fluxo, armazenamento ou análise.

BREVE DESCRIÇÃO DOS DESENHOS

[004] A FIG. 1 fornece uma vista geral simplificada dos conceitos de fluxo de dados, de acordo com pelo menos algumas modalidades.

[005]A FIG. 2 fornece uma vista geral do fluxo de dados entre os vários subcomponentes de um sistema de gerenciamento de fluxo (SMS) e um sistema de processamento de fluxo (SPS) que compreende uma coleção de etapas de processamento de fluxo, de acordo com pelo menos algumas modalidades.

[006]A FIG. 3 ilustra exemplos dos conjuntos respectivos de interfaces de programação que podem ser implementados em um SMS e um SPS, de acordo com pelo menos algumas modalidades.

[007]A FIG. 4 ilustra uma interface com base em web de exemplo que pode ser implementada para permitir que os clientes de SPS gerarem os gráficos de etapas de processamento de fluxo, de acordo com pelo menos algumas modalidades.

[008]A FIG. 5 ilustra exemplos de interfaces de apresentação de registros programáticos e interfaces de recuperação de registros que podem ser implementadas em um SMS, de acordo com pelo menos algumas modalidades.

[009]A FIG. 6 ilustra exemplos de elementos de um subsistema de ingestão de um SMS, de acordo com pelo menos algumas modalidades.

[010]A FIG. 7 ilustra elementos de exemplo de um subsistema de armazenamento de um SMS de acordo com pelo menos algumas modalidades.

[011]A FIG. 8 ilustra elementos de exemplo de um subsistema de recuperação de um SMS e exemplos de interações do subsistema de recuperação com um SPS, de acordo com pelo menos algumas modalidades.

[012]A FIG. 9 ilustra exemplos de grupos de redundância que podem ser configurados para nós de um SMS ou um SPS, de acordo com pelo menos algumas modalidades.

[013]A FIG. 10 ilustra um ambiente de rede de fornecedor no qual os nós de um dado grupo de redundância podem ser distribuídos entre uma pluralidade de data centers, de acordo com pelo menos algumas modalidades.

[014]A FIG. 11 ilustra uma pluralidade de destinos de posicionamento que podem ser selecionados para os nós de um SMS ou um SPS, de acordo com pelo menos algumas modalidades.

[015]A FIG. 12a e 12b ilustram exemplos de pedidos de opção de segurança que podem ser apresentadas pelos clientes de SPS e clientes de SMS, respectivamente, de acordo com pelo menos algumas modalidades.

[016]A FIG. 13a ilustra exemplo de interações entre um produtor de fluxo de dados e um nó de ingestão de um SMS, de acordo com pelo menos algumas modalidades.

[017]A FIG. 13b ilustra exemplo de elementos de um número de sequência que pode ser gerado por um registro de dados ingeridos em um SMS, de acordo com pelo menos algumas modalidades.

[018]A FIG. 14 ilustra exemplos de armazenamento e recuperação ordenado dos registros de dados de fluxo em um SMS, de acordo com pelo menos algumas modalidades.

[019]A FIG. 15 ilustra um exemplo de mapeamento de partição de fluxo e as decisões de configuração correspondentes que podem ser feitas para os nós de SPS e SMS, de acordo com pelo menos algumas modalidades.

[020]A FIG. 16 ilustra um exemplo de reparticionamento de fluxo dinâmico, de acordo com pelo menos algumas modalidades.

[021]A FIG. 17 é um diagrama de fluxo que ilustra os aspectos das operações que podem ser realizados para suportar conjuntos respectivos de interfaces programáticas para a ingestão de registro de fluxo e recuperação de registro de fluxo, de acordo com pelo menos algumas modalidades.

[022]A FIG. 18a é um diagrama de fluxo que ilustra aspectos de operações que podem ser executadas para configurar os estágios de processamento de fluxo, de acordo com pelo menos algumas modalidades.

[023]A FIG. 18b é um diagrama de fluxo que ilustra aspectos das operações que podem ser executadas em resposta às invocações de componentes de uma biblioteca de cliente para a configuração dos nós de trabalho de processamento de fluxo, de acordo com pelo menos algumas modalidades.

[024]A FIG. 19 é um diagrama de fluxo que ilustra aspectos das operações que podem ser executados para implementar uma ou mais políticas de recuperação para processamento de fluxo, de acordo com pelo menos algumas modalidades.

[025]A FIG. 20 é um diagrama de fluxo que ilustra aspectos de operações que podem ser executados para implementar uma pluralidade de opções de segurança para fluxos de dados, de acordo com pelo menos algumas modalidades.

[026]A FIG. 21 é um diagrama de fluxo que ilustra aspectos de operações que podem ser executados para implementar uma política de particionamento para fluxos de dados, de acordo com pelo menos algumas modalidades.

[027]A FIG. 22 é um diagrama de fluxo que ilustra aspectos das operações que podem ser executadas para implementar reparticionamento dinâmico dos fluxos de dados, de acordo com pelo menos algumas modalidades.

[028]A FIG. 23 é um diagrama de fluxo que ilustra aspectos das operações que podem ser executadas para implementar um uma política de ingestão de registro do tipo pelo-menos-uma-vez para registros de fluxo de dados, de acordo com pelo menos algumas modalidades.

[029]A FIG. 24 é um diagrama de fluxo que ilustra aspectos de operações que podem ser executados para implementar uma pluralidade de políticas de persistência para fluxos de dados, de acordo com pelo menos algumas modalidades.

[030]A FIG. 25 ilustra um exemplo de um sistema de processamento de fluxo, em que os nós de trabalho de um estágio de processamento coordenar as suas cargas de trabalho usando uma tabela de banco de dados, de acordo com pelo menos algumas modalidades.

[031]A FIG. 26 ilustra exemplos de entradas que podem ser armazenadas em uma tabela de atribuição de partição usada para a coordenação da carga de trabalho, de acordo com pelo menos algumas modalidades.

[032]A FIG. 27 ilustra aspectos das operações que podem ser executadas pelos nós de trabalho de um estágio de processamento de fluxo para selecionar as partições nas quais realizar as operações de processamento, de acordo com pelo menos algumas modalidades.

[033]A FIG. 28 ilustra os aspectos das operações que podem ser executadas por nós de trabalho de um estágio de processamento de fluxo para atualizar uma tabela de atribuição de partição com base nas informações obtidas a partir de um subsistema de controle de serviço de gerenciamento de fluxo, de acordo com pelo menos algumas modalidades.

[034]A FIG. 29 ilustra aspectos das operações de balanceamento de carga que podem ser realizadas pelos nós de trabalho de um estágio de processamento de fluxo, de acordo com pelo menos algumas modalidades.

[035]A FIG. 30 é um diagrama de blocos que ilustra um dispositivo de computação de exemplo que pode ser utilizado em, pelo menos, algumas modalidades.

[036]Embora modalidades sejam descritas aqui a título de exemplo para várias modalidades e os desenhos ilustrativos, os versados na técnica reconhecerão que as modalidades não estão limitadas às modalidades descritas ou aos desenhos. Deve ser entendido, que os desenhos e a descrição detalhada dos mesmos não se destinam a limitar as modalidades a formas em particular descritas, mas, pelo contrário, a intenção é cobrir todas as modificações, equivalentes e alternativas caindo dentro do espirito e escopo, conforme definido pelas reivindicações anexas. Os cabeçalhos usados aqui são apenas para fins organizacionais e não se destinam a serem usados para limitar o escopo da descrição ou das reivindicações. Conforme utilizado ao longo deste pedido, a palavra "pode" é usada num sentido permissivo (isto é, o que significa que tem o potencial para), em vez de no sentido obrigatório (isto é, tendo sentido de precisar). Da mesma forma, as palavras "inclui", "incluindo" e "incluir" significam incluindo, mas não se limitando a.

DESCRIÇÃO DETALHADA

[037]Várias modalidades dos métodos e aparelhos para gerenciar a criação, armazenamento, recuperação e processamento de fluxos de dados em grande escala projetados para lidar com centenas ou mesmo milhares de produtores de dados concorrentes e consumidores de dados são descritos. O termo "fluxo de dados", tal como utilizado aqui, refere-se a uma sequência de registros de dados que podem ser gerados por um ou mais produtores de dados e acessados através de um ou mais consumidores de dados, em que cada registro de dados assume-se como sendo uma sequência imutável de bytes. Um serviço de gerenciamento de fluxo (SMS) pode fornecer as interfaces programáticas (por exemplo, as interfaces de programação de aplicações (APIs), páginas da web ou sites da web, interfaces gráficas de usuário ou ferramentas de linha de comando) para permitir a criação, configuração e eliminação de fluxos, assim como a apresentação, armazenamento e recuperação de registros de dados de fluxo em algumas modalidades. Alguns tipos de operações de fluxo (tais como a criação ou exclusão de fluxo, ou os tipos de operações de reparticionamento dinâmico descritas abaixo) que envolvem interações com os componentes de controle de SMS podem ser referidos como operações de "plano de control" aqui, enquanto as operações, tais como apresentação, armazenamento e recuperação de registro de dados que normalmente (por exemplo, em condições normais de operação) não exigem interações com os componentes de controle podem ser referidas aqui como operações de "plano de dados". Os conjuntos dinamicamente provisionados de recursos de computação, armazenamento e rede podem ser utilizados para implementar o serviço em algumas tais modalidades, com base, por exemplo, em várias políticas de particionamento que permitem que a carga de trabalho de gerenciamento de fluxo seja distribuída de uma forma escalável entre numerosos componentes de serviço, tal como descrito abaixo em maior detalhe. O acrônimo SMS pode ser utilizado aqui para se referir a um serviço de gerenciamento de fluxo e também para um sistema de gerenciamento de fluxo que compreende a coleta de recursos virtuais e/ou físicos utilizados para implementar um serviço de gerenciamento de fluxo.

[038]Alguns consumidores do SMS podem desenvolver aplicações que invocam diretamente as interfaces programáticas de SMS em várias modalidades. Em pelo menos algumas modalidades, no entanto, em adição às interfaces SMS, uma estrutura de processamento de nível de aplicativo ou abstração de alto nível pode ser fornecida aos consumidores, o que pode simplificar vários aspectos do processamento de fluxo para aqueles clientes que não desejam desenvolver aplicações usando as funções de gerenciamento de fluxo de nível inferior suportadas diretamente pelo SMS. Essa estrutura pode fornecer suas próprias interfaces programáticas (construídas, por exemplo, no topo das interfaces SMS), permitindo que os consumidores se foquem mais na lógica de negócios a ser implementada usando os registros de fluxo que em operações de gerenciamento de fluxo de nível inferior. A estrutura de nível superior pode ser implementada como um serviço de processamento de fluxo (SPS) com seus próprios componentes de plano de controle e dados de plano em algumas modalidades, o que pode fornecer a funcionalidade avançada tal como provisionamento de recursos automatizado para processamento de fluxo, falhas (failovers) automáticas de nós de processamento, a capacidade de construir os gráficos de fluxo de trabalho de processamento de streaming arbitrária, suporte para fluxos efémeros, reparticionamento dinâmico com base em mudanças de carga de trabalho ou outras condições de desencadeamento e assim por diante. Em pelo menos algumas modalidades, ou o serviço de gerenciamento de fluxo, o serviço de processamento de fluxo, ou ambos os serviços, podem ser implementados como serviços acessíveis pela rede gerenciados por multilocatário em um ambiente de virtualização. Isto é, vários recursos físicos (tais como servidores computadores ou hosts, dispositivos de armazenamento, dispositivos de rede e similares) podem, pelo menos em alguns casos, ser compartilhados entre fluxos de consumidores diferentes em tais modalidades, sem necessariamente fazer os consumidores cientes de exatamente como os recursos estão sendo compartilhados, ou mesmo fazer um consumidor ciente de que um determinado recurso está sendo compartilhado. Os componentes de controle dos serviços de processamento gerenciado e/ou gerenciamento de fluxo gerenciado por multilocatários podem dinamicamente adicionar, remover ou reconfigurar os nós ou recursos sendo usados para um fluxo em particulado com base em várias políticas aplicáveis, algumas das quais podem ser selecionáveis pelo cliente. Além disso, os componentes de controle também podem ser responsáveis pela implementação transparente de vários tipos de protocolos de segurança (por exemplo, para garantir que a aplicação atual de um cliente não possa acessar os dados de outro cliente, mesmo que, pelo menos, algum hardware ou software possa ser compartilhado por ambos os clientes), monitorar o uso de recursos para cobrança, gerar informações de registro que podem ser usadas para auditar ou depuração e assim por diante. A partir do ponto de vista dos clientes do(s) serviço(s) gerenciado(s) por multilocatários, a funcionalidade de controle/administrativa implementada pelo(s) serviço(s) pode eliminar grande parte da complexidade envolvida no suporta das aplicações de fluxo em larga escala. Em alguns cenários, os consumidores desses serviços multilocatários podem ser capazes de indicar que os mesmos não desejam compartilhar recursos para pelo menos alguns tipos de operações relacionadas a fluxo, em cujo caso alguns recursos físicos podem ser designados pelo menos temporariamente como sendo de único-locatário para esses tipos de operações (isto é, limita-se às operações realizadas em nome de um único consumidor ou cliente).

[039]Uma quantidade de diferentes abordagens pode ser tomada para a implementação de operações de plano de controle e plano de dados de SMS e/ou SPS em várias modalidades. Por exemplo, com relação às operações de controle de plano, em algumas implementações um grupo de redundância de servidores de controle ou nós podem ser configurados. O grupo de redundância pode incluir uma pluralidade de servidores de controle, dos quais um servidor é designado como um servidor principal responsável por responder às solicitações administrativas referentes a vários fluxos, enquanto outro servidor pode ser designado para assumir como primário no evento de uma condição de disparo tal como uma falha em (ou perda de conectividade a) corrente primária. Em outra implementação, uma ou mais tabelas criadas em um serviço de banco de dados acessível pela rede pode ser utilizado para armazenar metadados de plano de controle (tais como mapas partição) para vários fluxos, e vários nós de ingestão, armazenamento ou recuperação podem ser capazes de acessar as tabelas conforme necessário para se obter se os subconjuntos de metadados necessários para as operações de plano de dados. Os detalhes com relação aos vários aspectos da funcionalidade de plano e controle e plano de dados do SPS e do SMS em diferentes modalidades são fornecidos abaixo. Observa-se que em algumas modalidades em que um serviço de gerenciamento de fluxo é executado, um serviço de processamento de fluxo que fornece primitivos de nível mais elevado pode não ser necessariamente implementado. Em outras modalidades, somente interfaces programáticas de alto de nível de um serviço de processamento de fluxo podem ser expostas aos clientes e interfaces de gerenciamento de fluxo de baixo nível usadas podem não estar disponibilizadas aos clientes.

[040]De acordo com algumas modalidades, um sistema de gerenciamento de fluxo pode compreender uma pluralidade de subsistemas independentemente configuráveis, incluindo um subsistema ingestão de registro primariamente responsável pela obtenção ou coleta de registros de dados, um subsistema de armazenamento de registros principalmente responsáveis por salvar o conteúdo do registro de dados de acordo com persistência aplicável ou políticas durabilidade e um subsistema de recuperação de registros principalmente responsável por responder os pedidos de leitura direcionados aos registros armazenados. Um subsistema de controle também pode ser implementado em algumas modalidades, que compreendem um ou mais componentes administrativos ou de controle responsáveis por configurar os subsistemas restantes, por exemplo, mediante determinação de forma dinâmica e/ou a inicialização da quantidade necessária de nós para cada um dentre os subsistemas de ingestão, armazenamento e recuperação nos recursos selecionados como servidores virtuais ou físicos. Cada um dos subsistemas de ingestão, armazenamento, recuperação e controle pode ser implementado usando uma pluralidade respectiva de componentes de hardware e/ou software que podem ser coletivamente referidos como "nós" ou "servidores" dos subsistemas. Os vários recursos de um SMS podem ser, dessa forma, logicamente ditos como pertencendo a uma das quatro categorias funcionais: ingestão, armazenamento, recuperação e controle. Em algumas implementações, os conjuntos respectivos de componentes de controle podem ser estabelecidos para cada um dos outros subsistemas, por exemplo, subsistemas de controle de ingestão independentes, subsistemas de controle de armazenamento e/ou subsistemas de controle de recuperação podem ser implementados. Cada um desses subsistema de controle pode ser responsável por identificar os recursos a serem utilizados para os outros nós do subsistema correspondente e/ou para responder às solicitações administrativas dos clientes ou de outros subsistemas. Em algumas implementações, os pools de nós capazes de realizar vários tipos de funções de SPS e/ou SMS podem ser configurados com antecedência e os membros selecionados desses pools podem ser atribuídos a novos fluxos ou novos estágios de processamento conforme necessário.

[041]As políticas de particionamento de fluxo e os mapeamentos associados podem ser implementados, pelo menos em algumas modalidades, por exemplo, para distribuir os subconjuntos dos registros de dados entre diferentes conjuntos de nós de ingestão, armazenamento, recuperação e/ou controle. Por exemplo, com base na política de particionamento selecionada para um fluxo de dados em particular, assim como em outros fatores, tais como as expectativas das taxas de ingestão de registro e/ou taxas de recuperação, um componente de controle pode determinar quantos nós (por exemplo, processos ou threads) devem ser estabelecidos inicialmente (isto é, no momento de criação de fluxo) para ingestão, armazenamento e recuperação e como esses nós devem ser mapeados para as máquinas físicas e/ou virtuais. Ao longo do tempo, a carga de trabalho associada a um dado fluxo pode aumentar ou diminuir, que (entre outras condições de disparo) pode levar ao reparticionamento do fluxo. Tal reparticionamento pode envolver alterações em vários parâmetros, tais como a função a ser usada para determinar a partição do registro, as chaves de particionamento usadas, a quantidade total de partições, a quantidade de nós de ingestão, nós de armazenamento ou nós de recuperação ou a colocação dos nós em diferentes recursos físicos ou virtuais. Em pelo menos algumas modalidades, o reparticionamento pode ser implementado de forma dinâmica sem interromper o fluxo dos registros de dados, usando as técnicas descritas abaixo em mais detalhes. Os diferentes esquemas de particionamento e os critérios de desencadeamento de repartição podem ser usados para diferentes fluxos de dados em algumas modalidades, por exemplo, com base nos parâmetros fornecidos pelo cliente ou nas heurísticas dos nós de controle de SMS. Em algumas modalidades, pode ser possível limitar a quantidade e/ou a frequência das repartições, por exemplo, com base nas preferências de cliente, o tempo de vida esperado de um fluxo ou outros fatores.

[042]Uma quantidade de diferentes políticas e interfaces de ingestão de registro pode ser implementada em diferentes modalidades. Por exemplo, em algumas modalidades, os clientes (por exemplo, os componentes executáveis ou módulos configurados para invocar as interfaces programáticas do SMS em nome dos consumidos do SMS) podem usar tanto ou interfaces de apresentação em linha ou interfaces de apresentação por referência. Para as apresentações em linha, o conteúdo ou o corpo do registro de dados pode ser incluído como parte do pedido de submissão em tais modalidades. Em contraste, em um pedido de envio por referência, um endereço (como um endereço de armazenamento de dispositivo, um endereço de registro de banco de dados ou um URL (UniformrecordLocator)) pode ser fornecido a partir do qual o conteúdo ou o corpo do registro de dados pode ser obtido. Em algumas implementações, uma interface de apresentação híbrida também pode ou em vez disso ser suportado, em que os primeiros N bytes do registro de dados podem ser incluídos na linha, enquanto que os bytes remanescentes (se houver) são fornecidos por referência. Em tal cenário, os registros curtos (cujos corpos são menores que N bytes de comprimento) podem ser inteiramente especificados pelo pedido de apresentação, enquanto as porções dos registros mais longos podem ter de ser obtidas a partir do endereço correspondente.

[043]Além das diferentes alternativas para especificar o conteúdo de registro durante a ingestão, em algumas modalidades uma variedade de políticas de ingestão relacionadas a reconhecimento ou de-duplicação também pode ser implementada. Por exemplo, para algumas aplicações de fluxo, os clientes podem querer garantir que todos e cada registro de dados sejam ingeridos de forma confiável pelo SMS. Em grandes ambientes de gerenciamento de fluxo distribuídos, os pacotes podem ser perdidos ou várias falhas podem ocorrer de tempos em tempos ao longo do percurso entre os produtores de dados e os nós de ingestão, que poderia potencialmente resultar em alguns dados apresentados sendo perdidos. Em algumas modalidades, portanto, um SMS pode implementar uma política de ingestão de pelo-menos-uma- vez, de acordo com o qual um apresentador de registro pode apresentar o mesmo registro uma ou mais vezes até que uma confirmação positiva seja recebida a partir do subsistema de ingestão. Em condições normais de funcionamento, um registro pode ser apresentado uma vez e o apresentador pode receber uma confirmação após o nó de ingestão de recepção ter obtido e armazenado o registro. Se a confirmação for perdida ou atrasada, ou se a solicitação de envio de apresentação de registro for perdida, o apresentador pode apresentar novamente o mesmo registro de dados uma ou mais vezes, até que finalmente uma confirmação seja recebida. O nó de ingestão pode, por exemplo, gerar uma confirmação para cada apresentação, independentemente de se tratar de um duplicado ou não, com base em uma expectativa de que o registro não será reenviado se um reconhecimento já for recebido pelo apresentador. O nó de ingestão pode, contudo, ser responsável pelo menos em algumas modalidades para o reconhecimento de que o mesmo registro de dados foi apresentado várias vezes, e para evitar o armazenamento de novas cópias dos dados duplicados desnecessariamente. Em uma modalidade, pelo menos duas versões de uma política de ingestão de pelo-menos-uma-vez pode ser suportado - um versão (que pode ser denominada "ingestão de pelo-menos-uma-vez, sem-duplicação") em que o SMS é responsável pela de-duplicação dos registros de dados (isto é, assegurar que os dados são armazenados no subsistema de armazenamento de SMS em resposta a somente um de um conjunto de duas ou mais apresentações) e uma versão em que a duplicação de armazenamento de registros de dados pelo SMS é permitida (que pode-se denominar "pelo-menos-uma-vez, duplicação-permitida"). A abordagem de pelo-menos-uma vez, duplicação-permitida pode ser útil para as aplicações de fluxo em que existem poucas ou nenhumas consequências negativas da duplicação de registro de dados e/ou para as aplicações de fluxo que realizam a sua própria eliminação de duplicata. Outras políticas de ingestão também podem ser suportadas, como uma política de ingestão de melhor esforço em que os reconhecimentos não são necessários para cada registro de dados apresentado. A perda de alguns registros de dados pode ser aceitável se uma política de ingestão de melhor esforço estiver em vigor em pelo menos algumas modalidades. Os clientes podem selecionar quais políticas de ingestão desejam usar para várias correntes em várias modalidades.

[044]Com relação ao armazenamento dos registros de fluxo, uma quantidade de políticas alternativas também pode ser suportada em, pelo menos, algumas modalidades. Por exemplo, um cliente pode ser capaz de escolher uma política de persistência dentre vários suportadas pelo SMS, que rege tais aspectos de armazenamento de registros como a quantidade de cópias de um dado registro de dados que devem ser armazenados, o tipo de tecnologia de armazenamento (por exemplo, a RAM volátil ou não-volátil, armazenamento baseado em disco rotativo, dispositivos de estado sólido (SSD), dispositivos de armazenamento ligado à rede e similares) a ser utilizado para as cópias e assim por diante. Por exemplo, se um cliente seleciona uma política de persistência de N réplica para o armazenamento com base em disco, uma submissão de registro de dados não pode ser considerada completa até N cópias do registro serem escritas com segurança para os N dispositivos de disco respectivos. Em pelo menos algumas modalidades em que os dispositivos de armazenamento com base em disco são usados, o subsistema de armazenamento de SMS pode tentar gravar os registros de dados de entrada de uma dada partição sequencialmente ao disco, por exemplo, para evitar o impacto de execução de buscas em disco. Os números de sequência podem ser gerados para (e armazenados com) os registros de dados usando várias técnicas, como descrito abaixo, incluindo, por exemplo, técnicas baseadas em carimbo temporal que permitem recuperação de registro em ordem com base nos momentos de ingestão. Os registros de dados de uma dada partição podem ser armazenados em conjunto, por exemplo, de forma contígua no disco e, separadamente, a partir dos registros de dados de outras partições em pelo menos algumas modalidades. Em algumas implementações, de acordo com uma política de retenção (selecionada por um cliente ou pelo SMS) ou uma política de janela de tempo de de-duplicação (que indica o período de tempo, subsequente a uma apresentação de qualquer determinado registro de dados, durante qual o SMS pode ser necessário para garantir que nenhumas duplicatas daquele determinado registro de dados sejam armazenadas no subsistema de armazenamento de SMS, mesmo que algumas duplicatas sejam enviadas), pelo menos alguns registros de dados podem ser arquivados em tipos diferentes de serviço de armazenamento e/ou apagados após um período de tempo do SMS. Tais operações de remoção podem ser referidas aqui como "corte" de fluxo. Os clientes podem apresentar solicitações de corte de fluxo ao corte em algumas modalidades, por exemplo, notificar o SMS que os registros de dados especificados já não são necessários e podem, portanto, ser eliminados a partir da perspectiva do cliente que apresenta o pedido de corte ou explicitamente solicitando a exclusão de registros de dados especificados. Em cenários nos quais pode haver vários clientes que consomem os registros de dados de um determinado fluxo, o SMS pode ser responsável por garantir que um determinado registro não seja excluído ou cortado prematuramente, antes que o mesmo seja acessado por todos os consumidores interessados. Em algumas implementações, se houver N consumidores de dados de um determinado fluxo, antes de excluir um determinado registro R do fluxo, o SMS pode esperar até que tenha determinado que todos os consumidores de dados N leram ou processaram R. O SMS pode determinar que R foi lido por todos os consumidores com base nos pedidos de corte respectivos dos consumidores, por exemplo, ou com base nas respectivas indicações de quão longe dentro do fluxo de dados os consumidores progrediram. Em algumas modalidades, alguns tipos de consumidores de dados (tais como aplicações relacionadas aos testes) podem aceitar a eliminação de pelo menos um pequeno subconjunto de registros de dados, antes de serem acessados. Por conseguinte, os pedidos podem ser capazes de notificar o SMS quanto à aceitabilidade de eliminação de dados antes da recuperação em, pelo menos, algumas modalidades e o SMS pode agendar exclusões de acordo com as notificações. Em algumas modalidades, uma política de arquivo pode ser implementada, por exemplo, como parte da política de retenção de dados, indicando, por exemplo, os tipos de dispositivos de armazenamento para o qual os registros de dados de fluxo devem ser copiados e as políticas de agendamento a serem utilizadas para tais cópias.

[045]Em pelo menos algumas modalidades, uma pluralidade de interfaces de programação também pode ser suportada para recuperação de registro. Em uma modalidade, pode ser utilizado uma abordagem baseada no iterador, em que uma interface de programação (por exemplo, getIterador) pode ser usada para instanciar e posicionar uma iterador ou cursor em um deslocamento especificado lógico (por exemplo, com base no número de sequência ou carimbo temporal) dentro uma partição de um fluxo. Uma interface programática diferente (tal como getNextRecords) pode, então, ser usada para ler um determinado número de registros de dados sequencialmente a partir da posição atual do iterador. A instanciação de um iterador pode, em efeito, permitir que um cliente especifique uma posição de partida arbitrária ou aleatória para recuperação de registros dentro da partição de fluxo. Se um cliente desejar ler os registros de dados em um padrão de acesso aleatório em tal modalidade, o cliente poderá ter de criar repetidamente novos iteradores. Em sistemas de armazenamento com base em disco rotativo, as buscas em disco necessárias para acessos aleatórios frequentes podem impactar os tempos de resposta de I/O significativamente. Assim, como um incentivo para os clientes lerem os registros de dados de fluxo em sequência em vez de aleatoriamente, diferentes (por exemplo, mais elevadas) taxas de cobrança podem ser aplicadas a acessos de leitura aleatória que são aplicados aos acessos de leitura sequencial em pelo menos algumas modalidades. Assim, por exemplo, um cliente pode ser cobrado X unidades monetárias por chamada de getIterator e Y unidades monetárias por registro recuperador via getNextRecords, com X > Y em algumas implementações. Quando interfaces de cliente alternativas são suportadas para outras categorias operação (como a ingestão), em pelo menos algumas modalidades as taxas de cobrança ou preços para as alternativas também podem ser diferentes - por exemplo, um cliente pode ser cobrado a mais por um pedido de apresentação por referência do que por um pedido de apresentação online, assim como um cliente pode ser cobrado a mais por leituras aleatórias do que para leituras sequenciais. Outros fatores também podem influenciar a cobrança em várias modalidades, tais como os tamanhos dos registros de dados, a distribuição de solicitações de gravação versus leitura ao longo do tempo, as políticas de persistência selecionadas e assim por diante.

[046]De acordo com algumas modalidades, um serviço de processamento de fluxo (SPS) pode permitir que os clientes especifiquem fluxos de trabalho de processamento arbitrariamente complexos que compreendem vários estágios de processamento, em que a saída do processamento executado em um determinado estágio pode ser utilizada como entrada para zero ou mais outras fases. As políticas de particionamento (similares às descritas para o SMS para ingerir, armazenar e recuperar os registros de dados) podem ser usadas para dividir a carga de trabalho de processamento entre uma pluralidade de nós de trabalho em várias fases em algumas modalidades. Em tal modalidade, as interfaces de SPS programáticas podem ser implementadas que permitem que os clientes especifiquem as várias definições de configuração para qualquer um determinado estágio, incluindo, por exemplo, a(s) fonte(s) de dados de entrada para o estágio (por exemplo, um ou mais fluxos a partir do qual os registros de dados devem ser recuperados, juntamente com as políticas de processamento para os fluxos), as operações de processamento a serem realizadas no estágio e um descritor ou especificação para a saída ou distribuição de resultado a partir do estágio (por exemplo, caso a saída deva ser salva aos locais de armazenamento, enviada para um ponto de extremidade da rede ou alimentada em um ou mais outros estágios de processamento na forma de um fluxo diferente). Em pelo menos algumas modalidades, as operações de processamento especificadas para um estágio de SPS podem ser idempotentes: isto é, se uma determinada operação de tratamento é realizada várias vezes com os mesmos dados de entrada, o resultado da operação não difere do resultado que seria obtido caso a operação fosse realizada apenas uma vez. As recuperações de falhas (por exemplo, uma falha de nodo de trabalho em um estágio de SPS) podem ser simplificadas se as operações de processamento forem idempotentes, conforme descrito abaixo em mais detalhe. De acordo com algumas modalidades, as operações de processamento não- idempotentes podem ser permitidas em alguns ou todos os estágios de SPS.

[047]Com base, pelo menos em parte, nas informações de configuração, tal como as políticas de particionamento de fluxo de entrada e, então, a natureza das operações de processamento recebidas através das interfaces de programação de SPS, em várias modalidades os servidores de controle de SPS podem determinar quantos nós de trabalho devem ser configurados inicialmente para os vários estágios de um fluxo de trabalho de processamento. As capacidades de execução dos recursos a serem utilizados para os nós de trabalho (por exemplo, as máquinas virtuais ou físicas a serem utilizadas) também podem serem levados em conta quando se determina o número inicial e colocação dos nós de trabalho. O número selecionado de nós de trabalho (que pode, em algumas implementações, cada um, compreender um thread executável ou um processo executável) pode ser instanciado. Cada nó de trabalho pode ser configurado, por exemplo, para obter os registros de dados das fontes de entrada apropriados (por exemplo, dos nós de recuperação de uma ou mais partições de fluxo), executar as operações de processamento especificadas nos registros de dados e transmitir os resultados do processamento ao(s) destino(s) de saída especificado(s).Além disso, em pelo menos algumas modalidades, um esquema de ponto de verificação pode ser implementado, de acordo com o qual um determinado nó de trabalho pode ser configurado para armazenar os registros de progresso ou indicativo de pontos de verificação da porção de uma partição que foi processada nesse nó de trabalho, pressupondo-se que os registros de partição estão sendo processados sequencialmente. O nó de trabalho pode, por exemplo, escrever um registro de progresso para armazenamento persistente periodicamente em algumas implementações (por exemplo, uma vez a cada N segundo ou uma vez a cada R registos de dados serem processados) e/ou em resposta a pedidos de ponto de verificação a partir de um servidor de controle de SPS.

[048]Os registros de progresso podem ser utilizados para recuperação rápida das falhas de nó de trabalho em algumas modalidades. Por exemplo, um servidor de controle de SPS pode monitorar o estado de saúde dos vários nós de trabalho ao longo do tempo, por exemplo, usando um mecanismo de batimentos cardíacos e/ou monitoramento dos níveis de uso de recursos (tal como o uso de CPU, uso do dispositivo I/O ou os níveis de uso). Em resposta a uma determinação pelo servidor de controle de SPS que um nó de trabalho específico está em um estado indesejado ou insalubre (por exemplo, se está não responsivo ou sobrecarregado), um nó de trabalho substituto pode ser instanciado para tomar as responsabilidades do nó de trabalho em particular. O nó de trabalho substituto pode acessar o registro de progresso mais recente armazenado pelo nó de trabalho substituído para identificar o conjunto de registros de dados que o nó de trabalho substituto deve processar. Nas modalidades em que as operações de processamento são idempotentes, mesmo que algumas operações sejam repetidas (por exemplo, devido ao fato de que o registro de progresso mais recente foi escrito algum momento antes da instanciação de trabalho substituto), os resultados gerais do tratamento não serão afetados pela falha e substituição. Em algumas implementações, além de armazenar os registos de progresso que indicam o subconjunto de um determinado fluxo ou partição que foi processado pelos mesmos, um nó de trabalho também pode ser configurado para armazenar as informações de estado de aplicação acumuladas. Por exemplo, se um fluxo de trabalho de processamento de fluxo for responsável por determinar os valores de cobrança do cliente para um serviço específico com base na análise dos registros de dados de fluxo que indicam métricas de uso de serviço, um nó de trabalho pode, periodicamente, armazenar os valores de cobrança acumulados determinados para diversos clientes.

[049]Em pelo menos algumas modalidades, os servidores de controle de SPS também podem ser configurados para responder a vários outros acionadores, tais como, alterar os níveis de carga de trabalho ou desequilíbrios de carga de trabalho detectados (por exemplo, se as taxas de ingestão para uma partição se tornar desproporcionadamente mais elevadas do que outras) iniciando-se outras ações, tal como solicitar o reparticionamento dinâmica dos fluxos de entrada para vários estágios, mudar o número de nós de trabalho atribuídos a uma determinada partição em um determinado estágio, atribuir os nós de trabalho de alta execução a alguns estágios ou transferir os nós de trabalho de um recurso físico para outro recurso físico com uma capacidade de execução diferente. Em algumas modalidades, por exemplo, em resposta a uma determinação por um servidor de controle de SPS que a política de recuperação de melhor esforço deve ser aplicada a um determinado estágio em vez de uma política de recuperação baseada no ponto de verificação, os registros de progresso do tipo descrito acima podem não estar armazenados pelos nós de trabalho de, pelo menos, algumas etapas de SPS. Em algumas implementações de tal política de recuperação de melhor esforço, um nó de trabalho substituto pode simplesmente processar os novos registros de dados à medida que são recebidos, sem a necessidade de acesso aos registros progredir. Em algumas modalidades, se um cliente quiser implementar uma política de recuperação de melhor esforço em um estágio de SPS, as operações de processamento de fluxo realizadas no estágio não precisam necessariamente ser idempotentes. Em algumas modalidades em que as operações de processamento não-idempotente devem ser realizadas em registros de fluxo em um estágio de SPS, a recuperação com base no ponto de verificação não pode ser suportada e um esquema de recuperação diferente tal como a recuperação de melhor esforço pode ser usada. Em pelo menos uma modalidade, somente as operações de processamento de fluxo idempotente podem ser permitidas nos estágios de SPS.

[050]Os registros de dados de alguns fluxos podem conter informações sensíveis ou confidenciais, ou as operações de processamento realizadas nos estágios de SPS podem incluir o uso de algoritmos proprietários cuja descoberta pelos concorrentes pode ser problemática. Os clientes podem, assim, estar preocupados com a segurança de diversas categorias de operações de gerenciamento e processamento de fluxo, especialmente se as operações forem realizadas usando recursos localizados em centros de dados de rede de fornecedor que não são totalmente controladas pelos próprios clientes. As redes criadas por uma entidade como uma empresa ou uma organização do setor público para fornecer um ou mais serviços de rede de acesso (tais como vários tipos de banco de dados, serviços de computação ou armazenamento baseado em nuvem) acessíveis através da Internet e/outras redes para um conjunto distribuído dos clientes pode ser chamado de redes de fornecedores aqui. Em algumas modalidades, os clientes podem ser capazes de escolher dentre uma pluralidade de opções relacionadas à segurança para os seus fluxos de dados. Conforme descrito acima, uma configuração de SPS e de SMS combinada pode compreender nós que pertencem a um número de categorias funcionais diferentes, tais como os nós de controle para o SMS e/ou o SPS, os nós de ingestão de SMS, nós de armazenamento de SMS, nós de recuperação de SMS e nós de trabalho ou de processamento de SPS. As opções relacionadas à segurança disponibilizadas aos clientes podem incluir as opções para a colocação ou localização de vários tipos de nós em algumas modalidades. Por exemplo, em uma modalidade, um cliente pode ser capaz de pedir que os nós de trabalho de SPS para um ou mais estágios de processamento de um fluxo de trabalho de fluxo seja implementado em dispositivos de computação localizados em instalações de propriedade do cliente, mesmo que os registos de fluxo sejam inicialmente recolhidos e/ou armazenados usando os recursos localizados em uma rede de fornecedor. Em resposta a esses pedidos de colocação, os nós de diferentes categorias funcionais para um determinado fluxo podem ser instanciados em conjuntos respectivos de recursos com diferentes características ou perfis de segurança.

[051]Os conjuntos de recursos podem diferir uns dos outros em várias características relacionadas à segurança em diferentes modalidades, incluindo, por exemplo, a localização física, protocolos de segurança físicos sendo utilizados (por exemplo, que tenha acesso físico aos recursos), os níveis de isolamento de rede (por exemplo, a extensão em quais os endereços de rede dos recursos são visíveis a várias entidades), multi-aluguel contra único-aluguel e assim por diante. Em algumas modalidades, os clientes podem ser capazes de estabelecer redes virtuais isoladas (IVNs) dentro de uma rede de fornecedor, com um dado cliente que sendo dado controle substancial sobre as configurações de redes de vários dispositivos incluídos dentro da IVN do cliente. Em particular, os clientes podem ser capazes de restringir o acesso aos endereços de rede (por exemplo, Protocolo de Internet (IP) ou endereços de IP) atribuídos a vários servidores ou instâncias de computação diferentes dentro de suas IVNs. Em tais modalidades, os clientes podem solicitar que certos subconjuntos de seus nós de SMS ou de SPS sejam instanciados dentro dos IVNs especificados. Nas modalidades em que os recursos de rede de fornecedor, tal como os hosts de instância de virtualização (que podem tipicamente ser configurados como hosts de multilocatários) estão sendo usados para várias categorias de nós de SPS ou SMS, um cliente pode solicitar que um conjunto de nós seja instanciado nos hosts de instância que estão restritos a instâncias de implementação pertencentes a somente aquele cliente (isto é, alguns nós de SPS ou SMS podem ser implementados em hosts de instância configurados como hosts de único-locatário).

[052]Em algumas modalidades, como outra opção relacionada à segurança, os clientes podem solicitar que os registros de dados de um fluxo particular sejam criptografados antes de serem transmitidos através de um enlace de rede - por exemplo, antes de ser ingerido no SMS, entre os subsistemas de ingestão e armazenamento, entre os subsistemas de armazenamento e recuperação, entre os subsistemas de recuperação e os nós de trabalho de SPS e/ou entre os nós de trabalho e os destinos de saída de SPS. Os clientes podem especificar os algoritmos de criptografia a serem usados em algumas modalidades. Em uma modalidade, os protocolos de redes seguras, como os protocolos TLS (TransportLayer Security) ou SSL (secure sockets layer) podem ser usados para as transmissões de registro de dados e/ou para transmitir os resultados de processamento de SPS.

Conceitos de fluxo de dados e visão geral

[053]A FIG. 1 fornece uma vista geral simplificada dos conceitos de fluxo de dados, de acordo com pelo menos algumas modalidades. Como mostrado, um fluxo 100 pode compreender uma pluralidade de registos de dados (DRs) 110, tais como os DRs 110A, 110B, 110C, 110D e 110E. Um ou mais produtores de dados 120 (que também podem ser referidos como fontes de dados), tais como produtores de dados 120A e 120B, podem executar as operações de gravação 151 para gerar o conteúdo de registros de dados de fluxo 100. Um número de tipos diferentes dos produtores de dados pode gerar fluxos de dados em diferentes modalidades, como, por exemplo, aplicações de celular ou tablet, redes de sensores, plataformas de mídia social, aplicações de log ou componentes de log de sistema, agentes de monitoramento de vários tipos e assim por diante. Um ou mais consumidores de dados 130 (tal como os consumidores de dados 130A e 130B) podem executar as operações de leitura 152 para acessar o conteúdo dos registros de dados gerados pelos produtores de dados 120. Os consumidores de dados 130 podem compreender, por exemplo, nós de trabalho de um estágio de processamento de fluxo em algumas modalidades.

[054]Em pelo menos algumas modalidades, um determinado registo de dados 110 como armazenado em um SMS pode compreender uma porção de dados 101 (por exemplo, as porções de dados 101A, 101B, 101C, 101D e 101E de DRs 110A, 110B, 110C, 110D e 110E respectivamente) e um número de sequência SN 102 (por exemplo, SNs 102A, 102B, 102C, 102D e 102E de DRs 110A, 110B, 110C, 110D e 110E respectivamente).O número de sequência 102 pode ser um indicativo da ordem em que os DRs são recebidos em um sistema de gerenciamento de fluxo (ou a um nó em particular de um sistema de gerenciamento de corrente) na modalidade representada. As porções de dados 101 podem compreender uma sequência de bytes não-interpretadas imutáveis em algumas implementações: isto é, uma vez que uma operação de gravação 152 está concluída, o conteúdo de DR gerado como um resultado da gravação não pode ser alterado pelo SMS, e em geral, o SMS não pode estar ciente da semântica dos dados.Em algumas implementações, os registos de dados diferentes de um determinado fluxo 100 podem compreender diferentes quantidades de dados, enquanto que em outras implementações, todos os registos de dados de um determinado fluxo podem ser do mesmo tamanho. Em pelo menos algumas implementações, os nós do SMS (por exemplo, nós de subsistema de ingestão e/ou nós de subsistema de armazenamento) podem ser responsáveis pela geração de SNs 102. Como descrito abaixo em maior detalhe, os números de sequência dos registos de dados não necessitam ser sempre consecutivos. Em uma implementação, clientes ou dados produtores 120 pode fornecer, como parte de uma solicitação de gravação, a indicação de um número de sequência mínimo a ser utilizado para o registro de dados correspondente. Em algumas modalidades, os produtores de dados 120 podem apresentar os pedidos de gravação que contêm ponteiros para (ou endereços de) as porções de dados dos registros de dados, por exemplo, fornecendo o endereço de um dispositivo de armazenamento (como um nome de dispositivo e um deslocamento dentro do dispositivo) ou um endereço de rede (tal como um URL) a partir do qual pode ser obtido a porção de dados.

[055]O serviço de gerenciamento de fluxo pode ser responsável por receber os dados dos produtores de dados 120, armazenar os dados e permitir que os consumidores de dados 130 acessem os dados em um ou mais padrões de acesso em várias modalidades. Em pelo menos algumas modalidades, a corrente 100 pode ser particionada ou "fragmentado" para distribuir a carga de trabalho de receber, armazenar e recuperar os registos de dados. Em tais modalidades, uma partição ou um fragmento pode ser selecionado para um registo de dados de entrada 110 com base em um ou mais atributos do registo de dados e os nós específicos que são para ingerir, armazenar ou recuperar o registo de dados podem ser identificados com base na partição. Em algumas implementações, os produtores de dados 120 podem fornecer chaves de particionamento explícitas com cada operação de gravação que pode servir como atributos de particionamento, e essas chaves podem ser mapeadas para particionar identificadores. Em outras implementações, o SMS pode inferir a identificação de partição com base em fatores tais como a identidade do produtor de dados 120, os endereços de IP dos produtores de dados ou mesmo com base no conteúdo dos dados apresentados. Em algumas implementações, em que os fluxos de dados são particionados, os números de sequência podem ser atribuídos a uma base por partição - por exemplo, embora os números de sequência possam indicar a ordem na qual os registos de dados de uma partição específica são recebidos, os números de sequência dos registos de dados DR1 e DR2 em duas partições diferentes podem não indicam, necessariamente, a ordem relativa em que DR1 e DR2 foram recebidos. Em outras implementações, os números de sequência podem ser atribuídos em uma largura de fluxo em vez de uma base por partição, de modo que se o número de sequência SN1 atribuído a um registro de dados DR1 for inferior ao número de sequência SN2 atribuído ao registro de dados DR2, isso implicaria que DR1 foi recebido mais cedo do que DR2 pelo SMS, independentemente das partições às quais DR1 e DR2 pertencem.

[056]As interfaces de recuperação ou leitura suportadas por um SMS podem permitir que os consumidores de dados 130 acessem os registros de dados sequencialmente e/ou em ordem aleatória em várias modalidades. Em uma modalidade, um conjunto com base no iterador das interfaces de programação de aplicativos de leitura (APIs) pode ser suportado. Um consumidor de dados 130 pode apresentar um pedido para obter um iterador para um fluxo de dados, com a posição inicial do iterador indicado por um número de sequência especificado e/ou um identificador de partição. Após o iniciador ser instanciado, o consumidor de dados pode apresentar os pedidos para ler os registros de dados em ordem sequencial começando daquela posição inicial dentro do fluxo ou da partição. Se um consumidor de dados desejar ler os dados de registos em uma ordem aleatória, um novo iterador pode ter de ser instanciado para cada leitura em tais modalidades. Em pelo menos algumas implementações, os registros de dados de uma determinada partição ou fluxo podem ser gravados ao armazenamento baseado em disco em ordem de número de sequência, geralmente usando as operações de gravação sequenciais que evitam buscas de disco. As operações de leitura sequencial também podem evitar a sobrecarga de buscas de disco. Assim, em algumas modalidades, os consumidores de dados podem ser encorajados a realizar mais leituras sequenciais que as leituras aleatórias usando incentivos de preços: por exemplo, as operações de leitura de acesso aleatório, tais como instâncias de iterador podem ter taxas de cobrança associadas mais elevadas que operações de leitura de acesso de sequencial. Ambiente do sistema de exemplo

[057]A FIG. 2 fornece uma vista geral do fluxo de dados entre os vários sub- componentes de um sistema de gerenciamento de fluxo (SMS) e um sistema de processamento de fluxo (SPS) que compreende uma coleção de etapas de processamento de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado, o SMS 280 pode compreender um subsistema de ingestão 204, um subsistema de armazenamento 206, um subsistema de recuperação 208 e um subsistema de controle de SMS 210. Cada um dos subsistemas de SMS pode incluir um ou mais nós ou componentes, implementados, por exemplo, usando os threads ou processos executáveis respectivos instanciados em vários recursos de uma rede de fornecedor (ou uma instalação de propriedade de cliente ou de terceiros) como descrito abaixo. Os nós do subsistema de ingestão 204 podem ser configurados (por exemplo, pelos nós do subsistema de controle de SMS 210) para obter os registros de dados de um fluxo de dados em particular dos produtores de dados 120 (tais como 120A, 120B e 120C) com base em uma política de particionamento em uso para o fluxo e cada nó de ingestão pode passar os registros de dados recebidos para os nós correspondentes do subsistema de armazenamento 206. Os nós de subsistema de armazenamento podem salvar os registros de dados em qualquer um dos vários tipos de dispositivos de armazenamento de acordo com uma política de persistência selecionada para o fluxo. Os nós de subsistema de recuperação 208 podem responder a solicitações de leitura por parte dos consumidores de dados, tais como os nós de trabalho de SPS 290. Os estágios de processamento de fluxo 215, tais como estágios 215A, 215B, 1215C e 215D do SPS 290 podem ser estabelecidos com a ajuda do subsistema de controle de SPS 220. Cada etapa 215 pode incluir um ou mais nós de trabalho configurados pelo subsistema de controle de SPS 220 para executar um conjunto das operações de processamento nos registros de dados recebidos. Como mostrado, algumas etapas 215 (tais como 215A e 215B) podem obter registros de dados diretamente a partir do SMS 280, enquanto outros (como 215C e 215D) podem receber suas entradas a partir de outras etapas. Os múltiplos estágios de SPS 215 podem operar em paralelo em algumas modalidades, por exemplo, diferentes operações de processamento podem ser executadas simultaneamente em registos de dados obtidos a partir do mesmo fluxo nos estágios 215A e 215B. Observa-se que os respectivos subsistemas e estágios de processamento similares aqueles ilustrados na FIG. 2 para um fluxo em particular pode ser instanciado para outros fluxos também.

[058]Em pelo menos algumas modalidades, pelo menos alguns dos nós dos subsistemas e estágios de processamento mostrado na FIG. 2 podem ser implementados usando os recursos de rede de fornecedor. Como observado anteriormente, as redes configuradas por uma entidade como uma empresa ou uma organização do setor público para fornecer um ou mais serviços de rede de acesso (tais como vários tipos de serviços baseados em nuvem de banco de dados, computação ou armazenamento) acessíveis através da Internet e/ou a outras redes a um conjunto distribuído dos clientes pode ser chamado de redes de fornecedor aqui. Alguns dos serviços podem ser usados para construir os serviços de nível superior: por exemplo, serviços de computação, armazenamento ou banco de dados podem ser usados como blocos de construção para um serviço de gerenciamento de fluxo ou um serviço de processamento de fluxo. Pelo menos alguns dos serviços principais de uma rede de fornecedor pode ser empacotada para uso do cliente em unidades de serviço chamado "instâncias": por exemplo, uma máquina virtual instanciada por um serviço de computação virtualizado pode representar uma "instância de computação", e um dispositivo de armazenamento tal como um volume em nível de bloco instanciado por um serviço de armazenamento pode ser referido como uma "instância de armazenamento", ou um servidor de gerenciamento de banco de dados pode ser referido como uma "instância de banco de dados". Os dispositivos de computação, tais como servidores em que tais unidades de vários serviços acessíveis a rede de uma rede de fornecedor são implementados podem ser referidos como "hosts de instância" ou mais simplesmente como "hosts" no presente documento. Os nós do subsistema ingestão 204, o subsistema de armazenamento 206, o subsistema de recuperação 208, o sistema de controle de SMS 210, os estágios de processamento 215 e/ou o subsistema de controle de SPS 220 pode compreender threads ou processos que executam em várias instâncias de computação em uma pluralidade de hosts de instância em algumas modalidades. Um determinado host de instância pode incluir várias instâncias de computação, e a coleção das instâncias de computação em um determinado host de instância pode ser utilizada para implementar os nós de vários fluxos diferentes de um ou mais clientes. Os exemplos de armazenamento podem ser utilizados para armazenar os registos de dados de vários fluxos em algumas modalidades, ou conforme os destinos dos resultados dos estágios de processamento de fluxo.Com o tempo, os nós de subsistema de controle podem modificar as populações de outros subsistemas de forma dinâmica em resposta a várias condições de disparo, por exemplo, por adição ou remoção dos nós, alteração dos mapeamentos dos nós para processos ou calcular instâncias ou hosts de instância, ou repartição de um determinado fluxo enquanto ainda continua a receber, armazenar e processar os registos de dados conforme descrito abaixo com referência à FIG. 15 e FIG. 16.

[059]No contexto das modalidades em que os recursos de rede de fornecedor são usados para as operações relacionadas ao fluxo, o termo "cliente", quando usado como a fonte ou o destino de uma determinada comunicação, pode referir-se a qualquer um dos dispositivos de computação, processos, módulos de hardware ou módulos de software que são de propriedade, geridos por, ou atribuídos ao, uma entidade (como uma organização, um grupo com vários usuários ou um único usuário) que é capaz de acessar e usar pelo menos um serviço acessível por rede de uma rede de fornecedor. Os clientes de um serviço em si podem ser implementados usando recursos de outro serviço - por exemplo, um consumidor de dados de fluxo (um cliente de um serviço de gerenciamento de fluxo) pode compreender uma instância de computação (um recurso fornecido por um serviço de computação virtualizada).

[060]Uma determinada rede de fornecedor pode incluir numerosos centros de dados (que podem ser distribuídos em diferentes regiões geográficas) que hospeda vários pools de recursos, tais como coleções de servidores de computadores físicos e/ou virtualizados, servidores de armazenamento com um ou mais dispositivos de armazenamento cada, equipamentos de rede e similares, necessários para implementar, configurar e distribuir a infraestrutura e serviços oferecidos pelo fornecedor. Uma quantidade de diferentes componentes de hardware e/ou software, alguns dos quais podem ser instanciados ou executados em diferentes datacenters ou em diferentes regiões geográficas, podem coletivamente ser usados para implementar cada um dos serviços em várias modalidades. Os clientes podem interagir com os recursos e os serviços na rede de fornecedor dos dispositivos localizados em locais de propriedade do cliente ou gerenciados pelo cliente ou datacenters à rede de fornecedor e/ou dos dispositivos dentro da rede de fornecedor. Observa-se que, apesar das redes de fornecedores servirem como um contexto de exemplo no qual muitas das técnicas de gerenciamento e processamento de fluxo descritas aqui podem ser implementadas, essas técnicas também podem ser aplicadas a outros tipos de sistemas distribuídos que redes de fornecedores, por exemplo, para ambientes distribuídos em grande escala operados por uma entidade empresarial única para as suas próprias aplicações.

Exemplos de interface de programação

[061]Tal como indicado acima, em algumas modalidades pelo menos um SPS pode usar as interfaces programáticas de SMS para construir a funcionalidade de nível mais alto que pode ser mais facilmente utilizada pelos clientes de SPS para implementar a lógica comercial desejada para várias aplicações baseadas em fluxo. Ao considerar as diferenças entre a SPS e SMS, uma analogia pode ser útil: as funções de SPS podem, em geral, ser comparadas a construtos de linguagem de programação em linguagens de alto nível, como C++, enquanto as funções de SMS podem, em geral, ser comparadas às instruções em linguagem assembly para qual os construtos de linguagem de programação são traduzidos por um compilador. Pode ser possível implementar as mesmas operações usando as instruções em linguagem assembly diretamente, mas a programação na linguagem de alto nível pode ser tipicamente mais fácil para muitas categorias de clientes ou usuários. Da mesma forma, pode ser possível implementar várias aplicações usando as primitivas fornecidas por um SMS, mas pode ser mais fácil fazê-lo usando os recursos de SPS. As operações de processamento de SPS (tais como as operações de processamento idempotente realizadas em registros de dados) podem ser aplicadas no conteúdo de dados dos registos de fluxo, enquanto as operações de SMS forem realizadas para adquirir, armazenar e recuperar os próprios registros, geralmente sem considerar os conteúdos dos registros. A FIG. 3 ilustra exemplos dos conjuntos respectivos de interfaces de programação que podem ser implementados em um SMS e um SPS, de acordo com pelo menos algumas modalidades. Uma quantidade de diferentes interfaces de programação de aplicativos (APIs) são indicadas para ambos o SMS e o SPS a título de exemplo. As APIs ilustradas não se destinam a serem listas exaustivas daquelas suportadas em qualquer determinada implementação e algumas das APIs ilustradas podem não ser suportadas em uma determinada implementação.

[062]Como indicado pela seta 350, os clientes de SPS 375 podem invocar as interfaces programáticas de SPS 305 para configurar os estágios de processamento. Os vários tipos de interfaces programáticas de SPS 305 podem ser implementados em diferentes modalidades. Por exemplo, uma API createStreamProcessingStage pode permitir que os clientes solicitem a configuração de um novo estágio de processamento 215 para um fluxo de entrada especificado, de tal modo que os nós de trabalho do estagio sejam, cada um, configurados para realizar um conjunto de operações idempotentes especificados na invocação de interface e distribuir os resultados para os destinos indicados por um descritor de distribuição de saída ou política. Em algumas versões do API createStreamProcessingStage ou o seu equivalente, um cliente pode solicitar a criação do fluxo de entrada também, enquanto em outras versões, um fluxo de entrada pode ter de ser criado antes do estágio de processamento ser criado. Uma política de recuperação pode ser especificada para os nós de trabalho, indicando, por exemplo, se uma técnica de recuperação baseada em ponto de verificação deve ser usada ou uma técnica de recuperação de melhor esforço for preferida. Em algumas modalidades de uma API initializeWorkerNode pode ser suportada para solicitar a instanciação explícita dos nós de trabalho em um estágio especificado. Em modalidades em que a recuperação baseada no ponto de verificação é executada, uma API saveCheckpoint pode ser apoiada para permitir que os clientes solicitem que os registros de progresso sejam gerados por nós de trabalho.

[063]Vários tipos de APIs de gerenciamento de saída de SPS podem ser suportados em diferentes modalidades, como uma API setOutputDistribution pelo qual um cliente pode indicar um ou mais fluxos a serem criados usando os resultados das operações de processamento realizados em uma fase especificada e as políticas de particionamento específicas a serem utilizadas para os fluxos de recém-criados. Alguns estágios de processamento podem ser configurados principalmente para reparticionamento - por exemplo, uma função de particionamento PF1 que mapeia os registros de dados para as partições N1 com base no conjunto de atributo de registro A1 pode estar em uso por um fluxo de entrada S1 e um estágio de processamento pode ser usado para implementar uma função de particionamento PF2 diferente para mapear aqueles mesmos registros de dados para as partições N2 (usando ou um conjunto de atributos diferentes A2 ou o mesmo conjunto de atributos A1). Algumas APIs de SPS, tal como linkStages, podem ser utilizadas para configurar os gráficos arbitrários (por exemplo, gráficos acíclicos direcionados) compreendendo uma pluralidade de estágios. Em algumas modalidades, os conectores para estruturas de processamento de fluxo de terceiros ou de código aberto podem ser suportados. Em um exemplo de realização, em um estágio de SPS pode ser usado para preparar os registros de dados (por exemplo, mediante a formatação de forma adequada dos resultados das operações de tratamento realizadas no estágio) para o consumo pelos sistemas de terceiros ou de código aberto existentes. Uma API, tal como createThirdPartyConnector, pode ser utilizada na configuração de tais conectores na modalidade representada e as transformações apropriadas dos resultados do estágio de SPS em um formato compatível com o sistema de terceiros podem ser realizadas através de um ou mais módulos conectores instanciados como um resultado de uma invocação de createThirdPartyConnector.

[064]O SPS pode invocar os APIs de SMS 307 para executar pelo menos algumas das suas funções, conforme indicado pela seta 352. Os APIs de SMS 307 podem incluir, por exemplo, createStream e deleteStream (para criar e eliminar um fluxo, respectivamente) e getStreamInfo (para obter os metadados de um fluxo, tais como os endereços de rede de vários tipos de nós responsáveis por uma determinada partição) na modalidade representada. Uma interface putRecord pode ser usada para escrever os registros de dados, enquanto as interfaces de getIterator e getNextRecords podem ser utilizadas para leituras não-sequenciais e sequenciais respectivamente. Uma interface repartitionStream pode ser usada para solicitar o reparticionamento dinâmico de um fluxo especificado em algumas modalidades. Os clientes 370 que desejarem fazê-lo podem invocar as APIs de SMS 307 diretamente, como indicado pela seta 354. Como indicado anteriormente, várias outras APIs de SMS e/ou SPStambém podem ser implementadas em outras modalidades e algumas das APIs listadas na FIG. 3 não podem ser implementadas em algumas modalidades.

[065]Em várias modalidades, as interfaces programáticas além das APIs também podem ou não ser implementadas tanto ao SPS como ao SMS. Essas interfaces podem incluir interfaces gráficas de usuário, as páginas de web ou sites de web, interfaces de linha de comando e assim por diante. Em alguns casos, as interfaces baseadas na web ou GUIs podem usar as APIs como blocos de construção - por exemplo, uma interação baseada em web pode resultar na invocação de uma ou mais APIs dos componentes de controle de SMS ou SPS. A FIG. 4 ilustra uma interface com base em web de exemplo que pode ser implementada para permitir que os clientes de SPS gerarem os gráficos de etapas de processamento de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado, a interface compreende uma página de web 400 com uma área de mensagem 402, uma área de menu gráfico 404 e uma área de projeto gráfico 403.

[066]Os usuários podem ser fornecidos as instruções gerais com relação à construção dos gráficos de processamento de fluxo na área de mensagem 402, assim como links para habilitar o uso para aprender mais sobre os conceitos de fluxo e primitivos. Uma quantidade de ícones gráficos pode ser fornecida como parte de um conjunto de ferramentas de gráfico de processamento de fluxo na área de menu 404. Por exemplo, os clientes podem ser autorizados para indicar, como entradas ou saídas de vários estágios de processamento de SPS, fluxos persistentes 451, fluxos efémeros 452 ou conectores 453 a ambientes de processamento de terceiros. Com relação ao SPS/SMS aos quais a interface baseada em web é implementada, um fluxo persistente 451 pode ser definido como um fluxo cujo registros de dados são armazenados em dispositivos de armazenamento persistente, tais como discos, RAMs não voláteis ou SSD e um fluxo efémero 452 pode ser definido como um cujos registros de dados não necessitam ser armazenados em dispositivos de armazenamento persistente. Um fluxo efémero pode ser criado, por exemplo, a partir da saída de um estágio de SPS que se espera ser consumido como entrada por um estágio de SPS diferente em que uma política de recuperação de melhor esforço deve ser implementada.

[067]Dois tipos de estágios de processamento são suportados no exemplo de página de web de construção gráfica de SPS 400: os estágios 455 em que a recuperação do nó de trabalho com base em ponto de verificação é utilizada (por exemplo, cada nó de trabalho salva os registros de progresso em intervalos e em caso de falha de um nó de trabalho em particular, um nó de substituição se refere aos registros de progresso do nó falho para determinar quais os registros de dados começar a processar) e os estágios 456 em que a recuperação de melhor esforço é utilizada (por exemplo, nós de trabalho de substituição não se referem aos registros de progresso, mas simplesmente começam a processar novos registros de dados à medida que são recebidos). Os detalhes sobre as operações de processamento a serem realizadas em cada etapa podem ser inseridos clicando no ícone correspondente na área de construção do gráfico 403, como indicado pelas instruções na área de mensagem 402. Além dos ícones para os fluxos, conectores e estágios de processamento, área de menu 404 também inclui o tipo de ícone 459 que indica os sistemas de processamento de terceiros ou de fluxo externo e tipo de ícone 460, indicando os nós de um serviço de armazenamento que pode ser implementado em uma rede de fornecedor cujos recursos estão sendo usados para os estágios de processamento.

[068]No cenário de exemplo mostrado na FIG. 4, um cliente construiu um gráfico 405 que compreende três estágios de processamento 412, 415 e 416 dentro da área de projeto gráfico 403. O estágio de processamento 412, que é configurado para usar a recuperação baseada em posto de verificação, usa um fluxo persistente 411 como entrada. A saída ou resultados do processamento no estágio 412 são enviados para dois destinos: sob a forma de um fluxo persistente diferente 413 que forma a entrada do estágio 415 e sob a forma de um fluxo efémero 414 que forma a entrada do estágio 416. Os estágios 415 e 416 usam, ambos, as políticas de recuperação de melhor esforço para os seus nós de trabalho. A saída do estágio 415 é enviada sob a forma de um fluxo efémero para o nó de serviço de armazenamento 419. A saída do estágio 415 é enviada através de um conector 417 a um sistema de processamento de terceiros 418. Um botão de "salvar gráfico" 420 pode ser usado para salvar uma representação do gráfico de estágio de processamento, por exemplo, em qualquer formato adequado, tais como JSON (JavaScriptObjectNotation), XML (ExtensibleMarkupLanguage) ou YAML. Os fluxos de trabalho de processamento arbitrariamente complexos podem ser construídos usando as ferramentas similares àqueles mostradas na FIG. 4 em várias modalidades. Os fluxos de trabalho criados usando essas ferramentas podem ser posteriormente ativados e tais ativações podem resultar em invocações de APIs de SMS - por exemplo, para obter os registros de dados para o estágio de processamento, tal como o estágio 412 da FIG. 4, as interfaces de getIterator e/ou de getNextRecords podem ser invocadas em operação 411.

[069]A FIG. 5 ilustra exemplos de interfaces de apresentação de registros programáticos e interfaces de recuperação de registros que podem ser implementadas em um SMS, de acordo com pelo menos algumas modalidades. Os registros de dados, tal como os DRs 110K e 110Q ilustrados, podem ser apresentados através de vários tipos de interfaces de ingestão programáticas 510 ao SMS na modalidade retratada. Um DR 110 pode compreender quatro tipos de elementos em algumas modalidades: um identificador de fluxo, tal como 501A (para o fluxo "S1") ou 501B (para o fluxo "S2"), uma indicação dos dados ou do corpo do registro, uma chave de partição opcional 504 (tais como 504A ou 504B) e um indicador de preferência de sequenciamento opcional 506 (tais como os indicadores de preferência de sequenciamento 506A e 506B). Os dados em si podem ser fornecidos em linha em alguns registros de dados (por exemplo, os dados em linha 502 de DR 110K), enquanto que para outros registros de dados um ponteiro ou endereço 503 pode ser fornecido, indicando ao SMS um local acessível por rede (ou um endereço a um dispositivo local que não exige transferências de rede). Em algumas modalidades, um determinado fluxo pode suportar tanto apresentações de registo de dados em linha e por referência (com base em endereços). Em outras modalidades, um determinado fluxo de dados pode exigir que os produtores de dados forneçam todos os dados em linha ou todos os dados por referência. Em algumas implementações, uma apresentação de registro de dados pode incluir um identificador de partição a ser utilizado para o registro.

[070]Os registros de dados de entrada 110 podem ser direcionados aos nós de ingestão e/ou armazenamento respectivos com base em uma política de particionamento na modalidade representada. Da mesma forma, a recuperação de registro também pode ser baseada em partições - por exemplo, um ou mais nós de recuperação podem ser designados para responder aos pedidos de leitura direcionados aos registros de uma determinada partição. Para alguns fluxos, os produtores de dados podem ser obrigados a fornecer uma chave de partição explícita com cada solicitação de gravação de registro de dados. Para outros fluxos, os SMS podem ser capazes de distribuir os registos de dados de acordo com um esquema de particionamento que depende dos metadados ou atributos além das chaves de partição explicitamente fornecidas - por exemplo, as informações de identificação relativas ao produtor de dados de apresentação podem ser usados como uma chave de partição ou uma porção ou a totalidade do endereço de IP do produtor de dados de apresentação pode ser usada, ou pode ser utilizada uma porção dos dados a ser apresentada. Em algumas implementações, por exemplo, uma função hash pode ser aplicado a uma chave de partição para se obter um valor de número inteiro de um determinado tamanho, tal como um número inteiro de 128 bits. A faixa total dos números inteiros positivos desse tamanho (por exemplo, de 0 a 2A128-1) pode ser dividida em N sub-intervalos contíguos, sendo que cada sub-intervalo representa uma partição respectiva. Assim, em tal exemplo, qualquer determinar chave de partição determinada ou fornecida para um registro de dados seria em hash para um número inteiro de 128 bits correspondentes e o sub-intervalo contíguo dos números inteiros de 128 bits ao qual esse número inteiro pertence pode indicar a partição à qual o registro de dados pertence. Mais detalhes sobre as políticas de particionamento e o seu uso são fornecidos abaixo com relação à FIG. 15.

[071]O conjunto de nós responsáveis pela ingestão ou aceitação dos registros de dados da partição em particular, armazenar os registros de dados e responder aos pedidos de leitura para a partição em particular, são coletivamente referidos como nós de ISR (ingestão, armazenamento e recuperação) para a partição na FIG. 5. A notação Sj-Pk é usada para indicar a partição de k-enésima do fluxo Si. Na modalidade ilustrada, os nós de ISR 520A estão configurados para ingerir, armazenar e recuperar os registros de partição S1-P1, nós de ISR 520B são configurados para registro da partição S1-P2, nós de ISR 520C são configurados para registro da partição S1-P3, nós de ISR 520K são configurados para registro da partição S2-P1 e nós de ISR 520L são configurados para registro da partição S2-P2. Em algumas modalidades, um determinado nó de um subsistema de ingestão, um subsistema de armazenamento ou um subsistema de recuperação pode ser configurado para processar os registos de dados de mais de uma partição (ou mais de uma partição de mais de um fluxo). Em algumas modalidades, os registos de uma única partição de um determinado fluxo podem ser ingeridos, armazenados ou recuperados por mais de um nó. O número de nós de ingestão designados para uma determinada partição Sj-Pk pode, pelo menos em alguns casos, se diferir do número de nodos de ingestão designados por uma partição SJ-Pl diferente e também pode ser diferente do número de nós de armazenamento designados por SJ-Pk e/ou o número de nós recuperação designados para SJ-PK. No que diz respeito à ingestão e/ou recuperação, os nós de controle de SMS podem implementar os APIs (como getStreamInfo) em algumas modalidades para permitir que os clientes determinem quais nós são responsáveis por quais partições. Os mapeamentos entre os registros de dados e partições, e entre as partições e nós de ISR (ou nós de controle) configurados, podem ser modificadas ao longo do tempo, conforme descrito abaixo na discussão sobre reparticionamento dinâmico.

[072]Em algumas modalidades, várias interfaces programáticas diferentes 580 podem ser implementadas para recuperar ou ler registos de dados de fluxo a partir de uma determinada partição. Como mostrado na FIG. 5, algumas interfaces de recuperação 581 podem ser implementadas para acessos não-sequenciais, como getIterator (para instanciar um iterador ou ler o cursor em ou depois de um registro de dados com um número de sequência especificado) ou getRecord (para ler um registro de dados com uma sequência de número especificada). Outras interfaces de recuperação 582 podem ser implementadas para recuperação sequencial, tais como getNextRecords (uma interface que solicita que N registros sejam lidos a partir da posição atual de um iterador, em ordem crescente de número de sequência). Em sistemas de armazenamento baseados em disco rotativo, como mencionado anteriormente, I/O sequencial pode em muitos casos ser muito mais eficiente do que I/O aleatória, devido ao fato de que o número de buscas de cabeça em disco necessário em média por I/O pode ser tipicamente muito menor para I/O sequencial que para I/O aleatória. Em muitas modalidades, os registros de dados de uma determinada partição podem ser gravados em ordem numérica sequência, e como resultado os pedidos de leitura sequenciais com base na ordenação numérica sequencial (por exemplo, usando getNextRecords ou uma interface similar) pode ser muito mais eficiente do que pedidos de leitura aleatórios. Em pelo menos algumas modalidades, por conseguinte, diferentes taxas de cobrança podem ser ajustadas para interfaces de recuperação sequencial versus não sequenciais - por exemplo, os clientes podem ser cobrados mais para leituras não-sequenciais.

Subsistema de ingestão

[073]A FIG. 6 ilustra exemplos de elementos de um subsistema de ingestão 204 de um SMS, de acordo com pelo menos algumas modalidades. Na modalidade representada, as operações de ingestão são logicamente divididas em funções front-end e back-end, com as funções de front-end envolvendo as interações com os produtores de dados 120 (por exemplo, 120A, 120B ou 120C) e as funções de back-end envolvendo as interações com um subsistema de armazenamento de SMS. Tal divisão front-end/back-end pode ter várias vantagens, tais como o reforço de segurança do subsistema de armazenamento e evitar ter de fornecer detalhes da política de separação para os produtores de dados. As bibliotecas de cliente de SMS 602 podem ser fornecidas para a instalação em vários produtores de dados 120 e os produtores de dados podem invocar as interfaces programáticas incluídas nas bibliotecas 602 para enviar dados para ingestão. Por exemplo, em uma modalidade os produtores de dados 120 podem compreender agentes de log ou monitoramento instanciados em centenas ou milhares de servidores físicos e/ou virtuais de uma rede de fornecedor. Tais agentes podem coletar várias mensagens de log e/ou métricas em seus respectivos servidores e periodicamente apresentar as mensagens ou métricas coletadas para um endpoint de distribuidor de carga de front-end 604 instanciado por um ou mais nós de controle de ingestão 660 do SMS. Em algumas modalidades, um ou mais endereços de IP virtuais (VIPs) podem ser fixados para os distribuidores de carga, em que os produtores de dados podem apresentar os dados de fluxo. Em uma implementação, uma técnica de round-robin DNS (Domain Name System) pode ser usada para um VIP para selecionar um distribuidor de carga em particular dentre os vários distribuidores de carga equivalentemente configurados aos quais os dados devem ser enviados pelos produtores de dados 120.

[074]Os registos de dados recebidos podem ser direcionados para qualquer um dos vários nós de front-end 606 (por exemplo, 606A, 606B ou 606C) na modalidade representada. Em pelo menos algumas modalidades, o distribuidor de carga 604 pode não estar ciente da política de particionamento 650 em uso para os registros de dados e o nó de front-end 606 pode, portanto, ser escolhido para um determinado registro de dados usando balanceamento de carga round-robin (ou algum outro algoritmo de balanceamento de carga de uso geral) em vez de balanceamento de carga com base na partição. Os nós de front-end 606 podem estar cientes das políticas de particionamento 650 para vários fluxos e podem interagir com os nós de controle de ingestão 660 para obter as identidades do nó de ingestão de back-end específico 608 (por exemplo, 608A, 608B ou 608C) que está configurado para os registros de dados de uma determinada partição. Assim, na modalidade representada, os nós de front-end 604 podem, cada um, transmitir os registos de dados para uma pluralidade de nós de back-end 606, com base nas partições respectivas às quais pertencem os registos de dados. Conforme observado anteriormente, a partição a qual um registro de dados pertence pode ser determinada com base em qualquer combinação de vários fatores, tais como uma chave de partição fornecida pelo produtor de dados, um ou mais outros atributos, tais como a identidade ou endereço do produtor de dados ou o conteúdo dos dados.

[075]Os nós de back-end 606 podem, cada um, receber os registros de dados pertencentes a uma ou mais partições de um ou mais fluxos e transmitir os registros de dados para um ou mais nós do subsistema de armazenamento. Os nós de back-end podem ser referidos como "servidores PUT" em algumas modalidades em que os dados são enviados via APIs de serviços web "PUT" HTTP (HyperTextTransferProtocol). Um determinado nó de back-end pode determinar o conjunto de nós do subsistema de armazenamento ao qual seus registros de dados devem ser transmitidos através da apresentação de uma consulta para um nó de controle 660 (que por sua vez pode apresentar uma consulta correspondente a um nó de controle do subsistema de armazenamento nas modalidades em que controlar as funções para os diferentes subsistemas são manipulados por conjuntos separados de nós).

[076]Em pelo menos algumas modalidades, uma variedade de políticas de reconhecimento de ingestão diferentes 652 podem ser suportadas, tal como uma política de ingestão de pelo-menos-uma-vez ou uma política de ingestão de melhor esforço. Em uma política de pelo-menos-uma-vez, os produtores de dados 120 podem exigir reconhecimentos positivos para cada registro de dados apresentados e podem repetidamente apresentar o mesmo registro de dados (se um reconhecimento da primeira submissão não for recebido), até que um reconhecimento seja finalmente recebido. Na política de ingestão de melhor esforço, os reconhecimentos positivos podem não ser necessários para pelo menos alguns registros de dados apresentados (embora o subsistema de ingestão possa fornecer ainda reconhecimentos ocasionais ou possa responder a pedidos explícitos para reconhecimentos dos produtores de dados). Em algumas modalidades nas quais o subsistema de ingestão 204 é necessário para fornecer os reconhecimentos para os produtores de dados, o nó de ingestão de back-end 608 responsável por um determinado registro de dados pode esperar até que o número necessário de réplicas dos registros de dados seja criado com êxito no subsistema de armazenamento (por exemplo, de acordo com uma política de persistência estabelecida para o fluxo), antes de gerar um reconhecimento. Em várias modalidades, um número de sequência pode ser gerado pelo subsistema de ingestão para cada registro de dados recebidos, por exemplo, indicativo da ordem em que esse registro foi ingerido em relação a outros registros da mesma partição ou fluxo e tal número de sequência pode ser retornado ao produtor de dados como um reconhecimento, ou como parte de um reconhecimento. Mais detalhes sobre os números de sequência são apresentados a seguir com referência à FIG. 13a e FIG. 13b. O número de reconhecimento e/ou sequência pode ser transmitido de volta para o produtor de dados através de um nó de front-end 606 em algumas implementações. Em pelo menos uma implementação, a política de pelo-menos-uma-vez pode ser implementada entre os nós de front-end e back-end do próprio subsistema de ingestão - por exemplo, um determinado nó de front-end 606 pode repetidamente apresentar um registro de dados para o nó de back-end apropriado 608 até o nó de back-end fornecer um reconhecimento.

[077]Nós de controle ingestão 660 podem ser responsáveis por, entre outras funções, instanciar os nós de front-end e back-end, monitorando os níveis de saúde e de carga de trabalho dos nós, orquestrando failovers, conforme necessário, fornecendo respostas a perguntas a respeito de quais nós são responsáveis por uma determinada partição ou para consultas relacionadas a política, para operações de configuração relacionadas a ingestão resultando do reparticionamento dinâmico dos fluxos. O número de nós de controle de ingestão designados para um dado conjunto de um ou mais fluxos pode ser alterado ao longo do tempo em algumas modalidades, por exemplo, um ou mais nós de controle mestre podem ser responsáveis pela reconfiguração do pool de nó de controle, conforme necessário. Em algumas modalidades, em que os grupos de redundância são criados para nós de front-end ou back-end de ingestão, conforme descrito abaixo em mais detalhe com respeito à FIG. 9 e FIG. 10, os nós de controle 660 podem ser responsáveis por manter o controle dos quais os nós são primários e que são não-primários, para detectar as condições de disparo para falha e para selecionar os substitutos quando falhas forem necessárias. Observa-se que a arquitetura de subsistema de ingestão de multi- camadas ilustrada na FIG. 6 não pode ser implementada em algumas modalidades, por exemplo, apenas um único conjunto dos nós de ingestão pode ser configurado em alguns cenários.

Subsistema de armazenamento

[078]A FIG. 7 ilustra elementos de exemplo de um subsistema de armazenamento de um SMS de acordo com pelo menos algumas modalidades. Como mostrado, os nós de ingestão 608 (por exemplo, os nós de back-end de ingestão em modalidades em que as responsabilidades de ingestão de front-end e back-end são manipuladas por diferentes conjuntos de nós) podem transmitir os registros de dados de uma ou mais partições de um fluxo para os nós de armazenamento respectivos 702 configurados para essas partições. Por exemplo, o registro de dados 110A da partição S1-P1 é enviado ao nó de armazenamento 702A, o registro de dados 110B da partição S2-P3 é enviado para o nó de armazenamento 702B e 702C, o registro de dados 110C da partição S3-P7 é enviado para o nó de armazenamento 702D e o registro de dados 110D da partição S4-P5 é enviado inicialmente para o nó de armazenamento 702E. Nós de controle de armazenamento 780 podem ser responsáveis pela aplicação das políticas de persistência 750 que são aplicadas aos registros de dados dos diferentes fluxos, configurando e reconfigurando os nós de armazenamento, conforme necessário, monitorando estados de nó de armazenamento, gerenciando falhas, respondendo a consultas de configuração de armazenamento ou consultas de política de armazenamento e várias outras tarefas administrativas na modalidade representada.

[079]Políticas de persistência 750 podem diferir uma da outra em vários modos em diferentes modalidades. Por exemplo, uma política de persistência que P1 aplicada à fluxo SJ pode diferir de uma política P2 aplicada para transmitir Sk em (a) o número de réplicas de cada registro de dados a ser armazenado, (b) o tipo de dispositivo de armazenamento ou sistema em que as réplicas estão a ser armazenadas (por exemplo, se réplicas devem ser armazenadas na memória volátil, caches não-voláteis, armazenamento baseado em disco rotativo, drives de estado sólido (SSDs), dispositivos de armazenamento de vários tipos, RAID (matrizes redundantes de discos baratos) de vários tipos, em sistemas de gerenciamento de banco de dados, em nós de um serviço de armazenamento implementado por uma rede do fornecedor e assim por diante), (c) a distribuição geográfica das réplicas (por exemplo, se os dados de fluxo devem ser feitos resilientes a falhas em grande escala ou certos tipos de catástrofes colocando réplicas em diferentes data centers) , (d) o protocolo de reconhecimento de escrita (por exemplo, se N réplicas devem ser armazenadas, quantas cópias de N precisam ser gravadas com êxito antes que uma confirmação deva ser fornecida para o nó de ingestão), e/ou (e) se, no caso em que várias réplicas de dados registros deverão armazenadas, as réplicas devem ser criadas em paralelo ou sequencialmente. Em alguns casos em que várias réplicas deverão ser armazenadas, como no caso de registro de dados 110D, um determinado nó de armazenamento pode transmitir o registro de dados para outro nó de armazenamento (por exemplo, nó de armazenamento 702E envia registro de dados 110D para replicação adicional para o nó de armazenamento 702F e nó de armazenamento 702F o envia para o nó de armazenamento 702G). Em outros casos em que uma política de persistência de múltiplas réplicas é usada, como no caso de registro de dados 110B para que duas réplicas em memória devem ser armazenadas, o nó de ingestão pode iniciar as repetições múltiplas em paralelo. Em pelo menos algumas modalidades, a política de persistência escolhida pelo cliente pode não especificar o tipo de local de armazenamento para ser usado para registros de dados de fluxo; em vez disso, o SMS pode selecionar os tipos apropriados de tecnologia de armazenamento e/ou locais com base em vários critérios, tais como custo, execução, a proximidade de fontes de dados, requisitos de durabilidade e assim por diante. Em uma modalidade, o cliente ou o SMS pode decidir usar tecnologias de armazenamento diferentes ou tipos de locais de armazenamento para diferentes partições de um determinado fluxo, ou para diferentes fluxos.

[080]No exemplo mostrado na FIG. 7, a política de persistência aplicada para transmitir S1 (ou pelo menos partição S1-P1 de fluxo S1) é uma política de réplica única em memória, enquanto que para fluxo S2 é aplicado uma política de duas réplicas em paralelo em memória. Assim, uma réplica em memória 704A de registro de dados 110A é criada no nó de armazenamento 702A, enquanto duas réplicas em memória 705A e 705B correspondentes ao registro de dados 110B são criadas em nós de armazenamento paralelo 702B e 702C. Para registro de dados de fluxo de S3 110C, uma única réplica em disco 706A é criada. Para fluxo S4, uma política sequencial de três réplicas-em-disco é aplicável, e como resultado respectivo réplicas em disco 707A, 707B e 707C são criadas sequencialmente em nós de armazenamento 702E, 702F e 702G. Vários outros tipos de políticas de persistência podem ser aplicados a fluxos de dados em modalidades diferentes. Nós do subsistema de recuperação podem obter registros de dados a partir dos nós de armazenamento adequados em resposta a invocações de vários tipos de APIs de recuperação por parte dos consumidores de dados. Subsistema de recuperação e estágios de processamento

[081]A FIG. 8 ilustra elementos de exemplo de um subsistema de recuperação de um SMS e exemplos de interações do subsistema de recuperação com um SPS, de acordo com pelo menos algumas modalidades. Como mostrado, o subsistema de recuperação 206 pode compreender uma pluralidade de nós de recuperação 802, como nó de recuperação 802A, 802B e 802C, assim como um conjunto de nós de controle de recuperação 880. Cada um dos nós de recuperação 802 pode ser configurado para responder pedidos de recuperação de dados fluxo a partir de vários clientes ou consumidores de dados 130, tal como o nós de trabalho 840 de um SPS como descrito abaixo. Uma variedade de interfaces de programação de recuperação 802 pode ser implementada pelos nós de recuperação em diferentes modalidades, tais como as interfaces de recuperação não sequenciais e sequenciais descritas anteriormente. Em algumas modalidades, APIs de serviços web, tais como solicitações HTTP GET, podem ser usadas para recuperação de registro de dados, e os nós de recuperação 802 podem, portanto, ser referido como servidores GET. Um dado nó de recuperação 802 pode ser configurado, por exemplo, por um nó de controle de recuperação 880, para obter os registros de dados de uma ou mais partições de fluxo na modalidade representada a partir do conjunto apropriado de nós de subsistema de armazenamento 702, tais como nós de armazenamento 702A e 702B.

[082]Na modalidade representada, um nó de recuperação 802 pode interagir com um ou mais nós de armazenamento 702, e também responder aos pedidos de recuperação recebidos a partir de um ou mais nós de trabalho SPS 840. Por exemplo, registros de dados de partições S4-P5 (por exemplo, registro de dados 110K) e S5- P8 (por exemplo, registro de dados 110L) são lidos a partir do nó de armazenamento 702A pelo nó de recuperação 802A, e fornecidos a nós de trabalho 840A e 840K respectivamente. Registros de dados de partição S6-P7, tais como 110M, são lidos por nó de recuperação 802B a partir do nó de armazenamento 702A e fornecidos ao nó de trabalho 840K. Registros de dados de partição S4-P7 são lidos por nó de recuperação 802C a partir do nó de armazenamento 702B e fornecidos ao nó de trabalho 840B, e também a outros dados de consumidores 130 (por exemplo, consumidores de dados que invocam diretamente APIs de recuperação de SMS em vez de interagir com SMS através de um SPS).

[083]Em pelo menos algumas modalidades, alguns ou todos os nós de recuperação 802 podem implementar respectivos caches 804 (como cache 804A no nó de recuperação 802A, cache 804B no nó de recuperação 802B, e cache 804C no nó de recuperação 802C) em que os registros de dados de várias partições podem ser retidos temporariamente em antecipação de pedidos futuros de recuperação. Nós de controle de recuperação 880 podem ser responsáveis por implementar uma série de políticas de recuperação 882, inclusive por exemplo políticas de cache (por exemplo, como um grande cache deve ser configurado para uma determinada partição, por quanto tempo os registros de dados devem ser armazenado em cache), políticas de seleção de nó de armazenamento (por exemplo, que determinado nó de armazenamento deve ser contatado primeiro para obter um determinado registro de dados, em cenários em que várias réplicas de registros de dados são armazenadas) e assim por diante. Além disso, nós de controle de recuperação podem ser responsáveis por instanciar e monitorar os nós de recuperação 802, respondendo a perguntas a respeito de quais nós de recuperação são responsáveis por quais partições, iniciando ou respondendo a operações de reparticionamento, e assim por diante.

[084]No exemplo ilustrado, SPS 290 compreende duas fases de processamento, 215A e 215B. Nós de controle de SPS 885 podem ser responsáveis por instanciar nós de controle 804 nos vários estágios de processamento 215, tais como nó de trabalho 840A para processar registros de partição S4-P5, nó de trabalho 840B para processar registros de partição S4-P7 e nó de trabalho 840K para processar registros de partições S5-P8 e S6-P7. Os nós de controle SPS 885 podem implementar interfaces de programação (tal como aquelas ilustrados na FIG. 3 e FIG. 4) permitindo que os clientes de SPS projetem fluxos de trabalho de processamento. Várias políticas de checkpoint 850 podem ser implementadas por fases diferentes de processamento ou fluxos de trabalho, indicando quando ou se nós de trabalho devem armazenar registros de progresso indicando quanto progresso fizeram no processamento de suas respectivas partições, os tipos de dispositivos de armazenamento que devem ser usados para os registros de progresso, e assim por diante. Políticas de falha/recuperação 852 podem indicar as condições de acionamento ou limite que devem conduzir a substituição de um nó de trabalho com um outro nó, e se a recuperação de melhor esforço deve ser utilizada ou recuperação com base em ponto de verificação deve ser utilizada para uma dada fase de transformação . Em pelo menos algumas modalidades, os nós de controle de SPS 885 podem interagir com vários tipos de nós de controle de SMS, por exemplo, para identificar os nós de recuperação a partir dos quais devem ser obtidos os registros de dados de um dado fluxo, para estabelecer novos fluxos efêmeros ou persistentes que possam ser necessários para um fluxo de trabalho de processamento em especial, e assim por diante. Em pelo menos uma modalidade os clientes podem interagir com os nós de controle SPS para instanciar fluxos - por exemplo, em vez de usar interfaces de controle de SMS, alguns clientes podem querer invocar as interfaces de SPS de nível superior somente. Note-se que, embora conjuntos separados de nós de controle sejam mostrados nas figs. 6, 7 e 8, para a ingestão de SMS, armazenamento, e subsistemas de recuperação, e para as fases de SPS, em pelo menos algumas modalidades um dado nó de controle pode ser usado para vários dos subsistemas e/ou SPS.

Grupos de redundância de nó

[085]Em pelo menos algumas modalidades, grupos de nós redundantes podem ser configurados para um ou mais subsistemas de um SMS. Ou seja, em vez de, por exemplo, configurar um nó de recuperação para recuperar registros de dados para uma partição fluxo de SJ-Pk, podem ser estabelecidos dois ou mais nós para tais recuperações, com um nó que está sendo concedido um papel "primário" ou ativo em um determinado ponto no tempo, enquanto o outro nó ou nós são designados como nós "não primários". O nó primário atual pode ser responsável por responder a solicitações de trabalho, por exemplo, os pedidos recebidos, quer de clientes ou dos nós de outros subsistemas. O nó (ou nós) não-primário pode permanecer dormente até uma falha ser acionado, por exemplo, devido a uma falha, perda de conectividade ao primário, ou outras condições de acionamento, altura em que um não-primário selecionado pode ser notificado por um nó de controle para assumir as responsabilidades do primário anterior. O principal papel pode, assim, ser revogado do nó primário atual titular durante a falha e concedido a um nó não-primário atual. Em algumas modalidades, os nós não primários podem assumir como principais quando é feita uma determinação de que um limite de falha deve ocorrer, por exemplo, as notificações explícitas podem não ser necessárias. Tais grupos redundantes de nós pode ser configurados para ingestão, armazenamento, recuperação e/ou funções de controle em um SMS em várias modalidades, e uma abordagem semelhante também pode ser tomada para nós de trabalho em um SPS em pelo menos algumas modalidades. Tais grupos compreendem, pelo menos, um nó primário e pelo menos um nó não primário para uma dada função podem ser referidos como "grupos de redundância" ou "grupos de replicação" em algumas modalidades. Note-se que os grupos de redundância dos nós de armazenamento podem ser executados independentemente do número de cópias físicas dos registros de dados que são armazenados - por exemplo, o número de réplicas a serem armazenadas de um registro de dados pode ser determinado através de uma política de persistência, enquanto o número de nós de armazenamento que estão configurados para a partição correspondente pode ser determinado com base em políticas de grupo de redundância.

[086]A FIG. 9 ilustra exemplos de grupos de redundância que podem ser criados para nós de um SMS ou um SPS, de acordo com pelo menos algumas modalidades. Na modalidade representada, para uma determinada partição de fluxo de SJ-Pk, respectivos grupos de redundância (RGs) 905, 915, 925 e 935 são configurados para nós de ingestão, nós de armazenamento, nós de recuperação e nós de controle. Um RG 935 comum para os nós de controle é implementado na modalidade ilustrada, embora RGs separados para os nós de controle da ingestão, os nós de controle de armazenamento, ou nós de controle de recuperação possam ser implementados em algumas modalidades. Cada RG compreende um nó primário (por exemplo, ingestão nó primário 910A, nó de armazenamento primário 920A, nó de recuperação primário 930A, e o nó de controle primário 940A) e, pelo menos, um nó não primário (por exemplo, nó não primário de ingestão 910B, nó não-primário de armazenamento 920B, nó de recuperação não primário 920C e nó de recuperação não primário 920D). O papel primário pode ser revogado e concedido a um fluxo não- primário, de acordo com as respectivas políticas de falha 912 (para nós de ingestão), 922 (para nós de armazenamento), 932 (para os nós de recuperação) e 942 (para nós de controle). As políticas de falha podem, por exemplo, reger as condições acionamento que devem levar a uma alteração no estado primário, se e como o estado de saúde dos primários ou não-primários deve ser monitorado, o número de não- primários que devem ser configurados num dado grupo de redundância, e assim por diante. Em pelo menos algumas modalidades, um único RG pode ser estabelecido por várias partições - por exemplo, RG 905 pode ser responsável pelo tratamento de ingestão de registros de partição SJ-Pk, bem como Sp-Pq. Em algumas implementações, um nó que é designado como primário para uma partição pode simultaneamente ser designado como um não primário para uma outra partição. Numa modalidade, vários nós podem ser designados simultaneamente como nós primários dentro de um determinado RG - por exemplo, a carga de trabalho relacionada com a ingestão de uma determinada partição pode ser distribuída entre os dois nós primários, com um nó designado como um não-primário, no caso de uma falha em qualquer dos primários. O número de nós instanciados num dado RG pode depender da disponibilidade ou nível de resiliência desejado para as funções correspondentes (por exemplo, a quantas falhas concomitantes ou de sobreposição o grupo destina-se a ser capaz de resistir). Em algumas modalidades, em complemento ou em vez de serem usados para nós de SMS, grupos de redundância podem ser configurados para nós de trabalho de estágios de processamento de SPS. Os membros de um dado RG podem, por vezes, ser distribuídos geograficamente, por exemplo, em vários centros de dados, como ilustrado na FIG. 10. Nós de controle selecionados podem ser configurados para detectar condições de acionamento de falha em algumas modalidades, por exemplo, usando mecanismos de batimentos cardíacos ou outras técnicas de vigilância da saúde, e esses nós de controle podem orquestrar a falha, selecionando o nó não-primário apropriada como o substituto para um primário falhado, notificando/ativando o nó de substituição acionado, e assim por diante.

[087]Em algumas modalidades uma rede de servidor pode ser organizada numa pluralidade de regiões geográficas, e cada região pode incluir um ou mais recipientes de disponibilidade, que também podem ser chamados de "zonas de disponibilidade" aqui. Um recipiente de disponibilidade, por sua vez, pode compreender um ou mais locais distintos ou centros de dados, projetados de tal forma (por exemplo, com componentes independentes de infraestrutura, tais como equipamentos relacionados com a energia, equipamentos de refrigeração, componentes de segurança física) que os recursos em um determinado recipiente de disponibilidade são isolados a partir de falhas em outros recipientes de disponibilidade. Não pode ser esperado que uma falha em um recipiente de disponibilidade resulte numa falha em qualquer outro recipiente de disponibilidade; assim, o perfil da disponibilidade de uma instância de recursos ou de servidor de controle destina-se a ser independente do perfil de disponibilidade de instâncias de recursos ou servidores de controle num recipiente de disponibilidade diferente. Diversos tipos de aplicações podem ser protegidos contra falhas em um único local com o lançamento de várias instâncias de aplicação nos respectivos recipientes de disponibilidade, ou (no caso de alguns SMSs e SPSS) distribuir os nós de um determinado grupo de redundância em vários recipientes de disponibilidade. Ao mesmo tempo, em algumas implementações, conectividade de rede de latência baixa e barato pode ser proporcionada entre recursos (como hosts ou instâncias de computação usadas para os nós de SMS e SPS) que residem dentro da mesma região geográfica, e transmissões de rede entre os recursos do mesmo recipiente de disponibilidade podem ser ainda mais rápidas. Alguns clientes podem querer especificar os locais em que os seus recursos de gerenciamento de fluxo ou de processamento de fluxo são reservados e/ou instanciados, por exemplo, quer ao nível da região, o nível de recipiente de disponibilidade, ou um nível de centro de dados, para manter um grau desejado de controle de onde vários componentes de seus aplicativos exatamente são executados. Outros clientes podem ser menos interessados no local exato em que os seus recursos são reservados ou instanciados, contanto que os recursos satisfaçam os requisitos do cliente, por exemplo, para execução, disponibilidade elevada, e assim por diante. Nós de controle localizados em um recipiente de disponibilidade (ou centro de dados) podem ser capazes de configurar remotamente outros nós de SMS ou SPS em outros recipientes de disponibilidade (ou outros centros de dados) em algumas modalidades - ou seja, um determinado recipiente de disponibilidade ou centro de dados pode não precisar ter nós de controle locais para gerir os nós de SMS/SPS.

[088]A FIG. 10 ilustra um ambiente de rede de fornecedor no qual os nós de um dado grupo de redundância pode ser distribuído entre uma pluralidade de data centers, de acordo com pelo menos algumas modalidades. Rede de fornecedor 1002 compreende três recipientes de disponibilidade 1003A, 1003B e 1003C na modalidade representada. Cada recipiente de disponibilidade inclui partes ou a totalidade de um ou mais centros de dados - por exemplo, recipiente de disponibilidade 1003A compreende centros de dados 1005A e 1005B, recipiente de disponibilidade 1003B inclui centro de dados 1005C, e o recipiente de disponibilidade 1003C inclui centro de dados 1005D. Uma variedade de diferentes grupos de redundância 1012 de nós de SMS e/ou os SPS é mostrada. Alguns RGs 1012 podem ser implementados inteiramente dentro de um único centro de dados, como no caso de RG 1012A localizado no centro de dados 1005A. Outros RGs podem usar recursos de vários centros de dados dentro de um determinado recipiente de disponibilidade, como RG 1012B, que abrange os centros de dados 1005A e 1005B do recipiente disponibilidade 1003A. No entanto, outros RGs podem ser implementados usando recursos espalhados em diferentes recipientes de disponibilidade. Por exemplo, RG 1012C utiliza recursos localizados em centros de dados 1005B e 1005C de recipientes de disponibilidade 1003A e 1003B respectivamente, e RG 1012D utiliza recursos em centros de dados 1005B, 1005C e 1005D em recipientes de disponibilidade 1003A, 1003B e 1003C respectivamente. Num exemplo de implementação, se RG 1012 compreende um nós primário e dois não primários, cada um dos três nós pode ser localizado em um recipiente de disponibilidade diferente, assegurando, assim, que pelo menos um nó é altamente provável que permaneça funcional, mesmo se eventos de falha em larga escala ocorrerem em dois recipientes diferentes de disponibilidade simultaneamente.

[089] Serviços de console1078 e 1076, associados a SMS e SPS, respectivamente, podem fornecer interfaces fáceis de usar baseadas na Web para configurar as configurações relacionadas com fluxo na rede do fornecedor 1002 na modalidade representada. Um certo número de serviços adicionais, pelo menos alguns dos quais podem ser utilizados pelo SMS e/ou RPU, pode ser implementado na rede de fornecedor 1002 usando recursos distribuídos por um ou mais centros de dados ou através de um ou mais recipientes de disponibilidade. Por exemplo, um serviço de computação virtual 1072 pode ser implementado, permitindo aos clientes para usar quantidades selecionadas de energia em pacote como instâncias de computação de vários níveis de capacidade diferentes, e essas instâncias de computação podem ser usadas para implementar os nós de SMS e/ou SPS. Um ou mais serviços de armazenamento 1070 podem ser implementados, permitindo aos clientes armazenar e acessar objetos de dados com níveis de durabilidade de dados desejados, por exemplo, quer através de uma interface de volume de dispositivo de bloco ou através de uma interface de serviços da web. Os objetos de armazenamento podem ser anexáveis a ou acessíveis das instâncias de computação do serviço 1072 e podem ser utilizados para implementar diferentes políticas de persistência de fluxo em subsistemas de armazenamento de SMS em algumas modalidades. Em uma modalidade, um ou mais serviços de banco de dados como um serviço de gerenciamento de banco de dados de alta execução chave-valor 1074 ou um serviço de banco de dados relacional pode ser implementado na rede de fornecedor 1002, e um serviço como esse banco de dados pode ser usado para armazenar os registros de dados de fluxo de subsistemas de armazenamento de SMNS e/ou para o armazenamento de metadados de subsistemas de controle, subsistemas de ingestão, subsistemas de armazenamento, subsistemas de recuperação ou etapas de processamento.

Opções de segurança de fluxo

[090]Em pelo menos algumas modalidades, aos usuários de SMS e/ou SPS pode ser fornecido um número de opções relacionadas à segurança para os fluxos de dados, permitindo aos clientes selecionar os perfis dos recursos (por exemplo, máquinas virtuais ou físicas) de segurança a serem utilizados para as diversas categorias funcionais, tais como a ingestão, armazenamento, recuperação, processamento e/ou controle. Essas opções podem incluir, por exemplo, as escolhas quanto aos tipos de localizações físicas dos recursos utilizados para vários nós (por exemplo, se as instalações de rede do fornecedor devem ser utilizadas ou facilidades de propriedade de cliente devem ser utilizadas, que podem ter diferentes características de segurança do que facilidades de rede do fornecedor), opções sobre criptografia de dados de transmissão e/ou escolhas de isolamento de rede em várias partes da infraestrutura de manipulação de fluxo. Alguns clientes podem estar preocupados com a possibilidade de intrusos ou invasores obterem acesso a lógica de negócios de propriedade valiosa ou algoritmos, por exemplo, e podem querer implementar nós de trabalho de processamento de fluxo, usando dispositivos de computação dentro de promessas de propriedade do cliente. Os tipos de recursos a serem utilizados para a implementação de um conjunto de nós de SMS e/ou SPS podem ser aqui referidos como os "tipos de destino de posicionamento" para esses nós. A FIG. 11 ilustra uma pluralidade de tipos de destinos de posicionamento que podem ser selecionados para os nós de um SMS ou um SPS, de acordo com pelo menos algumas modalidades.

[091]Destinos de posicionamento podem ser selecionados dentro da rede de fornecedor 1102 para alguns tipos de categorias funcionais SMS/SPS (por exemplo, ingestão, armazenamento, recuperação, controle ou processamento) e rede externa de fornecedor 1102 para outros tipos de categorias funcionais SMS/SPS na configuração representada. Dentro de rede de fornecedor 1102, alguns recursos, tais como instâncias de computação, instâncias de armazenamento, ou instâncias de banco de dados podem ser implementados usando hosts de instância de multilocatários 1103. Tais de hosts de instância de multilocatários, em cada uma das quais nós de SPS ou SMS para um ou mais clientes podem ser instanciados, podem formar uma primeira categoria "A" de tipos de destino de posicionamento. Para evitar ter de compartilhar recursos físicos com outros clientes, alguns clientes podem pedir que os seus nós de SMS/SPS sejam implementados usando hosts de instância restritos a um único cliente. Tais hosts de instâncias de monolocatário podem formar categoria de colocação tipo "B".Hosts de instância de monolocatário podem ser preferíveis do ponto de vista de alguns clientes por várias razões. Como hosts de instância de multilocatários podem incluir instâncias de computação que pertencem a outros clientes, pode haver uma maior probabilidade de ataques de segurança de instâncias de outro cliente em hosts de instância de multilocatários do que em hosts de instância de monolocatário. Além disso, o fenômeno "vizinho barulhento", no qual a instância de computação de um cliente CI1 em execução no host multilocatário experimenta um aumento na carga de trabalho e começa a consumir uma grande proporção de ciclos de computação do host ou outros recursos, portanto, potencialmente afetando a execução de aplicações de outro cliente que estão sendo executadas em uma instância de computação diferente CI2, também pode ser evitado quando os hosts de instância de monolocatário são usados.

[092]Redes isoladas virtuais (IVNs) 1106, como IVN 1106A e 1106B podem representar uma outra categoria "C" de tipos de destino de posicionamento na modalidade representada. Uma IVN 1106 pode ser criada a pedido de um cliente de rede fornecedor em algumas modalidades como o equivalente lógico de uma rede privada, construída com recursos de rede do fornecedor, mas com configuração de rede que está sendo controlada em grande parte pelo cliente. Por exemplo, o cliente pode decidir os endereços IP a serem usados dentro de uma IVN 1106, sem ter que se preocupar com a possibilidade de duplicação de endereços IP que podem já estar a ser utilizada fora de IVN. Implementação de vários tipos de nós de SMS e SPS em uma ou mais IVNs pode adicionar um nível extra de segurança de rede para a gestão e/ou processamento de fluxo de dados de um cliente na modalidade representada. Em alguns casos, um determinado cliente pode querer colocar uma categoria funcional de nós de SMS/MSF numa IVN 1106, e uma diferente categoria funcional numa IVN diferente. Uma dada IVN 1106 pode compreender quaisquer hosts de instância de monolocatário, hosts de instância de multilocatários, ou ambos os tipos de instância hosts em várias modalidades. Em algumas modalidades, um outro conjunto de escolhas do tipo de destino de posicionamento (ou escolhas de perfil de segurança), usando os recursos do fornecedor de rede, não mostrado na FIG. 11, pode estar disponível para, pelo menos, alguns clientes. Em modalidades em que os clientes podem adquirir e usar instâncias de computação de serviço de computação virtualizado de um fornecedor de rede para as operações transmissão-relacionadas, as instâncias de computação podem ser usadas em um dos dois modos. Em um modo, um cliente pode fornecer a um SPS ou um SMS o programa ou programas executáveis que devem ser executados em instâncias de computação configuradas como nós de trabalho de SPS (ou por nós de ingestão, armazenamento ou recuperação), e deixar SMS ou SPS executar os programas e gerenciar os nós. Este primeiro modo pode ser referido como um modo "gerido por serviço de fluxo" de usar instâncias de computação para as operações de transmissão. No outro modo, um cliente pode desejar executar os programas executáveis e gerenciar as instâncias de computação, com menos apoio do SPS ou SMS. Este segundo modo pode ser referido como um modo "gerido por cliente" de usar instâncias de computação para as operações de fluxo. Estes dois modos de operação podem, portanto, representar escolhas adicionais com respeito aos tipos de destino de posicionamento cliente- selecionável ou perfis de segurança. Um cliente pode optar pelo modo gerenciado pelo cliente se, por exemplo, o programa executável é suscetível de exigir a depuração (incluindo single-stepping) que melhor pode ser realizada por especialistas no assunto da organização do cliente, enquanto o modo gerenciado por serviço de fluxo pode ser uma escolha razoável para um código mais maduro, que não é provável de exigir a depuração. Em algumas modalidades, diferentes políticas de preços podem ser aplicadas a estes dois modos.

[093]Uma série de opções de posicionamento pode ser suportada em instalações externas para o fornecedor de rede na modalidade mostrada na FIG. 11. Por exemplo, hosts 1160 em que bibliotecas de SMS 1171 e/ou bibliotecas de SPS 1172 estão instaladas podem ser utilizados para a gestão ou processamento de fluxo de dentro de instalações do cliente (por exemplo, centros de dados de propriedade do cliente ou premissas) 1110A ou 1110B, com os dois tipos de instalações do cliente diferindo no seu modo de conectividade com a rede do fornecedor. Instalação de cliente 1110A está ligada à rede do fornecedor 1102 através de pelo menos alguns links de internet compartilhados 1151 (ou seja, o tráfego de rede de outras entidades também pode fluir sobre algumas das ligações entre instalação de cliente 1110A e rede do fornecedor 1102). Em contraste, algumas instalações de clientes (como 1110B) podem ser ligadas à rede do fornecedor através de links especiais não compartilhados dedicados físicos 1106 (que podem, por vezes, ser referidos como links "diretos de conexão"). Estes dois tipos diferentes de instalações de clientes compreendem opções de destino de posicionamento "D" e "E", respectivamente, na terminologia utilizada na FIG. 11. Em algumas modalidades, porções do SMS e/ou SPS também podem ser implementáveis em instalações de terceiros (por exemplo, centros de dados usados, mas não de propriedade ou geridos por clientes do SMS/SPS), e tais instalações de terceiros podem ser designadas como tipo de destino de posicionamento "F". Em pelo menos uma parte das instalações de cliente e/ou terceiros, as bibliotecas de SMS e/ou SPS podem ter que ser obtidas a partir da rede do fornecedor e instaladas nos hosts a serem utilizados para os nós de SMS/SPS. Em pelo menos uma modalidade, os nós de todas as categorias funcionais podem ser aplicados externamente para o fornecedor de rede com a ajuda das bibliotecas adequadas. Os tipos de destino de posicionamento diferentes podem ser diferentes uns dos outros em vários aspectos relacionados com a segurança em diferentes modalidades, tais como as características de isolamento de rede implementadas, a funcionalidade de detecção de intrusão suportada, políticas de segurança física aplicada, os níveis de criptografia suportados, e assim por diante. Por conseguinte, cada um dos vários tipos de destino pode ser considerado como tendo um respectivo perfil de segurança, que pode ser diferente do perfil dos outros destinos de posicionamento em uma ou mais formas de segurança. Em algumas modalidades, os clientes do SMS e/ou SPS podem escolher os respectivos tipos de destino de posicionamento para os diferentes subsistemas ou nós configurados programaticamente, por exemplo, através do envio de um pedido para um ou mais nós de controle do SMS ou SPS, como ilustrado na FIG.12a e 12b. Note-se que em algumas modalidades e para certos tipos de aplicações de fluxo, os clientes podem desejar controlar os tipos de destino de posicionamento não apenas por razões de segurança, mas também para o execução e/ou razões de funcionalidade. Por exemplo, o fenômeno "vizinho barulhento" descrito acima pode ser evitado pelo uso de recursos cliente-premissa dedicados ou hosts de instância de monolocatário. Em algumas modalidades, os clientes podem ter hardware e/ou software para fins especiais ou proprietário que desejam usar para estágios SPS ou nós de SMS, onde as capacidades funcionais ou níveis de execução viável que utilizam esses componentes não podem ser facilmente replicadas em um fornecedor de rede, ou simplesmente não são suportados na rede do fornecedor. Um cliente pode ter acesso a um centro de dados externo para um servidor de computador com capacidades de processamento de nível de computador, por exemplo, que pode ser capaz de executar o processamento de SPS a uma taxa muito mais elevada do que seria possível com a uso dos recursos de rede de fornecedor apenas. Permitir a um cliente selecionar os destinos de posicionamento de vários nós pode permitir que tais dispositivos de propósitos especiais ou software sejam utilizados.

[094]A FIG. 12a e 12b ilustram exemplos de pedidos de opção de segurança que podem ser apresentadas pelos clientes de SPS e clientes de SMS, respectivamente, de acordo com pelo menos algumas modalidades. A FIG. 12a ilustra uma solicitação de opção de segurança de SPS 1200 em que um cliente indica, por uma ou mais etapas de processamento com identificadores 1210, os tipos de destinos de posicionamento (PDTs) solicitados para nós do estágio de controle (elemento 1212) e os PDTs solicitados para nós de trabalho (elemento 1214). Em pelo menos uma modalidade, os clientes podem também ser capazes de enviar solicitações para configurar as configurações de criptografia para seus registros de dados de fluxo ou resultados de processamento de fluxo, por exemplo, ao solicitar que os registros de dados sejam criptografados usando um algoritmo especificado ou protocolo antes da sua transmissão através de vários links de rede, ou que várias interações de controle ou administrativas sejam criptografadas. Por exemplo, na FIG. 12a, as configurações de criptografia para o estágio podem indicar técnicas de criptografia a serem aplicadas aos resultados das etapas de operações de processamento e/ou a criptografia usada para as comunicações entre os nós de controle do estágio e os nós de trabalho do estágio.

[095]Do mesmo modo, na Fig. 12b, solicitação de opção de segurança de SMS de um cliente 1250 compreende uma série de elementos que indicam preferências de segurança do cliente para um ou mais fluxos com identificadores especificados 1252.Preferências de tipo de destino de posicionamento para nós de ingestão, nós de armazenamento e nós de recuperação podem ser indicadas em elementos 1254, 1258 e 1262, respectivamente. Preferências de PDT para nós de controle de ingestão, nós de controle de armazenamento e nós de controle de recuperação podem ser indicadas por elementos 1256, 1260 e 1264, respectivamente. Preferências de criptografia para registros de dados, por exemplo, se e/ou como a criptografia deve ser implementada para os registros de dados à medida que são transmitidos a partir de uma categoria de nó para outra, podem ser indicadas através de elemento 1266. Usando pedidos de opção de segurança, tais como os mostrados na FIG. 12a e 12b, os clientes podem ser capazes de escolher os locais (por exemplo, dentro da rede do fornecedor ou externo à rede do fornecedor) e vários outros componentes do perfil de segurança para diferentes partes da sua gestão de fluxo e ambiente de processamento.

[096]Note-se que a escolha de destinos de posicionamento de nó pode ser oferecida por outras razões além de segurança em pelo menos algumas modalidades. Por exemplo, um cliente pode querer ter alguns tipos de nós de SMS ou SPS implementados em hosts de monolocatário por motivos de execução (por exemplo, para evitar os problemas de "vizinho barulhento" indicados anteriormente, em vez de principalmente por razões de segurança. Opções de posicionamento podem ser alteradas em pelo menos algumas modalidades, durante o tempo de vida de um fluxo - por exemplo, um cliente pode, inicialmente, permitir que nós de SMS sejam instanciados em hosts de instância de multilocatário, mas podem querer mover, pelo menos, um subconjunto dos nós para hosts de instância de monolocatário mais tarde. Políticas de preços diferentes podem ser aplicadas às diferentes opções relacionadas à segurança em pelo menos algumas modalidades - por exemplo, pode custar mais implementar nós de SMS de uma determinada categoria funcional em uma IVN que em hosts de instância de multilocatário fora de IVNs, ou pode custar mais implementar nós de SMS em hosts de instância de monolocatário que em hosts de instância de multilocatários. Armazenamento sequencial e recuperação de registros de fluxo

[097]Para muitos tipos de aplicações de fluxo, os registros de dados podem ser recebidos pelo SMS em taxas muito elevadas a partir de uma pluralidade de produtores de dados 120, e os consumidores de dados podem, tipicamente, desejar acessar registros de dados armazenados na ordem em que foram gerados os registros. Especialmente em ambientes nos quais discos rotativos magnéticos são usados como dispositivos de armazenamento de registros de dados de fluxo, como mencionado anteriormente, padrões de acesso sequencial de I/O (para ambas leitura e escrever) podem ter vantagens significativas de execução em relação a padrões aleatórios de acesso I/O. Em várias modalidades, os números de sequência específicos de partição ou específicos de fluxo podem ser atribuídos aos registros de dados à medida que são recebidos pelo SMS, e as operações de recuperação sequenciais com base em números de sequência podem ser suportadas. A FIG. 13a ilustra exemplo de interações entre um produtor de fluxo de dados e um subsistema de ingestão de um SMS, de acordo com pelo menos algumas modalidades. O produtor de fluxo de dados pode apresentar um registro de dados 110 para um subsistema de ingestão, e na modalidade representada, o subsistema de ingestão pode responder com um número de sequência 102, que foi escolhido para o registro apresentado. Em pelo menos algumas modalidades, um nó de ingestão pode obter uma porção do número de sequência a partir do subsistema de armazenamento - por exemplo, o número de sequência 102 pode ser determinado subsequente ao armazenamento do registro de dados recebidos em conformidade com a política de persistência aplicável em tais modalidades e o subsistema de armazenamento pode gerar um indicador de sequência numérica próprio para o registro de dados e fornecer esse indicador para inclusão no número de sequência maior atribuído ao registro de dados pelo nó de ingestão.

[098]Os números de sequência podem ser implementados em várias modalidades para fornecer uma ordenação estável e consistente de registros de dados e para permitir a iteração repetível sobre registros por consumidores de dados. Os números de sequência atribuídos aos registros de dados de uma partição específica podem aumentar monotonamente ao longo do tempo, embora eles não precisem ser consecutivos em pelo menos algumas implementações. Em várias modalidades, os números de sequência podem ser atribuídos pelo menos com um subconjunto da seguinte semântica: (A) números de sequência são únicos dentro de um fluxo, ou seja, não há dois registros de dados de um determinado fluxo a que pode ser atribuído o mesmo número de sequência; (B) os números de sequência podem servir como índices nos registros de dados do fluxo e podem ser usados para iterar sobre registros de dados dentro de uma determinada partição de fluxo; (C) para qualquer produtor de dados, a ordem em que o produtor de dados enviou com sucesso os registros de dados é refletida nos números de ordem atribuído aos registros de dados; e (d) sequência de numeração para registros de dados com um valor chave de partição determinado retém a semântica crescente de forma monótona através de operações de reparticionamento dinâmicas - por exemplo, os números de ordem atribuído a registros de dados com um valor de chave de partição K1 depois de um reparticionamento podem cada um ser maior do que qualquer um dos os números de sequência que foram atribuídos a registros de dados com esse valor chave de partição K1 antes do reparticionamento dinâmico. (Reparticionamento dinâmico é descrito em mais pormenor abaixo com respeito à FIG. 16.)

[099]Em algumas modalidades, um produtor de dados pode querer influenciar a seleção do número de sequência 102 selecionado para, pelo menos, alguns registros de dados. Por exemplo, um produtor de dados 120 pode desejar demarcar fronteiras ou separadores dentro dos números sequenciais atribuídos de um fluxo, de modo que se torna mais fácil para os consumidores de dados desse fluxo enviar solicitações de leitura destinadas aos subconjuntos particulares do fluxo. Em algumas implementações, o produtor de dados 120 pode apresentar uma indicação de um número mínimo de sequência em conjunto com um registro, e o SMS pode selecionar um número de sequência de acordo com o mínimo requerido, que também está de acordo com a semântica de número sequencial discutida acima.

[0100]A FIG. 13b ilustra exemplo de elementos de um número de sequência que pode ser gerado por um registro de dados ingeridos em um SMS, de acordo com pelo menos algumas modalidades. O número de sequência pode compreender quatro elementos na modalidade representada: um número de versão de SMS n1-bit 1302, um carimbo temporal (timestamp) de n2 bits ou valor de época 1304, um número de subsequência de n3-bit 1306 e um número de partição de n4-bit 1308. Em algumas implementações, podem ser utilizados números de sequência de 128 bits, por exemplo, N1, N2, N3 e N4 pode ser de 4, 44, 64 e 16 bits, respectivamente. O número da versão 1302 pode ser usado simplesmente para evitar confusão ao longo dos lançamentos de versão do software de SMS, por exemplo, de modo que é fácil dizer qual versão do software de SMS foi utilizada para gerar o número de sequência. Não pode ser esperado que o número de versão 1302mude frequentemente em pelo menos algumas implementações. O valor de carimbo temporal 1304 pode ser obtido, por exemplo, a partir de uma fonte de relógio local ou uma fonte de relógio globalmente acessível (por exemplo, um sistema de gestão de estado de um fornecedor de rede que implemente um getCurrentEpoch ou getCurrentTime API) por um nó de subsistema de ingestão. Em pelo menos algumas implementações, um deslocamento de um ponto bem conhecido no tempo (por exemplo, o número de segundos que se tenham decorrido desde UTC 00:00:00 em 1° de Janeiro, 1970, que pode ser obtido invocando várias chamadas tempo-relacionadas de sistema em sistemas operacionais baseados em Unix™) pode ser usado para o valor de carimbo temporal 1304. Em algumas modalidades, o número de subsequência 1036 pode ser gerado pelo subsistema de armazenamento e pode indicar a ordem na qual os registros de dados de uma partição específica são escritos em um dispositivo de armazenamento. Assim, em uma implementação em que numerosos registros de dados são recebidos dentro de um determinado segundo e os valores de carimbo temporal 1304 só mudam em intervalos de aproximadamente um segundo, os números de subsequência 1306 podem servir como indicadores da chegada do registro (ou armazenamento) para registros de dados que porventura tenham chegado no mesmo segundo e, portanto, têm atribuído o mesmo valor de carimbo temporal. O número de partição 1308 pode identificar exclusivamente uma partição dentro de um determinado fluxo em algumas modalidades. Em pelo menos algumas implementações, em que os carimbos temporais de número de sequência indicam (pelo menos aproximadamente) os tempos de relógio em que os registros de dados correspondentes foram ingeridos, os números de sequência podem ser utilizados para um mecanismo de indexação para determinados tipos de pedidos de recuperação baseados no tempo. Por exemplo, um cliente pode querer recuperar os registros de fluxo gerados ou ingeridos em um determinado dia ou durante um intervalo de tempo especificado, e os números de sequência podem ser usados como teclas de um índice secundário implícito para recuperar o conjunto apropriado de registros de dados. Assim, em pelo menos algumas modalidades, o uso de números de sequência que contêm marcas de tempo para armazenamento e recuperação ordenados pode ter um benefício adicional de fornecer um índice temporal para o conjunto de registros de dados armazenados.

[0101]Registros de dados de uma determinada partição podem normalmente ser escritos (por exemplo, no disco) em ordem de número de sequência, muitas vezes usando grandes operações de gravação sequenciais. Em algumas modalidades, como indicado anteriormente, interfaces programáticas baseadas em iterador podem ser implementadas para permitir que os consumidores de dados leiam os registros de dados na ordem do número de sequência. A FIG. 14 ilustra exemplos de armazenamento e recuperação ordenado dos registros de dados de fluxo em um SMS, de acordo com pelo menos algumas modalidades. Seis registros de dados 110A - 110F de uma partição SJ-Pk (a ka. partição de um fluxo Sj) são mostrados armazenados em ordem de número de sequência. Tal como ilustrado, os números de sequência não podem ser consecutivos em pelo menos algumas modalidades, por exemplo, por causa da maneira em que os valores são atribuídas às porções de carimbo temporal 1304 ou os números de subsequências 1306 discutidos acima podem nem sempre resultar em valores consecutivos para esses elementos.

[0102]No exemplo mostrado na FIG. 14, um consumidor de dados solicitou um iterador a ser criado, especificando um número de sequência de partida "865". Em resposta ao pedido, o SMS inicializou Iterator1, posicionado no registro de dados com o número de sequência mais próximo que é maior do que ou igual ao número de sequência de partida requerido. Neste caso, registro de dados 110C com o número de sequência 870 foi escolhido como posição de partida do iterador, já que a seguinte sequência menor (860, atribuída ao registro de dados 110B) é menor do que o número de sequência no pedido do consumidor. A interface getIterator pode ser considerada o equivalente lógico de um pedido para definir um cursor em uma posição desejada dentro da partição, e a interface getNextRecords pode ser usada para, em seguida, ler registros de dados a partir da posição do cursor, por exemplo, para mover o cursor ao longo do fluxo na ordem de número de sequência. No exemplo ilustrado, um consumidor de dados invocou a interface getNextRecords com o parâmetro "iteração" definido para Iterator1 e "maxNumRecords" (o número máximo de registros de dados para retornar) igual a 3. Consequentemente, o subsistema de recuperação de SMS retorna os registros de dados 110C, 110D e 110E nessa ordem para o consumidor de dados. O iterador Iterator1 pode ser movido para uma nova posição, por exemplo, para registro de dados 110F, após a chamada getNextRecords completar, e invocações getNextRecord subsequentes para o mesmo iterador podem retornar registros de dados começando com 110F. A semântica da chamada getIterator podem diferir em algumas modalidades - por exemplo, em vez de posicionar a iteração no registro de dados com o número de sequência mais próximo maior ou igual ao número de sequência especificado, a iteração pode ser posicionada no registro de dados mais próximo com o maior número de sequência igual ou menor do que o número de sequência requerido em algumas modalidades. Em outra modalidade, os clientes podem ter de especificar um número de sequência existente na chamada getIterator - por exemplo, um erro pode ser devolvido se um registro com o número sequencial solicitado não existe no fluxo.

Mapeamentos de partição

[0103]Conforme descrito anteriormente, a carga de trabalho relacionada com a ingestão, armazenamento, recuperação e processamento dos registros de um determinado fluxo podem ser subdivididas e distribuídas entre vários nós em várias modalidades de acordo com vários particionamento e políticas de reparticionamento. A FIG. 15 ilustra um exemplo de mapeamento de partição de fluxo 1501 e as decisões de configuração correspondentes que podem ser feitas para os nós de SPS e SMS, de acordo com pelo menos algumas modalidades. Quando um fluxo de dados em particular é criado ou inicializado, por exemplo, em resposta a invocação de um cliente de uma createStream API, uma política de particionamento pode ser ativada para o fluxo, a qual pode ser utilizada para determinar a partição da qual qualquer dado registrados de dados do fluxo deve ser considerado um membro. Os nós particulares do subsistema de ingestão 204, o subsistema de armazenamento 206, o subsistema de recuperação 208 e quaisquer estágios de SPS relevantes 215 que estão a executar operações para um dado conjunto de dados podem ser acionados com base na partição do registro. Numa modalidade, pelo menos um subconjunto dos nós de controle utilizados para um dado registro de dados pode ser acionado com base na partição também. Em pelo menos algumas modalidades, reparticionamento dinâmico de um fluxo de dados pode ser suportado, como parte da política de particionamento, por exemplo, em resposta às condições de acionamento indicadas na política ou em resposta a pedidos explícitos.

[0104]Em várias modalidades, a partição selecionada para um determinado registro de dados pode ser dependente de uma chave de particionamento para o registro, cujo valor pode ser fornecido pelo produtor de dados quer diretamente (por exemplo, como um parâmetro de uma solicitação de gravação ou venda), ou indiretamente (por exemplo, o SMS pode usar metadados, como o identificador ou nome do cliente produtor de dados, um endereço de IP do produtor de dados ou partes do conteúdo real do registro de dados como uma chave de partição). Uma ou mais funções de mapeamento 1506 podem ser aplicadas para a chave de partição de registro de dados ou atributos 1502 para determinar o identificador de partição de registro de dados 1510 na modalidade mostrada na FIG. 15. Em uma implementação, por exemplo, um dado identificador de partição 1510 pode representar um intervalo contíguo ao longo do espaço de valores inteiros de 128 bits, de modo a que a união daos intervalos para todas as partições do fluxo pode abranger todos os valores possíveis que um número inteiro de 128 bits pode assumir. Em um tal cenário de exemplo, uma função simples de mapeamento 1506 pode gerar um valor de hash de 128 bits a partir do valor(es) da chave de partição ou o valor(es) de atributo selecionados do registro de dados, e o identificador de partição pode ser determinado com base no intervalo contíguo particular dentro do qual o valor de hash por acaso está. Em algumas implementações, os intervalos contíguos podem, pelo menos inicialmente, ser iguais em tamanho; em outras implementações, partições diferentes podem corresponder a intervalos contíguos que podem diferir em tamanho uma da outra. Reparticionamento pode também resultar em adaptações dos limites do intervalo em uma implementação. Outras funções de separação 106 podem ser usadas em diferentes implementações.

[0105] Se o fluxo de dados sofre reparticionamento dinâmico (como discutido abaixo em maior detalhe), a partição para a qual registros com uma chave especial são mapeados pode mudar. Assim, em pelo menos alguns exemplos de realização, nós de controle de SMS e/ou SPS podem ter que manter o controle de vários mapeamentos diferentes que se aplicam a um fluxo durante a vida útil do fluxo. Em algumas modalidades, os metadados tais como uma faixa de validade de carimbo temporal 1511 ou uma faixa de validade de número de sequência podem ser armazenados pelos nós de controle para cada mapeamento de partição. A faixa de validade de carimbo temporal 1511 pode, por exemplo, indicar que um determinado mapeamento M1 aplica-se aos tempos da criação do fluxo até o tempo T1, que um mapeamento diferente M2 aplica-se de T1 para T2, e assim por diante. Ao responder a pedidos de leitura dirigidos a um fluxo, os nós de recuperação podem ter que primeiro determinar qual o mapeamento deve ser usado (dependendo, por exemplo, do número de sequência indicado em um pedido de leitura), e, em seguida, usar esse mapeamento para identificar os nós de armazenamento adequados.

[0106]Os nós de controle de SPS e SMS podem ser responsáveis por partições de mapeamento para recursos em várias granularidades diferentes em pelo menos algumas modalidades. Por exemplo, como mostrado no exemplo de implementações 1599 da FIG. 15, em uma aplicação, cada nó de ingestão, armazenagem, recuperação ou processamento (de trabalho) pode ser implementado como um respectivo processo ou um respectivo segmento de execução em uma máquina virtual do servidor, tais como Java™ Virtual Machine (JVM) ou uma instância de computação e cada JVM ou instância de computação pode ser instanciada em um determinado host físico. Em algumas modalidades, várias JVMs podem ser lançadas dentro de uma única instância de computação, adicionando outra camada de decisões de mapeamento de recursos. Assim, para uma determinada partição, um ou mais nós de controle podem selecionar quais recursos específicos devem ser utilizados como nós de ingestão 1515, nós de armazenamento 1520, nós de recuperação 1525 ou nós de trabalho de estágio de processamento 1530 (por exemplo, os nós 1530A ou 1530B para estágios PS1 ou PS2 respectivamente). Os nós de controle também podem determinar os mapeamentos dos nós para os servidores (como servidores de ingestão 1535, servidores de armazenamento 1540, servidores de recuperação 1545 ou servidores de processamento 1550), e os mapeamentos entre servidores e hosts (tais como hosts de ingestão 1555, hosts de armazenamento 1560, hosts de recuperação 1565 ou hosts de SPS 1570A/1570B). Em algumas implementações, um mapeamento de partição pode ser considerado compreendendo as informações de identificação (por exemplo, identificadores de recursos) em cada uma das várias granularidades de recursos (por exemplo, granularidades de nó, servidor e de host) ilustradas, uma indicação do registro de dados de atributos que estão sendo usados como entrada para a função ou funções 1506, bem como as próprias funções 1506. Os servidores de controle podem armazenar representações do mapeamento de partição numa loja de metadados, e em algumas modalidades pode expor várias APIs (tais como getPartitionInfoAPIs) ou outras interfaces de programação para fornecer a informação de mapeamento para os produtores de dados, os consumidores de dados, ou para os nós dos subsistemas de SMS ou SPS.

[0107]Os mapeamentos de registros de dados para partições, e das partições para os recursos, pode ser ainda mais complicado em algumas modalidades por vários fatores, tais como: (A) um nó de dado, servidor ou host pode ser designado responsável por várias partições em algumas modalidades, ou (b) falhas ou outras causas podem resultar em a novos nós, servidores ou hosts ser atribuído um dado conjunto de partições ou partição. Além disso, como indicado acima e abaixo descrito, os mapeamentos de partição para uma dada fracção podem ser modificados dinamicamente ao longo do tempo, enquanto os registros de transmissão continuam a ser tratado pelos nós de SMS e/ou SPS. Como resultado, várias versões de metadados de mapeamento podem ser conservadas durante um dado fluxo, pelo menos temporariamente, em algumas modalidades, cada uma correspondendo a um período de tempo diferente.

Reparticionamento de fluxo dinâmico

[0108]A FIG. 16 ilustra um exemplo de reparticionamento de fluxo dinâmico, de acordo com pelo menos algumas modalidades. No tempo T1 da linha do tempo ilustrada na FIG. 16, um fluxo S1 é criado ou inicializado. Um mapeamento de partição PM1 é criado para o fluxo S1, e permanece em vigor durante o intervalo de tempo T1 até T2. Três registros de dados recebidos por um SMS entre T1 e T2 são mostrados a título de exemplo. Registro de dados 110A (DR110A) é apresentado com um valor de chave de partição fornecido pelo cliente "Alice", DR110B é apresentado com um valor de chave de partição fornecido pelo cliente "Bill" e DR110C é apresentado com um valor de chave de partição fornecido pelo cliente "Charlie". No mapeamento inicial PM1, todos os três registros de dados 110A, 110B e 110C são mapeadas para a mesma partição com um identificador de partição "P1". Para registros de dados P1, um único nó I1 é configurado para processar a ingestão, um único nó S1 está configurado para cuidar do armazenamento, um único nó R1 é configurado para processar a recuperação e um único nó de trabalho W1 é configurado para manipular o processamento de SPS. O carimbo temporal de início para um intervalo de validade do mapeamento de PM1é definido coma T1.

[0109]No tempo T2, fluxo de S1 é repartido de forma dinâmica no exemplo de linha do tempo da FIG. 16. Registros de dados continuam a chegar e ser tratados por SMS e os SPS na modalidade representada, independentemente de quando o reparticionamento ocorre; nem o SMS nem o SPS precisam ser tomados offline. O reparticionamento pode ser iniciado como um resultado de qualquer de um número de fatores - por exemplo, em resposta a uma detecção de uma condição de sobrecarga a um nó de ingestão, armazenamento, recuperação e processamento, em resposta a uma detecção de uma inclinação ou desequilíbrio entre níveis de carga de trabalho em diferentes hosts dos vários subsistemas, ou em resposta a um pedido de um consumidor de dados ou um cliente produtor de dados. Na modalidade representada, um novo mapeamento PM2 tem efeito no tempo T2 (ou pouco depois de T2), como indicado pela configuração de carimbo temporal de intervalo de validade mostrada para PM2. Em pelo menos algumas implementações, um conjunto diferente de atributos de registro de dados pode ser usado para particionar registros de dados que foram usados antes do reparticionamento. Em alguns casos, um atributo de particionamento adicional pode ser apresentado pelo produtor dos dados (por exemplo, a pedido do SMS), enquanto em outros casos o atributo adicional pode ser gerado por um nó de ingestão de SMS. Tais atributos adicionais podem ser referidos como atributos "salgados", e a técnica de uso de atributos adicionais para reparticionando pode ser referido como "salga". Em um exemplo de implementação, um servidor de ingestão sobrecarregado pode indicar a um produtor de dados (por exemplo, com o código da biblioteca de cliente de SMS que está sendo executado pelo produtor de dados) que, por repartição, um valor inteiro pequeno selecionado aleatoriamente seja fornecido de forma adicional à chave de partição precedentemente usada. A combinação da chave de partição original e o número inteiro adicional salgado poderá ser posteriormente utilizada para distribuir a carga de trabalho de ingestão entre um conjunto diferente de nós de ingestão. Em algumas modalidades, os nós de recuperação e/ou consumidores de dados podem ter de ser informados sobre os atributos adicionais serem usados para reparticionamento. Tais atributos adicionais não podem ser utilizados para reparticionamento em pelo menos algumas implementações.

[0110]Na modalidade mostrada nas FIGS. 16, os novos mapeamentos de partição resultam em diferentes partições serem acionados para, pelo menos, alguns dos registros de dados recebidos depois de T2, em relação à partiçãoacionada para a mesma chave antes de T2. DR110P é apresentado depois de T2 com o valor de chave de partição "Alice", DR110Q é apresentado depois de T2 com o valor de chave de partição "Bill", e DR110R é apresentado depois de T2 com o valor de chave de partição "Charlie". Usando o mapeamento PM2, DR110P é designado como membro de partição "P4", DR110Q é designado como membro de partição "P5", enquanto DR110R é designado como membro de partição "P6" no cenário de exemplo ilustrado. Na modalidade representada, nenhum dos registros de dados de exemplo mostrados como sendo recebidos após T2 são designados como membros da partição anteriormente utilizado "P1"; em vez disso, partições completamente novas podem ser utilizadas após o reparticionamento. Em algumas modalidades, pelo menos algumas divisórias previamente utilizadas podem continuar a ser utilizadas depois de reparticionamento. Para cada uma das novas partições P4, P5 e P6, nós diferentes podem ser designados para ingestão, armazenamento, recuperação e/ou processamento. Por exemplo, os nós I4, S4, R4 e W4 podem ser configurados para partição P4, os nós I5, S5, R5 e P5 podem ser configurados para partição P5, e nós I6, S6, R6 e P6 podem ser configurados para partição P6. Em algumas modalidades, o mesmo nó de armazenamento pode ser utilizado para um registro com uma chave de partição específica ou atributo após reparticionamento como foi utilizado para tais registros antes de repartição, mas num local diferente de armazenamento dentro desse nó (por exemplo, um outro disco, um disco diferente de partição, ou um diferente SSD) pode ser usado depois do reparticionamento.

[0111]Durante pelo menos algum período de tempo após o reparticionamento dinâmico em T2, solicitações de recuperação podem continuar a ser recuperadas para registros de dados que foram processados pela ingestão de SMS e/ou subsistemas de armazenamento antes do reparticionamento. Em pelo menos alguns casos, os registros de dados solicitados podem ter de ser retirados com base no mapeamento de PM1 que estava em vigor no momento em que os registros de dados foram ingeridos. Por conseguinte, como indicado na FIG. 16, para efeitos de recuperação de dados, tanto PM1 e PM2 podem continuar a ser utilizados durante algum tempo depois de T2. Em pelo menos algumas implementações, registros de dados podem, eventualmente, ser excluído do fluxo à medida em que envelhecem, e os mapeamentos de partição mais velhos também podem ser descartados, eventualmente, por exemplo, quando todos os registros de dados correspondentes foram excluídos. Em algumas realizações, em vez de (ou antes) de serem apagados, registros de fluxo podem ser arquivados (por exemplo, com base em políticas de arquivamento selecionadas pelo cliente) para um conjunto diferente de locais de armazenamento ou dispositivos, de tal forma que os mapeamentos de partição usados pelo SMS podem ainda ser utilizáveis para recuperar os registros depois de arquivamento. Em tais modalidades, os mapeamentos de partição, como PM1 e PM2, podem ser retidos durante o tempo em que eles são necessários para apoiar solicitações de recuperação direcionadas para o armazenamento de arquivos. Em algumas implementações de arquivo, diferentes abordagens de recuperação podem ser utilizadas que não exigem os mapeamentos de partição fluxo que devem ser retidos (por exemplo, novos índices podem ser criados para os registros de dados arquivados). Em algumas modalidades uma partição tal como P2 que estava a ser utilizada antes de uma repartição, mas para a qual gravações não são dirigidas após a repartição, pode, em algum ponto depois do reparticionamento, ser "fechada" para leituras - por exemplo, o equivalente a uma mensagem de erro "final da partição atingido" pode ser fornecido em resposta a pedidos de recuperação.

[0112]Em algumas implementações, um dado fluxo de dados pode ser dividido em numerosas (por exemplo, centenas ou milhares) partições. Considere um caso de exemplo em que um fluxo S1 é inicialmente dividido em partições 1000, P1, P2, ..., P1000. No caso de uma condição de sobrecarga correspondente a uma partição, por exemplo P7, é detectada, pode ser útil alterar o mapeamento inicial de registros de dados para P7, mas os mapeamentos das outras partições não precisam ser alterados. Numa abordagem, duas novas partições P1001 e P1002 podem ser criadas através de uma operação de reparticionamento. Registros recebidos após a repartição, cujos atributos teriam inicialmente (isto é, sobre a base do mapeamento original) resultado na sua filiação em P7, podem ser mapeados para qualquer P1001 ou P1002 após a repartição, distribuindo assim a carga de trabalho de P7 entre duas partições. As partições restantes, por exemplo, P1 - P6 e P8 - P1000, talvez não precisem de modificação. Uma vez que apenas um pequeno subconjunto de partições é afetado por uma tal repartição, pelo menos em algumas modalidades uma estrutura de dados combinada, como um gráfico acíclico dirigido de entradas de partição (ou uma árvore de entradas de partição), pode ser gerada e armazenada. Cada entrada pode indicar um intervalo de saída função de particionamento, e um intervalo de tempo de validade (o período de tempo durante o qual as informações de particionamento da entrada deve ser considerado válido). Suponha, no exemplo acima, que o reparticionamento envolvendo P7 foi realizado no momento T2, enquanto que o fluxo S1 (e seu mapeamento inicial) foi criado no momento T1. Em tal cenário, o período de tempo de validade para a entrada quanto a P7 seria "T1 Tot2", os períodos de tempo de validade para P1001 e P1002 seriam "T2 em diante", e os períodos de tempo de tempo de validade para as partições restantes seria "T1 em diante ". Usar uma tal estrutura de dados combinada pode levar a uma redução substancial na quantidade de memória ou armazenamento utilizada para mapeamento de metadados de partição em pelo menos algumas implementações. No exemplo acima, foi discutida uma divisão de partição P7 em duas novas partições. Em pelo menos algumas implementações, partições também podem ser mescladas durante reparticionamento - por exemplo, duas partições adjacentes para as quais foram recebidas relativamente poucas solicitações de recuperação, ou relativamente poucos registros foram submetidos, podem ser fundidas em uma única partição. Para qualquer ponto no tempo, a partição à qual um registro de dados pertence pode ser determinada de forma inequívoca através da função de particionamento e as informações de intervalo de tempo de validade. Com o tempo, a estrutura de dados combinada pode evoluir à medida que mais divisões e/ou fusões são realizadas, mas o espaço total necessário para os metadados de particionamento pode (dependendo do curso sobre a frequência com que ocorrem divisões, e quantas partições são afetadas pelas divisões em média ) não aumentar dramaticamente. Em contraste, numa implementação diferente, cada vez que um reparticionamento ocorre, todo o conjunto de metadados inalterados para um fluxo pode ser replicado e combinado com entradas para as partições afetadas por reparticionamento. Os requisitos de armazenamento e memória para metadados de mapeamento de partição pode aumentar a uma taxa muito mais rápida na última aplicação, especialmente se os mapeamentos mais velhos podem ter que ser mantidos durante, pelo menos, algum tempo depois de reparticionamento como descrito acima.

[0113]Em pelo menos algumas modalidades nas quais números de sequência que compreendem os valores de carimbo temporal (tais como o valor de carimbo temporal 1304 mostrado na FIG. 13b) são usados, um tipo especial de transição de sequência de número pode ser implementada para reparticionamento dinâmico. Suponha por exemplo que um esquema de números de sequência com base em carimbo temporal, semelhante ao mostrado na FIG. 13b, está sendo usado para um fluxo S1, em que novos valores de carimbo temporal são gerados a cada segundo para inclusão nos números de sequência. Em pelo menos algumas implementações em que reparticionamento dinâmico é suportado, os números de ordem atribuídos após o reparticionamento dinâmico podem todos usar um conjunto diferente de valores de carimbo temporal (começando com um valor de carimbo temporal inicial selecionado correspondente ao evento de repartição) do que foi usado antes do reparticionamento dinâmico. Por exemplo, se o valor de carimbo temporal em uso no momento que o reparticionamento dinâmico está comprometido (isto é, pôr em prática) foi Tk, todos os novos números de sequência emitidos após a confirmação podem ser obrigados a usar valores de carimbo temporal Tk+1 em diante. Uma vez que os valores de número de sequência codificam o valor de carimbo temporal em pelo menos alguns dos seus bits de ordem mais elevada no esquema usado na FIG. 13b, assegurar que os eventos de reparticionamento correspondem aos limites de carimbo temporal conforme descritos por sua vez pode simplificar a contabilidade envolvida na identificação dos mapeamentos que serão utilizados em resposta a um pedido de recuperação. Assim, em tais implementações, quando um pedido de recuperação especificando um número de sequência em particular é recebido, o valor de carimbo temporal pode ser extraído do número de sequência, e pode ser facilmente determinado se o mapeamento de pós-reparticionamento deve ser utilizado ou o mapeamento de pré-reparticionamento deve ser usado. Se o valor de carimbo temporal extraído é mais baixo do que o carimbo temporal inicial selecionado para a repartição, o mapeamento de pré-reparticionamento pode ser utilizado, e se o valor de carimbo temporal extraído é igual a ou maior do que o valor de carimbo temporal inicial selecionado para a repartição, o mapeamento de pós-reparticionamento pode ser utilizado.

Métodos de gestão e processamento de fluxo

[0114]A FIG. 17 é um diagrama de fluxo que ilustra os aspectos das operações que podem ser realizadas para suportar conjuntos respectivos de interfaces programáticas para a ingestão de registro de fluxo e recuperação de registro de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 1701, um pedido para criar ou inicializar um fluxo de dados pode ser recebido, por exemplo, a partir de um cliente SMS ou de um cliente produtor de dados. O mapeamento de partição inicial a ser utilizado para o fluxo pode ser determinado (elemento 1704), por exemplo, a(s) função(ões) que devem ser usadas para identificar a partição a que um registro de dados em particular pertence, e os parâmetros de entrada a serem utilizados para a função(ões), podem ser identificados com base numa política de particionamento. Como mencionado anteriormente, os componentes de controle de SMS podem ser responsáveis por receber e responder às solicitações de criação de fluxo em várias modalidades. A maneira pela qual o fluxo de criação e inicialização (bem como outras operações de plano controle) é aplicada podem variar de uma modalidade para outra. Numa modalidade, por exemplo, um grupo de redundância de servidores de controle pode ser estabelecido, e o servidor de controle primário do referido grupo de redundância pode responder a um pedido de criação de fluxo para gerar e armazenar os metadados adequados para um novo fluxo (por exemplo, o mapeamento de partição inicial, os conjuntos iniciais de nós da ingestão, armazenamento e recuperação, e assim por diante) em um local de armazenamento persistente. As respostas a consultas posteriores sobre o fluxo (por exemplo, um pedido de um nó ingestão de front-end sobre o nó de back-end responsável por uma dada partição) podem ser geradas pelo servidor de controle primário usando os metadados armazenados. Numa outra execução da funcionalidade do plano de controle de SMS, metadados de configuração de fluxo podem ser armazenados numa base de dados que é diretamente acessível por, pelo menos, alguns nós dos subsistemas de ingestão, armazenamento ou recuperação. Depois de um fluxo ser criado e inicializado, as operações de plano de dados, tais como registro de submissão, armazenamento e recuperação podem começar, e podem ser geridas por componentes respectivos dos subsistemas correspondentes, normalmente sem interações adicionais com os componentes de controle.

[0115]Em algumas modalidades, os produtores de dados podem ser obrigados a apresentar chaves de partição explícitas com pedidos de gravação, enquanto que em outras modalidades, as entradas que serão utilizadas para as funções de partição podem ser determinadas com base nos metadados associados com os pedidos de gravação, tais como a identidade do produtores de dados, os endereços de IP a partir dos quais os registros de dados são recebidos, ou a partir do conteúdo dos próprios registros de dados. Em pelo menos uma aplicação os clientes podem, opcionalmente, fornecer identificadores de partição nas submissões de registro de dados e funções de particionamento adicionais podem não ser necessárias em tal implementação.

[0116]Um número de diferentes fatores pode ser tido em conta na determinação ou configuração do conjunto inicial de nós para funções de ingestão, armazenamento e recuperação para o fluxo (elemento de 1707). Por exemplo, o mapeamento de partição em si (que pode determinar em quantas partições o fluxo é dividido e os tamanhos relativos esperados das partições), informações sobre as taxas de ingestão esperadas e/ou taxas de recuperação, se essas informações estão disponíveis, requisitos de durabilidade/persistência para os registros de dados de fluxo e/ou requisitos de alta disponibilidade para os vários subsistemas (que podem resultar na criação de grupos de redundância semelhantes aos ilustrados na FIG. 9 e 10) podem influenciar o número e colocação dos nós dos diferentes subsistemas. Além disso, em modalidades em que os clientes possam indicar as preferências do tipo de destino de posicionamento para várias categorias de nós (como ilustrado na FIG. 11, 12a e 12b), tais preferências podem também desempenhar um papel na determinação dos recursos a serem utilizados para os nós de SMS e/ou SPS. Em pelo menos algumas modalidades, respectivos grupos de nós capazes de executar funções de ingestão, armazenamento e/ou recuperação podem ser configurados com antecedência, e componentes de controle podem atribuir membros selecionados de tais pools para cada novo fluxo que é criado. Em outras modalidades, pelo menos em alguns casos novos nós de ingestão, armazenamento ou recuperação podem ter que ser instanciados quando o fluxo é criado ou inicializado.

[0117]Nos nós de ingestão na modalidade representada, os registros podem ser recebidos através de qualquer um de um conjunto de interfaces de programação implementadas para apresentação de registro de dados (elemento 1710), incluindo, por exemplo interfaces de apresentação em linha (em que os dados estão incluídos nos pedidos de envio) e interfaces de apresentação por referência (em que um endereço é fornecido nos pedidos de envio, a partir do qual os dados podem ser recuperados pelos nós de ingestão de SMS ou os nós de armazenamento de SMS, por exemplo, usando solicitações de serviços web ou outras interfaces). Qualquer um de uma série de diferentes tipos de interfaces de programação podem ser fornecidos em modalidades diferentes para cada uma das formas de registros que apresentem, por exemplo, respectivas interfaces de programação de aplicativos (APIs) podem ser suportadas por submissão de referência em linha versus por-referência, páginas da web ou websites podem ser estabelecidos, interfaces gráficas de usuário podem ser implementadas ou ferramentas de linha de comando podem ser desenvolvidas. Em pelo menos algumas modalidades, o SMS pode atribuir um número de sequência para cada registro ingerido, por exemplo, indicativo da ordem pela qual os registros são ingeridos ou armazenados, e os números de sequência podem ser úteis para solicitações de recuperação de consumidores de dados. Nos nós de subsistema de recuperação, as solicitações de recuperação de registros podem ser recebidas através de qualquer de um conjunto de interfaces de recuperação programáticas implementadas e conteúdos dos registros de dados solicitados podem ser fornecidos em resposta (elemento 1713). Para o acesso não sequencial, as interfaces podem incluir, por exemplo, getIterator (solicitando uma iteração a ser instanciada numa posição selecionada dentro de uma partição com base num número de sequência indicado na invocação getIterator) ou getRecordWithSequenceNumber (para obter um registro de dados com um número de sequência especificado). Para o acesso sequencial, interfaces, como getNextRecords (solicitando um número de registros em ordem a partir de uma posição atual de um iterador ou a partir de um número de sequência especificado) podem ser implementadas. Em pelo menos algumas modalidades, diferentes interfaces de recuperação podem ter taxas de faturamento diferentes associadas a elas - por exemplo, as taxas de faturamento por registro para recuperação sequencial podem ser definidas mais baixas do que as taxas de faturamento por registro para recuperação não sequencial. As interfaces de submissão diferentes também podem ter diferentes taxas de faturamento em algumas modalidades - por exemplo, submissões por referência podem custar mais por registro do que submissões em linha.

[0118]Com o tempo, nós de controle ou servidores de faturamento especializados podem coletar métricas de uso para as diferentes interfaces programáticas implementadas nos vários subsistemas do serviço de gestão de fluxo (elemento 1716). As métricas podem incluir, por exemplo, as contagens de invocação de diferentes interfaces de programação, o número total de registros ingeridos ou recuperados (que podem ser diferentes contagens de invocação para pelo menos algumas interfaces, tais como getNextRecords que podem ser utilizadas para recuperar múltiplos registros com uma única invocação), a quantidade total de dados ingeridos ou recuperados, e assim por diante. Montantes de faturamento que devem ser cobrados aos clientes que possuem o fluxo, ou clientes que produzem e/ou consumem dados do fluxo, podem opcionalmente ser gerados com base, pelo menos em parte, nas métricas de uso e as respectivas taxas de cobrança associadas com as interfaces programáticas (elemento 1719). Em pelo menos algumas modalidades, as atividades de faturação podem ser assíncronas em relação às operações de recuperação/de processamento de fluxo - por exemplo, uma fatura pode ser gerada no final de um período de faturação mensal baseado nas métricas recolhidas durante o mês.

[0119]A FIG. 18a é um diagrama de fluxo que ilustra aspectos de operações que podem ser executadas para configurar os estágios de processamento de fluxo (SPS), de acordo com pelo menos algumas modalidades. Como mostrado no elemento 1801, interfaces programáticas podem ser implementadas permitindo que os clientes configurem um número de estágios de processamento de registros de dados de fluxo. Para configurar um estágio particular, por exemplo, um cliente pode indicar a operação(ões) de processamento a ser executada em registros de dados de fluxo particionado no estágio, a política de distribuição para a saída das operações de processamento, assim como outros parâmetros tais como a identidade dos fluxos de entrada a partir da qual os dados a serem processados devem ser obtidos. Em algumas modalidades, as operações de processamento em estágios de SPS podem ser obrigadas a ser idempotentes. Em outras modalidades, as operações não- idempotentes também podem ser suportadas por pelo menos alguns estágios. Se o processamento a ser realizado num determinado estágio é não-idempotente, um cliente pode ainda ser capaz de obter benefícios relacionados com recuperação de idempotência em algumas modalidades, configurando os nós de trabalho a descarregar periodicamente a saída das operações para um local externo persistente, gravando quando as operações de descarga foram realizadas no que diz respeito à sequência de recuperação de registro, e mais tarde configurar os nós de trabalho de substituição para repetir as operações de descarga durante a recuperação. Em pelo menos algumas modalidades, os clientes podem ser capazes de configurar grafos dirigidos acíclicos (DAGs) ou outros gráficos de estágios de processamento, com vários estados diferentes operando em dados de fluxo em paralelo, e os resultados de alguns estágios sendo usado como fluxos de entrada para outros estágios. Em algumas modalidades, um ou mais fluxos efêmeros em vez de persistentes podem ser criados entre diferentes estágios, por exemplo, a saída de registros de dados a partir de uma fase não tem necessariamente de ser armazenada em dispositivos de armazenamento persistente antes de ser alimentada como entrada para um estágio diferente.

[0120]Qualquer uma de uma série de diferentes políticas de recuperação pode ser implementada por fases SPS em algumas modalidades, incluindo, por exemplo, uma política de recuperação baseada em ponto de verificação ou uma política de recuperação de melhor esforço. Em uma modalidade, um cliente pode usar uma interface de programação para selecionar as políticas de recuperação para as diferentes fases de SPS. Em fases para as quais a recuperação baseada em ponto de verificação é usada, nós de trabalho podem ser configurado para armazenar registros de progresso ou pontos de verificação em intervalos, indicando quão longe em uma partição de fluxo eles foram (por exemplo, os números de sequência dos registros processados mais recentemente podem ser armazenados como indicadores do progresso). Os registros de progresso podem ser utilizados mais tarde durante as operações de recuperação após falhas, como descrito abaixo com referência à FIG. 19. Em uma política de recuperação de melhor esforço, registros de progresso não precisam ser armazenados e nós de trabalho de substituição configurados em resposta a uma falha podem simplesmente processar novos registros de dados à medida em que são recebidos. Dentro de um dado gráfico de estágio de SPS ou fluxo de trabalho, em algumas modalidades diferentes políticas de recuperação podem ser aplicadas a diferentes fases.

[0121]Um servidor de controle de SPS pode receber, por exemplo, através de uma das interfaces de programação indicadas no elemento 1801, uma indicação da operação idempotente Op1 a ser realizada em um determinado estágio PS1 de um fluxo S1 de acordo com uma política de particionamento PPol1, com os resultados do processamento a serem distribuídos de acordo com o descritor de distribuição de saída DDesc1 (elemento 1804). O número de nós de trabalho a serem configurados para estado PS1, e os recursos virtuais ou físicos necessários para os nós, podem ser determinados, por exemplo, com base em vários fatores, tais como o Ppol1, a complexidade das operações idempotentes Op1, e as capacidades de execução dos recursos a serem utilizados para os nós de trabalho (elemento 1807).

[0122]Os nós de trabalho podem então ser instanciados e configurados (elemento 1810), por exemplo, como processos ou threads em recursos de máquinas virtuais ou físicas selecionados. Numa modalidade simples, por exemplo, um nó de trabalho pode, inicialmente, ser atribuído para cada partição de S1. Um dado nó de trabalho pode ser configurado para (a) receber registros de dados do subconjunto adequado dos nós de recuperação de S1, (b) realizar Op1 nos registros de dados recebidos, (c) opcionalmente, por exemplo, com base na política de recuperação para PS1, armazenar registros de progresso/pontos de validação indicando quais conjuntos de registros de partição foram processados, e (d) transmitir a saída para destinos indicados por DDesc1 (por exemplo, como entradas para fluxos persistentes ou efêmeros intermediários, ou diretamente para outros estágios de processamento ou sistemas de armazenamento). Note-se que pelo menos em algumas modalidades, o processamento de SPS pode não necessariamente gerar nenhuma saída que tem de ser transmitida em outro lugar numa base contínua. Por exemplo, alguns aplicativos SPS podem simplesmente servir como repositórios temporários de registros de dados, e/ou podem implementar interfaces de consulta que permitem aos usuários visualizar os registros de dados. Esse pedido pode gerir a sua própria produção, por exemplo, a saída pode ser gerada em resposta a consultas recebidas e não de acordo com um descritor de distribuição. Um aplicativo SPS log-relacionado pode manter registros de log do último dia colhidos a partir de um sistema distribuído em larga escala, por exemplo, permitindo que os clientes vejam os dados de registro para fins de depuração ou análise. Por conseguinte, em algumas modalidades, os descritores de distribuição de saída não necessitam ser especificados para pelo menos algumas fases de um SPS, pelo menos para alguns fluxos ou para pelo menos algumas partições. Os nós de trabalho podem, em seguida, iniciar a recuperação e registros de processamento de dados de acordo com suas respectivas definições de configuração (elemento 1813). Os nós de controle de SPS podem monitorar o estado de saúde (por exemplo, usando verificações de resposta tais como um protocolo de batimento cardíaco) dos nós de trabalho, bem como várias outras métricas, como os níveis de uso de recursos nos recursos que estão sendo utilizados para os nós de trabalho (elemento 1816 ) em pelo menos algumas modalidades. A informação colhida a partir dos nós de trabalho podem ser usadas para determinar se um limite de falha é necessário, por exemplo, se um nó de trabalho deve ser substituído e uma política de recuperação implementada como descrito abaixo.

[0123]Em algumas modalidades, uma biblioteca de cliente instalável SPS pode ser fornecida para os clientes que desejam implementar nós de trabalho de SPS nas instalações de propriedade do cliente e/ou em recursos selecionados pelo cliente da rede do fornecedor. A biblioteca de cliente também pode permitir aos clientes de SPS selecionar a medida em que eles desejam usar vários recursos do plano de controle de um serviço gerenciado por SPS, tais como funções de vigilância da saúde, carga de trabalho automatizado de monitoramento e balanceamento, gerenciamento de segurança, reparticionamento dinâmico e similares. A FIG. 18b é um diagrama de fluxo que ilustra aspectos das operações que podem ser executadas em resposta às invocações de componentes de uma biblioteca de cliente para a configuração dos nós de trabalho de processamento de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 1851, uma biblioteca de cliente de SPS pode ser fornecida (por exemplo, através de download a partir de um web site de um serviço gerenciado por SPS de multilocatários configurável para executar os tipos de operações ilustradas na FIG. 18a). A biblioteca pode incluir um número de componentes executáveis e/ou componentes que podem ser ligados aos pedidos dos clientes. Alguns componentes da biblioteca podem permitir aos clientes selecionar, registrar com o serviço gerenciado por SPS, ou especificar propriedades desejadas, vários nós de trabalho nos quais fluem as operações de tratamento de um ou mais estágios de SPS devem ser executados. Por exemplo, um cliente pode querer usar seu próprio conjunto de instâncias de computação implementadas em um serviço de computação virtual de uma rede de fornecedor para os nós de trabalho, enquanto outro cliente pode querer usar dispositivos de computação localizados no próprio centro de dados do cliente (como dispositivos de uso especial não suportados pelo fornecedor de rede) para registros de fluxo de processamento. Os clientes podem trazer nós de trabalho on-line em uma base como necessária nas suas próprias instalações, ou usar instâncias de computação do serviço de computação virtual, como desejado. Além disso ou em vez de tal instanciação sob demanda de nós de trabalho, em algumas realizações clientes podem pré-configurar pools de potencialmente reutilizáveis nós de trabalho que podem ser implantados quando necessário. Em algumas implementações, um componente de biblioteca pode ser executado ou invocado para permitir que um cliente se registre, com o serviço gerenciado por SPS, um processo em particular ou segmento instanciado pelo cliente como um nó de trabalho de uma etapa especificada, para que as operações do plano de controle subsequentes possam ser tratadas pelo serviço de gestão de SPS. Em uma modalidade, o cliente pode também ser capaz de selecionar entre diferentes níveis de responsabilidades do plano de controle a ser tratado pelo serviço gerenciado por SPS para os nós dos de trabalho - por exemplo, um cliente pode querer usar os seus próprios módulos personalizados para monitorar saúde de nó de trabalho, enquanto outro cliente pode querer usar o serviço gerenciado por SPS para monitorar a saúde do nó de trabalho e tomar as medidas adequadas no caso de uma falha ser detectada.

[0124]O serviço gerenciado por SPS pode receber uma indicação de que um determinado cliente deseja usar a biblioteca de cliente para configurar nós de trabalho e/ou operações de plano de controle de um determinado estágio de SPS PS1 (elemento 1854). (PS1 ele próprio pode ser projetado usando interfaces programáticas incluídas na biblioteca, ou usando interfaces programáticas expostas pelo serviço gerenciado por SPS semelhante à interface baseada na web ilustrada na FIG. 4.) O cliente pode também indicar os fluxos cujos dados devem ser recuperados para uso como entrada por PS1. Opcionalmente, em pelo menos algumas modalidades, o cliente pode indicar as definições do plano de controle para PS1, por exemplo, se o cliente deseja usar os recursos de monitoramento de saúde do serviço para os nós, ou está disposto a usar ferramentas de monitoramento de saúde personalizadas (elemento 1857). Dependendo das preferências indicadas pelo cliente, um ou mais nós de SMS e/ou SPS a serem configurados para o uso do cliente podem ser determinados (elemento 1860). A conectividade de rede pode ser estabelecida entre os nós de trabalho do cliente para os nódulos de SMS/SPS e/ou outras operações de configuração podem ser realizadas para possibilitar o fluxo dos registros de dados e os resultados de processamento como desejado. Os registros de dados podem ser fornecidos aos nós de trabalho de SP1 após o recebimento de solicitações de recuperação e operações de plano de controle desejadas (se algum foi solicitado pelo cliente) pode ser realizado conforme necessário. Foi observado que, pelo menos em algumas modalidades, uma abordagem similar que possibilita que os clientes controlem a extensão em que eles desejam usar a funcionalidade do plano de controle de vários subsistemas de um serviço de gerenciado por SMS também pode ou em vez disso ser implementada.

[0125]A FIG. 19 é um fluxograma que ilustra aspectos das operações que podem ser executados para implementar uma ou mais políticas de recuperação para processamento de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 1901, um nó de controle de SPS pode determinar que os critérios de desencadeamento para a substituição de um nó de trabalho particular foram atendidos - por exemplo, o nó de trabalho pode ter ficado sem resposta ou insalubre, os níveis de carga de trabalho do nó atual podem ter atingido um valor de limite para falhas, o número de erros detectados no nó de trabalho pode ter excedido o limite ou algum outro estado inesperado de um nó de trabalho pode ser identificado. Um nó de trabalho de substituição pode ser identificado ou instanciado (elemento 1904). Em algumas modalidades, um pool de threads de trabalho disponíveis pode ser criado, a partir do qual um pode ser selecionado como um substituto, por exemplo, um novo thread ou processo pode ser iniciado.

[0126]Se uma política de recuperação de melhor esforço tiver de ser usada no estágio de SPS em que o nó de trabalho particular estava ativo (conforme determinado no elemento 1907), o nó de trabalho substituto pode simplesmente começar a processar os registros de dados adicionais na medida em que se tornam disponíveis (elemento 1916) , por exemplo, nenhum registro de progresso do nó de trabalho substituído precisa ser examinado. Se uma política de recuperação à base de checkpoint tiver de ser usada, uma indicação do local (por exemplo, um endereço de um dispositivo de armazenamento ou URL) em que o nó de trabalho substituto pode acessar os registros de progresso armazenados pelo nó de trabalho substituído pode ser fornecida (elemento 1910). O nó de trabalho de substituição pode recuperar o registro de progresso mais recente armazenado pelo nó substituído e usar o registro de progresso para determinar o conjunto de registros de dados em que o nó de trabalho de substituição deve realizar as operações idempotentes do estágio (elemento 1913). Nessa política de recuperação à base de checkpoint, dependendo da duração entre o último registro de progresso e o momento em que o nó de trabalho de substituição é instanciado, bem como da taxa em que o nó de trabalho substituído processou registros adicionais subsequentes ao registro de progresso que está sendo armazenado, alguns registros de dados podem ser processados mais de uma vez. Se as operações que estão sendo realizadas forem idempotentes, essas operações de repetição podem não ter efeitos negativos em pelo menos algumas modalidades. Após o nó de trabalho de substituição ter realizado as operações de recuperação de repetição com base no registro de progresso anteriormente armazenado, em pelo menos algumas modalidades, o thread de trabalho de substituição pode armazenar seu próprio registro de progresso indicando que a recuperação é completa, e pode iniciar as operações normais do thread de trabalho nos registros de dados recém- recebidos (elemento 1916).

[0127]A FIG. 20 é um fluxograma que ilustra aspectos de operações que podem ser executados para implementar uma pluralidade de opções de segurança para fluxos de dados, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 2001, uma ou mais interfaces programáticas podem ser implementadas que permitam que os clientes selecionem várias opções de segurança para o gerenciamento e processamento de fluxo de dados inclusive, por exemplo, opções de tipo de destino de colocação para os nós de categorias funcionais diferentes (por exemplo, nós de ingestão, armazenamento, recuperação, processamento ou controle). Os tipos de destino de colocação podem diferir uns dos outros em vários aspectos de seus perfis de segurança. A localização física dos recursos a serem utilizados para os nós de SMS ou SPS pode diferir de um tipo de destino para outro em algumas modalidades. Por exemplo, recursos como hosts de instância localizados em centros de dados de rede do fornecedor podem ser utilizados para os nós ou recursos em instalações de propriedade do cliente podem ser utilizadas ou recursos de terceiros podem ser utilizados. Os níveis de isolamento de rede ou outras características de rede podem diferir de um tipo de destino para outro em pelo menos algumas modalidades - por exemplo, alguns nós de SMS ou SPS podem ser instanciados em redes virtuais isoladas ou em instalações de propriedade do cliente conectadas à rede do fornecedor via links físicos isolados dedicados. Em uma modalidade, os clientes podem indicar que certos tipos de nós de SMS ou SPS devem ser estabelecidos em hosts de instância de uma rede de monolocatário de uma rede do fornecedor, em vez de usar hosts de instância de multilocatários que também podem estar disponíveis. Em pelo menos algumas modalidades, vários tipos de opções de encriptação também podem ser selecionados através de interfaces programáticas relacionadas à segurança.

[0128]As escolhas ou preferências do perfil de segurança de um cliente em relação aos nós de uma ou mais categorias funcionais para um fluxo S1 podem ser recebidas através das interfaces programáticas relacionadas à segurança. Por exemplo, o cliente pode selecionar um perfil de segurança para nós de da categoria funcional FC1 (por exemplo, o cliente pode querer implementar nós de trabalho de SPS nas dependências de propriedade do cliente) e um perfil de segurança diferente para nós de uma categoria funcional diferente FC2 (por exemplo, o cliente pode querer implementar nós ingestão de SMS ou nós de armazenamento nos centros de dados de rede do fornecedor) (elemento 2004). Em alguns casos, um cliente pode decidir criar nós de todas as categorias funcionais diferentes com o mesmo perfil de segurança. O SMS e/ou SPS pode definir tipos de destino de colocação padrão para as várias categorias funcionais em algumas modalidades - por exemplo, a menos que um cliente indique o contrário, os nós de todas as categorias funcionais podem ser configurados em redes virtuais isoladas de uma rede de fornecedor.

[0129]Os nós de categorias funcionais diferentes podem então ser configurados com base nas preferências do cliente para perfis de segurança e/ou locais (ou com base em configurações padrão para as categorias funcionais para as quais o cliente não fornece preferências) (elemento 2007). A configuração pode envolver, por exemplo, a seleção de hosts ou máquinas físicas apropriadas e instanciamento de instâncias de computação adequadas, máquinas virtuais, processos e/ou threads para os nós de categorias funcionais diferentes e estabelecimento de conexões de rede apropriadas entre os nós. Em algumas modalidades, os componentes da biblioteca executáveis para funções diferentes de gerenciamento e processamento de fluxo podem ser fornecidos para a instalação em hosts externos à rede do fornecedor como parte da configuração.

[0130]De acordo com pelo menos algumas modalidades, os módulos de criptografia podem ser ativados em uma ou mais categorias de nós, por exemplo, de acordo com preferências de criptografia expressas do cliente ou com base em configurações de criptografia padrão (elemento 2010). Os nós de categorias funcionais diferentes podem então ser ativados, de modo que os dados do fluxo sejam ingeridos, armazenados, recuperados e/ou processados como desejado pelo cliente (elemento 2013).

[0131]A FIG. 21 é um fluxograma que ilustra aspectos de operações que podem ser executados para implementar uma política de particionamento para fluxos de dados, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 2101, uma política de particionamento pode ser determinada para um fluxo de dados. A política pode compreender, por exemplo, um mapeamento inicial de registros de dados para partições com base em chaves fornecidas pelos produtores de dados ou com base em vários atributos dos registros de dados submetidos, bem como um ou mais critérios de desencadeamento para reparticionar o fluxo de dados. Em algumas modalidades, por exemplo, uma função hash pode ser aplicada à chave ou chaves de partição, obtendo-se um valor de hash inteiro de 128 bits. O intervalo de possíveis números inteiros de 128 bits pode ser dividido em subintervalos contíguos N, sendo que cada um representa partições N do fluxo. O número de partições e/ou tamanhos relativos de subintervalos podem variar de um fluxo para outro em algumas modalidades. Em pelo menos algumas modalidades, o cliente, em cujo nome um fluxo está sendo configurado pode fornecer dados referentes ao esquema de particionamento a ser usado, por exemplo, o número de partições desejado, ou características desejadas da função de particionamento a ser usada. Em pelo menos uma modalidade, os clientes podem fornecer identificadores de partição ou nomes para algum subconjunto ou todos os registros de dados submetidos.

[0132]Na medida em que os registros de dados do fluxo são recebidos, suas partições respectivas podem ser determinadas com base nas chaves e/ou outros atributos fornecidos e o conjunto apropriado de nós de ingestão, nós de armazenamento e nós recuperação pode ser selecionado para a partição identificada (elemento 2104). Em pelo menos algumas modalidades, os números de sequência respectivos podem ser gerados para os registros de dados, por exemplo, indicativos da sequência em que os registros de uma determinada partição foram recebidos (elemento 2107). Os números de sequência podem compreender uma série de elementos em algumas implementações, como os valores do carimbo temporal (por exemplo, número de segundos decorridos desde epoch bem conhecido como 00:00:00 UTC 1° de janeiro de 1970), valores de subsequência obtidos de um subsistema de armazenamento, números de versão do software de SMS e/ou identificadores de partição. Os números de sequência podem ser fornecidos aos produtores de dados em algumas modalidades, por exemplo, para reconhecer a ingestão bem-sucedida dos registros de dados submetidos. Os números de sequência também podem ser utilizados pelos consumidores de dados para recuperar os registros de dados de um fluxo ou de uma partição na ordem da ingestão em algumas modalidades.

[0133]Os registros de dados podem ser armazenados na ordem de número de sequência em pelo menos algumas modalidades nos nós de armazenamento para os quais eles são direcionados com base na política de particionamento (elemento 2110). Em modalidades em que os dispositivos de armazenamento de discos magnéticos rotativos são usados, escritas sequenciais podem ser normalmente usadas para salvar os registros de dados recebidos pelo disco evitando, assim, latências de busca do disco. Em pelo menos algumas implementações, tampões não- voláteis podem ser usados como caches de escrita antes de armazenar os registros no disco, por exemplo, para diminuir ainda mais a probabilidade de buscas do disco. Em resposta às solicitações de leitura de registros de dados múltiplos ordenados pelo número sequencial (por exemplo, invocações de getNextRecords ou interfaces similares), os registros de dados podem ser lidos posteriormente usando leituras sequenciais dos dispositivos de armazenamento (elemento 2113).

[0134]A FIG. 22 é um diagrama de fluxo que ilustra aspectos das operações que podem ser executadas para implementar reparticionamento dinâmico dos fluxos de dados, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 2201, uma determinação pode ser realizada (por exemplo, um componente de SMS ou SPS) que um fluxo deve ser repartido dinamicamente. Um número de condições de desencadeamento diferentes pode conduzir a uma decisão de repartição de um fluxo, como detecção de sobrecarga em um ou mais nós de ingestão, armazenamento, recuperação, processamento ou controle ou uma detecção de um desequilíbrio nos níveis de carga de trabalho de diferentes nós, ou uma solicitação de reparticionamento que pode ser recebida de um cliente (por exemplo, um produtor de dados ou consumidor de dados). As solicitações de repartição do cliente podem incluir detalhes específicos da repartição solicitada em algumas implementações, como vários parâmetros do mapeamento modificado a ser gerado (por exemplo, o número de partições a ser adicionado ou removido, cujas partições específicas devem ser combinadas ou divididas e assim por diante). Numa implementação, uma solicitação de repartição do cliente pode indicar um estado de problema (como um desequilíbrio de carga) que o cliente deseja resolver e o SMS ou SPS pode ser responsável por traduzir a descrição do estado de problema na operação de repartição apropriada. Em alguns casos, em vez de solicitar uma repartição ou a descrição de um estado de problema, um cliente pode especificar os critérios desencadeantes a serem usados para a repartição. A determinação de uma alteração no requisito de durabilidade de dados do fluxo de dados pode desencadear a repartição em algumas modalidades que pode, por exemplo, resultar na seleção de um conjunto diferente de dispositivos de armazenamento ou tecnologia de armazenamento diferente para os registros do fluxo. A detecção de uma mudança para um padrão de uso do fluxo de dados (por exemplo, a taxa em que os registros de dados estão sendo produzidos ou consumidos) também pode resultar na repartição em alguns casos e também pode resultar no uso de uma técnica de armazenamento diferente ou de um conjunto diferente de dispositivos de armazenamento que é mais adequado para o padrão de uso alterado. Por exemplo, uma decisão de repartição pode se basear na determinação de que, para a taxa de leituras e escritas esperada para uma dada partição ou um fluxo completo, SSDs pode ser uma tecnologia de armazenamento mais apropriada do que os discos magnéticos rotativos. As mudanças de versão de software e/ou hardware programadas ou iminentes podem desencadear a repartição em uma modalidade. Em alguns casos, preocupações relativas a preços e faturamento podem desencadear a repartição, como quando um cliente indica uma restrição de orçamento que pode ser atendida com mais eficácia usando uma abordagem de partição diferente ou uma abordagem para armazenamento diferente. As metas de execução alteradas também podem desencadear a repartição em pelo menos algumas modalidades. Na modalidade representada na FIG. 22, um valor de carimbo temporal inicial (como um deslocamento em segundos de 00:00:00 UTC 1° de janeiro de 1970, um valor epoch normalmente disponível através de uma chamada de sistema em vários sistemas operacionais) a ser usado para os números sequenciais atribuídos após a repartição pode ser selecionado (elemento 2204). Em algumas implementações, um gerente de estado global implementado em uma rede do fornecedor podem dar suporte ao API getEpochValue, por exemplo, permitindo que vários componentes de SMS e/ou SPS obtenham valores de carimbo temporal consistentes para que sejam usados para geração de número sequencial. Em outras implementações, podem ser utilizadas outras fontes de tempo - por exemplo, um nó de controle de SMS ou SPS pode ser designado para fornecer valores de carimbo temporal consistentemente ordenados para outros componentes ou uma invocação de chamada de sistema local pode ser usada. Em algumas modalidades, os valores de carimbo temporal não precisam corresponder necessariamente ao tempo do relógio em qualquer host particular - por exemplo, um valor de contador inteiro monotonamente crescente pode ser simplesmente utilizado.

[0135]Um mapeamento de partição modificado, diferente do mapeamento em uso no momento da decisão de repartição, pode ser gerado para o fluxo (elemento 2207). O mapeamento modificado pode mapear registros de dados com uma chave de partição particular para uma partição diferente dos registros de dados com a mesma chave que foram mapeados antes da repartição em pelo menos algumas modalidades. Algumas partições (normalmente, partições muito usadas) podem ser divididas, enquanto outras partições (normalmente menos usadas) podem ser mescladas, dependendo das condições desencadeantes para o reparticionamento e/ou das métricas da carga de trabalho observadas. Uma função de particionamento diferente pode ser usada após o reparticionamento do que antes do reparticionamento em algumas modalidades - por exemplo, uma função hash diferente ou uma abordagem diferente para a subdivisão dos resultados da função hash em partições pode ser usada. Em algumas implementações, por exemplo, em que as partições correspondem a intervalos contíguos de inteiros de 128 bits, o espaço inteiro de 128 bits pode ser dividido em um conjunto diferente de subintervalos após o reparticionamento. Em pelo menos algumas modalidades, novos conjuntos de nós de ingestão, armazenamento, recuperação, processamento ou controle podem ser atribuídos às partições recém-criadas. Em algumas implementações, uma estrutura de dados combinada eficiente-espaço pode ser utilizada para representar tanto o mapeamento inicial quanto o mapeamento modificado (elemento 2208). Por exemplo, uma estrutura de árvore ou gráfico acíclico direcionado pode ser armazenada, em que cada entrada contém uma indicação de um intervalo de saída da função de particionamento (por exemplo, o intervalo dos resultados de uma função hash de particionamento que correspondem a uma determinada partição) e um intervalo de tempo de validade, de modo que apenas os registos correspondentes às partições modificadas precisem ser alterados como um resultado de um reparticionamento. As entradas para partições que permanecem inalteradas durante o reparticionamento podem não precisar ser modificadas na estrutura de dados. Os novos nós podem ser configurados para implementar o mapeamento da partição modificado (elemento 2210). Em pelo menos algumas modalidades, uma vez que as solicitações de recuperação para registros de dados armazenados na base do mapeamento anterior possam continuar sendo recebidas por pelo menos algum tempo, os nós anteriores e o mapeamento anterior podem ser mantidos por algum tempo. Quando uma solicitação de leitura especificando um número sequencial particular ou carimbo temporal for recebida (elemento 2213), pode ser determinado (por exemplo, em um nó de controle ou em um nó de recuperação) se a solicitação de leitura deve ser satisfeita usando o novo mapeamento de partição ou o mapeamento de partição anterior. O mapeamento selecionado pode então ser utilizado para identificar o nó de armazenamento adequado a partir do qual os dados solicitados devem ser obtidos.

[0136]A FIG. 23 é um diagrama de fluxo que ilustra aspectos das operações que podem ser executadas para implementar um uma política de ingestão de registro do tipo pelo-menos-uma-vez para registros de fluxo de dados, de acordo com pelo menos algumas modalidades. Como mostrado no elemento de 2301, uma ou mais interfaces programáticas podem ser implementadas para permitir que os clientes selecionem uma política de ingestão de registro para um fluxo de dados dentre várias opções de políticas de ingestão, incluindo, por exemplo (a) uma política pelo menos uma vez de acordo com a qual um requerente do registro deve submeter um registro uma ou mais vezes até que uma confirmação positiva seja recebida ou (b) uma política de ingestão em melhor esforço de acordo com a qual as confirmações não são fornecidas em pelo menos algumas submissões de registro. Alguns clientes que produzem dados podem não apresentar tantas preocupações com a perda potencial de uma pequena fração de seus registros como outros e, portanto, podem optar pela abordagem da ingestão de melhor esforço. Em algumas implementações, mesmo para fluxos configurados para ingestão de melhor esforço, o SMS pode fornecer ainda confirmações por algum subconjunto dos registros de dados, ou pode até mesmo tentar fornecer confirmações para todos os registros de dados, mesmo que a política de melhor esforço não exija confirmações para todos os registros de dados.

[0137]A solicitação pode ser recebida através de uma das interfaces programáticas, indicando uma política de ingestão particular a ser utilizada para um fluxo especificado (elemento 2304). Os nós de ingestão podem ser instanciados de acordo com a política de particionamento em vigor para o fluxo (elemento 2307). Quando uma ou mais submissões do mesmo registro de dados forem recebidas em um nó de ingestão (elemento 2310), diferentes ações podem ser tomadas dependendo da política de ingestão em vigor. Se a política de ingestão pelo menos uma vez estiver em uso (como determinado no elemento 2313), uma confirmação pode ser enviada ao produtor de dados para uma ou mais submissões, mas o registro de dados pode ser salvo apenas uma vez no subsistema de armazenamento (2316). (Note-se que, de acordo com as políticas de persistência em vigor para o fluxo, N réplicas de um determinado registro podem ser armazenadas em alguns casos, mas se um determinado registro de dados for submetido M vezes, as réplicas podem ser geradas apenas para uma das submissões - ou seja, o número total de réplicas armazenadas do registro ainda seria N, e não NxM) Se uma política ingestão de melhor esforço estava em vigor (como detectado também no elemento 2313), o registro de dados ainda pode ser salvo uma vez em um dispositivo de armazenamento, mas nenhuma confirmação precisa de ser enviada ao produtor de dados (elemento 2319). Em pelo menos algumas modalidades, os montantes do faturamento do cliente podem ser, opcionalmente, determinados com base, pelo menos em parte, na política de ingestão selecionada (elemento 2322). Como observado anteriormente, em algumas modalidades, duas versões de uma política de ingestão pelo menos uma vez podem ser suportadas. Em uma versão, similar à ilustrada na FIG. 23, o SMS pode ser responsável pelos registros de dados de de- duplicação (ou seja, assegurando que os dados sejam armazenados no subsistema de armazenamento de SMS em resposta a um único conjunto de duas ou mais submissões). Em uma versão diferente da ingestão pelo menos uma vez, a duplicação dos registros de dados por SMS pode ser permitida. A última abordagem pode ser útil para aplicações de fluxo em que existem poucas ou nenhuma consequência negativa da duplicação do registro de dados e/ou aplicações do fluxo que realizam sua própria eliminação de duplicados.

[0138]A FIG. 24 é um diagrama de fluxo que ilustra aspectos de operações que podem ser executados para implementar uma pluralidade de políticas de persistência para fluxos de dados, de acordo com pelo menos algumas modalidades. Como mostrado no elemento de 2401, uma ou mais interfaces programáticas que permitem que os clientes selecionem uma política de persistência para registros de dados de fluxo dentre uma pluralidade de políticas de persistência podem ser implementadas. As políticas de persistência podem diferir uma da outra em vários aspectos: p.ex., (a) o número de réplicas que devem ser salvas pode ser diferente (p.ex., N réplica vs. 2 réplicas vs. políticas de réplica única podem ser suportadas) (b) tipos de local/dispositivo de armazenamento que devem ser usados podem diferir (por exemplo, disco magnético rotativo vs. SSD vs. RAM vs. serviço de banco de dados ou serviço de armazenamento multilocatário) e/ou (c) as políticas podem diferir na extensão prevista de resiliência a falhas em grande escala (por exemplo, políticas do centro de multidados vs. políticas do centro de dados únicos podem ser suportadas). Uma solicitação pode ser recebida pela indicação da seleção, pelo cliente, de uma política de persistência particular para um fluxo especificado (elemento 2404). Em algumas modalidades, a política de persistência selecionada por um cliente pode resultar na uso de diferentes tipos de locais de armazenamento ou tipos de dispositivo para as respectivas partições de um dado fluxo. Em uma modalidade, o SMS, em vez do cliente, pode selecionar o tipo de local de armazenamento ou os tipos de dispositivo, tanto ao nível do fluxo quanto no nível da partição. Os clientes podem indicar metas de durabilidade de dados e/ou metas de execução (como leitura desejada ou taxa de transferência da escrita ou latência) em algumas modalidades ao selecionar a política de persistência em algumas modalidades e essas metas podem ser usadas por SMS para selecionar os tipos de dispositivos de armazenamento ou locais adequados. Por exemplo, se latências baixas forem desejadas, SSDs pode ser usado ao invés de girar discos magnéticos para armazenar os registros de dados de uma ou mais partições ou fluxos.

[0139]Um conjunto de nós de ingestão pode ser determinado ou configurado para receber os registros de dados do fluxo selecionado dos produtores de dados, e um conjunto de nós de armazenamento pode ser configurado para implementar a política de persistência selecionada (elemento 2407). Quando um registro de dados é recebido em um nó de ingestão (elemento 2410), uma ou mais cópias do registro de dados podem ser armazenadas, com base na política de persistência selecionada, em dispositivos de armazenamento selecionados pelos nós de armazenamento responsáveis pela partição à qual o registro de dados recorde pertence (elemento 2413). Em pelo menos algumas implementações, os montantes do faturamento podem ser, opcionalmente (e/ou de maneira assíncrona) determinados com base nas políticas de persistência selecionadas pelo cliente (elemento 2416). Gerenciamento de carga de trabalho descentralizada para processamento do fluxo

[0140]Em algumas modalidades, uma parte substancial ou a totalidade das funcionalidades do plano de controle de um SPS pode ser implementada de uma forma descentralizada, por exemplo, pelos nós de trabalho em um dado estágio de SPS coordenando várias operações de controle (como atribuição de partição aos nódulos de trabalho, respostas ao reparticionamento dinâmico, monitoramento saudável e/ou equilíbrio de carga) através de uma estrutura de dados compartilhados como uma tabela de banco de dados. Um determinado nó de trabalho W1 pode inspecionar as entradas na estrutura de dados compartilhados para determinar, por exemplo, que as partições dos fluxos de entrada do estágio (se houver) não estão sendo processadas atualmente. Se uma partição P1 for encontrada, W1 pode atualizar uma entrada na estrutura de dados compartilhados para indicar que W1 irá executar as operações de processamento do estágio os registros P1. Outros nós de trabalho podem aprender que W1 é atribuído para processar registros P1 e, portanto, podem atribuir partições diferentes para si mesmos. Os nós de trabalho podem, periodicamente, ou ocasionalmente, enviar consultas ao controle de plano de SMS para determinar os mapas de partição atuais em vigor para o fluxo de entrada e atualizar a estrutura de dados compartilhados para indicar mudanças de mapa (por exemplo, como resultado de reparticionamento), se necessário. O equilíbrio de carga e outras operações também podem ser coordenadas através da estrutura de dados compartilhados em várias modalidades, conforme descrito abaixo. Em algumas implementações descentralizadas, os nós de controle dedicados podem não ser necessários para SPS reduzindo, assim, a sobrecarga necessária para implementar fluxos de trabalho de SPS. Essas implementações do plano de controle de SPS descentralizado podem ser especialmente populares com usuários conscientes do orçamento que utilizam bibliotecas do cliente de SPS para implementar vários aspectos do processamento de fluxo, p.ex., instâncias de computador na rede do fornecedor que são atribuídas aos consumidores ou em locais fora da rede do fornecedor. As técnicas do plano de controle de SPS descentralizadas também podem ser utilizadas em modalidades em que as bibliotecas do cliente não são usadas, por exemplo, quando todos os recursos usados para SMS e SPS são configurados na rede do fornecedor. Um SPS em que os nós de trabalho implementam algumas ou todas as funções do plano de controle de SPS para, pelo menos, alguns estágios do processamento pode ser referido neste documento como um "SPS de controle descentralizado".

[0141]A FIG. 25 ilustra um exemplo de um sistema de processamento de fluxo, em que os nós de trabalho de um estágio de processamento coordenar as suas cargas de trabalho usando uma tabela de banco de dados, de acordo com pelo menos algumas modalidades. Em SPS de controle descentralizado 2590, dos estágios 215A e 215B são definidos, cada um com um conjunto respectivo de nós de trabalho. O estágio 215A compreende nós de trabalho 2540A e 2540B, enquanto que no estágio 415B compreende nós de trabalho 2540K e 2540L. Para cada estágio 215A e 215B, uma tabela de atribuição de partição correspondente (PA) 2550 é criada em um serviço de banco de dados 2520, como tabela de PA 2550A para estágio 215A e tabela de PA 2550B para estágio 215B. A tabela de PA 2550 para um dado estágio pode ser criada durante a inicialização do estágio em algumas modalidades, por exemplo, em resposta a uma invocação de um componente ou função da biblioteca do cliente. Cada tabela de PA 2550 pode ser preenchida com um conjunto inicial de entradas ou linhas que representam partições não atribuídas dos fluxos de entrada do estágio (ou seja, partições às quais nenhum nó de trabalho é atualmente atribuído). Colunas ou atributos exemplares das entradas da tabela de PA são apresentados na FIG. 26 e descrito abaixo. Os nós de trabalho 2540 (por exemplo, processos ou threads lançados em instâncias de computação ou outros servidores) que são lançados para o estágio podem conceder acesso de leitura/escrita à tabela de PA do estágio. As leituras e escritas direcionadas às tabelas PA dos nós de trabalho estão representadas na FIG. 25 pelas setas 2564A, 2564B, 2564K e 2564L para nós de trabalho 2540A, 2540B, 2540K e 2540L respectivamente.

[0142]Um determinado nó de trabalho 2540 pode ser configurado para selecionar, pela análise das entradas na tabela de PA, uma partição particular em que executa operações de processamento do estágio. Em uma implementação, o nó de trabalho 2540A pode verificar as entradas na tabela de PA 2550A até encontrar uma entrada de uma partição não atribuída Pk e poder tentar atribuir a partição Pk a si mesmo pela atualização da entrada, por exemplo, pela inserção do identificador do nó de trabalho em uma das colunas da entrada. Essa inserção pode ser considerada análoga ao bloqueio da partição pelo nó de trabalho. Dependendo do tipo de serviço de banco de dados a ser utilizado, diferentes abordagens para gerenciar escritas potencialmente simultâneas às entradas da tabela de PA (por exemplo, por dois ou mais nós de trabalho que identificam uma partição não atribuída quase ao mesmo tempo) pode ser usada.

[0143]Em uma modalidade, um serviço de banco de dados multilocatário não- relacional de uma rede do fornecedor pode ser usado, o qual suporta uma consistência forte e operações de escrita condicionais sem necessariamente dar suporte à semântica da transação do banco de dados relacional. Uma operação de escrita condicional pode ser utilizada no caso de atualizações pelos nós de trabalho. Considere um exemplo em que uma coluna de "ID-nó-trabalho" é usado para indicar o identificador do nó de trabalho particular atribuído a uma partição na tabela de PA, e que o valor da coluna é definido como "nulo" se nenhum nó de trabalho for atribuído à partição. Nesse cenário, um nó de trabalho com identificador WID1 pode solicitar o equivalente lógico do disposto a seguir: "Se, na entrada para partição Pk, ID-nó- trabalho for nulo, então definir ID-nó-trabalho para aquela entrada em WID1". Se essa solicitação de escrita condicional for bem-sucedida, o nó de trabalho com identificador WID1 pode presumir que partição Pk é atribuída a ele. O nó de trabalho pode, então, iniciar a recuperação dos registros de dados da partição Pk, por exemplo, o uso de interfaces de recuperação de registro do subsistema de recuperação SMS 206, conforme indicado pelas setas 2554 (por exemplo, setas 2554A, 2554B, 2554K e 2554L para nós de trabalho 2540A, 2540B, 2540K e 2540L respectivamente), e execução das operações de processamento nos registros recuperados. Se a escrita condicional falhar, o nó de trabalho pode retomar a busca por uma partição não atribuída diferente. Em outras modalidades, os serviços do banco de dados (como banco de dados relacional) que suportam transações podem ser utilizados, e a funcionalidade da transação pode ser utilizada para implementar o equivalente das operações de escrita condicional - por exemplo, para garantir que apenas uma de uma pluralidade de tentativas simultâneas (ou quase simultâneas) de atribuir uma partição para um nó de trabalho tenha êxito, e que os nós de trabalho envolvidos nessas tentativas simultâneas são seguramente informados de seu sucesso ou fracasso. As técnicas de sincronização que não se baseiam nem nas escritas condicionais nem no suporte de transação podem ser utilizadas em algumas modalidades. Em algumas implementações, um serviço de banco de dados não pode ser utilizado; em vez disso, um serviço de bloqueio pode ser usado pelos nós de trabalho para obter acesso exclusivo às atualizações das entradas nas estruturas de dados persistentes análogas às tabelas de PA.

[0144]Outros nós de trabalho 2540 podem examinar as entradas na tabela de PA, determinar quais partições são não-atribuídas e pode, eventualmente, ter sucesso na atribuição de uma ou mais partições para eles mesmos. Desta forma, a carga de trabalho de processamento para as partições do fluxo ou fluxos de entrada do estágio podem, eventualmente, ser distribuídos entre si pelos nós de trabalho do estágio.

[0145]O mapeamento da partição inicial de qualquer fluxo pode mudar ao longo do tempo, por exemplo, como um resultado das operações reparticionamento dinâmico descrito anteriormente. Por conseguinte, na modalidade representada na FIG. 25, um ou mais dos nós de trabalho 2540 podem ocasionalmente (ou em resposta a condições desencadeantes descritas abaixo) submeter solicitações para o subsistema de controle de SMS 210 dos fluxos de entrada do seu estágio para obter metadados de partição atuais. Em algumas implementações, essas solicitações podem compreender invocações de APIs do plano de controle de SMS, como invocações de API getStreamInfo indicadas pelas setas 2544A, 2544B, 2544K e 2544L. O subsistema de controle de SMS pode, por exemplo, responder a uma lista atualizada de partições do fluxo e/ou outros detalhes, como os prazos de validade das partições. Se as informações de partição fornecidas pelo subsistema de controle de SMS 210 não coincidirem com as entradas na tabela de PA, a tabela de PA pode ser modificada pelo nó de trabalho, por exemplo, pela inserção ou exclusão de entradas para uma ou mais partições. Essas solicitações 2554 ao subsistema de controle de SMS podem ser, tipicamente, muito menos frequentes do que as solicitações de recuperação de registro 2554 (e/ou operações de leitura ou escrita do banco de dados 2564) em pelo menos algumas modalidades, conforme indicado pela etiqueta "pouco frequente" da seta 2554A. Por exemplo, uma vez que uma partição é atribuída, um nó de trabalho pode, normalmente, manter a recuperação e processamento dos registros de dados de partição até que os dados de partição sejam totalmente consumidos (por exemplo, se o proprietário do fluxo fechar o fluxo, ou se a partição for fechada em decorrência do reparticionamento dinâmico) ou até que alguma outra circunstância baixa probabilidade seja encontrado (por exemplo, se um nó de trabalho diferente pedir uma transferência de partição devido ao desequilíbrio de carga detectado, conforme discutido abaixo). Assim, a sobrecarga associada à invocação de getStreamInfo ou APIs similares pode, normalmente, ser muito pequena em várias modalidades, mesmo se uma quantidade substancial de informação for fornecida em resposta a qualquer invocação (como pode ser o caso se a centenas ou milhares de partições forem definidas para o fluxo de entrada do estágio).

[0146]Algumas operações de gerenciamento de carga de trabalho principais de um ambiente de SPS de controlo descentralizado podem, assim, ser resumidas como se segue na modalidade representada na FIG. 25: (a) seleção, baseada, pelo menos em parte, no caso à tabela do banco de dados pelo primeiro nó de trabalho de um estágio de processamento de fluxo, uma partição particular de um fluxo de dados de entrada do estágio de processamento do fluxo em um conjunto de operações de processamento definidas para esse estágio é implementado; (b) escrita, em uma entrada particular armazenada na tabela, de um indicador de uma atribuição da partição particular ao primeiro nó de trabalho; (c) recuperação, pelo primeiro nó de trabalho, dos registros da partição particular usando interfaces programáticas de recuperação de registro implementadas em um serviço de gerenciamento de fluxo multilocatário; (d) implementação, pelo primeiro nó de trabalho, do conjunto de operações de processamento nos registros da partição particular; (e) determinação, por um segundo nó de trabalho, com base, pelo menos em parte, na entrada particular na tabela do banco de dados, a do primeiro nó de trabalho é atribuída para executar o conjunto de operações de processamento na partição particular; e (f) seleção, pelo segundo nó de trabalho, de uma partição diferente na qual o conjunto de operações de processamento é executado. Se e quando um nó de trabalho determinar que nenhum registro permanece em uma partição atribuída a ele, o nó de trabalho pode solicitar metadados no fluxo de entrada do subsistema de controle de SMS e pode atualizar a tabela de PA se os metadados indicarem uma discrepância.

[0147]A FIG. 26 ilustra exemplos de entradas que podem ser armazenadas em uma tabela de atribuição de partição 2550 usada para a coordenação da carga de trabalho, de acordo com pelo menos algumas modalidades. Como mostrado, a tabela 2550 pode compreender quatro colunas: coluna do identificador de partição 2614, coluna do identificador do nó de trabalho atribuído 2618, coluna do indicador de saúde do nó de trabalho 2620 e coluna do indicador do nível de carga de trabalho 2622. Outros conjuntos de colunas podem ser implementados em outras implementações - por exemplo, uma coluna que indica um tempo de criação de partição ou um intervalo de valor de saída da função de particionamento pode ser utilizado em algumas modalidades ou a coluna do indicador do nível de carga de trabalho não pode ser usada.

[0148]Note-se que a lista de partição 2650 mantida pelo subsistema de controle de SMS (por exemplo, como parte da árvore de entrada de partição, gráfico ou outra estrutura de dados combinada descrita anteriormente) pode, pelo menos em alguns momentos, incluir mais partições que estão incluídas na tabela de PA 2550 em algumas modalidades. No exemplo representado, a lista de partição 2650 inclui partições P1, P2, P3, P4 e P5, das quais P1 e P4 são mostradas em um estado fechado como resultado do reparticionamento, enquanto que P2, P3 e P5 são mostradas como ativas (ou seja, partições cujos registros de dados estão sendo atualmente recuperados e processados). A tabela de PA 2650 inclui entradas para partições ativas na modalidade representada e não inclui entradas para as partições fechadas (que podem ter sido excluídas pelos nós de trabalho quando eles obtiveram respostas às invocações do getStreamInfo após a ocorrência do reparticionamento, por exemplo). Pelo menos em algumas implementações, nem todas as partições atualmente abertas do fluxo podem ter necessariamente entradas respectivas na tabela de PA em um determinado momento; em vez disso, por exemplo, apenas um subconjunto dessas partições que é atualmente atribuído ou que está sendo processado pode ser representado.

[0149]No cenário exemplar ilustrado na FIG. 26, as partições P1 e P2 são atribuídas aos nós de trabalho com identificadores W7 e W3, respectivamente, enquanto que P5 é atualmente não atribuído. A coluna do indicador de saúde 2620 pode armazenar diferentes tipos de valores em diferentes implementações. Em algumas implementações, os nós de trabalho podem ser responsáveis por atualizar periodicamente (por exemplo, uma vez a cada N segundos, ou de acordo com um cronograma baseado em um conjunto de heurísticas) o conteúdo das colunas do indicador de saúde nas entradas de PA de suas partições designadas atribuídas para indicar que os nós de trabalho estão ativos e são capazes de continuar suas operações de recuperação e processamento. Na FIG. 26, uma indicação do tempo mais recente que o nó de trabalho para essa entrada atualizou a coluna do indicador de saúde ("modificação-mais-recente") pode ser armazenada - por exemplo, de trabalho W7 é mostrado como tendo modificado a entrada às 02:24:54 e 53 segundos em 1°de dezembro de 2013. Outros nós de trabalho podem usar o valor da modificação mais recente para determinar se o nó de trabalho atribuído é saudável ou não em algumas modalidades - por exemplo, se X segundos ou minutos se passaram, conforme definido em uma política de falha para o estágio, pode ser presumido que o nó de trabalho atribuído é insalubre ou inacessível e a partição pode ser reatribuída. Em outras implementações, um contador pode ser usado como um indicador de saúde (por exemplo, se o valor de contador não mudou em Y segundos, o nó de trabalho atribuído pode ser considerado um candidato a falha), ou um valor da "leitura-mais- recente" indicando quando o nó de trabalho atribuído leu pela última vez a entrada pode ser usado.

[0150]Em pelo menos algumas modalidades, um valor do indicador do nível de carga de trabalho 2622 pode ser armazenado na entrada, por exemplo, pelo nó de trabalho atribuído, como o número de registros processados durante algum intervalo de tempo recente (por exemplo, cinco minutos antes da modificação-mais-recente), métricas relacionadas ao execução recente do nó de trabalho, como a uso da CPU, uso de memória, a uso do armazenamento e similares. Esses valores do indicador de nível da carga de trabalho podem ser utilizados em algumas modalidades pelos nós de trabalho para determinar se existem desequilíbrios de carga, conforme descrito abaixo em relação à FIG. 29, e para tomar medidas em resposta aos desequilíbrios detectados. Por exemplo, um nó de trabalho Wk pode determinar que o seu nível de carga de trabalho está acima do nível de carga de trabalho médio e pode cancelar a atribuição de uma de suas partições ou pode solicitar um reparticionamento dinâmico; alternativamente, o nó de trabalho Wk pode determinar se a sua carga de trabalho está muito baixa em relação à de outros nós de trabalho ou partições e pode atribuir partições adicionais a si mesmo. Assim, usando as colunas da tabela de PA indicadas na FIG. 26, os nós de trabalho podem executar alguns dos mesmos tipos de funções do plano de controle na modalidade representada que podem ser tipicamente executados pelos nós de controle de SPS dedicados nas implementações de SPS de controle centralizado.

[0151]A FIG. 27 ilustra aspectos das operações que podem ser executadas pelos nós de trabalho de um estágio de processamento de fluxo para selecionar as partições nas quais realizar as operações de processamento, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 2701, uma tabela de PA PAT1 pode ser inicializada em um serviço de banco de dados para um estágio de processamento de SPS de controle descentralizado SP1. A tabela pode ser criada, por exemplo, quando um componente da biblioteca de clientes de SPS for invocado, por exemplo, de um host em uma instalação do cliente ou de uma instância de computação em um centro de dados da rede do fornecedor. A biblioteca do cliente pode ser usada para vários fins: por exemplo, para fornecer um componente executável como arquivo JAR (arquivo de Java™) para as operações de processamento particulares a serem implementadas no estágio de SPS, indicar um marcador (como um nome de programa, um nome de processo ou um nome de instância de computação ) que pode ser usado para identificar os nós de trabalho, indicar o fluxo a ser usado como a entrada para o estágio para indicar os destinos de saída (se houver) do estágio e assim por diante. A PAT1 pode, inicialmente, ser preenchida em algumas modalidades com entradas ou linhas para, pelo menos, um subconjunto das partições {P1, P2, ...} definido para os fluxos de entrada do estágio. Em algumas implementações, a tabela pode ficar vazia inicialmente, e um ou mais nós de trabalho podem preencher a tabela com linhas para partições não atribuídas, por exemplo, como um resultado da obtenção de metadados de partição de um subsistema de controle de SMS. Um conjunto inicial de nós de trabalho {W1, W2, ...} pode ser iniciado, por exemplo, em várias instâncias de computação em uma rede de fornecedor ou nos dispositivos de computação de propriedade do cliente (elemento 2704). Pode ser concedido acesso de escrita e leitura aos nós de trabalho da PAT1 na modalidade representada.

[0152]Como os nós de trabalho ficam on-line, eles podem acessar PAT1 para tentar encontrar partições sem atribuição. Por exemplo, o nó de trabalho W1 pode analisar PAT1 e constatar que a partição P1 não foi atribuída (elemento 2707). W1 pode, então, atualizar a entrada de P1 em PAT1, por exemplo, usando uma solicitação de escrita condicional ou uma solicitação de atualização transacional dependendo do tipo de serviço do banco de dados que está sendo usado, para indicar que P1 é atribuída a W1 (elemento 2710). Após a atualização da tabela, W1 pode iniciar a recuperação dos registros de dados de P1 usando interfaces do subsistema de recuperação de SMS (elemento 2713) e pode executar operações de processamento do estágio PS1 nos registros recuperados.

[0153]Enquanto isso, em algum momento, um nó de trabalho diferente W2 pode acessar PAT1 em sua própria tentativa de encontrar partições não atribuídas (elemento 2716). W2 pode determinar, com base na atualização anterior de W1, se P1 já está atribuída, mas que uma partição diferente P2 não está atribuída. Em algumas modalidades, uma determinação do W2 de que o nó de trabalho atribuído atual de P2 é insalubre ou inativo (por exemplo, com base na coluna do indicador de saúde na entrada de P2) também pode levar W2 a selecionar P2. Assim, em pelo menos algumas modalidades, tanto um estado não atribuído quanto uma determinação de um estado insalubre de um nó de trabalho atual pode ser utilizado para selecionar uma dada partição para reatribuição (ou atribuição inicial).W2 pode então tentar atualizar PAT1 para atribuir P2 para si mesmo (elemento 2719). Se a atualização for bem-sucedida, W2 pode começar a recuperar os registros de P2 usando interfaces de recuperação de SMS (elemento 2722) e executando operações de processamento adequadas definidas para o estágio.

[0154]Como mencionado anteriormente, os nós de trabalho em um SPS de controle descentralizado podem obter informações de mapeamento de partição (normalmente com pouca frequência) de SMS e usar essas informações para atualizar a tabela de PA, se necessário. A FIG. 28 ilustra os aspectos das operações que podem ser executadas por nós de trabalho de um estágio de processamento de fluxo para atualizar uma tabela de atribuição de partição com base nas informações obtidas a partir de um subsistema de controle de serviço de gerenciamento de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 2801, durante a inicialização do nó de trabalho ou em resposta a várias condições desencadeantes como o fechamento de uma das partições que lhe são atribuídas, o nó de trabalho W1 pode submeter uma solicitação ao subsistema de controle de SMS para obter a lista de partição atual ou mais recente ou a lista de partição ativa. Em algumas implementações, um getStreamInfo ou API similar pode ser invocado para este fim. Outras condições desencadeantes podem ser usadas em algumas modalidades: por exemplo, os nós de trabalho podem ser configurados para obter listas de partição novas após quantidades aleatórias de tempo, ou em resposta a quedas ou aumentos inesperados nos níveis da carga de trabalho. A lista de partições devolvida por SMS pode ser comparada com as entradas da tabela de PA para a partição (elemento 2807). Se uma discrepância for constatada (por exemplo, se houver alguma partição na lista partição recém-obtida que não esteja na tabela de PA, ou se houver uma entrada na tabela de PA que não está na lista de SMS), o nó de trabalho pode inserir ou excluir entradas na tabela de PA para resolver a discrepância na modalidade representada (elemento 2810). (Pode ser necessária coordenação adicional se uma entrada que é direcionada para exclusão tiver atualmente um nó de trabalho atribuído em algumas implementações - por exemplo, o nó de trabalho atribuído pode ser notificado diretamente ou por meio da própria tabela de PA).

[0155]Após a discrepância ser corrigida ou caso nenhuma discrepância seja detectada, o nó de trabalho W1 pode selecionar um conjunto de partições nas quais as operações de processamento do estágio deveriam ser executadas (elemento 2813) e, por conseguinte, pode atualizar a tabela de PA. Em alguns casos, dependendo da condição desencadeante que resultou na recuperação da lista de partição, W1 já pode ter uma ou mais partições atribuídas a ele e pode não precisar fazer alterações em suas atribuições nem atualizar a tabela de PA. O W1 pode então proceder para recuperar os registros de dados de sua partição ou partições atribuídas e processar os registros, sem ter que interagir com o subsistema de controle de SMS ou alterar o número de entradas na tabela de PA (elemento 2816).Eventualmente, quando uma condição desencadeante é detectada (por exemplo, quando o equivalente a uma resposta "final da partição atingido" for recebida para uma solicitação de recuperação, indicando que a uma partição é fechada), W1 pode enviar novamente uma solicitação ao subsistema de controle de SMS para obter informações de partição novas e as operações dos elementos 2801 em diante podem ser repetidas.

[0156]A FIG. 29 ilustra aspectos das operações de balanceamento de carga que podem ser realizadas pelos nós de trabalho de um estágio de processamento de fluxo, de acordo com pelo menos algumas modalidades. Como mostrado no elemento 2901, um nó de trabalho W1 pode determinar que uma análise de equilíbrio de carga deve ser realizada no seu estágio após a detecção de qualquer uma dentre várias condições desencadeantes, como a detecção de um nível elevado de uso de recursos ou com base em um cronograma configurável. O W1 pode analisar as entradas na tabela de PA (elemento 2904) para determinar várias métricas da carga de trabalho para o estágio. Essas métricas podem incluir o número médio de partições atribuídas aos nós de trabalho, ao nível médio de carga de trabalho dos nós de trabalho ou de partições diferentes (nas modalidades em que os indicadores de nível de carga de trabalho são salvos na tabela), um intervalo ou distribuição da carga de trabalho por nó de trabalho e assim por diante.

[0157]O W1 pode então comparar sua própria carga de trabalho (por exemplo, com base no número de partições atribuídas a W1, e/ou nos indicadores do nível de carga de trabalho por partição) com algumas ou todas as métricas. Em geral, é possível chegar a qualquer um dos três tipos de conclusões: que W1 está sobrecarregado, que W1 está livre ou que a carga de trabalho de W1 não está alta nem baixa. Os níveis da carga de trabalho que são "muito alto" ou "muito baixo" podem ser definidos pelas políticas selecionadas pelos clientes em cujo nome o estágio está configurado em algumas modalidades ou usando um conjunto padrão de heurísticas em outras modalidades. Se W1 determinar que a sua carga de trabalho está muito baixa (elemento 2907), por exemplo, abaixo de um limite mínimo de carga T1, um nó de trabalho com mais carga ou ocupado pode ser identificado (elemento 2910). O W1 pode, então, iniciar um processo de transferência de uma ou mais partições Pm de Wk para si mesmo (elemento 2913), por exemplo, pela tentativa de modificar a entrada Pm na tabela de PA, solicitando essa modificação (que pode resultar na geração de uma notificação para Wk) ou solicitando Wk diretamente.

[0158]Se o W1 determinar que a sua carga de trabalho está muito alta (elemento 2916), por exemplo, acima de um limite máximo T2, ele pode identificar uma ou mais partições atribuídas Pn para abandonar (ou seja, para liberar para atribuição por outros nós de trabalho) (elemento 2919). W1 pode então modificar as entradas apropriadas na tabela de PA, por exemplo, pela remoção de seu identificador a partir da coluna atribuída da entrada para Pn (elemento 2922). Se a carga de trabalho de W1 não estiver nem alta, nem baixa, ou depois que W1 tomou os tipos de ações descritas acima para aumentar ou diminuir a sua carga de trabalho, W1 pode retomar os registros de processamento das partições aos quais foi atribuído (elemento 2925). As operações correspondentes aos elementos 2901 em diante podem ser repetidas quando e se as condições que desencadearem outra análise de equilíbrio de carga forem atendidas. Note-se que nas operações ilustradas na FIG. 29, W1 é mostrado como iniciando mudanças da carga de trabalho apenas quando ele detecta um desequilíbrio em relação à sua própria carga de trabalho. Em outras modalidades, W1 pode iniciar ações de reequilíbrio se ele detectar desequilíbrios entre outros nós de trabalho do que no seu próprio - por exemplo, se ele determinar que W2 tem um nível de carga de trabalho muito menor do que W3. Em algumas implementações, W1 pode solicitar ou iniciar um reparticionamento dinâmico (por exemplo, invocando um API de SMS repartitionStream conforme mostrado na FIG. 3, ou sua equivalente), se e quando ele detectar desequilíbrios de carga de trabalho. Em algumas modalidades, os tipos de operações ilustradas na FIG. 29 podem ser executadas por um nó de trabalho recém-configurado - por exemplo, quando nós novos são adicionados a um estágio depois que o estágio já estiver em funcionamento há algum tempo, os nós novos podem notificar indiretamente os nós existentes de sua presença solicitando reatribuição de partições de nós existentes excessivamente carregados. Em algumas modalidades, as técnicas de controle descentralizado similares às descritas acima para os nós de trabalho de SPS também podem ou em vez disso são utilizadas em um ou mais subsistemas de SMS, por exemplo, nós do subsistema de ingestão, armazenamento ou recuperação podem coordenar suas cargas de trabalho usando estruturas de dados compartilhados semelhantes aos das tabelas de PA.

[0159]Note-se que em várias modalidades, operações diferentes das ilustradas nos fluxogramas da FIG. 17 - FIG. 24 e FIG. 27-29 podem ser utilizados para implementar o serviço de gerenciamento de fluxo e/ou a funcionalidade de processamento do fluxo descrita acima. Algumas das operações mostradas não podem ser implementadas em algumas modalidades ou podem ser implementadas numa ordem diferente, ou em paralelo, em vez de sequencialmente. É observado também que, no que diz respeito a cada uma das funções de SMS e SPS em relação às quais as interfaces programáticas são respaldadas em várias modalidades, qualquer combinação de uma ou mais técnicas podem ser usadas para implementar as interfaces, incluindo o uso de APIs de páginas da web, sites da web, serviços da web, outros APIs, ferramentas de linha de comando, interfaces gráficas de usuário, aplicativos móveis (apps), aplicativos para tablets e similares.

Casos de Uso

[0160]As técnicas descritas acima, de estabelecimento de serviços multilocatários escaláveis gerenciados dinamicamente configuráveis à base de particionamento escalável para coleta, armazenamento, recuperação e processamento em estágios dos registros de dados do fluxo podem ser úteis em vários cenários. Por exemplo, grandes redes do fornecedor podem compreender milhares de hosts de instância implementando instâncias de serviço de vários serviços de mono ou multilocatários diferentes para dezenas de milhares de clientes simultaneamente. Os agentes de monitoramento e/ou faturamento instalados em diversas instâncias e anfitriões hosts podem gerar rapidamente milhares de registros de métricas, o que podem precisar de armazenamento e análise para produzir registros de faturamento precisos, para determinar planos de aprovisionamento eficazes para os centros de dados da rede do fornecedor, para detectar ataques de rede e similares. Os registos de monitoramento podem formar um fluxo de entrada para SMS para ingestão e armazenamento escalável e técnicas de SPS descritas podem ser implementadas para a análise de métricas coletadas. Da mesma forma, os aplicativos para coletar e analisar um grande número de registros de log de várias fontes de log (por exemplo, logs do aplicativo dos nós de um aplicativo distribuído, ou logs do sistema dos hosts ou instâncias de computação em um centro de dados) também podem ser capazes de usar SMS e funcionalidade de SPS. Em pelo menos alguns ambientes, as operações de processamento de SPS podem compreender uma operação de processamento de Extração-Transformação-Carga (ETL) em tempo real (ou seja, uma operação que transforma registros de dados recebidos em tempo real para o carregamento em um destino, em vez de fazer a transformação off-line), ou uma transformação de registros de dados para inserção em um depósito de dados. O uso de uma combinação de SMS/SPS para o carregamento de dados em um depósito de dados em tempo real pode evitar atrasos que sejam normalmente necessários para limpar e curar dados de uma ou mais fontes de dados, antes que os dados possam ser inseridos em um depósito para análise.

[0161]Um número de aplicativos "big data" diferentes também podem ser construídos usando técnicas de SMS e SPS. Por exemplo, a análise das tendências em diversas formas de interações de mídia social pode ser realizada de forma eficiente usando fluxos. Os dados coletados de telefones ou tablets, como informações de localização dos usuários podem ser gerenciadas como registros de fluxo. Informações de áudio ou vídeo coletadas, por exemplo, de uma frota de câmeras de monitoramento podem representar outra categoria de dados de fluxo que poderiam ser coletados e processados de forma escalável ajudando, potencialmente, a evitar ataques de vários tipos. Aplicativos científicas que requerem análise de conjuntos de dados crescentes coletados, por exemplo, de satélites meteorológicos, sensores baseados em oceanos, sensores baseados em florestas, telescópios astronômicos, também podem se beneficiar das capacidades de gerenciamento e processamento de fluxo descritas neste documento. As opções de configuração baseadas em políticas flexíveis e opções de preço podem ajudar diferentes tipos de usuários a personalizar a funcionalidade de flux para adequar seus orçamentos específicos e requisitos de durabilidade/disponibilidade de dados.

[0162]As modalidades da presente divulgação podem ser descritas levando em consideração as seguintes cláusulas: 1. Um sistema que compreende: um ou mais dispositivos de computação configurados para: determinar, por meio de um ou mais componentes de controle de um serviço de gerenciamento de fluxo multilocatário, em que um ou mais componentes de controle são atribuídos ao fluxo de dados particular que compreende uma pluralidade de registros de dados gerados por um ou mais produtores, um conjunto respectivo de nós de (a) um subsistema de ingestão de registro, (b) um subsistema de armazenamento de registro e (c) um subsistema de recuperação de registro, em que cada subsistema do subsistema de ingestão de registro, subsistema de armazenamento de registro e subsistema de recuperação de registro compreende um ou mais nós dinamicamente configuráveis por um ou mais componentes de controle baseados em uma ou mais políticas incluindo uma política de particionamento; receber registros de dados submetidos através de uma ou mais interfaces programáticas de submissão de registro implementadas no subsistema de ingestão de registro, em que uma ou mais interfaces programáticas de submissão de registro incluem uma primeira interface de submissão que presta suporte à submissão em linha dos registros de dados e uma segunda interface de submissão que permite a submissão dos registros dos dados pela referência aos endereços de rede na qual os dados são armazenados; fornecer conteúdo dos registros de dados em resposta às solicitações de recuperação do registro de dados recebidos através de uma ou mais interfaces programáticas de recuperação de registro implementadas no subsistema de recuperação de registro, em que uma ou mais interfaces programáticas de recuperação de registros incluem uma primeira interface de recuperação que permite um padrão de acesso não sequencial e uma segunda interface de recuperação que permite um padrão de acesso sequencial, e em que uma taxa de faturamento associada ao uso da primeira interface de recuperação difere de uma taxa de faturamento associada ao uso da segunda interface de recuperação; gerar uma quantidade de faturamento do cliente associada ao fluxo de dados particular com base, pelo menos em parte, nas métricas de contagem de uso respectivas da pluralidade de interfaces de recuperação de registro e da pluralidade de interfaces de submissão de registro. 2. O sistema mencionado na cláusula 1, em que um ou mais dispositivos de computação são configurados ainda para: atribuir, de acordo com a política de particionamento, um registro de dados particular do fluxo de dados particular a uma partição do fluxo de dados particular, com base, pelo menos em parte, em uma chave associada ao registro de dados particular, em que a chave é indicada por uma solicitação de escrita correspondente ao registro de dados particular. 3. O sistema mencionado na cláusula 1, em que um ou mais dispositivos de computação são configurados ainda para: selecionar com base, pelo menos em parte, em uma partição à qual um registro de dados particular é atribuído, um ou mais (a) nós particulares do subsistema de ingestão de registro responsável pelo aceite do registro de dados particular, (b) nós particulares do subsistema de armazenamento de registro responsável pelo armazenamento de pelo menos uma cópia do registro de dados particular e (c) nós particulares do subsistema de recuperação responsável pela obtenção do registro de dados particular do subsistema de armazenamento de registro em resposta a uma solicitação lida. 4. O sistema mencionado na cláusula 1, em que pelo menos um subsistema do subsistema de ingestão de registro, o subsistema de armazenamento do registro e o subsistema de recuperação do registro compreende uma pluralidade de nós configurados por um ou mais de componentes de controle de como membros de um grupo de redundância, em que o grupo de redundância compreende: (a) um ou mais nós primários atribuídos para executar operações em um conjunto de registros de dados e (b) um ou mais nós não-primários configurados para assumir um papel principal em resposta a uma detecção de um ou mais eventos desencadeantes. 5. O sistema mencionado na cláusula 1, em que um ou mais dispositivos de computação são configurados ainda para: gerar, correspondendo a um registro de dados particular, um número sequencial particular indicativo de uma ordem em que o registro de dados particular foi recebido no subsistema de ingestão de registro relativo a outros registros de dados da partição à qual o registro de dados particular pertence; armazenar, pelo subsistema de armazenamento de registro, uma pluralidade de registros de dados incluindo o registro de dados particular numa ordem baseada, pelo menos em parte, nos respectivos números sequenciais gerados pelos registros de dados; e em resposta a uma solicitação de leitura que invoca a primeira interface de recuperação com o número sequencial particular como um parâmetro, recuperar o registro de dados particular do subsistema de armazenamento do registro. 6.Um método que compreende: execução, por um ou mais dispositivos de computação: determinação, para um fluxo de dados particular que compreende uma pluralidade de registros de dados, de um conjunto de nós configuráveis por um ou mais componentes de controle para executar operações de gerenciamento de fluxo baseadas em uma ou mais políticas, incluindo uma política de particionamento de fluxo; fornecimento de registros de dados em resposta às solicitações de recuperação do registro recebidas através de uma ou mais interfaces programáticas de recuperação de registro, em que uma ou mais interfaces programáticas de recuperação de registros incluem uma primeira interface de recuperação que permite um padrão de acesso não sequencial e uma segunda interface de recuperação que permite um padrão de acesso sequencial, e em que uma taxa de faturamento associada ao uso da primeira interface de recuperação difere de uma taxa de faturamento associada ao uso da segunda interface de recuperação; e geração de uma quantidade de faturamento do cliente associada ao fluxo de dados particular com base, pelo menos em parte, nas métricas de contagem de uso respectivas da pluralidade de interfaces de recuperação de registro. 7. O método mencionado na cláusula 6 que compreende ainda a execução, pelos um ou mais dispositivos de computação: atribuição, de acordo com a política de particionamento, de um registro de dados particular do fluxo de dados particular a uma primeira partição do fluxo de dados particular, com base, pelo menos em parte, em uma chave associada ao registro de dados particular, em que a chave é indicada por uma solicitação de escrita correspondente ao registro de dados particular. 8. O método mencionado na cláusula 6 que compreende ainda a execução, pelos um ou mais dispositivos de computação: seleção, com base, pelo menos em parte, em uma partição à qual um registro de dados particular é atribuído, de um ou mais (a) nós particulares do subsistema de ingestão de registro responsável pelo aceite do registro de dados particular, (b) nós particulares do subsistema de armazenamento de registro responsável pelo armazenamento de pelo menos uma cópia do registro de dados particular e (c) nós particulares do subsistema de recuperação responsável pela obtenção do registro de dados particular do subsistema de armazenamento de registro em resposta a uma solicitação lida. 9. O método mencionado na cláusula 6 que compreende ainda a execução, pelos um ou mais dispositivos de computação: recebimento de registros de dados submetidos através de uma ou mais interfaces programáticas de submissão de registro, em que uma ou mais interfaces programáticas de submissão de registro incluem uma primeira interface de submissão que presta suporte à submissão em linha dos registros de dados e uma segunda interface de submissão que permite a submissão dos registros dos dados pela referência: (a) um endereço de objeto em um serviço de armazenamento implementado por uma rede do fornecedor (b) um localizador de registro universal (c) um registro do banco de dados. 10.O método mencionado na cláusula 6 que compreende ainda a execução, pelos um ou mais dispositivos de computação: remoção, a partir de um nó particular de um subsistema de armazenamento de dados, de um registro de dados particular com base, pelo menos em parte, em: (a) uma janela de de-duplicação de dados configurada para um fluxo de dados particular, (b) uma política de arquivamento de dados associada ao fluxo de dados particular, (c) uma política de retenção de dados indicada por um cliente, (d) uma solicitação do cliente para remover o registro de dados particular ou (e) uma indicação de que o registro de dados particular foram processados por um ou mais consumidores de dados. 11.O método mencionado na cláusula 6, em que pelo menos um subsistema de: (a) subsistema de ingestão de registro, (b) subsistema de armazenamento do registro ou (c) subsistema de recuperação do registro configurado para o fluxo de dados particular compreende uma pluralidade de nós configurados por um ou mais componentes de controle como membros de um grupo de redundância, em que o grupo de redundância compreende: (a) um ou mais nós primários atribuídos para executar operações em um conjunto de registros de dados do fluxo e (b) um ou mais nós não-primários configurados para assumir um papel principal em resposta a um ou mais eventos desencadeantes. 12.O método mencionado na cláusula 11, em que um nó primário particular de um ou mais nós primários é instanciado em um centro de dados particular, e em que um nó não-primário particular de um ou mais nós não-primários é instanciado em um centro de dados diferente. 13.O método mencionado na cláusula 11 que compreende ainda a execução, pelos um ou mais dispositivos de computação: detecção de um evento desencadeante de um ou mais eventos desencadeantes; e notificação de um nó não-primário particular de um ou mais nós não-primários para assumir o papel principal. 14.O método mencionado na cláusula 6, em que um ou mais componentes de controle compreendem uma pluralidade de nós de controle configurados como um grupo de redundância, que compreende um nó de controle primário configurado para responder as solicitações para operações do plano de controle em um ou mais fluxos de dados, incluindo o fluxo de dados particular e pelo menos um nó de controle não- primário configurado para assumir um papel principal em resposta a um ou mais eventos desencadeantes. 15.O método mencionado na cláusula 6 que compreende ainda a execução, pelos um ou mais dispositivos de computação: armazenamento, em um banco de dados acessível pela rede de uma rede do fornecedor, os metadados do fluxo de dados particular incluindo um mapa de partição gerado em conformidade com a política de particionamento de fluxo; e acesso, a partir de um subsistema de recuperação de registros, aos metadados para responder uma solicitação de recuperação de registro particular. 16.O método mencionado na cláusula 6 que compreende ainda a execução, pelos um ou mais dispositivos de computação: geração, correspondendo a um registro de dados particular do fluxo de dados, de um número sequencial particular indicativo de uma ordem em que o registro de dados particular foi recebido no subsistema de ingestão de registro relativo a outros registros de dados da partição à qual o registro de dados particular pertence; armazenamento, pelo subsistema de armazenamento de registro, de uma pluralidade de registros de dados incluindo o registro de dados particular numa ordem baseada, pelo menos em parte, no respectivo carimbo temporal gerado pelos registros de dados; e em resposta ao recebimento de uma solicitação de leitura que invoca a primeira interface de recuperação com o número sequencial particular como um parâmetro, recuperação do registro de dados particular do subsistema de armazenamento do registro. 17.O método mencionado na cláusula 6, em que um nó particular do conjunto de nós compreende: (a) pelo menos uma parte de uma tabela do banco de dados de um serviço de banco de dados implementado em uma rede do fornecedor, ou (b) pelo menos uma parte de um objeto de armazenamento de um serviço de armazenamento implementado em uma rede do fornecedor. 18. Instruções do programa de armazenamento do meio de armazenamento não-transitório acessível por computador que, quando executadas em um ou mais processadores, implementam um nó de controle um serviço de gerenciamento de fluxo multilocatário, em que o nó de controle é configurado para: receber uma solicitação para inicializar um fluxo de dados particular a ser constituído por uma pluralidade de registros de dados gerados por um ou mais produtores de dados; determinar, com base, pelo menos em parte, em uma política de particionamento associada ao fluxo de dados particular, um ou mais parâmetros que devem ser usados para configurar um ou mais subsistemas para o fluxo de dados particular, incluindo um subsistema de recuperação de registro, em que um ou mais parâmetros compreendem um número inicial de nós que devem ser instanciados no subsistema de recuperação de registros; identificar um ou mais recursos que devem ser usados para um nó particular do subsistema de recuperação de registro, em que o nó particular deve ser configurado para implementar uma pluralidade de interfaces programáticas de recuperação de registro, incluindo uma primeira interface de recuperação que permite um padrão de acesso não-sequencial e uma segunda interface de recuperação que permite um padrão de acesso sequencial; e configurar o nó particular do subsistema de recuperação de registro usando um ou mais recursos. 19. O meio de armazenamento não-transitório acessível por computador mencionado na cláusula 18, em que um ou mais subsistemas incluem um subsistema de ingestão de registro que compreende um ou mais nós configuráveis para receber registros de dados do fluxo de dados particular e um subsistema de armazenamento de registro configurável para armazenar registros de dados do fluxo em um conjunto selecionado de locais de armazenamento. 20.O meio de armazenamento não-transitório acessível por computador mencionado na cláusula 19, em que pelo menos um subsistema do subsistema de ingestão de registro, o subsistema de armazenamento do registro e o subsistema de recuperação do registro compreende uma pluralidade de nós configurados como membros de um grupo de redundância, em que o grupo de redundância compreende: (a) um ou mais nós primários atribuídos para executar operações em um conjunto de registros de dados do fluxo e (b) um ou mais nós não-primários configurados para assumir um papel principal em resposta a um ou mais eventos desencadeantes. 21.O meio de armazenamento não-transitório acessível por computador mencionado na cláusula 19, sendo que pelo menos um nó do: subsistema de ingestão de registro, subsistema de armazenamento do registro ou subsistema de recuperação do registro compreende um componente de uma instância de computação de um serviço de computação virtualizado implementado na rede do fornecedor. 22.O meio de armazenamento não-transitório acessível por computador mencionado na cláusula 19, em que um ou mais produtores de dados compreendem um ou mais: (a) um componente de log de um dispositivo de computação, (b) um aplicativo de mídia social, (c) um agente de monitoramento em um dispositivo de computação, (d) um dispositivo de sensor, (e) um telefone móvel ou (f) um tablet.

Sistema de computador ilustrativo

[0163]Em pelo menos algumas modalidades, um servidor que implementa uma parte ou a totalidade de uma ou mais tecnologias descritas neste documento, incluindo técnicas para implementar os componentes dos subsistemas de SMS (por exemplo, subsistemas de ingestão, armazenamento, recuperação e controle), bem como nós de trabalho e de controle de SPS, podem incluir um sistema de computador de uso geral que inclui ou está configurado para acessar um ou mais meios acessíveis por computador. A FIG. 30 ilustra esse dispositivo de computação de uso geral 9000.Na modalidade ilustrada, o dispositivo de computação 9000 inclui um ou mais processadores 9010 acoplados a uma memória de sistema 9020 através de uma interface de entrada/saída (I/O) 9030.O dispositivo de computação 9000 inclui ainda uma interface de rede 9040 acoplada à interface I/O 9030.

[0164]Em várias modalidades, o dispositivo de computação 9000 pode ser um sistema de processador único que inclui um processador 9010, ou um sistema de multiprocessador que inclui vários processadores 9010 (por exemplo, dois, quatro, oito ou outro número apropriado).Os processadores 9010 podem ser quaisquer processadores adequados capazes de executar instruções. Por exemplo, em várias modalidades, os processadores 9010 podem ser processadores de uso geral ou embutidos que implementam uma variedade de arquiteturas do conjunto de instruções (ISAs), como o x86, PowerPC, SPARC ou MIPS ISAs ou qualquer outra ISA cabível. Em sistemas com múltiplos processadores, cada processador 9010 pode, comumente, mas não necessariamente, implementar a mesma ISA. Em algumas implementações, as unidades de processamento gráfico (GPUs) podem ser utilizadas em vez ou além dos processadores convencionais.

[0165]A memória do sistema 9020 pode ser configurada para armazenar instruções e dados acessíveis pelos processadores 9010.Em várias modalidades, a memória do sistema 9020 pode ser implementada usando qualquer tecnologia de memória adequada, como memória estática de acesso aleatório (SRAM), RAM dinâmica sincrônica (SDRAM), memória não volátil/tipo flash ou qualquer outro tipo de memória. Na modalidade ilustrada, as instruções de programa e dados que implementam uma ou mais funções desejadas, como aqueles métodos, técnicas e dados descritos acima, são mostrados armazenados na memória do sistema 9020 como código 9025 e dados 9026.

[0166]Em uma modalidade, a Interface I/O 9030 pode ser configurada para coordenar o tráfego de I/O entre o processador 9010, a memória do sistema 9020 e quaisquer dispositivos periféricos no dispositivo, incluindo a interface de rede 9040 ou outras interfaces periféricas, como vários tipos de dispositivos de armazenamento persistente e/ou volátil utilizados para armazenar réplicas físicas de partições do objeto de dados. Em algumas modalidades, a interface I/O 9030 pode executar qualquer protocolo necessário, timing ou outras transformações de dados para converter os sinais dos dados de um componente (por exemplo, memória do sistema 9020) para um formato adequado para ser utilizado por outro componente (por exemplo, processador 9010).Em algumas modalidades, a interface I/O 9030 pode incluir suporte para dispositivos ligados através de vários tipos de barramentos periféricos, como uma variante da Interconexão de Componentes Periféricos (PCI) padrão de barramento ou Barramento Serial Universal (USB) padrão, por exemplo. Em algumas modalidades, função da interface I/O 9030 pode ser dividida em dois ou mais componentes separados, como uma ponte norte e uma ponte sul, por exemplo. Além disso, em algumas modalidades, algumas ou todas as funcionalidades da interface I/O 9030, como uma interface para a memória do sistema 9020, podem ser incorporadas diretamente ao processador 9010.

[0167]A interface de rede 9040 pode ser configurada para permitir que os dados sejam trocados entre o dispositivo de computação 9000 e outros dispositivos 9060 ligados a uma rede ou redes 9050, como outros sistemas ou dispositivos computacionais conforme ilustrado na FIG. 1 a FIG. 29, por exemplo. Em várias modalidades, a interface de rede 9040 pode dar suporte à comunicação através de quaisquer redes de dados gerais com ou sem fio adequadas, como tipos de rede Ethernet, por exemplo. Além disso, a interface de rede 9040 pode suportar a comunicação via redes de telecomunicação/telefonia, como redes de voz analógicas ou redes de comunicações de fibra digital, através de redes de área de armazenamento, como SANs de Canal de Fibra, ou através de qualquer outro tipo adequado de rede e/ou protocolo.

[0168]Em algumas modalidades, a memória do sistema 9020 pode ser uma modalidade de um meio acessível por computador configurado para armazenar instruções e dados de programas conforme descrito acima para a FIG. 1 a FIG. 29 para implementar modalidades dos métodos e aparelhos correspondentes. No entanto, em outras modalidades, as instruções e/ou dados do programa podem ser recebidas, enviados ou armazenados em diferentes tipos de meios acessíveis por computador. De um modo geral, um meio acessível por computador pode incluir meios de armazenamento não-transitórios ou meios de memória, como meio magnético ou óptico, por exemplo, disco ou DVD/CD acoplado ao dispositivo de computação 9000 via interface I/O 9030.Um meio de armazenamento não-transitório acessível por computador pode incluir também quaisquer meios voláteis ou não-voláteis, como RAM (por exemplo, SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., que podem ser incluídos em algumas formas de realização do dispositivo de computação 9000 como a memória do sistema 9020 ou outro tipo de memória. Além disso, um meio acessível por computador pode incluir meios ou sinais de transmissão como sinais elétricos, eletromagnéticos ou digitais, transmitidos através de um meio de comunicação, como uma rede e/ou link sem fios, como pode ser implementado pela interface de rede 9040. Partes ou todos os múltiplos dispositivos de computação, como os ilustrados na FIG. 30 podem ser usados para implementar a funcionalidade descrita em várias modalidades; por exemplo, componentes de software que executam em diversos dispositivos e servidores diferentes podem colaborar para fornecer a funcionalidade. Em algumas modalidades, partes da funcionalidade descrita podem ser implementadas usando dispositivos de armazenamento, dispositivos de rede ou de sistemas de computador para uso especial, além ou em vez de serem implementados usando sistemas de computador de uso geral. O termo "dispositivo de computação" usado neste documento refere-se a pelo menos todos estes tipos de dispositivos e não se limita a estes tipos de dispositivos.

Conclusão

[0169]Várias modalidades podem incluir ainda o recebimento, envio ou armazenamento de instruções e/ou dados implementados de acordo com a descrição anterior em um meio acessível por computador. De um modo geral, um meio acessível por computador pode incluir meios de armazenamento ou meios de memória, como meio magnético ou óptico, por exemplo, disco ou DVD/CD-ROM, meios voláteis ou não-voláteis como RAM (por exemplo, SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc., bem como meios ou sinais de transmissão como sinais elétricos, eletromagnéticos ou digitais, transmitidos através de um meio de comunicação, como uma rede e/ou link sem fios.

[0170]Os vários métodos ilustrados nas Figuras e descritos neste documento representam modalidades exemplares dos métodos. Os métodos podem ser implementados em software, hardware ou em uma combinação dos mesmos. A ordem do método pode ser alterada e vários elementos podem ser adicionados, reordenados, combinados, omitidos, modificados, etc.

[0171]Várias modificações e alterações podem ser feitas como seria óbvio para uma pessoa versada na técnica tendo o benefício desta divulgação. Este documento destina-se a abranger todas essas modificações e alterações e, por conseguinte, o relatório acima deve ser considerado em sentido ilustrativo em vez de um sentido restritivo.

Claims (30)

1. Método, CARACTERIZADO por compreender: executar, por um ou mais dispositivos de computação: determinação, para um fluxo de dados particular compreendendo uma sequência de uma pluralidade de registros de dados, de um conjunto de nós configuráveis por um ou mais componentes de controle para executar operações de gerenciamento de fluxo com base em uma ou mais políticas, incluindo uma política de particionamento de fluxo para particionar o fluxo de dados particular que compreende a sequência da pluralidade de registros em uma pluralidade de partições; fornecimento de registros de dados em resposta às solicitações de recuperação de registro recebidas através de uma ou mais interfaces de recuperação de registro programáticas, em que a uma ou mais interfaces de recuperação de registros programáticas incluem uma primeira interface de recuperação que permite um padrão de acesso não sequencial e uma segunda interface de recuperação que permite um padrão de acesso sequencial, e em que uma taxa de faturamento associada a um uso da primeira interface de recuperação difere de uma taxa de faturamento associada a um uso da segunda interface de recuperação; e geração de uma quantidade de faturamento de cliente associada ao fluxo de dados particular com base, pelo menos em parte, nas respectivas métricas de contagem de uso da pluralidade de interfaces de recuperação de registro.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação, a: atribuição, de acordo com a política de particionamento, de um registro de dados particular do fluxo de dados particular a uma primeira partição do fluxo de dados particular, com base, pelo menos em parte, em uma chave associada ao registro de dados particular, em que a chave é indicada por uma solicitação de escrita correspondente ao registro de dados particular.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação: seleção, com base, pelo menos em parte, em uma partição à qual um registro de dados particular é atribuído, de um ou mais dentre (a) um nó particular de um subsistema de ingestão de registro responsável por aceitar o registro de dados particular, (b) um nó particular de um subsistema de armazenamento de registro responsável por armazenar pelo menos uma cópia do registro de dados particular e (c) um nó particular de um subsistema de recuperação responsável por obter o registro de dados particular do subsistema de armazenamento de registro em resposta a uma solicitação lida.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação: recebimento de registros de dados submetidos através de uma ou mais interfaces de submissão de registro programáticas, em que a uma ou mais interfaces de submissão de registro programáticas incluem uma primeira interface de submissão que suporta em linha à submissão dos registros de dados e uma segunda interface de submissão que permite a submissão dos registros dos dados por referência a um dentre: (a) um endereço de objeto em um serviço de armazenamento implementado por uma rede de fornecedores (b) um localizador de registro universal (c) um registro do banco de dados.

5. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação: remoção, a partir de um nó particular de um subsistema de armazenamento de dados, de um registro de dados particular com base, pelo menos em parte, em uma dentre: (a) uma janela de de-duplicação de dados configurada para o fluxo de dados particular, (b) uma política de arquivamento de dados associada ao fluxo de dados particular, (c) uma política de retenção de dados indicada por um cliente, (d) uma solicitação do cliente para remover o registro de dados particular ou (e) uma indicação de que o registro de dados particular foi processado por um ou mais consumidores de dados.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que pelo menos um subsistema dentre: (a) um subsistema de ingestão de registro, (b) um subsistema de armazenamento de registro ou (c) um subsistema de recuperação do registro configurado para o fluxo de dados particular compreende uma pluralidade de nós configurados pelo um ou mais componentes de controle como membros de um grupo de redundância, em que o grupo de redundância compreende: (a) um ou mais nós primários atribuídos para executar operações em um conjunto de registros de dados do fluxo e (b) um ou mais nós não-primários configurados para assumir um papel principal em resposta a um ou mais eventos desencadeantes.

7. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que um nó primário particular dos um ou mais nós primários é instanciado em um centro de dados particular, e em que um nó não-primário particular do um ou mais nós não-primários é instanciado em um centro de dados diferente.

8. Método, de acordo com a reivindicação 6, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação: detecção de um evento desencadeante do um ou mais eventos desencadeantes; e notificação de um nó não-primário particular do um ou mais nós não-primários para assumir o papel principal.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o um ou mais componentes de controle compreendem uma pluralidade de nós de controle configurados como um grupo de redundância, compreendendo um nó de controle primário configurado para responder às solicitações para operações de plano de controle em um ou mais fluxos de dados, incluindo o fluxo de dados particular, e pelo menos um nó de controle não-primário configurado para assumir um papel principal em resposta a um ou mais eventos desencadeantes.

10. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação: armazenamento, em um banco de dados acessível pela rede de uma rede de fornecedor, dos metadados do fluxo de dados particular incluindo um mapa de partição gerado de acordo com a política de particionamento de fluxo; e acesso, a partir de um subsistema de recuperação de registros, aos metadados para responder uma solicitação de recuperação de registro particular.

11. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreender ainda executar, por um ou mais dispositivos de computação: geração, correspondendo a um registro de dados particular do fluxo de dados, de um número sequencial particular indicativo de uma ordem em que o registro de dados particular foi recebido em um subsistema de ingestão de registro relativo a outros registros de dados da partição à qual o registro de dados particular pertence; armazenamento, por um subsistema de armazenamento de registro, de uma pluralidade de registros de dados incluindo o registro de dados particular numa ordem com base, pelo menos em parte, no respectivo carimbo temporal gerado para os registros de dados; e em resposta ao recebimento de uma solicitação de leitura que invoca a primeira interface de recuperação com o número sequencial particular como um parâmetro, recuperação do registro de dados particular do subsistema de armazenamento de registro.

12. Sistema incluindo um ou mais processadores e uma ou mais memórias, as uma ou mais memórias incluindo instruções de programa que, quando executadas em um ou mais processadores, implementam um nó de controle de um serviço de gerenciamento de fluxo multilocatário, CARACTERIZADO pelo fato de que o nó de controle é configurado para: receber uma solicitação para inicializar um fluxo de dados particular a ser compreendido por uma sequência de uma pluralidade de registros de dados gerados por um ou mais produtores de dados; determinar, com base, pelo menos em parte, em uma política de particionamento para particionar o fluxo de dados particular que compreende a sequência da pluralidade de partições em uma pluralidade de partições, um ou mais parâmetros a serem usados para configurar um ou mais subsistemas para o fluxo de dados particular, incluindo um subsistema de recuperação de registro, em que um ou mais parâmetros compreendem um número inicial de nós a serem instanciados no subsistema de recuperação de registros; identificar um ou mais recursos a serem usados para um nó particular do subsistema de recuperação de registro, em que o nó particular é para ser configurado para implementar uma pluralidade de interfaces de recuperação de registro programáticas, incluindo uma primeira interface de recuperação que permite um padrão de acesso não-sequencial e uma segunda interface de recuperação que permite um padrão de acesso sequencial; e configurar o nó particular do subsistema de recuperação de registro usando o um ou mais recursos.

13. Sistema, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que um ou mais subsistemas incluem um subsistema de ingestão de registro compreendendo um ou mais nós configuráveis para receber registros de dados do fluxo de dados particular, e um subsistema de armazenamento de registro configurável para armazenar registros de dados do fluxo em um conjunto selecionado de locais de armazenamento.

14. Sistema, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que pelo menos um subsistema do subsistema de ingestão de registro, o subsistema de armazenamento de registro, e o subsistema de recuperação de registro compreende uma pluralidade de nós configurados como membros de um grupo de redundância, em que o grupo de redundância compreende: (a) um ou mais nós primários atribuídos para executar operações em um conjunto de registros de dados do fluxo e (b) um ou mais nós não-primários configurados para assumir um papel principal em resposta a um ou mais eventos desencadeantes.

15. Sistema, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que pelo menos um nó dentre: o subsistema de ingestão de registro, o subsistema de armazenamento do registro ou o subsistema de recuperação do registro compreende um componente de uma instância de computação de um serviço de computação virtualizado implementado na rede de fornecedor.

16. Sistema CARACTERIZADO por compreender: um ou mais dispositivos de computação compreendendo um ou mais processadores de hardware respectivos e memória e configurados para: determinar uma política de particionamento a ser aplicada para distribuir registros de dados de um fluxo de dados entre uma pluralidade de nós de um serviço de gerenciamento de fluxo multilocatário, em que a política de particionamento compreende um mapeamento inicial dos registros de dados para uma pluralidade de partições com base pelo menos em parte em um ou mais valores de atributos associados com os registros de dados; identificar, usando o mapeamento inicial, uma primeira partição da qual um registro de dados particular do fluxo de dados é para ser designado um membro, com base pelo menos em parte no valor do atributo particular; gerar, correspondendo ao registro de dados particular, um número sequencial indicativo de uma posição do registro de dados particular dentro de uma sequência de aquisição de registro em um nó de ingestão do serviço de gerenciamento de fluxo, em que o no de ingestão é selecionado com base pelo menos em parte no mapeamento inicial; armazenar uma pluralidade de registros de dados da primeira partição em uma localização de armazenamento de dados do serviço de gerenciamento de fluxo em uma ordem com base pelo menos em parte nos números sequenciais respectivos da pluralidade de registros de dados, em que a localização de armazenamento de dados é selecionada com base pelo menos em parte no mapeamento inicial; e em resposta a uma determinação de que um critério de desencadeamento para reparticionar o fluxo de dados foi atendido, gerar um mapeamento modificado de registro de dados para as partições; iniciar o uso do mapeamento modificado sem interrupção de um fluxo de aquisições de registros de dados do fluxo de dados; e selecionar, para outro registro de dados com valor de atributo particular, em que o outro registro de dados é recebido subsequente a uma iniciação do uso do mapeamento modificado, pelo menos um dentre: (a) um nó de ingestão diferente do serviço de gerenciamento de fluxo ou (b) uma localização de armazenamento de dados diferente do serviço de gerenciamento de fluxo.

17. Método, CARACTERIZADO por compreender: executar, por um ou mais dispositivos computacionais de um serviço de gerenciamento de fluxo: determinação de um mapeamento inicial de registros de dados de um fluxo de dados para uma pluralidade de partições com base pelo menos em parte em um ou mais valores de atributos dos registros de dados; identificação, usando o mapeamento inicial, de uma primeira partição da qual um registro de dados particular do fluxo de dados é para ser designado um membro, com base pelo menos em parte em um valor de atributo particular; armazenamento do registro de dados particular em uma localização de armazenamento selecionada com base pelo menos em parte no mapeamento inicial; e em resposta à determinação de que um critério de desencadeamento foi atendido, geração de um mapeamento modificado de registro de dados para partições; e seleção, para um outro registro de dados com valor de atributo particular e sem interromper o fluxo dos registros de dados do fluxo de dados, em que o outro registro de dados é recebido subsequente a uma iniciação de um uso do mapeamento modificado, de uma localização de armazenamento diferente.

18. Mídia de armazenamento acessível por computador não transitório CARACTERIZADA por armazenar instruções de programa que quando executadas em um ou mais processadores fazem com que o um ou mais processadores executem: determinação uma política de particionamento para ser aplicada para distribuir registros de dados de um fluxo de dados entre uma pluralidade de nós de um serviço de gerenciamento de fluxo, em que a política de particionamento compreende uma indicação de um mapeamento inicial dos registros de dados para uma pluralidade de partições; configuração de um primeiro conjunto de nós de ingestão do serviço de gerenciamento de fluxo para receber registros de dados do fluxo de acordo com o mapeamento inicial, e um primeiro conjunto de nós de armazenamento de dados do serviço de gerenciamento de fluxo para armazenar registros de dados de acordo com o mapeamento inicial; em resposta a uma determinação de que um critério de desencadeamento para reparticionar dinamicamente o fluxo de dados foi atendido, geração de um mapeamento modificado de registro de dados para uma pluralidade diferente de partições; configuração, sem interromper um fluxo de registro de dados do fluxo de dados, de um conjunto de nós de ingestão diferente e um conjunto de nós de armazenamento de dados diferente para registros de dados recebidos subsequente a uma geração do mapeamento modificado; e retenção, para pelo menos um período de tempo particular durante o qual registros de dados de chegada são armazenados de acordo com o mapeamento modificado, de registros de dados armazenados no primeiro conjunto de nós de dados de acordo com o mapeamento inicial.

19. Sistema, CARACTERIZADO por compreender: um ou mais dispositivos de computação que implementam um serviço de processamento de fluxo multilocatário configurados para: implementar uma ou mais interfaces programáticas configuradas para receber informações de configuração para processar um fluxo de dados, em que as informações de configuração especificam uma pluralidade de etapas de processamento para o processamento, e para uma ou mais etapas de processamento individuais das etapas de processamento: (a) uma política de particionamento para dividir registros de dados recebidos pela etapa de processamento ao longo do tempo em uma pluralidade de partições de fluxo a serem distribuídas entre nós de trabalho da etapa de processamento, (b) uma operação de processamento a ser executada pelos nós de trabalho da etapa de processamento nas partições de fluxo de acordo com a política de particionamento, e c) um descritor de distribuição de saída para resultados da etapa de processamento; receber, a partir de um cliente particular através da uma ou mais interfaces programáticas, informações de configuração para processar um fluxo de dados particular especificando pelo menos uma primeira etapa de processamento a ser executada de acordo com uma primeira política de particionamento especificada nas informações de configuração e uma segunda etapa de processamento a ser executada de acordo com uma segunda política de particionamento especificada nas informações de configuração, e em que a saída da primeira etapa de processamento deve ser fornecida como entrada para a segunda etapa de processamento; determinar, para a segunda etapa de processamento, com base pelo menos em parte na segunda política de particionamento e na capacidade de execução estimada de recursos a serem implementados como nós de trabalho para a segunda etapa de processamento, um número inicial de nós de trabalho para a segunda etapa de processamento; atribuir, com base pelo menos em parte na segunda política de particionamento, partições de fluxo individuais de uma pluralidade de partições de fluxo da saída da primeira etapa de processamento para nós de trabalho respectivos do número inicial de nós de trabalho para a segunda etapa de processamento, em que uma ou mais das partições de fluxo são atribuídas para um nó de trabalho particular da segunda etapa de processamento e uma outra das partições de fluxo é atribuída para um outro nó de trabalho da segunda etapa de processamento, fazer o nó de trabalho particular da segunda etapa de processamento (a) receber registros de dados da uma ou mais partições de fluxo de acordo com a segunda política de particionamento, (b) executar uma operação de processamento particular nos registros de dados recebidos da uma ou mais partições de fluxo, (c) armazenar registros de progresso indicando os registros de dados processados mais recentemente que o nó de trabalho particular processou e (d) transferir resultados da operação de processamento particular para um ou mais destinos de acordo com um descritor de distribuição de saída particular para a segunda etapa de processamento; fazer o outro nó de trabalho executar a operação de processamento particular nos registros de dados recebidos da outra partição de fluxo; monitorar um estado de saúde do nó de trabalho particular; e em resposta a uma determinação de que o nó de trabalho particular está em um estado não desejado, configurar um nó de trabalho de substituição para a segunda etapa de processamento para substituir o nó de trabalho particular, em que o nó de trabalho de substituição acessa um registro de progresso armazenado pelo nó de trabalho particular sendo substituído para identificar, com base pelo menos em parte no registro de progresso, um próximo registro de dados da uma ou mais partições nas quais executar a operação de processamento particular pelo nó de trabalho de substituição.

20. Método, CARACTERIZADO por compreender: executar, por um ou mais dispositivos de computação que implementam um serviço de processamento de fluxo multilocatário: implementação de uma ou mais interfaces programáticas configuradas para receber informações de configuração para processar um fluxo de dados, em que as informações de configuração especificam uma pluralidade de etapas de processamento para o processamento, e para uma ou mais etapas de processamento individuais dentre as etapas de processamento: (a) uma política de particionamento para dividir registros de dados recebidos pela etapa de processamento ao longo do tempo em uma pluralidade de partições de fluxo a serem distribuídas entre nós de trabalho da etapa de processamento, (b) uma operação de processamento a ser executada pelos nós de trabalho da etapa de processamento nas partições de fluxo de acordo com a política de particionamento, e (c) um descritor de distribuição de saída para resultados da etapa de processamento; recepção, a partir de um cliente particular através da uma ou mais interfaces programáticas, de informações de configuração para processar um fluxo de dados particular especificando pelo menos uma primeira etapa de processamento a ser executada de acordo com uma primeira política de particionamento especificada nas informações de configuração e uma segunda etapa de processamento a ser executada de acordo com uma segunda política de particionamento especificada nas informações de configuração, e em que a saída da primeira etapa de processamento deve ser fornecida como entrada para a segunda etapa de processamento; determinação, para a segunda etapa de processamento, com base pelo menos em parte na segunda política de particionamento e na capacidade de execução estimada de recurso para serem implementados como nós de trabalho para a segunda etapa de processamento, de um número inicial de nós de trabalho para a segunda etapa de processamento; atribuição, com base pelo menos em parte na segunda política de particionamento, de partições de fluxo individuais de uma pluralidade de partições de fluxo da saída da primeira etapa de processamento para nós de trabalho respectivos do número inicial de nós de trabalho para a segunda etapa de processamento, em que uma ou mais das partições de fluxo são atribuídas a um nó de trabalho particular da segunda etapa de processamento e uma outra das partições de fluxo é atribuída a um outro nó de trabalho da segunda etapa de processamento; fazer o nó de trabalho particular da segunda etapa de processamento executar: (a) recebimento de registros de dados das uma ou mais partições de fluxo de acordo com a segunda política de particionamento; (b) execução de uma operação de processamento particular nos registros de dados recebidos das uma ou mais partições de fluxo, (c) armazenamento de registros de progresso indicando os registros de dados processados mais recentemente que o nó de trabalho particular processou, e (d) transferência de resultados da operação particular para um ou mais destinos de acordo com um descritor de distribuição de saída particular para a segunda etapa de processamento; fazer o outro nó de trabalho executar a operação de processamento particular nos registros de dados recebidos da outra partição de fluxo; monitoramento de um estado de saúde do nó de trabalho particular; e em resposta a uma determinação de que o nó de trabalho particular está em um estado não desejado, configuração de um nó de trabalho de substituição para a segunda etapa de processamento para substituir o nó de trabalho particular, em que o nó de trabalho de substituição acessa um registro de progresso armazenado pelo nó de trabalho particular sendo substituído para identificar, com base pelo menos em parte no registro de progresso, um próximo registro de dados da uma ou mais partições de fluxo nas quais executar a operação de processamento particular pelo nó de trabalho de substituição.

21. Mídia de armazenamento acessível por computador não transitório CARACTERIZADA por armazenar instruções de programa que, quando executadas em um ou mais processadores, implementam um nó de controle de um serviço de processamento de fluxo multilocatário, em que o nó de controle é operável para: implementar uma ou mais interfaces programáticas configuradas para receber informações de configuração para processamento de fluxo de dados, em que as informações de configuração especificam uma pluralidade de etapas de processamento para o processamento, e para uma ou mais etapas de processamento individuais das etapas de processamento: (a) uma política de particionamento para dividir registros de dados recebidos pela etapa de processamento ao longo do tempo em uma pluralidade de partições de fluxo a serem distribuídas entre nós de trabalho da etapa de processamento, (b) uma operação de processamento a ser executada pelos nós de trabalho da etapa de processamento nas partições de fluxo de acordo com a política de particionamento, e (c) um descritor de distribuição de saída para resultados da etapa de processamento; receber, a partir de um cliente particular através da uma ou mais interfaces programáticas, informações de configuração para processar um fluxo de dados particular especificando pelo menos uma primeira etapa de processamento a ser executada de acordo com uma primeira política de particionamento especificada nas informações de configuração e uma segunda etapa de processamento a ser executada de acordo com uma segunda política de particionamento especificada nas informações de configuração, e em que a saída da primeira etapa de processamento deve ser fornecida como entrada da segunda etapa de processamento; determinar, para a segunda etapa de processamento, com base pelo menos em parte na segunda política de particionamento e na capacidade de execução estimada de recursos a serem implementados como nós de trabalho para a segunda etapa de processamento, um número inicial de nós de trabalho para a segunda etapa de processamento; atribuir, com base pelo menos em parte na segunda política de particionamento, partições de fluxo individuais de uma pluralidade de partições de fluxo da saída da primeira etapa de processamento para os nós de trabalho respectivos do número inicial de nós de trabalho para a segunda etapa de processamento, em que uma ou mais das partições de fluxo são atribuídas a um nó de trabalho particular da segunda etapa de processamento e uma outra partição das partições de fluxo é atribuída a outro nó de trabalho da segunda etapa de processamento; fazer o nó de trabalho particular da segunda etapa de processamento: (a) receber registros de dados das uma ou mais partições de fluxo de acordo com a segunda política de particionamento, (b) executar uma operação de processamento particular nos registros de dados recebidos das uma ou mais partições de fluxo, (c) armazenar registros de progresso indicando registros de dados processados mais recentemente que o nó de trabalho particular processou, e (d) transferir resultados da operação de processamento particular para um ou mais destinos de acordo com um descritor de distribuição de saída particular para a segunda etapa de processamento; fazer o outro nó de trabalho executar a operação de processamento particular nos registros de dados recebidos da outra partição de fluxo; monitorar um estado de saúde do nó de trabalho particular; e em resposta a uma determinação de que o nó de trabalho particular está em um estado não desejado, configurar um nó de trabalho de substituição para a segunda etapa de processamento para substituir o nó de trabalho particular, em que o nó de trabalho de substituição acessa um registro de progresso armazenado pelo nó de trabalho particular sendo substituído para identificar, com base pelo menos em parte no registro de progresso, um próximo registro de dados da uma ou mais partições nas quais executar a operação de processamento particular pelo nó de trabalho de substituição.

22. Sistema, CARACTERIZADO por compreender: um ou mais dispositivos de computação compreendendo um ou mais processadores e memória e configurados para: implementar um primeiro conjunto de interfaces programáticas que permitem que um cliente de um serviço de gerenciamento de fluxo multilocatário selecione, para um fluxo de dados particular, uma política de ingestão de dados dentre uma pluralidade de políticas de ingestão de dados, em que a pluralidade de políticas de ingestão de dados inclui uma política de ingestão pelo menos uma vez de acordo com a qual um remetente de registro transmite uma indicação de um registro de dados uma ou mais vezes para o serviço de gerenciamento de fluxo até que um reconhecimento positivo seja recebido; implementar um segundo conjunto de interfaces programáticas que permitem o cliente selecionar, para o fluxo de dados particular, uma política de persistência de dados dentre uma pluralidade de políticas de persistência de dados, em que a pluralidade de políticas de persistência de dados compreende uma política de persistência de múltiplas réplicas, de acordo com as quais múltiplas cópias do registro de dados devem ser armazenadas em locais de armazenamento respectivos pelo serviço de gerenciamento de fluxo; receber, no serviço de gerenciamento de fluxo através das respectivas interfaces programáticas do primeiro e segundo conjuntos, uma primeira indicação de que o cliente selecionou a política de ingestão pelo menos uma vez para o fluxo de dados particular e uma segunda indicação de que o cliente selecionou a política de persistência de múltiplas réplicas para o fluxo de dados particular; determinar um número de nós de ingestão de dados ou um número de nós de armazenamento de dados a serem configurados para o fluxo de dados particular com base, pelo menos em parte, em uma política de particionamento de acordo com a qual um nó de ingestão de dados do número de nós de ingestão de dados é selecionado para ingerir registros de dados de uma partição particular do fluxo de dados particular ou um nó de armazenamento de dados do número de nós de armazenamento de dados é selecionado para armazenar registros de dados da partição particular do fluxo de dados particular; e em resposta a uma pluralidade de transmissões que indicam um registro de dados particular para o serviço de gerenciamento de fluxo, enviar pelo menos um reconhecimento positivo correspondente à pluralidade de transmissões de acordo com a política de ingestão pelo menos uma vez; e armazenar, em resposta a uma transmissão particular da pluralidade de transmissões, cópias do registro de dados particular em uma pluralidade de locais de armazenamento de acordo com a política de persistência de múltiplas réplicas.

23. Método, CARACTERIZADO por compreender: executar, por um ou mais dispositivos de computação: implementação de um conjunto de interfaces programáticas que permitem que um cliente de um serviço de gerenciamento de fluxo selecione, para um fluxo de dados particular, uma política de ingestão de dados dentre uma pluralidade das políticas de ingestão de dados, em que a pluralidade de políticas de ingestão de dados inclui uma política de ingestão pelo menos uma vez de acordo com a qual um remetente de registro deve transmitir uma indicação de um registro de dados uma ou mais vezes para o serviço de gerenciamento de fluxo até que um reconhecimento positivo seja recebido; recepção de uma solicitação através de uma interface programática do conjunto, indicando que o cliente selecionou a política de ingestão pelo menos uma vez para o fluxo de dados particular; determinação de um número de nós de ingestão de dados a serem configurados para o fluxo de dados particular com base, pelo menos em parte, em uma política de particionamento de acordo com a qual um nó de ingestão de dados do número de nós de ingestão de dados é selecionado para ingerir registros de dados de uma partição particular do fluxo de dados particular; e em resposta ao recebimento de uma pluralidade de transmissões indicando um registro de dados particular no serviço de gerenciamento de fluxo, envio dos respectivos reconhecimentos positivos correspondendo a cada transmissão da pluralidade de transmissões de acordo com a política de ingestão pelo menos uma vez; e armazenamento, em resposta ao recebimento de uma transmissão particular da pluralidade de transmissões, de cópias do registro de dados particular em um ou mais locais de armazenamento de acordo com uma política de persistência de dados selecionada para o fluxo de dados particular.

24. Mídia de armazenamento acessível por computador não transitório, CARACTERIZADA por armazenar instruções de programa que, quando executadas em um ou mais processadores, fazem o um ou mais processadores: implementar um conjunto de interfaces programáticas que permitem um cliente de um serviço de gerenciamento de fluxo de dados baseado em rede selecionar, para um fluxo de dados particular, uma política de persistência de dados dentre uma pluralidade de políticas de persistência de dados, em que a pluralidade de políticas de persistência de dados inclui (a) uma política de persistência de múltiplas réplicas de acordo com a qual múltiplas cópias de um registro de dados do fluxo de dados particular devem ser armazenadas em locais de armazenamento respectivos e (b) uma política de persistência de réplica única na qual uma única cópia de um registro de dados do fluxo de dados particular deve ser armazenada, em que os registros de dados para o fluxo de dados particular são ingeridos no fluxo de dados particular com base em uma política de ingestão de dados selecionada; receber, através de uma interface programática do conjunto, uma solicitação indicando que o cliente selecionou a política de persistência de múltiplas réplicas para o fluxo de dados particular; determinar um número de nós de armazenamento de dados a serem configurados para o fluxo de dados particular com base, pelo menos em parte, em uma política de particionamento de acordo com a qual um nó de armazenamento de dados do número de nós de armazenamento de dados é selecionado para armazenar registros de dados de uma partição particular do fluxo de dados particular; e configurar uma pluralidade de nós de armazenamento para implementar a política de persistência de múltiplas réplicas para registros de dados do fluxo de dados particular.

25. Sistema, CARACTERIZADO por compreender: um ou mais dispositivos de computação de hardware configurados para: implementar um conjunto de interfaces programáticas que permitem clientes de uma rede de fornecedores selecionar dentre uma pluralidade de opções relacionadas à segurança para registros de dados de um fluxo especificado, em que a pluralidade de opções relacionadas à segurança inclui uma ou mais opções de tipo de destino de posicionamento para nós de uma ou mais categorias funcionais de uma pluralidade de categorias funcionais que incluem: (a) nós de controle, (b) nós de ingestão de registro, (c) nós de armazenamento de registro, (d) nós de recuperação de registro e (e) nós de processamento de registro; receber, através de uma interface programática do conjunto de interfaces programáticas, uma ou mais solicitações de um cliente da rede de fornecedor, em que uma das uma ou mais solicitações do cliente especifica uma da pluralidade de opções relacionadas à segurança compreendendo pelo menos uma dentre uma ou mais opções de tipo de destino de posicionamento selecionadas para um fluxo particular, em que a pelo menos uma opção de tipo de destino de posicionamento instrui que um ou mais nós de uma primeira categoria funcional da pluralidade de categorias funcionais associadas ao fluxo particular devem ser configurados em um ou mais centros de dados da rede de fornecedor , e instrui que um ou mais nós de uma segunda categoria funcional da pluralidade de categorias funcionais associadas ao fluxo particular devem ser configurados em uma instalação externa à rede de fornecedor; em resposta a uma ou mais solicitações do cliente da rede de fornecedor: configurar um ou mais nós da primeira categoria funcional em um ou mais dispositivos de computação de hardware de um ou mais centros de dados da rede de fornecedor; iniciar uma configuração de um ou mais nós da segunda categoria funcional em um ou mais dispositivos de computação de hardware da instalação externa à rede de fornecedor; e ativar um ou mais nós de ingestão de registros atribuídos ao fluxo de dados para começar a coletar registros de dados do fluxo particular.

26. Método, CARACTERIZADO por compreender: executar, por um ou mais dispositivos de computação de hardware: implementação de um conjunto de interfaces programáticas que permitem que um cliente de um serviço de gerenciamento de fluxo de dados selecione, para um fluxo específico, uma opção de posicionamento para uma ou mais categorias funcionais de nós do serviço de gerenciamento de fluxo, em que o serviço de gerenciamento de fluxo usa nós de uma pluralidade de categorias funcionais, incluindo pelo menos (a) nós de ingestão de dados e (b) nós de processamento de dados; recebimento, através de uma interface programática do conjunto de interfaces programáticas, de uma solicitação do cliente do serviço de gerenciamento de fluxo de dados, em que a solicitação especifica uma opção de posicionamento selecionada para um fluxo particular, em que a opção de posicionamento especificada na solicitação do cliente instrui o serviço de gerenciamento de fluxo para configurar um ou mais nós de uma primeira categoria funcional da pluralidade de categorias funcionais usando recursos com um primeiro perfil de segurança e instrui o serviço de gerenciamento de fluxo para configurar um ou mais nós de uma segunda categoria funcional da pluralidade de categorias funcionais usando recursos com um perfil de segurança diferente; em resposta à solicitação do cliente do serviço de gerenciamento de fluxo de dados: início de uma configuração de um ou mais nós da primeira categoria funcional em um primeiro recurso selecionado com o primeiro perfil de segurança, em que o primeiro recurso selecionado é implementado por um ou mais primeiros dispositivos de computação de hardware; e início de uma configuração de um ou mais nós da segunda categoria funcional em um segundo recurso selecionado com o perfil de segurança diferente, em que o segundo recurso selecionado é implementado por um ou mais segundos dispositivos de computação de hardware.

27. Mídia de armazenamento acessível por computador não transitório CARACTERIZADA por armazenar as instruções de programa de um serviço que, quando executadas em um ou mais processadores de hardware de computador, fazem um ou mais processadores: receber, a partir de um cliente do serviço, uma solicitação de configuração compreendendo uma opção de segurança selecionada para um fluxo de dados particular para o qual os nós de uma pluralidade de categorias funcionais devem ser configurados, em que a pluralidade de categorias funcionais compreende pelo menos uma categoria de ingestão de dados e uma categoria de recuperação de dados, em que a opção de segurança indica um perfil de segurança de um recurso a ser usado para um ou mais nós de pelo menos uma categoria funcional da pluralidade de categorias funcionais; em resposta à solicitação do cliente do serviço, configurar, de acordo com a solicitação compreendendo a opção de segurança selecionada, um nó de uma primeira categoria funcional da pelo menos uma categoria funcional em um recurso com um primeiro perfil de segurança, em que o recurso é implementado por um ou mais dispositivos de computação de hardware; e iniciar uma configuração de um nó de uma segunda categoria funcional da pluralidade de categorias funcionais em um recurso diferente com um perfil de segurança diferente, em que o recurso diferente é implementado por um ou mais dispositivos de computação de hardware diferentes.

28. Sistema, CARACTERIZADO por compreender: um ou mais dispositivos de computação compreendendo um ou mais respectivos processadores de hardware e memória e configurados para: receber, a partir de um cliente de um serviço de gerenciamento de fluxo, uma indicação de um ou mais atributos para particionar um fluxo de dados; determinar um mapeamento de registros de dados do fluxo de dados para uma pluralidade de partições do fluxo de dados com base pelo menos em valores diferentes do um ou mais atributos dos registros de dados indicados pelo cliente do serviço de gerenciamento de fluxo; e receber registros de dados individuais dos registros de dados do fluxo de dados em dois ou mais diferentes nós de ingestão, armazenamento ou outros do serviço de gerenciamento de fluxo com base, pelo menos, no mapeamento dos registros de dados do fluxo de dados para a pluralidade de partições do fluxo de dados.

29. Método, CARACTERIZADO por compreender: executar, por um ou mais dispositivos de computação de um serviço de gerenciamento de fluxo: recebimento, a partir de um cliente do serviço de gerenciamento de fluxo, de uma indicação de um ou mais atributos para particionar um fluxo de dados; determinação de um mapeamento de registros de dados do fluxo de dados para uma pluralidade de partições do fluxo de dados com base, pelo menos, em valores diferentes do um ou mais atributos dos registros de dados indicados pelo cliente do serviço de gerenciamento de fluxo; e recebimento dos registros de dados individuais dos registros de dados do fluxo de dados em dois ou mais diferentes nós de ingestão, armazenamento, ou outros do serviço de gerenciamento de fluxo com base, pelo menos, no mapeamento dos registros de dados do fluxo de dados para a pluralidade de partições do fluxo de dados.

30. Mídia de armazenamento acessível por computador não transitório CARACTERIZADA por armazenar instruções de programa que, quando executadas em um ou mais processadores, fazem com que o um ou mais processadores executem: recebimento, a partir de um cliente de um serviço de gerenciamento de fluxo, de uma indicação de um ou mais atributos para particionar um fluxo de dados; determinação de um mapeamento de registros de dados do fluxo de dados para uma pluralidade de partições do fluxo de dados com base, pelo menos, em valores diferentes do um ou mais atributos dos registros de dados indicados pelo cliente do serviço de gerenciamento de fluxo; e recebimento dos registros de dados individuais dos registros de dados do fluxo de dados em dois ou mais diferentes nós de ingestão, armazenamento, ou outros do serviço de gerenciamento de fluxo com base, pelo menos, no mapeamento dos registros de dados do fluxo de dados para a pluralidade de partições do fluxo de dados.

Images