Data Mesh: uma abordagem distribuída para dados

O que é Data Mesh? - Apresentação

Tudo bem, pessoal? Meu nome é Guilherme Silveira e vou estar aqui com vocês nesse curso de Introdução a Data Mesh. Esse curso vai mostrar para nós um pouco sobre arquiteturas existentes para lidar com grandes volumes de dados que as empresas hoje em dia já utilizam.

São padrões de arquiteturas, formas de trabalhar com o processo, o pipeline de dados, que já estão sendo utilizados em muitas empresas de médio e grande porte. Só que essas formas de trabalhar com dados possuem algumas características negativas, algumas desvantagens, como toda abordagem vai ter algumas desvantagens.

Vamos discutir nesse curso quais são algumas dessas características negativas, essas desvantagens de, por exemplo, um Data Lake, um Date Warehouse ou variações delas, e vamos introduzir o conceito de um Data Product.

Uma unidade bem pequena que vamos trabalhar em cima e expandir a importância dela dentro de um sistema, de uma organização, dentro dos vários sistemas existentes de uma organização que acabam formando o que conhecemos hoje como Data Mesh, que é uma outra forma de organizarmos esses processos e o compartilhamento de dados, o acesso e a produção, aos dados dentro das nossas organizações, das nossas empresas, dos nossos sistemas.

Então em vez de sistemas tradicionais, centralizadores, vamos ver de qual forma descentralizada ou parcialmente descentralizada conseguimos trabalhar para minimizar o tempo para colocar um produto novo de dados no nosso mercado, no nosso trabalho, na nossa empresa.

Então se tenho um sistema novo baseado no consumo de dados de diversas outras partes da minha empresa, quero diminuir o tempo para conseguir colocar esse produto em produção. Também quero ser capaz de ter novos sistemas, por exemplo, a minha empresa acabou de adquirir esse ano cinco outras empresas e tenho que colocar todos os sistemas dessas cinco empresas dentro do meu grande sistema que tenho na minha empresa atual.

Então tenho que fazer isso de uma forma que não seja tão dolorosa, que não leve tanto tempo. Também não quero que tenha problemas de comunicação entre quem utiliza dados e cria dados. Quero tentar diminuir esses problemas de comunicação.

E vamos falar como, aquela semente que falei do Data Product, um produto bem pequeno de dados vai crescer, virar um Data Mesh e com isso tenta resolver diversos desses problemas. E vamos discutir diversas dessas características.

Esse curso não é especificamente somente para uma cientista de dados ou um cientista de dados, não é só para quem trabalha com análise de dados, não é só para quem trabalha com Excel no dia a dia ou algo do gênero. Pode ser uma pessoa que não tenha conhecimento de programação? Não tem problema. Uma pessoa que tem conhecimento de programação? Também não tem problema.

Esse curso vai introduzir esses conceitos, entendermos como funciona essas arquiteturas para trabalhar com dados em Bets em grandes empresas, essas dificuldades e como o Data Mesh pode ser uma solução para solucionar alguns desses problemas, independente um pouco do nosso background de onde viemos. Essa é a ideia desse curso. Te vejo daqui a pouco na primeira aula. Até lá.

O que é Data Mesh? - Data Lake

Tudo bem, pessoal? Vamos começar o nosso curso. A nossa ideia é utilizar algum exemplo para falar sobre Data Mesh. E o exemplo legal é que como o conceito de Data Mesh acaba sendo aplicado para um momento em que empresas possuem muitas coisas, muitos produtos de dados acontecendo dentro daquela organização, vou usar uma empresa que é uma organização gigantesca, que é a Amazon.

Se pensarmos na Amazon e todas as empresas que ela já adquiriu, todas as empresas que ela já criou, todas as empresas que ela já forkou etc., tem muita coisa legal para explorarmos. Isso não significa necessariamente que a forma que a Amazon implementa as coisas é a forma que vou discutir aqui com vocês ou que vocês vão imaginar.

Porém, a ideia é que possamos explorar isso e pensar formas diferentes que poderíamos implementar diversas ideias. Então pensando na Amazon, vou começar com algumas áreas da Amazon. Estou usando a palavra área, uma área dentro da organização, mas pode ser um produto de negócio dentro daquela organização, pode ser uma empresa que a Amazon adquiriu.

Por exemplo, a Amazon Store que é a grande loja da Amazon, estou pensando nela como um grande site da Amazon. O site onde você faz as buscas, então, é uma unidade de negócio? Pode ser uma unidade de negócio, uma Business Unit, pode ser uma empresa, pode ser um CNPJ, alguma coisa do gênero.

Kindle. De novo, um grande produto que é o leitor de E-books etc., tem tantos aplicativos como as ferramentas de criação de livros digitais etc. Está tudo aqui dentro dessa área da empresa. GoodReads que é uma empresa que a Amazon adquiriu que é de reviews. Então você vai lá e fala sobre o que você achou de um livro.

Audible são AudioBooks gigante, também acho que a Amazon adquiriu muitos anos atrás. Também AudioBooks, livros em versão áudio. Alexa, mas aí você fala, "O que a Alexa tem a ver com os livros que você estava falando antes?" Parece que nada, mas vai ter.

Então Alexa é aquela assistente pessoal, assistente de inteligência artificial em que você fala, "Alexa, me dá um café" e ela traz um café para você. Não faz assim ainda, mas faz várias coisas. "Que horas são?" e ela responde. Não faz coisas mais complexas. Então Alexa também é uma área da empresa, um produto.

Prime Video é onde estão os vídeos e subscriptions, as assinaturas de vídeos, de filmes, de séries. IMDB também é um site comprado pela Amazon onde você tem informações e reviews também, listas, tops de filmes, Internet Movie Database, o banco de dados na Internet. Filmes, seriados e todas as produções audiovisuais do gênero.

Então são diversos produtos. Quando você pensa na organização da Amazon, você imagina todas essas áreas e a complexidade que é todos os produtos que existem em diversas dessas áreas porque diversas dessas tem mais de um produto até, pensando como um produto vendável. A Kindle tem diversos aplicativos, tem o aparelho físico, tem os livros.

E do lado da criação tem os aplicativos para ajudar na criação do E-book. Tem tudo isso. Tem a captação de novos autores e autoras. Tem tudo isso para pensarmos. Então, é muito grande cada um desses universos e tem intersecções. Então estou pensando sobre a complexidade e a riqueza.

Claro, na sua empresa, na sua organização você vai ter, talvez, menos produtos, menos áreas etc., talvez diversas e aí vai de você. E o que vou pensar? Do outro lado temos como utilizamos os dados gerados por essas empresas ou organizações.

Do lado esquerdo você vai pensar que diversas dessas tem sistemas em que executamos operações, transações. Então faço uma busca e compro um produto na Amazon. Leio um livro, dou um review ou leio um review, uma opinião, compro a assinatura de um AudioBook, por exemplo, faço uma pergunta para a Alexa. São sistemas operacionais em que fazemos operações, transações ocorrem. Esses são os sistemas.

Será que é um plano que é chamado esse plano de cima para baixo? É chamado de Operacional. Imagina um quadrado aqui, é chamado de Operacional. Por outro lado, enquanto esses sistemas geram dados, temos outros sistemas que vão processar esses dados de alguma forma.

Ou utilizar dados processados. São sistemas analíticos. São sistemas que os cientistas de dados, as pessoas Business Analysts, os analistas de dados, analistas de negócios utilizam. Por exemplo, gerar um dashboard de vendas. Estou vendo um exemplo aleatório que não está aqui nos meus exemplos.

Mas vamos para outros exemplos, uma campanha de Email Marketing. A campanha de Email Marketing vai usar dados de diversos lugares daqui. Forecast, prevermos as vendas da Amazon. Quero prever. Por quê? Porque preciso adquirir os produtos, ter eles distribuídos dentro do meu país, dentro das regiões adequadas para que quando for feita uma compra, saia barato e rápido enviar para algum lugar.

Não falte o produto e etc. Recomendações também utiliza dados. Então para recomendar, por exemplo, um livro, vou usar dados para você, vou usar dados da sua compra no Kindle, vou ver se você acabou de comprar a figura do Spider Man, do Homem-Aranha. Se você comprou um boneco do Homem-Aranha, adivinha? Vou te recomendar livros do Homem-Aranha para fazer sentido.

Se você comprou a boneca da Mulher Maravilha, vou te recomendar livros da Mulher Maravilha. Se você comprou bonecos da Vila Sésamo, vou te recomendar livros da Vila Sésamo e por aí vai. Livros de matemática. Vou entender um pouco sobre a demografia, entender um pouco sobre você e fazer recomendações.

Então, informações da Amazon Store, da Kindle, da GoodReads, do AudioBook, tudo isso serve para recomendar livros. Até mesmo da Alexa. Se você está perguntando questões do novo filme da Mulher Maravilha, já sei quais indicações de livros posso dar. Quem costuma gostar de produtos da Mulher Maravilha costuma ler esses livros e recomendo.

A análise de subscrição, de pessoas que desistem da assinatura do Prime da Amazon, por exemplo, então essa análise vai usar o máximo de informações que fizerem sentido. E o próprio catálogo da Amazon. O catálogo da Amazon tem que utilizar dados desses lugares para atualizar aqui.

Por exemplo, quando um filme está disponível agora ou não está, quando um livro novo foi criado ou não foi, tudo isso vai atualizar de alguma forma. Então, esses são cinco exemplos, entre aspas, simples, simples exemplos diretos que eu trouxe, de como utilizar dados gerados por todos esses sistemas.

Só que agora pensa, a galera do Email Marketing que vai mandar um e-mail falando, "Olha, recomendações desse mês para você comprar na Amazon". Essa galera que escreve esse e-mail vai ter que se conectar com o banco de dados da Amazon, vai ter que receber eventos do Kindle, vai ter que acessar o bucket do GoodReads, vai ter que acessar um sistema legado do AudioBook. Estou inventando.

Mas vai ter que fazer várias coisas de novo. Não sabemos necessariamente como é implementado o A, B, C ou D. Mas não importa. O que importa nessa realidade é que, à medida que escala essa complexidade desses sistemas, quem vai utilizar esses dados, vai ter que utilizar eles de diversas formas e em diversos lugares. E é um “fuzuê”, uma bagunça.

O que o pessoal começou a fazer? Coloca tudo isso em um lugar só. Em vez de a pessoa do Email Marketing Campaign ter que ter informações de trezentos lugares diferentes e lidar com tudo isso, coloca tudo dentro de um lugar só. Então começava a criar um super lugar. Vamos colocar um super lugar? Esse é o meu famoso super lugar. O super ligar está aqui.

E esse super lugar é onde vamos colocar tudo. Então, por exemplo, vou colocar os dados da Amazon Store aqui dentro. Então automaticamente todos os dados da Amazon Store vem para cá. Colocamos lá também todos os dados da Kindle. Da forma que estou fazendo está parecendo que é um único banco que é jogado para cá. Mas imagina, na verdade, tem diversos.

O Kindle tem as reviews que são feitas no Kindle. Então é jogado para cá. Tem as informações. Aí, de repente, em outro sistema, um outro tipo de sistema as seleções em que você só seleciona a frase, você faz suas marcações da frase. Então um desse sistema SQL e o outro desse sistema sei lá o que é que armazena isso.

Então vai jogar tudo lá dentro. O log do Kindle está lá também em algum lugar. Em algum lugar alguém joga esse log do Kindle, faz esse dump. Você vai jogando esses dados de todos os sistemas, de toda a nossa organização aqui dentro. Você vai jogando tudo isso. Tudo isso vai sendo jogado de alguma forma para algum lugar aí dentro.

E você vai jogando tudo isso de uma forma nada organizada, de uma forma um pouco organizada. Tem um limite aí do que é esse um pouco ou vou fazer de uma forma subjetiva isso, sem muito apego ao que é esse um pouco. E isso costumamos dar um nome.

Esse dump que fazemos, jogar esses dados dentro de uma forma minimamente organizada, pensamos em um grande oceano onde você vai jogando os dados. E os dados estão lá para quem quiser consumir em um único lugar que é o Data Lake. Esse é o Data Lake. É um lugar onde você joga todos esses dados.

E agora, quem quer consumir esses dados, basta ir lá em Email Marketing Campaign e precisa consumir esses três dados de três lugares, sabe que está tudo em um único lugar central, então consome desse único lugar central.

A análise de subscription, de assinaturas usa dois? Solta tudo nesse lugar central. Recomendação usa cinco? Cinco é muito, vai demorar até desenhar todas essas setas. Então vai lá e acessa esses cinco. Então o que estamos fazendo? Estamos colocando um lugar central que facilita executarmos essas perguntas.

Agora, claro, algumas dessas informações talvez eu quisesse em tempo real. Estou fazendo um dashboard de tempo real, talvez eu quisesse em tempo real. Algumas dessas informações quero de bet, de tempo em tempo. Quero atualização de 1 em 1 hora, de 1 em 1 dia, de mês em mês, de ano em ano.

