一个让数据团队集体焦虑的趋势正在发生：越来越多的企业把 Segment、mParticle 这些传统 CDP（客户数据平台）的合同到期后不再续约，转而用 Snowflake + dbt + Hightouch/Census 的组合来替代。
这不是小公司在省钱。Notion、Retool、GitLab 这些估值数十亿的公司都在做同样的事。
根据 Integrate.io 2026 年初的统计，CDP 市场规模在 $37.1 亿到 $75.1 亿之间（口径差异来自对”可组合 CDP”的定义分歧），而 Reverse ETL 作为可组合架构的核心组件，正在蚕食传统 CDP 的地盘。Hightouch 已经拥有 250+ 目标集成，Census 拿到了 Tiger Global 领投的 $6000 万 C 轮融资。
但我要先说一个不受欢迎的观点：可组合数据栈不是银弹，它的真实成本被严重低估了。
传统 CDP 到底出了什么问题
传统 CDP 的商业模式建立在一个假设上：企业需要一个”单一客户视图”的中央平台，所有数据汇入，所有激活从这里出发。
这个假设在 2020 年之前是成立的。那时候大多数企业的数据基础设施很弱，没有像样的数据仓库，更没有 dbt 这样的转换层。CDP 提供了一个”开箱即用”的解决方案：接入数据源、做身份解析、建用户画像、推送到营销工具。
问题是，2026 年的企业数据基础设施已经完全不同了。
Snowflake、BigQuery、Databricks 这些云数据仓库已经成为大多数企业的”数据真相源”。dbt 让数据转换变得标准化和可版本控制。在这个背景下，传统 CDP 变成了一个尴尬的存在：它要求你把数据再复制一份到它的平台里，用它的 schema 重新建模，用它的规则做身份解析。
这带来三个实际痛点：
数据延迟。数据从源系统到 CDP 再到营销工具，中间环节越多延迟越大。很多传统 CDP 的同步频率是小时级甚至天级。
数据一致性。当你的数据仓库里有一套用户画像，CDP 里又有一套，两边不一致的时候（这几乎是必然的），到底信谁？
成本失控。传统 CDP 按 MTU（月度追踪用户）计费，Segment 的企业版动辄 $10 万+/年。而这些钱买的本质上是”数据搬运”——把你已经有的数据搬到另一个地方。
可组合数据栈的架构逻辑
可组合数据栈的核心思想很简单：既然数据已经在仓库里了，为什么不直接从仓库激活？
架构长这样：
数据源 → ETL（Fivetran/Airbyte）→ 数据仓库（Snowflake/BigQuery）→ dbt 转换 → Reverse ETL（Hightouch/Census）→ 下游工具（Salesforce/HubSpot/广告平台）
每一层都是独立的、可替换的组件。不喜欢 Fivetran 的定价？换 Airbyte。dbt 模型写得不好？重构不影响其他层。Hightouch 涨价了？Census 接上就行。
这种架构的优势很明确：
数据仓库是唯一真相源。所有下游工具看到的都是同一份数据，不存在一致性问题。
灵活性极高。你可以用 SQL 定义任何你想要的用户分群，不受 CDP 预设模型的限制。想做”过去 7 天浏览了定价页 3 次以上但没有开始试用的用户”？一条 SQL 搞定。
成本可控。Reverse ETL 工具的定价通常比传统 CDP 低一个数量级。Hightouch 的起步价 $350/月，Census 类似。对比 Segment 的 $10 万+/年，差距明显。
但是——被低估的真实成本
这是我要重点说的部分，因为太多文章只讲可组合数据栈的好处，不讲代价。
CDP.com 在 2026 年 5 月的分析中给出了一个让人清醒的数字：可组合数据栈通常需要 3-5 名专职数据工程师（每人年薪 $15-20 万），负责仓库建模、身份解析管道、连接器维护和 on-call 轮值。
算一笔账：3 个数据工程师 × $17.5 万/年 = $52.5 万/年。加上 Snowflake 计算费用、dbt Cloud、Reverse ETL 工具的订阅费，总拥有成本（TCO）很可能超过传统 CDP。
传统 CDP 贵，但它把复杂性封装了。你不需要自己做身份解析（这是数据工程里最难的问题之一），不需要自己维护数百个连接器，不需要自己处理 schema 变更和数据质量问题。
可组合数据栈把这些复杂性还给了你。如果你的团队有能力消化这些复杂性，你会获得更大的灵活性和控制权。如果没有，你会陷入一个更贵、更脆弱的系统。
实时性困境：可组合架构的阿喀琉斯之踵
还有一个结构性问题很少被讨论：可组合数据栈天然不擅长实时场景。
当一个 AI Agent 需要在用户浏览你的网站时做实时个性化推荐，它需要亚秒级的用户画像访问和即时激活能力。但可组合架构的数据流转路径是：
事件发生 → ETL 同步到仓库（分钟级）→ dbt 模型重建（分钟到小时级）→ Reverse ETL 同步到下游（分钟级）
整条路走下来，延迟是分钟到小时级。对于”这个用户刚刚把商品加入购物车，30 秒内给他推一个优惠券”这种场景，可组合架构做不到。
传统 CDP 在这方面有天然优势：数据在它的平台内流转，可以做到秒级甚至毫秒级响应。
2026 年的趋势是 AI Agent 越来越多地参与实时决策。如果你的业务重度依赖实时个性化，纯可组合架构可能不是最优解。
谁应该选可组合，谁应该留在传统 CDP
根据我的观察，适合可组合数据栈的团队有几个共同特征：
已经有成熟的数据仓库和 dbt 实践。如果你的仓库里已经有干净的用户模型，可组合架构只是在上面加一层激活，边际成本很低。
有 2+ 名数据工程师。身份解析、数据质量、管道维护需要专人负责。没有这个人力，别碰可组合。
主要场景是批量激活。邮件营销、广告受众同步、CRM 数据更新——这些场景对实时性要求不高，可组合架构完全胜任。
对数据控制权有强需求。金融、医疗行业不希望客户数据流经第三方平台，可组合架构让数据始终在自己的仓库里。
反过来，这些团队应该留在传统 CDP：
没有数据工程团队。如果你的”数据团队”就是一个会写 SQL 的分析师，传统 CDP 的开箱即用能力是你需要的。
重度依赖实时个性化。电商网站的实时推荐、App 内的实时触发消息，这些场景传统 CDP 做得更好。
需要开箱即用的身份解析。跨设备、跨渠道的用户身份合并是一个极其复杂的工程问题。传统 CDP 花了十年打磨这个能力，自己从零搭建的成本和风险都很高。
2026 年的折中方案：混合架构
现实中越来越多的企业选择了折中路线：用数据仓库做批量分析和激活，用轻量级 CDP 或事件流处理实时场景。
比如：Snowflake + dbt + Hightouch 处理日常的营销自动化和广告受众同步，同时保留一个轻量级的事件流（比如 RudderStack 的实时管道）处理实时触发场景。
Hightouch 自己也在往这个方向走。它的”AI Decisioning Platform”试图在仓库原生架构上叠加实时决策能力，虽然目前还不如传统 CDP 成熟，但方向是对的。
这种混合架构的 TCO 通常比纯传统 CDP 低 30-50%，同时覆盖了大部分实时场景。代价是架构复杂度更高，需要团队理解两套系统的边界和协作方式。
常见问题
从传统 CDP 迁移到可组合架构需要多长时间？
典型迁移周期 3-6 个月。最耗时的部分不是技术实现，而是在数据仓库里重建用户模型和身份解析逻辑。建议分阶段迁移：先迁移批量场景（广告受众、邮件列表），最后处理实时场景。
Hightouch 和 Census 怎么选？
Hightouch 的目标集成更多（250+ vs Census 的 150+），适合需要对接大量下游工具的团队。Census 的 dbt 原生集成更强，适合重度 dbt 用户。两者定价接近，功能重叠度高，选哪个差别不大。
可组合数据栈需要什么级别的数据仓库？
最低要求：一个有干净用户表的云数据仓库（Snowflake/BigQuery/Databricks/Redshift）。理想状态：有 dbt 项目管理转换逻辑，有数据质量监控（dbt tests 或 Great Expectations），有文档化的数据字典。
小团队（5-10 人）适合可组合数据栈吗？
看你有没有数据工程能力。如果团队里有 1-2 个懂 dbt 和 SQL 的人，且主要场景是批量激活，可以用 Hightouch/Census 的入门版（$350/月左右）搭一个轻量级可组合架构。但如果连数据仓库都还没建好，先把基础打好再说。
传统 CDP 会消失吗？
不会，但会分化。高端市场（需要实时 AI 决策的大企业）会继续用传统 CDP，但产品形态会进化——更多地和数据仓库集成，而不是试图替代仓库。中低端市场会被可组合架构蚕食，因为成本优势太明显。
我的判断
可组合数据栈不是”更好的 CDP”，它是一种完全不同的数据架构哲学。它把控制权还给了数据团队，但也把复杂性还给了数据团队。
如果你的团队有能力、有意愿承担这个复杂性，可组合架构会给你更大的灵活性、更低的长期成本、更强的数据控制权。
如果你只是想”让营销团队能自己建用户分群发邮件”，传统 CDP 的开箱即用能力可能是更务实的选择。
2026 年的现实是：大多数成长期企业（B 轮到 D 轮）正在往可组合方向走，但走得比预期慢，因为身份解析和实时性这两个问题比想象中难解决。
最聪明的做法可能是：先用可组合架构覆盖 80% 的批量场景，剩下 20% 的实时场景用轻量级方案补齐。别试图一步到位，那条路上躺着很多失败的迁移项目。
Stay updated with our latest AI insights
