Arquitetura e governança de dados com Data Mesh: A visão de um bibliotecário no mundo dos dados
As organizações já entenderam o valor dos dados para os negócios e a cada dia elas buscam aprimorar o uso deles. Mas com o volume crescendo exponencialmente, problemas de organização e processamento dos dados foram surgindo.
Data lakes e Data lake houses se tornaram uma solução, mas em grande escala se tornaram um monstro que o time de engenharia de dados precisa administrar. Só que essa balança está pesando cada vez mais contra o time de engenharia de dados.
Então surge um novo paradigma: Data Mesh.
Nesse artigo irei introduzir o conceito de Data Mesh linkando com algumas conexões que fiz da minha formação em biblioteconomia.
Bora lá?!
Sumário:
Problemas estruturais
Data Mesh
Descentralização orientadas a domínio
Dados como produto
Taxonomias, ontologias e tesauros
Plataforma Self Service
Governança computacional federada
Data lineage
Considerações finais
Problemas estruturais
Vou utilizar como exemplo hipotético e de forma simplificada, os dados de uma biblioteca universitária.
Uma biblioteca pode ingerir muitos dados:
- Cadastro de alunos
- Todo o sistema da biblioteca física (empréstimos, devoluções acervo, usuários …)
- O sistema da biblioteca digital (acessos, acervo etc)
- Fontes de informações diversas, como as bases de dados bibliográficas
- Desempenho dos alunos nas avaliações (se você relacionar quais conhecimentos eles precisariam ter em cada questão de uma avaliação com as informações disponibilizadas pela biblioteca, poderia gerar um novo uso né?!)
E falando em uso, todos eles relacionados poderão gerar produtos incríveis:
- Recomendador de informações aos usuários (livros, artigos, vídeos, teses, bases de dados…)
- Dashboards analíticos do uso efetivo do acervo (não apenas empréstimos mas também analisar se os alunos estão usando o acervo como referência em seus trabalhos).
- Previsão do número de quais materiais serão emprestados
- Desenvolver um estudo de usuário correlacionando os dados de forma mais efetiva e entender melhor os não usuários
- Recomendador de novos itens para agregar ao acervo
…
Muuuuuitas coisas podem entrar e sair disso.
E o que é isso?
É uma plataforma com todo esse big data:
Só que se você olhar melhor ela, vai estar com os dados passando por um pipeline de transformações para fornecer dados aos clientes:
Clientes esses que para nosso exemplo podem ser: cientistas de dados, gestores das bibliotecas ou bibliotecários que utilizem para desenvolverem análises.
Também poderiam ser os próprios sistemas que usam esses dados para executarem algumas funcionalidades, como por exemplo usar o recomendador dentro da interface do usuário do sistema da biblioteca.
Tudo isso está na responsabilidade dos engenheiros de dados. Cada vez mais novas fontes e novas necessidades de clientes surgem.
E isso não está escalando na velocidade necessária.
Sem dizer que time de engenharia de dados não entende o que ocorre com os dados de origem em profundidade e também não conseguem fornecer dados com uma aplicação assertiva para as necessidades dos consumidores.
No final ninguém fica feliz e o negócio não entrega o valor esperado.
Data Mesh
A solução para o cenário anterior é a mudança do paradigma da arquitetura dos dados.
Criado por Zhamak Dehghani (diretora de tecnologia na Thoughtworks), em dois artigos publicados no blog do Martin Fowler (para quem não é da área de tecnologia, ele é uma das maiores referências em engenharia de software):
How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
No qual indico para sua leitura.
Assim como sua própria explicação (em inglês):
O paradigma é fundamentado em 4 princípios:
- Descentralização orientada a domínios
- Dados como produto
- Plataforma Self Service
- Governança computacional federada
Descentralização orientada a domínios
Ao invés de ter todos os dados em um único local eles estarão divididos por domínios.
Domínios são uma divisão dos dados a partir de uma estrutura lógica arquitetada para o próprio contexto da organização.
Por exemplo: poderia se ter um domínio usuários, que podem ser originados através de uma ou mais fontes de dados operacionais dos sistemas da universidade. Este domínio, fornecerá uma ou mais saídas de dados para que sejam analisados.
O domínio Usuários seria alimentado por fontes de dados de quem é usuário do sistema de bibliotecas. Então todos os dados dos usuários dos sistemas:
- Biblioteca física
- Biblioteca digital
- Repositório institucional
E outros domínios seriam criados com equipes mais próximas do entendimento destes dados suportando elas.
Como por exemplo um outro domínio: Acervo.
Que poderiam ter os dados do acervo da biblioteca física, biblioteca digital, do repositório institucional e das bases de bibliográficas assinadas.
Ou outro domínio como Uso da informação destes usuários sob o Acervo.
Seria formado por:
- Acessos a biblioteca digital
- Acessos ao repositório institucional
- Empréstimos e consultas da biblioteca física
- Utilização real do acervo (citações dos materiais do repositório sob as do acervo)
E um último para o exemplo de Desempenho Educacional.
Não sou da área da educação e apenas estou demonstrando um exemplo da ideia.
No caso seria um domínio com as notas das avaliações em cada disciplina, as notas das questões (assim entenderia quais conteúdos teve dificuldade), notas dos critérios de avaliação de projetos a serem entregues e até a frequência do aluno.
Todos estes domínios estariam ligados por APIs se comunicando e comunicando com os demais.
Dados como produto
Para que os dados não fiquem perdidos dentro de tantos nós desta “malha”, garantindo aqualidade, consistência e confiança.
Eles são tratados como produtos, que deverão deixar os clientes felizes
Por exemplo: com estes domínios traçados anteriormente, será fornecido uma API e o cliente poderá extrair para criar um recomendador de informações aos usuários.
Produto de dados é o Recomendador.
Mas para criá-lo, os cientistas de dados precisaram de outros produtos.
Os dados.
Os dados como produtos.
De acordo com a Zhamaki em seu artigo, os dados como produtos tem 3 principais características:
- Código: das pequenas transformações dos pipelines de dados, das APIs de fornecimento, da estrutura semântica e sintática, políticas de controle de acesso e governança.
- Dados e Metadados: o dado propriamente dito, com suas diversificadas formas e tipos que podem vir de origem. Estruturação dos metadados, para que possam ser utilizados, reutilizados, encontrados e catalogados em documentações computacionais.
- Infraestrutura: A infraestrutura permite toda a construção, criação e manutenção na execução do código.
Taxonomias, ontologias e tesauros
Como profissional da informação já comecei a perceber algumas relações que me chamaram muita atenção.
A criação e classificação de domínios e principalmente dos termos das colunas dos dados é um ponto que precisa ser contextualizado com a organização.
A arquitetura das relações entre si precisam ficar claras. Seja por uma estrutura hierárquica (taxonomia), semântica (ontologia) e sintático entre termos (tesauro).
Por exemplo a relação hierárquica (taxonomia) dos usuários:
E o usuários irão herdar os atributos dos alunos que possuem um desempenho educacional.
E ao ampliarmos um pouco mais esses domínios, percebemos a relação entre usuários, uso da informação e acervo:
Ainda mais, os autores dos materiais do acervo do repositório institucional, podem também serem alunos da universidade.
As ligações por APIs não são apenas ligações.
Há um sentido, uma lógica, uma semântica (uma ontologia) por detrás.
Tem muito a se aprofundar.
Ainda tem a relação dos metadados das tabelas, dos domínios.
Metadados que precisam ser entendidos e catalogados de acordo com seus significados.
Eles podem estar em duas ou mais tabelas com nomes diferentes porque áreas distintas nomearam desta forma, mas na realidade são a mesma informação.
Neste sentido enxergo as relações dos tesauros com controles de termos diferentes mas com o mesmo significado.
O desenvolvimento de um tesauro passa por diversas etapas com o entendimento do negócio, coleta de termos, classificação, estruturação e validação. Não caberá aqui neste momento eu traçar os termos de uma classificação com o Data mesh.
Plataforma Self Service
Com os dados descentralizados, não apenas eles ficaram mais próximos dos banco de dados operacionais mas também como os clientes ficaram próximos deles.
Mas as ferramentas que os clientes geralmente utilizam atualmente são incompatíveis com a ferramentas dos dados no lake.
Qual a solução?
Uma plataforma de interoperabilidade de dados que possuam serviços que tornem os clientes mais autônomos possível no desenvolvimento dos seus relatórios e tomada de decisão.
Ou seja, a arquitetura do data mesh tem que estar dentro de uma plataforma (um sistema) que converse com os produtos de dados e com os clientes de forma mais simples.
Eu ainda acrescento, um trabalho forte de alfabetização de dados (data literacy), para que os clientes possam desempenhar uma maior evolução.
Governança computacional federada
Ok! Temos dados por domínios, dados como produtos e uma plataforma self service.
Mas e como controlar os dados sensíveis dos domínios?
Como gerenciar quais clientes podem acessar qual conjunto de dados?
Como encontrar as tabelas e domínios de dados?
Através da governança computacional federada a cada domínio de dados. Dentro da plataforma a governança será automatizada, possuindo regras de para governanças individuais aos domínios e regras universais a todos os dados.
Data lineage
Em torno desta nova arquitetura de dados existem empresas como a Alvin que desenvolveram uma plataforma “plug and play” para realizar a ponte para os dados analíticos.
O mais incrível é que o software consegue saber o que ocorreu com cada metadado de diversas fontes ao decorrer nas transformações existentes. Também consegue simular outras alterações nas tabelas para verificar o que e quem esta mudança afetará.
Eu achei sensacional!
Confira aqui, o Medium deles com os artigos sobre a ferramenta.
Não deixe de assistir a palestra de um dos engenheiros de software da Alvin:
Eu cheguei na Alvin, atrás do Gabs Ferreira. Se você quer ficar antenado sobre tecnologia, segue as redes dele e assine sua newsletter que tenho certeza que é sucesso.
Considerações finais
Ao ver um novo paradigma deste, com uma ramificação tão grande de diversas áreas. Eu fico muito interessado.
Mas fiquei bastante contente da confirmação das minhas abstrações quando li este artigo do Juan Sequeda trazendo alguns pontos sobre Data Mesh e engenharia do conhecimento
Ainda tenho muito a me aprofundar no tema em diversos aspectos.
Para quem se interessou em aprofundar em ontologias, eu indico estes 3 livros:
Caso você tbm queira entender um pouco mais sobre web semântica, também vale a pena esse aqui também.
E meu estalo para estudar sobre Data Mesh, veio deste curso da Alura:
Se você não é aluno e também quer ser, confira o meu cupom de desconto.
E não deixe de escutar o podcast do hipsters que saiu mês passado sobre Data Mesh, está fantástico:
E você? O que pensa sobre o Data Mesh? Compartilhe nos comentários e vamos trocar conhecimentos.
Se você chegou até aqui e curtiu, dê palmas, compartilhe e se inscreva para me acompanhar.
Ainda há muito a se explorar…
