卓越中心的 BI 解决方案体系结构
本文面向 IT 专业人员和 IT 经理。 你将了解 COE 中的 BI 解决方案体系结构以及采用的不同技术。 技术包括 Azure、Power BI 和 Excel。 一起，可以利用它们来提供可缩放且数据驱动的云 BI 平台。
设计可靠的 BI 平台有点像构建桥梁：将转换和扩充的源数据连接到数据使用者的网桥。 这种复杂结构的设计需要一种工程思维模式，尽管它可能是您能设计的最有创意和最有成就感的 IT 体系结构之一。 在大型组织中，BI 解决方案体系结构可以包括：
- 数据源
- 数据引入
- 大数据/数据准备
- 数据仓库
- BI 语义模型
- 报告
显示 BI 平台体系结构关系图（从数据源到机器学习）的 
平台必须支持特定需求。 具体而言，它必须具备扩展性和性能，以满足业务服务和数据消费者的期望。 同时，必须从基础上确保其安全。 而且，它必须具有足够的弹性以适应变化，因为可以确定，随着时间的推移，新的数据和新的主题领域必须上线。
框架
在 Microsoft，从一开始我们就通过投资框架开发来采用类似系统的方法。 技术和业务流程框架可增加设计和逻辑的重用，并提供一致的结果。 它们还提供利用许多技术在体系结构方面的灵活性，并通过可重复的过程简化和减少工程开销。
我们了解到，设计良好的框架可以提高对数据世系、影响分析、业务逻辑维护、管理分类和简化治理的可见性。 此外，开发变得更加快速，大型团队之间的协作变得更加响应和有效。
本文将介绍我们的几个框架。
数据模型
数据模型提供对数据的结构化和访问方式的控制。 对业务服务和数据使用者，数据模型是其与 BI 平台的接口。
BI 平台可以提供三种不同类型的模型：
- 企业模型
- BI 语义模型
- 机器学习 （ML） 模型
企业模型
企业模型 由 IT 架构师构建和维护。 它们有时称为维度模型或数据市场。 通常，数据以关系格式存储为维度和事实数据表。 这些表存储的是从多个系统合并而来的清理和强化数据，它们是报告和分析的权威来源。
企业模型为报告和 BI 提供一致且单一的数据源。 它们只构建一次，并作为企业标准进行共享。 治理政策保证数据安全，因此对敏感数据集（如客户信息或财务）基于需要进行访问限制。 它们采用确保一致性的命名约定，从而进一步确立数据和质量的可信度。
在云 BI 平台中，企业模型可以部署到 Azure Synapse中的
BI 语义模型
BI 语义模型 表示企业模型的语义层。 它们由 BI 开发人员和业务用户构建和维护。 BI 开发人员创建从企业模型源数据的核心 BI 语义模型。 业务用户可以创建规模较小的独立模型，或者，他们可以使用部门或外部源扩展核心 BI 语义模型。 BI 语义模型通常侧重于单个主题区域，并且通常广泛共享。
业务功能不是单独由数据启用，而是由描述概念、关系、规则和标准的 BI 语义模型启用。 这样，它们就表示直观且易于理解的结构，这些结构定义数据关系并将业务规则封装为计算。 他们还可以强制实施细粒度的数据权限，确保适当的人员有权访问正确的数据。 重要的是，它们加速查询性能，提供极其响应的交互式分析，即使是在数 TB 的数据上也是如此。 与企业模型一样，BI 语义模型采用确保一致性的命名约定。
在云 BI 平台中，BI 开发人员可以将 BI 语义模型部署到 Azure Analysis Services、Power BI Premium 容量 或 Microsoft Fabric 容量。
重要
有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。
有关详细信息，请参阅 Power BI Premium 许可 和 Power BI Premium 常见问题解答的重要更新。
建议在 Power BI 用作报告和分析层时部署到 Power BI。 这些产品支持不同的存储模式，允许数据模型表缓存其数据或使用 DirectQuery，这是一种将查询传递到基础数据源的技术。 当模型表表示大量数据或需要提供近实时结果时，DirectQuery 是理想的存储模式。 两种存储模式可组合在一起：复合模型组合在单个模型中使用不同存储模式的表。
对于查询量很大的模型，Azure 负载均衡器 可用于在模型副本之间均匀分配查询负载。 它还允许缩放应用程序并创建高度可用的 BI 语义模型。
机器学习模型
机器学习（ML）模型 由数据科学家构建和维护。 它们大多是从数据湖中的原始数据源生成的。
经过训练的 ML 模型可以揭示数据中的模式。 在许多情况下，这些模式可用于进行可用于扩充数据的预测。 例如，购买行为可用于预测客户流失或细分客户。 可将预测结果添加到企业模型，以便按客户细分进行分析。
在云 BI 平台中，可以使用 Azure 机器学习 来训练、部署、自动化、管理和跟踪 ML 模型。
数据仓库
BI 平台的核心部分是承载企业模型的数据仓库。 它是一种受制裁的数据来源，作为记录系统，作为中心，为企业模型提供服务，用于报告、BI 和数据科学。
许多业务服务（包括业务线（LOB）应用程序，都可以依赖数据仓库作为企业知识的权威和管理来源。
在 Microsoft，我们的数据仓库托管在 Azure Data Lake Storage Gen2 (ADLS Gen2) 和 Azure Synapse Analytics 上。
Azure Synapse Analytics 连接到 Azure Data Lake Storage Gen2 的关系图 
- ADLS Gen2 使 Azure 存储成为在 Azure 上构建企业数据湖的基础。 它旨在服务多 TB 的信息，同时保持数百千兆位的吞吐量。 而且，它提供低成本的存储容量和交易。 更重要的是，它支持 Hadoop 兼容的访问，这使你可以像使用 Hadoop 分布式文件系统（HDFS）一样管理和访问数据。 事实上，Azure HDInsight、Azure Databricks，Azure Synapse Analytics 都可以访问 ADLS Gen2 中存储的数据。 因此，在 BI 平台中，最好存储原始源数据、半处理或暂存数据以及生产就绪数据。 我们使用它来存储所有业务数据。
- Azure Synapse Analytics 是一种分析服务，它汇集了企业数据仓库和大数据分析。 借助它可以使用无服务器的按需资源或预配资源，任意执行自己定义的大规模数据查询。 Synapse SQL 是 Azure Synapse Analytics 的一部分，它支持基于 T-SQL 的完整分析，因此托管包含维度和事实数据表的企业模型是理想的选择。 可以使用简单的 Polybase T-SQL 查询从 ADLS Gen2 高效地加载表。 然后，你可以利用 MPP 来运行高性能分析。
业务规则引擎框架
我们开发了一个 业务规则引擎（BRE）框架，用于编录可在数据仓库层中实现的任何业务逻辑。 BRE 可能意味着很多事情，但在数据仓库的上下文中，它可用于在关系表中创建计算列。 这些计算列通常使用条件语句表示为数学计算或表达式。
目的是从核心 BI 代码拆分业务逻辑。 传统上，业务规则在 SQL 存储过程中硬编码，因此在业务需求发生更改时，通常需要付出大量精力来维护它们。 在 BRE 中，业务规则定义一次，并应用于不同的数据仓库实体时多次使用。 如果计算逻辑需要更改，则只需在一个位置更新，而不是在许多存储过程中更新。 也有一个好处：BRE 框架也会推动实现的业务逻辑的透明度和可见性，这些逻辑可以通过一组创建自我更新文档的报表公开。
数据源
数据仓库几乎可以合并来自任何数据源的数据。 它主要基于 LOB 数据源构建，这些数据源通常是关系数据库，用于存储特定于主题的销售、营销、财务等数据。这些数据库可以是云托管的，也可以驻留在本地。 其他数据源可以是基于文件的，尤其是来自设备的 Web 日志或 IOT 数据。 更重要的是，数据可以从软件即服务（SaaS）供应商处获取。
Microsoft 的一些内部系统使用原始文件格式直接将操作数据输出到 ADLS Gen2。 除了数据湖之外，其他源系统还包括关系 LOB 应用程序、Excel 工作簿、其他基于文件的源以及 Master 数据管理（MDM）和自定义数据存储库。 MDM 存储库允许我们管理主数据，以确保权威、标准化和验证的数据版本。
数据引入
根据业务的节奏，定期从源系统引入数据并加载到数据仓库中。 可以是每天一次或更频繁。 数据引入涉及提取、转换和加载数据。 或者，也许另一种方式是：提取、加载和转换数据。 差异归结于转换的发生位置。 转换应用于清理、符合、集成和标准化数据。 有关详细信息，请参阅 提取、转换和加载（ETL）。
最终，目标是尽快高效地将正确的数据加载到企业模型中。
在微软，我们使用 Azure 数据工厂（ADF）。 这些服务用于计划和协调数据验证、转换，并将大量数据从外部源系统加载到我们的数据湖中。 它由自定义框架管理，以并行和大规模地处理数据。 此外，还进行了全面的日志记录，以支持故障排除、性能监视，并在满足特定条件时触发警报通知。
与此同时，Azure Databricks（一个基于 Apache Spark 的分析平台，针对 Azure 云服务平台进行了优化）执行专门针对数据科学的转换。 它还使用 Python 笔记本生成和执行 ML 模型。 这些 ML 模型的分数将加载到数据仓库中，以便将预测与企业应用程序和报表集成。 由于 Azure Databricks 直接访问 Data Lake 文件，因此无需复制或获取数据。
引入框架
我们开发了一个引入框架，作为一组配置表和过程。 它支持以数据驱动的方法以高速和最少的代码获取大量数据。 简言之，此框架简化了获取数据以加载数据仓库的过程。
框架取决于存储数据源和数据目标相关信息的配置表，例如源类型、服务器、数据库、架构和表相关详细信息。 此设计方法意味着我们不需要开发特定的 ADF 管道或 SQL Server Integration Services （SSIS） 包。 相反，过程采用我们选择的语言编写，以创建在运行时动态生成和执行的 ADF 管道。 因此，数据获取成为一种可轻松实现的配置操作。 传统上，需要大量的开发资源来创建硬编码的 ADF 或 SSIS 包。
引入框架旨在简化处理上游源架构更改的过程。 当检测到架构更改以获取源系统中新添加的属性时，可以手动或自动更新配置数据。
业务流程框架
我们开发了一个 业务流程框架 来操作和协调数据管道。 协调框架使用一种数据驱动设计，并且依赖于一组配置表。 这些表存储描述管道依赖项的元数据，以及如何将源数据映射到目标数据结构。 自从开发这个自适应框架以来，投资已经回本；现在不再需要对每个数据移动进行硬编码。
数据存储
Data Lake 可以存储大量原始数据，以供以后与暂存数据转换一起使用。
在Microsoft，我们使用 ADLS Gen2 作为单一事实来源。 它与暂存数据和生产就绪数据一起存储原始数据。 它为大数据分析提供了高度可缩放且经济高效的 Data Lake 解决方案。 将高性能文件系统的强大功能与大规模相结合，它针对数据分析工作负载进行优化，加快了见解的获取时间。
ADLS Gen2 结合了两者的优势：它既是 BLOB 存储，也是高性能文件系统命名空间，并且我们配置了细粒度访问权限。
然后，优化的数据存储在关系数据库中，为企业模型提供高性能、高度可缩放的数据存储，并具有安全性、治理和可管理性。 特定于主题的数据市场存储在 Azure Synapse Analytics 中，它由 Azure Databricks 或 Polybase T-SQL 查询加载。
数据消耗
在报告层，业务服务使用从数据仓库获取的企业数据。 它们还可以直接在 Data Lake 中访问数据，以便执行即席分析或数据科学任务。
细化权限在所有层（数据湖、企业模型和 BI 语义模型）强制执行。 权限可确保数据使用者只能查看他们有权访问的数据。
在 Microsoft，我们使用 Power BI 报表和仪表板以及 Power BI 分页报表。 某些报告和即席分析是在 Excel 中完成的，尤其是用于财务报告。
我们发布数据字典，该字典提供有关数据模型的参考信息。 他们可供用户使用，以便他们可以发现有关 BI 平台的信息。 字典文档模型设计，提供有关实体、格式、结构、数据世系、关系和计算的说明。 我们使用 Azure 数据目录 使数据源易于发现和易于理解。
通常，数据使用模式因角色而异：
- 数据分析师 直接连接到核心 BI 语义模型。 当核心 BI 语义模型包含所需的所有数据和逻辑时，它们使用实时连接来创建 Power BI 报表和仪表板。 他们需要使用部门数据扩展模型时，会创建 Power BI 复合模型。 如果需要电子表格样式的报表，则它们使用 Excel 基于核心 BI 语义模型或部门 BI 语义模型生成报表。
- BI 开发人员和操作报表作者直接连接到企业模型。 他们使用 Power BI Desktop 创建实时连接分析报表。 他们还可以撰写操作类型的 BI 报表，作为“Power BI 分页报表”。编写原生 SQL 查询，通过 T-SQL 访问 Azure Synapse Analytics 企业模型中的数据，或者通过 DAX 或 MDX 访问 Power BI 语义模型。
- 数据科学家直接连接到数据湖中的数据。 他们使用 Azure Databricks 和 Python 笔记本开发 ML 模型，这些模型通常是实验性的，需要专业技能才能用于生产。
相关内容
有关本文的详细信息，请查看以下资源：
- Fabric 采用路线图：卓越中心
- 通过 Azure Synapse Analytics 实现 Azure 中的企业 BI
- 问题？ 尝试咨询 Fabric 社区
- 建议？ 提出改进 Fabric 的想法
专业服务
认证 Power BI 合作伙伴可用于帮助组织在设置 COE 时取得成功。 他们可以为你提供经济高效的训练或数据的审核。 若要查找 Power BI 合作伙伴，请访问 Microsoft Power BI 合作伙伴门户。