Produtos de dados da análise de escala de nuvem no Azure
Os produtos de dados são dados tratados como produtos e calculados, salvos e tratados por serviços de persistência poliglota, que podem ser exigidos por determinados casos de uso. O processo de criar e tratar um produto de dados pode exigir serviços e tecnologias que não estão incluídos nos serviços principais da zona de destino de dados. Um exemplo disso seria relatar com requisitos de nicho, como conformidade e relatório fiscal.
Considerações sobre o design
Uma zona de destino de dados pode ser tratada por vários produtos de dados criados pela ingestão de dados na mesma zona de destino de dados ou em várias zonas de destino de dados. Isso é mostrado no diagrama a seguir.
O exemplo acima mostra:
- Consumo de dados interzonas:
- O produto de dados B consome os dados do produto de dados A e de outros produtos de dados ou de dados existentes no data lake na sua própria zona de destino.
- Os produtos de dados C e D consomem apenas dados em suas próprias zonas de destino de dados.
- Consumo de dados interzonas:
- O produto de dados B também consome dados do produto de dados C e os dados no data lake de terceiros da zona de destino.
Importante
No caso de consumo de dados entre zonas, como o produto de dados B é criado pela leitura na zona de destino de dados 3, esse acesso de leitura exige a aprovação das operações da zona de destino de dados e das equipes de operações de integração da zona de destino de dados 3.
Importante
O produto de dados B consome dados dos produtos de dados A e C. Antes que isso possa acontecer, o produto de dados B deve registrar o consumo de produtos de dados por meio de contratos de compartilhamento de dados. Este contrato de compartilhamento de dados deve atualizar a linhagem do produto de dados a para o produto de dados B e do produto de dados C para o produto de dados B.
O grupo de recursos de um produto de dados inclui todos os serviços necessários para criá-lo e mantê-lo. Podemos chamar esse grupo de recursos de aplicativo de dados. Os exemplos de serviços que podem fazer parte de um aplicativo de dados incluem Azure Functions, Serviço de Aplicativo do Azure, Aplicativos Lógicos, Azure Analysis Services, Serviços Cognitivos do Azure, Azure Machine Learning, Banco de Dados SQL do Azure, Banco de Dados do Azure para MySQL e Azure Cosmos DB. Para obter mais informações, confira os exemplos de aplicativo de dados.
Os produtos de dados têm dados das fontes de dados de READ, que tiveram algumas transformações de dados aplicadas. Os exemplos podem ser um conjunto de dados recém coletado ou um relatório de BI.
Recomendações sobre design
Crie produtos de dados na zona de destino de dados ao aderir a princípios de design que permitem escalar com a governança de dados. As seções a seguir fornecem as recomendações de design para ajudar a planejar o ecossistema de aplicativos de dados.
Implanta vários grupos de recursos
Cada aplicativo de dados é um grupo de recursos. Como os aplicativos de dados são serviços de computação, serviços de persistência poliglota ou ambos, eles só podem ser necessários dependendo de determinados casos de uso. Assim, eles podem ser considerados um componente opcional da zona de destino de dados. Caso você precise de aplicativos de dados, crie vários grupos de recursos por aplicativo de dados, conforme mostra o diagrama a seguir.
Obter proteções
O Azure Policy conduz a configuração padrão dos serviços em uma zona de destino de dados. Pense na análise operacional como vários grupos de recursos que a equipe de produto de dados pode solicitar de um catálogo de serviços padrão. Usando o Azure Policy, você pode configurar o limite de segurança e o conjunto de recursos necessário.
Importante
Para gerar consistência, configure um Azure Policy para cada aplicativo de dados.
Consumir dados de vários locais
Os aplicativos de dados gerenciam, organizam e fazem sentido dos dados provenientes de vários ativos de dados e apresentam os insights obtidos. Um produto de dados é o resultado dos dados de um ou vários aplicativos de dados nas zonas de destino de dados. Permita que os aplicativos de dados acessem dados de várias fontes quando necessário.
Escale conforme necessário
Os serviços que compõem os aplicativos de dados são implantações incrementais para a zona de destino de dados. Escale os aplicativos de dados conforme necessário.
Habilitar descoberta de dados
Registre automaticamente os produtos de dados em um catálogo de dados, como o Azure Purview, para permitir a verificação de dados.
Identificar seus produtos de dados
Ao começar a planejar uma zona de destino de dados, identifique quantos produtos de dados (e os aplicativos de dados que os geram e mantêm), conforme necessário, para ajudar a impulsionar a arquitetura do aplicativo de produto de dados. A conformidade com a governança de plataforma implementada deve desempenhar o papel principal nas decisões.
Concentre-se em como os aplicativos de dados são produtores e consumidores de dados para outros. Por exemplo, suponha que você identificou um conjunto de produtos de dados (A, B, C e D) que são dados produzidos e consumidos. Você precisa dos produtos de dados A e D como fontes para os dados no Aplicativo de Dados B para o produto de dados B. O produto de dados B é criado com base nos dados que o Aplicativo de Dados B consome dos produtos de dados A e D. O Aplicativo de Dados B atua como próprio produtor de dados e também produz dados para o produto de dados C.
Controlar o ambiente de aplicativo de dados com a infraestrutura como código
A governança e a infraestrutura como código devem controlar o ambiente de aplicativos de dados em todo o ecossistema de produtos de dados, conforme mostrado no diagrama anterior.
Publicar modelos de dados
As equipes de produto de dados devem publicar os modelos de dados em um repositório de modelagem.
Definir expectativas para usuários de produtos de dados
Atualize os contratos de compartilhamento de dados com os contratos de nível de serviço e as certificações para os produtos de dados, para que você transmita expectativas precisas para os possíveis usuários do produto de dados.
Linhagem de captura
Se o produto de dados B for criado com base nos dados provenientes dos produtos de dados A e D, a linhagem deverá ser capturada de A e D para B. Uma linhagem adicional também deve ser capturada para o produto de dados C, já que ele é criado usando dados do produto de dados B. A linhagem atualizada deve ser capturada em um aplicativo de linhagem de dados, antes de cada versão do produto de dados.
Observação
O uso do Azure Pipelines permite que você crie portões de aprovação e invoque funções que podem garantir que os metadados, a linhagem e os SLAs sejam registrados no serviço de governança correto.
Definir a arquitetura do aplicativo de dados
Você deve criar uma arquitetura detalhada para cada produto de dados, que defina totalmente a relação com outros produtos de dados, as dependências e os requisitos de acesso.
Cenário de design de exemplo
Para entender o processo de definição da arquitetura, explore o exemplo a seguir de uma instituição financeira e o respectivo produto de dados de monitoramento de crédito.
O produto de dados de monitoramento de crédito mostrado neste diagrama consome dados de um armazenamento de dados de leitura ingerido pela equipe de operações de integração. Ele gerar produtos de dados também consumidos por outros dois produtos de dados.
Observação
Um armazenamento ou uma fonte de dados de leitura também é conhecido como fonte de registro áurea. Essas fontes de dados foram limpas, mas não tiveram transformações aplicadas.
A equipe de produto de dados de monitoramento de crédito solicita acesso de leitura aos armazenamentos de dados de leitura que eles precisam para a criação dos produtos de dados. As solicitações são encaminhadas para os proprietários dos dados para aprovação. Depois de receber aprovação, a equipe de produto pode começar a criar o aplicativo de dados.
Os dados da fonte de dados de leitura são transformados nos produtos de dados de monitoramento de crédito. Os novos produtos de dados são armazenados na camada coletada do data lake. Esses novos produtos de dados e a nova linhagem de dados devem ser registrados como parte do processo de implantação do DevOps. Uma função pode verificar os metadados registrados com a estrutura física do ativo de dados. Ela deve registrar a dependência nos ativos de dados e nos produtos de dados da fonte de dados de leitura.
A equipe de produto de dados de aprovação de empréstimo tem uma dependência de alguns dos produtos de dados de monitoramento de crédito. A equipe de aprovação de empréstimo deve solicitar acesso de leitura aos produtos de dados de monitoramento de crédito necessários para os produtos de dados. Depois de liberar o produto de dados de aprovação de empréstimo e o aplicativo de dados, todos os ativos, a linhagem e os modelos do produto de dados devem ser registrados nos serviços de governança relevantes.
Aplicativos de dados de exemplo
As seções a seguir contêm aplicativos de dados de exemplo para ilustrar ainda melhor os cenários de aplicativo de dados.
Aplicativo de dados de análise de dados e de ciência de dados
Um aplicativo para análise de dados e ciência de dados pode conter os serviços mostrados no aplicativo de dados de exemplo product-analytics-rg.
Observação
O aplicativo de dados acima está disponível como um modelo, que implanta um conjunto de serviços que você pode usar para análise de dados e ciência de dados. Assim como todos os nossos modelos, esse modelo de aplicativo de produto de dados é um blueprint que você pode usar para criar ambientes rapidamente para equipes multifuncionais. Todos os serviços desnecessários devem ser desabilitados explicitamente.
O modelo de Análise de Produtos de Dados contém todos os modelos para implantar um produto de dados para análise e ciência de dados dentro de uma zona de destino de dados do cenário de análise de escala de nuvem.
Os artefatos de implantação e código incluem os seguintes serviços:
- Machine Learning
- Key Vault
- Application Insights
- Storage
- Registro de Contêiner
- Serviços Cognitivos (opcional)
- Data Factory (selecione entre o Data Factory e o Synapse)
- Workspace do Synapse (selecione entre o Data Factory e o Synapse)
- Azure Search (opcional)
- Pool de SQL (opcional)
- Pool de Big Data (opcional)
Aplicativo de Dados em Lote
O modelo de Aplicativo de Dados em Lote contém todos os modelos para implantar um produto de dados para processamento de dados em lote dentro de uma zona de destino de dados do cenário de análise de escala de nuvem.
Os artefatos de implantação e código incluem os seguintes serviços:
- Key Vault
- Data Factory (selecione entre o Data Factory e o Synapse)
- Azure Cosmos DB (opcional)
- Workspace do Synapse (selecione entre o Data Factory e o Synapse)
- Banco de Dados MySQL (opcional)
- Banco de Dados SQL do Azure (opcional)
- Banco de Dados PostgreSQL (opcional)
- Banco de Dados MariaDB (opcional)
- Pool de SQL (opcional)
- SQL Server (opcional)
- Pool Elástico SQL (opcional)
- Pool de Big Data
Aplicativo de Dados de Streaming
O modelo de Aplicativo de Dados de Streaming contém todos os modelos para implantar um produto de dados para processamento de dados em tempo real dentro de uma zona de destino de dados do cenário de análise de escala de nuvem
Os artefatos de implantação e código incluem os seguintes serviços:
- Key Vault
- Hubs de Evento
- Hub IoT
- Stream Analytics (opcional)
- Azure Cosmos DB (opcional)
- Workspace do Synapse
- Banco de Dados SQL do Azure (opcional)
- Pool de SQL (opcional)
- SQL Server (opcional)
- Pool Elástico SQL (opcional)
- Pool de Big Data
- Data Explorer (opcional)
Para localizar os repositórios que contêm os modelos de implantação mencionados anteriormente, veja os modelos de implantação para análise de escala de nuvem