搞不清全量刷新、增量刷新、子范围刷新的区别？这三种方式听起来相似，背后的机制和适用场景却完全不同。本文讲清机制：数据怎么落地、刷新时动了多少数据、各自补不了哪块短板。
本文是「机制原理篇」，讲清楚三种刷新方式在做什么。如果你要的是在 Desktop 与 Server 上一步步配出来的操作手册，请看姊妹篇 《Tableau Server 服务器增量提取详解》 。
本文依据 Tableau 官方「刷新数据提取」文档撰写，覆盖 2024.1 的非唯一键列支持与 2024.2 新增的子范围刷新。
本文要点 ① 实时连接每次查库，全量提取整表复制，增量提取只加新行 ② 全量刷新是「替换」，增量刷新是「追加」，增量标识列决定水位线在哪 ③ 增量刷新只认标识列有没有变大，历史行的修改它一概看不见 ④ 子范围刷新（2024.2+）在追加新行的同时，把最近一段时间重抽一遍 ⑤ 配置的 N 天是「下限」不是「上限」；单位选「天」比选「月」可控 ⑥ 选型依据只有一个：源端会不会改历史数据，以及改动能追溯到多久以前 ⑦ 子范围刷新的时间窗口按 UTC 计算，北京时间下会缺约 8 小时（官方确认为设计使然，非 bug）
一、先分清：三种数据连接方式
理解刷新的前提，是理解数据存在哪里。
- 实时连接：每次交互都向源库发一次查询，本地不保存任何副本。数据始终与源端一致，但性能系于源库和网络，并发高时会拖慢源系统。适合数据量小或需要实时决策的场景。
- 全量提取：把整表复制到本地
.hyper文件，作为离线快照。断开源库也能分析，但每次刷新都要重下全部数据，成本与数据量成正比。 - 增量提取：只把新增的行复制进已有的
.hyper。速度最快、源库负载最低，代价是抓不到历史行的改动。
一句话区分：实时连接 = 每次查库；全量提取 = 整表复制；增量提取 = 只加新行。
后两者都会落地成 .hyper 文件，真正的差别只在「刷新时下载多少数据」。
二、全量刷新 vs 增量刷新：替换与追加
这是最容易混淆的一组概念，用一个动作就能分清：
- 全量刷新（Full Refresh） 的逻辑是「替换」。每次刷新先清空整个
.hyper，再从源端重读全部行。即使某行一字未改，也要重新下载一遍。好处是与源端 100% 一致，代价是全表扫描。 - 增量刷新（Incremental Refresh） 的逻辑是「追加」。保留已有行，只追加标识列大于水位线的新行。秒级完成，但已有行一个都不碰。
根本差异：全量刷新动的是「整个文件」，增量刷新动的是「文件末尾新加的一段」。
三、增量标识列：水位线定在哪
增量标识列是增量刷新的指南针。Tableau 记录上次提取时该列的最高值（水位线），下次只取超过这条线的行。
官方界面中这一项叫「使用列标识新行」，要求是随写入单调递增的列：
- 日期 / 时间戳（如
created_at） - 自增 ID（如
order_id）
唯一键列与非唯一键列
两者的处理方式不同，这是 2024.1 引入的变化：
- 唯一键列（自增 ID）：每行取值唯一。刷新时取「标识列 > 水位线」的行，边界清晰，不重复也不遗漏。
- 非唯一键列（日期时间）：同一时刻可以有多行。2024.1 起 Tableau 增加了一个步骤——先删除提取中等于最高值的行，再查询大于等于最高值的所有行。这样同一时刻迟到写入的记录才不会被漏掉。
关键限制
增量刷新只认「标识列有没有变大」，其他字段的变化它一概看不见。
源端把历史行的订单状态从「待付款」改成「已付款」，标识列没变，增量刷新永远不会更新这一行。这不是缺陷，是设计的取舍——正因为补不上这块短板，才有了子范围刷新。
四、子范围刷新：补上历史修改这块短板
子范围刷新（Sub-range Refresh） 是 Tableau 2024.2 引入的功能，通过「要刷新的最小日期范围」字段配置。它在增量刷新的基础上，额外指定一段时间范围，把这段范围内的已有数据删除并重新提取，从而捕获可能发生的任何历史修改。
前提：子范围刷新只对「日期」或「日期时间」类型的标识列开放。如果标识列用的是自增 ID，这个字段不会出现——这时要抓历史修改，只能回到定期全量刷新。
4.1 一次刷新实际做了三步
- 第一步：按标识列取水位线之后的所有新行，追加到提取末尾。
- 第二步：删除最近 N 天的已有行，再从源端整段重新读取。
- 第三步：合并——历史（范围外）＋ 重抽段（范围内）＋ 纯新行。
注意它并不是「只刷子范围」，而是增量追加与子范围重抽两步叠加。
4.2 时间范围怎么解释：选「天」比选「月」可控
配置时填一个数字加一个单位。Tableau 的解释方式是：当前时间单位已过的部分 ＋ 前 N 个完整的单位。
- 设为「3 个月」，4 月 1 日刷新：提取 4 月已过的 1 天 ＋ 前 3 个整月，约 91 天。
- 设为「3 个月」，4 月 28 日刷新：提取 4 月已过的 28 天 ＋ 前 3 个整月，约 118 天。
同一个配置，实际跨度在 91 ~ 118 天之间漂移。因此官方的最佳实践是：使用对你有意义的最小适用时间单位。想稳定覆盖「刷新日 ＋ 前 90 天」，就填 90 ＋ 天，而不是 3 ＋ 月。
4.3 时区：只按 UTC 计算，北京时间会缺约 8 小时
这是一个文档里不会写明、却很容易踩的坑。
子范围刷新的时间窗口，目前是按 UTC（协调世界时）计算的。如果标识列与业务口径使用的是北京时间（UTC＋8），实际重抽的区间会比预期晚 8 小时，表现为约 8 小时的数据覆盖不到。这一点已由笔者实测确认，并与 Tableau 官方确认过：官方不将其视为缺陷（bug），而是当前版本的设计使然。
实践中的两种应对方式：
- 放宽天数来吸收偏差：需要覆盖 90 天时，配置得略多一些（例如 91 天及以上），用多出来的余量抵消这 8 小时的错位。
- 源端统一转成 UTC：在 SQL 或 ETL 环节把标识列的时间统一转为 UTC 存储，让口径与 Tableau 的计算基准保持一致，从根上避免偏差。
如果刷新窗口卡得很紧（要求小时级的精确覆盖），建议先在测试环境用真实数据验证一次，再放到生产环境。
4.4 配置的 N 天是下限，不是上限
如果源端待更新的新数据比配置的 N 天更多，Tableau 会一路回溯到「有新数据的起点」全部取回，再叠加配置的 N 天重抽范围。
举例：子范围只配了 2 天，但上次刷新发生在 10 天前——本次会提取 10 天全新数据 ＋ 额外 2 天的重抽范围，共 12 天。
4.5 两个必须记住的前提
- 源表结构一旦变更（例如新增一列），必须先执行一次完全刷新，之后才能重新开始增量刷新。否则新列不会进入
.hyper。 - 标识列若包含未来日期（例如「计划交货日期」），子范围刷新的结果可能与预期不符。官方建议基于「记录写入时刻」的日期时间字段做提取。
五、怎么选：一个判断就能定下来
- 只追加、不修改（日志、交易流水、传感器数据）→ 纯增量刷新，最快最轻量。
- 追加为主，偶有回溯修改（订单管理、审批流程）→ 增量 + 子范围，推荐配置为 90 ＋ 天。
- 改动可能落在任意历史时点（CRM、客户主数据）→ 每日增量 + 定期全量，例如每日增量、每周日全量。
三条路共用一个前置条件：源表结构变更后必须先跑一次完全刷新。
六、术语速查
- 数据提取（Extract）：把源库中的数据复制一份到本地
.hyper文件，作为离线快照。 - 全量刷新（Full Refresh）：删除整个提取，重新从源库下载全部数据。
- 增量刷新（Incremental Refresh）：只把新增的行追加到提取中，已有行不动。
- 增量标识列：判断哪些行是新数据的列，要求随写入单调递增。官方界面称为「使用列标识新行」。
- 非唯一键列：同一取值可对应多行（典型是日期）。2024.1 起支持，配套「高级设置」选项。
- 子范围刷新（Sub-range Refresh）：2024.2 起支持。在增量刷新基础上，额外删除并重抽最近一段时间的已有数据。官方界面称为「要刷新的最小日期范围」。
- Hyper 文件：Tableau 新一代提取格式。2024.2 是可以打开旧版
.tde的最后一个版本，之后一律为.hyper。
附：配置侧的约束
机制之外，增量刷新还有几条硬性约束，在 Desktop 与 Server 上的具体操作与踩坑，见姊妹篇 《Tableau Server 服务器增量提取详解》 ：
- 「行数」必须选所有行，样本提取不能做增量刷新
- 启用聚合后，增量刷新不可用
- 子范围刷新只对日期或日期时间类型的标识列开放，自增 ID 用不了
- 子范围刷新的时间窗口按 UTC 计算；标识列若为北京时间，需放宽天数或在源端统一转 UTC
- 设置了「要刷新的最小日期范围」后，「高级设置」不再可用——两者互斥
No comments yet