evento
Junte-se a nós na FabCon Vegas
31/03, 23 - 2/04, 23
O melhor evento liderado pela comunidade Microsoft Fabric, Power BI, SQL e AI. 31 de março a 2 de abril de 2025.
Registe-se hoje mesmoEste browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
Este artigo destina-se a profissionais e gestores de TI. Você aprenderá sobre a arquitetura de soluções de BI no COE e as diferentes tecnologias empregadas. As tecnologias incluem Azure, Power BI e Excel. Juntos, eles podem ser aproveitados para fornecer uma plataforma de BI na nuvem escalável e orientada por dados.
Projetar uma plataforma de BI robusta é algo como construir uma ponte; uma ponte que conecta dados de origem transformados e enriquecidos aos consumidores de dados. O projeto de uma estrutura tão complexa requer uma mentalidade de engenharia, embora possa ser uma das arquiteturas de TI mais criativas e gratificantes que você poderia projetar. Em uma grande organização, uma arquitetura de solução de BI pode consistir em:
A plataforma deve suportar demandas específicas. Especificamente, ele deve ser dimensionado e executado para atender às expectativas dos serviços corporativos e dos consumidores de dados. Ao mesmo tempo, tem de ser segura desde o início. E deve ser suficientemente resiliente para se adaptar à mudança, porque é certo que, com o tempo, novos dados e áreas temáticas devem ser colocados online.
Na Microsoft, desde o início, adotamos uma abordagem semelhante a sistemas, investindo no desenvolvimento de estruturas. As estruturas técnicas e de processos de negócios aumentam a reutilização do design e da lógica e fornecem um resultado consistente. Eles também oferecem flexibilidade na arquitetura, aproveitando muitas tecnologias, e simplificam e reduzem a sobrecarga de engenharia por meio de processos repetíveis.
Aprendemos que estruturas bem projetadas aumentam a visibilidade da linhagem de dados, análise de impacto, manutenção da lógica de negócios, gerenciamento de taxonomia e simplificação da governança. Além disso, o desenvolvimento tornou-se mais rápido e a colaboração entre grandes equipas tornou-se mais ágil e eficaz.
Descreveremos várias de nossas estruturas neste artigo.
Os modelos de dados fornecem controle sobre como os dados são estruturados e acessados. Para os serviços empresariais e consumidores de dados, os modelos de dados são a sua interface com a plataforma de BI.
Uma plataforma de BI pode fornecer três tipos diferentes de modelos:
Os modelos empresariais são criados e mantidos por arquitetos de TI. Eles às vezes são referidos como modelos dimensionais ou data marts. Normalmente, os dados são armazenados em formato relacional como tabelas de dimensões e fatos. Essas tabelas armazenam dados limpos e enriquecidos consolidados de muitos sistemas e representam uma fonte autorizada para relatórios e análises.
Os modelos empresariais fornecem uma fonte de dados única e consistente para relatórios e BI. Eles são construídos uma vez e compartilhados como um padrão corporativo. As políticas de governança garantem que os dados estejam seguros, portanto, o acesso a conjuntos de dados confidenciais, como informações de clientes ou finanças, é restrito com base nas necessidades. Adotam convenções de nomenclatura que garantem a coerência, estabelecendo assim ainda mais a credibilidade dos dados e a qualidade.
Em uma plataforma de BI na nuvem, os modelos corporativos podem ser implantados em um pool SQL Synapse no Azure Synapse. O pool Synapse SQL torna-se então a única versão da verdade com a qual a organização pode contar para insights rápidos e robustos.
Os modelos semânticos de BI representam uma camada semântica sobre os modelos empresariais. Eles são criados e mantidos por desenvolvedores de BI e usuários corporativos. Os desenvolvedores de BI criam modelos semânticos de BI principais que originam dados de modelos corporativos. Os usuários corporativos podem criar modelos independentes de menor escala — ou podem estender os principais modelos semânticos de BI com fontes departamentais ou externas. Os modelos semânticos de BI geralmente se concentram em uma única área temática e geralmente são amplamente compartilhados.
Os recursos de negócios são habilitados não apenas por dados, mas por modelos semânticos de BI que descrevem conceitos, relacionamentos, regras e padrões. Dessa forma, eles representam estruturas intuitivas e fáceis de entender que definem relações de dados e encapsulam regras de negócios como cálculos. Eles também podem impor permissões de dados refinadas, garantindo que as pessoas certas tenham acesso aos dados certos. É importante ressaltar que eles aceleram o desempenho da consulta, fornecendo análises interativas extremamente responsivas — até mesmo em terabytes de dados. Assim como os modelos empresariais, os modelos semânticos de BI adotam convenções de nomenclatura que garantem consistência.
Em uma plataforma de BI na nuvem, os desenvolvedores de BI podem implantar modelos semânticos de BI no Azure Analysis Services, capacidades do Power BI Premium das capacidades do Microsoft Fabric.
Importante
Às vezes, este artigo se refere ao Power BI Premium ou suas assinaturas de capacidade (SKUs P). Lembre-se de que a Microsoft está atualmente consolidando opções de compra e desativando as SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de assinaturas de capacidade de malha (SKUs F).
Para obter mais informações, consulte Atualização importante chegando ao licenciamento do Power BI Premium e Perguntas frequentes sobre o Power BI Premium.
Recomendamos a implantação no Power BI quando ele for usado como sua camada de relatórios e análises. Esses produtos suportam diferentes modos de armazenamento, permitindo que as tabelas de modelo de dados armazenem seus dados em cache ou usem o DirectQuery, que é uma tecnologia que passa consultas para a fonte de dados subjacente. O DirectQuery é um modo de armazenamento ideal quando as tabelas de modelo representam grandes volumes de dados ou há a necessidade de fornecer resultados quase em tempo real. Os dois modos de armazenamento podem ser combinados: os modelos compostos combinam tabelas que usam diferentes modos de armazenamento em um único modelo.
Para modelos muito consultados, o Azure Load Balancer pode ser usado para distribuir uniformemente a carga de consulta entre réplicas de modelo. Ele também permite que você dimensione seus aplicativos e crie modelos semânticos de BI altamente disponíveis.
Os modelos de Machine Learning (ML) são construídos e mantidos por cientistas de dados. Eles são desenvolvidos principalmente a partir de fontes brutas no data lake.
Modelos de ML treinados podem revelar padrões em seus dados. Em muitas circunstâncias, esses padrões podem ser usados para fazer previsões que podem ser usadas para enriquecer dados. Por exemplo, o comportamento de compra pode ser usado para prever a rotatividade de clientes ou segmentar clientes. Os resultados da previsão podem ser adicionados aos modelos empresariais para permitir a análise por segmento de cliente.
Em uma plataforma de BI na nuvem, você pode usar o Aprendizado de Máquina do Azure para treinar, implantar, automatizar, gerenciar e rastrear modelos de ML.
No coração de uma plataforma de BI está o armazém de dados, que hospeda seus modelos corporativos. É uma fonte de dados sancionados — como um sistema de registro e como um hub — servindo modelos corporativos para relatórios, BI e ciência de dados.
Muitos serviços empresariais, incluindo aplicativos de linha de negócios (LOB), podem confiar no data warehouse como uma fonte autorizada e controlada de conhecimento corporativo.
Na Microsoft, nosso data warehouse está hospedado no Azure Data Lake Storage Gen2 (ADLS Gen2) e no Azure Synapse Analytics.
Desenvolvemos uma estrutura Business Rules Engine (BRE) para catalogar qualquer lógica de negócios que possa ser implementada na camada de data warehouse. Um BRE pode significar muitas coisas, mas no contexto de um armazém de dados é útil para criar colunas calculadas em tabelas relacionais. Estas colunas calculadas são geralmente representadas como cálculos matemáticos ou expressões usando instruções condicionais.
A intenção é separar a lógica de negócios do código de BI principal. Tradicionalmente, as regras de negócios são codificadas em procedimentos armazenados SQL, portanto, muitas vezes resulta em muito esforço para mantê-las quando as necessidades de negócios mudam. Em um BRE, as regras de negócios são definidas uma vez e usadas várias vezes quando aplicadas a diferentes entidades de data warehouse. Se a lógica de cálculo precisar mudar, ela só precisa ser atualizada em um lugar e não em vários procedimentos armazenados. Há também um benefício colateral: uma estrutura BRE impulsiona a transparência e a visibilidade da lógica de negócios implementada, que pode ser exposta por meio de um conjunto de relatórios que criam documentação de autoatualização.
Um armazém de dados pode consolidar dados de praticamente qualquer fonte de dados. Ele é construído principalmente sobre fontes de dados LOB, que geralmente são bancos de dados relacionais que armazenam dados específicos do assunto para vendas, marketing, finanças, etc. Esses bancos de dados podem ser hospedados na nuvem ou residir localmente. Outras fontes de dados podem ser baseadas em arquivos, especialmente logs da Web ou dados IOT provenientes de dispositivos. Além disso, os dados podem ser obtidos de fornecedores de Software como Serviço (SaaS).
Na Microsoft, alguns de nossos sistemas internos emitem dados operacionais diretamente para o ADLS Gen2 usando formatos de arquivo brutos. Além do nosso data lake, outros sistemas de origem incluem aplicativos LOB relacionais, pastas de trabalho do Excel, outras fontes baseadas em arquivos e Master Data Management (MDM) e repositórios de dados personalizados. Os repositórios MDM nos permitem gerenciar nossos dados mestre para garantir versões confiáveis, padronizadas e validadas dos dados.
Periodicamente, e de acordo com os ritmos do negócio, os dados são ingeridos dos sistemas de origem e carregados no data warehouse. Pode ser uma vez por dia ou em intervalos mais frequentes. A ingestão de dados diz respeito à extração, transformação e carregamento de dados. Ou, talvez o contrário: extraindo, carregando e depois transformando dados. A diferença se resume ao local onde ocorre a transformação. As transformações são aplicadas para limpar, conformar, integrar e padronizar dados. Para obter mais informações, consulte Extrair, transformar e carregar (ETL).
Em última análise, o objetivo é carregar os dados certos no seu modelo empresarial da forma mais rápida e eficiente possível.
Na Microsoft, usamos o Azure Data Factory (ADF). Os serviços são usados para agendar e orquestrar validações, transformações e cargas em massa de dados de sistemas de origem externa em nosso data lake. Ele é gerenciado por estruturas personalizadas para processar dados em paralelo e em escala. Além disso, o registro abrangente é realizado para dar suporte à solução de problemas, monitoramento de desempenho e disparar notificações de alerta quando condições específicas são atendidas.
Enquanto isso, o Azure Databricks — uma plataforma de análise baseada no Apache Spark otimizada para a plataforma de serviços de nuvem do Azure — executa transformações especificamente para ciência de dados. Ele também constrói e executa modelos de ML usando notebooks Python. As pontuações desses modelos de ML são carregadas no data warehouse para integrar previsões com aplicativos e relatórios corporativos. Como o Azure Databricks acessa os arquivos do data lake diretamente, ele elimina ou minimiza a necessidade de copiar ou adquirir dados.
Desenvolvemos um framework de ingestão como um conjunto de tabelas de configuração e procedimentos. Ele suporta uma abordagem orientada por dados para adquirir grandes volumes de dados em alta velocidade e com código mínimo. Em suma, esta estrutura simplifica o processo de aquisição de dados para carregar o data warehouse.
A estrutura depende de tabelas de configuração que armazenam informações relacionadas à fonte de dados e ao destino dos dados, como tipo de origem, servidor, banco de dados, esquema e detalhes relacionados à tabela. Essa abordagem de design significa que não precisamos desenvolver pipelines específicos do ADF ou pacotes do SQL Server Integration Services (SSIS). Em vez disso, os procedimentos são escritos na linguagem de nossa escolha para criar pipelines do ADF que são gerados e executados dinamicamente em tempo de execução. Assim, a aquisição de dados torna-se um exercício de configuração facilmente operacionalizado. Tradicionalmente, seriam necessários recursos de desenvolvimento extensivos para criar pacotes ADF ou SSIS codificados.
A estrutura de ingestão também foi projetada para simplificar o processo de manipulação de alterações de esquema de origem upstream. É fácil atualizar os dados de configuração — manual ou automaticamente, quando são detetadas alterações de esquema para adquirir atributos recém-adicionados no sistema de origem.
Desenvolvemos uma estrutura de orquestração para operacionalizar e orquestrar nossos pipelines de dados. Ele usa um design controlado por dados que depende de um conjunto de tabelas de configuração. Essas tabelas armazenam metadados que descrevem as dependências do pipeline e como mapear dados de origem para estruturas de dados de destino. Desde então, o investimento no desenvolvimento deste quadro adaptativo pagou-se a si próprio; Não há mais a necessidade de codificar cada movimento de dados.
Um data lake pode armazenar grandes volumes de dados brutos para uso posterior, juntamente com transformações de dados de preparação.
Na Microsoft, usamos o ADLS Gen2 como nossa única fonte de verdade. Ele armazena dados brutos juntamente com dados em estágios e dados prontos para produção. Ele fornece uma solução de data lake altamente escalável e econômica para análise de big data. Combinando o poder de um sistema de arquivos de alto desempenho com grande escala, ele é otimizado para cargas de trabalho de análise de dados, acelerando o tempo de insight.
O ADLS Gen2 oferece o melhor de dois mundos: é o armazenamento BLOB e um namespace de sistema de arquivos de alto desempenho, que configuramos com permissões de acesso refinadas.
Os dados refinados são então armazenados em um banco de dados relacional para oferecer um armazenamento de dados de alto desempenho e altamente escalável para modelos corporativos, com segurança, governança e capacidade de gerenciamento. Os data marts específicos do assunto são armazenados no Azure Synapse Analytics, que são carregados por consultas T-SQL do Azure Databricks ou Polybase.
Na camada de relatórios, os serviços corporativos consomem dados corporativos provenientes do data warehouse. Eles também acessam dados diretamente no data lake para análises ad hoc ou tarefas de ciência de dados.
Permissões refinadas são impostas em todas as camadas: no data lake, modelos corporativos e modelos semânticos de BI. As permissões garantem que os consumidores de dados só possam ver os dados aos quais têm direitos de acesso.
Na Microsoft, usamos relatórios e painéis do Power BI e relatórios paginados do Power BI. Alguns relatórios e análises ad hoc são feitos no Excel, especialmente para relatórios financeiros.
Publicamos dicionários de dados, que fornecem informações de referência sobre nossos modelos de dados. Eles são disponibilizados aos nossos usuários para que eles possam descobrir informações sobre nossa plataforma de BI. Os dicionários documentam designs de modelos, fornecendo descrições sobre entidades, formatos, estrutura, linhagem de dados, relações e cálculos. Usamos o Catálogo de Dados do Azure para tornar nossas fontes de dados facilmente detetáveis e compreensíveis.
Normalmente, os padrões de consumo de dados diferem com base na função:
Para obter mais informações sobre este artigo, consulte os seguintes recursos:
Os parceiros certificados do Power BI estão disponíveis para ajudar a sua organização a ter sucesso ao configurar um COE. Eles podem fornecer treinamento econômico ou uma auditoria de seus dados. Para envolver um parceiro do Power BI, visite o portal do parceiro do Power BI.
Você também pode se envolver com parceiros de consultoria experientes. Eles podem ajudá-lo a avaliar, avaliar ou implementar o Power BI.
evento
Junte-se a nós na FabCon Vegas
31/03, 23 - 2/04, 23
O melhor evento liderado pela comunidade Microsoft Fabric, Power BI, SQL e AI. 31 de março a 2 de abril de 2025.
Registe-se hoje mesmoFormação
Percurso de aprendizagem
Arquiteto de Soluções: projetar soluções do Microsoft Power Platform - Training
Aprenda como um arquiteto de soluções projeta soluções.
Certificação
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstre métodos e boas práticas que se alinhem aos requisitos técnicos e comerciais para modelagem, visualização e análise de dados com o Microsoft Power BI.