EBD CAP03 VA04 FAST DATA COM STREAM PROCESSING

Bem-vindo ao novo
mundo Fast Data.

A velocidade com que acontecem
as mudanças hoje, contínuas,

num mundo de negócio
e na sociedade como um todo,

exige que a computação
tenha novos padrões

e acompanhe todo esse ritmo
com que acontece toda essa evolução.

Então, para que possamos
entender um pouco

de como a maturidade da computação
distribuída vem evoluindo

e dando conta de impulsionar
toda essa transformação,

nós vamos acompanhar
alguns tópicos aqui

em relação à computação
baseada em streaming,

baseada em processamento
real time,

entendendo um pouco
desses conceitos e soluções

que estão sendo criadas
para resolver esses problemas.

Então, uma das melhores definições
para esse processamento real time,

é um processamento
de dados em movimento.

E esse dado
é processado

o mais próximo do momento
que ele é produzido ou recebido.

Então, é fluxo
contínuo de dados,

onde esse processamento
se torna mais near on-line.

É difícil trabalhar
com uma visão real time

porque é uma fração
de milésimos de segundos,

mas é muito simples entender
que ele está sendo processado

à medida que ele está
sendo produzido.

Então, essa seria
a melhor definição.

Esse fluxo também pode ser
definido como fluxo de eventos.

Então, nós produzimos
muitos eventos,

seja um evento para uma transação
financeira no e-commerce,

um evento de transação
usando uma instituição bancária,

pode ser um evento de log
numa operação de Telecom,

podem ser hoje vários tipos de comunicação
em redes sociais, em mídias,

que geram arquivos de log
ou mensagens de eventos.

Então, nós começamos a criar
um modelo orientado a eventos,

e esses eventos, que são
os dados produzidos,

passam por um fluxo, porque existe
ali uma plataforma, uma solução,

com uma capacidade bem grande
de fazer esse processamento.

Então, é comum quando
nós olhamos...

Vamos pegar, por exemplo,
um case como o Uber.

O Uber gera vários eventos,
são eventos de corridas,

eventos do Uber Eats
para fazer entrega de alimentos.

E, assim, nós temos
uma quantidade enorme de eventos

sendo gerados em várias
partes pelo mundo.

É uma aplicação
que é fácil entender

a necessidade de fazer esse
processamento mais real time.

Então, praticamente todas
as interações do Uber

dependem desse processamento
mais real time.

Acompanhando essa capacidade,
que trabalha em grande escala,

e várias aplicações
estão evoluindo dessa forma,

nós precisamos de soluções
que suportem todo esse padrão

da computação
distribuída.

Então, nós vamos começar a entender
um pouco desse fluxo de eventos

baseado em um processamento
usando streaming.

Então, streaming seria esse fluxo
contínuo de processamento.

Às vezes nós usamos
o termo streaming

para falar de transmissão de vídeo,
transmissão de áudio,

que também é um fluxo
contínuo de eventos

ou de processamento
de dados.

Nesse exemplo,
nós temos o input,

esse input vai passar
dentro de um fluxo

que evita a persistência
em um banco de dados.

Então, perceba que o fluxo,
à medida que ele é gerado,

já é empurrado para ser processado
de alguma forma com essa engine,

e, no final, nós estamos buscando
resolver algum problema.

Pode ser um problema de transformação
de dados na engenharia de dados,

pode ser uma necessidade
de tomada de decisão

com um algoritmo
que vai usar esses dados

para fazer uma recomendação,
para fazer uma análise de fraude.

E, assim, nós conseguimos
fazer um pipeline,

que seria toda
essa visão do fluxo

funcionando sem
a necessidade de passar

por algumas camadas
lentas de persistência.

Então, nós saímos daquele
modelo batch, que é o padrão,

onde começamos a trabalhar
com grandes volumes de Big Data.

Foi aí que começaram
as soluções como o Hadoop,

soluções mais
conhecidas,

que trabalham o armazenamento
de grande escala

para depois
processar o dado.

E o uso de muito recurso,
principalmente de memória,

possibilita fazermos todo
esse fluxo sem esfriar o dado,

ou seja, sem colocar esse dado
numa camada mais fria de persistência.

Então, é isso que permite
ele responder

com alta performance
e com menor latência.

Um dos fatores que viabilizam
trabalhar com esse fluxo pesado

de processamento de muitos
eventos real time,

é porque nós vemos na linha
do tempo que o custo de memória,

o uso de memória,
caiu,

e, com isso, nós conseguimos
não só processar grande volume,

mas manter esse
volume nesse pipeline

usando uma capacidade
de memória maior.

E a tendência é que trabalhemos
cada vez mais in memory,

