我们正在为企业自助服务构建Enterprise DWH：数十TB的数据和大约30个企业用户。流程如下：Sources -> ETL -> DWH -> Power BI -> User。
交易谷物事实可能包含数十亿行，非累加度量和KPI。因此，我们无法选择使用外部内存中的多维数据集（表格模型）或PBI导入模式。同时，我们对性能有非常严格的要求-构建PBI可视化的时间不应超过15秒。
出于性能和可用性的考虑，我们最终让PBI团队定义了实例化视图，以从每个事务事实表（在DWH层）构建多个（此时不是太多）聚合派生。每个导数只是一个更汇总的事实表以及预先计算/汇总的KPI。
部分是由于尚未实施治理，也许是由于表和KPI的数量，业务用户发现事务粒度的Star Schema过于复杂（有时很慢），并且倾向于仅使用派生的汇总事实进行数据探索。 。我感觉交易粒度只能由Power BI团队使用，并且不能说将来每个交易事实表将有多少个衍生产品（取决于5到10）。
我们现在统治的方法是否是标准（最佳实践）方法？我们是否应该鼓励我们的业务用户使用交易事实？还是创建5个派生聚合并将负担放在Power BI团队的一边是一个好方法？
PBI报告的15秒要求有多普遍？表示当用户选择任何限幅器值时，应在<15秒内重新刷新报告。 阈值不是太低吗？
我们现在统治的方法是否是标准（最佳实践）方法？
是。使用（实例化）视图或在Power BI内存表格模型中构建部分聚合是完全正常的。这些只是“数据集市”，它们是为特定目的和特定受众而构建的。在捕获企业所有相关事实和维度属性的全保真模型与针对特定目的或观点的易于导航和回答问题的模型之间存在固有的张力。
而且没有办法在DWH中真正定义度量，因为不能在最低谷物或任何中间谷物上计算非累加度量。因此，您确实[[需要
表格模型来定义标准化的，可重复使用的计算。PBI报告的15秒要求有多普遍？相当。它是一种交互式报告工具，通常需要几个单独的查询才能刷新报告页面。因此，查询响应时间为10秒或更长时间会导致非常差的用户体验。
我们是否应该鼓励我们的业务用户使用交易事实？有些人会直接进入最低的层次并可以访问所有数据，因此很兴旺，因此您不应该阻止它。但是大多数人不会，并且希望从中更好地查看数据。
或者创建5个派生聚合并将负担放在Power BI团队的一边是一个好方法？以这种方式思考。无论是最终用户/分析师构建模型，还是Power BI团队，结果都是一样的。从DWH层开始，将构建一个模型来选择相关数据，定义有意义的度量并提供可接受的性能。该模型可能仅用于单个报告，或者可能被整个部门共享。