Este artigo descreve como um escritório de planejamento urbano fictícia pode usar essa solução. A solução fornece um pipeline de dados de ponta a ponta que segue o padrão de arquitetura do MDW, juntamente com os processos de DevOps e DataOps correspondentes, para avaliar o uso do estacionamento e tomar decisões de negócios mais fundamentadas.
Arquitetura
O diagrama a seguir mostra a arquitetura geral da solução.
Baixe um Arquivo Visio dessa arquitetura.
Fluxo de dados
O Azure Data Factory (ADF) e o Azure Data Lake Storage (ADLS) Gen2 armazena os dados:
A API do serviço Web de estacionamento da cidade Contoso está disponível para transferir dados dos pontos de estacionamento.
Há um trabalho de cópia do ADF que transfere os dados para o esquema Destino.
Em seguida, o Azure Databricks limpa e padroniza os dados. Ele usa os dados brutos e as condições para que os cientistas de dados possam usá-los.
Se a validação revelar dados ruins, eles são despejados no esquema Malformado.
Importante
As pessoas perguntavam por que os dados não são validados antes de serem armazenados no ADLS. 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 o pipeline. Se você despejou os dados ruins antes de adicioná-los ao ADLS, os dados corrompidos serão inúteis porque você não poderá repetir 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.
Por fim, o pipeline fornece os dados de duas maneiras diferentes:
O Databricks disponibiliza os dados para o cientista de dados para que eles possam 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 de negócios.
Componentes
A solução usa estes componentes:
Detalhes do cenário
Um MDW (data warehouse) moderno permite 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 insights para um MDW por meio de painéis analíticos, relatórios operacionais ou análises avançadas para todos os usuários.
Configurar um ambiente de MDW para ambientes de desenvolvimento e produção é complexo. A automatização do processo é fundamental. Ela ajuda a aumentar a produtividade, minimizando o risco de erros.
Este artigo descreve como um escritório de planejamento urbano fictícia pode usar essa solução. A solução fornece um pipeline de dados de ponta a ponta que segue o padrão de arquitetura do MDW, juntamente com os processos de DevOps e DataOps correspondentes, para avaliar o uso do estacionamento e tomar decisões de negócios mais fundamentadas.
Requisitos da solução
Capacidade de coletar dados de diferentes fontes ou sistemas.
Infraestrutura como código: implante novos ambientes de desenvolvimento e preparação de maneira automatizada.
Implante as alterações de aplicativo em diferentes ambientes de maneira automatizada:
Implemente pipelines de CI/CD (integração contínua/entrega contínua).
Use portões de implantação para aprovações manuais.
Pipeline como código: verifique se as definições de pipeline de CI/CD estão no controle do código-fonte.
Realize testes de integração nas alterações usando um conjunto de dados de exemplo.
Execute pipelines de forma agendada.
Dê suporte ao desenvolvimento ágil futuro, incluindo a adição de cargas de trabalho de ciência de dados.
Dê suporte para segurança em nível de registro 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, no Azure Analysis Services (AAS) e no Power BI.
Dê suporte para 10 usuários de painel simultâneos 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.
Dê suporte ao monitoramento.
Configuração centralizada em um armazenamento seguro como o Azure Key Vault.
Possíveis casos de uso
Este artigo usa a cidade fictícia 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 coletam dados dos sensores. Eles precisam de uma plataforma que coletará dados de várias fontes diferentes. Em seguida, os dados devem ser validados, limpos e transformados em um esquema conhecido. Os planejadores urbanos da Contoso podem explorar e avaliar dados de relatório sobre o uso do estacionamento com ferramentas de visualização de dados, como o Power BI, para determinar se eles precisam de mais estacionamento ou recursos relacionados.
Considerações
A lista a seguir resume os principais aprendizados e práticas recomendadas demonstrados por essa solução:
Observação
Cada item na lista abaixo é vinculado à seção de Principais aprendizados relacionados no documento para o exemplo de solução de sensor de estacionamento no GitHub.
Implantar 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 a build e o pipeline de lançamento correspondentes. Você pode encontrar as etapas de instalação detalhadas e os pré-requisitos neste repositório de Exemplos do Azure.
Configuração e implantação
Configuração inicial: instale todos os pré-requisitos, importe os repositórios do GitHub de Exemplos do Azure para seu próprio repositório e de defina as variáveis de ambiente necessárias.
Implantar recursos do Azure: a solução vem com um script de implantação automatizado. Ela implanta todos os recursos do Azure e entidades de serviço do Microsoft Entra necessários por ambiente. O script também implanta Azure Pipelines, grupos de variáveis e conexões de serviço.
Configurar a integração do git no Data Factory de desenvolvimento: configure a integração do git para trabalhar com o repositório importado do GitHub.
Executar uma build inicial e lançamento: 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 nos ambientes.
Recursos Implantados
Se a implantação for bem-sucedida, deverá haver três grupos de recursos no Azure representando três ambientes: desenvolvimento, preparação e produção. Também deve haver pipelines de build e lançamento de ponta a ponta no Azure DevOps que podem implantar automaticamente as alterações nesses três ambientes.
Para ver uma lista detalhada de todos os recursos, confira a seção Recursos Implantados do LEIAME da Demonstração do Sensor de Estacionamento – DataOps.
Integração contínua e entrega contínua
O diagrama a seguir demonstra o processo de CI/CD e a sequência para os pipelines de build e lançamento.
Baixe um Arquivo Visio dessa arquitetura.
Os desenvolvedores desenvolvem em seus próprios ambientes de área restrita dentro do grupo de recursos de desenvolvimento e fazem commit das alterações em seus próprios branches de curta duração do git. Por exemplo,
<developer_name>/<branch_name>.Quando as alterações são concluídas, os desenvolvedores fazem uma solicitação de pull (PR) ao branch principal para revisão. Isso inicia automaticamente o pipeline de validação de PR, que executa os testes de unidade, lint e builds do DACPAC (pacote de aplicativos da camada de dados).
Após a conclusão da validação da PR, o commit para o principal disparará um pipeline de build que publica todos os artefatos de compilação necessários.
A conclusão de um pipeline de build bem-sucedido disparará o primeiro estágio do pipeline de lançamento. Isso implanta os artefatos de compilação de publicação no ambiente de desenvolvimento, exceto para o ADF.
Os desenvolvedores publicam manualmente no desenvolvimento do ADF a partir do branch de colaboração (principal). A publicação manual atualiza os modelos do Azure Resource Manager (ARM) no branch
adf_publish.A conclusão bem-sucedida do primeiro estágio dispara um portão de aprovação manual.
Em Aprovação, o pipeline de lançamento continua com o segundo estágio, implantando alterações no ambiente de preparação.
Execute testes de integração para testar as alterações no ambiente de preparação.
Após a conclusão bem-sucedida do segundo estágio, o pipeline dispara um segundo portão de aprovação manual.
Em Aprovação, o pipeline de lançamento continua com o terceiro estágio, implantando alterações no ambiente de produção.
Para obter mais informações, leia a seção Pipeline de build e lançamento do LEIAME.
Testando
A solução inclui suporte para teste de unidade e teste de integração. Ele usa o pytest-adf e a estrutura de testes Nutter. Para obter mais informações, consulte a seção Teste do LEIAME.
Observabilidade e monitoramento
A solução dá suporte à observabilidade e ao monitoramento para Databricks e Data Factory. Para obter mais informações, consulte a seção Observabilidade/monitoramento do LEIAME.
Próximas etapas
Se você quiser implantar a solução, siga as etapas na seção Como usar a amostra do LEIAME da Demonstração do sensor de estacionamento – DataOps.
Exemplos de código da solução no GitHub
Observabilidade/monitoramento
Azure Databricks
- Como monitorar o Azure Databricks com o Azure Monitor
- Monitorar trabalhos do Azure Databricks com o Application Insights
Data Factory
- Monitorar o Azure Data Factory com o Azure Monitor
- Criar alertas para monitorar proativamente os pipelines do data factory
Synapse Analytics
- Monitorando a atividade de consulta e a utilização de recursos no Azure Synapse Analytics
- Monitorar a carga de trabalho do pool de SQL do Azure Synapse Analytics usando DMVs
Armazenamento do Azure
Resiliência e recuperação de desastre
Azure Databricks
Data Factory
Synapse Analytics
Armazenamento do Azure
- Recuperação de desastres e failover da conta de armazenamento
- Práticas recomendadas para o uso do Azure Data Lake Storage Gen2 – alta disponibilidade e recuperação de desastre
- Redundância do Armazenamento do Azure
Passo a passo detalhado
Para obter um passo a passo detalhado da solução e dos conceitos principais, assista ao vídeo a seguir: DataDevOps para data warehouse moderno no Microsoft Azure