Compartilhar via


Um cenário de instituição financeira para malha de dados

Esse cenário é para clientes que desejam usar análises em escala de nuvem para escalabilidade e arquiteturas de malha de dados. Ele demonstra um cenário complexo com zonas de destino, integrações de dados e produtos de dados.

Perfil do Cliente

Uma empresa fictícia, o Woodgrove Bank, é uma grande empresa de serviços financeiros com uma pegada mundial. Os dados do Woodgrove Bank estão hospedados em sistemas locais e de implantação de nuvem. Dentro da arquitetura do Woodgrove Bank, há vários sistemas de data warehouse para marketing consolidado e relatórios integrados. Essa arquitetura inclui vários data lakes para análise e descoberta de dados não planejadas. Os aplicativos do Woodgrove Bank são interconectados por meio de padrões de integração de aplicativos, que são baseados principalmente em API ou em eventos.

A situação atual

É desafiador para o Woodgrove Bank distribuir dados para locais diferentes devido à complexidade do armazenamento de dados. A integração de novos dados é demorada e é tentador duplicar dados. O Woodgrove Bank acha difícil supervisionar o cenário de dados de ponta a ponta devido à conectividade ponto a ponto. O banco subestimou a demanda por consumo intensivo de dados. Novos casos de uso são introduzidos rapidamente, um após o outro. A governança de dados, como a propriedade e a qualidade dos dados, e os custos são difíceis de controlar. Manter-se atualizado com as regulamentações é difícil porque o Woodgrove Bank não sabe exatamente onde seus dados residem.

Solução de arquitetura: Malha de Dados

Nos últimos anos, as organizações reconhecem que os dados estão no centro de tudo. Os dados abrem novas eficiências, impulsionam a inovação, desbloqueiam novos modelos de negócios e aumentam a satisfação do cliente. É uma prioridade máxima para as empresas usarem métodos controlados por dados, como dados em escala.

Chegar a um estágio em que o valor mais profundo dos dados é acessível a todos os membros da organização é desafiador. Sistemas herdados e fortemente interconectados, plataformas monolíticas centralizadas e governança complexa podem ser barreiras significativas para gerar valor a partir de dados.

Sobre a Malha de Dados

O conceito de malha de dados, termo cunhado por Zhamak Dehghani, abrange dados, tecnologia, processos e organização. Conceitualmente, é uma abordagem acessível para gerenciar dados em que vários domínios usam seus próprios dados. A malha de dados desafia a ideia de centralização convencional de dados. Em vez de examinar os dados como um repositório enorme, a malha de dados considera a decomposição de produtos de dados independentes. Essa mudança, de centralizada para propriedade federada, é suportada por uma plataforma de dados moderna e de autoatendimento normalmente projetada usando tecnologias nativas de nuvem.

Quando você divide o conceito de malha de dados em blocos de construção, aqui estão alguns pontos importantes a serem considerados:

  • Dados como produto: cada domínio (organizacional) gerencia seus dados de ponta a ponta. A responsabilidade está no proprietário dos dados dentro do domínio. Os pipelines se tornam uma preocupação prioritária dos domínios em si.
  • a Governança de Dados Computacional Federada: para garantir que cada proprietário de dados possa confiar nas outras pessoas e compartilhar seus produtos de dados, um órgão de governança de dados corporativo deve ser estabelecido. O órgão de governança implementa a qualidade dos dados, a visibilidade central da propriedade de dados, o gerenciamento de acesso a dados e as políticas de privacidade de dados.
  • Propriedade de dados orientada por domínio: a empresa deve definir e modelar idealmente cada nó de domínio de dados dentro da malha aplicando os princípios do design orientado por domínio.
  • Self-Serve Data Platform: uma malha de dados requer uma plataforma de dados de autoatendimento que permite que os usuários removam a complexidade técnica e se concentrem em seus casos de uso de dados individuais.

Análise de escala de nuvem

O pensamento de dados como um produto e um modelo de plataforma de autoatendimento não são novos para a Microsoft. A Microsoft observou as melhores práticas de plataformas distribuídas, pipelines entre domínios, propriedade federada e dados autoexplicativos por muitos anos.

O Woodgrove Bank pode fazer a transição para a malha de dados usando a análise em escala de nuvem. A análise em escala de nuvem é um blueprint de software livre e prescritivo para criar e implantar rapidamente plataformas de dados modernas. Ele é associado às práticas recomendadas e princípios de design do Azure e está alinhado com o Azure Well-Architected Framework. A análise em escala de nuvem fornece às empresas um ponto de vista prescrito de 80% e os 20% restantes são personalizáveis.

A análise em escala de nuvem oferece às empresas um caminho de design estratégico para a malha de dados e pode ser usada para configurar rapidamente essa arquitetura. Ele oferece um blueprint, incluindo os principais serviços de plataforma de dados para gerenciamento de dados.

No nível mais alto, a análise em escala de nuvem usa uma funcionalidade de gerenciamento de dados, que é habilitada por meio da zona de destino de gerenciamento de dados. Essa zona é responsável pela governança de dados federada de uma organização da plataforma (autoatendimento) e pelos domínios de dados que geram valor empresarial por meio de produtos de dados. O benefício dessa abordagem é que ela remove a complexidade técnica ao aderir aos mesmos padrões. Garante que não haja proliferação da tecnologia. Ele também permite que as empresas comecem de forma modular, com uma estrutura pequena, e depois expandam ao longo do tempo.

A zona de destino de gerenciamento de dados, como você pode ver no diagrama a seguir, envolve todos os domínios de dados. Ele associa todos os domínios e fornece a supervisão que o Woodgrove Bank está procurando.

Diagrama mostrando como a malha de dados distribui de forma inteligente produtos de dados entre domínios de dados.

A análise em escala de nuvem também defende a aplicação de governança consistente que usa uma arquitetura comum quando os produtos de dados são distribuídos. A estrutura permite a comunicação direta entre domínios. Ele permanece no controle colocando uma ênfase na catalogação central e classificação para proteger dados e permitir que os grupos descubram dados. Ela coloca um guarda-chuva sobre seu estado dos dados.

Domínios de dados

Ao usar a análise em escala de nuvem como um caminho estratégico, você precisa pensar na decomposição de sua arquitetura e na granularidade resultante. A malha de dados decompõe dados independentemente dos limites das tecnologias. Em vez disso, aplica os princípios do DDD (design controlado pelo domínio), uma abordagem para o desenvolvimento de software que envolve sistemas complexos para organizações maiores. O DDD é popular devido ao seu efeito nas práticas modernas de desenvolvimento de aplicativos e software, como microsserviços.

Um dos padrões do design controlado pelo domínio é conhecido como contexto limitado. Contextos limitados definem os limites lógicos do espaço de solução de um domínio para gerenciar melhor a complexidade. É importante que as equipes entendam quais aspectos, incluindo dados, podem ser alterados e quais são dependências compartilhadas que exigem coordenação com outras pessoas. A malha de dados adota contexto delimitado. Ele usa esse padrão para descrever como as organizações podem coordenar em torno de domínios de dados e se concentrar no fornecimento de dados como um produto. Cada domínio de dados possui e opera vários produtos de dados com sua própria pilha de tecnologia, que é independente das outras.

Diagrama mostrando a arquitetura da malha de dados.

Produtos de dados

Ao ampliar a arquitetura interna desse domínio de dados, você espera encontrar produtos de dados dentro dele.

Os produtos de dados atendem a uma necessidade específica dentro de empresas que usam dados. Os produtos de dados gerenciam, organizam e fazem sentido dos dados entre domínios e apresentam os insights obtidos. Um produto de dados resulta de dados de uma ou muitas integrações de dados ou outros produtos de dados. Os produtos de dados são estreitamente alinhados com os domínios de dados e herdam a mesma linguagem construída e formalizada acordada por stakeholders e designers. Cada domínio que gera dados é responsável por disponibilizar esses produtos de dados para os outros domínios.

Para ajudar a fornecer rapidamente produtos de dados, a análise em escala de nuvem oferece modelos para padrões de integração e distribuição de dados. A estrutura fornece processamento em lote de dados, transmissão e análise de dados para atender às necessidades de diversos consumidores.

Uma grande coisa sobre a análise em escala de nuvem é como os domínios e os produtos de dados são organizados. Cada domínio de dados se alinha a uma zona de aterrissagem de dados, que é um constructo lógico e uma unidade de escala na arquitetura de análise em escala de nuvem. Ele permite a retenção de dados e a execução de cargas de trabalho de dados, o que gera insights e valor. Cada produto de dados se alinha com um grupo de recursos dentro da zona de destino de dados e todas as zonas de destino de dados e zonas de gerenciamento se alinham com assinaturas. Essa abordagem facilita a implementação e o gerenciamento.

Todos os modelos de análise em escala de nuvem herdam o mesmo conjunto de políticas da zona de destino de gerenciamento de dados. Os modelos fornecem automaticamente os metadados necessários para descoberta de dados, governança, segurança, gerenciamento de custos e excelência operacional. Você pode incorporar rapidamente novos domínios de dados sem a necessidade de incorporação, integração e testes complexos.

O diagrama a seguir ilustra a aparência de um produto de dados:

Diagrama de um domínio de dados que contém um produto de dados.

Uma abordagem pragmática para a criação de produtos de dados é alinhar-se com a origem dos dados ou com o caso de uso do consumidor. Em ambos os casos, você precisa fornecer uma exibição abstrata do modelo de dados de aplicativo subjacente (complexo). Você deve tentar ocultar os detalhes técnicos e otimizar para consumo intensivo de dados. Uma exibição do Azure Synapse ou um arquivo Parquet, que agrupa logicamente dados, é um exemplo de como um produto de dados pode ser compartilhado em vários domínios de dados.

Em seguida, você precisa trabalhar na descoberta de dados, na procedência, no uso e na linhagem. Uma abordagem comprovada é usar um serviço de governança de dados, como o Microsoft Purview, para registrar todos os dados. A integração de dados na análise em escala de nuvem conecta perfeitamente os pontos, pois permite a criação desses produtos de dados à medida que executa simultaneamente o registro de metadados.

Ao alinhar domínios de dados e coleções do Microsoft Purview, você captura automaticamente todas as informações de origem de dados, linhagem, qualidade de dados e informações de consumo dos domínios individuais. Com essa abordagem, você pode conectar vários domínios de dados e produtos a uma solução de governança centralizada, que armazena todos os metadados de cada ambiente. O benefício é que ele integra centralmente todos os metadados e o torna facilmente acessível a vários consumidores. Você pode estender essa arquitetura para registrar novos produtos de dados.

O diagrama a seguir ilustra uma arquitetura de malha de dados entre domínios que usa a análise em escala de nuvem.

Diagrama mostrando a integração de dados.

O design de rede permite que os produtos de dados sejam compartilhados entre domínios usando o custo mínimo e eliminando um único ponto de falha e limitações de largura de banda. Para ajudar a garantir a segurança, você pode usar o modelo de segurança do Microsoft Zero Trust. A análise em escala de nuvem propõe o uso do isolamento de rede por meio de pontos de extremidade privados e comunicação de rede privada, um modelo de acesso a dados controlados por identidade que usa MIs, UMIs e grupos de segurança aninhados, seguindo o princípio de privilégio mínimo.

Você pode usar identidades gerenciadas para garantir que um modelo de acesso de privilégio mínimo seja seguido. Aplicativos e serviços nesse modelo têm acesso limitado a produtos de dados. As políticas do Azure, com as políticas de dados futuras, são usadas para habilitar o autoatendimento e impor recursos em conformidade em todos os produtos de dados, em escala. Com esse design, você pode ter acesso a dados uniformes, mantendo-se totalmente no controle por meio da governança e auditoria de dados centralizados.

Diagrama ilustrando um contrato de dados.

Evoluir para o futuro

A análise em escala de nuvem foi projetada com a malha de dados em mente. A análise em escala de nuvem fornece uma abordagem comprovada pela qual as organizações podem compartilhar dados em muitos domínios de dados. Essa estrutura permite que os domínios tenham autonomia para fazer escolhas e ela rege a arquitetura, cercando-a com serviços de gerenciamento de dados.

Quando você estiver implementando a malha de dados, agrupe e organize logicamente seus domínios. Essa abordagem requer uma visão empresarial e provavelmente é uma mudança cultural para sua organização. A mudança exige que você federe a propriedade de dados entre domínios de dados e proprietários responsáveis por fornecer seus dados como produtos. Também exige que as equipes estejam em conformidade com os recursos centralizados que a zona de destino do gerenciamento de dados oferece. Essa nova abordagem pode exigir que equipes individuais desistam de seus mandatos atuais, que provavelmente gerarão resistência. Você pode ter que fazer certas escolhas políticas e encontrar um equilíbrio entre abordagens centralizadas e descentralizadas.

Você pode dimensionar uma arquitetura de malha de dados adicionando mais zonas de destino à arquitetura para domínios individuais. Essas zonas de destino usa o emparelhamento de rede virtual para se conectar à zona de destino de gerenciamento de dados e a todas as outras zonas de destino. Esse padrão permite que você compartilhe produtos e recursos de dados entre zonas. Ao dividir em zonas separadas, você pode espalhar cargas de trabalho entre assinaturas e recursos do Azure. Essa abordagem permite implementar a malha de dados organicamente.

Saiba Mais

Recursos da Microsoft:

  • modelo de zona de aterrissagem de gerenciamento de dados
  • modelo de zona de destino de dados

Artigo do fundador da malha de dados, Zhamak Dehghani: