Editar

Compartilhar via

Business Intelligence empresarial

Power BI
Azure Synapse Analytics
Fábrica de dados do Azure
Microsoft Entra ID
Armazenamento do Blobs do Azure

Este cenário de exemplo mostra como os dados podem ser ingeridos em um ambiente de nuvem de um data warehouse local e, em seguida, fornecidos usando um modelo de BI (business intelligence). Essa abordagem pode ser uma meta final ou um primeiro passo para a modernização completa com componentes baseados em nuvem.

As etapas a seguir baseiam-se no cenário de ponta a ponta do Azure Synapse Analytics. Ele usa o Azure Pipelines para ingerir dados de um banco de dados SQL em pools de SQL do Azure Synapse e transforma-os para análise.

Arquitetura

Diagrama da arquitetura de BI corporativo com o Azure Synapse.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Fonte de dados

  • Os dados de origem estão localizados em um banco de dados do SQL Server no Azure. Para simular o ambiente local, os scripts de implantação para esse cenário provisionam um banco de dados SQL do Azure. O banco de dados de exemplo AdventureWorks é usado como o esquema de dados de origem e de dados de exemplo. Para obter informações sobre como copiar dados de um banco de dados local, consulte Copiar e transformar dados de e para o SQL Server.

Ingestão e armazenamento de dados

  1. O Azure Data Lake Gen2 é usado como uma área de preparo temporária durante a ingestão de dados. Em seguida, você pode usar o PolyBase para copiar dados para um pool de SQL dedicado do Azure Synapse.

  2. O Azure Synapse Analytics é um sistema distribuído que realiza análises em grandes quantidades de dados. Ele dá suporte a MPP (processamento altamente paralelo), que o torna adequado para executar análise de alto desempenho. O pool de SQL dedicado do Azure Synapse é um destino para ingestão contínua do local. Ele pode ser usado para processamento adicional, bem como para fornecer os dados para o Power BI por meio do DirectQuery.

  3. O Azure Pipelines é usado para orquestrar a ingestão e a transformação de dados em seu workspace do Azure Synapse.

Análise e relatórios

Componentes

Este cenário usa os seguintes componentes:

Arquitetura simplificada

Diagrama da arquitetura simplificada de BI corporativo.

Detalhes do cenário

Uma organização tem um grande data warehouse local armazenado em um banco de dados SQL. Ela deseja usar o Azure Synapse para executar a análise e, em seguida, fornecer esses insights usando o Power BI.

Autenticação

O Microsoft Entra autentica usuários que se conectam a painéis e aplicativos do Power BI. O logon único é usado para conexão à fonte de dados no pool provisionado do Azure Synapse. A autorização ocorre na origem.

Carregamento incremental

Quando um processo automatizado de ETL (extração-transformação-carga) ou de ELT (extração-carga-transformação) é executado, é mais eficiente carregar apenas os dados que foram alterados desde a execução anterior. Isso é chamado de carga incremental, em vez de uma carga completa que carrega todos os dados. Para executar um carregamento incremental, você precisa de uma maneira de identificar quais dados foram alterados. A abordagem mais comum é usar um valor de marca d’água alta, que rastreia o valor mais recente de uma coluna na tabela de origem, que pode ser uma coluna de data e hora ou uma coluna de inteiro exclusivo.

A partir do SQL Server 2016, é possível usar tabelas temporais, que são tabelas com versão do sistema que mantêm um histórico completo de alterações de dados. O mecanismo de banco de dados registra automaticamente o histórico de todas as alterações em uma tabela de histórico separada. Você pode consultar os dados históricos adicionando uma cláusula FOR SYSTEM_TIME a uma consulta. Internamente, o mecanismo de banco de dados consulta a tabela do histórico, mas isso é transparente ao aplicativo.

Observação

Para versões anteriores do SQL Server, você pode usar a CDC (captura de dados de alterações). Essa abordagem é menos conveniente do que as tabelas temporais porque você tem de consultar uma tabela separada, e as alterações são controladas por um número de sequência de log em vez de um carimbo de data/hora.

Tabelas temporais são úteis para dados de dimensão, os quais podem ser alterados ao longo do tempo. Tabelas de fatos geralmente representam uma transação imutável, como uma venda, caso em que não faz sentido manter o histórico de versão do sistema. Em vez disso, as transações normalmente contam com uma coluna que representa a data da transação, que pode ser usada como o valor de marca d'água. Por exemplo, no Data Warehouse AdventureWorks, as tabelas SalesLT.* têm um campo LastModified.

