Alguém já ouviu falar algo sobre o título deste artigo? Se não ouviu, continue comigo que vou explicar. Se já ouviu, também continue por aqui, pois podemos trocar conhecimentos sobre o tema.
Serão dois artigos para falar do tema:
- O que é a Arquitetura de Malha de Dados?
- Como projetar/construir uma Arquitetura de Malha de Dados?
Entretanto antes de entrar no assunto, vamos relembrar alguns cenários dentro da área de TI que posteriormente provocaram o surgimento da arquitetura de malha de dados.
Quem já passou pelas seguintes situações?
– A área de TI é muito lenta para entregar um projeto.
– Todo esse tempo para construir o projeto?
– Vou contratar alguém e fazer dentro do departamento.
– Quando vocês me entregarem o projeto já não me serve mais.
– Não entrega no prazo.
Eu também já passei por todas essas situações. E concordo não é fácil agradar a todos. E é mais difícil ainda atender as necessidades dos usuários.
A alguns anos atrás, diante dessas reclamações e dificuldades algumas empresas começaram um movimento para tentar agilizar a construção dos projetos. Aqui tem alguns exemplos:
– Contratação de consultorias para a construção de projetos específicos
– Utilização da metodologia ágil
– Criação de equipes multidisciplinares (squads)
– Acesso diretamente aos dados para os usuários finais
Para conseguir tornar realidade um desenvolvimento mais ágil, as empresas utilizaram algumas dessas possibilidades. Ou até todas as possibilidades em conjunto.
Com todo esse movimento feito pelas empresas, recentemente surgiu um novo termo: Data Mesh Architecture. Traduzindo para o português, seria algo como: Arquitetura de Malha de Dados.
O termo pode ser novo. No entanto, o conceito por trás do termo não é novo. Já existe a alguns anos. Recentemente, o conceito cresceu e está invadindo as empresas. Mais e mais companhias estão adotando essa arquitetura.
Com o advento do Data Lake centralizado, as empresas perceberam que a equipe de dados de TI se tornou um gargalo para os novos projetos envolvendo Big Data. A equipe de dados não consegue lidar com toda a demanda, avaliar questões analíticas de gerenciamento e atender aos proprietários dos dados com a rapidez necessária. Desta forma, as pessoas que tomam decisões baseadas em dados ficam na mão e perdem oportunidades que podem ser cruciais para a empresa.
Por exemplo:
– Uma empresa de E-Commerce precisa responder rapidamente a uma questão de Black Friday ou as vésperas de datas importantes.
– Tem uma interdição ocorrendo em uma avenida importante. Devo mudar a rota do transporte para qual via?
– Mudo o layout de uma página web para aumentar a taxa de conversão de vendas as vésperas do Natal?
Essas e outras questões precisam de respostas rápidas e a equipe de TI não consegue dar vazão a essas respostas. Não conseguem porque estão na maior parte do tempo envolvidos em correções emergenciais para o que está em produção continue funcionando. Também precisam de tempo para entender o domínio dos dados para responder as questões. Ou seja, estão atolados até o pescoço com atividades diárias.
Se não é possível a equipe de TI responder as questões cruciais rapidamente, então as empresas começaram a investir em equipes autônomas que atendem a um departamento específico, por exemplo, vendas. Essas equipes são chamadas de “Equipes de Domínio Autônomas”. Essas equipes são especializadas em um domínio, conhecem muito bem os dados e conseguem atender rapidamente as necessidades do negócio.
Essas equipes, projetam, constroem e executam seus próprios aplicativos sem a necessidade da intervenção de TI.
Apesar dessas equipes serem independentes ainda precisavam de TI para obtenção de novos dados e insights necessários ao seu domínio. Isso é o suficiente para a empresa? Claro que não.
Como a responsabilidade dos dados continuava sendo de TI, o gargalo ainda estava ocorrendo. A solução foi transferir a responsabilidade da gestão de dados para as equipes de domínio. E é aqui que chegamos na ideia central da arquitetura da malha de dados, ops, Data Mesh.
Uma arquitetura de malha de dados permite que as equipes de domínio realizem análises de dados no seu próprio domínio ou até mesmo entre domínios por conta própria. Consegue também interconectar os dados de outros domínios, de forma semelhante às APIs em uma arquitetura de microsserviço.
Isso está ficando divertido.
O que é malha de dados ou Data Mesh?
O termo Data Mesh foi cunhado pela primeira vez por Zhamak Dehghani em 2019 e é baseado em quatro princípios que agrupam conceitos bem conhecidos.
– Propriedade do domínio
– Produto de Dados
– Plataforma de infraestrutura de dados de autoatendimento
– Governança federada
Vamos explicar cada princípio:
Propriedade de domínio: Exige que as equipes de domínio assumam a responsabilidade por seus dados. Ou seja, tem que garantir a qualidade dos dados, a disponibilidade dos dados, a governança sobre os dados, documentação de metadados, etc. Desta forma a equipe central de dados (TI) não tem mais ingerência sobre os dados da equipe de domínio.
Produto de dados: Os dados são tratados como um produto. Desta forma, assume-se que existem outras equipes que necessitam dos dados. Ou sejam, são consumidores para os dados além do domínio. Resumindo: Os dados do domínio devem ser tratados como uma API para que outras equipes possam acessar.
Plataforma de infraestrutura de dados de autoatendimento: É um local onde todos os dados estão hospedados. E ao mesmo tempo fornece funcionalidades, ferramentas e sistemas que permite criar, executar e manter os produtos de dados interoperáveis para todos os domínios.
Governança federada: Este princípio é crucial para que a Malha de Dados funcione eficientemente. Este princípio é a garantia de interoperabilidade de todos os produtos de dados através da padronização realizada em toda a malha de dados pela guilda de governança. A governança federada tem por objetivo garantir que o ecossistema de dados esteja aderente às regras organizacionais da empresa.
Abaixo uma visão da Arquitetura Data Mesh
Qual é a vantagem em ter Malha de Dados mantida pelas Equipes de Domínios?
Podemos destacar algumas vantagens:
– Dados disponíveis como produto.
– Rapidez na resposta a novas questões.
– Conhecimento mais aprofundado sobre os dados
– Independência no desenvolvimento de APIs para disponibilizar os dados
– Liberdade para obter outras fontes de dados (externas ou de outros domínios)
No próximo artigo vamos falar sobre como colocar em prática a Arquitetura de Malha de Dados (Data Mesh).
Aguardo vocês no próximo artigo.
