Data Mesh: dados como produtos

Data products - Apresentação

Tudo bem, pessoal? O meu nome é Guilherme Silveira. E estamos aqui para falar sobre Data Product. O que é um Data Product? Como criamos um Data Product? É um Data Product ou é um Data as a Product? E de onde aparece?

Como que naturalmente em todas as empresas, literalmente, todas as empresas, pode não ser 100%, que utilizam dados aparece um conceito próximo de Data Product. Faz sentido esse nome no contexto de cada empresa, e aí esse Data Product vai se desenvolvendo e vira algo muito maior com vários problemas que precisamos resolver.

E alguns desses problemas resolvemos de uma forma distribuída, descentralizada com questões que vamos abordar nesse curso. Então vamos falar sobre quem é responsável pelos dados, Data Ownership. Vamos falar sobre o manifesto de definição do que com Data Product. Como facilitar.

O que é o mínimo esperado por algumas pessoas para um Data Product. O que pode ser o mínimo esperado que você também espere, o quantum arquitetural mínimo. Sobre tipos de Data Product, uma taxonomia que classifica em Source alinhados a fonte, alinhados a consumidor e agregadores. Data Product agregadores, uma classificação possível.

Vamos falar de diversas características importantes. Vamos falar das portas de entrada e saída, como elas parecem similares, mas, na verdade, uma não tem nada a ver com a outra. Mas tem muito a ver com a outra, vamos falar disso também. Vamos falar sobre problemas de consistência eventual e de temporalidade.

Aí você fala, "Guilherme, eu sabia, sistemas distribuídos, você está colocando esse negócio de sistemas distribuídos e fazer esse produto". E lembro da regra do Martin Fowler, espero que seja do Martin Fowler, lembro daquela regra que fala "A primeira regra de sistemas distribuídos é não usar sistemas distribuídos". Lembro disso até hoje.

E lembro, eu, Guilherme, me lembro disso. Mas o problema de temporalidade não ocorre só quando vamos usar o Data Product nessa evolução arquitetural que é o Data Mesh. Ela ocorre em qualquer sistema de dados porque hoje em dia os dados são distribuídos.

Você fala, "Guilherme, mas na minha empresa uso o monolito. E o meu monolito tem para mim o banco de dados relacional". Sim, mas na hora que você cruza esses bancos de dados relacionais com arquivo de log, com e-mails enviados, com as respostas das pessoas, com CRM, com não sei o quê, os seus dados estão distribuídos e você acabou de ter os dados distribuídos e os famosos problemas de temporalidade.

Esses problemas estão aí nos esperando. E a questão é, como resolvemos? E se hoje você já tem eles e resolve simplesmente não ligando para eles e isso não te afeta e você está feliz, maravilha, porque continuará sem te afetar e você continuará sendo feliz. Agora, se isso te afeta, aí precisamos tratar e vamos ver como conseguimos com esse conceito de Data Product isolado, com diversas características que virão do Data Mesh dessa evolução.

Aí já na visão da Zhamak que agrupou várias questões e visões de como isso pode ser evoluído, como isso resolve e pode ser resolvido, os problemas de consciência eventual. Questões de identidades que também aparecem em sistemas distribuídos. Em quem confio e qual é a entidade? Qual livro? E quem é responsável por me dizer o que é um livro e o que tem nesse livro?

Como lidamos com isso de uma forma descentralizada e distribuída, distribuída e descentralizada. Como lidamos com a distribuição dos Data Products e as equipes, os papéis das pessoas e quais são os tipos de equipes que possuo, como lido com isso e como entrego o valor, como faço para implementar isso, por onde começo.

Por onde começar? Crio um Roadmap ou simplesmente saio implementando? Ou planejo tudo e depois implemento? Um pouco de sugestão também nesse caminho. Não é nosso foco principal. O foco principal é todo o resto que falei. Espero que vocês aproveitem e te vejo já já.

Data products - O que são data products

Tudo bem, pessoal? Vamos começar a falar sobre o que é um Data Product. Só um parênteses, se você fez o curso de Introdução a Data Mesh, essa primeira aula deve ser mais tranquila porque vamos introduzir o conceito de Data Product e como isso vai crescendo até virar um emaranhado de produtos de dados.

Então essa ideia do Data Product você já viu no curso de Data Mesh? Maravilha. Assiste essa aula com velocidade mais rápida. Você não viu? Veja essa aula comigo e no final da aula te convido para algumas opções próximas. Vamos lá.

O primeiro passo é o que é um produto de dados? O que é um Data Product? Podemos começar de diversas formas, vai ter diversas definições e vamos em frente. O que vou usar como Data Product é um pedaço de código. Esse código pode não ser um código, pouco código, muito código, configuração arrasta e solta, seja o que for.

Mas um pedaço de software, um código que vai rodar uma lógica, um algoritmo que vai rodar. Deixa eu colocar no diagrama, um algoritmo, um processo que vai rodar e esse algoritmo que vai rodar vai usar dados, esse é um Data Product.

Então o que ele vai usar? Vai usar dados. Então temos uma fonte de dados. Essa fonte de dados está aqui. E essa fonte vou utilizar no algoritmo, no processo. Vou colocar "Algoritmo". Por exemplo, se tenho um Recomendador de livros na Amazon, vou usar a Amazon como exemplo.

Uma loja on-line que vende diversas coisas. Vou usar o exemplo da Amazon porque é super rica, com muitas coisas diferentes, muitas empresas, sub-empresas, organizações etc., então dá para bolarmos muita coisa juntos. Então o Recomendador de livros da Amazon. Vou consumir os dados de algum lugar. Esse é o Data Product que recomenda livros e usa vários dados.

Por exemplo, posso usar os dados das compras dos livros. Então as compras dos livros que você fez eu vou utilizar para recomendar. Então esses dados vão entrar como entrada no sistema, em um algoritmo, e o algoritmo vai ter uma saída. É óbvio, ele tem que ter uma saída.

E essa saída vai ser um lugar que vou armazenar algum dado ou alguma coisa. Não precisa ser armazenamento. Estou dando só um exemplo. Então vou armazenar, por exemplo, um banco de dados SQL ou não NoSQL, não importa. Um banco de dados onde armazeno as recomendações. Isso é válido? É.

Esse amarelo é o Data Product. Aí você fala, "Guilherme, você vai consumir só as compras dos livros da pessoa?". Vamos parar para pensar, pode ter outros momentos onde isso também gera informações. As pessoas que usam sistemas geram informações, geram dados, na verdade, que vão virar informações para nós, que são úteis para o Recomendador de livros.

Por exemplo, posso ter quando a pessoa avalia um livro. De que adianta a pessoa comprar um livro, ler o livro e dar uma nota péssima? Aí o Recomendador tem que utilizar isso de alguma forma. Ou, às vezes, a pessoa dá uma avaliação porque ela já tinha o livro antes. Pensando em uma loja que vende livros físicos, digitais, seja lá o que for, já são duas fontes de dados para um Recomendador.

Então, o meu Data Product é esse do meio, tem duas entradas e uma saída. Essas entradas como entram? Através de um evento. Toda vez que tenho a compra de um livro, "Guilherme comprou um livro", esse evento é enviado para o Recomendador de livros. Ou, toda vez que, “Guilherme avalia um livro", esse evento é enviado para o Recomendador de livros. O Recomendador recalcula o que tem que recalcular e atualiza esse banco de dados da direita.

Na hora que ele atualiza esse banco de dados da direita, um outro sistema que vou colocar em verde, que é o sistema que mostra o Recomendador de informações, é o "Mostra Recomendações", ele vai buscar essas recomendações no banco e mostra para você.

Quando você acessa em algum site de alguma forma, “www.meusitedelivros.com.br”, busca e aparece uma seção com as recomendações, é esse sistema operacional, um sistema que faz operações, transaciona, que está sendo usado através de uma API, um GraphQL, um acesso direto a um banco, seja lá o que for, está acessando esse banco.

Então pode ser uma API, pode ser o que for, está acessando, trazendo as recomendações e te mostrando. Então quer dizer que se tenho na direita esse sistema operacional onde nós usuários operamos, do outro lado também temos o sistema operacional que é o sistema de, por exemplo, comprar livros.

Então esse sistema operacional que é onde compro livros, essa é a minha loja, na verdade. Então na loja que é um sistema grande, médio, pequeno, não sei, seja o que for, tenho um sistema de compras, não precisa ser o sistema de pagamento, não precisa ser o sistema de avaliação. Tem vários sistemas dentro da minha loja. No sistema de compras, então quando compro, percebe agora?

Na verdade, quando compro um livro, recebo, por exemplo, um evento. Então tenho aqui um evento. Aqui é "Livro comprado". Livro adquirido, comprado, seja lá o que for. Esse é o sistema de compras. Mas também tenho na loja, de repente, na mesma loja, um sistema de avaliações.

E esse sistema de avaliações também, de repente, envia mensagens toda vez que tem uma avaliação nova. Então "Nova avaliação", ou “Alteração de avaliação”, “Avaliação removida” e etc. E aí fazemos alguma coisa aqui. Da forma que desenhei, o que tenho?

Tenho sistemas operacionais onde seres humanos, provavelmente, geram dados, geramos dados, Data Product, e que isso consome dados e gera alguma coisa, gera alguma informação interessante para nós.

Essa informação pode ser armazenada, pode ser enviada para frente, para outros sistemas, pode ser mostrada em um dashboard, em uma tela, em um site com um resumo de informações, pode ser usada de qualquer outra forma, esses dados que foram gerados.

Então o Data Product é um transformador de dados. Basicamente, é isso. É uma forma vulgar, é uma forma bem mais ou menos de se dizer. Mais ou menos, no sentido de que não precisa dizer o que é, ao mesmo tempo sim e ao mesmo tempo não. É isso que é um Data Product. Dados para gerar dados que é uma coisa genérica.

Mas percebe qual é o poder? É que se vermos um Data Product dessa forma, e o Data Product acessa diretamente as suas fontes de dados, o que vai acontecer é que à medida que o sistema cresce, vamos ter cada mais novas fontes. Por exemplo, vou ter uma nova fonte, pensando na Amazon, temos o sistema da Alexa que você faz aquele assistente pessoal de inteligência artificial etc.

Então temos as perguntas que você faz para a Alexa. E à medida que você faz perguntas para a Alexa, uma pergunta sobre livro, por exemplo, “Você perguntou sobre um livro? Vou te recomendar”. Aqui estou filtrando as novas perguntas somente sobre livros.

Então aqui já tenho algum processo de filtro. Como será que esse processo de filtro pode acontecer? Pode ser várias ferramentas que utilizamos. Se estamos falando sobre evento, pensando no aspecto técnico, se esses sistemas operacionais estão despachando eventos, um sistema de eventos, seja um Kafka ou alguma outra coisa, o que vamos ter?

Podemos ter processadores que filtram, que recebem eventos e despacham um a um. Podemos ter processadores que recebem eventos e filtram por características daquela mensagem que está sendo recebida. Por exemplo, só vou filtrar perguntas relacionadas a livro. Pode ser algum que acumula.

Então, não vou querer enviar todo livro comprado a todo instante. Ou talvez sim. Você comprou um livro e é um evento muito importante. Então toda vez teve uma nova avaliação e é muito importante. Toda vez. Você fez uma pergunta, o peso não é tão grande, não vou querer ficar rodando toda vez. Isso é só uma vez por dia.

Então acumula e dá acesso em batches uma vez por dia. Blocos uma vez por dia. Se esses eventos são transformados pela tecnologia que você utiliza, não tem problema. E esses exemplos que dei, esses três específicos, são exemplos de que a mensagem vem da esquerda para a direita. Ela dá um stream, ela vem de cima para baixo, da esquerda para direita. Depende de como você desenha.

Mas poderia ter outros tipos de sistemas como, por exemplo, imagina que o IMDB, que é o Internet Movie Database da Amazon, imagina que lá no nosso caso o sistema de avaliação é um banco de dados SQL que você tem acesso direto, de repente, por qualquer motivo. Então nesse caso o Recomendador é quem acessa as avaliações.

Então do lado esquerdo Sistemas Operacionais e lá na direita também Sistema Operacional. O Data Product jogando em algum lugar de armazenamento. Poderia ser armazenamento, poderia ser outra coisa. Então essa é a ideia de um Data Product. Você tem diversas variações com querys.

Pode ser SQL, pode ser um GraphQL, uma API. Precisa ser um sistema interno? Não. Pode ser um sistema externo. Não importa. O que importa é que isso é um Data Product. Essa é a ideia de um Data Product. E essa ideia vai começar a crescer e vamos começar a discutir ela com mais carinho a partir de agora.

Isso traz algumas vantagens porque não temos intermediários que são equipes intermediando o nosso acesso direto aos dados e as pessoas que queremos conversar donas desses times nesses sistemas e etc. E temos uma comunicação direta com as pessoas, temos outros problemas porque agora qual é o padrão usado por tudo isso?

Existe um padrão. Como fazemos para que tenhamos uma governança? Como faço para padronizar não só a forma de acesso, mas o modo e a questão se tenho autorização para acessar esses dados ou não? Tenho autorização para acessar às perguntas da Alexa? Faz sentido acessar outros sistemas externos de outro grupo da Amazon? Será que posso? Será que não posso?

Em que situações tenho esse direito ou não tenho? Então tem várias questões de governança que vão acontecer aqui. E à medida que isso pipoca, começamos a ter muitos sistemas, entram outras perguntas. Como gerenciamos todos esses Data Products? Você começa a perceber que vai ter muito Data Product, vai ter muito sistema, muito Data Product. Quer dizer, faz sentido isso a medida que sua empresa cresceu na complexidade dos seus sistemas.

Na complexidade do seu sistema de crescimento e o sistema está atrasando? É um dos problemas que você está enfrentando? Então parece fazer sentido. Para quem não viu o curso de Data Mesh, discutimos diversos dos problemas que surgem a partir daqui. À medida que vamos crescendo isso, discutimos isso lá no curso de Data Mesh.

Se é o seu interesse, esse é um bom momento. Você fala, "Legal, entendi o que é a ideia de um Data Product, essa unidade. Estou percebendo que vou ter que ter várias necessidades e estou interessado em entender como vai ser e onde vou chegar lá longe no final". Assiste o curso de Data Mesh e depois volta aqui. Não tem problema nenhum se você já assistiu o curso de Data Mesh, é só continuar.

Agora se você está interessado ou interessada, "Quero entender melhor como funciona esse Data Product isoladamente e não tenho pressa de entender onde vou chegar e os detalhes de diversas dessas questões como governança e etc". Aí continua aqui porque nesse curso não vou atacar algumas dessas questões. No curso de Data Mesh conversamos sobre algumas dessas questões, sobre os problemas e como o Data Mesh tenta resolver isso.

Então lá tem algumas dessas soluções comentadas. Nesse curso vamos focar no Data Product em si. Em como entender, quais são as variações, porquê das variações, como fazer isso funcionar e etc. Então, resumindo, três opções. Se você já viu Data Mesh, é só continuar. Se você ainda não viu Data Mesh e quer entender alguns dos problemas de governança, de descoberta e outros pontos, faz o curso de Data Mesh. Vale a pena.

Se você está tranquilo, não está interessado nessas perguntas nesse instante, vamos entender mais sobre o Data Product. No momento em que você tiver interesse, "Quero saber a grande imagem disso tudo, Big picture". Beleza, uma visão acima, aí faz o curso de Data Mesh quando fizer sentido para você. Vamos em frente. Nos vemos daqui a pouco.

Data products - Responsabilidade pelos dados

Tudo bem, pessoal? Como citei, isso vai crescer. A nossa realidade é que começamos com Data Product no sistema e isso cresce. Então na medida que isso cresce, pensa no "Recomendador de Livros", vou colocar outro produto. Um produto que vai tentar entender na nossa empresa a necessidade de produtos a serem vendidos.

Por exemplo, se tenho um livro que perto da virada de ano, vende muito, o meu sistema tem que perceber isso para ter certeza que vou ter no estoque o suficiente para esses livros serem entregues. Então tenho que ter um sistema, por exemplo, um Data Product que faz a previsão de vendas. Para quê? Para que possamos, prevendo a venda, ter o suficiente para os nossos fornecedores.

Pedir o suficiente para os nossos fornecedores a tempo. Ter nos nossos centros de distribuição esse produto. No local adequado. Se sou de São Paulo, não adianta esses livros estarem do outro lado do Brasil. Se você é do outro lado do Brasil não adiante esses livros estarem em São Paulo porque vai demorar muito para chegar.

Então tentar otimizar esse processo. Como podemos? Prevendo. Prevendo pode ser um algoritmo de uma Machine Learning, por exemplo. Então estou dando dois exemplos de uma Machine Learning. Mas poderia ser exemplos de telas de dashboard, de relatórios analíticos e etc. Todos os Data Products poderiam estar fornecendo dados para relatórios analíticos, Top 50 livros, por exemplo. Um exemplo muito simples.

Então o que vamos utilizar? Vamos utilizar para previsão de vendas, temos que saber das vendas. Temos que saber isso. Todo livro comprado também vem para cá, também quero saber. "Livro comprado" também vem para cá. Então toda vez que vem um livro comprado também fico sabendo para poder prever as vendas.

Mas uma outra coisa são as queries da Alexa. As queries da Alexa, toda vez que você pergunta sobre um livro, também vou me preparar. Por quê? Porque se está perguntando sobre o livro, estou prevendo que vai aumentar as vendas daqui a pouco. Está aumentando, está ganhando tração as perguntas, essas vendas vão aumentar, por exemplo, estou imaginando.

Mas também um inventário para poder prever as vendas e necessidades. Aí preciso do inventário. O que poderia fazer? Poderia fazer um Data Project que já prevê as vendas e a necessidade de compras. Então para isso preciso do inventário, preciso saber quantos livros tenho. Vou colocar aqui o nosso inventário, aqui é o estoque.

Vou chamar de "Estoque", então só tem um sistema de estoque. Ou poderia ser dentro da loja, então ”Loja” já que tenho a Alexa e o IMDB e dentro da loja tenho o estoque. Poderia ser centro de distribuição etc. Qual é o sistema onde tenho isso? Na loja, no estoque, toda vez tenho que acessar aqui para saber, vamos supor que é um banco que eu mesmo acesso, ou um GraphQL ou API.

Então estou buscando disponibilidade desses objetos. Começou a ficar confuso. Mas vamos ver da esquerda para a direita. A previsão de vendas e necessidades, o que vamos fazer com isso? Tenho que fazer alguma coisa com isso. Vou enviar e-mails? O que vou fazer? Se for um evento, poderia ser enviar e-mails. Mas enviar os e-mails na hora que tem um problema? Não sei.

Talvez eu queira simplesmente armazenar e uma vez por mês você roda um processo, um relatório em que você faz algo. Você poderia automatizar e já fazer o pedido para o fornecedor. Você poderia. E aí vai para a sua fornecedora e já pede mais daquele produto para tal data. Poderia automatizar. Mas poderia, de repente, só armazenar porque quero um dashboard. Então poderia ser só um armazenar.

Então no Recomendador, deixei um armazenamento e aqui também armazenamento. Mas queria dar um exemplo de um que tenho, um "Dashboard de Alarmes". Aí você fala, "Guilherme, você poderia automatizar esse alarme já disparando um e-mail, disparando um contato com o fornecedor e fazendo um procurement etc". Poderia, você está certo.

Mas percebe já a confusão que está ficando aqui. Está ficando confuso. Sem contar que a saída de um desses, por exemplo, a saída do Recomendador poderia ser usada, adivinha para quem? Para a entrada da Previsão. Poderia usar direto daqui, mas seria meio estranho. Provavelmente você vai ter que tomar uma decisão. Se o Recomendador de Livros realmente armazena em um banco, provavelmente você vai querer, de alguma forma, usar esses dados de armazenados como fonte para cá.

Isso é em um banco? Não sei se você vai receber ou se vai buscar. Aí depende de qual é esse local de armazenamento. Mas percebe agora como ficou? Então aqui tenho as Recomendações. Você poderia falar, "Olha Gui, não vou conectar daqui, vou conectar daqui porque onde está armazenado você não desenhou, você não abriu onde que está armazenado". E você está certo. Não desenhei.

Então poderíamos colocar esse aqui dentro do Data Product. Poderíamos sim. Não estou colocando. Poderia ser que o Recomendador, na verdade, dispara eventos de Recomendações novas e que aqui simplesmente lemos as Recomendações, enquanto aqui realmente só armazenamos através de uma ferramenta. Poderia ser. Não estou falando que esse Design, essa forma de desenharmos seria ideal ou seria ruim.

São maneiras de desenharmos esse armazenamento. Vai depender do que você precisa, do que é ótimo para o seu sistema. Mas percebe que só dessa forma que fiz agora, vou jogar mais para cá, vou jogar mais para cá, olha como ficou. Olha o caos que está ficando. E essa é a verdade. Muitos de nós temos essa questão. Começamos em uma empresa pequena fazendo esses Data Products assim mesmo, dessa forma, isolando esses produtos e simplesmente criando de forma aleatória.

E isso gera alguns perigos. Um primeiro perigo é essa complexidade toda e não temos como esconder ela porque existe, você depende desses dados. Essa dependência existe entre esses dois lados. Vou mudar essa cor para vermelho para sabermos que todo mundo que está entrando é vermelho e todo mundo que está no outro produto é laranja. Ou poderia ser azul porque laranja já usei ali. E aqui também é vermelho porque está usando para esse outro.

Agora ficou um pouco mais claro. Mas o ponto era justo esse, mostrar a complexidade do que estamos lendo e do que estamos recebendo. E claro, se criamos os nossos Data Products de forma aleatória, vai começar a dar problema, por quê? Quem é responsável? Qual equipe é responsável por manter o Recomendador de dados? Qual equipe é responsável por manter esse código?

Qual equipe é responsável por manter essas conexões? E quando digo essas conexões, digo que o sistema de armazenamento que tem aqui ou não é o sistema que dispara e disponibiliza essas informações para lá. Isso é, quem é responsável por esses dados? Qual equipe, quais seres humanos são responsáveis por manter um código que desse lado de cá disponibiliza os dados com a qualidade necessária de limpeza, de direitos de acesso, de permissão, de segurança, de criptografia e tudo o mais?

Quem é responsável por isso nessa ponta? E na outra ponta? E no meio do caminho em trânsito? Pelos sistemas que mantém o trânsito. Quem é responsável por tudo isso? A galera que implementa a loja, o front-end e o back-end da loja? Não sei. A galera que implementa o Recomendador que é responsável por isso em todos os outros sistemas? Parece que não.

Então tem formas de pensarmos isso. E uma das formas é Data Lake, Data Warehouse, para quem tiver interesse pode ver no curso de Data Mesh. Aqui já vamos discutir direto, essa forma descentralizada, o que ela vai tentar fazer? Mesmo que tudo isso esteja no mesmo Cloud. Mesmo que todos esses dados estejam na mesma região, na mesma alguma coisa, na mesma storage de alguma forma.

Mesmo que estejam lá em uma mesma forma, em uma mesma conta, agrupamento, mesmo que esteja lá vamos manter essa distribuição de sistemas. Vamos trabalhar com sistemas distribuídos. E sabemos, sistemas distribuídos, pepinos à vista. Natural e sabemos disso. Então vamos trabalhar e resolver esse pepino. Qual é a vantagem que estamos vendo?

É a seguinte, quem vai ficar responsável por esses dados desse lado de cá é quem manja desses dados. Quem manja dos dados de compras é quem trabalha com as compras. Quem manja das avaliações é quem trabalha no sistema de avaliações. Quem manja dos dados de perguntas da Alexa, é quem trabalha nessa área da Alexa. Quem manja das avaliações IMDB é quem trabalha na IMDB.

Então a responsabilidade, o ownership, o dono, a dona, a pessoa que se sente responsável por aquilo, é a pessoa que já é responsável por aquilo, que já é responsável por gerar esses dados. Se já sou responsável por gerar esses dados, sou responsável pela qualidade desses dados.

É muito mais fácil para mim do que para uma outra pessoa ter que entender tudo o que entendo, eu ter que avisar ela de todas as mudanças no meu entendimento e na minha utilização desses dados para que ela intermedeie a comunicação com uma outra pessoa que vai utilizar. Se eu já sei e eu entendo bem, por que estou colocando alguém no meio que não sabe e não entende bem para intermediar alguém na outra ponta que vai utilizar? Telefone sem fio.

Então esse é o argumento, suas vantagens e desvantagens. Então é esse trabalho que vamos fazer agora, vamos começar a discutir cada vez mais. Essa abordagem de Data Product que vai virar uma Mesh, já virou uma Mesh, já está assim, essa abordagem traz problemas, traz vantagens que discutimos diversos pontos, governança, discovery etc., núcleo de Data Mesh.

Mas agora estou pensado. Realmente, produto, sistema, Data Product, sistemas operacionais, sistemas analíticos como esse dashboard de alarme, o próprio “Mostra Recomendações”. Você pode pensar como analítico operacional, depende de como isso é, esses sistemas, como podemos quebrar e trabalhar com eles. É muito disso que quero discutir com vocês. Vamos para o próximo vídeo.

Sobre o curso Data Mesh: dados como produtos

O curso Data Mesh: dados como produtos possui 153 minutos de vídeos, em um total de 30 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:

• Data products
• Taxonomia
• Portas e consistência
• Significado
• Business Domains
• Equipes