Zonas de destino de dados
As zonas de destino de dados estão conectadas à zona de destino de gerenciamento de dados por emparelhamento de rede virtual ou pontos de extremidade privados. Cada zona de destino de dados é considerada uma zona de destino relacionada à arquitetura da zona de destino do Azure.
Importante
Antes de provisionar uma zona de destino de dados, verifique se o modelo operacional de DevOps e CI/CD está em vigor e se uma zona de destino de gerenciamento de dados é implantada.
Cada zona de aterrissagem de dados tem várias camadas que permitem agilidade para as integrações de dados de serviço e aplicativos de dados que ela contém. Você pode implantar uma nova zona de destino de dados com um conjunto padrão de serviços que permitem que a zona de destino de dados comece a ingerir e analisar dados.
Uma assinatura típica do Azure associada a uma zona de destino de dados tem a seguinte estrutura:
| Camada | Necessário | Grupos de recursos |
|---|---|---|
| Camada de serviços da plataforma | Sim | |
| Serviços principais | Sim | |
| Aplicativo de Dados | Opcional |
|
| Relatório e visualização | Opcional |
Nota
Embora a camada de serviços Principais esteja marcada como necessária, nem todos os grupos de recursos e serviços incluídos neste artigo podem ser necessários para sua zona de destino de dados.
Arquitetura da zona de destino de dados
A arquitetura da zona de destino de dados ilustra as camadas, seus grupos de recursos e os serviços que cada grupo de recursos contém. A arquitetura apresenta uma visão geral de todos os grupos e funções associados à zona de destino de dados e à extensão do acesso deles aos planos de dados e controle. A arquitetura também ilustra como cada camada se alinha com as responsabilidades do Modelo Operacional.
Dica
Antes de implantar uma zona de destino de dados, considere o número de zonas de destino de dados iniciais que deseja implantar.
Serviços de plataforma
A camada de serviços de plataforma inclui serviços necessários para habilitar a conectividade e a observabilidade à zona de aterrissagem de dados no contexto da análise em escala de nuvem. A tabela a seguir lista os grupos de recursos recomendados.
| Grupo de Recursos | Necessário | Descrição |
|---|---|---|
network-rg |
Sim | Rede |
security-rg |
Sim | Segurança e monitoramento |
Rede
O grupo de recursos de rede contém serviços de conectividade, incluindo as Redes Virtuais do Azure , Grupos de Segurança de Rede (NSG) e tabelas de rotas . Todos esses serviços são implantados em um único grupo de recursos.
A rede virtual da zona de destino de dados é emparelhada automaticamente com a rede virtual da zona de destino de gerenciamento de dados e com a rede virtual da sua assinatura de conectividade.
Segurança e monitoramento
** O grupo de recursos de segurança e monitoramento inclui o Azure Monitor e o Microsoft Defender for Cloud para coletar telemetria de serviço, para definir critérios e alertas de monitoramento, e para aplicar políticas e verificação aos serviços.
Serviços principais
A camada de serviços principais inclui serviços fundamentais necessários para habilitar sua zona de aterrissagem de dados no contexto da análise de escala de nuvem. A tabela a seguir lista os grupos de recursos que fornecem o conjunto padrão de serviços disponíveis em cada zona de destino de dados implantada.
| Grupo de Recursos | Necessário | Descrição |
|---|---|---|
storage-rg |
Sim | Serviços do Data Lake |
runtimes-rg |
Sim | Runtimes de integração compartilhada |
mgmt-rg |
Sim | Agentes de CI/CD |
external-data-rg |
Sim | Armazenamento de dados externo |
data-ingestion-rg |
Opcional | Serviços de ingestão de dados compartilhados |
shared-applications-rg |
Opcional | Aplicativos compartilhados (Synapse ou Databricks) |
Armazenamento
Conforme mostrado no diagrama, três contas do Azure Data Lake Storage Gen2 são provisionadas em um só grupo de recursos dos serviços de data lake. Os dados transformados em diferentes estágios são salvos em um dos data lakes da zona de destino de dados. Os dados estão disponíveis para consumo por suas equipes de análise, ciência de dados e visualização.
As camadas do data lake usam terminologia diferente dependendo da tecnologia e do fornecedor. Esta tabela fornece diretrizes sobre como aplicar termos para análise em escala de nuvem:
| Análise em escala de nuvem | Lago Delta | Outros termos | Descrição |
|---|---|---|---|
| Cru | Bronze | Aterrissagem e conformidade | Tabelas de ingestão |
| Enriquecido | Prata | Zona de padronização | Tabelas refinadas. Entidade completa armazenada, conjuntos de registros prontos para consumo nos sistemas de registro. |
| Coletado | Ouro | Zona do Produto | Recurso ou tabelas agregadas. Zona primária para aplicativos, equipes e usuários consumirem produtos de dados. |
| Desenvolvimento | -- | Zona de Desenvolvimento | Local para engenheiros de dados e cientistas, compreendendo uma área restrita de análise e uma zona de desenvolvimento de produtos. |
Nota
No diagrama anterior, cada zona de destino de dados tem três contas de armazenamento do data lake. No entanto, dependendo de seus requisitos, você pode optar por consolidar suas camadas brutas, enriquecidas e coletadas em uma conta de armazenamento e manter outra conta de armazenamento chamada "workspace" para que os consumidores de dados tragam outros produtos de dados úteis.
Para obter mais informações, consulte:
- visão geral do Azure Data Lake Storage para análise em escala de nuvem
- Padronização de Dados
- provisionar contas do Azure Data Lake Storage Gen2 para cada zona de destino de dados
- principais considerações para o Azure Data Lake Storage
- Configurações de controle de acesso e de data lake no Azure Data Lake Storage
Runtimes de integração compartilhada
O Azure Data Factory e o Azure Synapse Analytics Pipelines usam o IR (Integration Runtimes) para acessar com segurança fontes de dados em redes emparelhadas ou isoladas. Os IRs compartilhados devem ser implantados em uma máquina virtual (ou em conjuntos de dimensionamento de máquinas virtuais do Azure) no grupo de recursos do ambiente de integration runtime compartilhado.
Para habilitar o grupo de recursos compartilhado:
- Crie pelo menos um Azure Data Factory no grupo de recursos de integração compartilhada da zona de destino de dados. Use-o somente para vincular o runtime de integração auto-hospedada compartilhado, não para pipelines de dados.
- Criar e configurar um runtime de integração auto-hospedado na máquina virtual.
- Associe o runtime de integração auto-hospedada aos data factories do Azure nas zonas de destino de dados.
- Use scripts do PowerShell para atualizar periodicamente o runtime de integração auto-hospedada.
Nota
A implantação descreve a implementação de uma única máquina virtual com um runtime de integração auto-hospedado. Você pode associar um runtime de integração auto-hospedada a várias máquinas virtuais locais ou no Azure. Esses computadores são chamados de nós e você pode ter até quatro nós associados a um runtime de integração auto-hospedada. Os benefícios de ter vários nós são:
- Maior disponibilidade do runtime de integração auto-hospedada para que ele não seja mais o único ponto de falha em seu aplicativo de dados ou na orquestração da integração de dados na nuvem.
- Desempenho e taxa de transferência aprimorados durante a movimentação de dados entre serviços de dados locais e de nuvem. Obtenha mais informações sobre comparações de desempenho .
Para associar vários nós, instale o software do runtime de integração auto-hospedada no Centro de Download. Em seguida, registre-o usando uma das chaves de autenticação obtidas do cmdlet New-AzDataFactoryV2IntegrationRuntimeKey, conforme descrito no tutorial .
Mais informações são detalhadas em Alta disponibilidade e escalabilidade do Azure Data Factory.
Importante
Implante runtimes de integração compartilhada o mais próximo possível da fonte de dados. Você pode implantar os runtimes de integração em uma zona de destino de dados, em nuvens de terceiros ou em uma nuvem privada, desde que a máquina virtual tenha conectividade com as fontes de dados necessárias.
Gestão
Os Agentes de CI/CD são executados em máquinas virtuais e ajudam a implantar artefatos do repositório de código-fonte, incluindo aplicativos de dados e alterações na zona de destino de dados.
Para obter mais informações, confira Agente de pipeline do Azure.
Armazenamento externo
Os editores de dados de parceiros precisam colocar dados na sua plataforma para que as suas equipes de aplicativos de dados possam extraí-los para os respectivos data lakes. Você também pode ter fontes de dados internas ou externas que não podem dar suporte aos requisitos de conectividade ou autenticação impostos no restante das zonas de destino de dados. Usar uma conta de armazenamento separada é a abordagem recomendada para receber dados e, em seguida, um runtime de integração compartilhada ou um processo de ingestão semelhante para trazê-los para o pipeline de processamento. Como veremos no diagrama a seguir, o grupo de recursos de armazenamento de ingestão de upload permite provisionar repositórios de blobs para esses casos de uso.
As equipes de aplicativos de dados solicitam os blobs de armazenamento. Essas solicitações são aprovadas pela equipe de operações da zona de destino de dados. Os dados devem ser excluídos de seu blob de armazenamento de origem após serem ingeridos no armazenamento de dados brutos.
Importante
Como o provisionamento de blobs do Armazenamento do Azure ocorre conforme a necessidade, recomendamos implantar inicialmente um grupo de recursos de serviços de armazenamento vazio em cada zona de destino de dados.
Ingestão de dados
Esse grupo de recursos é opcional e não impede a implantação da zona de aterrissagem. É aplicável se você tiver ou estiver desenvolvendo um mecanismo de ingestão independente de dados que ingerir automaticamente dados com base em metadados registrados, incluindo cadeias de conexão, caminhos para transferência de dados e agendamentos de ingestão.
O grupo de recursos de ingestão e processamento tem serviços-chave para esse tipo de estrutura.
Implante uma instância do Banco de Dados SQL do Azure para armazenar metadados usados pelo Azure Data Factory. Provisione um Azure Key Vault para armazenar segredos relacionados aos serviços de ingestão automatizados. Esses segredos podem incluir:
- Credenciais de metastore do Azure Data Factory
- Credenciais da entidade de serviço para o processo automatizado de ingestão
Para obter mais informações, consulte Como as estruturas de ingestão automatizadas dão suporte à análise em escala de nuvem no Azure.
Os serviços incluídos neste grupo de recursos incluem:
| Serviço | Necessário | Diretrizes |
|---|---|---|
| Azure Data Factory | Sim | O Azure Data Factory é seu mecanismo de orquestração para ingestão independente de dados. |
| Banco de Dados SQL do Azure | Sim | Azure SQL Database é o metastore do Azure Data Factory. |
| Hubs de Eventos ou Hub IoT | Opcional | Os Hubs de Eventos ou o hub IoT pode fornecer streaming em tempo real para os Hubs de Eventos, além de processamento em lote e streaming por meio de um workspace de engenharia do Databricks. |
| Azure Databricks | Opcional | Você pode implantar o Azure Databricks ou o Azure Synapse Spark para uso com o mecanismo de ingestão independente de dados. |
| Azure Synapse | Opcional | Você pode implantar o Azure Databricks ou o Azure Synapse Spark para usá-lo com o mecanismo de ingestão independente de dados. |
Aplicativos compartilhados
Esse grupo de recursos opcional é usado quando há a necessidade de ter um conjunto de serviços compartilhados disponibilizado para todas as equipes que criam aplicativos de dados nesta zona de destino de dados. Os usos de exemplo incluem:
- Um workspace do Azure Databricks usado como um Metastore compartilhado para todos os outros workspaces do Databricks criados na mesma zona de destino de dados (ou região)
- Uma instância compartilhada do Azure Synapse Analytics usando pools de SQL sem servidor para permitir que os usuários consultem entre contas de armazenamento isoladas.
Nota
O Azure Databricks usa o Unity Catalog para regulamentar o acesso e a visibilidade de metastores nos espaços de trabalho do Databricks. O Catálogo do Unity está habilitado no nível de locatário, mas os metarrepositórios estão alinhados às regiões do Azure. Na prática, isso significa que todos os workspaces do Databricks habilitados para o Catálogo Unity em uma determinada região do Azure precisarão se registrar no mesmo Metastore. Para obter mais informações, confira Práticas recomendadas do catálogo do Unity.
Siga as práticas recomendadas de análise em escala de nuvem para integrar o Azure Databricks:
- Proteger o acesso ao Azure Data Lake Gen2 por meio do Azure Databricks
- práticas recomendadas do Azure Databricks
Aplicativo de dados
Cada zona de aterrissagem de dados pode ter vários aplicativos de dados. Você pode criar esses aplicativos ingerindo dados de várias fontes. Você também pode criar aplicativos de dados de outros aplicativos de dados dentro da mesma zona de destino de dados ou de outras zonas de destino de dados. A criação dos aplicativos de dados está sujeita à aprovação do administrador de dados.
Grupo de recursos do aplicativo de dados
O grupo de recursos do aplicativo de dados inclui todos os serviços necessários para fazer esse aplicativo de dados. Por exemplo, um Banco de Dados do Azure é necessário para o MySQL, que é usado por uma ferramenta de visualização. Os dados devem ser ingeridos e transformados antes de serem inseridos nesse banco de dados MySQL. Nesse caso, você pode implantar o Banco de Dados do Azure para MySQL e um Azure Data Factory no grupo de recursos do aplicativo de dados.
Dica
Se você optar por não implementar um mecanismo agnóstico de dados para ingestão única a partir de fontes operacionais, ou se conexões complexas não forem facilitadas em seu mecanismo agnóstico de dados, crie um aplicativo de dados alinhado à origem. Para obter mais informações, confira Aplicativos de dados (alinhados à origem).
Para obter mais informações sobre como integrar produtos de dados, consulte aplicativos de dados de análise em escala de nuvem no Azure.
Relatórios e Visualização
Você pode usar ferramentas de visualização e relatórios em workspaces do Fabric, que têm muitas semelhanças com workspaces do Power BI, sem precisar implantar recursos exclusivos na zona de destino de dados. Você pode incluir um grupo de recursos para implantar a capacidade do Fabric, máquinas virtuais para gateways de dados ou outros serviços de dados necessários para entregar seu aplicativo de dados ao usuário final.