WEBVTT

00:00:07.948 --> 00:00:10.718
Bem-vindo ao novo 
mundo Fast Data.

00:00:10.718 --> 00:00:14.791
A velocidade com que acontecem
as mudanças hoje, contínuas,

00:00:14.791 --> 00:00:18.431
num mundo de negócio
e na sociedade como um todo,

00:00:18.431 --> 00:00:21.331
exige que a computação
tenha novos padrões

00:00:21.331 --> 00:00:26.867
e acompanhe todo esse ritmo
com que acontece toda essa evolução.

00:00:26.867 --> 00:00:29.247
Então, para que possamos 
entender um pouco

00:00:29.247 --> 00:00:33.537
de como a maturidade da computação 
distribuída vem evoluindo

00:00:33.537 --> 00:00:37.377
e dando conta de impulsionar
toda essa transformação,

00:00:37.377 --> 00:00:39.817
nós vamos acompanhar
alguns tópicos aqui

00:00:39.817 --> 00:00:43.107
em relação à computação
baseada em streaming,

00:00:43.107 --> 00:00:46.657
baseada em processamento
real time,

00:00:46.657 --> 00:00:49.497
entendendo um pouco 
desses conceitos e soluções

00:00:49.497 --> 00:00:52.517
que estão sendo criadas
para resolver esses problemas.

00:00:52.517 --> 00:00:56.617
Então, uma das melhores definições
para esse processamento real time,

00:00:56.617 --> 00:00:58.867
é um processamento
de dados em movimento.

00:00:58.867 --> 00:01:00.567
E esse dado
é processado

00:01:00.567 --> 00:01:04.170
o mais próximo do momento 
que ele é produzido ou recebido.

00:01:04.170 --> 00:01:07.317
Então, é fluxo
contínuo de dados,

00:01:07.317 --> 00:01:10.657
onde esse processamento 
se torna mais near on-line.

00:01:10.657 --> 00:01:14.657
É difícil trabalhar 
com uma visão real time

00:01:14.657 --> 00:01:17.817
porque é uma fração
de milésimos de segundos,

00:01:17.817 --> 00:01:21.187
mas é muito simples entender
que ele está sendo processado

00:01:21.187 --> 00:01:23.077
à medida que ele está 
sendo produzido.

00:01:23.077 --> 00:01:25.217
Então, essa seria
a melhor definição.

00:01:25.727 --> 00:01:29.807
Esse fluxo também pode ser 
definido como fluxo de eventos.

00:01:29.807 --> 00:01:31.947
Então, nós produzimos 
muitos eventos,

00:01:31.947 --> 00:01:35.317
seja um evento para uma transação
financeira no e-commerce,

00:01:35.317 --> 00:01:40.218
um evento de transação
usando uma instituição bancária,

00:01:40.218 --> 00:01:43.628
pode ser um evento de log
numa operação de Telecom,

00:01:43.628 --> 00:01:47.814
podem ser hoje vários tipos de comunicação
em redes sociais, em mídias,

00:01:47.814 --> 00:01:52.122
que geram arquivos de log
ou mensagens de eventos.

00:01:52.122 --> 00:01:55.882
Então, nós começamos a criar
um modelo orientado a eventos,

00:01:55.882 --> 00:01:59.432
e esses eventos, que são
os dados produzidos,

00:01:59.432 --> 00:02:06.027
passam por um fluxo, porque existe
ali uma plataforma, uma solução,

00:02:06.027 --> 00:02:09.638
com uma capacidade bem grande 
de fazer esse processamento.

00:02:09.638 --> 00:02:12.148
Então, é comum quando
nós olhamos...

00:02:12.148 --> 00:02:14.718
Vamos pegar, por exemplo,
um case como o Uber.

00:02:14.718 --> 00:02:17.348
O Uber gera vários eventos,
são eventos de corridas,

00:02:17.348 --> 00:02:20.658
eventos do Uber Eats
para fazer entrega de alimentos.

