Data Mesh: indo além do Data Lake e Data Warehouse

Published in

Data Hackers

13 min readMay 14, 2021

Este artigo apresenta uma visão sobre a última tendência de arquitetura de dados na indústria que pode facilitar a democratização dos dados dentro da sua empresa.

Na Era da Informação, o poder dos dados dentro das empresas tem sido mantido nas mãos de poucas pessoas, geralmente nos departamentos de TI. As unidades de negócio, como marketing, analistas de negócio e executivos usam os dados para tomarem decisões importantes, mas geralmente tem que requisitar estes dados ao departamento de TI. Esta situação centraliza a coleta e transformação dos dados nas mãos de equipes que, em muitos casos, estão desalinhadas das necessidades das áreas de negócio da empresa. Por exemplo, imagine uma empresa de e-commerce com dados de clientes e pedidos (realizados no site) que são utilizados por várias áreas da organização:

A área de marketing necessita visualizar o volume de vendas por categorias de produtos para expandir suas campanhas, dinamicamente todos os dias.
A área de ciência de dados está construindo o sistema de recomendação de produtos e precisam ter os dados atualizados para o treinamento dos modelos.
A área de gestão da empresa precisa visualizar os resultados agregados de cada área e de toda a empresa.

O problema é que todas as demandas de coleta e preparação dos dados para estas áreas da empresa ficam, geralmente, concentradas na área de TI, onde um time centralizado de engenheiros de dados precisam preparar os dados para as área de negócio. Entretanto, em muitos casos, os engenheiros de dados não tem o conhecimento de negócio necessário para gerar os dados com a qualidade esperada pela área de negócio. Além disso, a centralização desta tarefa nas mãos dos engenheiros de dados, desconectados das outras áreas, leva a menor velocidade de entrega das áreas de negócio. Quem nunca ouviu uma área de negócio reclamar que precisa analisar alguma informação importante (já requisitada à engenharia), mas que a engenharia está demorando muito pra entregar.

Muitas empresas estão investindo na próxima geração do seu Data Lake/Warehouse, com a esperança de democratizar os dados em larga escala para fornecer insights de negócios e, por fim, tomar decisões inteligentes automatizadas. Embora os avanços tecnológicos da última década com Data Lake/Warehouse tenham lidado com a escala em relação ao volume e processamento de dados, eles falharam em lidar com a escala em outras dimensões: mudanças no cenário de dados, aumento do número de fontes de dados, diversidade de regras de negócio sobre os dados e velocidade de resposta à mudanças nas regras de negócio.

As plataformas de dados baseadas na arquitetura Data Lake/Warehouse têm características comuns que levaram a promessas não cumpridas na democratização dos dados em larga escala dentro das empresas:

centralizada e monolítica: um time de engenharia é responsável por todo o pipeline de dados, desde a coleta dos dados na fonte até a disponibilização das informações aos usuários de negócio. Este time se torna o gargalo quando é necessária a alteração do pipeline de dados. No exemplo do e-commerce, um único time da engenharia centralizaria a responsabilidade por preparar os dados para várias áreas diferentes da empresa. Só que cada área possui requisitos diferentes sobre os dados de clientes e pedidos e, geralmente, a equipe de engenharia não consegue ter uma visão de negócio especializada para todas as áreas e dar celeridade em resposta às mudanças nas regras de negócio.

plataforma de dados centralizada: os arquitetos de dados implementam um pipeline de dados com vários estágios (ingestão, preparação, agregação, etc.). Apesar deste modelo fornecer algum nível de escala, alocando times diferentes para cada estágio do pipeline, ele tem uma limitação inerente que retarda a entrega de novas funcionalidades, pois um estágio é dependente do outro. Existe um forte acoplamento entre os estágios do pipeline para entregar uma funcionalidade independente. O estágio de transformação de dados, por exemplo, depende do estágio de extração de dados, que pode estar sob a responsabilidade de uma equipe diferente.

grupo de engenheiros de dados altamente especializados trabalhando em silos: engenheiros de dados trabalham, geralmente, isolados do restante da empresa, ou seja, distantes de onde os dados são gerados (fontes de dados) e utilizados (áreas onde as decisões são tomadas sobre os dados). Os engenheiros não são separados apenas organizacionalmente, mas também separados e agrupados em times baseados nas suas expertises em ferramentas de big data, geralmente sem o conhecimento necessário da área de negócio. Suponha, no exemplo do e-commerce, que a área de marketing esteja requisitando que sejam coletados dados do Twitter para analisar o engajamento dos consumidores com a empresa. Neste caso, um time estaria focado em trazer os dados do Twitter, outro time de engenheiros em preparar estes dados e o time de marketing em analisar as informações. O problema é que os times de engenharia que coletam e preparam estão isolados e ficam, geralmente, muito longe da área de negócio, podendo não entregar o resultado esperado.

Esta estrutura centralizada do Data Lake/Warehouse trouxe alguns desafios às equipes para democratização dos dados dentro da empresa:

Falta dos responsáveis pelos dados: quem são os responsáveis pelos dados?
Problemas de qualidade dos dados: o time de infraestrutura é responsável pela qualidade, mas não conhece os dados tão bem, pois não estão intimamente ligados com o time de negócio.
Escalabilidade organizacional: o time centralizado de ETL se torna o gargalo na democratização dos dados na empresa.

O que é Data Mesh?

O Data Mesh foi proposto por Zhamak Dehghani (diretora de tecnologia na ThoughtWorks) no artigo “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” como uma nova abordagem para projetar e desenvolver arquiteturas de dados com o objetivo de facilitar a democratização em escala dos dados na empresa. Ao contrário de arquiteturas centralizadas e monolíticas baseados em um data warehouse (armazém de dados) e/ou um data lake (lago de dados), um data mesh é um paradigma arquitetural e organizacional que desafia a antiga suposição de que devemos centralizar grandes volumes de dados analíticos para usá-los, manter todos os dados em um só lugar ou gerenciá-los por meio de um time de dados centralizado para entregar valor às áreas de negócio.

O Data Mesh (Malha de Dados) segue quatro princípios, que segundo Zhamak, são necessários para qualquer implementação do data mesh atingir os resultados esperados de escala, qualidade e integridade dos dados: (1) arquitetura de dados descentralizada orientada ao domínio; (2) dados disponibilizados como produto; (3) infraestrutura para disponibilizar os dados como self-service; (4) governança federada para permitir a interoperabilidade dos domínios. Cada princípio leva a uma nova visão lógica da arquitetura técnica e da estrutura organizacional.

Arquitetura de dados descentralizada orientada ao domínio

A arquitetura deve ser modelada para organizar os dados analíticos por domínios. Nesta arquitetura, a interface do domínio com o restante da organização não inclui apenas os recursos operacionais, mas também o acesso aos dados analíticos que o domínio atende. No exemplo do e-commerce, poderíamos ter domínios de ‘clientes’ e ‘pedidos’. O domínio de ‘clientes’ poderia fornecer, por exemplo, endpoints de APIs para: 1) obter todos os clientes (um por linha) baseado em filtros; 2) disponibilizar estatísticas sobre os clientes (como número de clientes ativos, inadimplentes, etc.).

Cada domínio pode expor uma ou mais APIs operacionais, assim como um ou mais endpoints para serem utilizados em várias áreas da empresa. Isso implica que a arquitetura deve remover qualquer acoplamento para permitir que os domínios forneçam seus dados analíticos e permita que a engenharia concentre em gerenciar os dados, independentemente de outros domínios. Para escalar, a arquitetura deve oferecer suporte à autonomia das equipes de domínio em relação à implantação de seus sistemas de dados operacionais ou analíticos.

Dados disponibilizados como produto

O objetivo do Data Mesh é tratar os dados como um produto, onde cada fonte de dados tem seu próprio gerente/proprietário do produto de dados que fazem parte de uma equipe multifuncional de engenheiros de dados. Cada fonte de dados tem uma equipe focada em uma oferta autônoma, construindo uma arquitetura distribuída orientada ao domínio. Cada domínio deve ser descoberto, endereçável, auto descritivo, seguro (governado pelo controle de acesso global), confiável e interoperável (governado por um padrão aberto). Cada domínio poderá armazenar seus dados em um data lake/warehouse e, em muitos casos, também terá uma cópia de alguns dos dados em um banco de dados relacional transacional.

Cada domínio deve ter um proprietário do produto de dados, responsável por garantir que os dados sejam entregues como um produto. Estas entregas devem incluir: qualidade de dados, menor tempo de espera de consumo de dados e, em geral, satisfação do usuário de dados. O proprietário do produto deve ter um conhecimento profundo de quem são os usuários dos dados, como eles usam estes dados e quais são os métodos nativos com os quais eles se sentem confortáveis para consumir os dados. Esse conhecimento íntimo dos usuários resulta no projeto de interfaces de produtos de dados que atendam as necessidades das áreas de negócio. A conversa entre os usuários e os proprietários dos produtos é uma parte necessária para estabelecer as interfaces dos produtos de dados.

Plataforma de dados self-service

Você deve estar pensando: “Mas, vou precisar construir uma infraestrutura de plataforma de dados para cada domínio?”. Como você pode imaginar, para construir, implantar, executar, monitorar e acessar um domínio de dados existe uma boa parte da infraestrutura que precisa ser provisionada e gerenciada. As habilidades necessárias para provisionar essa infraestrutura são especializadas e seriam difíceis de replicar em cada domínio. Mais importante ainda, a única maneira de as equipes serem proprietárias autônomas de seus produtos de dados é ter acesso a uma abstração de alto nível da infraestrutura que remove a complexidade e o desafio do provisionamento e do gerenciamento do ciclo de vida dos produtos de dados.

Isso exige que exista uma infraestrutura de dados self-service, como uma plataforma, para habilitar a autonomia do domínio. A ideia principal é evitar a duplicação de esforços, permitindo que cada equipe de produtos de dados construa seus produtos de dados rapidamente. Note que esta plataforma de infraestrutura de dados não deve se tornar uma plataforma de dados (ela permanece agnóstica em relação ao domínio). A infraestrutura self-service deve incluir recursos para reduzir o custo atual e a especialização necessária para construir produtos de dados, incluindo: armazenamento de dados escalável, esquema de produtos de dados, construção e orquestração de pipeline de dados, linhagem de dados, etc. Portanto, quando for criar uma nova API ou endpoint, os desenvolvedores podem aproveitar toda a infraestrutura pronta para construir a solução. Por exemplo, se um produto de dados precisar utilizar filas distribuídas para comunicação entre módulos da solução, os engenheiros podem aproveitar uma infraestrutura implantada com Apache Kafka e apenas criar os tópicos de comunicação entre os módulos, ao invés de precisar implantar e administrar o cluster do Kafka.

Infraestrutura de dados separada como uma plataforma

Governança Federada

A implementação do data mesh requer um modelo de governança de dados que abrange a descentralização do domínio, interoperabilidade por meio de padronização global, uma topologia dinâmica e, o mais importante, a execução automatizada de decisões pela plataforma. A isso denominamos governança federada. Cada dono de um produto de dados tem autonomia e poder de decisão local de domínio, enquanto cria e adere a um conjunto de regras globais — regras aplicadas a todos os produtos de dados e suas interfaces — para garantir um ecossistema saudável e interoperável. O grupo tem uma tarefa difícil: manter um equilíbrio entre centralização e descentralização; quais decisões precisam ser localizadas para cada domínio e quais decisões devem ser feitas globalmente para todos os domínios. Em última análise, as decisões globais têm um propósito, criar interoperabilidade e um efeito de rede composto por meio da descoberta e composição de produtos de dados.

O modelo de dados de domínio é uma preocupação que deve ser localizada em um domínio que esteja mais intimamente familiarizado com ele. No exemplo de e-commerce, o modelo de dados de ‘produtos mais comprados no mês’ deve ser deixada para a equipe de ‘domínio de produtos’. No entanto, a decisão sobre como identificar um ‘cliente ativo da empresa’ é uma preocupação global, pois pode ser encontrado em outros domínios. Ou seja, a governança de dados sobre o domínio de ‘cliente ativo da empresa’ deve ser centralizada em um único lugar.

Um conjunto de dados de domínio só se torna um produto de dados depois que localmente, dentro do domínio, passa pelo processo de garantia de qualidade de acordo com as métricas de qualidade do produto de dados esperadas e as regras de padronização global. Os proprietários de produtos de dados de domínio estão em melhor posição para decidir como medir a qualidade dos dados de seu domínio, conhecendo os detalhes das operações de domínio que produzem os dados. Apesar de tal tomada de decisão ser localizada e autônoma, é preciso garantir que a modelagem esteja atendendo aos padrões globais da empresa de qualidade, definido pela equipe de governança federada e automatizado pela plataforma.

Arquitetura Data Mesh em nuvem

Zhamak acredita que a tecnologia não seja a limitação para migração para o Data Mesh, já que as ferramentas utilizadas no Data Lake/Warehouse podem ser aproveitadas no Data Mesh. O uso das soluções em nuvem irá facilitar muito a migração da sua estrutura atual para Data Mesh. Zhamak apresenta como exemplo utilizar o Google Cloud Dataflow para o processamento de dados em streaming e em lote e o Google Cloud Data Catalog para descoberta central, controle de acesso e governança de conjuntos de dados de domínio distribuídos. Além disso, existe uma ampla variedade de opções de armazenamento de dados em nuvem que permitem que os produtos de dados de domínio escolham o armazenamento adequado para a necessidade.

O artigo “How to Create a Modern CPG Data Architecture with Data Mesh” apresenta uma arquitetura Data Mesh na AWS para gerenciar os dados da área de varejo. O setor de e-commerce cresceu 75% em meio à pandemia e este crescimento no volume de dados trouxe desafios ao setor de varejo no gerenciamento destes dados. Historicamente, o setor não se comunica diretamente com os consumidores e, por isso, os dados de clientes e compras representam praticamente a única informação disponível.

A arquitetura (apresentada na Figura abaixo) é uma solução que segue o seguinte fluxo:

Os dados são ingeridos dentro da AWS;
Os dados são gerenciados pelo domínio de dados do negócio em um modelo pub/sub onde os produtores e consumidores utilizam uma infraestrutura de comunicação, segurança, governança e descoberta;
Os metadados são gerenciados por múltiplos serviços: AWS Glue é utilizado para o catálogo de dados, Amazon Neptune é utilizado para armazenar a linhagem dos dados e o Amazon DynamoDB para armazenar os contratos de dados.
Os consumidores buscam os dados seguindo as propriedades dos contratos armazenados no DynamoDB. Estes contratos desacoplam os produtores e consumidores e permite a interação entre eles.
O AWS Lake Formation facilita a configuração de um data lake seguro com um repositório centralizado, administrado e seguro que armazena todos os dados, tanto em sua forma original quanto preparados para análise. Ele permite romper os silos de dados e combinar diferentes tipos de análises para obter insights e orientar as melhores decisões de negócios.
O processamento de análises dos dados é realizado com o Lake Formation, juntamente com Amazon Athena para consultas interativas, facilitando a análise de dados armazenados no Amazon S3 usando SQL padrão. O Elasticsearch é utilizado como mecanismo de busca e análise de dados distribuído e o Amazon SageMaker como um serviço para ajudar cientistas e engenheiros de dados a preparar, criar, treinar e implantar modelos de machine learning (ML) de alta qualidade rapidamente.

Quando começar a pensar sobre Data Mesh na sua empresa?

Quando você deve considerar a mudança da estrutura atual para o data mesh? Em primeiro lugar, se você está feliz com sua estrutura, se está satisfeito com a maneira como sua empresa usa os dados para tomar decisões, então não o faça! O Data Mesh exige que você construa uma arquitetura e infraestrutura que pode ser complexa para a sua empresa, dada as habilidades da sua equipe e estágio das tecnologias. Além disso (e talvez mais importante), o Data Mesh exige uma mudança de cultura dentro da sua empresa, desde a área de negócio até a engenharia, o que pode ser uma barreira na implantação desta arquitetura.

Quando o número de fontes de dados, conjunto de consumidores, regras de negócio e complexidade dos domínios for aumentando, o uso do Data Lake/Warehouse pode se tornar um gargalo na entrega de soluções de qualidade. Neste caso, talvez seja o momento de você iniciar a discussão interna na empresa sobre a migração da estrutura atual para o Data Mesh. Se você tem desenvolvimento orientado ao domínio, começou a trabalhar com microsserviços ou se fez uma migração para a nuvem, a migração para o Data Mesh tende a ter um custo bem menor.

Uma boa estratégia é utilizar estudos de casos dentro da sua empresa como “candidatos perfeitos” para serem atendidos individualmente e migrar sua arquitetura atual aos poucos para o Data Mesh. Por exemplo, se você está descartando fontes de dados a serem importadas, que são valiosas para usuários do negócio, porque é complexo integrar estas fontes de dados na estrutura de Data Lake/Warehouse atual da sua empresa, então pode ser uma boa oportunidade para utilizar este cenário como estudo de caso para migração para esta nova arquitetura.