Fountain 在 ClickHouse Cloud 上重建数据平面支撑 Cue

Fountain为一线员工打造解决方案——包括零售、物流、餐饮服务、医疗保健和酒店业的时薪工人，他们构成了全球劳动力的主体。自2014年以来，Fountain的平台已处理超过9100万份申请和1400万次招聘，拥有10款产品，服务遍及75个以上国家的客户。

作为一家为一线招聘周期（从申请到入职日期）提供支持的全球性公司，Fountain全天候运营，依赖它的公司（及其员工）也是如此。“一线永不眠，”Fountain数据平台负责人Alex Norton说。“我们的客户在成千上万个地点全天候进行招聘、入职和排班。”

过去，Fountain依赖三小时批处理作业。“这根本无法服务我们的客户，他们需要做出决策现在，”Alex说。于是他们构建了Cue Frontline Superintelligence，这是他们驱动一线运营的智能体AI平台。借助Cue，一线招聘经理可以在上午9：02观察到信号，并在9：05做出决策。

“一线申请人的半衰期是分钟，而不是小时。借助ClickPipes从三小时刷新降至两分钟或更短，对我们的客户群而言真正具有变革意义。” — Alex Norton，Fountain数据平台负责人

在Open House SF 2026上，Alex和高级分析工程师Cecily Storey讲述了他们如何构建Cue的故事，从他们抛弃的多供应商批处理架构，到他们迁移到的精简系统——在AWS上使用ClickPipes和ClickHouse Cloud，以及这如何帮助他们以大约降低三分之一的成本实现亚秒级查询。

旧技术栈走到尽头的五个原因

Fountain的旧分析架构采用传统的批处理模式。数据从源数据库（13个Postgres生产数据库和4个MongoDB数据库）通过第三方复制供应商进入S3，以Iceberg和Parquet格式落地，然后进入BigQuery和ClickHouse（使用s3表函数）进行分析。

Fountain的旧批处理架构：成本高、脆弱、对一线需求而言太慢

“这对我们三小时刷新管道来说还算可以，”Alex说，“但即便如此，它也變得昂贵而脆弱。”团队要跨多个供应商和云管理一条管道；一旦MongoDB加入进来，对Fountain的小型数据团队来说就成了麻烦。“维护它花费了大量时间，而这些时间本可以用来创新，”他说。

Alex强调了最终迫使他们重建的五个制约因素。第一是新鲜度：三小时的节奏与以分钟为单位行动的智能体不兼容。第二是成本：一个逻辑跳转产生了四张独立账单：复制、S3存储、仓库摄取和分析计算。“即使在三小时刷新的情况下，成本也失控了，”他说。

第三是复杂性：三个供应商和两种中间格式意味着每个接缝处都会出现模式漂移。第四是基数，100亿行以上的表和过渡窗口呈指数级爆炸。第五是并发：十几个租户中的数千名用户访问同一数据平面，Alex说，“把查询延迟降到10秒以下是一场战斗……降到1秒以下是不可能的。”

用ClickPipes和ClickHouse Cloud重建

Alex简单地描述了新架构：“我们以ClickPipes为主导，其他一切都建立在它之上。”Fountain没有将复制、对象存储和仓库拼接成一条长链，而是使用ClickPipes托管CDC将Postgres和MongoDB直接流式传输到ClickHouse Cloud。“一个供应商，每个源数据库一个连接，零胶水代码。”

Fountain新的基于ClickHouse的架构：一个供应商、一跳、无调度器

原生JSON让Fountain无需字符串解析即可处理MongoDB深度嵌套的文档，Alex说，在旧系统中，“这变得非常昂贵，尤其是在近实时场景下。” 增量物化视图在ClickPipes写入批次的那一刻转换数据，因此数据路径上没有编排器。而行级访问控制通过构造保持每个客户的数据隔离，而不是靠某人必须记得编写的查询。

结果是两条对称的管道——一条用于Postgres，一条用于MongoDB——每条都运行相同的短路径：源、ClickPipes、物化视图、Cue。旧架构有两跳、四张账单和跨接缝的模式漂移，而新架构有一个分析平台、一跳、没有调度器。