00:02:20.658 --> 00:02:23.688
E, assim, nós temos 
uma quantidade enorme de eventos

00:02:23.688 --> 00:02:26.828
sendo gerados em várias
partes pelo mundo.

00:02:26.828 --> 00:02:28.878
É uma aplicação
que é fácil entender

00:02:28.878 --> 00:02:32.578
a necessidade de fazer esse 
processamento mais real time.

00:02:32.578 --> 00:02:36.698
Então, praticamente todas
as interações do Uber

00:02:36.698 --> 00:02:40.538
dependem desse processamento
mais real time.

00:02:40.538 --> 00:02:45.496
Acompanhando essa capacidade,
que trabalha em grande escala,

00:02:45.496 --> 00:02:48.866
e várias aplicações 
estão evoluindo dessa forma,

00:02:48.866 --> 00:02:53.155
nós precisamos de soluções
que suportem todo esse padrão

00:02:53.155 --> 00:02:54.985
da computação
distribuída.

00:02:54.985 --> 00:02:58.685
Então, nós vamos começar a entender 
um pouco desse fluxo de eventos

00:02:58.685 --> 00:03:02.065
baseado em um processamento
usando streaming.

00:03:02.065 --> 00:03:06.493
Então, streaming seria esse fluxo
contínuo de processamento.

00:03:06.493 --> 00:03:08.933
Às vezes nós usamos 
o termo streaming

00:03:08.933 --> 00:03:12.623
para falar de transmissão de vídeo,
transmissão de áudio,

00:03:12.623 --> 00:03:16.130
que também é um fluxo
contínuo de eventos

00:03:16.130 --> 00:03:18.432
ou de processamento 
de dados.

00:03:19.220 --> 00:03:22.270
Nesse exemplo, 
nós temos o input,

00:03:22.270 --> 00:03:25.320
esse input vai passar
dentro de um fluxo

00:03:25.320 --> 00:03:29.220
que evita a persistência 
em um banco de dados.

00:03:29.220 --> 00:03:32.250
Então, perceba que o fluxo,
à medida que ele é gerado,

00:03:32.250 --> 00:03:36.880
já é empurrado para ser processado
de alguma forma com essa engine,

00:03:36.880 --> 00:03:40.350
e, no final, nós estamos buscando
resolver algum problema.

00:03:40.350 --> 00:03:44.360
Pode ser um problema de transformação 
de dados na engenharia de dados,

00:03:44.360 --> 00:03:47.589
pode ser uma necessidade 
de tomada de decisão

00:03:47.589 --> 00:03:50.734
com um algoritmo
que vai usar esses dados

00:03:50.734 --> 00:03:54.724
para fazer uma recomendação,
para fazer uma análise de fraude.

00:03:54.724 --> 00:03:58.234
E, assim, nós conseguimos 
fazer um pipeline,

00:03:58.234 --> 00:04:00.794
que seria toda
essa visão do fluxo

00:04:00.794 --> 00:04:03.584
funcionando sem 
a necessidade de passar

00:04:03.584 --> 00:04:06.664
por algumas camadas 
lentas de persistência.

00:04:06.664 --> 00:04:09.674
Então, nós saímos daquele 
modelo batch, que é o padrão,

00:04:09.674 --> 00:04:13.594
onde começamos a trabalhar
com grandes volumes de Big Data.

00:04:13.594 --> 00:04:16.774
Foi aí que começaram
as soluções como o Hadoop,

00:04:16.774 --> 00:04:19.624
soluções mais 
conhecidas,

00:04:19.624 --> 00:04:21.774
que trabalham o armazenamento 
de grande escala

00:04:21.774 --> 00:04:23.824
para depois 
processar o dado.

00:04:23.824 --> 00:04:29.901
E o uso de muito recurso,
principalmente de memória,

00:04:29.901 --> 00:04:34.941
possibilita fazermos todo
esse fluxo sem esfriar o dado,

00:04:34.941 --> 00:04:39.416
ou seja, sem colocar esse dado 
numa camada mais fria de persistência.

00:04:39.416 --> 00:04:42.302
Então, é isso que permite 
ele responder

00:04:42.302 --> 00:04:45.188
com alta performance
e com menor latência.

00:04:46.242 --> 00:04:51.171
Um dos fatores que viabilizam
trabalhar com esse fluxo pesado

00:04:51.171 --> 00:04:54.941
de processamento de muitos
eventos real time,

00:04:54.941 --> 00:04:57.601
é porque nós vemos na linha 
do tempo que o custo de memória,

00:04:57.601 --> 00:05:00.051
o uso de memória,
caiu,

00:05:00.051 --> 00:05:04.051
e, com isso, nós conseguimos 
não só processar grande volume,

00:05:04.051 --> 00:05:07.021
mas manter esse 
volume nesse pipeline

00:05:07.021 --> 00:05:10.501
usando uma capacidade 
de memória maior.

00:05:10.501 --> 00:05:14.919
E a tendência é que trabalhemos
cada vez mais in memory,

00:05:14.919 --> 00:05:20.095
com soluções que armazenem 
de forma contínua esse dado em memória

00:05:20.095 --> 00:05:24.761
o tempo suficiente para resolver 
algum problema nesse pipeline.

00:05:24.761 --> 00:05:27.871
Então, isso também é
uma viabilidade recente.

00:05:27.871 --> 00:05:31.101
Não era viável tentarmos resolver
esses problemas em real time

00:05:31.101 --> 00:05:34.681
a algum tempo atrás por causa 
da maturidade da computação distribuída

00:05:34.681 --> 00:05:39.787
associada ao custo 
dos recursos computacionais.

00:05:39.787 --> 00:05:43.417
Nós já usamos vários exemplos
de casos de usos aplicados

00:05:43.417 --> 00:05:45.547
a processamento
real time.

00:05:45.547 --> 00:05:47.467
Então, temos exemplos
mais clássicos

00:05:47.467 --> 00:05:51.567
como recomendação para vendas,
por exemplo, no e-commerce,

00:05:51.567 --> 00:05:55.137
temos exemplos no setor financeiro, 
com análise de fraude.

00:05:55.137 --> 00:05:57.687
E, assim, nós temos 
criado cada vez mais

00:05:57.687 --> 00:06:01.067
essa capacidade de responder 
à necessidade de negócio

00:06:01.067 --> 00:06:03.898
com soluções
real time.

00:06:03.898 --> 00:06:06.777
Então, evento da indústria 4.0,
por exemplo,

00:06:06.777 --> 00:06:11.237
que depende de vários sensores 
coletando dados num processo produtivo,

00:06:11.237 --> 00:06:14.352
e esses processos podem 
passar por um streaming,

00:06:14.352 --> 00:06:18.572
onde vai ter um algoritmo
de detecção de anomalias

00:06:18.572 --> 00:06:23.762
para entender a possibilidade de ter 
um problema nesse processo produtivo

00:06:23.762 --> 00:06:27.943
e indicar isso como uma falha 
nos próximos cinco minutos.

00:06:27.943 --> 00:06:31.943
Então, quanto menor a janela
de tomada de decisão, maior o valor.

00:06:31.943 --> 00:06:35.943
E, com isso, toda essa viabilidade
vai mudando o mindset

00:06:35.943 --> 00:06:40.465
de como as áreas de negócio pensam 
no problema e pensam na solução,

00:06:40.465 --> 00:06:44.115
buscando cada vez mais 
aproximar esse time to market

00:06:44.115 --> 00:06:46.875
para tomada de decisão
no real time.

00:06:47.245 --> 00:06:50.845
E nós temos 
uma evolução natural

00:06:50.845 --> 00:06:52.705
sobre o conceito
dos microsserviços.

00:06:52.705 --> 00:06:55.645
Na engenharia de softwares,
nós começamos a desacoplar

00:06:55.645 --> 00:06:57.835
vários componentes 
computacionais

00:06:57.835 --> 00:07:02.545
e criar soluções mais flexíveis,
mais ágeis e mais evolutivas

00:07:02.545 --> 00:07:05.306
com o conceito 
de microsserviços.

00:07:05.306 --> 00:07:08.596
E quando nós falamos
de processamento streaming,

00:07:08.596 --> 00:07:10.526
esse processamento 
distribuído,

00:07:10.526 --> 00:07:12.986
principalmente
para tomada de decisão,

00:07:12.986 --> 00:07:16.506
nós começamos a usar
o termo event-driven,

00:07:16.506 --> 00:07:21.112
que seria você usar vários
pontos de medição.

00:07:21.112 --> 00:07:25.382
Pode ser controle de log,
controle de mensagem,

00:07:25.382 --> 00:07:31.430
controle de eventos, que são 
os registros captados por IoT,

00:07:31.430 --> 00:07:36.894
e através desses eventos nós 
vamos direcionando vários fluxos.

00:07:36.894 --> 00:07:40.794
Então, esses fluxos podem ser
encadeados num pipeline,

00:07:40.794 --> 00:07:43.714
e, com isso, nós passamos 
por transformação,

00:07:43.714 --> 00:07:47.364
por detecção, 
por discovery,

00:07:47.364 --> 00:07:50.724
e por tomadas de decisões 
cada vez mais inteligentes.

00:07:50.724 --> 00:07:55.014
Então, construir esses pipelines
dentro desse modelo

00:07:55.014 --> 00:07:58.354
também muda algumas características
no desenvolvimento.

00:07:58.354 --> 00:08:01.524
Então, à medida que nós não
dependemos da persistência,

00:08:01.524 --> 00:08:05.810
nós temos um estado que vai
acompanhando todo o fluxo,

00:08:05.810 --> 00:08:09.230
e, a partir dali, fica 
um pouco mais simples

00:08:09.230 --> 00:08:13.020
para que o código não 
tenha uma dependência

00:08:13.020 --> 00:08:16.780
desse processo 
de armazenamento.

00:08:16.780 --> 00:08:19.480
Então, ele fica um pouco 
mais independente

00:08:19.480 --> 00:08:25.661
e ele consegue seguir
o fluxo do início ao fim

00:08:25.661 --> 00:08:27.631
para resolver 
um determinado problema,

00:08:27.631 --> 00:08:31.105
como esses casos de usos
que nós mencionamos.

00:08:31.615 --> 00:08:34.531
Trabalhando dessa forma,
nós começamos a ver

00:08:34.531 --> 00:08:38.021
essa evolução de como
os eventos acontecem

00:08:38.021 --> 00:08:41.601
dentro de um processo
sequencial.

00:08:41.601 --> 00:08:46.109
Por exemplo: nessa imagem aqui
nós podemos ver uma sequência.

00:08:46.109 --> 00:08:51.028
E simplificando aqui, nós temos
eventos que estão numa ordem,

00:08:51.028 --> 00:08:55.838
e essa ordem vai chegando 
na camada de processamento

00:08:55.838 --> 00:08:58.211
e vai sendo
processada.

00:08:58.211 --> 00:08:59.658
Independentemente
da ordem que chegou,

00:08:59.658 --> 00:09:03.748
existe um controle para ele 
saber qual é a ordem correta

00:09:03.748 --> 00:09:06.678
para manter 
essa sequência.

00:09:06.678 --> 00:09:10.904
Então, o próprio código,
o próprio controle da arquitetura,

00:09:10.904 --> 00:09:15.605
se encarrega de organizar
esse processamento

00:09:15.605 --> 00:09:19.763
sem depender de uma indexação
física da persistência.

00:09:20.519 --> 00:09:23.039
E, aqui, nós temos esse exemplo
de uma camada superior,

00:09:23.039 --> 00:09:24.579
que são 
os "producers".

00:09:24.579 --> 00:09:28.509
É um nome usado 
para a entrada do dado.

00:09:28.509 --> 00:09:30.179
Então, esse dado está
sendo produzido,

00:09:30.179 --> 00:09:33.489
e, de alguma forma,
ele está sendo organizado.

00:09:33.489 --> 00:09:38.568
Pode ser, por exemplo,
através de uma camada de broker.

00:09:38.568 --> 00:09:42.128
E um exemplo de broker
bastante comum hoje é o Kafka.

00:09:42.128 --> 00:09:45.368
Então, o Kafka faz 
um armazenamento intermediário,

00:09:45.368 --> 00:09:48.118
e ele serve outras 
camadas de consumo,

00:09:48.118 --> 00:09:51.906
que são aplicações 
ou fluxos de processamento

00:09:51.906 --> 00:09:54.576
que vão buscar esse 
dado no broker

00:09:54.576 --> 00:09:58.936
e usar esses dados para fazer
processamentos com várias finalidades.

00:09:58.936 --> 00:10:03.754
Então, na parte inferior aqui,
nós temos dois consumers

00:10:03.754 --> 00:10:06.894
que estão buscando esse dado
em ordens aleatórias,

00:10:06.894 --> 00:10:08.864
de acordo com a necessidade
da aplicação,

00:10:08.864 --> 00:10:11.324
para fazer alguns 
processamentos.

00:10:11.324 --> 00:10:13.334
Então, vamos imaginar 
aqui que nós temos

00:10:13.334 --> 00:10:16.434
o evento que saiu lá do log,
que saiu do sensor,

00:10:16.434 --> 00:10:19.014
ele entrou nessa camada 
intermediária, que é o broker,

00:10:19.014 --> 00:10:22.711
que está organizando 
e garantindo uma persistência

00:10:22.711 --> 00:10:25.181
mesmo que ainda 
com alta velocidade,

00:10:25.181 --> 00:10:28.011
usando memória
distribuída, por exemplo.

00:10:28.011 --> 00:10:30.711
Nós temos na imagem aqui,
na parte superior,

00:10:30.711 --> 00:10:35.296
esses eventos acontecendo
com o input de alguns registros.

00:10:35.296 --> 00:10:38.896
E, de forma simples, nós estamos
contando aqui esses eventos,

00:10:38.896 --> 00:10:40.956
que tem 
um timestamp,

00:10:40.956 --> 00:10:46.621
e ele está contando os animais
relacionados à cada registro.

00:10:46.621 --> 00:10:49.901
Então, à medida que esse 
fluxo está acontecendo,

00:10:49.901 --> 00:10:51.711
nós temos essa 
linha do tempo,

00:10:51.711 --> 00:10:55.681
que é o streaming recebendo esses 
dados e fazendo o processamento.

00:10:55.681 --> 00:10:59.021
E na camada inferior
nós temos o pipeline,

00:10:59.021 --> 00:11:03.837
que pode ser, num caso
um pouco mais simplificado,

00:11:03.837 --> 00:11:06.137
um incremento
dessa contagem.

00:11:06.137 --> 00:11:09.537
Então, no estágio 
de um determinado horário,

00:11:09.537 --> 00:11:12.236
ele coloca janelas aqui
para facilitar.

00:11:12.236 --> 00:11:15.096
Esses eventos
são processados,

00:11:15.096 --> 00:11:18.376
e, eventualmente, pode ser
que um desses eventos

00:11:18.376 --> 00:11:20.706
tenha chegado 
com um delta de tempo

00:11:20.706 --> 00:11:25.056
e está com o time atrasado
dentro da sequência.

00:11:25.056 --> 00:11:29.056
Isso não tem importância porque ele vai 
conseguir resolver esse processamento

00:11:29.056 --> 00:11:31.229
e encaixar isso 
dentro do pipeline.

00:11:31.229 --> 00:11:35.386
Esse conceito de watermarking
consegue resolver isso na arquitetura.

00:11:35.386 --> 00:11:39.026
Então, a arquitetura também está
preparada para alta resiliência.

00:11:39.026 --> 00:11:45.021
Ou seja, é difícil você quebrar
esse processamento distribuído

00:11:45.021 --> 00:11:51.287
porque as próprias soluções
vão resolver isso com alta resiliência,

00:11:51.287 --> 00:11:57.464
e também garantir esses 
controles de sequência, por exemplo,

00:11:57.464 --> 00:11:59.119
num fluxo 
de processamento.

00:11:59.524 --> 00:12:02.644
Nós temos uma visão
de uma arquitetura moderna

00:12:02.644 --> 00:12:05.584
porque muita coisa foi
criada na última década.

00:12:05.584 --> 00:12:08.424
Então, as soluções que resolvem
isso em grande escala

00:12:08.424 --> 00:12:11.624
na computação distribuída
foram criadas recentemente

00:12:11.624 --> 00:12:15.094
e estão evoluindo cada vez mais
para trabalhar real time.

00:12:15.094 --> 00:12:18.264
E nós temos aqui, por exemplo,
no centro dessa visão,

00:12:18.264 --> 00:12:20.534
desse design, 
um broker,

00:12:20.534 --> 00:12:25.513
e esse broker tem esse armazenamento 
de eventos que escala.

00:12:25.513 --> 00:12:29.523
No caso aqui, se nós olharmos
o principal, que é o Kafka,

00:12:29.523 --> 00:12:33.567
escala com um número 
de acessos muito alto

00:12:33.567 --> 00:12:37.807
tanto para fazer a escrita
quanto para fazer a leitura.

00:12:37.807 --> 00:12:40.902
Nós podemos fazer aqui
um número de TPS

00:12:40.902 --> 00:12:45.202
maior que qualquer outro tipo 
de broker de mensagem, por exemplo,

00:12:45.202 --> 00:12:47.222
que nós 
tínhamos antes.

00:12:47.222 --> 00:12:50.072
Então, uma característica
é essa alta escalabilidade.

00:12:50.072 --> 00:12:52.332
E, com isso, nós 
podemos atender

00:12:52.332 --> 00:12:56.132
soluções de Big Data 
e conectar o legado,

00:12:56.132 --> 00:13:00.378
que já cria eventos de forma 
contínua através de SOA,

00:13:00.378 --> 00:13:01.978
através de algumas 
arquiteturas,

00:13:01.978 --> 00:13:05.798
para resolver esse problema
de uma forma integrada.

00:13:05.798 --> 00:13:10.218
Então, o pipeline tanto
para a parte operacional,

00:13:10.218 --> 00:13:12.338
transacional,
quanto analítico,

00:13:12.338 --> 00:13:16.508
vai seguir para esse padrão
de arquitetura moderna com real time.

00:13:16.508 --> 00:13:21.948
E o Kafka, que é um exemplo,
fica no meio dessa camada

00:13:21.951 --> 00:13:27.954
servindo como um organizador
de tópicos desses eventos,

00:13:27.954 --> 00:13:30.544
e, com isso, nós conseguimos
atender várias aplicações

00:13:30.544 --> 00:13:32.114
e vários
casos de uso,

00:13:32.114 --> 00:13:37.322
com o producer e o consumer
sendo integrados nesse ambiente.

00:13:37.322 --> 00:13:39.872
Então, é uma aplicação
amplamente usada.

00:13:39.872 --> 00:13:43.282
Praticamente todas as grandes
organizações e as startups

00:13:43.282 --> 00:13:46.732
estão evoluindo usando 
esse tipo de solução.

00:13:46.732 --> 00:13:52.896
O Apache Spark, que é o principal componente 
hoje de computação distribuída,

00:13:52.896 --> 00:13:56.801
também tem como 
uma das principais características

00:13:56.801 --> 00:13:59.888
o processamento de streaming,
além de outros processamentos.

00:13:59.888 --> 00:14:03.151
Apesar de ele ter sido construído
para trabalhar em batch,

00:14:03.151 --> 00:14:06.271
ele tem esse
componente streaming,

00:14:06.271 --> 00:14:10.091
que é um dos mais usados
e o mais difundido na comunidade,

00:14:10.091 --> 00:14:13.871
tanto nos movimentos open sources
quanto na criação de soluções

00:14:13.871 --> 00:14:16.181
para Big Data
Analytics.

00:14:16.181 --> 00:14:18.311
A engenharia de dados 
também tem usado bastante

00:14:18.311 --> 00:14:21.771
para fazer transformação
em processamento distribuído.

00:14:21.771 --> 00:14:26.139
Então, com certeza ele é hoje
um dos principais componentes

00:14:26.139 --> 00:14:29.409
da computação distribuída
baseada em streaming.

00:14:29.409 --> 00:14:33.579
O Apache Flink tem uma história
que também é recente.

00:14:33.579 --> 00:14:37.299
Ele foi criado quase junto
com o Spark na linha do tempo,

00:14:37.299 --> 00:14:39.649
2009, 2010.

00:14:39.649 --> 00:14:44.982
Ele foi criado na Alemanha e evoluiu
com a comunidade open source em 2014.

00:14:44.982 --> 00:14:49.815
Virou um projeto do Apache
junto com o Spark.

00:14:49.815 --> 00:14:52.225
E a principal diferença 
é que o Apache Flink

00:14:52.225 --> 00:14:54.615
foi construído para ser
um processamento streaming,

00:14:54.615 --> 00:14:57.655
diferentemente do Spark, 
que nasceu batch,

00:14:57.655 --> 00:15:01.385
e o streaming e o Spark
trabalham com microbatch.

00:15:01.385 --> 00:15:04.645
O Flink é o mais 
nativo possível

00:15:04.645 --> 00:15:08.265
para fazer esse processamento 
real time num padrão streaming.

00:15:08.265 --> 00:15:10.235
Então, tem algumas 
particularidades.

00:15:10.235 --> 00:15:12.075
Ele também não é
tão difundido.

00:15:12.075 --> 00:15:16.376
Apesar de ser bastante usado,
ele tem uma aplicabilidade menor

00:15:16.376 --> 00:15:19.946
comparado com o Spark, porque o Spark
tem muitas outras funcionalidades

00:15:19.946 --> 00:15:22.157
além de um processamento
streaming.

00:15:22.157 --> 00:15:26.287
Então, também é considerado
um dos principais componentes

00:15:26.287 --> 00:15:29.757
a serem avaliados por essa 
computação distribuída.

00:15:29.757 --> 00:15:33.067
Então, nós temos um futuro
que vai depender muito

00:15:33.067 --> 00:15:35.237
dessa computação
real time.

00:15:35.237 --> 00:15:36.757
Isto está
só começando.

00:15:36.757 --> 00:15:41.903
Cada vez mais as soluções vão ser
criadas e orientadas a eventos,

00:15:41.903 --> 00:15:46.661
e esses eventos impulsionados
pela tomada de decisão de negócio,

00:15:46.661 --> 00:15:51.258
que é acelerada pela
velocidade natural

00:15:51.258 --> 00:15:56.021
com que o mundo 
tem sido desafiado.

00:15:56.021 --> 00:15:58.941
Nós dependemos dessa
evolução computacional,

00:15:58.941 --> 00:16:00.251
que não ficou
para trás.

00:16:00.251 --> 00:16:04.081
Na verdade, a tendência
é que a computação

00:16:04.081 --> 00:16:06.511
vai direcionar 
a velocidade do mundo.

00:16:06.511 --> 00:16:10.151
Assim como está acontecendo,
nós vemos a computação quântica

00:16:10.151 --> 00:16:12.767
e muita coisa
que vem pela frente,

00:16:12.767 --> 00:16:14.561
e nós só estamos
começando

00:16:14.561 --> 00:16:16.745
toda essa jornada
para o Fast Data.