导入建模的数据缩减方法

本文面向开发和发布 Power BI 语义模型的 Power BI Desktop 数据建模者。 具体而言，它描述了各种技术，以帮助减少加载到 导入模型中的数据。

导入模型装载了经过压缩和优化的数据，然后由 VertiPaq 存储引擎存储到磁盘上。 将源数据加载到内存中时，可以实现 10 倍压缩，因此可以合理地期望 10 GB 的源数据可以压缩到大约 1 GB 的大小。 此外，保存到磁盘上时，还可以再缩减 20%。

尽管 VertiPaq 存储引擎实现了效率，但应尽量减少加载到模型中的数据。 尤其是对于大型模型，或那些预计会随着时间的推移而变大的模型。 以下是四个令人信服的原因：

• 容量可能不支持更大的模型大小。 共享容量可以承载最多 1 GB 大小的模型，而高级容量可以承载更大的模型，具体取决于 SKU。 有关详细信息，请参阅 Power BI Premium 中的大型语义模型。
• 较小型的模型可以减少对容量资源（尤其是内存）的争用。 容量中的许多较小模型可以同时加载更长的时间，从而导致较低的逐出率。
• 较小的模型大小可实现更快的数据刷新，从而降低延迟报告、更高的语义模型刷新吞吐量，以及源系统和容量资源的压力较小。
• 较小的表行计数可能会导致更快的计算评估，从而提高整体查询性能。

删除不必要的列

模型表列有以下两个主要用途：

• 报告，以实现适当筛选、分组和汇总模型数据的报表设计。
• 模型结构，通过支持模型关系、模型计算、安全角色，甚至数据颜色格式设置。

你可能可以删除任何不用于这些目的的列。 从表中删除列有时称为 垂直筛选。

建议根据已知的报告要求，设计列数量恰如其分的模型。 你的要求可能会随时间而变化，但请记住，添加列比以后删除列要容易得多。 删除列可能会破坏报表或模型结构。

删除不必要的行

您应该将模型表加载的行数尽可能减少。 可以通过将筛选的行集加载到模型表中来实现这一点，原因有两个不同的原因：按时间或实体进行筛选。 删除行有时称为 水平筛选。

• 按时间筛选涉及限制加载到事实数据表的数据历史记录量（以及限制加载到模型日期表中的日期行）。 建议默认不加载所有可用历史记录，除非它是已知的报告要求。 可以使用参数实现基于时间的 Power Query 筛选器，甚至将其设置为使用相对时间段（相对于刷新日期，例如过去五年）。 此外，请记住，对时间筛选器的回顾性更改不会中断报表;它只会在报表中生成更少的（或更多）数据历史记录。
• 按实体筛选需要将一部分源数据加载到模型中。 例如，不加载所有销售区域的销售情况，而只加载单个区域的销售情况。 此设计方法会导致许多较小的模型，并且还无需定义 行级别安全性（RLS），但需要在 Power BI 服务中授予特定的语义模型权限，并创建连接到每个语义模型的重复报表。 可以使用 Power Query 参数和 Power BI 模板文件简化管理和发布。 有关详细信息，请参阅 Power BI Desktop 中的“创建和使用报表模板”。

分组依据和汇总

缩减模型大小的最有效方法可能是加载预汇总数据。 可以使用此方法来提升事实数据表的粒度。 但它有明显的取舍，即细节丢失。

假设源销售事实数据表为每个订单行存储一行。 可以通过汇总所有销售指标、按日期、客户和产品分组来实现显著的数据减少。 可以通过 按月份级别的日期分组来实现更显著的数据减少。 虽然它可以实现模型大小的可能减少 99%，但无法再报告日级别或单个订单行级别。 决定汇总事实数据总是涉及权衡。 可通过模型设计来缓解权衡，该模型设计包含 DirectQuery 存储模式下的某些表，本文 稍后 将对此进行了介绍。

优化列数据类型

VertiPaq 存储引擎为每个列使用单独的内部数据结构。 根据设计，这些数据结构可实现数值列数据的最高优化，该数据结构使用 值编码。 但是，文本和其他非数值数据使用 哈希编码。 哈希编码要求存储引擎将数字标识符分配给列中包含的每个唯一值。 然后，它是存储在数据结构中的数字标识符，需要在存储和查询期间进行哈希查找。

在某些特定实例中，可以将源文本数据转换为数值。 例如，销售订单编号可能以文本值（例如 SO123456）为前缀一致。 在这种情况下，可以删除前缀 SO ，并将订单号值转换为整数。 对于大型表，此修改可能会导致大幅减少数据，尤其是在列包含唯一值或高基数值时。

在此示例中，建议将列默认摘要属性设置为 Do Not Summarize。 这有助于避免对订单号值进行不适当的汇总。

自定义列的首选项

VertiPaq 存储引擎存储模型 计算列 ，定义在 DAX 中，就像常规 Power Query 源列一样。 但是，内部数据结构存储方式略有不同，通常实现效率较低的压缩。 此外，所有 Power Query 表加载后都会生成数据结构，这可能会导致数据刷新时间延长。 因此，相较于以 Power Query computed 列（在 M 中定义）形式添加表列，以 calculated 列形式添加效率更低。

尽可能选择在 Power Query 中创建自定义列。 当源是数据库时，可以通过两种方式实现更大的负载效率：可以在 SQL 语句（使用提供程序的本机查询语言）中定义计算，也可以具体化为数据源中的列。

但是，在某些情况下，模型计算列可能是更好的选择。 当公式涉及评估度量值时，或者它只需要 DAX 函数中支持的特定建模功能时，情况就如此。 有关此类示例的信息，请参阅 DAX中关于父子层次结构的功能解析。

禁用 Power Query 查询负载

不应将用于支持与其他查询的数据集成的 Power Query 查询加载到模型。 为了避免将这些查询加载到模型，请确保在这些实例中禁用查询加载。

禁用自动日期/时间

Power BI Desktop 包含一个称为“自动日期/时间”的选项。 启用后，它会为模型中每个日期列创建隐藏的自动日期/时间表。 此选项支持报表作者在为日历时间段配置筛选器、分组和钻取操作时使用。 隐藏表实际上是增加模型大小的计算表。

有关详细信息，请参阅 Power BI Desktop 中的自动日期/时间指南。

使用 DirectQuery 存储模式

DirectQuery 存储模式是导入存储模式的替代方法。 DirectQuery 模型表不导入数据。 相反，它们只包含定义表结构的元数据。 在查询数据表时，使用原生查询从基础数据源检索数据。 在单个模型中合并 Import 和 DirectQuery 存储模式表时，称为 复合模型。

降低模型大小的一种有效方法是将大型事实数据表的存储模式设置为 DirectQuery。 请考虑这种设计方法通常能很好地与之前介绍过的按组汇总技术配合使用。 例如，汇总的销售数据可用于实现高性能摘要报告。 钻取页可以显示特定的（且狭窄的）筛选器上下文下的详细销售数据，并显示所有相关的销售订单。 在此示例中，钻取页可以包含基于 DirectQuery 模型表的可视化元素，以检索销售订单数据。

但是，涉及到 DirectQuery 存储模式和复合模型的许多安全性和性能问题。 有关详细信息，请参阅 Power BI Desktop 中的“使用复合模型”。

相关内容

有关本文的详细信息，请查看以下文章：

• Power BI 服务中的语义模型模式
• Power BI Desktop 中的存储模式
• 是否有任何问题? 尝试咨询 Fabric 社区
• 有建议？ 提供改进 Fabric 的想法