缓存策略（热缓存和冷缓存）

Azure 数据资源管理器使用多层数据缓存系统以确保快速查询性能。数据存储在可靠的存储（例如，Azure Blob 存储）中，但部分数据存储在处理节点、SSD 甚至 RAM 上，以便更快地访问。

实时分析使用多层数据缓存系统来确保快速查询性能。数据存储在可靠的存储空间（例如，OneLake）中，但部分数据缓存在处理节点、SSD 甚至 RAM 上，以方便更快地进行访问。

通过缓存策略，可以选择应缓存哪些数据。可以通过对热数据设置缓存策略来区分热数据缓存和冷数据缓存。热数据保存在本地 SSD 存储中，以实现更快的查询性能，冷数据存储在可靠存储中，这更便宜，但访问速度较慢。

缓存将 95% 的本地 SSD 磁盘用于热数据。如果空间不足，最新数据优先保存在缓存中。其余 5% 用于未分类为热的数据。此设计可确保加载大量冷数据的查询不会从缓存中逐出热数据。

当所有引入数据缓存后，可以获得最佳查询性能。但是，某些数据可能不值得保留在热缓存中。例如，不经常访问的旧日志记录可能被认为不太重要。在这种情况下，团队通常会选择较低的查询性能，而不是付费以保持数据温暖。

使用管理命令在数据库、表或具体化视图级别更改缓存策略。

使用管理命令更改群集、数据库、表或具体化视图级别的缓存策略。

提示

群集专为临时查询而设计，中间结果集适合群集的总 RAM。对于 map-reduce 等大型作业，将中间结果存储在持久性存储中可能很有用。为此，请创建连续导出作业。此功能使你可以使用 HDInsight 或 Azure Databricks 等服务执行长时间运行的批处理查询。

如何应用缓存策略

引入数据时，系统将跟踪引入的日期和时间以及创建的盘区。盘区的引入日期和时间值（如果盘区是从多个预先存在的盘区中构建的，则为最大值）用于计算缓存策略。

注意

可以使用引入属性 creationTime 来指定引入日期和时间的值。这样做时，请确保表的有效盘区合并策略中的 Lookback 属性与你为 creationTime 设置的值一致。

默认情况下，有效策略为 null，这意味着所有数据都被视为热数据。表级别的 null 策略意味着该策略将从数据库继承。非 null 表级别的策略会重写数据库级别的策略。

运行查询时，可以将范围限制为仅查询热缓存中的数据。

注意

数据范围设置仅适用于支持缓存策略的实体，例如表和具体化视图。对于其他实体（例如外部表和行存储中的数据），它会被忽略。

以下为几种可能的查询：

default 值指示使用群集默认设置，该设置决定查询应涵盖所有数据。

如果不同的方法之间存在差异，set 则优先于客户端请求属性。为表引用指定值要优先于两者。

例如，在下面的查询中，所有表格引用都将仅使用热缓存数据，但对“T”的第二个引用除外，该引用的范围是所有数据：

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

缓存策略独立于保留策略：

根据预期的查询模式，配置此策略以在成本和性能之间实现最佳平衡。

示例：

在此示例中，最后 28 天的数据将位于群集 SSD 上，另外 28 天的数据将存储在 Azure Blob 存储中。你可以对全部 56 天的数据运行查询。