通过业务键聚合加速查询-日志服务(SLS)-阿里云帮助中心

同一业务键的日志会分散写入 LogStore 的所有 Shard，例如trace_id、session_id 这类业务键的等值查询每次都要扫描全部 Shard，数据规模越大响应越慢。业务键聚合存储（business key aggregated storage）是日志服务 SLS 提供的 LogStore 存储增强能力：按配置的业务键字段，将相同业务键或同一业务链路的数据稳定写入同一组 ShardGroup，查询时按业务键自动裁剪无关 Shard。开启后无需改变写入方式和查询语法，即可降低单次查询的扫描量，提升高频定向查询的效率。

适用范围

业务键聚合存储对地域和存储对象有以下要求，不满足时无法使用该能力。

已发布地域：当前仅 ap-southeast-8 地域支持业务键聚合存储，其他地域暂不可用。
支持的存储对象：仅 LogStore 支持业务键聚合存储。

适用场景与业务键选型

查询条件中稳定包含固定的业务键字段时，业务键聚合存储可以显著减少查询需要扫描的 Shard 数量。命中裁剪的前提是查询条件同时包含全部业务键字段的等值匹配，因此配置两个字段的组合时，只带其中一个字段的查询会回退为全 Shard 扫描，完整规则参见查询加速的命中与回退条件。

下表列出典型场景与推荐的业务键组合。其中“+”表示将两个字段同时配置为一组业务键，“、”分隔的是可选其一的多个候选，每组业务键最多包含 2 个字段。

场景	推荐业务键	用户价值
Trace 链路排障	`trace_id`、`service` + `trace_id`	查询某条调用链时减少 Shard 扫描范围，提升链路日志检索速度。
Agent 应用观测	`trace_id`、`agent_run_id`、`session_id`	将一次 Agent Run 的模型调用、工具调用、检索、记忆和异常事件聚集存储，提升 Trace 查询效率。
用户会话分析	`tenant_id` + `session_id`、`tenant_id` + `user_id`	快速查询某个用户或某次会话的完整行为日志。
订单或交易排障	`tenant_id` + `order_id`、`transaction_id`	快速定位订单异常、支付失败、交易链路问题。
主机或客户端访问日志	`__source__` + `remote_addr`、`host`	聚集同一来源、客户端或域名的访问日志，便于排障。
IoT 或设备日志	`tenant_id` + `device_id`	快速查询单个设备的运行、告警和连接日志。
安全审计或攻击溯源	`src_ip`、`account_id`、`ak_id`、`user_id`	针对某个 IP、账号、密钥或用户追踪行为日志。

收益有限或需先评估的场景

以下场景开启业务键聚合存储的收益有限，或者可能带来写入热点。开启前需从三个维度评估：查询条件是否稳定包含业务键字段、业务键字段值的分布是否集中、业务键字段在日志中的覆盖率。

场景	原因
查询条件很少包含固定业务键	查询时无法按业务键裁剪 Shard，收益有限。
业务键倾斜严重	同一业务键值的日志固定写入同一个 ShardGroup，该键值的日志占比即该 ShardGroup 的写入占比，因此字段值的分布频率差异过大会导致写入倾斜。例如单个 `user_id` 的日志量占总日志量超过 20%，则约 20% 的日志会集中写入同一个 ShardGroup。
业务键字段缺失率较高	字段不存在或字段值为空时按空字符串参与 hash 计算，这些日志会集中写入同一个 ShardGroup，造成写入倾斜，同时聚集效果不明显。
可写 Shard 数量过少	每个 ShardGroup 内的可写 Shard 过少，容灾能力有限。可写 Shard 数量的取值口径参见“规划 ShardGroup 数量”。

使用限制

业务键字段最少配置 1 个，最多配置 2 个。
字段顺序参与路由计算，调整字段顺序视为策略变更。
字段不存在或字段值为空时，按空字符串参与 hash 计算。
ShardGroup 数量必须为 2 的幂，例如 4、8、16、32、64。
修改策略后，新策略会在短暂延迟后生效；查询策略变更之前的历史时间段时，可能回退为全 Shard 扫描。

规划 ShardGroup 数量

ShardGroup 数量决定查询裁剪的粒度：分组越多，单次查询扫描的 Shard 越少，但每个分组内的可写 Shard 也越少，容灾能力和抗热点能力随之下降。可写 Shard 数量与 ShardGroup 数量按以下口径规划：

建议至少 8 个可写 Shard，使每个 ShardGroup 保留 2 个左右的可写 Shard，具备较好的容灾能力。
4 个可写 Shard 也可以开启，但每个 ShardGroup 仅约 1 个可写 Shard，容灾能力有限。
控制台根据当前 LogStore 的可写 Shard 数量给出推荐值，用于在查询裁剪效果、容灾能力和热点风险之间取得平衡。

当前可写 Shard 数	推荐 ShardGroup 数	说明
4	4	每组约 1 个可写 Shard，查询可以裁剪，但容灾能力有限。
8	4	每组约 2 个可写 Shard，适合开始使用。
16	4 或 8	可根据查询加速需求选择。
32	8 或 16	适合高频定向查询场景。
64	16 或 32	适合大规模点查、链路排障和会话分析。

推荐值给出两个取值时，取较大值裁剪更细，取较小值则每个 ShardGroup 保留的可写 Shard 更多。

配置业务键聚合存储

新建 LogStore 时可以直接开启业务键聚合存储；对已有 LogStore，则在 LogStore 属性页面开启、修改或关闭。两种方式配置的业务键字段和 ShardGroup 数量含义完全一致。

配置前需完成以下准备：

已在管理Project 中完成 Project 创建，并已按管理LogStore 创建目标 LogStore。
已规划用于聚合的业务键字段，例如 trace_id、session_id、user_id、order_id。字段需要在日志中稳定存在、常用于查询过滤，且区分度较高。
目标 LogStore 具有足够的可写 Shard 数量，取值口径参见“规划 ShardGroup 数量”。当前可写 Shard 数量可以通过管理Shard 描述的 Shard 管理入口查看和调整。

创建 LogStore 时开启

登录日志服务控制台。
在 Project 列表区域，单击目标 Project。
在日志存储 > 日志库页签中，单击 + 图标。
在创建 LogStore 页面，找到业务键聚合存储配置项。
打开业务键聚合存储开关，配置业务键字段和分片分组（ShardGroup）数量。ShardGroup 数量建议单击使用推荐值，由控制台根据当前可写 Shard 数量给出，取值依据参见“规划 ShardGroup 数量”。
单击确定。

修改已有 LogStore 的配置

登录日志服务控制台。
在 Project 列表区域，单击目标 Project。
在日志存储 > 日志库页签中，将鼠标悬浮在目标 LogStore 上，选择修改。
在 LogStore 属性页面左侧导航栏，单击业务键聚合存储。
尚未开启时，打开业务键聚合存储开关并配置业务键字段和分片分组（ShardGroup）数量；已开启时，按需修改业务键字段（包括字段顺序）或分片分组（ShardGroup）数量。
单击保存。

说明

修改业务键字段、字段顺序或 ShardGroup 数量属于策略变更，仅对变更生效后新写入的数据生效，历史数据不会重新分布。

关闭业务键聚合存储

关闭业务键聚合存储后，后续新写入的数据不再按业务键聚合，按业务键的查询裁剪随之失效。已写入的历史数据仍保留在原有 Shard 中，不会被自动迁移或重新分布，因此关闭操作不会造成数据丢失，也不会触发数据重写。

登录日志服务控制台，在 Project 列表区域单击目标 Project。
在日志存储 > 日志库页签中，将鼠标悬浮在目标 LogStore 上，选择修改，进入 LogStore 属性页面。
在左侧导航栏，单击业务键聚合存储。
关闭业务键聚合存储开关。
单击保存。

参数说明

创建 LogStore 和修改 LogStore 属性时，业务键聚合存储相关配置项的含义如下。

参数	说明
业务键聚合存储	是否开启业务键聚合存储。开启后，日志服务按业务键将相关日志写入同一组 ShardGroup。
业务键字段	用于决定日志落入哪个 ShardGroup 的字段，最少 1 个，最多 2 个。字段顺序参与路由计算。
分片分组（ShardGroup）数量	用于业务键聚合的逻辑分组数量。必须为 2 的幂，建议使用系统推荐值。
使用推荐值	根据当前可写 Shard 数自动计算并填入推荐的 ShardGroup 数量。
Shard 分片数据均衡状态	展示当前 LogStore 的 Shard 数据范围是否均衡，用于判断是否需要执行数据 Rerange。
数据 Rerange	重新分配 Shard 数据范围，改善 Shard 数据范围不均衡问题。执行前需确认业务侧是否已通过 SDK 指定 Hash 写入。

查询加速的命中与回退条件

开启业务键聚合存储后，如果查询条件包含全部业务键字段的等值匹配，日志服务会根据业务键计算出目标 ShardGroup，只扫描该分组对应的 Shard，而不是扫描 LogStore 的全部 Shard，从而减少参与计算的数据规模。例如业务键配置为 tenant_id 和 agent_run_id 两个字段，查询条件为：

tenant_id = 'tenant-a' AND agent_run_id = 'run-001'

此时日志服务可以定位到唯一的目标 ShardGroup，仅扫描该分组内的数据。以下情况无法命中业务键聚合存储，查询会回退为全 Shard 扫描：

查询条件缺少任一业务键字段。
业务键字段不是等值匹配，例如模糊查询、范围查询或正则查询。
查询时间范围跨越策略变更时间，无法按单一策略裁剪。
查询表达式无法确定唯一的业务键值。
当前 LogStore 未开启业务键聚合存储。

计费说明

业务键聚合存储本身不改变 LogStore 的计费模式，开启后日志的写入、存储、查询和分析费用仍按当前 LogStore 的计费模式收取。

如果查询命中业务键裁剪，扫描的数据量和查询耗时会下降，相关的查询分析费用也可能随之降低。实际效果取决于查询条件是否包含完整业务键、ShardGroup 数量配置、数据分布以及查询的时间范围。

常见问题

为什么开启后查询没有明显变快？

首先按查询加速的命中与回退条件核对查询是否命中裁剪，重点确认查询条件是否包含全部业务键字段的等值匹配、查询时间范围是否包含策略生效之前的数据。若查询本身满足命中条件，则排查两类数据侧原因：日志中业务键字段的缺失率较高，聚集效果不明显；ShardGroup 数量过少，扫描裁剪比例有限。

什么情况下需要数据 Rerange？

当Shard 分片数据均衡状态显示 Shard 数据范围不均衡时，可以考虑执行数据 Rerange。执行前需确认业务侧是否通过 SDK 等方式指定了 Hash 写入：如果业务侧持续指定 Hash 写入，Rerange 之后仍可能继续产生热点。