Então tem diversas formas diferentes que queremos acessar um mesmo tipo de dado. Tenho uma mesma informação e quero acessar de diversas formas. Como faço isso? Vou ter que criar alguém que faz isso para mim. Outra coisa, vou querer agora, para eu poder acessar o Email Marketing e conseguir acessar os dados que quero, o Email Marketing precisa entender como funciona as informações de compra.

Só que, calma aí, quem é o responsável pelo Data Lake? Quem é o time responsável pelo Data Lake? Esse time tem um nome. Quem costuma criar tudo isso, é o time de Data Engineering, que é quem engenharia todo esse processo, toda essa arquitetura. Esse time é responsável por essa arquitetura.

E no momento em que esse time faz alguns processos para trazer esses dados daqui para dentro, você vai se comunicar com quem? Com esse time. Então se você precisa agora de um novo modo, "agora preciso que isso venha em IO Time para mim". Vou ter que conversar com o time de engenharia para o time de engenharia fazer isso para mim.

Só que adivinha o que acontece? O time de engenharia tem os pedidos meus, os pedidos da equipe de Forecast, os pedidos da equipe de Recomendação e de todos esses outros. Não só isso. Fizemos alguma alteração aqui desse lado? A equipe que vai atualizar o processo de jogar da esquerda para a direita é quem? O time de engenharia.

E o que vai acontecer com esse time de engenharia? Super Pipeline, uma lista de coisas a fazer. E você vai estar competindo as suas necessidades com todas as outras. Boa sorte. Qual é o problema? A equipe de pessoas especialistas em engenharia de dados não é gigantesca. Não temos pessoas infinitas no mercado para trabalhar isso para nós. É escasso e difícil contratar pessoas do gênero, especializadas nisso.

E aí entramos em um super problema. Quer dizer, se a sua empresa não passa por esse problema, sua empresa tem um Data Lake e funciona que é uma maravilha e escala essa complexidade de uma forma maravilha? Maravilha, siga em frente.

Você pode assistir a esse curso e entender quando vai valer a pena, porque vai valer a pena mudar, mas se isso é suficiente e está funcionando e você não está sentindo dores da complexidade dessas linhas doidas, vamos em frente. Essa é a ideia de não ir para Data Mesh. Não tem problema.

Agora, no momento que a sua arquitetura como essa tende na escala no volume de dados? Maravilha. Então, quer dizer, muitos dados sendo gerados. Maravilha. Ela tende a velocidade que você precisa consumir esses dados. Então, os dados que estão aqui dentro, você processa eles na direita, nos seus processadores em uma velocidade rápida? Maravilha. Isso são problemas que várias tecnologias resolvem.

O que é o problema que vamos tentar resolver com o Data Mesh? É a complexidade do número de sistemas. Você está crescendo no número de sistemas, da esquerda que são sistemas operacionais onde você transaciona coisas, que geram dados, ou sistemas que consomem dados.

Se esses caras estão crescendo em uma escala enorme, costuma trazer dor de cabeça para uma abordagem como o Data Lake. Ou uma abordagem mais bagunçada que é o Data Swap que simplesmente joga lá e não estou nem olhando para o que está fazendo. Joga ali e não estou nem aí, se virem. E aí mais trabalho ainda para essa equipe da direita.

Essas abordagens costumam trazer um problema por causa dessa complexidade aqui. se você sente essas dores, vamos trazer outra abordagem para tentar resolver esse problema. Essa é sacada que vamos ver aqui. Então, tentar fazer o quê? Tentar diminuir o trabalho dessa complexidade aproximando as pessoas da direita com as pessoas da esquerda.

Quem entende sobre o Kindle e os dados do Kindle e o que representa aquelas colunas ou aqueles dados ou aqueles logs etc., é a equipe que está no dia a dia lidando com esses dados operacionais. É essa equipe que entende. Então a comunicação entre você e quem gera os dados é muito mais rica do que entre você e uma equipe intermediária que processa os dados.

Por quê? Telefone sem fio. Não existe, não tem segredo. Coloca mais camadas de intermediação, você tem mais ruído entre essas camadas. Não importa. É estatística. Então vamos querer diminuir essa equipe intermediária. Vamos achar uma funcionalidade muito importante para essa equipe, e vai existir, só que não vai ser o papel dela de hoje em dia. Vai ser um papel um pouco diferente.

E é isso que vamos tentar entender. Então, sistemas operacionais na direita, sistemas analíticos, que fazem análises nos nossos dados, cientistas de dados, analistas de dados, analistas de negócios etc., e a equipe de engenharia de dados, com especializações específicas dentro da engenharia aqui no meio.

Esse é mais ou menos uma estrutura do Data Lake. Claro, existem variações, não se preocupe. Não é esse o nosso problema. Mas o ponto é entendermos o que é o problema que você pode estar sofrendo. E se você está sofrendo, o que vamos poder fazer? Vamos falar no próximo vídeo. Até mais.

O que é Data Mesh? - Data Warehouse

Tudo bem, pessoal? Lembra que falei do Data Lake? Aquele lugar onde se joga tudo e aí sai utilizando. Então quando paramos para pensar que a analogia que temos, uma analogia do mundo real, tenho a minha cozinha. Na minha cozinha guardo várias ferramentas, vários instrumentos, várias coisas que posso utilizar.

E posso ter uma gaveta que abro e coloco os garfos, as facas, colheres, palitos, hachi, Cheot-garak, seja lá o que for, copos, tigelas, pratos e coloco tudo naquela gaveta e fecho. Quer dizer, está tudo dentro de uma única gaveta. Quando abrir, tenho que conseguir pegar. E boa sorte para conseguir pegar.

Não vai estar bagunçado. Vai estar razoavelmente organizado como no Data Lake está razoavelmente organizado. Mas alguns estão enfileirados um do lado do outro. Alguns estão empilhados. Alguns estão na diagonal. Cada um está de um jeito ali. E vou ter que saber como pegar cada um daqueles.

Então o Data Lake acaba fazendo um pouco disso. Ele não necessariamente vai uniformizar muita coisa. A ideia é justamente essa, deixar o mais cru possível para que você possa fazer o que você quiser com aquilo. O problema é que isso te dá muito trabalho. Esse é um dos problemas. Um outro ponto que acho que é interessante lembrarmos, comentei de alguns usos do dia a dia.

Então alguns dos usos citei que é baseado, por exemplo, em um evento. Uma coisa acontece e já quero fazer. Por exemplo, aconteceu uma venda de um livro, quero atualizar o Ranking dos livros mais vendidos do dia, desse dia atual, desse instante. Porque se venderam mais de dez de um mesmo livro, talvez tenha mudado a posição do Ranking.

Então isso é baseado em evento. Aconteceu, recebo esse evento que aconteceu e processo. Ou quero fazer de bloco em bloco, de batch. O termo “batch”, em batch, de bloco em bloco. É quando falo assim, "Não quero calcular ao vivo". Não é analytics, uma análise que quero em tempo real. Quero fazer de bloco em bloco como, por exemplo, os livros mais vendidos do ano.

Aí não adianta eu for fazer agora porque é do ano passado. Os livros mais vendidos de dois mil e tantos. Então vou ter que reexecutar só quando acaba e aí executo para um bloco de uma vez só. Então é comum ter essas duas formas de uso. E tem uma terceira forma de uso também que é a sob demanda. Preciso de um garfo e aí vai alguém lá e te dá um garfo e você pega, que é uma API.

Costumamos usar como API, vocação remota, tem diversas variações para fazer isso da forma técnica como implementar. Mas aí preciso de alguma coisa. Você fala o que você precisa e alguém vai lá, pega e entrega para você. Nas outras duas formas você vai recebendo. E se parar para pensar na cozinha, por exemplo, quando eu recebo peixe em casa, preciso na hora já fatiar, posicionar para separar e congelar. Já preciso separar e processar naquele instante.

Quer dizer, é um evento quando chega um peixe em casa. Agora, cebola, quando chega cebola em casa, não vou fatiar na hora. Não estou a fim de fatiar a cebola na hora porque vou perder cebola. Não faz sentido nenhum. Na hora que precisa de um cebola, o que faço? Tenho duas opções, ou posso fazer em batch, em um grande processo.

Processa já todas as cebolas e guarda porque quero chorar uma única vez. Ou não, ou busco uma cebola, faço aquela cebola. Amanhã quando precisar, faço a outra cebola. Então, depende, vai ter várias formas de usarmos os nossos dados. E a sacada é que o Data Lake não está necessariamente padronizando isso tudo para nós. E ficamos sem padrão nenhum.

Muitas vezes sem padrão nenhum. Muitas vezes com padrão mínimo. Então qual alternativa que existe no mercado? E não necessariamente a ordem de criação é essa do mercado. Mas existe uma alternativa. Vou selecionar e jogar para baixo que é essa. Joguei para cá e daqui um pouco aparece. E esse outro que vem para cá e coloco para cá e vai aparecer.

Faço de novo alguma coisa intermediária. Então vamos ter algum lugar para armazenar tudo, só que de uma forma diferente. Antes armazenávamos como? Jogando as coisas de uma forma, entre aspas, crua lá dentro. Um pouco crua lá dentro. Agora quero fazer um pouco diferente.

Agora vou armazenar de uma forma, deixa eu copiar isso que é uma cola para mim para não ter que fazer toda vez, quero armazenar de uma forma um pouco mais interessante porque, por exemplo, vários desses possuem informações sobre livros. Então vou querer ter aqui alguma forma de representar livro. E esse modelo de um livro é meio que um modelo que tenta, de alguma forma, agrupar as características meio que globais.

Vou chamar essa de modelo mestre que todo mundo que olhar vai falar, "Nossa, é isso representa tudo o que gostaria de ser". Tudo o que um livro da Amazon gostaria de ser. Tudo o que um livro do Kindle gostaria de ser. Tudo o que um livro do Audible gostaria de ser. Então tudo o que um livro representa está aqui dentro.

Estou falando de uma forma vulgar para quem conhece os termos técnicos. E, de novo, existem refinamentos de como essa análise de modelo pode ser feita. Mas estou tentando dar uma linha geral de uma abordagem para entendermos quais são as dificuldades que vamos tentar passar e encontrar um meio termo. Não se apeguem tanto, "essa é a única forma". Não, não é. Tem diversas formas.

Mas tenho essa representação de livro. E da mesma forma que tenho uma representação de livro que é usado em diversos desses, tenho uma representação de outras coisas. Por exemplo, a representação de quê? De um filme. Tenho também a representação de outras coisas, por exemplo, a representação de uma "Avaliação".

Então tenho a representação de uma avaliação também. E assim você vai criando várias representações de várias coisas. Várias coisas você vai colocando lá dentro e maravilha. Agora que está tudo meio que de uma forma padronizada, quando precisar saber informações sobre um livro, o que vai ter?

A Amazon Store já vai ter preenchido livro. Kindle já vai ter trazido informações. GoodReads já vai ter trazido. Audible já vai ter trazido. Acho que é isso. Sobre filme, de repente, Prime Video vai ter trazido. O IMDB também. Acho que a Amazon Store também vai trazer informações sobre livro.

Avaliação? Amazon tem avaliação, Kindle tem avaliação, GoodReads tem avaliação, Audible não estou lembrando, faz tempo que não uso. Audible acho que tem avaliação. Alexa vou fingir que não. Não sei. Alexa tem avaliação de outras coisas, das skills. Prime Video tem avaliação, não necessariamente. Já vamos ver da mesma forma. Todo mundo tem avaliação. Curioso. Entre outros modelos.

Então todo mundo enfia “goela” abaixo esses modelos, de alguma forma, e todo mundo usa os modelos que quer. Se para o seu Email Marketing Campaign é só baseado em livro, você só vai usar livro. Não vou usar filme em avaliação. Mas se para Recomendação você usa avaliação e livro, então avaliação e livro.

E aqui é um lugar único de uma forma padronizada de uso. É uma forma um pouco mais organizada. Organizada é a palavra-chave aqui. Então, quer dizer, se tenho a gaveta da cozinha e abro, tenho, pelo menos, as coisas em um lugar separado com o mínimo de padrão. O mínimo ou o máximo de padrão de acordo com a normalização que você quer aplicar, entre outras coisas.

É uma palavra técnica para quem é da área de dados. Quem não é da área de dados não tem problema não saber. Mas você tem o mínimo de organização porque existem várias formas de pensar organização, o termo normalização é uma delas. E aí você acessa esses dados. Maravilha. Todo mundo feliz, todo mundo contente e não tem problema nenhum na vida. Não é verdade. Por quê?

Porque isso começa a ficar complexo novamente, vamos sempre acessar, mas essa é uma complexidade que não temos como tirar. O Email Marketing Campaign tem que utilizar informações de livro e de avaliação. Não tem como fugir disso. Vai precisar de informação de livro. Não, no caso, só de livro.

Mas Recomendação precisa de informação de livro e avaliação. Não tem como fugir dessa complexidade. Mas essa da esquerda, precisava de toda essa complexidade? Porque, de novo, essa complexidade vai aumentar em larga escala. Por que vai aumentar em larga escala? Porque é como no sistema anterior, no Data Lake, lembra que estamos discutindo de escalabilidade e não de volume de dados.

Não de tempo de processamento desses dados. Isso são questões resolvidas. Temos ferramentas, temos arquiteturas, as duas permitem arquiteturas que resolvem esses problemas. Claro, depende da escala. Agora, sistemas novos. A Amazon comprou uma empresa nova, comprou Twitch e agora você tem um monte de coisa nova.

E aí, o que você faz com isso? O que você faz com tudo isso, com todos esses sistemas novos? Vou ter que fazer agora um dumpão e usar um Data Lake ou vou pegar agora e mapear toda a doidera que o Twitch, que é para streamers, tudo o que o Twitch tem vou ter que mapear para todos os meus modelos. Percebe a complexidade que vamos ter que adicionar para poder mapear e incluir as coisas?

É uma complexidade. Precisava dessa complexidade sendo que nem sei quantas pessoas vão usar ou de que forma, qual estratégia uso para trazer esses dados novos para cá. Então à medida que os sistemas escalam, e aqui estou colocando sistemas que tem características diferentes, mas se você pensar, por exemplo, em uma rede de hospital, ela compra um hospital novo, os sistemas são muito similares.

E aí você vai ter que refazer esse mapeamento todo para um sistema muito similar. Aí você vai precisar de automatizações para facilitar. Você tem toda uma complexidade aqui que eu Guilherme estou, inclusive, escondendo de vocês. E essa complexidade se chama, adivinha? O pipeline que é todo o processamento... Vou jogar para trás, vou aprender e jogar, Send to Back.

Isso se chama pipeline que é o processo. O pipeline é um processo, é uma linha de um cano. Então é um cano onde vai fazendo várias coisas. Então várias coisas são executadas aqui. Por exemplo, descobri que um livro que está sendo referenciado pela Alexa é o mesmo livro que está sendo referenciado pelo Kindle.

Ou três livros, uma versão digital, uma versão Audible e a versão física. Os três livros têm SBNs distintos, mas representam, entre aspas, o mesmo conteúdo. Não necessariamente, páginas são diferentes entre esses livros. Então preciso, de alguma forma entre aspas, normalizar isso. Falar que esses três SBNs são o mesmo livro e jogar todos eles para a mesma representação no meu modelo master.

Então preciso ter esse processo de pipeline. O que antes tínhamos um de distância, agora temos dois de distância e temos quem cuidando disso tudo? Adivinha? As pessoas da nossa equipe de engenharia de dados. Toda essa galera automatizando, tentando automatizar todo esse processo.

E agora o Email Marketing quer entender esse livro. Dureza. Porque Email Marketing para entender esse livro, o Email Marketing fala assim, "Mas, estou mandando e-mail para os usuários da Amazon e estou vendo que no livro temos um campo representando o tempo. E não faz sentido. Livro não tem tempo.

Tem tempo esse livro? Não tem um atributo, uma característica. Não tem. É o tempo para ler? Uma pessoa leve em média 1 hora e aí ela escreve lá, "Uma pessoa leva em média 1 hora". E não era isso. Esse tempo tinha vindo de onde? Tinha vindo do Audible que é o tempo de duração do livro na versão Audio. percebe o problema que começamos a entrar agora?

Começamos a entrar em um problema, que é um problema clássico de tentarmos modelar diversos sistemas que são domínios diferentes, são áreas diferentes da humanidade. Trabalhamos, temos um entendimento de livro que existe uma forma genérica de pensarmos livros. Existe isso.

Só que essa forma genérica é muito difícil de ela conseguir manter também as formas específicas. Ela manter as características comuns a todos os livros, inclusive, as diferentes de uma forma que não gere confusão para quem vai consumir isso.

Aí você fala, "É só colocar uma descrição". Sim, você coloca, mas quem lê a descrição? Muita gente não lê a descrição. Tem formas. Tem namescape, tem várias formas que à medida que você entra no aspecto técnico, quem é da área técnica de engenharia, de dados etc., vai ter soluções. Se você não é, não se preocupe. É o teu foco.

O teu foco aqui é entender o que é tal do Data Mesh e para isso queremos entender o que é essa outra solução. Essa solução onde temos um grande armazenamento, a gaveta, e a gaveta tem o mínimo de organização. Então tem separadores para separar o garfo e a colher. E aí vem a pergunta. Temos na cultura americana o spoon, fork, spork.

O que é o spork? O spork é o garfo/colher. E aí o garfo/colher entra onde? Entra no garfo ou colher? Entra na separatória do garfo, entra na colher, entra no meio dos dois? Onde coloco esse spork? Então, quer dizer, você tem representações de modelos que são difíceis de tomar decisões na hora que tentamos padronizar tudo, formalizar tudo. É difícil, tem híbridos aí.

Então, você tem questões difíceis de serem resolvidas nessa modelagem master. Existem questões difíceis. Sabemos que em arquitetura não existe solução ideal para tudo. Então não quer dizer se você usa esse tipo de modelagem e funciona e resolve os seus problemas.

Agora, se você está sofrendo com essa modelagem, está sofrendo com essa complexidade, está sofrendo com manter o pipeline, está sofrendo que a equipe da direita gera os produtos de dados, não consegue entender esses dados ou que o processo é tão longo que o pipeline só traz os dados atualizados de três dias atrás, sendo que você queria isso em real time, em tempo real.

Esse processo é muito longe. Ou que, por exemplo, adicionou um novo sistema e você adicionar todo o pipeline, para você ter os dados daqui, para você poder consumir, demora muito tempo? Tudo isso é indicativo do quê? Que temos que cortar intermediários.

Entrou em um sistema novo, entrou no Twitch, para o meu sistema de Email Marketing Campaign poder recomendar coisas do Twitch, tenho que fazer com que todo o pipeline leve em consideração agora o Twitch. Todo o pipeline tem que ser atualizado.

Pode ser pequeno, pode ser longo, pode ser o que for, para atualizarmos os nossos modelos para aí eu poder atualizar o meu Email Marketing Campaign e poder acessar. Dependo de tudo isso, basicamente. Uma dependência muito grande. E aí é mais tempo para conseguir entregar o meu produto no mercado, a minha solução no mercado e também mais tempo para os dados chegarem aqui e começar a fornecer alguma coisa, trazer valor.

Então essa solução de grande dump organizado é chamado da Data Warehouse que é realmente um depósito, mas um depósito organizado. Porque se for o depósito do lado de casa, bagunçou. Mas é um depósito organizado que é o Warehouse, um centro de distribuição, algo do gênero.

Vou pensar mais como centro de distribuição que é organizado para que as pessoas tenham o mínimo de estrutura para que essas consultas sejam feitas de uma forma razoavelmente uniformizada. Tem essas estruturas.

Aí você fala, "Guilherme, então sempre Data Warehouse e nunca Data Lake". Pelo contrário. Muita gente vai defender Data Lake em vez de Data Warehouse justamente para te dar flexibilidade total. O problema de flexibilidade total sem estrutura nenhuma é que você tem flexibilidade total sem estrutura nenhuma. Boa sorte para dar estrutura e entender estrutura.

Problema de quanto mais estrutura melhor é que é difícil estruturar tudo e vamos ter problemas em estruturar. Percebe? Os dois tem problemas. Colocar esse caminho intermediário tem problemas. Então qual vai ser a nossa alternativa que vamos tentar apresentar? É arrancar todo o intermediário fora, literalmente.

Tentar diminuir os intermediários e fazer com que esses produtos que consomem dados, que vamos chamar de Data Product, um produto de dados, esses Data Products consumam diretamente de quem está fornecendo. E quem está fornecendo não é a Amazon Store, é um sistema lá dentro, porque tem vários sistemas, que fornece os dados que gostaria.

Essa é a ideia, que essa Data Product consuma direto do nosso fornecedor. Então vou ter um produto de dados gerando os dados para quem vai consumir e produtos gerando dados de quem gera os dados. Ficou ruim a frase. Mas muito próximo de quem gera esses dados.

Então a nossa solução vai ser arrancar intermediários que em várias áreas da tecnologia acabam fazendo com que as mudanças ocorram mais rápido. Só que como vou padronizar tudo isso? Tem várias questões que levantamos, que vamos ver nesse curso dessa forma que estou discutindo. Uma forma mais arquitetural.

E quem quiser depois entrar em áreas mais específicas, vamos ver em outros cursos também. Nesse curso específico vou querer discutir agora com vocês o que é um produto de dados e como veríamos esse produto de dados. Nosso próximo passo. Nos vemos na próxima.

Sobre o curso Data Mesh: uma abordagem distribuída para dados

O curso Data Mesh: uma abordagem distribuída para dados possui 130 minutos de vídeos, em um total de 25 atividades. Gostou? Conheça nossos outros cursos de Data Science em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• O que é Data Mesh?
• Data as a Product
• Domínios
• Governança e Descoberta
• Os quatro princípios