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.