Article body
正文
经营看板需要快速打开，关键指标又要反映业务变化。团队如果只追求缓存命中率，容易忽略结果对应的数据时间；如果每次都重新扫描源库，也可能让重复分析持续消耗资源。
衡石把图表数据缓存、数据集加速与数据更新作为可配置的分析能力交给企业。 项目可以根据业务时效要求选择查询路径，再由数据团队维护更新计划与指标口径。理解这些能力各自的作用，比笼统地说“开启缓存就能提速”更有助于交付。
先区分三个对象：图表缓存保存查询结果，加速引擎承载已处理的数据，历史问答记录保存过去的分析内容。它们的更新条件不同，不能把其中一种机制推广到整条 ChatBI 链路。
一、衡石有哪些可用的加速与刷新手段
| 机制 | 衡石提供的能力 | 使用时要明确的边界 |
|---|---|---|
| 图表数据缓存 | 应用可设置图表数据缓存周期；未单独设置时沿用系统配置。 | 确认该图表的实际周期及查询条件，不把它当成整段问答的答案缓存。 |
| 图表刷新 | 刷新操作可绕过图表缓存，重新发起数据查询。 | 数据若来自加速引擎，查询到的仍是该引擎中的数据，未必是源库最新记录。 |
| 数据集加速 | 将数据集处理结果放入所用加速引擎，减少后续重复执行复杂加工的工作。 | 需要同时规划数据更新，确认加速后的数据范围和授权配置。 |
| 数据更新管理 | 对导入引擎的数据集进行立即更新或设置更新计划，并检查更新状态和记录。 | 源库变化、引擎更新和页面取数是不同环节，要分别确认。 |
公开应用设置手册列示的图表缓存默认周期是3600秒，即1小时 ，并支持应用级配置。实际部署可能已有调整，项目应检查生效值。刷新与加速的使用方式，可分别查看应用设置、图表操作和性能使用指引。
二、让数据时效沿着实际路径得到验证
“源库已经更新”和“用户已经看到新数据”之间，可能还隔着同步计划、加速引擎中的数据以及图表缓存。管理员应先确认这次分析实际读的是哪一层，再决定要执行什么操作。
| 变化或诉求 | 应核查的环节 | 不能混淆的操作 |
|---|---|---|
| 源库增加了新的业务记录 | 数据集是否导入引擎，相关更新任务是否成功，图表是否重新查询。 | 只刷新图表，不一定会先更新引擎数据。 |
| 源表字段名称或类型变化 | 数据集结构及依赖它的字段、指标与图表。 | 更新 schema 用于同步结构信息，不等于所有业务数据已刷新。 |
| 指标计算规则发生变化 | 指标定义、使用它的分析对象与实际查询结果。 | 需要重新核对结果，不能只等待缓存周期结束。 |
| 用户授权或组织范围变化 | 当前身份、资源授权、数据权限模式与访问结果。 | 之前返回过某个结果，不代表该身份以后仍可查看。 |
衡石的数据集更新功能支持查看状态、记录与最近更新情况，并为相关数据集配置更新计划。团队可以把更新完成情况纳入日常巡检，再以同条件查询检查新数据是否进入分析结果。具体更新方式与支持范围应按数据集类型确认。
历史消息中的数字也需要按它生成时的条件理解。用于经营决策时，应重新查询关键指标，检查数据批次与时间范围。不能把再次打开一条旧回答视为已经执行了新查询。
三、先维护业务语义，再判断结果能否复用
“本月销售额”“本月营收”看起来相近，在企业里却可能对应不同规则：是否含税、如何处理退款、按下单还是确认收入统计。团队应先确认这些术语是否真的指向同一指标，再讨论重复计算与复用。
衡石的指标和 HQL 分析能力为维护这些定义提供了对象。Data Agent 可以结合数据集知识和业务语境寻找相关资源，数据团队则能够回到指标与查询核对结果。复用的前提还包括一致的数据范围、筛选条件、统计时间及有效授权。
如果企业在自己的集成层增加结果缓存，还应把租户、执行身份、权限变化和数据版本纳入设计。这里讨论的是集成建议，不代表衡石对外公开了某一种统一缓存键格式，也不代表可以绕过正常的数据授权链路。
四、按业务选择实时性与计算成本
| 业务需求 | 可考虑的实施方式 | 业务负责人需要确认 |
|---|---|---|
| 稳定历史期间的经营复盘 | 维护经过核对的数据批次，并设置适合重复访问的缓存周期。 | 历史期间是否仍会补录、冲销或调整，调整后如何重算。 |
| 按日更新的销售分析 | 将数据更新计划与业务结算节奏衔接，再安排看板查询。 | 数据截止时间、最近成功更新记录与失败处理。 |
| 需要读取最新变化的库存等分析 | 在源库承载能力允许时评估直连；如使用同步或引擎，明确更新延迟。 | 可以接受的延迟，以及峰值查询对源系统的影响。 |
| 复杂跨源分析 | 先进行数据整合或固化部分复杂加工，再配置后续分析。 | 更新节奏、计算口径与数据权限是否匹配。 |
这些选择需要把速度与时效一起测试。开启加速引擎后，应检查同步后的结果；走直连查询时，也要观察源库负载。衡石公开性能 FAQ 对两类路径的取舍有进一步说明。
五、一个零售经营分析的实施示例
以下为虚拟方案示例，不代表真实客户案例或实测效果。 零售企业希望各区域在早会上查看前一日销售表现，同时让运营人员查询当天退款变化。两类问题的数据时效要求不同，不宜使用同一套更新假设。
项目组先由财务确认销售与退款指标的统计规则，再为前一日经营看板配置数据更新和缓存周期。每天查看更新任务是否完成，并用固定门店与期间对账。对当天退款分析，则单独评估查询路径与可接受延迟，明确查询时的数据截止点。
区域负责人和总部用户使用各自身份验收，分别检查可见门店与指标结果。这样既能复用衡石已有的指标、图表和数据更新能力，也能把不同业务场景的时效要求落实到配置和验证中。
六、上线前验证变化后的结果
- 数据变化： 追加、修正或删除测试记录，检查相关更新流程和新查询结果。
- 口径变化： 修改测试指标后，核对引用它的看板与问法，不假定所有历史回答自动更新。
- 权限变化： 切换角色或收回授权，检查正常入口及外部集成是否仍遵守访问边界。
- 冷热对照： 分别记录首次与重复查询表现、刷新行为和数据截止时间，避免只展示有利的一次。
衡石的缓存与加速能力，为企业提供了控制重复计算和组织数据更新的手段。项目团队把指标口径、数据批次、查询路径与用户身份同时管好，才能让更快的分析结果持续用于经营。