Considerações de design para plataformas de dados de autoatendimento
A malha de dados é uma nova abordagem empolgante para o design e o desenvolvimento da arquitetura de dados. Ao contrário da arquitetura de dados tradicional, a malha de dados separa a responsabilidade entre domínios de dados funcionais que se concentram na criação de produtos de dados e uma equipe de plataforma que se concentra em recursos técnicos. Esta separação de responsabilidades deve refletir-se na sua plataforma. Você deve encontrar um equilíbrio entre fornecer recursos independentes de domínio e permitir que suas equipes de domínio modelem, processem e distribuam seus dados em toda a organização.
Escolher o nível certo de granularidade de domínio e regras para dissociar usando plataformas não é fácil. Este artigo contém vários cenários que fornecem orientações detalhadas.
Análise à escala da cloud
Quando quiser criar uma malha de dados com o Azure, recomendamos que adote análises em escala de nuvem. Essa estrutura é uma arquitetura de referência implantável e vem com modelos de código aberto e práticas recomendadas. A arquitetura de análise em escala de nuvem tem dois blocos de construção principais que são fundamentais para todas as opções de implantação:
- Zona de aterrissagem de gerenciamento de dados: a base da sua arquitetura de dados. Ele contém todos os recursos críticos para o gerenciamento de dados, como catálogo de dados, linhagem de dados, catálogo de API, gerenciamento de dados mestre e assim por diante.
- Zonas de aterrissagem de dados: assinaturas que hospedam suas soluções de análise e IA. Eles incluem recursos-chave para hospedar uma plataforma de análise.
O diagrama a seguir fornece uma visão geral de uma plataforma de análise em escala de nuvem com uma zona de aterrissagem de gerenciamento de dados e uma única zona de aterrissagem de dados. Nem todos os serviços do Azure são representados no diagrama. Ele foi simplificado para destacar os principais conceitos de organização de recursos dentro dessa arquitetura.
A estrutura de análise baseada em nuvem não é explícita sobre o tipo exato de arquitetura de dados que você deve provisionar. Você pode usá-lo para muitas soluções comuns de análise em escala de nuvem, incluindo data warehouses (corporativos), data lakes, data lake houses e malhas de dados. Todas as soluções de exemplo neste artigo usam arquitetura de malha de dados.
Entenda que todas as arquiteturas aderem aos princípios de malha de dados: propriedade de domínio, dados como produto, plataforma de dados de autoatendimento e governança computacional federada. Caminhos diferentes podem levar a uma malha de dados. Não existe uma única resposta certa ou errada. Você deve fazer as compensações certas para as necessidades da sua organização.
Zona de aterragem de dados única
O padrão de implantação mais simples para criar uma arquitetura de malha de dados envolve uma zona de aterrissagem de gerenciamento de dados e uma zona de aterrissagem de dados. A arquitetura de dados em tal cenário seria semelhante à seguinte:
Neste modelo, todos os seus domínios de dados funcionais residem na mesma zona de aterrissagem de dados. Uma única assinatura contém um conjunto padrão de serviços. Os grupos de recursos segregam diferentes domínios de dados e produtos de dados. Os serviços de dados padrão, como o Azure Data Lake Store, os Aplicativos Lógicos do Azure e o Azure Synapse Analytics, aplicam-se a todos os domínios.
Todos os domínios de dados seguem princípios de malha de dados: os dados seguem a propriedade do domínio e os dados são tratados como produtos. A plataforma é totalmente self-service, embora existam variações limitadas de serviços. Todos os domínios devem aderir e estar em conformidade com os mesmos princípios de gestão de dados.
Essa opção de implantação pode ser útil para empresas menores ou projetos greenfield que desejam adotar a malha de dados, mas não complicar demais as coisas. Essa implantação também pode ser um ponto de partida para uma organização que planeja criar algo mais complexo. Neste caso, planeje expandir para várias zonas de pouso em um momento posterior.
Sistema de origem alinhado e zonas de aterragem alinhadas com o consumidor
No modelo anterior, não levamos em conta outras assinaturas ou aplicativos locais. Você pode alterar ligeiramente o modelo anterior adicionando uma zona de aterrissagem alinhada ao sistema de origem para gerenciar todos os dados recebidos. A integração de dados é um processo difícil, por isso ter duas zonas de aterragem de dados é útil. A integração continua sendo uma das partes mais desafiadoras do uso de dados em geral. A integração também requer muitas vezes ferramentas adicionais para abordar a integração, porque os seus desafios diferem dos da integração. Ajuda a distinguir entre fornecer dados e consumir dados.
Na arquitetura à esquerda deste diagrama, os serviços facilitam a integração de todos os dados, como CDC, serviços para extrair APIs ou serviços de data lake para criar conjuntos de dados dinamicamente. Os serviços nesta plataforma podem extrair dados de ambientes locais, na nuvem ou de fornecedores de SaaS. Esse tipo de plataforma normalmente também tem mais sobrecarga, porque há mais acoplamento com aplicativos operacionais subjacentes. Talvez você queira tratar isso de forma diferente de qualquer uso de dados.
Na arquitetura à direita do diagrama, a organização otimiza para consumo e tem serviços focados em transformar dados em valor. Esses serviços podem incluir aprendizado de máquina, relatórios e assim por diante.
Esses domínios de arquitetura seguem todos os princípios de malha de dados. Os domínios assumem a propriedade dos dados e têm permissão para distribuir dados diretamente para outros domínios.
Zonas de aterrissagem de dados centrais, genéricas e especiais
A próxima opção de implantação é outra iteração do design anterior. Essa implantação segue uma topologia de malha controlada: os dados são distribuídos por meio de um hub central, no qual os dados são particionados por domínio, logicamente isolados e não integrados. O hub desse modelo usa sua própria zona de aterrissagem de dados (independente do domínio) e pode ser propriedade de uma equipe central de governança de dados supervisionando quais dados são distribuídos para quais outros domínios. O hub também possui serviços que facilitam a integração de dados.
Para domínios que exigem serviços padrão para consumir, usar, analisar e criar novos dados, use a zona de aterrissagem de dados genérica. Esta subscrição única contém um conjunto padrão de serviços. Aplique também a virtualização de dados, pois a maioria dos seus produtos de dados já persiste no hub e você não precisa de mais duplicação de dados.
Essa implantação permite "especiais": zonas de pouso extras que você pode provisionar quando não é possível agrupar domínios logicamente. Eles podem ser necessários quando limites regionais ou legais se aplicam, ou quando seus domínios têm requisitos exclusivos e contrastantes. Você também pode precisar deles em situações em que uma forte governança subsidiária global é aplicada, com exceções para atividades no exterior.
Se sua organização precisa controlar quais dados são distribuídos e consumidos por quais domínios, a implantação de hub é uma boa opção. Também é uma opção se você estiver abordando preocupações com variantes de tempo e não voláteis para grandes consumidores de dados. Você pode padronizar fortemente o design do produto de dados, o que permite que seus domínios viajem no tempo e realizem reentregas. Este modelo é especialmente comum dentro do setor financeiro.
Zonas de aterrissagem de dados funcionais e alinhadas regionalmente
O provisionamento de várias zonas de aterrissagem de dados pode ajudá-lo a agrupar domínios funcionais com base na coesão e eficiência para trabalhar e compartilhar dados. Todas as suas zonas de aterrissagem de dados aderem à mesma auditoria e controles, mas você ainda pode ter flexibilidade e alterações de design entre diferentes zonas de aterrissagem de dados.
Determine os domínios de dados funcionais que você deseja agrupar logicamente para uma zona de aterrissagem de dados compartilhados. Por exemplo, você pode implementar os mesmos modelos se tiver limites regionais. Propriedade, segurança ou limites legais podem forçá-lo a segregar domínios. A flexibilidade, o ritmo da mudança e a separação ou venda das suas capacidades também são fatores importantes a considerar.
Mais orientações e melhores práticas podem ser encontradas em domínios de dados.
Diferentes zonas de pouso não ficam sozinhas. Eles podem se conectar a data lakes hospedados em outras zonas. Isso permite que os domínios colaborem em toda a sua empresa. Você também pode aplicar persistência poliglota para misturar diferentes tecnologias de armazenamento de dados. A persistência poliglota permite que seus domínios leiam diretamente dados de outros domínios sem duplicar dados.
Ao implantar várias zonas de aterrissagem de dados, saiba que há sobrecarga de gerenciamento anexada a cada zona de aterrissagem de dados. Você deve aplicar o emparelhamento de VNet entre todas as zonas de aterrissagem de dados, deve gerenciar pontos de extremidade privados extras e assim por diante.
Implantar várias zonas de aterrissagem de dados é uma boa opção se sua arquitetura de dados for grande. Você pode adicionar mais zonas de destino à sua arquitetura para atender às necessidades comuns de vários domínios. Essas zonas de pouso extras usam emparelhamento de rede virtual para se conectar à zona de pouso de gerenciamento de dados e a todas as outras zonas de pouso. O emparelhamento permite que você compartilhe conjuntos de dados e recursos entre suas zonas de destino. A divisão de dados em zonas separadas permite distribuir cargas de trabalho entre suas assinaturas e recursos do Azure. Essa abordagem ajuda a implementar organicamente a malha de dados.
Empresa de grande escala que requer diferentes zonas de gerenciamento de dados
Grandes empresas que operam em escala global podem ter requisitos de gerenciamento de dados contrastantes entre diferentes partes de sua organização. Você pode implantar várias zonas de gerenciamento e aterrissagem de dados juntas para resolver esse problema. O diagrama a seguir mostra um exemplo desse tipo de arquitetura:
Várias zonas de aterrissagem de gerenciamento de dados devem justificar sua sobrecarga e complexidade de integração. Por exemplo, outra zona de aterrissagem de gerenciamento de dados pode fazer sentido para situações em que os (meta)dados da sua organização não devem ser vistos por ninguém fora da organização.
Conclusão
A transição para a malha de dados é uma mudança cultural que envolve nuances, compensações e considerações. Você pode usar análises em escala de nuvem para obter práticas recomendadas e recursos executáveis. As arquiteturas de referência deste artigo oferecem pontos de partida para você iniciar sua implementação.