vimeo.com/.../1080186133

E você já deve ter se deparado
com algumas necessidades

diferentes no mesmo projeto,

onde você precisa capturar
dados em tempo real

e também dados históricos
e armazenar um grande volume disso

para usar o mesmo objetivo,
no final das contas,

e ter que casar tudo isso
em uma única arquitetura.

É disso que a gente vai falar agora,

falando um pouquinho
de arquitetura lambda.

Quando a gente fala
de arquitetura lambda,

eu estou falando de uma mescla
aqui de propósitos diferentes,

onde uma única arquitetura,
eu vou ter um único armazenamento,

mas eu vou atender
a diferentes propósitos.

Então, fica claro
que eu vou ter aqui,

provavelmente,
ferramentas distintas.

Eu tenho uma visão
que ela é a speed layer,

que a gente chama, ou seja,
a camada rápida.

Essa camada rápida,
eu capturo dados em tempo real.

Só recapitulando novamente
o que seria o dado em tempo real.

Não é a cada 10 segundos,
5 segundos, 3 segundos.

O dado em tempo real é, no momento
em que acontece uma mudança

na minha origem,

exatamente no mesmo momento
é disparado um gatilho,

que isso é levado
para o meu banco de dados.

Diferente do batch,
que, por exemplo,

se eu tiver uma carga
a cada 5 segundos,

ele vai esperar 5 segundos,
e tudo que aconteceu

nesses 5 segundos será levado
para o outro lado.

Por mais que o tempo seja pequeno,

essa segunda alternativa
de esperar os 5 segundos,

isso é uma carga em lote.

Não é tempo real.

Tempo real é, aconteceu, é enviado.

Aconteceu, é enviado.

E eu tenho também a carga em batch,
que é exatamente essa segunda opção.

Eu dei o exemplo aqui de 5 segundos,

mas, por exemplo, pode ser uma carga
que aconteça diariamente,

uma vez no dia.

Pode acontecer uma vez por semana,
pode acontecer uma vez por mês,

assim como também pode acontecer
de hora em hora.

Então, isso é a minha
arquitetura lambda.

E é disso que a gente vai falar
um pouco mais e vamos explorar

um pouquinho mais aqui.

Então, quando falamos aqui
de uma arquitetura lambda,

geralmente ela é composta
por 3 componentes aqui.

Aí eu tenho 3 camadas,
que nós costumamos chamar,

que são a speed layer,
a minha camada de batch

e a camada de serving, tá?

Vamos conhecer um pouquinho
mais de detalhe cada uma delas agora.

Eu tenho aqui o meu...

seguindo esse fluxo de dados
que nós temos aqui no nosso diagrama,

eu tenho aqui no número 1,
eu tenho o meu dado novo.

Eu tenho um dado entrante.

Então, esse dado, ele pode ser
tanto para a camada de batch layer,

que é a camada em lote, ou seja,

é aquele dado que ele tem
um horário para chegar.

Então, assim, a cada uma hora
eu tenho um processo que vai lá,

captura esse dado e traz ele.

E eu tenho a speed layer,
que é a camada em tempo real,

ou seja, aconteceu um evento,

automaticamente
vem para o meu banco de dados.

Aconteceu de novo,
ele vem para o meu banco de dados.

Pode ser um dado dessas duas
naturezas diferentes,

e cada uma vai ter
o seu processamento diferente,

porque, assim, demanda ferramentas
diferentes para fazer isso, tá?

Às vezes eu posso ter
uma ferramenta

que vai tratar tanto o dado
em batch quanto o dado em real-time?

Sim, na maioria das vezes
as ferramentas têm essa capacidade.

No entanto, elas vão trabalhar
de formas distintas aqui.

E, no final, eu tenho
o meu serving layer,

a minha camada de onde
eu vou servir esses dados,

onde eu vou disponibilizar
esses dados.

Vamos supor que eu estou trabalhando
aqui com cientistas de dados.

Eu sou aqui um engenheiro de dados

e eu sou responsável
por essa arquitetura.

Então, eu estou capturando dados
que vêm em lote, dados em tempo real.

E o meu cientista de dados
precisa disponibilizar esses dados

para os modelos
de machine learning dele, tá?

Então, essa camada de serving layer,
é uma camada onde eu vou ter aqui

as pessoas que vão consumir
esse dado, né?

Então, vocês podem ver aqui
que eu tenho ali as queries,

no item 5, as queries que vão dentro
do batch view ali, né?

Que são as visualizações
do in lote,

que são visões que a gente criou
da camada batch,

e eu também tenho a conexão
com os dados em tempo real.

Então, essa pessoa que vai
trabalhar ali no serving layer,

ele vai estar lendo esses dados,
vai estar trabalhando com esses dados.

Então, geralmente, é um ambiente
que a gente disponibiliza

que vai ter esse acesso a esses dados
já configurados, já com tudo certo

para ele trabalhar com isso.

Vamos dar uma olhada
em uma arquitetura

mais próximo da realidade.

Mais próximo não, na realidade.

Então, aqui eu trouxe uma arquitetura

que ela está em cima
de um cloud provider,

ou seja, em cima
de uma empresa que fornece cloud,

ferramentas, soluções de cloud

e nós temos exatamente
uma arquitetura lambda aqui.

Eu tenho dados que está vindo
em tempo real

e eu também tenho dados em batch,
dados em lote,

que estão sendo trabalhados aqui.

Vamos dar uma olhadinha aqui
como que funciona isso na prática,

em um ambiente de cloud.

Vamos observar aqui o diagrama,
onde eu tenho, por exemplo,

as minhas origens de dados.

Então, eu tenho aqui CRM,
operações, finanças,

recursos humanos
e streaming data, tá?

Eu tenho aqui uma conexão saindo,
para cá e outra aqui embaixo.

Veja que essa primeira conexão
está ligada aqui em data sources

de modo geral que representa todas
as outras quatro fontes de dados aqui

e o streaming data está conectado,
saindo sozinho para cá, né?

Ou seja, eu tenho aqui
o staging layer do meu data lake.

Ou seja, aqui ele captura
os dados em lote, em batch

e joga para cá, que é uma área
de staging, que a gente chama,

onde o dado vem
sem processamento.

Eu vou processar ele ainda
para armazenar ele arrumadinho,

bonitinho, tá?

E aqui embaixo eu tenho
o streaming layer, né?

Ou seja, a camada de ingestão aqui
que captura esse dado em tempo real.

Esse é o cara que dá o gatilho,
ele vai lá e acontecer um dado,

um evento novo, ele captura.

Observem que as ferramentas
aqui são diferentes, né?

Então, aqui em cima do data lake
eu tenho Azure Data Lake Storage,

Amazon S3, Hadoop.

Aqui embaixo eu tenho
o Azure Event Hub,

Amazon Kinesis, Apache Kafka,

que são ferramentas de captura
de dados em tempo real, tá?

Jogamos aqui para a parte
de processamento e query layer, né?

Então, eu tenho aqui
o meu data warehouse,

onde eu tenho os dados estão
sendo unidos aqui, tá?

Então, eu faço um processamento
aqui, um analytic services,

e eu armazeno aqui os dois dados.

E a partir daqui eu sigo
com uma camada de visualização.

Eu posso ter cubos aqui para poder
ter esse dado mais trabalhado, tá?

Camada de consumo e visualização.

Veja também
que do analytics service,

ele também segue direto
para visualização

e também para o consumption layer.

Porque tem algumas coisas
onde eu vou consumir

o meu dado que está vindo
em tempo real, diretamente.

Por exemplo, eu posso ter uma camada
de visualização como um Power BI,

que ele está conectado
a um dado em real time, tá?

Então, eu tenho um dado
que é histórico,

eu tenho um dado armazenado
de até, poxa, 5 minutos atrás,

tudo bem.

E esse dado é usado
para gerar gráficos,

para algumas coisas,

mas eu também tenho
um dado em real time

que está sendo alimentado,

alimentando diretamente
o meu dashboard, por exemplo,

que vai ter uma regra,
que vai ter uma análise,

que vai ter algum indicador em cima
desse dado em tempo real.

Então, aqui são os dois
fluxos distintos, tá?

Então, veja que o fluxo 1 aqui
é o meu dado em batch,

o fluxo 2 é o meu dado
em real time,

e veja que eles se unem aqui
em algum momento, né?

Então, eles estão juntos e misturados
aqui para atender tanto

a parte de consumo aqui,
seja por uma visualização

ou seja por algum aplicativo

ou alguma outra camada
que vai consumir isso.

De modo geral, falando
de uma maneira bem simples,

o que a gente tem do ponto de vista
de ingestão de dados, tá?

Então, camada batch é o meu dado
que eu vou pegar ele a cada X tempo.

Temos muitas ferramentas
para fazer isso.

Isso pode ser feito com Python,
pode ser feito com Spark,

pode ser feito com Scala,

pode ser feito com várias
ferramentas de mercado.

Agora, quando eu estou falando
de uma carga em tempo real,

ou um stream,
isso já fica um pouco mais complexo.

Por quê?

Estou falando de uma carga
aonde ela tem que acontecer

um evento de um lado,
ele já trazer para mim.

Ou seja, essa ferramenta tem
que ficar monitorando a origem, tá?

Então, não tem um momento
que ela vai lá e pega o que está pronto.

Ela tem que ficar monitorando.

Então, por isso que exige
ferramentas distintas,

ferramentas que vão
lidar com isso muito bem, tá?

Porque se não, novamente, se eu vou
lá a cada 5 segundos pegar os dados,

isso não é stream, não é dado real.

É batch também.

O tempo é pequeno?

Sim, mas ainda é batch.

Tratamentos diferentes e também
propósitos diferentes, tá, pessoal?

Porque não adianta eu querer ter
uma camada speed,

uma camada de dados
em real-time,

aonde eu vou ter várias etapas
de processamento e armazenamento

até esse dado ser consumido.

A hora que ele chegar lá
na ponta para ser consumido,

já se passou um tempo.

A tomada de decisão que era
para ser tomada naquele instante,

talvez já não adianta,
já não seja mais tão efetiva.

Se você não precisa ter
um dado em tempo real,

não vale a pena criar
essa camada speed.

Porque é um custo alto,
demanda ferramentas específicas,

e se você não vai consumir
ele imediatamente,

se ele não vai ter um gatilho
imediato dentro da sua arquitetura,

não vale a pena ter
uma camada como essa.

Quando olhamos aqui dentro
desse diagrama,

a gente vê várias fontes de dados
que podem ser planilhas,

arquivos, e-mail, whatsApp,
várias fontes de dados.

Temos dados aqui de mídias sociais,
temos dados de sistemas operacionais,

bancos de dados,
bancos de dados NoSQL,

diversas fontes de dados aqui
integradas e também IoT.

Então, nós temos aqui
dados de tudo que é fonte,

tudo que é formatos e fontes
que vocês imaginarem.

Camada de ingestão,
então, o modelo de ingestão aqui,

nós temos vários tipos,
self-service, armazenados, streaming,

on-demand, semantic, data-driven.

Então, aqui são as camadas
possíveis que a gente pode ter.

E o gerenciamento de dados.

Aqui, cada um deles vai ter...

Pode ser armazenado
em um formato diferente, né?

Como assim?

Poxa, eu tenho aqui...

Eu tenho bancos de dados NoSQL,
eu tenho MapReduce,

eu tenho banco colunar,
eu tenho banco de grafo, né?

Eu tenho bancos em memory,
por exemplo.

E eu tenho o nosso HDFS
aqui também, tá?

Então, tudo isso daqui
são possibilidades, né?

Eu posso ter cada uma dessas fontes
aqui, cada um desses data sources.

Possivelmente, numa arquitetura,

ele vai exigir um tipo
de armazenamento diferente, tá?

Dificilmente, apesar que hoje em dia
a gente tem bancos multimodais,

como Oracle 23ai, por exemplo,
que é tudo junto, né?

Então, eu tenho grafo,
eu tenho colunar, eu tenho vetorial,

eu tenho banco relacional,

eu tenho vários
tipos de bancos de dados, né?

Grafos, documentos,
dentro de uma única ferramenta.

Então, substituiria todo esse
data management aqui, né?

Substituiria ele, tá?

Mas isso é uma coisa
bastante nova, né?

Hoje, o que a gente tem, na maioria
das companhias, é ter a separação.

Então, dados de mídias sociais,

provavelmente vai parar
em um banco NoSQL, tá?

Dados aqui de operacionais,

possivelmente vai parar
em um banco mais estruturado, né?

Internet das coisas, possivelmente
em um banco de grafos ou um colunar.

Então, a gente teria
essa separaçãozinha aqui,

mas cada uma delas seria
feita uma ingestão em batch

para cada um deles, tá?

Parte de query management, né?

Então, área de transição

que seria o sandbox
e o data investigation.

Aqui a gente tem, por exemplo,

esse sandbox que é como
a gente cria hoje os ambientes

de processamento de dados.

Então, por exemplo, fiz a carga,

carreguei para dentro
de um banco de dados

ou vários bancos de dados
dentro da minha cloud, né?

Então, vem um cientista de dados
e ele vai trabalhar com esses dados.

Eu crio um sandbox para ele

que vai ter um pouquinho
de computação.

Então, por exemplo, 32GB
de processamento, 4, 8 vCPUs

e, às vezes, até GPU,
porque ele vai precisar.

E as fontes de dados já conectadas.

Por isso que isso faz parte
dessa arquitetura, tá?

Porque esses dados estão integrados
a essa área aqui, esse sandbox, tá?

Então, os cientistas de dados
conseguem lá trabalhar facilmente,

rapidamente, sem ter que fazer
um monte de integrações,

sem nada disso, tá?

E a parte de data investigation
também tem o mesmo propósito ali, tá?

E essa permanent area,
que são áreas de negócio

e sistemas integradores, tá?

Ou seja, qual é a diferença
entre elas?

Essa área de transição aqui
do sandbox do cientista de dados

é por projeto, tá?

Ou seja, o cientista de dados
veio trabalhar em um projeto,

vamos supor que seja de fraude.

Legal.

Quais dados ele precisa para trabalhar
nesse projeto de fraude?

Essa, essa, essa e essa fonte.

Legal.

A gente vai criar
esse ambiente para ele,

conectar essas fontes
e ele vai trabalhar.

Acabou o projeto,
isso aqui é apagado,

deixou de existir.

Esse sandbox morre, tá?

Nessa permanente area,

aqui a gente tem
as áreas de negócio

e sistemas integradores.

Ou seja, são conectores de dados
que a gente cria que vão ficar ali,

porque vai ter consumo
contínuo disso.

E aí, vamos falar um pouquinho
agora do speed layer, né?

Ou seja, aquela camada
que o dado é em real time, tá?

Ele também tem as origens,
pode ser uma rede social,

pode ser uma internet das coisas,
pode ser sensores de máquinas, né?

E pode ser outros bancos de dados.

Vamos supor que eu tenha lá
um mapeamento

que eu tenha que...

Apareceu uma compra nova, uma venda
nova, eu fiz uma venda nova.

Então, entrou uma venda
no meu sistema,

automaticamente eu quero
que ela vá para outro lugar.

Então, tem um gatilho ali
já de fazer isso aqui.

Automaticamente vendeu algo novo,
já é disparado automaticamente, tá?

Um caso bem interessante aqui, olha.

Vamos supor que você tenha
lá um monitoramento

de algumas partes comerciais
ali de ações no pregão

e a cotação do dólar.

Você acha que é interessante ter
a cotação do dólar em tempo real

ou você pode pegar ela
só no final do dia?

Ou de uma e uma hora?

Em tempo real, certo?

Então, se você faz negociações,
por exemplo, no pregão,

você tem que estar de olho
no valor do dólar,

no valor das ações ali
em tempo real.

Mudou um centavo que seja,
você tem que receber uma notificação.

Você tem que ter esse dado
para dar um gatilho, por exemplo,

nas suas negociações.

Então, vamos pegar um cenário aqui,

por exemplo, aonde você tenha
um dashboard,

onde você acompanha
diversas transações,

diversas coisas
que estão acontecendo.

E uma delas, você quer que,
dependendo do valor do dólar,

se ele subir muito,

suas transações podem
ficar comprometidas.

E se ele cair muito, você precisa
saber para, de repente,

acelerar as transações, tá?

E você tem um Power BI sobre isso.

Então, lá no Power BI, você conectou
numa API que informa, em tempo real,

o dado, o valor ali do dólar, né?

Então, automaticamente,
o que acontece?

Alterou o dólar,

ele manda esse valor novo
diretamente para o seu Power BI.

Seu Power BI tem uma regra
que, se passar de x valor,

por exemplo, R$5,50 o dólar,
ele vai ficar tudo vermelho.

Se cair para baixo de R$4,00,
por exemplo, ele vai ficar tudo verde,

os indicadores, tá?

É isso que vai acontecer.

Então, ele vai automaticamente
capturar esse dado

e já vai ter uma ação
aqui dentro, né?

E aí, por exemplo, aqui,
nessa camada que eu trago aqui,

nesse diagrama, nós temos aqui
um processamento muito maior, né?

Eu tenho a interface do usuário, tá?

Então, ele faz consulta
e entrega aqui nos dados.

Aqui, ele vai fazer o Kafka.

Faz o serviço de mensageria,
ou seja, captura os dados, né?

Então, ele vai lá, checa.

Checou?

Ele captura os dados e traz.

Então, ele está fazendo aqui,
capturando alguns pacotes, né?

Faz uma seleção de características
que joga aqui para um treinamento.

E aí, em tempo real, joga para cá
os metadados,

que faz um enriquecimento.

Então, assim, não só o valor do dólar,
mas ele pega o valor do dólar

e adiciona mais algum contexto,
mais alguma informação, né?

Classifica isso de alguma forma.

Traz alguma classificação aqui.

Faz aqui, joga aqui para busca
e armazenamento

e a interface do usuário
lê isso, tá?

Aqui está usando
o Elasticsearch e o Kibana,

que são ferramentas
que trabalham muito bem.

Contudo, com esse dado
em tempo real,

são plataformas
bastante pesada,

bastante dura para trabalhar
com isso, né?

Na captura está usando o Kafka,

no processamento aqui
está usando o Spark.

Então, essa aqui é uma arquitetura
que a gente pode ter.

E esse dado, veja que ele não vai
direto para a visualização.

Ele passa por alguns steps.

Só que são steps que têm
que ser muito rápido, tá?

Tem que ser muito rápido
e vai trazer mais informação,

vai agregar algo nesse dado
em tempo real.

E agora eu vou falar um pouquinho
sobre o algoritmo do MapReduce.

E como ele participa de tudo isso, né?

Então, nós temos aqui o MapReduce
dentro da arquitetura Lambda.

Ele vai ser o cara que vai também
ajudar a gente a processar

e buscar esse dado, né?

Então, eu posso ter, por exemplo,
dentro daquele diagrama...

Eu tenho a camada speed layer,
que pode processar

um pouco disso mais para frente.

Ele não vai ter a captura dos dados.

Ele não seria o responsável por isso,
mas vamos dizer que eu tenha lá

um Kafka que capturou
o dado em tempo real

e jogou para dentro de casa.

A partir daqui, talvez eu tenha
um MapReduce para distribuir isso,

para processar e entregar
na camada de front, né?

E em batch também.

E aí, vamos entender
mais ou menos como funciona

esse Map e depois o Reduce.

Então, olhando aqui
o nosso diagrama.

Eu tenho um input de dados, tá?

E ele vai fazer o Map, ou seja,
ele vai fazer o MapTasks aqui,

ele vai mapear tudo
que tem sobre isso,

depois ele vai reduzir isso
até fazer uma saída, ok?

Vamos colocar um exemplo
para ficar mais fácil, tá?

Eu tenho um bloco de dados aqui,
de entrada.

Tenho leão, urso, rio, carro, carro,
rio, leão, carro e urso.

Isso é o que eu tenho de dados.

Ele faz uma primeira abertura,
então, divide ali em três listas.

Três blocos de dados.

Então, leão, urso, rio, carro,
carro, rio, leão, carro e urso.

Observe que tem três.

Não é coincidência.

Eu tenho três blocos de dados,
três replicações, tá?

Legal.

E aí eu tenho lá, olha, o leão,
nesse primeiro bloquinho,

aparece uma vez,
o urso uma vez, o rio uma vez.

O carro uma vez, carro mais uma vez,
rio mais uma vez.

Leão, um, carro, um, urso, um.

Legal.

Aí eu faço agora o map, né?

Então, urso, um de um,
carro, um, um, um,

leão, um em um, rio, um em um.

O reduce.

Urso aparece dois,
carro três, leão dois, rio dois.

Então, assim, veja que nessa
camada anterior,

que ele faz urso um e um,
o que ele quer dizer?

Nos blocos,
o urso aparece no primeiro,

ele aparece uma vez,
e lá no último ele aparece uma vez.

Então, um e um.

Um mais um, basicamente.

O carro aparece um, um, um.

Ou seja, aparece três vezes.

Porque aparece duas vezes no segundo
bloco e uma vez no terceiro bloco.

Ou seja, a camada final ali
é um processamento,

é uma contagem de quantas vezes
essas palavras apareceram nos blocos.

O que eu tenho de saída?

Eu tenho urso que aparece duas vezes,
carro aparece três vezes,

leão aparece duas vezes,
e rio aparece duas vezes.

Essa é uma forma da gente olhar como
funciona o algoritmo do MapReduce.

Eu tenho uma entrada de dados.

Aqui, foram textos,
foram palavras, tá?

Agora, poderia ser
quantidade de vendas,

poderia ser uma série
de outras coisas

que eu faria esse split
desses dados,né?

Esses chunks aqui,
separaria em blocos.

E eu teria ali o mapeamento
do que tem, tá?

E faria um Reduce, né?

Seguindo toda essa contagem aqui,
essa separação e contagem.

E pense que cada um
desses caras aqui, olha,

desses verdes aqui, é um nó.

Então, cada um daria
a sua contribuição, né?

Vamos dizer que a pergunta
inicial aqui é...

Quantas vezes aparece cada palavra?

Essa é a pergunta.

Essa foi a minha query, né?

A query que eu escrevi ali foi...

Quantas vezes aparece cada palavra?

Cada um dos nós aqui
respondeu para mim, olha.

Leão aparece uma vez,
urso um, rio um.

O segundo nó, olha.

Carro um, carro um, rio um.

Terceiro nó, leão um,
carro um, urso um, né?

Então, eu tenho o quê?

Urso aparece um mais um,
carro um mais um mais um,

Leão um mais um, rio um mais um.

O final, então, é isso daqui.

Então, cada nó deu a sua
contribuição ali pra fazer, olha,

tipo, cara, comigo aqui nos meus
blocos de dados, eu tenho isso.

Eu tenho isso.

Eu tenho isso.

Juntou tudo e entregou o final.

Então, toda vez que a gente fala
de uma arquitetura lambda,

a gente tem um processamento misto.

Ou seja, eu tenho dados
que vem em tempo real,

eu tenho dados que vem em lote, tá?

E o MapReduce é uma ferramenta
que ajuda a gente a ter o processamento

no meio disso, tá?

Eu vou ter ferramentas que vão
capturar o meu dado em batch

e vão armazenar.

Eu vou ter ferramentas

que vai capturar
o meu dado em tempo real

e vai trazer para dentro
da arquitetura, né?

O MapReduce pode ser
a ferramenta aqui

no meio disso que vai ler tudo isso,

processar e trazer
uma informação no final.