“用户不必维护多个分析平台，可以依赖ClickHouse作为我们的实时分析平台。我们将成本降低了66%，而且维护起来简单得多。” — Alex Norton，Fountain数据平台负责人

深入了解Fountain的新架构

随后Alex把话筒交给了Cecily Storey，她是Fountain实时引擎的首席开发者，她逐一介绍了数据平面所依赖的四项ClickHouse能力：ClickPipes、原生JSON、增量物化视图和基于角色的访问控制。

ClickPipes

“ClickPipes是关键，”Cecily说。“如果从Alex和我所讲的内容中拿掉一个特性，那就是ClickPipes让我们的实时模型变得简单且可扩展。”

如今，Fountain运行着15个以上的连接器，为2000多个增量物化视图提供数据。在Postgres侧，11个生产部署持续复制到SharedReplacingMergeTree表中，以Postgres主键为键。每一行都带有由ClickPipes本身标记的两列，_peerdb_synced_at和_peerdb_is_deleted。“没有其他需要监控或付费的东西，”Cecily说。“没有Iceberg层，没有S3存储桶。”

MongoDB 数据源在支撑 Fountain 人力资源产品的四个数据库中遵循相同的模式。每个文档都落入原生 JSON 类型的单一列中。“ClickPipes Mongo 与原生 JSON 的搭配，正是让我们能够为 Mongo 数据源提供近实时能力的关键，”Cecily 说道。总体而言，CDC 层在大约 953 GiB 的压缩数据中，跨 1,550 张表保存了 84.8 亿行。

原生 JSON

在旧的批处理集群上，每个 MongoDB 字段都必须通过 JSONExtract 调用从字符串列中提取出来。“它很冗长，”Cecily 说，“而且对于你解析的每一行数据中所需的每一个字段来说，解析成本都很高。”

ClickHouse 的原生JSON 数据类型用简单的点号表示法取代了这一切。一个字段就只是doc.companyUuid::String或doc.homeAddress.city::String，可以按需深入到文档中的任意层级，无需任何提取函数。“不用每次都写 JSONExtract 和 JSONValue，真是件乐事，”Cecily 说。

由于采用读时模式，添加新的 MongoDB 字段只需对下游的 ReplacingMergeTree 做一行 SQL 修改。“没有 DDL，没有模式注册表，”Cecily 说。“我们不需要回填 ClickPipe 本身，因为我们需要的所有数据都已经存在于那个单一的 doc 字段中。”嵌套数组以动态值数组的形式到达，能与 ClickHouse 的数组函数（arrayMap、arrayJoin、arrayFirst、arrayLast）良好配合。

最重要的是，ClickHouse 在内部将 JSON 存储为列式子结构，而不是在每次读取时重新解析字符串。“这在大规模场景下是一个显著的胜利，”Cecily 说。“它为我们节省了大量的 CPU 和内存消耗。”

增量物化视图

“架构的核心”在于转换是如何发生的。CDC 数据源下游的每一个物化视图都会在 ClickPipes 向原始表写入一批数据的那一刻触发。“这就像瀑布一样，”Cecily 说。“你在一个中做出更改，它就会级联到下一个。”

Fountain 在其 15 个部署中的每一个上都以这种方式运行 100 多个模型，用 dbt 编写并直接将它们构建到 ClickHouse 中。大多数落入ReplacingMergeTree（对于像转换日志这样不可变的记录，则使用普通的MergeTree），转换被有意保持得很浅，以便查询保持快速。“没有 Dagster，没有 Airflow，没有 cron，”Cecily 说。“设置好就不用管了。刷新是存储引擎的一个属性。”

无需编排的转换：ClickPipes 向原始 CDC 表写入一批数据，物化视图触发，去重后的行落入 ReplacingMergeTree，无需调度器

这种插入时模型还解锁了团队“最大的性能胜利”。为了回答一个常见问题（“申请人在某个特定阶段停留了多长时间？”），他们需要每次转换的前一个和后一个时间戳。他们不是在整个表上于查询时运行该窗口函数，而是将工作移入物化视图，将 ClickHouse 的lagInFrame函数与ASOF JOIN配对使用。lagInFrame处理当前批次中的记录，ASOF JOIN回溯到已经存储的数据，而coalesce在批内值存在时采用它，否则回退到已存储的值。

在 8.38 亿行的转换表上于插入时计算一次，将每次查询的内存从 778 MiB 降至 153 MiB，减少了 80%。推广到各种查询形态后，同样的模式可节省 60-98% 的内存。“把昂贵的形态移到你的增量物化视图中，”Cecily 总结这一经验时说道，“让你的查询保持廉价。”

安全与治理

最后一块拼图或许是最新颖的：确保 Cue 的 LLM 永远无法看到或影响安全模型。“解决这个问题让我乐在其中，”Cecily 说。

正如 Cecily 所解释的，每个 Cue 分析查询都以按部署划分的服务用户身份运行：“我们基本上把它们设计成空容器，自身完全没有访问权限。”访问权限来自一个带时间戳版本的 RBAC 角色，该角色携带SELECT授权以及一组默认为空的会话变量。Fountain 的后端 MCP 在每次查询开始时，根据发起者是谁以及他们被允许查看什么来设置这些变量，而每张表上的行策略则针对租户键进行过滤。

租户安全的分析：Cue 设置每个调用者的权限变量，服务用户的角色路由查询，行策略按租户键过滤，而 LLM 永远不知道安全模型。

因此安全完全存在于数据平面中，而从不存在于模型构造的WHERE子句中。“我们的 LLM 对安全模型零知识，”Cecily 说。“即使有人试图对我们的智能体进行提示注入，他们也无法泄露跨客户数据，也无法访问他们不被允许查看的产品的数据，因为控制这些的变量都在数据库层面，并由我们的 MCP 完全在智能体 LLM 之外指定。”

而且该设计以安全方式失败。如果权限变量缺失或无效，如果角色未被应用，或者如果新表不在 RBAC 配置中，Cue 只会看不到数据，而不是看到过多数据。正如 Cecily 所说，“这是固有的安全状态行为。”

成果：更快、更便宜、为扩展而构建

所有这一切都是为了支撑 Cue——Fountain 的智能体分析与行动层。正如 Alex 所说，“我们从监控仪表盘——那些聚合了数小时或数天前收集的信号、然后主动浏览这些仪表盘来识别信号的仪表盘——转变为让这一切实时化，并让 Cue 来识别这些洞察并采取行动。”

Cecily 补充了这一转变背后的数字，指出：“我们从三个小时缩短到远不到两分钟，而现实是，对于绝大多数查询，我们的实时路径更像是亚秒级。”

总而言之，该系统目前承载着由 ClickPipes 持续复制的 84.8 亿行 CDC 数据，以及跨 15 个部署的 103 亿行分析数据，由 2,000 多个增量物化视图提供服务。窗口函数预物化将内存减少了 60-98%。与 Fountain 旧的基于批处理的流程相比，基于 ClickHouse Cloud 构建的新平台运行成本降低了约 66%。

将引擎转向内部

在为客户构建了 Cue 之后，Alex 表示他们现在计划“将这个引擎转向内部，供 Fountain 的团队内部使用”。利用ClickHouse 的远程 MCP，该公司将通过 Claude Desktop（打包为带有 skills 的插件）向内部利益相关者公开其实时语义模型，这样任何 Fountaineer 都可以直接查询数据模型，而无需向数据团队提交请求。“这对我们的产品团队来说将是变革性的，让他们与数据的联系比以往任何时候都更加紧密，”他说。

最初只是为了修复一条无法跟上需求的管道，如今已成为整个公司开始构建的基础。“我们用 ClickHouse 构建的近实时管道不仅正在改变小时工劳动力及其管理方式，”Alex 说，“也在改变我们如何构建产品，以进一步服务一线工作者。”