Arcesium 从 Athena 到 DuckDB 的 18 个月，成本降半

2026 年 6 月 30 日，金融科技公司 Arcesium 的工程师 Simran Batra 在官方工程博客上发了一篇文章，标题很朴实：Query Faster, Query Smarter: Our Move to DuckDB and What We Learned。

但里面藏着一个让人坐不住的数据——

Arcesium 的投资组合会计系统，约 40% 的生产事故源自 Athena 的账户级并发限制。每次客户 onboarding，查询量翻 10 倍直接撞墙。一个管理着大量机构资产数据的系统，瓶颈居然不在计算，在排队。

这不是架构缺陷，是商业模式被云服务的硬限制卡住了脖子。

● ● ●

三个引擎，一个结论

Arcesium 的核心产品是 Portfolio Accounting System：接收各类投资事件，经过复杂计算后持久化为 S3 上的 Parquet 文件。产品能力的本质，就是原始数据 + 复杂查询层。

查询层最初跑在 AWS Athena 上。Athena 的卖点是 serverless —— 不用管集群，按扫描量付费。但这个卖点在 Arcesium 的场景下变成了致命伤。

Athena 的账户级并发限制是硬编码的。Arcesium 的查询模式是高并发小查询，不是 PB 级大扫描。每当有新客户接入，查询量陡然增加 10 倍，Athena 直接返回限流错误。40% 的生产事故就是这么来的。

第一刀砍下去，团队选了 Trino。Trino 解决了扩展性问题——自己管集群，并发不受云服务限制。但新问题来了：资源开销太高。Trino 是重型的分布式查询引擎，跑在 Arcesium 这种数据量不大但查询密集的场景下，有点像开卡车送外卖。

第二步跑了一年多，团队意识到：这条路虽然能走，但经济账算不平。

● ● ●

DuckDB 怎么赢的

DuckDB 进入视野时，团队最初只是做 POC。结果让所有人重新思考了选型逻辑：

• 查询运行时减少 50%
• 资源消耗减少 50%

不是微调，是砍半。

Arcesium 的最终技术栈定格在 Java 微服务 + S3 Parquet + DuckDB 嵌入式 OLAP。架构极度简化：没有独立查询集群，DuckDB 作为嵌入式库跑在 Java 应用进程里，通过 JDBC 客户端直接访问 S3 上的 Parquet 文件。

2024 年底开始部分客户试点，2025 年底完成全量迁移。数千条 SQL 查询，从 Athena 经 Trino，最终全部落到 DuckDB。

● ● ●

Java 里跑一个嵌入式数据库，怎么保证隔离

这可能是整个迁移中最精巧的设计决策。

Arcesium 的查询层是 Java 微服务，每个请求可能触发不同的查询。DuckDB 是进程内数据库，如果所有请求共享一个连接，状态污染和资源争抢不可避免。

团队的做法是：master connection + duplicate() 模式。

启动时创建一个 master connection，用它配置全局参数——threads、内存、时区、S3 认证等。每个请求到来时调用 duplicate() 派生一个独立连接。这个派生的连接继承 master 的全部配置，但拥有独立的事务空间和资源上下文。请求结束就关闭，不会残留任何状态。

内存模式也做了区分：生产环境跑 in-memory 模式，纯内存计算，不落盘；调试和问题排查切到持久化模式，方便事后复盘。

参数调优清单值得抄一遍：threads、TimeZone、http_keep_alive、http_retries、http_retry_backoff、http_retry_wait_ms、allocator_background_threads。

● ● ●

Schema 演化：没有 Glue Catalog 的代价

DuckDB 不像 Athena 依赖 AWS Glue Catalog 管理 schema。它的 schema 直接从第一个 Parquet 文件推断。

这在 schema 稳定时完全不是问题。但 Arcesium 的 Parquet 文件来自多个上游系统，schema 会演化——新增字段、嵌套 STRUCT 变更、不同分区的文件结构不一致。

解决思路分两层。常规的多文件 schema 不一致，靠 union_by_name=true 搞定。但 v1.3.0 之前的 DuckDB，对 STRUCT 嵌套层级的变化支持有限——这是团队实际踩过的坑。

他们的反思很坦率：DuckDB 的"schema-on-read"哲学在灵活性和可维护性之间存在张力。没有 Glue Catalog 意味着少了一个要维护的基础设施组件，但也意味着你要自己处理好 schema 的边界情况。

● ● ●

让查询再快一点

迁移不只是换引擎，团队顺手做了几项深度优化。

Parquet 小文件压缩：上游系统产生大量小 Parquet 文件，DuckDB 每次查询要打开大量 S3 文件句柄。团队写了一个主动压缩任务，把碎片化的 Parquet 文件合并成更大的文件，减少 S3 的 list 和 open 开销。

视图 + 持久化混合：频繁被查询的中间表，不物化到本地，而是在 Parquet 文件上建视图。这样减少了数据复制和内存占用，同时又保留了 SQL 的抽象层。

PER_THREAD_OUTPUT 并行读写：利用 DuckDB 的并行机制，按线程并行输出，在多核机器上把 I/O 吞吐拉满。

最终效果：查询成本降低 50%，中小型查询速度提升 50%+，内存占用减少约 40%，不再触发任何服务限制。

● ● ●

"锋利边缘"

Simran 在文章里用了一个词：sharp edges（锋利边缘）。

DuckDB 不是平滑的工具。Schema 推断会踩坑，S3 连接需要显式指定 ENDPOINT 否则报 IO Error（团队用 CREATE SECRET + CREDENTIAL_CHAIN 解决），某些参数在文档不够显眼的地方，需要读源码才能理解行为。

她说得很直接：这条路不容易。但对金融科技这种查询多变、并发高、不依赖 PB 级扫描的场景，DuckDB 的简洁性和经济学价值值得下这笔迁移成本。

● ● ●

嵌入式数据库进了金融核心系统

这个案例的信号意义，比技术细节本身更大。

三年前，DuckDB 在人们的印象里还是"分析师用的本地工具"——单机跑 CSV，做做 ad-hoc 分析。没人会把它放进生产链路，更别提金融科技的核心会计系统。

Arcesium 干了一件事：他们用 18 个月证明了，几千条生产 SQL、数十个金融客户、复杂的投资组合计算——这些场景跑在一个嵌入式数据库上，不仅可行，而且比 serverless 快、比分布式集群便宜。

当华尔街开始把生产查询从 Athena 迁到 DuckDB，这已经不是一个"分析师工具"的故事了。

原文：Simran Batra, "Query Faster, Query Smarter: Our Move to DuckDB and What We Learned", Arcesium Engineering Blog, 2026.6.30

链接：medium.com/arcesium-engineering-blog/query-faster-query-smarter-our-move-to-duckdb-and-what-we-learned-c935128e80bc