Introdução aos sistemas distribuídos on-line para processamento de fluxos de dados – Parte I PROF. ANDRÉ LEON S. GRADVOHL, DR. 7/agosto/2015

Plano de apresentação Sobre o Palestrante. Histórico e motivação para a utilização de Complex Event Processing – CEP systems. Definição de sistemas CEP e conceitos importantes. Questões de tolerância a falhas envolvidas em sistemas CEP. Questões de escalabilidade envolvidas em sistemas CEP. Principais sistemas CEP atualmente e suas características. Perspectivas de pesquisa e desenvolvimento na área de sistemas distribuídos para processamento de fluxos de dados. 2 Parte I Parte II

Sobre o palestrante Prof. André Leon S. Gradvohl, Dr. Formação: Graduação em Computação, UFC (1997) Mestrado em Eng. Eletrônica e Computação, ITA (2000) Doutorado em Telecomunicações, FEEC/Unicamp (2005) Especialização em Jornalismo Científico, Labjor, Unicamp (2010) Pós-doutorado em Sistemas Distribuídos, Paris VI (2014) Linhas de pesquisa 3

Sobre o grupo de pesquisas do palestrante High Performance Intelligent Decision Systems – HighPIDS. Our research group works on design and implementation of decision support systems based on intelligent algorithms to work on high performance computer architectures. The goal of such algorithms is to solve semi-structured data mining and optimization problems. 4

Histórico e motivação para a utilização de Complex Event Processing – CEP systems Big data Streams Velocidade Variedade Volume Fluxos On-line 5 Exemplos: Análise financeira de ações em tempo real. Análise de tendências em redes sociais. Detecção de padrões de ataques a servidores.

Histórico e motivação para a utilização de Complex Event Processing – CEP systems Análise financeira em tempo real. 6 Dados são recebidos e permitem a recomendação de compra e venda de ações. Fonte: Oriani, F. B. Sistema para recomendação de compra e venda no mercado de ações utilizando Ensembles. Monografia de qualificação do Mestrado. Faculdade de Tecnologia/UNICAMP, 2015.

Histórico e motivação para a utilização de Complex Event Processing – CEP systems Análise de tendências em redes sociais. 7 Dados são recebidos e permitem a análise dos tópicos (textos) em redes sociais isoladamente ou em conjunto.

Histórico e motivação para a utilização de Complex Event Processing – CEP systems Detecção de padrões de ataques em servidores 8 Informações fornecidas pelos dispositivos de rede são analisadas para identificar padrões e evitar novas tentativas.

Histórico e motivação para a utilização de Complex Event Processing – CEP systems 9

Definição de sistemas CEP e conceitos importantes. Sistemas distribuídos para processamento online de eventos complexos Arquitetura genérica 10 Sistema de Processamento de Eventos Fluxo de dados Esses vértices são operadores. Eles realizam computações simples. Esses arcos são fluxos de dados. Eventualmente, alguns operadores salvam dados em disco. Alguns operadores podem estar juntos no mesmo nó de processamento. Os fluxos de dados podem vir de diferentes fontes (e. g. sites, celulares, sensores) Dados são processados pelos operadores e podem ser transformados por eles, antes de serem enviados a outros operadores. O grafo acíclico direcionado é a topologia do sistema.

Definição de sistemas CEP e conceitos importantes. Event Stream Processing – ESP ou Complex Event Processing – CEP São sistemas distribuídos Cada operador pode ficar em um nó de processamento e cada nó de processamento pode conter um ou mais operadores. Cada operador pode manter seu estado (stateful) ou não (stateless). Precisam ser executados continuamente. Dentro do possível, devem ser tolerantes as falhas, sempre disponíveis, escaláveis e elásticos. Precisam ter um bom desempenho Processar o maior número de eventos no menor tempo possível. 11

Questões de tolerância a falhas envolvidas em sistemas CEP. O principal elemento a ser observado são os operadores. Lembrar que esses operadores estão em um nó de processamento, mas um nó de processamento pode conter um ou mais operadores. São basicamente três tipos de técnicas para aumentar a tolerância a falhas: Replicação de componentes. Checkpoints. Upstream backup. Stateless e Stateful 12

Replicação de Componentes (operadores) 13 Supervisor Nó caiu!

Questões de tolerância a falhas envolvidas em sistemas CEP. Questões envolvidas na replicação de componentes: Se já estiverem instanciados, consumirão recursos (memória, cpu etc). Se não estiverem instanciados, sua instanciação consumirá tempo e acarretará na perda de tuplas, estouro de buffers. O supervisor deve ficar atento, observando toda a topologia, para tomar providências necessárias em caso de falhas. 14

Checkpoints 15 Não coordenado Cada operador salva seu estado em tempos diferentes. Coordenado Cada operador salva seu estado no mesmo tempo.

Questões de tolerância a falhas envolvidas em sistemas CEP. Questões envolvidas no Checkpoint: Checkpoints coordenados podem aumentar a latência do sistema, pois o tratamento do fluxo (stream) é suspenso para realizar o checkpoint. No entanto, o estado do sistema pode ser recuperado sem preocupações com consistências. Checkpoints não coordenados não impactam muito a latência do sistema, pois os nós upstream podem manter as tuplas nas filas. Contudo, são necessários algoritmos para verificar e garantir a consistência do sistema. 16

Fila de saída Fila de Entrada Arquitetura de um operador 17 Estado do processa- mento Estado de Rotea- mento

Fila de saída Fila de Entrada Item processado Nó caiu! Operador Upstream Operador Downstream Os itens seguintes só são enviados quando os últimos forem processados. Enquanto não forem confirmados, os itens são mantidos na fila de saída. Upstream backup (stateless) 18

Fila de saída Fila de Entrada Estado do processa- mento Estado de Rotea- mento Operador Upstream Operador Downstream Upstream backup (stateful) 19 Fila de saída Fila de Entrada Estado do processa- mento Estado de Rotea- mento De tempos em tempos

Questões de tolerância a falhas envolvidas em sistemas CEP. Questões envolvidas no upstream backup: No upstream backup para operadores stateless, a questão é o tamanho das filas de entrada e saída: Filas muito curtas podem acarretar em “buffer overflow”, se as confirmações demorarem. Filas muito longas podem consumir mais recursos e aumentar a latência. No upstream backup para operadores stateful, a questão é a propagação dos estados dos operadores. Em uma topologia muito extensa, propagar os estados pode aumentar a latência e causar perdas de tuplas. A consistência também pode ser um problema, se não for bem gerenciada. 20

Algumas Referências GOONETILLEKE, O. et al. Twitter analytics. ACM SIGKDD Explorations Newsletter, v. 16, p. 11–20, CHARDONNENS, T. et al. Big data analytics on high Velocity streams: A case study. IEEE International Conference on Big Data. out CHEN, Q.; HSU, M.; CASTELLANOS, M. Backtrack-Based Failure Recovery in Distributed Stream Processing. In: 14th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD), pp.261,266, 1-3 July GRADVOHL, A. L. S. et al. Comparing Distributed Online Stream Processing Systems Considering Fault Tolerance Issues. Journal of Emerging Technologies in Web Intelligence, v. 6, p ,

Perguntas? e Respostas! 22