Este é o fluxo geral para o pipeline ELT:

  1. Para cada tabela no banco de dados de origem, acompanhe o tempo de corte quando o último trabalho ELT foi executado. Armazene essas informações no data warehouse. Durante a configuração inicial, todas as horas são definidas como 1-1-1900.

  2. Durante a etapa de exportação de dados, a hora de corte é passada como um parâmetro para um conjunto de procedimentos armazenados no banco de dados de origem. Esses procedimentos armazenados consultam todos os registros que foram alterados ou criados após a hora de corte. Para todas as tabelas no exemplo, você pode usar a coluna ModifiedDate.

  3. Quando a migração de dados for concluída, atualize a tabela que armazena os tempos de corte.

Pipeline de dados

Esse cenário usa o banco de dados de exemplo AdventureWorks como fonte de dados. O padrão de carga de dados incrementais é implementado para garantir que apenas os dados que foram modificados ou adicionados após a execução mais recente do pipeline sejam carregados.

Ferramenta de cópia orientada por metadados

A Ferramenta interna de cópia baseada em metadados no Azure Pipelines carrega incrementalmente todas as tabelas contidas em nosso banco de dados relacional. Navegando pela experiência baseada em assistente, você pode conectar a ferramenta Copiar Dados ao banco de dados de origem e configurar o carregamento incremental ou completo para cada tabela. A ferramenta Copiar Dados cria os pipelines e os scripts SQL para gerar a tabela de controle necessária para armazenar dados para o processo de carregamento incremental, por exemplo, o valor/coluna de marca d'água alta para cada tabela. Depois que esses scripts forem executados, o pipeline estará pronto para carregar todas as tabelas no data warehouse de origem no pool dedicado do Synapse.

Captura de tela da ferramenta de dados de cópia baseada em metadados no Azure Synapse Analytics.

A ferramenta cria três pipelines para iterar em todas as tabelas do banco de dados, antes de carregar os dados.

Os pipelines gerados por essa ferramenta:

  • Contam o número de objetos, como tabelas, a serem copiados na execução do pipeline.
  • Iteram em cada objeto a ser carregado/copiado e, em seguida:
    • Verificam se uma carga delta é necessária; caso contrário, concluem uma carga completa normal.
    • Recuperam o valor de marca d'água alta da tabela de controle.
    • Copiam dados das tabelas de origem para a conta de preparo no Data Lake Storage Gen2.
    • Carregam dados no pool de SQL dedicado por meio do método de cópia selecionado, por exemplo, o comando PolyBase, Copy.
    • Atualizam o valor de marca d'água alta na tabela de controle.

Carregam dados no pool de SQL do Azure Synapse

A atividade de cópia copia dados do banco de dados SQL para o pool de SQL do Azure Synapse. Nesse exemplo, como nosso banco de dados SQL está no Azure, usamos o runtime de integração do Azure para ler dados do banco de dados SQL e gravá-los no ambiente de preparo especificado.

A instrução copy é usada para carregar dados do ambiente de preparo no pool dedicado do Synapse.

Utilizar o Azure Pipelines

Os pipelines no Azure Synapse são usados para definir o conjunto ordenado de atividades para concluir o padrão de carga incremental. Os gatilhos são usados para iniciar o pipeline, que pode ser disparado manualmente ou em um momento especificado.

Transformar os dados

Como o banco de dados de exemplo em nossa arquitetura de referência não é grande, criamos tabelas replicadas sem partições. Para cargas de trabalho de produção, o uso de tabelas distribuídas provavelmente melhorará o desempenho da consulta. Para mais informações, consulte Diretrizes de design para tabelas distribuídas no Azure Synapse. Os scripts de exemplo executam as consultas usando uma classe de recurso estática.

Em um ambiente de produção, considere a criação de tabelas de preparo com distribuição round-robin. Em seguida, transforme e mova os dados para tabelas de produção com índices columnstore clusterizados, que oferecem o melhor desempenho geral de consulta. Os índices ColumnStore são otimizados para consultas que examinam muitos registros. Os índices columnstore não tem o mesmo desempenho em pesquisas singleton, isto é, pesquisa de uma única linha. Se você precisar realizar pesquisas singleton frequentes, adicione um índice não clusterizado a uma tabela. As pesquisas singleton podem ser executadas com muito mais rapidez usando um índice não clusterizado. No entanto, as pesquisas singleton são geralmente menos comuns em cenários de data warehouse do que as cargas de trabalho OLTP. Para obter mais informações, confira Indexando tabelas no Azure Synapse.

Observação

As tabelas columnstore clusterizadas não dão suporte aos tipos de dados varchar(max), nvarchar(max) e varbinary(max). Nesse caso, considere a possibilidade de usar um heap ou índice clusterizado. Você pode colocar essas colunas em uma tabela separada.

Usar o Power BI Premium para acessar, modelar e visualizar dados

O Power BI Premium dá suporte a várias opções para se conectar a fontes de dados no Azure, em particular o pool provisionado do Azure Synapse:

  • Importar: os dados são importados para o modelo do Power BI.
  • DirectQuery: os dados são extraídos diretamente do armazenamento relacional.
  • Modelo composto: combine a importação para algumas tabelas e o DirectQuery para outras.

Esse cenário é fornecido com o painel do DirectQuery porque a quantidade de dados usados e a complexidade do modelo não são altas, portanto, é possível oferecer uma boa experiência do usuário. O DirectQuery delega a consulta para o mecanismo avançado de computação por baixo e utiliza amplas funcionalidades de segurança na origem. Além disso, o uso do DirectQuery garante que os resultados sejam sempre consistentes com os dados de origem mais recentes.

O modo de importação fornece o tempo de resposta de consulta mais rápido e deve ser considerado quando o modelo cabe inteiramente na memória do Power BI, a latência de dados entre as atualizações pode ser tolerada e pode haver algumas transformações complexas entre o sistema de origem e o modelo final. Nesse caso, os usuários finais querem acesso total aos dados mais recentes, sem atrasos na atualização do Power BI, e todos os dados históricos, que são maiores do que o que um conjunto de dados do Power BI pode lidar, entre 25 e 400 GB, dependendo do tamanho da capacidade. Como o modelo de dados no pool de SQL dedicado já está em um esquema em estrela e não precisa de transformação, o DirectQuery é uma opção apropriada.

Captura de tela do painel do Power BI.

O Power BI Premium Gen2 oferece a capacidade de trabalhar com modelos grandes, relatórios paginados, pipelines de implantação e ponto de extremidade interno do Analysis Services. Você também pode ter capacidade dedicada com uma proposta de valor exclusiva.

Quando o modelo de BI ou a complexidade do painel aumenta, é possível alternar para modelos compostos e começar a importar partes de tabelas de pesquisa, por meio de tabelas híbridas e alguns dados pré-agregados. Habilitar o cache de consultas no Power BI para conjuntos de dados importados é uma opção, além de utilizar tabelas duplas para a propriedade de modo de armazenamento.

Dentro do modelo composto, os conjuntos de dados atuam como uma camada de passagem virtual. Quando o usuário interage com visualizações, o Power BI gera consultas SQL para pools de SQL do Synapse com armazenamento duplo: na memória ou na consulta direta, dependendo de qual delas for mais eficiente. O mecanismo decide quando alternar da memória para a consulta direta e envia a lógica por push para o pool de SQL do Synapse. Dependendo do contexto das tabelas de consulta, elas podem atuar como modelos compostos armazenados em cache (importados) ou não em cache. Escolha qual tabela armazenar em cache na memória, combine dados de uma ou mais fontes do DirectQuery e/ou combine dados de uma combinação de fontes do DirectQuery e dados importados.

Recomendações: ao usar o DirectQuery no pool provisionado do Azure Synapse Analytics:

  • Use o cache do conjunto de resultados do Azure Synapse para armazenar em cache os resultados da consulta no banco de dados de usuário para uso repetitivo, melhorar o desempenho da consulta até milissegundos e reduzir o uso de recursos de computação. As consultas que usam conjuntos de resultados armazenados em cache não utilizam nenhum slot de simultaneidade no Azure Synapse Analytics e, portanto, não contam nos limites de simultaneidade existentes.
  • Use exibições materializadas do Azure Synapse para pré-computar, armazenar e manter dados, da mesma forma que uma tabela. As consultas que usam todos ou um subconjunto dos dados em exibições materializadas podem obter um desempenho mais rápido e não precisam fazer uma referência direta à exibição materializada definida para usá-los.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Títulos frequentes de violações de dados, infecções de malware e injeção de código mal-intencionado estão entre uma ampla lista de preocupações de segurança para empresas que buscam a modernização de nuvem. Os clientes corporativos necessitam de um provedor de nuvem ou uma solução de serviço que possa resolver essas questões, pois eles não podem se dar ao luxo de errar.

Esse cenário aborda as preocupações de segurança mais exigentes usando uma combinação de controles de segurança em camadas: rede, identidade, privacidade e autorização. A maior parte dos dados é armazenada no pool provisionado do Azure Synapse, com o Power BI usando o DirectQuery por meio de logon único. Você pode usar o Microsoft Entra ID para autenticação. Há também amplos controles de segurança para autorização de dados de pools provisionados.

Algumas perguntas comuns de segurança incluem:

  • Como posso controlar quem pode ver quais dados?
    • As organizações precisam proteger os dados para estarem em conformidade com as diretrizes federais, locais e da empresa a fim de mitigar os riscos de violação de dados. O Azure Synapse oferece vários recursos de proteção de dados para alcançar a conformidade.
  • Quais são as opções para verificar a identidade de um usuário?
  • Qual tecnologia de segurança de rede posso usar para proteger a integridade, a confidencialidade e o acesso de minhas redes e dados?
    • Para proteger o Azure Synapse, há uma variedade de opções de segurança de rede a serem consideradas.
  • Quais são as ferramentas que detectam e me notificam de ameaças?
    • O Azure Synapse fornece muitos recursos de detecção de ameaças, como: auditoria de SQL, detecção de ameaças SQL e avaliação de vulnerabilidades para auditar, proteger e monitorar bancos de dados.
  • O que posso fazer para proteger os dados na minha conta de armazenamento?
    • As contas de Armazenamento do Microsoft Azure são ideais para cargas de trabalho que exigem tempos de resposta curtos e consistentes ou que têm alto número de operações de IOP (entrada e saída) por segundo. As contas de armazenamento contêm todos os objetos de dados do Armazenamento do Microsoft Azure e têm muitas opções de segurança da conta de armazenamento.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Esta seção fornece informações sobre preços para diferentes serviços envolvidos nessa solução e menciona as decisões tomadas para esse cenário com um conjunto de dados de exemplo.

Azure Synapse

A arquitetura sem servidor do Azure Synapse Analytics permite escalar seus níveis de computação e armazenamento de maneira independente. Os recursos de computação são cobrados com base no uso, e você pode escalar ou pausar esses recursos sob demanda. Os recursos de armazenamento são cobrados por terabyte, assim seus custos aumentam à medida que você insere mais dados.

Azure Pipelines

Os detalhes de preços dos pipelines no Azure Synapse podem ser encontrados na guia Integração de Dados na página de preços do Azure Synapse. Há três componentes principais que influenciam o preço de um pipeline:

  1. Atividades do pipeline de dados e horas de runtime de integração
  2. Execução e tamanho do cluster de fluxos de dados
  3. Encargos de operação

O preço varia dependendo dos componentes ou atividades, frequência e número de unidades de runtime de integração.

Para o conjunto de dados de exemplo, o runtime de integração hospedado no Azure padrão, a atividade de cópia de dados para o núcleo do pipeline, é disparado em um agendamento diário para todas as entidades (tabelas) no banco de dados de origem. O cenário não contém fluxos de dados. Não há custos operacionais, pois há menos de 1 milhão de operações com pipelines por mês.

Pool dedicado e armazenamento do Azure Synapse

Os detalhes de preços do pool dedicado do Azure Synapse podem ser encontrados na guia Data Warehousing na página de preços do Azure Synapse. No modelo de consumo Dedicado, os clientes são cobrados por Unidades de Data Warehouse (DWU) provisionadas, por hora de tempo de atividade. Outro fator de contribuição é o custo de armazenamento de dados: tamanho dos dados inativos + instantâneos + redundância geográfica, se houver.

Para o conjunto de dados de exemplo, você pode provisionar 500DWU, o que garante uma boa experiência para a carga analítica. É possível manter a computação em funcionamento durante o horário comercial de relatórios. Se levado para produção, a capacidade reservada do data warehouse é uma opção atraente para gerenciamento de custos. Técnicas diferentes devem ser usadas para maximizar as métricas de custo/desempenho, abordadas nas seções anteriores.

Armazenamento de Blobs

Considere usar o recurso de capacidade reservada do Armazenamento do Microsoft Azure para reduzir o custo de armazenamento. Com esse modelo, você receberá um desconto se reservar uma capacidade de armazenamento fixa por um ou três anos. Para obter mais informações, confira Otimizar custos do Armazenamento de Blobs com capacidade reservada.

Não há armazenamento persistente nesse cenário.

Power BI Premium

Os detalhes dos preços do Power BI Premium podem ser encontrados na página de preços do Power BI.

Esse cenário usa workspaces do Power BI Premium com uma variedade de aprimoramentos de desempenho internos para acomodar necessidades analíticas exigentes.

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, confira Visão geral do pilar de excelência operacional.

Recomendações de DevOps

  • Crie grupos de recursos separados para ambientes de produção, desenvolvimento e teste. Ter grupos de recursos separados facilita o gerenciamento de implantações, a exclusão de implantações de teste a atribuição de direitos de acesso.

  • Coloque cada carga de trabalho em um modelo de implantação separado e armazene os recursos em sistemas de controle do código-fonte. Você pode implantar os modelos em conjunto ou individualmente como parte de um processo de CI (integração contínua) e CD (implantação contínua), facilitando o processo de automação. Nessa arquitetura, há quatro cargas de trabalho principais:

    • O servidor de data warehouse e os recursos relacionados
    • Pipelines do Azure Synapse
    • Ativos do Power BI: painéis, aplicativos, conjuntos de dados
    • Um cenário simulado do local para a nuvem

    Busque ter um modelo de implantação separado para cada uma das cargas de trabalho.

  • Considere preparar suas cargas de trabalho, quando for prático. Implante em várias fases e execute verificações de validação em cada uma antes de passar para a próxima. Desse modo, é possível efetuar push de atualizações para ambientes de produção de maneira controlada, além de minimizar problemas de implantação inesperados. Use as estratégias de implantação azul-verde e de versão canário para atualizar ambientes de produção dinâmicos.

  • Tenha uma boa estratégia de reversão para lidar com implantações com falha. Por exemplo, é possível reimplantar automaticamente uma implantação anterior bem-sucedida com base em seu histórico de implantações. Consulte o sinalizador --rollback-on-error na CLI do Azure.

  • O Azure Monitor é a opção recomendada para analisar o desempenho do data warehouse e de toda a plataforma de análise do Azure para uma experiência de monitoramento integrada. O Azure Synapse Analytics oferece uma experiência de monitoramento no portal do Azure para mostrar insights sobre a carga de trabalho do data warehouse. O portal do Azure é a ferramenta recomendada ao monitorar seu data warehouse, pois ele fornece períodos de retenção configuráveis, alertas, recomendações e gráficos e painéis personalizáveis para métricas e logs.

Início Rápido

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

Esta seção fornece detalhes sobre as decisões de dimensionamento para acomodar esse conjunto de dados.

Pool provisionado do Azure Synapse

Há uma variedade de configurações de data warehouse para escolher.

Unidades de data warehouse No. de nós de computação No. de distribuições por nó
DW100c 1 60
-- TO --
DW30000c 60 1

Para ver os benefícios de desempenho da escala horizontal, especialmente para unidades de data warehouse grandes, use pelo menos um conjunto de dados de 1 TB. Para encontrar o melhor número de unidades de data warehouse para seu pool de SQL dedicado, tente escalar de forma vertical e horizontal. Execute algumas consultas com diferentes números de unidades de data warehouse após o carregamento dos dados. Como o dimensionamento é rápido, você pode experimentar vários níveis de desempenho diferentes durante uma hora ou menos.

Encontrar o melhor número de unidades de data warehouse

Para um pool de SQL dedicado em desenvolvimento, comece selecionando um número menor de unidades de data warehouse. Um bom ponto de partida é DW400c ou DW200c. Monitore o desempenho do aplicativo, observando o número de unidades de data warehouse selecionadas em comparação com o desempenho observado. Suponha uma escala linear e determine quanto é necessário para aumentar ou diminuir as unidades do data warehouse. Continue fazendo ajustes até alcançar um nível de desempenho ideal para seus requisitos de negócios.

Escala do pool de SQL do Synapse

Azure Pipelines

Para recursos de escalabilidade e otimização de desempenho de pipelines no Azure Synapse e a atividade de cópia usada, consulte o Guia de desempenho e escalabilidade da atividade Copy.

Power BI Premium

Este artigo usa o Power BI Premium Gen 2 para demonstrar os recursos de BI. Atualmente, os SKUs de capacidade do Power BI Premium variam de P1 (oito núcleos virtuais) a P5 (128 núcleos virtuais). A melhor maneira de selecionar a capacidade necessária é passar por uma avaliação de carregamento de capacidade, instalar o aplicativo de métricas Gen 2 para monitoramento contínuo e considerar o uso do Dimensionamento automático com o Power BI Premium.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas