PowerBI 大型报表架构设计 - 30页100个度量值1000个对象

PowerBI 虽然从某种意义上说只是一个制作报表的工具，但在制作报表的过程中，从简单的报表，到极为复杂的报表都有可能。

企业级报表是要完全满足用户需求的，这和简单的可视化完全不同，在有些情况，甚至大部分情况，一切科学的可视化理论是失效的，客户就是上帝。

如果客户只能理解线图，你凭什么告诉客户自定义图表更好。这才是真实的企业环境。

这里简单探讨一下企业级报表项目解决方案的架构设计。

导航系统

很可惜，目前 PowerBI 对支持复杂企业结构报表并不理想，针对如下问题：

• 可视化对象需要囊括大量信息
• 众多报表主题及子主题
• 众多灵活的需求
• 一致的可维护的报表

PowerBI 目前很难应付，但就导航系统，就会因为无法复用而存在大量手工劳动，经过实践总结，要完成上述任务并设计出多级导航系统的一个可行方案如下：

这里面蕴含大量细节上的学问，这是目前几乎已知相对工作量最小的做法。

• 横向导航系统满足了长标题的报表名称
• 统一导航系统
• 二级导航系统应对大型复杂报表结构
• 纯 PowerBI 原生元素打造
• 精确到像素级别控制

这里可以延展一些问题让大家思考，为了设计高度精细的布局，你知道这些问题的答案吗：

• 在PBI布局网格中，每两个小点之间的距离是多大？（如：x像素）
• 在PBI布局网格中，任意元素的最小高度（宽度）是多大？（如：x像素）
• 在PBI布局网格中，如果要制作一个背景标题，应该选择什么元素？（如：图形，文本框）
• 在PBI布局网格中，如果要制作一个圆角矩形，应该选择什么元素？圆角弧度大小应该为多大？
• 在PBI布局网格中，如果要制作一个水平导航条，其高度应该如何设计最佳？
• 在PBI布局网格中，如果要制作一个导航按钮，如何设计使得性价比最佳？

如果您思考过以上问题，欢迎留言，以上问题均有标准答案。关于导航系统的制作，PBI在2018年更新过多次特性全部综合起来，终于可以制作成一个合理的导航系统，但由于无法重用，导致制作效率是低下的，关于这个话题，可以详尽地说明很多，将开专门主题再做探讨。

大家可以参考此图，自行实践。

数据准备

由于 PowerQuery 提供了分组功能，在数据准备上相对可以划分成更合理的结构。至于为何有这些分组及用意，相信很多伙伴也有自己的划分方式。

在 PowerBI 中，可以使用Ctrl+C, Ctrl+V的方式将PQ逻辑复制粘贴进新的PBI文件，这个功能使得数据准备的逻辑可以复用，是非常重要的。

业务模型数据

由于我们的重点是分析业务，所以业务模型数据是重点，为了构建业务模型，采用经典的ETL划分方式：

• 数据源配置，并获取数据
• 对获取到的数据进行处理
• 要加载的数据应满足事先定义好的结构

报表模型数据

几乎没有PowerBI的报表是仅仅依赖业务数据构建的，为了构建报表，还需要一些辅助的数据，称为：报表模型数据，如：年龄分组，参数表等。

业务指标

业务指标的宿主表定义。在PBI中可以通过计算表或输入表两种方法实现，推荐使用输入表法。

MVC

MVC，一词来自软件工程中前端设计模式。该方法论也适用于PowerBI报表设计：

• View，即可视化对象图表。
• Model，准确讲是 ViewModel ，是为了绘制某可视化图表而依赖的数据结果。
• Controler，由用户操作而产生的上下文环境与度量值共同担任。

Excel120 首次提出将软件工程设计模式的经典MVC模式引进PowerBI系统设计，这是一套成熟的方法论，用于解除图表，数据，业务逻辑之间的耦合，进而设计出可以高度复用，灵活扩展的结构。

此话题也将开设专题进行深入探讨。

权限控制

PowerBI 中全动态权限控制可通过RLS或更加灵活的机制实现，已经单开话题讨论。参考：PowerBI 企业级权限控制全动态终极解决方案。

