Watch full webinar here: https://bit.ly/3pZUrE4
Um Data Mesh é uma infraestrutura de dados descentralizada e distribuída na qual vários domínios autônomos gerenciam e expõem seus próprios dados, chamados de "produtos de dados", para o resto da organização. O data mesh tenta eliminar os gargalos gerados pela dependência de equipes de TI centralizadas, bem como garantir que os usuários com conhecimento dos dados sejam os que tomam decisões sobre sua função e significado desses dados na empresa.
Nesta sessão, Evandro Pacolla, Sales Engineer da Denodo, explica como a virtualização de dados é sua melhor aposta para implementar uma arquitetura Data Mesh ágil e eficaz.
Nesta sessão, você aprenderá:
- Como um Data Mesh não apenas permite melhor desempenho e agilidade, mas também acesso a dados de autoatendimento;
- Os requisitos de "produtos de dados" em um Data Mesh;
- Como implementar um Data Mesh simples e funcional usando a virtualização de dados;
- Por que um Data Lake não é a melhor opção para implementar um Data Mesh;
- Como a virtualização de dados permite que os domínios de um Data Mesh sejam realmente autônomos.
4. 4
▪ Data Mesh é um novo modelo de gerenciamento de dados
▪ Proposto por Zhamak Dehghani da ThoughWorks em
2019
▪ Passa de uma infraestrutura centralizada de gestão de dados
por uma única equipe, para uma organização mais distribuída.
▪ Várias unidades autônomas (domínios) são encarregadas de
gerenciar e expor seus próprios "Produtos de Dados" para o
resto da organização.
▪ Os "Produtos de Dados" devem ser fáceis de usar,
documentados e acessíveis ao resto da organização.
O que é uma Data Mesh?
5. 5
1. Falta de conhecimento específico sobre o domínio em equipes centralizados
▪ Equipes de TI centralizadas estão focadas em tecnologia e menos no negócio
▪ Eles trabalham com requisitos de negócios que nem sempre são explicitados
corretamente.
2. Lentidão para provisionamento de dados e também em alterações necessárias
▪ Devido ao volume de requisições, disponibilidade de recursos, prioridades,
etc.. TI acaba sendo por vezes o gargalo
▪ Por exemplo: Em processos de replicação de dados.
3. Falta de flexibilidade dos repositórios centralizados.
▪ A infraestrutura de dados em grandes organizações é diversificada e muda
com frequência.
▪ Não há sistema mágico que cubra todas as necessidades de uma prática
completa de gerenciamento de dados.
Quais problemas o Data Mesh está tentando resolver?
7. 7
▪ As diferentes unidades de negócios (domínios) são responsáveis por gerenciar e
expor seus próprios dados.
▪ Cada domínio entende melhor do que ninguém o significado de seus dados e
como usá-lo.
▪ Dá-lhes autonomia para usar as ferramentas que melhor se adequam aos
seus processos.
▪ O resultado é menos interações até que os requisitos do negócio sejam
validados.
▪ Elimina dependência e gargalo de equipes de TI centralizadas.
▪ Introduz novos conceitos e práticas para evitar os riscos de criação de silos de
dados, duplicação de esforços e incompatibilidades:
▪ Dados como Produto, Autoatendimento e "Governança Computacional
Federada"
Como?
8. 8
▪ Para garantir que cada domínio não se torne um silo de dados
isolado do resto, os dados expostos devem garantir o seguinte:
▪ Fácil de encontrar e usar
▪ Compreensível e documentado
▪ Seguro
▪ Utilizável por outros domínios
▪ O nível de confiança e qualidade dos dados de cada produto deve
ser explícito.
▪ Mas o processo para gerar o produto é um detalhe interno de sua
criação e cada domínio é livre para usar o processo que preferir.
1. Dados como produto
9. 9
▪ A equipe centralizada opera o Data Mesh globalmente, mas deixa domínios para
criar e gerenciar seus próprios produtos.
▪ Mas criar, proteger, implantar e gerenciar produtos de dados pode ser uma tarefa
bastante complexa..
▪ Nem todos os domínios têm experiência suficiente.
▪ Possível duplicação de esforços entre domínios para tarefas comuns.
▪ O Data Mesh deve oferecer uma infraestrutura capaz de simplificar e automatizar
tarefas comuns, como:
▪ Integração e transformação de dados de diferentes domínios.
▪ Gerenciamento de segurança e acesso a dados.
▪ Gerenciamento das APIs associadas a cada produto de dados.
▪ Documentação e catalogação.
2. Autoatendimento de dados
10. 10
▪ Os produtos criados por cada domínio devem ser interoperáveis e
devem ser capazes de ser combinados entre si para resolver as
necessidades dos negócios..
▪ Isso exige acordos sobre a semântica de entidades comuns (por
exemplo, cliente, produto, etc.), sobre formatos de dados e tipos, sobre
como invocar APIs de dados, etc..
▪ A segurança deve ser aplicada de acordo com as regulamentações e
políticas globais da empresa.
▪ Essa governança deve ser gerenciada globalmente (federada) e, sempre
que possível, automaticamente (computacional).
3. Governança Computacional Federada
12. 12
A Plataforma Denodo
Hybrid/
Multi-Cloud
Security &
Governance
Al/ML
Recommendations
Query
Optimization &
Acceleration
Advanced
Semantics
Data Catalog
Discover / Explore /
Document
BI Tools
SQL / MDX
Data Science
Tools
Data as a Service
RESTful / OData
GraphQL/ GeoJSON
Files
Cubes
Data Lake &
NoSQL
Cloud
Stores
Traditional
DB & DW
Files
INTEGRAR
GERIR
ENTREGAR
Dados em qualquer
formato e organização
Modelos lógicos e semânticos, com
segurança e governança
Democratizar o acesso aos dados
via múltiplos formatos e protocolos
13. 13
▪ Denodo é uma camada lógica intermediária entre
fontes de dados e consumidores de dados.
▪ Armazena apenas metadados (modelos), não dados.
▪ Comporta-se como um "banco de dados virtual":
tem tabelas e visualizações, e usa SQL como banco
de dados, mas não tem dados próprios.
▪ Em execução, é como um maestro de uma
orquestra: atua como a camada de acesso para
todas as fontes de dados, e se comunica com elas
para devolver os dados solicitados..
A arquitetura de Denodo
14. 14
▪ O Denodo permite acesso a qualquer fonte de dados.
▪ Dá a cada domínio flexibilidade para usar os sistemas que
preferem.
▪ Também oferece ferramentas avançadas de modelagem de
dados
▪ Permite que os domínios criem produtos diretamente
usando o Denodo, combinem várias fontes de dados e
exponham-nas na forma de um modelo lógico.
▪ Sem necessidade de escrever código, Denodo oferece
assistentes gráficos.
▪ Os produtos, gerados no Denodo ou não, podem ser expostos
como modelos SQL, mas também via APIs (Odata, GraphQL,
REST).
▪ Não há necessidade de escrever código adicional.
Simplificar a criação de Produtos de Dados
15. 15
▪ Os domínios não estão condicionados a um único sistema para qualquer operação. Você
pode usar seus próprios sistemas.
▪ Por exemplo, data marts ou seus aplicativos.
▪ Permite que você aproveite o conhecimento existente.
▪ Se necessário, eles também podem usar infraestrutura centralizada.
▪ Por exemplo, um Data Lake compartilhado entre domínios para data science.
▪ Os domínios podem evoluir sua própria infraestrutura e software para atender às suas
necessidades sem ter que esperar por uma mudança completa no nível corporativo.
Mantém a autonomia dos domínios
16. 16
▪ Exploração e documentação
▪ O Denodo inclui um catálogo completo que permite aos usuários de negócios pesquisar, explorar,
entender e acessar qualquer produto de dados.
▪ Denodo gera automaticamente documentação na forma de documentos OpenAPI para interfaces
REST.
▪ Inclui linhagem de dados de gráfica.
▪ Alto desempenho.
▪ Recursos de cache e aceleração de consultas para melhorar o desempenho de consultas mais
lentas.
▪ Implantações.
▪ Implantações automatizadas e auto-escaláveis na nuvem e contêineres/kubernetes.
Inclui recursos de autoatendimento
17. 17
▪ Permite a combinação de produtos entre domínios.
▪ Permite o design de produtos derivados.
▪ E garante compatibilidade entre produtos.
▪ A estrutura do produto pode ser importada a partir de ferramentas de modelagem
de dados (Embarcadero, ERWin, etc.) para garantir compatibilidade com modelos
pré-aprovados ou padronizados.
▪ Permite o uso de técnicas de modelagem “top-down”.
▪ Você pode aplicar políticas de segurança, com base em roles ou tags.
▪ Incluindo mascaramento, redação de dados, criptografia/descriptografia, etc.
Permite a Governança Computacional Federada
19. 19
Um cluster Denodo para servir um Data Mesh
SQL
Operational EDW
Data Lakes Files
SaaS APIs
REST GraphQL OData
Event
Product
Customer Location Employee
1. Cada domínio tem um
esquema virtual. Um
esquema comum e
compartilhado é
frequentemente útil
para fornecer produtos
de dados corporativos.
2. Cada domínio conecta
suas fontes.
3. Metadados são
mapeados para
tabelas virtuais.
Nenhum dado é
replicado.
4. Os domínios podem
criar seus produtos de
dados. Os produtos
podem ser usados
para definir outros
produtos.
5. Para execução, os produtos
podem ser direcionados às
fontes originais, ou persistir em
outra fonte centralizada (o lago
de dados).
Common Domain Event Management Human Resources 6. A equipe central
pode definir
diretrizes gerais
de governança
para garantir a
interoperabilidad
e
8. A infraestrutura
pode ser
dimensionada
para acomodar a
carga.
7. Os produtos podem ser expostos como
visualizações SQL ou como REST, Odata ou
APIs GraphQL.
21. 21
1. Data Mesh é um novo paradigma de gestão de dados.
▪ Delega responsabilidades para domínios (unidades de negócios) para gerenciar seus dados.
▪ Tenta eliminar gargalos com maior agilidade e qualidade no acesso aos dados.
2. Ferramentas como a Denodo fornecem uma base sólida para abordar esse tipo de estratégia..
▪ Permite que cada domínio use sua própria infraestrutura.
▪ Os recursos de abstração de camadas de virtualização simplificam a criação de produtos de dados, garantindo a
interoperabilidade entre eles.
▪ Oferece recursos avançados para governança e segurança de dados.
3. Outras tecnologias, como Data Lakes ou microsserviços, sozinhas, não são capazes de gerenciar efetivamente esses
tipos de arquiteturas.
▪ Os Data Lakes forçam o uso de infraestrutura centralizada, caindo em muitos dos problemas que o Data Mesh
tenta resolver.
▪ A criação manual de microsserviços, além de precisar de muito código à medida que retarda o desenvolvimento,
complica muito o uso de produtos e análises compostas por vários produtos e domínios.
Conclusões