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.
Arquitetura
O diagrama a seguir mostra a arquitetura geral da solução.
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados
O Azure Data Factory orquestra e o Azure Data Lake Storage Gen2 armazena os dados:
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.
Em 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.
Importante
As pessoas perguntaram por que os dados não são validados antes de serem armazenados no Armazenamento Data Lake. O motivo é que a validação pode introduzir um bug que pode corromper o conjunto de dados. Se você introduzir um bug nesta etapa, poderá corrigi-lo e repetir seu pipeline. Se você despejou os dados incorretos antes de adicioná-los ao Armazenamento Data Lake, os dados corrompidos serão inúteis porque você não poderá reproduzir seu pipeline.
Há uma segunda etapa de transformação do Azure Databricks que converte os dados em um formato que você pode 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.
O Polybase move os dados do data lake para o Azure Synapse Analytics e o Power BI acessa os dados e os apresenta ao usuário corporativo.
Componentes
A solução utiliza estes componentes:
Azure Data Lake Storage Gen2 (Armazenamento do Azure Data Lake Gen2)
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.
Execute 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.
Você também pode encontrá-lo no Azure Synapse Analytics, Azure Analysis Services e Power BI.
Suporte para 10 usuários simultâneos do painel e 20 usuários avançados simultâneos.
O pipeline de dados deve realizar a validação de dados e filtrar registros malformados para um armazenamento especificado.
Suporte ao monitoramento.
Configuração centralizada em um armazenamento seguro como o Azure Key Vault.
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 planejadores de cidades da Contoso podem explorar e avaliar dados de relatório sobre o uso de estacionamento com ferramentas de visualização de dados, como o Power BI, para determinar se precisam de mais estacionamento ou recursos relacionados.
Considerações
Essas 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 obter 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:
Nota
Cada consideração nesta seção vincula-se à seção Key Learnings relacionada nos documentos para o exemplo de solução de sensor de estacionamento no GitHub.
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.
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.
Ter um pipeline de CI/CD.
Implementar este cenário
A lista a seguir contém as etapas de alto nível necessárias para configurar a solução de sensores de estacionamento com os pipelines de construção e liberação correspondentes. Você pode encontrar etapas de configuração detalhadas e pré-requisitos neste repositório de Exemplos do Azure.
Configuração e implantação
Configuração inicial: instale todos os pré-requisitos, importe o repositório GitHub de Exemplos do Azure para seu próprio repositório e defina as variáveis de ambiente necessárias.
Implantar recursos do Azure: a solução vem com um script de implantação automatizado. Ele implanta todos os recursos necessários do Azure e as entidades de serviço do Microsoft Entra por ambiente. O script também implanta Pipelines do Azure, grupos de variáveis e conexões de serviço.
Configurar a integração do Git no dev Data Factory: configure a integração do Git para trabalhar com o repositório GitHub importado.
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.
Recursos implantados
Se a implantação for bem-sucedida, deve haver três grupos de recursos no Azure representando três ambientes: dev, stg e prod. Também deve haver pipelines de compilação e lançamento de ponta a ponta no Azure DevOps que possam implantar automaticamente as alterações nesses três ambientes.
Para obter uma lista detalhada de todos os recursos, consulte a seção Recursos implantados do Leiame de demonstração do DataOps - Parking Sensor.
Integração contínua e entrega contínua (CI/CD)
O diagrama abaixo demonstra o processo e a sequência de CI/CD para os pipelines de compilação e lançamento.
Transfira um ficheiro do Visio desta arquitetura.
Os desenvolvedores desenvolvem em seus próprios ambientes de sandbox dentro do grupo de recursos de desenvolvimento e cometem alterações em suas próprias ramificações Git de curta duração. 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 compilação de publicação no ambiente de desenvolvimento, exceto para o 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 do Azure Resource Manager na
adf_publishramificação.A conclusão bem-sucedida da primeira etapa aciona uma porta de aprovação manual.
Na aprovação, o pipeline de liberação 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.
Na aprovação, o pipeline de liberação continua com o terceiro estágio, implantando alterações no ambiente prod.
Para obter mais informações, leia a seção Pipeline de compilação e liberação do README.
Testar
A solução inclui suporte para testes de unidade e testes de integração. Ele usa pytest-Data Factory e o Nutter Testing Framework. Para obter mais informações, consulte a seção Teste do LEIA-ME.
Observabilidade e monitorização
A solução suporta observabilidade e monitoramento para Databricks e Data Factory. Para obter mais informações, consulte a seção Observabilidade/Monitoramento do LEIA-ME.
Próximos passos
Se você quiser implantar a solução, siga as etapas na seção Como usar o exemplo do Leiame de demonstração do DataOps - Parking Sensor.
Exemplos de código de solução no GitHub
Observabilidade/monitorização
Azure Databricks
- Monitorando o Azure Databricks com o Azure Monitor
- Monitorando trabalhos do Azure Databricks com o Application Insights
Data Factory
- Monitorar o Azure Data Factory com o Azure Monitor
- Crie alertas para monitorar proativamente seus pipelines de data factory
Azure Synapse Analytics
- Monitorando a utilização de recursos e a atividade de consulta no Azure Synapse Analytics
- Monitore sua carga de trabalho do pool SQL do Azure Synapse Analytics usando DMVs
Armazenamento do Azure
Resiliência e recuperação após desastre
Azure Databricks
Data Factory
Azure Synapse Analytics
Armazenamento do Azure
- Recuperação após desastre e ativação pós-falha de contas de armazenamento
- Práticas recomendadas para usar o Azure Data Lake Storage Gen2 – Alta disponibilidade e recuperação de desastres
- Redundância de Armazenamento do Azure
Instruções detalhadas
Para obter um passo a passo detalhado da solução e dos principais conceitos, assista à seguinte gravação de vídeo: DataDevOps para o Data Warehouse Moderno no Microsoft Azure