Editar

Business intelligence empresarial

Power BI
Synapse Analytics
Data Factory
Azure Active Directory
Armazenamento de Blobs

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, servidos 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 Azure Synapse e transforma os dados para análise.

Arquitetura

Diagrama da arquitetura de BI empresarial com Azure Synapse.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho

Fonte de dados

  • Os dados de origem estão localizados em um banco de dados 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 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 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 em um pool de SQL dedicado Azure Synapse.

  2. Azure Synapse Analytics é um sistema distribuído projetado para executar a análise em dados grandes. Ele dá suporte a MPP (processamento altamente paralelo), que o torna adequado para executar análise de alto desempenho. Azure Synapse pool de SQL dedicado é um destino para ingestão contínua do local. Ele pode ser usado para processamento adicional, além de servir 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 Azure Synapse.

Análise e relatórios

Componentes

Este cenário usa os seguintes componentes:

Arquitetura simplificada

Diagrama da arquitetura simplificada de BI empresarial.

Detalhes do cenário

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

Autenticação

Azure AD autentica os usuários que se conectam a dashboards e aplicativos do Power BI. O logon único é usado para se conectar à fonte de dados em Azure Synapse pool provisionado. A autorização ocorre na origem.

Carregamento incremental

Quando você executa um ETL (extração-transformação-carga) automatizado ou um processo ELT (extração-transformação de carga), é mais eficiente carregar apenas os dados que foram alterados desde a execução anterior. Ele é 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 de água alto , que rastreia o valor mais recente de alguma coluna na tabela de origem, uma coluna datetime ou uma coluna inteiro exclusiva.

A partir do SQL Server 2016, você pode 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 FOR SYSTEM_TIME cláusula a uma consulta. Internamente, o mecanismo de banco de dados consulta a tabela de histórico, mas é transparente para o aplicativo.

Observação

Para versões anteriores do SQL Server, você pode usar a CDC (captura de dados de alteração). 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 SalesLT.* tabelas têm um LastModified campo.

Aqui está 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. Na 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 o tempo de corte. Para todas as tabelas no exemplo, você pode usar a ModifiedDate coluna.

  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 uma fonte de dados. O padrão de carga de dados incremental é implementado para garantir que carreguemos apenas os dados que foram modificados ou adicionados após a execução mais recente do pipeline.

Ferramenta de cópia controlada por metadados

A ferramenta de cópia integrada controlada por 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 scripts SQL para gerar a tabela de controle necessária para armazenar dados para o processo de carregamento incremental, por exemplo, o alto valor/coluna de marca d'água 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 controlada por metadados no 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 esta ferramenta:

  • Conte o número de objetos, como tabelas, a serem copiados na execução do pipeline.
  • Iterar em cada objeto a ser carregado/copiado e, em seguida:
    • Verifique se uma carga delta é necessária; caso contrário, conclua uma carga completa normal.
    • Recupere o valor alto da marca d'água da tabela de controle.
    • Copie dados das tabelas de origem para a conta de preparo no ADLS Gen2.
    • Carregue dados no pool de SQL dedicado por meio do método de cópia selecionado, por exemplo, o comando Polybase, Copy.
    • Atualize o valor alto da marca d'água na tabela de controle.

Carregar dados em Azure Synapse pool de SQL

A atividade de cópia copia dados do banco de dados SQL para o pool de SQL Azure Synapse. Neste 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 gravar os dados no ambiente de preparo especificado.

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

Utilizar o Azure Pipelines

Os pipelines em 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. Confira Diretrizes de design para tabelas distribuídas no Azure Synapse. Os scripts de exemplo executam as consultas usando uma classe de recurso estático.

Em um ambiente de produção, considere criar 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 da consulta. Os índices ColumnStore são otimizados para consultas que examinam muitos registros. Os índices Columnstore não têm um bom desempenho para pesquisas singleton, ou seja, pesquisando 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 muito mais rapidamente 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

Não há suporte varchar(max)nvarchar(max)para tabelas columnstore clusterizados ou varbinary(max) tipos de dados. Nesse caso, considere a possibilidade de usar um heap ou índice clusterizado. Você pode colocar essas colunas em uma tabela separada.

Usar Power BI Premium para acessar, modelar e visualizar dados

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

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

Esse cenário é entregue com o painel do DirectQuery porque a quantidade de dados usados e a complexidade do modelo não são altas, portanto, podemos oferecer uma boa experiência do usuário. O DirectQuery delega a consulta ao poderoso mecanismo de computação abaixo e utiliza recursos de segurança abrangentes 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 se encaixa 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 desejam 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 de estrela e não precisa de transformação, o DirectQuery é uma escolha apropriada.

Captura de tela do painel no Power BI.

Power BI Premium Gen2 oferece a capacidade de lidar 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 proposta de valor exclusivo.

Quando o modelo de BI aumenta ou a complexidade do painel aumenta, você pode 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 consulta no Power BI para conjuntos de dados importados é uma opção, além de utilizar tabelas duplas para a propriedade do 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 é 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 armazenados em cache. Escolha qual tabela armazenar em cache na memória, combinar dados de uma ou mais fontes do DirectQuery e/ou combinar 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 Azure Synapse cache de conjunto de resultados para armazenar em cache os resultados da consulta no banco de dados do 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 usam nenhum slot de simultaneidade no Azure Synapse Analytics e, portanto, não contam com os limites de simultaneidade existentes.
  • Use Azure Synapse exibições materializadas para pré-computar, armazenar e manter dados como 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

Essas 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 valiosos dados e sistemas. Para obter mais informações, consulte 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 precisam de um provedor de nuvem ou uma solução de serviço que possa resolver suas preocupaçõ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 em Azure Synapse pool provisionado, com o Power BI usando o DirectQuery por meio do logon único. Você pode usar Azure AD 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. 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 Azure Synapse, há uma variedade de opções de segurança de rede disponíveis para considerar.
  • Quais são as ferramentas que detectam e me notificam de ameaças?
    • 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 Azure são ideais para cargas de trabalho que exigem tempos de resposta rápidos e consistentes ou que têm um alto número de operações de saída de entrada (IOP) por segundo. As contas de armazenamento contêm todos os objetos de dados do Armazenamento do Azure e têm muitas opções para 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 nesta 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 para pipelines em Azure Synapse podem ser encontrados na guia Integração de Dados na página de preços Azure Synapse. Há três componentes principais que influenciam o preço de um pipeline:

  1. Atividades de pipeline de dados e horas de runtime de integração
  2. Tamanho e execução 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 pelo Azure padrão, a atividade de cópia de dados para o núcleo do pipeline, é disparado em uma agenda diária 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.

Azure Synapse pool e armazenamento dedicados

Os detalhes de preço para Azure Synapse pool dedicado podem ser encontrados na guia Data Warehousing na página de preços Azure Synapse. No modelo de consumo dedicado, os clientes são cobrados por unidades DWU provisionadas, por hora de tempo de atividade. Outro fator contribuinte são os custos de armazenamento de dados: tamanho de seus dados em repouso + 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. Você pode manter a computação em funcionamento durante o horário comercial dos relatórios. Se levada para produção, a capacidade reservada do data warehouse é uma opção atraente para o gerenciamento de custos. Técnicas diferentes devem ser usadas para maximizar as métricas de custo/desempenho, que são abordadas nas seções anteriores.

Armazenamento de blob

Considere usar o recurso de capacidade reservada do Armazenamento do Azure para reduzir os custos de armazenamento. Com esse modelo, você receberá um desconto se reservar a 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 neste cenário.

Power BI Premium

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

Esse cenário usa Power BI Premium workspaces 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 em produção. Para obter mais informações, consulte 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 (entrega 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 de Azure Synapse
    • Ativos do Power BI: dashboards, aplicativos, conjuntos de dados
    • Um cenário simulado local para a nuvem

    Pretenda 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. Dessa forma, você pode enviar atualizações por push para seus ambientes de produção de forma controlada e minimizar problemas de implantação não previstos. Use a implantação azul-verde e as estratégias de lançamento canário para atualizar ambientes de produção ao vivo.

  • 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 --rollback-on-error sinalizador 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. Azure Synapse Analytics fornece uma experiência de monitoramento dentro do 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 obter mais informações, confira a visão geral do pilar de eficiência de desempenho.

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

pool provisionado 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 expansão, especialmente para unidades de data warehouse maiores, use pelo menos um conjunto de dados de 1 TB. Para encontrar o melhor número de unidades de data warehouse para o pool de SQL dedicado, tente aumentar e reduzir verticalmente. 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.

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

Dimensionamento do pool de SQL do Synapse

Azure Pipelines

Para obter recursos de escalabilidade e otimização de desempenho de pipelines em Azure Synapse e a atividade de cópia usada, consulte o guia de desempenho e escalabilidade do atividade Copy.

Power BI Premium

Este artigo usa Power BI Premium Gen 2 para demonstrar os recursos de BI. SkUs de capacidade para Power BI Premium intervalo de P1 (oito núcleos v) a P5 (128 núcleos v) atualmente. A melhor maneira de selecionar a capacidade necessária é passar por 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 Power BI Premium.

Colaboradores

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

Autores principais:

Outros colaboradores:

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

Próximas etapas