Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve como um escritório fictício de planejamento urbano poderia usar essa solução. A solução fornece um pipeline de dados de ponta a ponta que segue o padrão de arquitetura MDW, juntamente com os processos correspondentes de DevOps e DataOps, para avaliar o uso do estacionamento e tomar decisões de negócios mais informadas.
Architecture
O diagrama a seguir mostra a arquitetura geral da solução.
Descarregue um ficheiro Visio desta arquitetura.
Fluxo de dados
Azure Data Factory orquestra e Azure Data Lake Storage Gen2 armazena os dados.
O seguinte fluxo de dados corresponde ao diagrama anterior:
A API do serviço Web de estacionamento da cidade da Contoso está disponível para transferir dados dos lugares de estacionamento.
Há um trabalho de cópia de fábrica de dados que transfere os dados para o esquema de aterrissagem.
De seguida, o Azure Databricks limpa e padroniza os dados. Ele pega os dados brutos e os condiciona para que os cientistas de dados possam usá-los.
Se a validação revelar dados incorretos, eles serão despejados no esquema malformado.
Important
As pessoas perguntaram porque é que os dados não são validados antes de serem armazenados no Data Lake Storage. O motivo é que a validação pode introduzir um bug que pode corromper o conjunto de dados. Se introduzires um bug nesta etapa, poderás corrigi-lo e reexecutar a tua linha de processamento. Se despejaste os dados maus antes de os adicionares ao Data Lake Storage, então os dados corrompidos são inúteis porque não consegues reproduzir o pipeline.
Há um segundo passo de transformação do Azure Databricks que converte os dados para um formato que podes armazenar no data warehouse.
Finalmente, o pipeline serve os dados de duas maneiras diferentes:
O Databricks disponibiliza os dados para o cientista de dados para que ele possa treinar modelos.
A Polybase move os dados do data lake para o Azure Synapse Analytics e o Power BI acede aos dados e apresenta-os ao utilizador empresarial.
Components
Azure Data Factory é um serviço de integração de dados baseado na cloud que permite a movimentação e orquestração de dados. Nessa arquitetura, ele inicia o pipeline copiando dados da API do serviço web de estacionamento municipal da Contoso para a zona de aterrissagem do data lake.
Azure Data Lake Storage Gen2 é um data lake escalável e seguro baseado no Armazenamento de Blobs do Azure que suporta armazenamento em camadas e pipelines reexecutáveis. Nessa arquitetura, ele serve como o repositório central para dados brutos e processados em zonas de dados de pouso, malformadas e validadas.
Azure Databricks é uma plataforma de análise baseada no Apache Spark, concebida para big data e aprendizagem automática. Nessa arquitetura, ele executa duas etapas críticas de transformação. Primeiro, ele limpa e padroniza dados brutos enquanto filtra registros malformados para um esquema separado. Em seguida, ele converte dados validados em um formato adequado para armazenamento de data warehouse e disponibiliza dados processados para cientistas de dados para treinamento de modelos.
Azure Key Vault é um serviço cloud seguro para gerir segredos, chaves e certificados. Nessa arquitetura, ele armazena definições de configuração confidenciais e credenciais usadas em todo o pipeline, fornecendo gerenciamento de configuração centralizado e seguro.
Azure Synapse Analytics é um serviço integrado de análise que combina capacidades de big data e data warehousing. Nesta arquitetura, serve como o data warehouse que ingere dados transformados do Data Lake Storage via PolyBase para consultas e relatórios.
Power BI é uma ferramenta de análise de negócios que oferece visualizações e dashboards interativos. Nesta arquitetura, liga-se ao Azure Synapse Analytics para apresentar insights sobre dados de utilização de estacionamento a planeadores urbanos, para uma tomada de decisão informada.
Detalhes do cenário
Um armazém de dados moderno (MDW) permite-lhe reunir facilmente todos os seus dados em qualquer escala. Não importa se são dados estruturados, não estruturados ou semiestruturados. Você pode obter informações sobre um MDW por meio de painéis analíticos, relatórios operacionais ou análises avançadas para todos os seus usuários.
A configuração de um ambiente MDW para ambientes de desenvolvimento (dev) e produção (prod) é complexa. Automatizar o processo é fundamental. Ajuda a aumentar a produtividade enquanto minimiza o risco de erros.
Este artigo descreve como um escritório fictício de planejamento urbano poderia usar essa solução. A solução fornece um pipeline de dados de ponta a ponta que segue o padrão de arquitetura MDW, juntamente com os processos correspondentes de DevOps e DataOps, para avaliar o uso do estacionamento e tomar decisões de negócios mais informadas.
Requisitos da solução
Capacidade de recolher dados de diferentes fontes ou sistemas.
Infraestrutura como código: implante novos ambientes de desenvolvimento e preparo (stg) de forma automatizada.
Implante alterações de aplicativos em diferentes ambientes de maneira automatizada:
Implemente pipelines de integração contínua e entrega contínua (CI/CD).
Use portões de implantação para aprovações manuais.
Pipeline como código: certifique-se de que as definições de pipeline de CI/CD estejam sob controle do código-fonte.
Realize testes de integração em alterações usando um conjunto de dados de exemplo.
Executar pipelines de forma programada.
Apoie o desenvolvimento ágil futuro, incluindo a adição de cargas de trabalho de ciência de dados.
Suporte para segurança em nível de linha e em nível de objeto:
O recurso de segurança está disponível no Banco de dados SQL.
Também pode encontrá-lo no Azure Synapse Analytics, Azure Analysis Services e Power BI.
Suporte para 10 utilizadores simultâneos do painel de controlo e 20 utilizadores avançados simultâneos.
O pipeline de dados deve validar os dados e filtrar os registos malformados enviando-os para um armazenamento especificado.
Suporte ao monitoramento.
Potenciais casos de utilização
Este artigo usa a cidade fictícia de Contoso para descrever o cenário de caso de uso. Na narrativa, a Contoso possui e gerencia sensores de estacionamento para a cidade. Ele também possui as APIs que se conectam e obtêm dados dos sensores. Eles precisam de uma plataforma que colete dados de muitas fontes diferentes. Os dados devem ser validados, limpos e transformados em um esquema conhecido. Os planeadores urbanos de Contoso podem então explorar e avaliar dados de relatórios sobre a utilização do estacionamento com ferramentas de visualização de dados, como o Power BI, para determinar se precisam de mais estacionamento ou recursos relacionados.
Considerations
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para mais informações, consulte Microsoft Azure Well-Architected Framework.
As considerações nesta seção resumem os principais aprendizados e práticas recomendadas demonstrados por esta solução:
Utilize a organização por camadas no seu data lake. Manter dados de origem não modificados na zona de aterragem, encaminhar registos que falham na validação para a zona malformada e transformar os dados validados num formato pronto para armazenamento. Manter os dados de origem permite-lhe reprocessá-los sem voltar ao sistema de origem. Para o padrão análogo de casas de lago em bronze, prata e ouro, veja arquitetura de medalhões.
Torna os teus pipelines de dados rejogáveis e idempotentes. Conceba etapas de transformação de modo que, ao executá-las novamente com a mesma entrada, produzam o mesmo resultado. Reexecutar um pipeline permite corrigir um defeito na lógica de transformação e reprocessar dados históricos em vez de os descartar.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.
- Configuração segura e centralizada. Armazene cadeias de ligação, chaves e outros segredos no Key Vault em vez de em cadernos, definições de pipeline ou controlo de versão. Faça-lhes referência nos serviços ligados do Data Factory e nos âmbitos de segredos do Azure Databricks, para que cada ambiente resolva os respetivos valores.
Excelência Operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.
Valide os dados logo no início do seu fluxo de processamento. Aplicar verificações de esquema e qualidade no primeiro passo de transformação e encaminhar os registos que falharem para o esquema malformado. A validação antecipada mantém registos defeituosos fora dos níveis posteriores e dá-te um registo do que foi rejeitado e porquê.
Garantir que o código de transformação de dados é testável. Refatore a lógica de transformação em funções e módulos executados fora de um notebook, para que possam ser abrangidos por testes unitários no pipeline de validação do pull request.
Tenha um pipeline de CI/CD. Crie e disponibilize todos os ambientes a partir do controlo de código-fonte, em vez de o fazer manualmente. Para a mecânica específica da tecnologia, veja CI/CD no Azure Data Factory e CI/CD no Azure Databricks.
Monitorize infraestruturas, pipelines e dados. Recolha métricas e registos de cada camada para que uma falha apareça como um alerta em vez de um relatório obsoleto. Para mais informações, consulte Monitor Data Factory.
Implementar este cenário
A lista seguinte contém os passos de alto nível necessários para configurar esta solução com os correspondentes pipelines de build e release.
Configuração e implantação
Configuração inicial: Instale quaisquer pré-requisitos, crie o repositório Git que guarda a infraestrutura, notebook e código do pipeline, e defina as variáveis de ambiente necessárias.
Implante recursos Azure: Use uma infraestrutura como implementação de código, como Bicep ou Terraform, para implementar os recursos Azure e os princípios de serviço Microsoft Entra para cada ambiente. Configure separadamente as definições do Azure Pipelines, os grupos de variáveis e as ligações de serviços que invocam a implementação da infraestrutura.
Configure a integração com o Git na Data Factory de desenvolvimento: Configure a integração com o Git para que a Data Factory de desenvolvimento faça commit no seu repositório.
Realize uma compilação e liberação iniciais: crie uma alteração de exemplo no Data Factory, como habilitar um gatilho de agendamento e, em seguida, observe a alteração ser implantada automaticamente em todos os ambientes.
Integração contínua e entrega contínua (CI/CD)
O diagrama seguinte demonstra o processo CI/CD e a sequência para os pipelines de construção e lançamento.
Descarregue um ficheiro Visio desta arquitetura.
Os desenvolvedores desenvolvem em seus próprios ambientes isolados dentro do grupo de recursos de desenvolvimento e inserem alterações em suas próprias ramificações temporárias do Git. Por exemplo,
<developer_name>/<branch_name>.Quando as alterações são concluídas, os desenvolvedores enviam uma solicitação pull (PR) para a ramificação principal para revisão. Isso inicia automaticamente o pipeline de validação de RP, que executa os testes de unidade, o linting e as compilações do DACPAC (pacote de aplicativo da camada de dados).
Após a conclusão da validação de RP, o commit to main acionará um pipeline de construção que publica todos os artefatos de construção necessários.
A conclusão de um pipeline de construção bem-sucedido desencadeará o primeiro estágio do pipeline de liberação. Isso implanta os artefatos de build publicados no ambiente de desenvolvimento, exceto pelo Data Factory.
Os desenvolvedores publicam manualmente no dev Data Factory a partir da ramificação de colaboração (principal). A publicação manual atualiza os modelos de Azure Resource Manager na branch
adf_publish.A conclusão bem-sucedida da primeira etapa aciona uma porta de aprovação manual.
Após a aprovação, o pipeline de lançamento continua com o segundo estágio, implantando alterações no ambiente STG.
Execute testes de integração para testar alterações no ambiente stg.
Após a conclusão bem-sucedida do segundo estágio, o pipeline aciona uma segunda porta de aprovação manual.
Após aprovação, o pipeline de publicação continua com o terceiro estágio, implantando as alterações no ambiente de produção.
Para mais informações sobre como implementar estas etapas, consulte CI/CD no Azure Data Factory.
Testing
A solução inclui suporte para testes de unidade e testes de integração. Os testes unitários cobrem os módulos de transformação em Python e os testes de integração acionam um pipeline do Data Factory e verificam o seu resultado como parte da implementação no ambiente de pré-produção. Para mais informações, consulte Testes unitários para blocos de notas.
Observabilidade e monitorização
A solução suporta observabilidade e monitoramento para Databricks e Data Factory. Para Databricks, utilize o registo de auditoria incorporado da plataforma (a system.access.audit tabela) e a monitorização da execução de trabalhos em vez de exportar todos os diagnósticos por defeito. Se precisar de enviar os registos de diagnóstico do Databricks para uma área de trabalho do Log Analytics para alertas centralizados, essa capacidade requer o plano Premium, aplica-se a registos em vez de métricas e exige um controlo de acesso rigoroso, porque os registos de auditoria podem conter detalhes sensíveis sobre o seu ambiente. Para o Data Factory, encaminhar registos e métricas de diagnóstico para um espaço de trabalho do Log Analytics e configurar alertas para falhas de pipeline e latência das tarefas. Para mais informações, consulte Monitor Data Factory.
Próximos passos
Os seguintes recursos ajudam-no a implementar as práticas DataOps que este artigo descreve.
Integração e entrega contínuas
Observability/monitoring
Azure Databricks
Data Factory
- Monitor Azure Data Factory com Azure Monitor
- Crie alertas para monitorizar proativamente os seus pipelines de data factory
Azure Synapse Analytics
- Monitorização da utilização de recursos e da atividade de consultas em Azure Synapse Analytics
- Monitoriza a carga de trabalho do teu pool SQL Azure Synapse Analytics usando DMVs
Armazenamento do Azure
Resiliência e recuperação após desastre
Azure Databricks
Data Factory
Azure Synapse Analytics
- Backups geográficos e recuperação de desastres
- Restauração geográfica para SQL Pool
Armazenamento do Azure
- Recuperação após desastre e failover de contas de armazenamento
- Melhores práticas para usar Azure Data Lake Storage Gen2 – Alta disponibilidade e Recuperação em Desastres
- Redundância de Armazenamento do Azure
Visão geral detalhada
Para uma visão detalhada da solução e dos conceitos-chave, veja a seguinte gravação em vídeo: DataDevOps for the Modern Data Warehouse em Microsoft Azure