Partilhar via


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

Este cenário é para clientes que desejam usar análises em escala de nuvem para escalabilidade e arquiteturas de de malha de dados. Ele demonstra um cenário complexo com zonas de aterrissagem, 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 presença mundial. Os dados do Woodgrove Bank estão alojados em sistemas de implementação no local e na nuvem. Dentro da arquitetura do Woodgrove Bank, existem vários sistemas de data warehouse para marketing consolidado e relatórios integrados. Essa arquitetura inclui vários data lakes para análises não planejadas e descoberta de dados. Os aplicativos do Woodgrove Bank são interconectados por meio de padrões de integração de aplicativos, que são principalmente baseados em API ou eventos.

A situação atual

É um desafio para o Woodgrove Bank distribuir dados para diferentes locais 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 os regulamentos é difícil porque o Woodgrove Bank não sabe exatamente onde seus dados residem.

Solução de arquitetura: malha de dados

Ao longo dos ú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 para as empresas usar métodos orientados por dados, como dados em escala.

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

Sobre o Data Mesh

O conceito de malha de dados, termo cunhado por Zhamak Dehghani, engloba dados, tecnologia, processos e organização. Conceitualmente, é uma abordagem acessível para gerenciar dados onde 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 olhar para os dados como um enorme repositório, a malha de dados considera a decomposição de produtos de dados independentes. Essa mudança, de propriedade centralizada para federada, é suportada por uma plataforma de dados moderna e de autoatendimento normalmente projetada usando tecnologias nativas da nuvem.

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

  • Data as a Product: Cada domínio (organizacional) opera seus dados de ponta a ponta. A responsabilidade é do proprietário dos dados dentro do domínio. Os pipelines tornam-se uma preocupação de primeira classe dos próprios domínios.
  • Federated Computational Data Governance: Para garantir que cada proprietário de dados possa confiar nos outros e compartilhar seus produtos de dados, um órgão de governança de dados corporativos deve ser estabelecido. O órgão de governança implementa a qualidade dos dados, a visibilidade central da propriedade dos dados, o gerenciamento do acesso aos dados e as políticas de privacidade dos dados.
  • Domain-Oriented Propriedade de Dados: idealmente, a empresa deve definir e modelar cada nó de domínio de dados dentro da malha, aplicando os princípios do Design Orientado ao Domínio.
  • Self-Serve Data Platform: Uma malha de dados requer uma plataforma de dados de autoatendimento que permita aos usuários remover a complexidade técnica e se concentrar em seus casos de uso de dados individuais.

Cloud-Scale Analytics

O pensamento de dados como produto e um modelo de plataforma de autoatendimento não são novidade para a Microsoft. A Microsoft observou as práticas recomendadas 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 análises em escala de nuvem. A análise em escala de nuvem é um modelo de código aberto e prescritivo para projetar e implantar rapidamente plataformas de dados modernas. Está associado às práticas recomendadas e aos princípios de design do Azure e está alinhado com o Azure Well-Architected Framework. A análise em escala de nuvem dá às empresas um ponto de vista prescrito em 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 plano, incluindo serviços de plataforma de dados principais para gerenciamento de dados.

No mais alto nível, a análise em escala de nuvem usa um recurso de gerenciamento de dados, que é habilitado por meio da zona de aterrissagem de gerenciamento de dados. Essa zona é responsável pela governança de dados federados de uma organização da plataforma (de autoatendimento) e pelos domínios de dados que geram valor comercial por meio de produtos de dados. A vantagem desta abordagem é que elimina a complexidade técnica, ao mesmo tempo que respeita as mesmas normas. Ele garante que não haja proliferação de tecnologia. Também permite que as empresas comecem modulares, com uma pegada pequena, e depois cresçam ao longo do tempo.

A zona de aterrissagem de gerenciamento de dados, como você pode ver no diagrama a seguir, envolve todos os domínios de dados. Une todos os domínios e fornece a supervisão procurada pelo Woodgrove Bank.

Diagrama mostrando como a malha de dados distribui produtos de dados de forma inteligente 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 ênfase na catalogação e classificação central para proteger os dados e permitir que os grupos descubram dados. Coloca um guarda-chuva sobre a sua infraestrutura de dados.

Domínios de Dados

Quando você usa a análise em escala de nuvem como um caminho estratégico, precisa pensar na decomposição de sua arquitetura e na granularidade resultante. A malha de dados decompõe os dados por não seguir as fronteiras das tecnologias. Em vez disso, aplica os princípios do domain-driven design (DDD), uma abordagem ao desenvolvimento de software que envolve sistemas complexos para organizações maiores. DDD é popular por causa de seu efeito sobre as práticas modernas de desenvolvimento de software e aplicativos, como microsserviços.

Um dos padrões do design controlado por 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 aspetos, incluindo dados, podem mudar e quais são dependências compartilhadas que exigem coordenação com outros. A malha de dados abarca o contexto delimitado. Ele usa esse padrão para descrever como as organizações podem se 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 dos outros.

Diagrama mostrando a arquitetura de malha de dados.

Produtos de Dados

Quando você amplia a arquitetura interna de tal domínio de dados, espera encontrar produtos de dados dentro dele.

Os produtos de dados atendem a uma necessidade específica dentro das empresas que usam dados. Os produtos de dados gerenciam, organizam e dão sentido aos dados entre domínios e, em seguida, apresentam os insights obtidos. Um produto de dados resulta de dados de uma ou várias integrações de dados ou outros produtos de dados. Os produtos de dados estão estreitamente alinhados com os domínios de dados e herdam a mesma linguagem construída e formalizada acordada pelas partes interessadas 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 distribuição de dados e padrões de integração. A estrutura fornece lotes de dados, streaming e análises para atender às necessidades de diversos consumidores.

Uma grande coisa sobre a análise em escala de nuvem é como os domínios e produtos de dados são organizados. Cada domínio de dados se alinha com uma zona de aterrissagem de dados, que é uma construção lógica 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 está alinhado com um grupo de recursos dentro da zona de aterrissagem de dados, e todas as zonas de aterrissagem de dados e zonas de gerenciamento se alinham com as assinaturas. Esta abordagem facilita a implementação e a gestão.

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

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 fonte, onde os dados se originam, ou com o caso de uso previsto. Em ambos os casos, você precisa fornecer uma visã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 vista do Azure Synapse ou um ficheiro Parquet, que agrupa logicamente os dados, é um exemplo de como um produto de dados pode ser partilhado entre vários domínios de dados.

Em seguida, você precisa trabalhar na descoberta, procedência, uso e linhagem de dados. 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 em análises em escala de nuvem conecta perfeitamente os pontos porque permite criar esses produtos de dados à medida que realiza 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, linhagem, qualidade de dados e 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. A vantagem é que integra centralmente todos os metadados e os torna facilmente acessíveis 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 análises 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 um 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 Microsoft Zero Trust. A análise em escala de nuvem propõe o uso de isolamento de rede por meio de pontos de extremidade privados e comunicação de rede privada, um modelo de acesso a dados orientado por identidade que usa MIs, UMIs e grupos de segurança aninhados, seguindo o princípio de menor privilégio.

Você pode usar identidades gerenciadas para garantir que um modelo de acesso com privilégios mínimos seja seguido. Os aplicativos e serviços neste modelo têm acesso limitado a produtos de dados. As políticas do Azure, com as próximas políticas de dados, são usadas para habilitar o autoatendimento e impor recursos compatíveis em todos os produtos de dados, em escala. Com esse design, você pode ter acesso uniforme aos dados enquanto permanece totalmente no controle por meio de governança e auditoria centralizadas de dados.

Diagrama ilustrativo de um contrato de dados.

Evoluir para o futuro

A análise em escala de nuvem é 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 vários domínios de dados. Essa estrutura permite que os domínios tenham autonomia para fazer escolhas e rege a arquitetura, cercando-a com serviços de gerenciamento de dados.

Ao implementar malha de dados, agrupe e organize logicamente seus domínios. Essa abordagem requer uma visão corporativa e é provavelmente uma mudança cultural para sua organização. A mudança exige que você federar a propriedade de dados entre domínios de dados e proprietários que são responsáveis por fornecer seus dados como produtos. Também exige que as equipes estejam em conformidade com os recursos centralizados oferecidos pela zona de aterrissagem de gerenciamento de dados. Esta nova abordagem pode exigir que cada equipa desista dos seus mandatos atuais, o que é suscetível de gerar resistência. Poderá ter de 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 aterrissagem à arquitetura para domínios individuais. Essas zonas de pouso usam emparelhamento de rede virtual para se conectar à zona de pouso de gerenciamento de dados e a todas as outras zonas de pouso. Esse padrão permite que você compartilhe dados, produtos e recursos entre zonas. Ao dividir em zonas separadas, você pode distribuir cargas de trabalho entre assinaturas e recursos do Azure. Essa abordagem permite implementar a malha de dados organicamente.

Saiba mais

Recursos da Microsoft:

Artigo do fundador da malha de dados, Zhamak Dehghani: