一、先说句实话

增量更新失败这种事，基本每个用 Tableau Prep 的人都躲不过。头一天流程还跑得好好的，第二天一刷新，结果不是空数据就是重复数据，有时候干脆报错，把人搞得一头雾水。很多人第一反应是怀疑数据源出了问题，翻来覆去查了一遍又一遍，最后才发现，问题其实出在当初设置的那个“增量规则”身上。说白了，规则被时间或者变化的数据源给悄悄带偏了。别慌，这篇文章不扯高深理论，就用大白话把这件事讲透，带着你一步步把那个失灵的规则修回来，同时再教你怎么防范于未然。

二、增量更新到底是怎么回事

2.1 增量更新就像“只吃新饭”

你想象一下，每天家里都会做新饭，你只需要把今天新做的那一碗吃掉，不需要把昨天、前天甚至上个月的剩饭都热一遍。Tableau Prep 的增量更新就是这个道理。它会在自己脑子里记一个“上次吃到哪”，然后下次开动的时候，只从那个位置往后的新菜开始夹。这样，几十万条历史数据不用每次全量读一遍，每次只要看一看“有哪些是新增的”，效率自然高很多。

但这里有个非常关键的前提：这个“记忆”并不是凭空存在的，它完全取决于你在流程里写了什么样的规则。规则写得好，它就像装了导航一样，每次都能精准找到新数据；规则写得稀里糊涂，它就成了路痴，要么在老数据里原地打转，要么连新数据也漏个精光。

2.2 失败的时候会看到什么

我们先来认一下失败现场。假如你遇到了下面这几种情况，基本都是增量规则在作妖：

第一种，流程跑完了，但输出结果里一个数据都没有。这通常是规则把新数据全过滤掉了，比如你写了一个“等于今天”的条件，结果今天的数据还没生成，自然什么都捞不到。

第二种，流程跑完了，但数据明显重复了，昨天已经处理过的数据又出现了一遍。这种是过滤条件太宽松，旧数据没有被拦住。

第三种，流程直接报错，说什么“类型不匹配”或者“无法比较”。这种情况多半是字段类型变了，你还在拿原来的方式去做判断，两个东西根本不是一种类型，比都没法比。

遇到这些情况，别急着把整个流程删了重做。先深吸一口气，去把增量规则翻出来，八成病根就在那儿。

三、最坑的几个失败原因

3.1 上次刷新的“记忆点”丢了

很多小白一开始图省事，直接在筛选器里写一个“订单日期等于今天”的条件。看起来没毛病，但仔细想想，“今天”是个会漂移的值。如果你当天忘了跑，第二天再跑的时候，昨天的数据就永远也捞不回来了。更离谱的是，如果上游数据生产得晚，你白天跑流程时它还没生成，那跑出来也是空手而归。这种规则根本算不上增量，它只是拿当前时间硬碰运气。

正确的做法应该是记一个“上次处理到哪一天”的固定点，然后从这个点往后取所有比它新的数据。这个点不会漂移，跑一次就往前挪一次，稳得很。

3.2 日期字段类型对不上

在 Excel 里看到的是日期，到了数据库里却变成了一串文字，或者反过来。这样一搞，你写的“大于某一天”就会失效。因为文字和日期的比较规则完全不一样。文字会按一个字一个字去比，比如“2025-2-3”和“2025-10-1”，文字比较会认为“2025-2-3”更大，因为第 5 个字符“2”比“1”大。这种错位特别阴险，表面上看起来规则没毛病，但算出来的结果全反了。

3.3 数据源结构变了，规则跟着崩

还有一种常见情况，你原来根据一个叫“创建时间”的字段做增量，结果上游某一天调整了表结构，把这个字段删了，或者改了名字。你的规则里还写着它，程序一跑发现找不到这个字段，自然直接报错。遇到这种情况，你得先去更新字段映射，或者干脆换一个更稳定的增量字段。

3.4 筛选条件写得太死板

有的人喜欢把条件写得很具体，比如“日期大于 2025 年 1 月 1 日且状态为成功”。这个在当下没问题，但时间一长，2025 年 1 月 1 日已经过去了很久，之后每一天的数据都会满足这个条件，增量更新实际上变成了全量更新。流程越跑越慢，最后卡到怀疑人生。这就是典型的“没有随时间变化的规则”。

四、手把手修正增量规则（示例）

4.1 场景设定：销售订单日更

假设我们有一张销售订单表，每天都会新增几十条订单。订单里有三个关键字段：订单日期（日期类型）、订单金额（数值类型）、订单状态（字符串类型）。我们希望每天只处理新增的那些订单，不要去碰历史数据。下面我们用一个明确的技术栈来解决这个问题。

4.2 失败前我写的规则

先看看我当时犯的错。我在筛选器里加了一个计算字段，判断“订单日期是不是今天”。代码如下：

// 技术栈：Tableau Prep Builder 公式语言
// 这是错误示例，请大家不要模仿。

// 计算字段：是否今天
IF [订单日期] = TODAY() THEN
    TRUE      // 等于今天，就保留
ELSE
    FALSE     // 不是今天，就过滤掉
END

然后我把筛选器设为只保留“是否今天”为 TRUE 的行。这套规则在数据每天准时到位的时候确实能跑。可一旦遇到节假日，上游当天没生成数据，第二天再跑时，订单日期已经变成昨天，而 TODAY() 已经是新的一天，于是昨天漏掉的数据永远也补不回来。还有一种情况，如果当天有人补录了几天前的订单，订单日期不是今天，也会被无情报废。

4.3 重新思考：到底该保留哪些行

想明白问题后，我把思路换了一下。我不再去管“今天”是几号，我只问一个问题：这条订单的日期，是不是比我上次处理过的最大日期还要晚？如果是，就处理；如果不是，就跳过。这样，哪怕上周漏了三天，只要那三天的日期大于我上次处理的最大日期，它们也能被捞回来。所以增量的本质不是“当天”，而是“上次以后”。

4.4 修正后的规则

我先把数据源里最大的订单日期找出来，存到一个参数里，名字叫 [上次最大订单日期]。然后写一个新的计算字段，再去筛选。代码如下：

// 技术栈：Tableau Prep Builder 公式语言
// 参数 [上次最大订单日期] 来自聚合步骤的最大值
// 如果是第一次跑，可以手动填一个很早的日期，比如 #2020-01-01#
// 这样第一次相当于全量刷新，之后才进入增量模式

// 计算字段：是否新数据
IF [订单日期] > [上次最大订单日期] THEN
    TRUE      // 订单日期比上次最大日期晚，说明是新数据
ELSE
    FALSE     // 否则是老数据，直接跳过
END

// 最后用筛选器保留 [是否新数据] = TRUE 的行
// 这样既不会漏掉补录的旧日期（只要它晚于上次最大日期），也不会重复处理已经跑过的部分。

这里最关键的一点是：比较依据是“上次最大日期”，而不是“今天”。每次流程成功结束后，要记得把 [上次最大订单日期] 更新成本次处理到的最大日期。在 Tableau Prep 中，这个更新可以通过参数或者输出到数据库时使用“更新插入”来实现。

4.5 验证修正是否成功

规则改完，别急着收工。先拿一小部分数据试验一下，比如在输入步骤里加一个“取样”，只取最近 100 条数据跑一遍，看看输出结果有没有漏行、有没有重复。然后手动往数据源里插一条日期是昨天的测试订单，再跑一次，如果这条订单也被正常处理，说明规则已经“记住”了上次处理的位置，而不是死盯着今天。

五、关联技术：Tableau Prep 的“通配符合并”和“输出步骤”

5.1 通配符合并怎么用

增量更新经常和“通配符合并”搭配使用。比如你每天会收到一个文件，名字叫“销售_20250401.csv”，第二天又变成“销售_20250402.csv”。如果每次都手动去添加文件，那太麻烦了。Tableau Prep 里的“通配符合并”可以自动匹配所有符合某个命名规则的文件。

下面这个示例展示的是通配符模式的配置：

// 技术栈：Tableau Prep Builder
// 通配符合并配置
// 模式：销售_*.csv
// 作用：自动匹配所有以“销售_”开头、以“.csv”结尾的文件
// 注意：如果新文件的命名格式变了，请先修改通配符模式，否则会漏文件

用上通配符以后，只要新文件按照“销售_日期.csv”的格式放进来，流程就能自动把它们全部读取，再配合增量筛选条件，每天新增的那几个文件就会被精准处理，不需要人工干预。

5.2 输出步骤里的“发布”和“替换”

处理完增量数据后，输出方式也要讲究。如果每次都把整个结果覆盖一次，那就没意义了。正确做法是选择“追加”或者“更新插入”。在 Tableau Prep 的输出步骤中，你可以根据主键来判断哪些行要插入、哪些行要更新。比如订单编号是主键，如果已经存在，就更新金额和状态；如果不存在，就新增一条。这样增量结果就会安全地合并进历史数据中，既有历史，又有新增。

六、应用场景和优缺点

6.1 最适合用增量更新的场景

最适合用增量更新的场景，是那种数据量跟时间明显挂钩的业务。比如每天产生的销售订单、访问日志、监控指标、日报表数据。这些数据每天都在增长，而且一旦成为历史，基本不会再变动。这种情况下，增量更新能省掉大量没必要的重复计算。

如果你的数据源还包含多个小文件，比如每天一个 CSV，那增量更新加通配符合并就是绝配。没增加的文件不碰，新出现的文件自动纳入，简直不要太舒服。

6.2 增量更新的优点

第一，省时间。原来全量跑要一个小时，改成增量之后可能只要一分钟，感受非常直观。第二，省资源。对数据库和电脑的压力都小很多，别人还在吃内存的时候你已经跑完了。第三，容易排错。因为每次只处理新增的那一小块数据，出了问题能马上锁定是“哪一批数据”导致了异常，不用大海捞针。

6.3 增量更新的缺点和潜规则

缺点也很现实。第一，规则需要维护，数据源一变，规则很可能就得跟着改。第二，如果上游对历史数据做修改，比如把三天前的一条订单金额改了，而你的增量字段只看订单日期，那就发现不了这个改动。这时候就得引入“最后修改时间”这样的字段，来识别被修改过的旧数据。第三，如果没设计好，可能做成“假增量”，表面上跑得快，实际内部还是在全量扫描，那就得不偿失了。

七、注意事项

第一，增量字段一定要选稳定存在的字段，比如订单创建时间、最后修改时间。别选那些经常为空，或者没有递增规律的字段。

第二，处理日期类型时，要在流程开始前先把所有日期列统一成真正的日期类型，然后再去比较。这样可以避免字符串和日期“打架”的问题。

第三，每次跑完流程，都要看一眼输出结果里的最大日期或最大 ID，确认这个“记忆点”是对的。如果发现最大日期比实际少了几天，说明有数据漏掉了，要回去查规则。

第四，要留一个“手动全量刷新”的后门。比如把 [上次最大订单日期] 这个参数手动改成一个特别早的日期，再跑一次，就能把历史数据全部重刷一遍，用来修复那些已经被弄乱的数据。

第五，如果数据源支持 SQL，你可能会想在查询里直接写一个“ WHERE 时间 > 上次时间”的条件。但要注意，这样会破坏 Tableau Prep 后续的灵活性，而且 SQL 注入和日期格式问题也不好处理。除非你特别熟悉数据库，否则不建议这么干。

八、总结

回头再看，增量更新失败这件事，大多数不是命运在捉弄你，而是规则本身出了问题。要么用了“今天”这种会漂移的值，要么字段类型变了，要么筛选条件写得太窄。解决思路其实很简单：让规则关注“上次处理到哪里”，而不是“当前是哪一天”。同时，把字段类型整理清楚，对数据源结构变化保持敏感，再留一个手动全量刷新的后门，就能把问题稳稳兜住。

把这几点做到位，Tableau Prep 的增量更新就会从一个爱闹脾气的小祖宗，变成一个又稳又快的乖助手。最后说句实在话，规则修好以后不代表可以一劳永逸，隔一段时间要回头看一眼，尤其是当上游表结构调整、数据源搬家、字段名变动的时候。多留一份心眼，少熬一次夜，这才是数据工作者的浪漫。