com soluções que armazenem
de forma contínua esse dado em memória

o tempo suficiente para resolver
algum problema nesse pipeline.

Então, isso também é
uma viabilidade recente.

Não era viável tentarmos resolver
esses problemas em real time

a algum tempo atrás por causa
da maturidade da computação distribuída

associada ao custo
dos recursos computacionais.

Nós já usamos vários exemplos
de casos de usos aplicados

a processamento
real time.

Então, temos exemplos
mais clássicos

como recomendação para vendas,
por exemplo, no e-commerce,

temos exemplos no setor financeiro,
com análise de fraude.

E, assim, nós temos
criado cada vez mais

essa capacidade de responder
à necessidade de negócio

com soluções
real time.

Então, evento da indústria 4.0,
por exemplo,

que depende de vários sensores
coletando dados num processo produtivo,

e esses processos podem
passar por um streaming,

onde vai ter um algoritmo
de detecção de anomalias

para entender a possibilidade de ter
um problema nesse processo produtivo

e indicar isso como uma falha
nos próximos cinco minutos.

Então, quanto menor a janela
de tomada de decisão, maior o valor.

E, com isso, toda essa viabilidade
vai mudando o mindset

de como as áreas de negócio pensam
no problema e pensam na solução,

buscando cada vez mais
aproximar esse time to market

para tomada de decisão
no real time.

E nós temos
uma evolução natural

sobre o conceito
dos microsserviços.

Na engenharia de softwares,
nós começamos a desacoplar

vários componentes
computacionais

e criar soluções mais flexíveis,
mais ágeis e mais evolutivas

com o conceito
de microsserviços.

E quando nós falamos
de processamento streaming,

esse processamento
distribuído,

principalmente
para tomada de decisão,

nós começamos a usar
o termo event-driven,

que seria você usar vários
pontos de medição.

Pode ser controle de log,
controle de mensagem,

controle de eventos, que são
os registros captados por IoT,

e através desses eventos nós
vamos direcionando vários fluxos.

Então, esses fluxos podem ser
encadeados num pipeline,

e, com isso, nós passamos
por transformação,

por detecção,
por discovery,

e por tomadas de decisões
cada vez mais inteligentes.

Então, construir esses pipelines
dentro desse modelo

também muda algumas características
no desenvolvimento.

Então, à medida que nós não
dependemos da persistência,

nós temos um estado que vai
acompanhando todo o fluxo,

e, a partir dali, fica
um pouco mais simples

para que o código não
tenha uma dependência

desse processo
de armazenamento.

Então, ele fica um pouco
mais independente

e ele consegue seguir
o fluxo do início ao fim

para resolver
um determinado problema,

como esses casos de usos
que nós mencionamos.

Trabalhando dessa forma,
nós começamos a ver

essa evolução de como
os eventos acontecem

dentro de um processo
sequencial.

Por exemplo: nessa imagem aqui
nós podemos ver uma sequência.

E simplificando aqui, nós temos
eventos que estão numa ordem,

e essa ordem vai chegando
na camada de processamento

e vai sendo
processada.

Independentemente
da ordem que chegou,

existe um controle para ele
saber qual é a ordem correta

para manter
essa sequência.

Então, o próprio código,
o próprio controle da arquitetura,

se encarrega de organizar
esse processamento

sem depender de uma indexação
física da persistência.

E, aqui, nós temos esse exemplo
de uma camada superior,

que são
os "producers".

É um nome usado
para a entrada do dado.

Então, esse dado está
sendo produzido,

e, de alguma forma,
ele está sendo organizado.

Pode ser, por exemplo,
através de uma camada de broker.

E um exemplo de broker
bastante comum hoje é o Kafka.

Então, o Kafka faz
um armazenamento intermediário,

e ele serve outras
camadas de consumo,

que são aplicações
ou fluxos de processamento

que vão buscar esse
dado no broker

e usar esses dados para fazer
processamentos com várias finalidades.

Então, na parte inferior aqui,
nós temos dois consumers

que estão buscando esse dado
em ordens aleatórias,

de acordo com a necessidade
da aplicação,

para fazer alguns
processamentos.

Então, vamos imaginar
aqui que nós temos

o evento que saiu lá do log,
que saiu do sensor,

ele entrou nessa camada
intermediária, que é o broker,

que está organizando
e garantindo uma persistência

mesmo que ainda
com alta velocidade,

usando memória
distribuída, por exemplo.

Nós temos na imagem aqui,
na parte superior,

esses eventos acontecendo
com o input de alguns registros.

E, de forma simples, nós estamos
contando aqui esses eventos,

que tem
um timestamp,

e ele está contando os animais
relacionados à cada registro.

Então, à medida que esse
fluxo está acontecendo,

nós temos essa
linha do tempo,

que é o streaming recebendo esses
dados e fazendo o processamento.

E na camada inferior
nós temos o pipeline,

que pode ser, num caso
um pouco mais simplificado,

um incremento
dessa contagem.

Então, no estágio
de um determinado horário,

ele coloca janelas aqui
para facilitar.

Esses eventos
são processados,

e, eventualmente, pode ser
que um desses eventos

tenha chegado
com um delta de tempo

e está com o time atrasado
dentro da sequência.

Isso não tem importância porque ele vai
conseguir resolver esse processamento

e encaixar isso
dentro do pipeline.

Esse conceito de watermarking
consegue resolver isso na arquitetura.

Então, a arquitetura também está
preparada para alta resiliência.

Ou seja, é difícil você quebrar
esse processamento distribuído

porque as próprias soluções
vão resolver isso com alta resiliência,

e também garantir esses
controles de sequência, por exemplo,

num fluxo
de processamento.

Nós temos uma visão
de uma arquitetura moderna

porque muita coisa foi
criada na última década.

Então, as soluções que resolvem
isso em grande escala

na computação distribuída
foram criadas recentemente

e estão evoluindo cada vez mais
para trabalhar real time.

E nós temos aqui, por exemplo,
no centro dessa visão,

desse design,
um broker,

e esse broker tem esse armazenamento
de eventos que escala.

No caso aqui, se nós olharmos
o principal, que é o Kafka,

escala com um número
de acessos muito alto

tanto para fazer a escrita
quanto para fazer a leitura.

Nós podemos fazer aqui
um número de TPS

maior que qualquer outro tipo
de broker de mensagem, por exemplo,

que nós
tínhamos antes.

Então, uma característica
é essa alta escalabilidade.

E, com isso, nós
podemos atender

soluções de Big Data
e conectar o legado,

que já cria eventos de forma
contínua através de SOA,

através de algumas
arquiteturas,

para resolver esse problema
de uma forma integrada.

Então, o pipeline tanto
para a parte operacional,

transacional,
quanto analítico,

vai seguir para esse padrão
de arquitetura moderna com real time.

E o Kafka, que é um exemplo,
fica no meio dessa camada

servindo como um organizador
de tópicos desses eventos,

e, com isso, nós conseguimos
atender várias aplicações

e vários
casos de uso,

com o producer e o consumer
sendo integrados nesse ambiente.

Então, é uma aplicação
amplamente usada.

Praticamente todas as grandes
organizações e as startups

estão evoluindo usando
esse tipo de solução.

O Apache Spark, que é o principal componente
hoje de computação distribuída,

também tem como
uma das principais características

o processamento de streaming,
além de outros processamentos.

Apesar de ele ter sido construído
para trabalhar em batch,

ele tem esse
componente streaming,

que é um dos mais usados
e o mais difundido na comunidade,

tanto nos movimentos open sources
quanto na criação de soluções

para Big Data
Analytics.

A engenharia de dados
também tem usado bastante

para fazer transformação
em processamento distribuído.

Então, com certeza ele é hoje
um dos principais componentes

da computação distribuída
baseada em streaming.

O Apache Flink tem uma história
que também é recente.

Ele foi criado quase junto
com o Spark na linha do tempo,

2009, 2010.

Ele foi criado na Alemanha e evoluiu
com a comunidade open source em 2014.

Virou um projeto do Apache
junto com o Spark.

E a principal diferença
é que o Apache Flink

foi construído para ser
um processamento streaming,

diferentemente do Spark,
que nasceu batch,

e o streaming e o Spark
trabalham com microbatch.

O Flink é o mais
nativo possível

para fazer esse processamento
real time num padrão streaming.

Então, tem algumas
particularidades.

Ele também não é
tão difundido.

Apesar de ser bastante usado,
ele tem uma aplicabilidade menor

comparado com o Spark, porque o Spark
tem muitas outras funcionalidades

além de um processamento
streaming.

Então, também é considerado
um dos principais componentes

a serem avaliados por essa
computação distribuída.

Então, nós temos um futuro
que vai depender muito

dessa computação
real time.

Isto está
só começando.

Cada vez mais as soluções vão ser
criadas e orientadas a eventos,

e esses eventos impulsionados
pela tomada de decisão de negócio,

que é acelerada pela
velocidade natural

com que o mundo
tem sido desafiado.

Nós dependemos dessa
evolução computacional,

que não ficou
para trás.

Na verdade, a tendência
é que a computação

vai direcionar
a velocidade do mundo.

Assim como está acontecendo,
nós vemos a computação quântica

e muita coisa
que vem pela frente,

e nós só estamos
começando

toda essa jornada
para o Fast Data.