模型维护

模型维护，是PowerBI报表设计的重点。

模型维护中，常见的问题包括：

• 哪个自定义图表没用过，可以删除，不知道。
• 哪个列没用过，可以删除，不知道。
• 哪个度量值没用过，可以删除，不知道。
• 哪个度量值被哪个图表用着，不知道。
• 想改一个度量值，由于不知道被谁用，不敢改。

于是，能做的事只有一件，就是：只增加不敢删除。

这将有可能导致一个项目变得非常非常复杂。很可惜，目前 PowerBI 都没有给出官方的维护方法，这点使得 PowerBI 制作大型复杂报表非常力不从心。

这里推荐一个网站：app.datavizioner.com 目前该第三方网站可以大致帮助我们解决一部分问题。

可以通过上传PowreBI导出的模板文件 .PBIT（必须小于2M），在该网站得到对PowerBI文件结构的解析。

报告分析

可以看出对于本报告：

• 使用了 35 个页面
• 使用了 942 个可视化对象
• 使用了 17 种可视化对象
• 包括 26 张表
• 有 117 个度量值
• 实际使用了 19 列

这个报表所使用元素的规模（35页，942个可视化对象）很难纯人工维护。 在目前 PowerBI 没用给出官方高效维护方法的现状下，必须靠非常有效的人工管理，这就需要我们预先思考清楚如何管理以下元素：

• 业务基表
• 辅助基表
• 计算列
• 度量值
• 业务计算表
• 辅助计算表
• 关系
• 按列排序
• 可视化元素，用于图表，如：条形图等。
• 可视化元素，用于装饰，如：导航，LOGO，按钮等。
• 命名规则
• 注释规则

可以考虑以下原则以简化设计：

• 遵循非侵入式设计原则（Excel120提出），保持度量值优先。
• 尽量保持单向一对多关系。
• 区分业务基表与辅助表。
• 区分业务度量值与功能度量值。
• 建立可复用的度量值依赖体系结构。
• 区分度量值宿主表（Measure Host Table，非官方名称）。
• 建立指标命名规则。

大家可以进一步研究补充必要的管理规则。

M 脚本维护

该工具还提供了导出全部 M 脚本

当然，PowerBI 本身也提供了 M 导出的功能。这倒不是大问题。

模型分析

该工具提供了对模型分析的方法：

于是可以大致知道模型的规模以及可以增删的冗余成分：

可以看出，在上图呈现的结构中，蓝色表示使用的表；橙色表示未在可视化中直接使用的表，则可知：

• PBI模型真实的结构既不是星型模型也不是雪花模型，而是：星系模型（Excel120提出）。
• 星系模型：
• 包含多个星型，一般取决于事实表的个数，形成多事实表结构。
• 包含多个孤立星，也就是孤立表，它们通常起到容器，分组，参数，辅助可视化等作用。

因此，我们需要实际维护的是一个复杂的 星系模型。

维护中可以做的事情包括：

• 明确模型中各种表的作用，有的表中含有业务数据；而有的表则不然，用于其他方面。
• 隐藏未在可视化中直接使用的表或列。
• 清理未在可视化中使用过的度量值。
• 隐藏未在可视化中直接使用的度量值。

大家可以尝试使用该工具来维护分析自己的模型。

总结

本文将大型复杂PowerBI报表设计结构做了概要式的分析，分为三大方面：

• 数据准备结构设计：业务数据，辅助数据，指标宿主表，MVC，权限控制。
• 数据模型结构设计：基表，度量值，计算列，计算表，辅助表，关系，命名规则。
• 报表可视化结构设计：导航，布局，MVC。（这里并非研究如何作图，而是研究作图的可复用结构规律）

很显然，纯ETL理论，星型模式，可视化方法都并不真正适合PowerBI，您在大量工作中是否也感觉到了这个问题。在这方面，PowerBI是否给了我们一次可以基于PowerBI去重新思考如何设计结构的机会。PowerBI目前并没有给出官方的最佳实践，而且也不直接支持这些复杂问题的处理，耐心等待更新吧。另外，未来我们将更详尽的探讨在PBI现状下，上述所有内容的细化方法。