DataOps para armazenamento de dados moderno

Fábrica de dados do Azure
Azure Databricks
Azure DevOps
Azure Key Vault
Azure Synapse Analytics

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.

Architecture

O diagrama a seguir mostra a arquitetura geral da solução.

Diagrama de arquitetura demonstrando o DataOps para o data warehouse moderno.

Carrege um arquivo Visio desta arquitetura.

Fluxo de dados

Azure Data Factory orquestra e Azure Data Lake Storage Gen2 armazena os dados.

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. A API do serviço Web de estacionamento da cidade Contoso está disponível para transferir dados dos pontos de estacionamento.

  2. Há um trabalho de cópia do Data Factory que transfere os dados para o esquema Landing.

  3. Em seguida, Azure Databricks limpa e padroniza os dados. Ele processa os dados brutos para que os cientistas de dados possam utilizá-los.

  4. Se a validação revelar dados ruins, eles são despejados no esquema Malformado.

    Important

    As pessoas perguntaram por 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 você introduzir um bug nesta etapa, poderá corrigi-lo e re-executar o pipeline. Se você descartou os dados inválidos antes de adicioná-los ao Data Lake Storage, os dados corrompidos são inúteis porque você não pode executar novamente seu pipeline.

  5. Há uma segunda etapa de transformação Azure Databricks que converte os dados em um formato que você pode armazenar no data warehouse.

  6. Por fim, o pipeline fornece os dados de duas maneiras diferentes:

    1. O Databricks disponibiliza os dados para o cientista de dados para que eles possam treinar modelos.

    2. O Polybase move os dados do data lake para Azure Synapse Analytics e Power BI acessa os dados e os apresenta ao usuário de negócios.

Components

  • Azure Data Factory é um serviço de integração de dados baseado em nuvem que permite a movimentação e a orquestração de dados. Nessa arquitetura, ele inicia o pipeline copiando dados da API do serviço Web de estacionamento da cidade da Contoso para a zona de destino do data lake.

  • Azure Data Lake Storage Gen2 é um data lake escalonável e seguro baseado em Armazenamento de Blobs do Azure que dá suporte a pipelines de armazenamento em camadas e reproduzíveis. Nessa arquitetura, ele serve como o repositório central para dados brutos e processados em zonas de dados de aterrissagem, malformadas e validadas.

  • Azure Databricks é uma plataforma de análise baseada no Apache Spark projetada para big data e machine learning. Nessa arquitetura, ela executa duas etapas críticas de transformação. Primeiro, limpa e padroniza dados brutos ao filtrar registros malformados em um esquema separado. Em seguida, converte dados validados em um formato adequado para armazenamento de data warehouse e disponibiliza dados processados para cientistas de dados para treinamento de modelo.

  • Azure Key Vault é um serviço de nuvem seguro para gerenciar segredos, chaves e certificados. Nessa arquitetura, ela armazena configurações e credenciais confidenciais usadas em todo o pipeline, fornecendo gerenciamento de configuração centralizado e seguro.

  • Azure Synapse Analytics é um serviço de análise integrado que combina recursos de big data e data warehouse. Nessa arquitetura, ele serve como o data warehouse que ingere dados transformados de Data Lake Storage via PolyBase para consulta e relatórios.

  • Power BI é uma ferramenta de análise de negócios que fornece visualizações e dashboards interativos. Nessa arquitetura, ele se conecta a Azure Synapse Analytics para apresentar insights de dados de uso de estacionamento aos planejadores da cidade para tomada de decisões informadas.

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 de 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 integração contínua e entrega contínua (CI/CD).

    • 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.

  • 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 em Azure Synapse Analytics, Azure Analysis Services e 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.

  • Suporte ao monitoramento.

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 de cidades da Contoso podem então explorar e avaliar dados de relatório sobre o uso de estacionamento com ferramentas de visualização de dados, como Power BI, para determinar se precisam de mais recursos relacionados ou de estacionamento.

Disponibilidade de estacionamento na rua

Considerations

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 demonstradas por esta solução:

  • Use a camada de dados no data lake. Retenha dados de origem não modificados na zona de destino, roteie registros que falham na validação para a zona malformada e transforme os dados validados em um formato pronto para o warehouse. A retenção de dados de origem permite reprocessá-los sem retornar ao sistema de origem. Para o padrão análogo de bronze, prata e ouro lakehouse, consulte a arquitetura medalhão.

  • Torne seus pipelines de dados reproduzíveis e idempotentes. Etapas de transformação de design para que reexecucioná-las na mesma entrada produza o mesmo resultado. A reprodução de um pipeline permite corrigir um defeito na lógica de transformação e reprocessar dados históricos em vez de descartá-los.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

  • Proteger e centralizar a configuração. Armazene cadeias de conexão, chaves e outros segredos em Key Vault em vez de em notebooks, definições de pipeline ou controle do código-fonte. Faça referência a eles a partir de serviços vinculados do Data Factory e de Azure Databricks escopos secretos para que cada ambiente resolva seus próprios valores.

Excelência operacional

A excelência operacional abrange os processos de operações 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 no início do pipeline. Aplicar verificações de esquema e qualidade na primeira etapa de transformação e rotear registros que falham no esquema malformado. A validação antecipada mantém registros defeituosos fora das camadas downstream e fornece um registro do que foi rejeitado e por quê.

  • Verifique se o código de transformação de dados é testável. Lógica de transformação de fator em funções e módulos que são executados fora de um notebook para que você possa cobri-los com testes de unidade no pipeline de validação de solicitação de pull.

  • Tenha um pipeline de CI/CD. Compile e libere todos os ambientes do controle do código-fonte em vez de manualmente. Para a mecânica específica da tecnologia, consulte CI/CD em Azure Data Factory e CI/CD no Azure Databricks.

  • Monitore a infraestrutura, os pipelines e os dados. Colete métricas e logs de cada camada para que uma falha seja exibida como um alerta em vez de como um relatório obsoleto. Para obter mais informações, consulte Monitor Data Factory.

Implementar este cenário

A lista a seguir contém as etapas de alto nível necessárias para configurar essa solução com pipelines de build e lançamento correspondentes.

Configuração e implantação

  1. Configuração inicial: instale os pré-requisitos, crie o repositório Git que contém a infraestrutura, o notebook e o código do pipeline e defina as variáveis de ambiente necessárias.

  2. Implantar Azure recursos: use uma infraestrutura como implantação de código, como Bicep ou Terraform, para implantar os recursos Azure e Microsoft Entra entidades de serviço para cada ambiente. Configure separadamente as definições de Azure Pipelines, grupos de variáveis e conexões de serviço que invocam a implantação da infraestrutura.

  3. Configurar a integração do Git no dev Data Factory: configure a integração do Git para que o data factory de desenvolvimento se confirme com seu repositório.

  4. Executar uma compilação inicial e liberação: crie uma alteração de exemplo no Data Factory, como habilitar um gatilho de agendamento e observe a alteração ser implantada automaticamente nos ambientes.

CI/CD (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 release.

Diagrama que mostra o processo e a sequência de compilação e liberação.

Carrege um arquivo Visio desta arquitetura.

  1. 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>.

  2. 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, o linting e as compilações do DACPAC (pacote de aplicativos da camada de dados).

  3. 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.

  4. A conclusão de um pipeline de build bem-sucedido triggerá 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 do branch de colaboração (main). A publicação manual atualiza os modelos do Gerenciador de Recursos do Azure na ramificação adf_publish.

  5. A conclusão bem-sucedida do primeiro estágio dispara um portão de aprovação manual.

    Após aprovação, o pipeline de release continua com o segundo estágio, implantando alterações no ambiente de staging.

  6. Realizar testes de integração para testar as alterações no ambiente de stage.

  7. Após a conclusão bem-sucedida do segundo estágio, o pipeline aciona uma segunda barreira de aprovação manual.

    Após a 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 sobre como implementar esses estágios, consulte CI/CD no Azure Data Factory.

Testing

A solução inclui suporte para teste de unidade e teste de integração. Os testes de unidade abrangem os módulos de transformação Python e os testes de integração disparam um pipeline do Data Factory e verificam sua saída como parte da versão para o ambiente de preparo. Para obter mais informações, consulte Teste de unidade para notebooks.

Observabilidade e monitoramento

A solução dá suporte à observabilidade e ao monitoramento para Databricks e Data Factory. Para o Databricks, use o log de auditoria interno da plataforma (a tabela) e o system.access.audit monitoramento de execução de trabalho em vez de exportar todos os diagnósticos por padrão. Se você precisar fornecer logs de diagnóstico do Databricks para um workspace Log Analytics para alertas centralizados, essa funcionalidade exigirá o plano Premium, aplicará a logs em vez de métricas e precisará de um controle de acesso cuidadoso, pois os logs de auditoria podem conter detalhes confidenciais sobre sua implantação. Para o Data Factory, rote logs de diagnóstico e métricas para um workspace Log Analytics e configure alertas sobre falhas de pipeline e latência de trabalho. Para obter mais informações, consulte Monitor Data Factory.

Próximas etapas

Os recursos a seguir ajudam você a implementar as práticas de DataOps descritas neste artigo.

Integração e entrega contínuas

Observability/monitoring

Azure Databricks

Data Factory

Azure Synapse Analytics

Armazenamento do Azure

Resiliência e recuperação de desastre

Azure Databricks

Data Factory

Azure Synapse Analytics

Armazenamento do Azure

Visão geral detalhada

Para obter uma visão geral detalhada da solução e dos principais conceitos, assista à seguinte gravação de vídeo: DataDevOps para a Data Warehouse Moderna no Microsoft Azure