Powerbi 具有多个报表组特定聚合的星型架构：好还是坏 客观的

我们正在为业务自助服务构建企业DWH：数十TB的数据和大约30个业务用户。流程看起来像：

Sources->ETL->DWH->powerbi->User

事务粒度事实可能包含数十亿行、非累加度量和KPI。因此，外部内存多维数据集（表格模型）或PBI导入模式不是我们的选择。同时，我们有非常严格的性能要求——PBI可视化的构建时间不应该超过15秒

为了性能和可用性，我们最终让PBI团队定义物化视图，从每个事务事实表（在DWH层）构建多个（目前不是太多）聚合派生。每个衍生工具只是一个更聚合的事实表加上预先计算/聚合的KPI

问题 部分原因是治理尚未实现，可能是由于表和KPI的数量，业务用户发现事务粒度星型模式太复杂（有时很慢），往往只使用派生聚合事实进行数据探索。我觉得事务粒度只能由Power BI团队使用，并且不能说我们将来会为每个事务事实表使用多少衍生工具（这取决于，可能从5到10）

问题: 我们现在采用的方法=标准（最佳实践）方法吗？我们是否应该鼓励业务用户使用事务事实？还是创建5个衍生聚合并将负担放在Power BI团队的一边是一个好方法

附笔。 PBI报告的15秒要求有多普遍？表示当用户选择任何切片器值时，报告应在<15秒内重新刷新。门槛不是太低了吗

我们现在采用的方法=标准（最佳实践）方法吗

对。使用（物化的）视图或Power内存中的BI表格模型构建部分聚合是完全正常的。这些只是“数据集市”，它们是为特定目的和特定受众而构建的。在捕获企业所有相关事实和维度属性的全保真度模型和为特定目的或视角而易于导航和回答问题的模型之间存在着内在的紧张关系

在DWH中无法真正定义度量，因为不能在最低粒度或任何中间粒度上计算非加性度量。因此，您确实需要表格模型来定义标准化的、可重用的计算

PBI报告的15秒要求有多普遍

完全正确。它是一个交互式报告工具，通常需要几个单独的查询来刷新报告页面。因此，10秒或更长的查询响应时间会导致非常糟糕的用户体验

我们是否应该鼓励业务用户使用事务事实

有些人会直接进入最底层并访问所有数据，所以你不应该阻止它。但大多数人不会，并且希望从一开始就对数据有一个更精确的了解

还是创建5个衍生聚合并将负担放在Power BI团队的一边是一个好方法

---

这样想吧。无论是您的最终用户/分析师构建模型，还是您的Power BI团队，结果都是一样的。从DWH层开始，将构建一个模型来选择相关数据、定义有意义的度量并提供可接受的性能。该模型可能仅适用于一份报告，也可能适用于整个部门。

这不是对您问题的回答，但您是否了解Power BI？例如，请看著名的“万亿行演示”…@AndreyNikolov当然，我们尽可能使用复合模型。尽管如此，用例的数量仍然受到导入模型的最大大小的限制（非高级PBI为1GB）。这似乎是一个需要明确回答的过于宽泛和基于观点的问题。@AlexisOlson您认为有可能缩小范围吗？也许需要一些细节。或者，如果没有技术上的答案，那么我应该问什么问题呢？可能正是如此，才不是提出此类问题的合适场所。也许可以试试community.powerbi.com。它相当活跃。