具有多个报告组特定聚合的星型模式：好或坏
Star Schema with multiple report-group-specific aggregations: good or bad
Objective
我们正在为业务自助服务构建企业 DWH：数十 TB 的数据和大约 30 个业务用户。流程如下所示：Sources -> ETL -> DWH -> Power BI -> User。
事务粒度事实可能包含数十亿行、非附加度量和 KPI。因此，外部内存多维数据集（表格模型）或 PBI 导入模式不适合我们。同时我们有非常严格的性能要求——PBI 可视化的构建时间不应超过 15 秒。
为了性能和可用性，我们最终由 PBI 团队定义物化视图，以从每个交易事实 table（在 DWH 层）构建多个（此时不是太多）聚合衍生品。每个衍生品只是一个更聚合的事实 table 加上 pre-calculated/aggregated KPI。
问题
部分是因为治理还没有实现，可能是因为 tables 和 KPI 的数量，业务用户发现交易粒度星型模式太复杂（有时很慢），并且倾向于仅使用衍生的聚合事实进行数据探索。我感觉 transaction-grain 只会被 Power BI 团队使用，并且不能说我们将来每个交易事实 table 会有多少衍生品（这取决于，可能从 5 到 10） .
问题
我们现在采用的方法是否 = 标准（最佳实践）方法？我们应该鼓励我们的业务用户使用交易事实吗？还是创建 5 个衍生聚合并让 Power BI 团队承担负担是一个好方法？
P.S.
PBI 报告的 15 秒要求有多普遍？ 意味着当用户 select 任何切片器值时，报告应该在 < 15 秒内重新刷新. 是不是门槛太低了？
Is the approach we're doign now = a standard (best practice) approach?
是的。使用（物化）视图或在 Power BI 内存中表格模型中构建部分聚合是完全正常的。这些只是 "data marts"，它们是为特定目的和特定受众而构建的。捕获企业所有相关事实和维度属性的完全保真模型与针对特定目的或观点易于导航和回答问题的模型之间存在内在的紧张关系。
并且无法在 DWH 中真正定义度量，因为无法在最低粒度或任何中间粒度计算非附加度量。所以您确实需要表格模型来定义标准化、可重复使用的计算。
How common is the 15 seconds requirement for PBI reports?
相当。它是一种交互式报告工具，通常需要几个单独的查询来刷新报告页面。因此 10 秒或更长的查询响应时间会导致非常差的用户体验。
Shall we encourage our business users to use transactional facts?
有些人会直接进入最低粒度并访问所有数据而茁壮成长，所以你不应该阻止它。但大多数人不会，并且希望从更精心策划的数据视图开始。
Or creating 5 derivative aggregations and putting burden on side of Power BI team is a good approach?
这样想。无论是您 user/analysts 构建模型，还是您的 Power BI 团队，结果都是一样的。从您的 DWH 层开始，为 select 相关数据构建模型，定义有意义的度量并提供可接受的性能。该模型可能仅用于单个报告，也可能为整个部门共享。
Objective
我们正在为业务自助服务构建企业 DWH：数十 TB 的数据和大约 30 个业务用户。流程如下所示：Sources -> ETL -> DWH -> Power BI -> User。
事务粒度事实可能包含数十亿行、非附加度量和 KPI。因此，外部内存多维数据集（表格模型）或 PBI 导入模式不适合我们。同时我们有非常严格的性能要求——PBI 可视化的构建时间不应超过 15 秒。
为了性能和可用性，我们最终由 PBI 团队定义物化视图，以从每个交易事实 table（在 DWH 层）构建多个（此时不是太多）聚合衍生品。每个衍生品只是一个更聚合的事实 table 加上 pre-calculated/aggregated KPI。
问题
部分是因为治理还没有实现，可能是因为 tables 和 KPI 的数量，业务用户发现交易粒度星型模式太复杂（有时很慢），并且倾向于仅使用衍生的聚合事实进行数据探索。我感觉 transaction-grain 只会被 Power BI 团队使用，并且不能说我们将来每个交易事实 table 会有多少衍生品（这取决于，可能从 5 到 10） .
问题
我们现在采用的方法是否 = 标准（最佳实践）方法？我们应该鼓励我们的业务用户使用交易事实吗？还是创建 5 个衍生聚合并让 Power BI 团队承担负担是一个好方法？
P.S.
PBI 报告的 15 秒要求有多普遍？ 意味着当用户 select 任何切片器值时，报告应该在 < 15 秒内重新刷新. 是不是门槛太低了？
Is the approach we're doign now = a standard (best practice) approach?
是的。使用（物化）视图或在 Power BI 内存中表格模型中构建部分聚合是完全正常的。这些只是 "data marts"，它们是为特定目的和特定受众而构建的。捕获企业所有相关事实和维度属性的完全保真模型与针对特定目的或观点易于导航和回答问题的模型之间存在内在的紧张关系。
并且无法在 DWH 中真正定义度量，因为无法在最低粒度或任何中间粒度计算非附加度量。所以您确实需要表格模型来定义标准化、可重复使用的计算。
How common is the 15 seconds requirement for PBI reports?
相当。它是一种交互式报告工具，通常需要几个单独的查询来刷新报告页面。因此 10 秒或更长的查询响应时间会导致非常差的用户体验。
Shall we encourage our business users to use transactional facts?
有些人会直接进入最低粒度并访问所有数据而茁壮成长，所以你不应该阻止它。但大多数人不会，并且希望从更精心策划的数据视图开始。
Or creating 5 derivative aggregations and putting burden on side of Power BI team is a good approach?
这样想。无论是您 user/analysts 构建模型，还是您的 Power BI 团队，结果都是一样的。从您的 DWH 层开始，为 select 相关数据构建模型，定义有意义的度量并提供可接受的性能。该模型可能仅用于单个报告，也可能为整个部门共享。