Arquitetura de soluções de BI no Centro de Excelência

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:

• Origens de dados
• Ingestão de dados
• Big data / preparação de dados
• Armazém de dados
• Modelos semânticos de BI
• Relatórios

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.

Frameworks

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.

Modelos de dados

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:

• Modelos empresariais
• Modelos semânticos de BI
• Modelos de Machine Learning (ML)

Modelos empresariais

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.

Modelos semânticos de BI

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.

Modelos do Machine Learning

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.

Armazém de dados

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.

• O ADLS Gen2 torna o Armazenamento do Azure a base para a criação de data lakes corporativos no Azure. Ele foi projetado para atender a vários petabytes de informações enquanto sustenta centenas de gigabits de taxa de transferência. Além disso, oferece capacidade de armazenamento e transações de baixo custo. Além disso, ele suporta acesso compatível com Hadoop, que permite gerenciar e acessar dados da mesma forma que faria com um HDFS (Hadoop Distributed File System). Na verdade, o Azure HDInsight, o Azure Databricks e o Azure Synapse Analytics podem acessar dados armazenados no ADLS Gen2. Portanto, em uma plataforma de BI, é uma boa opção armazenar dados brutos de origem, dados semiprocessados ou em estágios e dados prontos para produção. Utilizamo-lo para armazenar todos os nossos dados comerciais.
• O Azure Synapse Analytics é um serviço de análise que reúne armazenamento de dados corporativos e análise de Big Data. Dá-lhe a liberdade de consultar dados nos seus termos, através de recursos a pedido ou aprovisionados sem servidor, em escala. O Synapse SQL, um componente do Azure Synapse Analytics, oferece suporte a análises completas baseadas em T-SQL, portanto, é ideal hospedar modelos corporativos que incluam suas tabelas de dimensões e fatos. As tabelas podem ser carregadas de forma eficiente a partir do ADLS Gen2 usando consultas T-SQL Polybase simples. Em seguida, você tem o poder do MPP para executar análises de alto desempenho.

Estrutura do mecanismo de regras de negócios

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.

Origens de dados

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.

Ingestão de 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.

Quadro de ingestão

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.

Estrutura de orquestração

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.

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

Consumo de dados

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:

• Os analistas de dados se conectam diretamente aos principais modelos semânticos de BI. Quando os principais modelos semânticos de BI contêm todos os dados e a lógica de que precisam, eles usam conexões em tempo real para criar relatórios e painéis do Power BI. Quando eles precisam estender os modelos com dados departamentais, eles criam modelos compostos do Power BI. Se houver necessidade de relatórios no estilo de planilha, eles usam o Excel para produzir relatórios com base em modelos semânticos de BI principais ou modelos semânticos de BI departamentais.
• Os desenvolvedores de BI e os autores de relatórios operacionais se conectam diretamente aos modelos corporativos. Eles usam o Power BI Desktop para criar relatórios analíticos de conexão em tempo real. Eles também podem criar relatórios de BI de tipo operacional como relatórios paginados do Power BI, escrevendo consultas SQL nativas para acessar dados dos modelos empresariais do Azure Synapse Analytics usando T-SQL ou modelos semânticos do Power BI usando DAX ou MDX.
• Os cientistas de dados se conectam diretamente aos dados no data lake. Eles usam o Azure Databricks e blocos de anotações Python para desenvolver modelos de ML, que geralmente são experimentais e exigem habilidades especializadas para uso em produção.

Conteúdos relacionados

Para obter mais informações sobre este artigo, consulte os seguintes recursos:

• Roteiro de adoção de malha: Centro de Excelência
• Enterprise BI no Azure com o Azure Synapse Analytics
• Perguntas? Tente perguntar à Comunidade do Power BI
• Sugestões? Contribua com ideias para melhorar o Power BI

Serviços profissionais

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.