Share via


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

Esse cenário é para clientes que desejam usar a análise em escala de nuvem para arquiteturas de escalabilidade e 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. Na 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 ad hoc 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 baseados em eventos.

A situação atual

É um desafio para o Woodgrove Bank distribuir dados para locais diferentes devido à complexidade do data warehouse. A integração de novos dados é demorada e é tentador duplicar dados. O Woodgrove Bank tem dificuldade em 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. É difícil manter-se atualizado com as regulamentações porque o Banco Woodgrove não sabe exatamente onde residem seus dados.

Solução de arquitetura: malha de dados

Nos últimos anos, as organizações reconheceram que os dados estão no coração 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 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 rigidamente interconectados, plataformas monolíticos centralizadas e governança complexa podem ser barreiras significativas para gerar valor fora dos dados.

Sobre a malha de dados

O conceito de malha de dados, um 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, da propriedade centralizada para a federada, é apoiada por uma plataforma de dados moderna e de autoatendimento, que 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 um produto: cada domínio (organizacional) opera seus dados de ponta a ponta. A responsabilidade está no proprietário dos dados no domínio. Os pipelines se tornam uma preocupação de primeira classe dos próprios domínios.
  • Governança de dados computacionais federados: 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 de dados, o gerenciamento de acesso a dados e as políticas de privacidade de dados.
  • Propriedade de dados orientada a domínio: a empresa deve, idealmente, definir e modelar cada nó de domínio de dados dentro da malha aplicando os princípios de design orientado ao domínio.
  • Plataforma de dados de autoatendimento: 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 em escala de nuvem

O pensamento de dados como produto e um modelo de plataforma de autoatendimento não são novos para a Microsoft. A Microsoft observou 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 a análise em escala de nuvem. A análise de escala de nuvem é um blueprint de código aberto e prescritivo para a criação e implantação rápida de plataformas de dados modernas. Ele 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 de 80% prescrito e os 20% restantes são personalizáveis.

A análise de escala de nuvem oferece às empresas um caminho de design estratégico para a malha de dados e pode ser usado para configurar rapidamente tal 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 federados de uma organização da plataforma (autoatendimento) e pelos domínios de dados que geram valor comercial por meio de produtos de dados. O benefício dessa abordagem é que ela remove a complexidade técnica, aderindo aos mesmos padrões. Garante que não haja proliferação de tecnologia. Ele também permite que as empresas iniciem o modular, com uma pequena superfície e cresçam 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 cola todos os domínios juntos e fornece a supervisão que o Banco Woodgrove está procurando.

Diagrama mostrando como a malha de dados distribui de forma inteligente os 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, dando ênfase à catalogação central e à classificação para proteger os dados e permitir que os grupos descubram dados. Ele coloca uma proteção sobre seu espaço de 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 da arquitetura e na granularidade resultante. A malha de dados decompõe dados não seguindo as bordas das tecnologias. Em vez disso, ele aplica os princípios do DDD (design controlado por 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 software e aplicativos, como microsserviços.

Um dos padrões do design controlado por domínio é conhecido como contexto limitado. Os contextos limitados são usados para definir 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 para coordenar com outras pessoas. A malha de dados adota o contexto limitado. 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 dos outros.

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 em empresas que usam dados. Os produtos de dados gerenciam, organizam e decifram os dados em domínios e, em seguida, apresentam os insights que obtidos. Um produto de dados é resultado dos dados de uma ou várias integrações de dados ou outros produtos de dados. Os produtos de dados são estreitamente alinhados com domínios de dados e herdam a mesma linguagem construída e formalizada. Ele é acordado por stakeholders e designers, e atende às necessidades do design. Cada domínio, que gera dados, é responsável por tornar esses produtos de dados disponíveis para os outros domínios.

Para ajudar a fornecer produtos de dados rapidamente, a análise em escala de nuvem oferece modelos para padrões de distribuição e integração de dados. A estrutura fornece lote de dados, streaming e análise 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 destino 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 é alinhado a um grupo de recursos na 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 integrar rapidamente novos domínios de dados sem a necessidade de integração, integração e teste complexos.

O diagrama a seguir ilustra como pode ser 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 com a origem, onde os dados são originados ou com o caso de uso de consumo. 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 o consumo de dados intensivo. Uma exibição Azure Synapse ou arquivo Parquet, que agrupa logicamente os dados, é um exemplo de como um produto de dados pode ser compartilhado entre vários domínios de dados.

Em seguida, você precisa trabalhar na descoberta de dados, na comprovação, no uso e na linhagem. Uma abordagem comprovada é usar um serviço de governança de dados, como o Azure 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 Azure 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 os torna facilmente acessíveis a vários consumidores. É possível 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 de Confiança Zero da Microsoft. 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 controlado por identidade que usa MIs, UMIs e grupos de segurança aninhados, seguindo o princípio de privilégios mínimos.

É possível usar identidades gerenciadas para garantir que um modelo de acesso com privilégios mínimos 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 o controle total por meio da governança e da auditoria de dados centralizadas.

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 rege a arquitetura, cercando-a com serviços de gerenciamento de dados.

Ao implementar a malha de dados, agrupe e organize logicamente seus domínios. Essa abordagem requer uma exibiçã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. Ele também exige que as equipes sejam compatíveis com as funcionalidades centralizadas oferecidas pela zona de destino de gerenciamento de dados. Essa nova abordagem pode exigir que equipes individuais desistam de seus mandatos atuais, que provavelmente gerarão resistência. Talvez você tenha que fazer determinadas escolhas políticas e ter um equilíbrio entre abordagens centralizadas e descentralizadas.

É possível escalar 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 distribuir cargas de trabalho entre assinaturas e recursos do Azure. Essa abordagem permite que você implemente a malha de dados de maneira orgânica.

Saiba mais

Microsoft.Resources:

Artigo do fundador da malha de dados Zhamak Dehheii: