如果要在 Tableau 二十多年的产品史中挑一条最被低估的主线，不是图表类型，不是 AI，而是数据模型。
原因很简单：数据模型决定了”分析师要为了回答一个问题，付出多少准备工作”。同样一句”上季度华东区销售额是多少”，在不同时代需要的前置劳动完全不同——有时是拖拽两次，有时是先在 SQL 里写一张宽表、再写 LOD 去重。
Tableau 数据模型十六年的演进，贯穿其中的只有一句话：
把”如何拼数据”的责任，从分析师身上逐步转移到产品引擎上。
理解这条线，你就理解了为什么 2020.2 是一次地震、为什么 2024.2 值得单独讲、以及为什么 2026.2 的可组合数据源会改变企业建模的组织方式。
一、混合模型：在视图层拼数据（6.0 / 8.0）
Tableau 官方在回顾产品创新史时交代得很坦白：之所以要有数据混合（Blending），是因为不理解 join 的用户也需要处理多张表。
v6.0（2010 年 11 月）引入的混合机制是这样的：把多个数据源拖到同一张工作表上，按公共维度，各自先聚合、再在视图层拼接。它有主数据源与辅助数据源之分，可以按单张工作表单独自定义。v8.0（2013 年）进一步支持行级数据混合，对粒度差异的容忍度更高。
但这个机制有两个让分析师刻骨铭心的后果：
第一，无法跨数据源做行级计算。 混合的本质是”聚合后拼接”，两个数据源的字段之间并不存在真正的行级对应关系。因此，凡是需要在行级别跨源操作的表达式——行级判断、跨源字符串拼接、跨源日期差——都无从下手。你能做的只有”两个已经聚合好的数字放在一起比较”。
第二，ATTR() 带来的星号。 从辅助数据源取来的维度，如果在当前视图粒度上不唯一，Tableau 无法返回单一值，只能返回 ATTR()，视图上就显示为那个令人不安的星号 *。这是分析师最常遇到、也最难向业务方解释的现象——业务方只会问：”为什么这里是个星号？”
再叠加”不可复用、不进入数据源”这一条：混合结果只属于那一张工作表，换个问题就得重来。
正是这两点，构成了分析师转向物理联接（Join）的最核心现实原因。 大家宁可在数据源页把表 join 成一张宽表，也不愿在视图层跟星号搏斗——哪怕宽表会带来新的麻烦。
*（ATTR）呈现。图片与数据来源：Tableau 帮助文档 · 多连接与数据混合二、物理模型与 ETL：把表压平成一张宽表（8.2 / 10.0 / 2018.1）
v8.2（2014 年 6 月）带来的数据源页（Data Tab），就是为”懂 join 的用户”准备的：联接与并集从对话框搬到了画布上，并且支持在探索过程中随时追加数据源。
v10.0（2016 年）更进一步：跨数据库连接打破了数据库边界，不同系统里的表可以直接联接。这一版之后，分析师向 IT 提的需求从”请帮我做一张宽表”变成了”请给我数据库访问权”——这是一个标志性的转变。
但物理模型的本质没有变：无论 join、union 还是自定义 SQL，最终产出的是一张扁平的宽表。在 2020.2 之前，物理层就是数据模型里唯一的一层。
代价也随之而来，而且不小：
- 粒度不同的表 join 之后，维度表上的度量会被复制——一张订单明细表关联客户表，客户表上若带度量，就会按订单行数重复；
- 聚合结果因此失真，分析师必须靠 LOD 表达式或 COUNT DISTINCT 手动去重补救；
- 于是”精通详细级别”成了 Tableau 高阶能力的代名词，也成了新手的噩梦。
Tableau Prep（2018.1）是这个矛盾的第一次外溢式缓解。 官方创新史把 Prep 视为多表路线的重要一步：把清洗与拼接前移到准备环节，让理解 join 的人在可视化之前就把数据整理好。
但 Prep 并没有改变范式——它只是把”分析师必须理解 join 与粒度”这件事，从一个工具挪到了另一个工具。真正的解法在两年后到来。
三、关系模型及其扩展（2020.2 → 2026.2）
3.1 2020.2 关系模型：数据模型从一层变成两层
这是 Tableau 历史上最大的一次建模变革。
2020.2 之后，数据源不再只有物理层，而是逻辑层 + 物理层两层结构：
- 逻辑层（画布上层）：拖入的表通过”关系”（那条被亲切地称为 noodle 的连线）关联。关键区别在于——这些表不会合并，各自保留原生的详细级别。
- 物理层（双击逻辑表进入）：传统的联接与并集仍然在此，产出单个逻辑表。
配合两条语义，问题被正面解决：
- 智能聚合：度量先在其所属表的粒度上聚合，再执行连接。既然先聚合后连接，物理 join 导致的重复就自然消失了。
- 上下文连接：连接类型不在建模时写死，而是在分析时，按视图中实际的字段组合动态决定——inner、left、right、full 都有可能，按需生成。
此外还有性能选项（基数与引用完整性）：Tableau 会取安全默认值；如果你的数据仓库里已经定义了完整性约束，Tableau 会自动读取，不需要手工判断。
对老用户还有一个贴心的兼容处理：2020.2 之前的工作簿打开后，会显示为一个名为 Migrated Data 的单个逻辑表，行为与旧版完全一致，你还可以继续向它追加关系。
这里必须说清一件事——关系模型与 LOD 的关系。
很多人以为关系模型出现后，LOD 就没用了。恰恰相反：
关系模型并未淘汰 LOD，而是把 LOD 从”纠正物理连接导致的重复”，回归到了”实现跨粒度聚合逻辑”的本义。
在物理模型时代，大量 LOD 写作其实是在做补救——用 {FIXED} 把被 join 复制过的度量拉回正确粒度。关系模型把这部分苦活接管之后，LOD 终于可以专心做它本来该做的事：表达”在另一个粒度上看这个数”。对高阶分析师和架构师来说，这是一次解放。
一句话概括这一跃迁：分析师只需声明”哪些字段匹配”，不必再决定连接类型与去重策略。
3.2 2024.2 多事实关系：从”一个中心”到”多个中心”
2020.2 带来了关系，但仍有一个硬限制。官方帮助文档写得很明确：
从版本 2020.2 到 2024.1，仅当事实表与单一维度表关联时，才能将事实表加入星型和雪花模型。
也就是说，一个数据模型里只能有一个中心。想同时分析销售额与市场投入？只能建两个数据源，或者先在数仓里做一张宽表。
2024.2 打破了这个限制：
- 允许存在多个基表（base table）：销售、市场、库存、预算等事实表可以共存，且彼此不需要直接关联；
- 共享表中的共享维度（日期、产品、地区等）会在分析时，把各基表的度量按外连接语义“拼接”起来；
- 连接选项相应扩展为包含外连接与交叉连接，以处理不同层级的关联性；
- 术语随之变更：2020.2–2024.1 称为
root table（根表），2024.2 及以后称为base table（基表）——从”根”到”基”，本身就说明了从唯一到可多。
典型收益非常直观：”销售额 vs 市场投入”、”实际支出 vs 预算”、”Customer 360″这类跨主题分析，一个数据源即可完成，不再依赖数据工程预先建模。
官方参考：使用关系的数据源的分析方式（需登录 Tableau 账号）／When and How to Use Multi-fact Relationships（官方博客）
3.3 2025.3 添加关联表：让数据库的外键替你建模
2025.3 带来的”添加关联表”（Add Related Tables），需要正确定位——它是关系模型在制作效率上的优化，不是范式变化。
在画布上右键任意表，如果 Tableau 能从数据库中的外键约束识别出关系，就会出现两个选项：
- Find and add directly related tables (n)：只添加与当前表直接相关的表；
- Find and add all related tables：添加直接相关的表，以及它们的下游相关表。
自动创建出来的关系，可以像手工关系一样编辑修改；识别不到时，仍然需要手工添加。
承上启下地说：从 2020.2 起，Tableau 就已经能够识别 Oracle、SQL Server 等库中常见的星型与雪花模式；2025.3 只是把这项能力做成了一个显式的、一键完成的建模动作。
3.4 2026.2 可组合数据源：建模对象上移到”已发布数据源”
2026.2 又是一次上移——建模对象从”数据库中的表”，变成了已发布的 Tableau 数据源。
- 把多个已发布的数据源组合成一个统一模型，附加业务逻辑与计算后再次发布，供工作簿与 API 共同复用；
- 上游任意一个已发布数据源更新时，组合数据源会在下次刷新时自动同步，无需手动重建；
- 意义在于：指标口径终于可以”一处定义、多处复用”。
Cloud 与 Server 的时差：可组合数据源是分批上线的——Tableau Cloud 在 6 月率先上线，Tableau Server 与 Desktop 在 7 月陆续跟进。中国大陆 Server 用户请以实际版本与补丁级别为准。
官方参考：Tableau 2026.2 新功能页（可组合数据源 / Composable Data Sources）
如果说前三次跃迁是”把手工活交给引擎”，这一次是”把建模资产本身变成可复用的积木”——从建模走向组装。
3.5 关系模型的三段式
| 维度 | 单基表关系（2020.2） | 多基表共享维度（2024.2） | 可组合数据源（2026.2） |
|---|---|---|---|
| 物理表现 | 单星型 / 雪花模型（1 个中心表） | 多星型 / 多事实表共存 | 引用已发布的 semantic 数据源 |
| 连接语义 | 动态上下文连接（按需生成） | 共享维度下自动做外连接 / 交叉拼接 | 继承上游已定义的语义与逻辑 |
| 解耦粒度 | 跨物理表解耦 | 跨业务主题 / 多事实表解耦 | 跨数据建模资产解耦（跨团队 / 数据源） |
| 核心适用场景 | 单业务主题（如订单-明细） | 多主题交叉（如销售额 vs 预算） | 企业级指标库统一与复用 |
四、面向 AI 的数据服务：模型不再只服务于图表
前三个范式解决的都是”人怎么用数据”。这一章解决的是”机器怎么用数据”。
4.1 2025.1 VizQL 数据服务：语义层开始对外提供服务
VizQL Data Service 让开发者可以通过 API，取得与可视化完全同源的数据逻辑——不必先画一张图，再想办法把图里的数抠出来。
这是 Headless BI（无中心 BI）与语义层服务化的起点：Tableau 不再只是一个”画图的地方”，而是可以被嵌入到企业 App、门户、工作流中的数据服务。
4.2 2026.2 实时仪表板查询：带上下文与权限的数据服务
2026.2 的 VizQL 实时仪表板查询（Live Dashboard Query），把这件事推进到了关键一步。
嵌入应用通过 Embedding API 拿到用户当前活跃的仪表板会话标识，传给 VizQL 数据服务后，返回的不是冷冰冰的表数据，而是”这个用户此刻在这张仪表板上看到的那些行”。
请特别注意这句话的含义：
AI Agent 消费的不仅是数据，而是带上下文的数据服务——用户权限、行级安全策略、维度筛选、参数设置，全部随数据一起返回。
这是传统 Headless BI 方案（纯 SQL 接口、Cube API）难以比拟的优势。那些方案里，权限与上下文往往需要在使用侧重新实现一遍，于是每个 AI 应用都在复制一套权限逻辑，也都在复制一套出错的可能。而在 Tableau 这里，权限与上下文由语义层统一保证，AI 拿到的数据天然就是”这个人该看的那些数据”。
这也解释了为什么它值得被称作一次范式变化：数据模型不再只是给人做图的输入，而是可被 AI 安全调用的语义层。
4.3 对自建 Server 用户的三条现实提示
- AI 需自带模型（BYOM）。Tableau Server 上的 Tableau Agent 不走 Salesforce 的 Einstein Trust Layer，而是由客户接入自己的模型：2025.3 仅支持 OpenAI（自备 API Key），2026.2 起支持 Azure OpenAI，可以部署在企业自有的 Azure 租户内。这不是”升级即可用 AI”，而是需要明确的模型接入与合规评审。
- Cloud 优先、Server 随后。Agent in Dashboards 在 Cloud 上是 Beta，在 Server 上是 Pilot（需申请）；语义搜索、托管 MCP 目前主要在 Cloud 侧。中国大陆 Server 用户读到这些特性时，往往要等 Server 分支版本，部分能力还需申请。
- Tableau Next 与 Semantics 不可用。语义层继续演进为独立的 SDM 资产（可组合性覆盖、AI 自动建模、Semantics DX），对中国大陆客户只能作为趋势了解，不纳入方案。
附：另一条线——数据连接与安全（2021.4 虚拟连接）
严格来说，虚拟连接不属于数据模型范畴，这里单列说明，不展开。
2021.4 引入的虚拟连接，是 Tableau Server / Cloud 上的一种新内容类型：集中创建与共享对表的访问、内嵌服务账户凭证（只存一次，不必每个数据源各存一份）、通过数据策略集中定义行级安全，并在服务端对每次查询强制执行。
它解决的是”谁能访问哪些数据“，而不是”数据如何组织成模型“——前者是连接与治理，后者才是建模范式。
一个必要提醒：虚拟连接与数据策略需要 Data Management / Enterprise（Tableau+）套餐，且创建者需 Creator 许可。它不是升级版本就能用。
官方参考：Tableau 中的行级安全性选项概述（含虚拟连接数据策略）
结语：三次交接，一次开放
回看这十六年，Tableau 的数据模型完成了三次交接：
| 时代 | 分析师要做什么 | 引擎接管了什么 |
|---|---|---|
| 物理拼接（2010–2020.1） | 选 join 类型、对齐粒度、写去重 | 基本没有 |
| 关系时代（2020.2–2024.1） | 声明匹配字段 | 连接类型、聚合粒度、去重 |
| 多事实与组合（2024.2–） | 选共享维度、组合已有资产 | 跨主题拼接、上游同步 |
不过必须说清一件事：这三次交接并不意味着建模越来越简单。 恰恰相反——数据模型本身是越来越复杂的：从”要不要混合”这一个选择，变成 join 类型、粒度对齐、关系匹配字段、基数与引用完整性、共享维度、可组合资产等一系列判断；每一个新能力都扩大了可支撑的分析场景，也同时抬高了对分析师建模判断力的要求。Tableau 接手的是机械劳动（连接与聚合的实现），接手的不是判断本身。
也正因如此，第 3.5 节那三段式的演进，本质上是一部”选择权不断增加”的历史：选择越多，能力上限越高，对建模者的要求也越高。
而对中国大陆的 Server 客户，有一个具体的落点值得记住：
如果你的企业还停在 2023.1，那你目前所处的正是”关系时代·单基表”阶段——可以使用关系模型，但无法在一个数据源内做多事实分析。升级到 2026.2 之后，多事实关系、共享维度、可组合数据源，全部是净新增能力，不需要数据工程预先建模，也不需要先建多套数据源。只是请记住：AI 相关能力需要自带模型，且部分能力 Cloud 优先。
数据模型的每一次跃迁，本质上都是把一项原本属于分析师的手工劳动，变成了引擎的默认行为。而到了 AI 时代，被服务化、被反复调用的，恰恰就是这些年来积累下来的模型资产——你过去建的模型，正在成为 AI 理解业务的底座。
文中版本与事实依据：Tableau 官方《数据模型》《关系、数据模型和数据源 FAQ》《Relate Your Data》帮助文档；官方博客《Analyzing the history of Tableau innovation》；2021.4 / 2024.2 / 2025.1 / 2025.3 / 2026.2 各版本新功能页；Tableau 技术支持计划（Server 维护与有限支持日期表）。
作者：喜乐君 · 2026-10