This is the first of a two part presentation about on line distributed systems for data stream processing. It was presented at VI Escola Regional de Alto Desempenho, UNESP, São José do Rio Preto-SP. File in Portuguese.

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

2. 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

3. 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 emTelecomunicações, FEEC/Unicamp (2005)
• Especialização em Jornalismo Científico, Labjor, Unicamp (2010)
• Pós-doutorado em Sistemas Distribuídos, ParisVI (2014)
• Linhas de pesquisa
3

4. 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.
• http://highpids.ft.unicamp.br
4
We are always looking for great
graduate students.

5. 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.

6. 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 deTecnologia/UNICAMP, 2015.

7. 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.

8. 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.

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

10. 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
001001100110
010010001011
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)
<key_1, value_A><key_2, value_B><key_3, value_C>
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.

11. 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

12. 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

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

14. 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

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

16. 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

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

18. Fila de saída
Fila de Entrada
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

19. 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

20. 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

21. Algumas Referências
• GOONETILLEKE, O. et al.Twitter analytics. ACM SIGKDD Explorations
Newsletter, v. 16, p. 11–20, 2014.
• CHARDONNENS, T. et al. Big data analytics on highVelocity streams: A case
study. IEEE International Conference on Big Data. out. 2013.
• 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 2013.
• GRADVOHL, A. L. S. et al. Comparing Distributed Online Stream Processing
Systems Considering FaultTolerance Issues. Journal of Emerging
Technologies in Web Intelligence, v. 6, p. 174-179, 2014.
21

22. Perguntas? e Respostas!
22