Pierre Zemb 来自 Clever Cloud 谈 FoundationDB

# Pierre Zemb 谈 Clever Cloud 与 FoundationDB 来源：https://theconsensus.dev/p/2026/06/18/pierre-zemb-from-clever-cloud.html The Consensus Logo (https://theconsensus.dev/) 关于软件基础设施。 ## Pierre Zemb 谈 Clever Cloud 与 FoundationDB Pierre Zemb 是 Clever Cloud 的一名职员工程师，他在 FoundationDB 之上构建与 Redis、PostgreSQL 和 etcd 等服务 API 兼容的数据层。 作者：Phil Eaton · 2026年6月18日 作为订阅者，您正在提前阅读本文。您的支持使这样的文章成为可能。谢谢。 *本文是一个系列访谈的一部分，采访对象是从事软件基础设施的开发者（而非创始人或高管），旨在了解他们的工作、他们如何走到今天、他们引以为豪的项目、从中学到的事故教训，以及他们好奇的事物。* Pierre（LinkedIn (https://www.linkedin.com/in/%F0%9F%91%A8%F0%9F%8F%BB%E2%80%8D%F0%9F%92%BB-pierre-zemb-8004125b/?from_theconsensus=1)，Twitter (https://x.com/PierreZ?from_theconsensus=1)）的职业生涯一直专注于欧洲云计算公司：先是 OVHcloud (https://theconsensus.dev/company/ovhcloud.html)，然后是现在的 Clever Cloud (https://theconsensus.dev/company/clever-cloud.html)。Clever Cloud 在 FoundationDB (https://theconsensus.dev/project/foundationdb.html) 之上大力投资（而 Pierre 则领导着相关数据服务的开发）。 ## 你曾在云提供商 OVHcloud 工作过一段时间。在那里你负责什么工作？# 我花了大约 6 年时间在 OVHcloud (https://theconsensus.dev/company/ovhcloud.html)，从在波兰的公共云团队实习开始，从事虚拟机监控的数据收集和可视化工作（不是存储方面），然后在 2016 年被聘用从事 Metrics Data Platform 的工作。该平台基于 Warp 10 (https://warp10.io/?from_theconsensus=1) 构建，帮助我们托管公司的所有遥测数据，从数据中心温度到虚拟机遥测。 在高峰期，OVHcloud 在底层 HBase 集群上每秒产生 250 万次写入和 650 万次读取。我最初是一名 Go/Java 开发者，然后通过学习运维 Hadoop 和 HBase（并且随时待命！）学会了运维技能，这并非易事，但确实非常有成就感！当时我们团队大约有 4 到 6 个人，同时负责开发和运维，正因为如此，我们是一个高度专注的团队。 在 Metrics 之后，我参与了 ioStream，这是我们基于 Apache Pulsar (https://theconsensus.dev/project/pulsar.html) 构建的队列即服务愿景，但该项目被取消了。然后我参与了 Managed Kubernetes，在那里我尝试改进 etcd (https://theconsensus.dev/project/etcd.html) 的性能 (https://www.youtube.com/watch?v=IrJyrGQ_R9c&from_theconsensus=1)，之后加入了 Clever Cloud (https://theconsensus.dev/company/clever-cloud.html)。 ## 你现在在 Clever Cloud 做什么？# 公平地说，好几件事吧。Clever Cloud 是一家自筹资金、盈利的欧洲云提供商。我们最初是为开发者提供的 Heroku/App Engine 替代方案，随着时间的推移，我们发展成了更广泛的服务：我们作为公共云运行的同一套堆栈，客户可以安装在自己的数据中心或完全隔离的环境中，并附带全套托管服务目录。我加入时我们大约有 25 人，现在接近 100 人，客户群从小型开发者一直到欧盟本身 (https://clever.cloud/blog/company/2026/04/17/clever-cloud-elected-to-deliver-sovereign-cloud-services-for-european-institutions/?from_theconsensus=1)。 Clever Cloud 也是一家工程驱动的公司 (https://clever.cloud/commitments/?from_theconsensus=1)，自己交付了大量基础设施（Sōzu (https://github.com/sozu-proxy/sozu?from_theconsensus=1) 负载均衡器、Exherbo (https://www.exherbo.org/?from_theconsensus=1) Linux 发行版等），正是这种文化使得构建我们自己的数据服务线成为可能。 我被聘用来创建并领导 Materia (https://clever.cloud/materia?from_theconsensus=1)，我们的无服务器数据库线，提供完全无服务器、托管且可扩展的服务。整个策略是使用 FoundationDB (https://theconsensus.dev/project/foundationdb.html)，一个高度可扩展且正确性高的分布式键值存储，我们可以用它作为基础来构建层，这样任何数据服务都可以建立在其之上。 除了 Materia 的工作，我还参与分布式系统值班轮换，我的一个新任务是推动整个工程组织的模拟测试。实际上，在 Clever Cloud，我几乎参与所有涉及分布式系统和数据的事情。 ## 你是如何开始编程的？# 这其实是一个有趣的故事，因为我在 2010 年 9 月写出了我的第一个 “Hello, world”，用的是 C 语言，当时我加入了一所法国工程学校，学习电子和飞机。在电子学第一门课两周后，我发现我对电子学并没有足够的热情来将其作为职业。幸运的是，学校还开设了一门奇怪的小型 C 语言课程，我对此念念不忘。 将爱好转变为职业的是一次在法国银行 Arkea 的兼职实习。我的导师发现我对他们平台的系统方面很好奇，就给我机会直接处理 Hadoop、Kafka 和一个小的测试 HBase 集群，并提供了真实的生产数据集供我操作。我对他感激不尽，因为他是让我专注于分布式系统的唯一原因。 ## 那么 Clever Cloud 的每个数据产品都运行在 FoundationDB 上吗？# 还没有，但每隔几个月这个列表就在增长。我们首批推出的层是 Materia KV (https://clever.cloud/product/materia-kv/?from_theconsensus=1)，我们的 Redis (https://theconsensus.dev/company/redis-labs.html) 兼容服务，我们将其选为启动目标。该协议广为人知，语义足够简单，我们可以将精力集中在底层工具箱上，它处理所有艰巨的工作（多租户、模式演进、键值层级等）。 第二层是 Materia etcd (https://clever.cloud/blog/company/2025/06/27/why-we-finally-built-our-own-managed-kubernetes-etcd/?from_theconsensus=1)，一个更难对付的家伙，涉及监视、租约、修订，它为我们的 Kubernetes 产品提供支持。我们还在开发内部服务，比如领导者选举服务和自制的多租户工作流引擎，我们正在认真考虑将控制平面的部分内容迁移到 FoundationDB (https://theconsensus.dev/project/foundationdb.html) 上。 ## Clever Cloud 是否向 FoundationDB 贡献代码？# 我们在两个不同的方面做出贡献，性质迥异。第一个是更广泛的 FoundationDB (https://theconsensus.dev/project/foundationdb.html) 社区，多年来我一直维护着 Rust 绑定 (https://github.com/foundationdb-rs/foundationdb-rs?from_theconsensus=1)。这个 crate 目前已有 1500 万次下载，除了我们之外，还被其他真实公司和开源项目在生产环境中使用。我们还花大量时间在 FoundationDB 论坛 (https://theconsensus.dev/project/foundationdb.html) 上，帮助其他人解决我们几年前遇到过的那种运维问题。 第二个方面是直接向上游 FoundationDB 本身贡献代码，这对我们来说直到最近才变得可行。随着我们使用量和团队的增长，我们可以投入工程时间直接改进 FoundationDB，目前我们正在与 Apple 和一些关键维护者讨论一组关于多租户的功能。 ## 你在办公室（不管是哪里），窗外能看到什么？# 我住在法国布列塔尼西端的布雷斯特，从我工作的地方可以看到大海和港口中移动的船只。我经常打壁球，所以也经常从俱乐部会所看到球场。 ## 运行 FoundationDB 是什么体验？# 我真的想强调，FoundationDB (https://theconsensus.dev/project/foundationdb.html) 是我操作过的最理智的分布式系统，相比我之前接触过的所有其他系统，比如 Hadoop、HBase、Kafka、ZooKeeper、Pulsar、BookKeeper、RabbitMQ、etcd、Kubernetes 等等。它可能会失败，但总是受其保证的约束。我们从未见过奇怪的行为，尽管多年来我们向它抛出了一些相当危险的操作。但就像任何复杂系统一样，你必须坐下来学习其内部原理才能操作它。 我们在 Clever Cloud (https://theconsensus.dev/company/clever-cloud.html) 不使用 Kubernetes 操作器，因为我们希望拥有 FoundationDB 的深度运维知识，也因为 FoundationDB 对我们的战略如此核心，以至于它位于 Kubernetes 之下，作为 Clever Cloud 其余部分构建的基础层。 这种健壮性也是为什么我们不怕将软件部署到本地 (https://clever.cloud/clever-cloud-on-premises-3/?from_theconsensus=1) 和隔离环境 (https://clever.cloud/clever-cloud-airgap/?from_theconsensus=1) 中。FoundationDB 在模拟中如此严苛地折磨自己，以至于我们信任相同的二进制文件，无论是在公共云的高端硬件上，还是在那些环境中常见的受限硬件和更紧张的网络条件下。例如，我们将托管的 Kubernetes 即服务交付给一个完全隔离运行的客户，使用了与公共云完全相同的堆栈。FoundationDB 在这方面对我们来说确实是一个优势。 ## 你说它可能会失败，但总是受约束的。那么：它是如何失败的？# 我们经历过基础设施故障，其中集群的大部分同时消失，几个机架最终连接在非常慢的网络中，或者某些进程下的虚拟机管理程序资源匮乏。有些甚至是我们自己造成的：有一次我们物理上拔错了 NVMe 驱动器，另一次我们错误地推送了一个错误的 WireGuard 拓扑。 在所有这些过程中，集群从未损坏数据，也从未做过任何我们无法解释的事情。有时它会自行处理问题，比如“这些机器以奇怪的方式不断重启，我会让重要角色远离它们，并将数据重新复制到更安全的地方”。有时它会故意停止进展，并准确告诉我们搞坏了什么，比如“我无法招募新的事务子系统，你在拓扑中犯了一个错误”。 这就是实践中“受其保证约束”的含义：当 FoundationDB (https://theconsensus.dev/project/foundationdb.html) 遇到麻烦时，它会牺牲可用性，而绝不牺牲正确性，并且它会告诉你原因。对我来说，这就是已交付软件和已运维软件 (https://pierrezemb.fr/posts/shipped-vs-operated/?from_theconsensus=1) 之间的真正区别。在我们的规模下，FoundationDB 表现得像已交付软件，无论是在公共云还是本地：我们不依赖脚本、人员或代理来每日照料集群。 ## 每个人都应该运行它吗？# 我想说 FoundationDB (https://theconsensus.dev/project/foundationdb.html) 有两个方面：对于开发者来说，它是一个工具箱，用于编写自己弹性且可扩展的数据服务；对于运维人员来说，它是一个健壮的系统。FoundationDB 的亮点在于，当你需要构建一个存储数据的分布式系统，并且你想要一些定制的东西时。它提供给您的原语是真正困难的那些：数据分布和分片、容错、分布式共识、MVCC、事务和可扩展性能。 在此基础上，您带来其余部分：模式、索引、查询计划和多租户。键布局成为您的模式，事务为您发明的任何数据模型提供可序列化语义。几乎没有任何可用的开源框架，您通常需要构建自己的工具箱，以标准化开发者访问键空间的方式，而不是让他们编写原始的键值对，因此您需要能够预先支付这个成本。 ## 最喜欢的编程语言？# Rust (https://theconsensus.dev/project/rust.html)，毫不犹豫，这出自一个花了多年时间写 Java (https://theconsensus.dev/project/java.html) 和 Go (https://theconsensus.dev/project/go.html) 的人之口。JVM 生态系统从开发者角度来看确实非常出色，但我在转换到 ZGC 之前，花了比我想承认的更多的时间来对大堆（超过 800 GB）进行神秘的 G1 GC 调优。Go 给了我轻松的运维故事（静态二进制、快速构建），但对我倾向于编写的代码来说，开发者抽象太薄了。Rust 同时给了我这两者，再加上出色的工具链。 ## 是什么说服你最终在底层使用 FoundationDB？# Warp 10 (https://warp10.io/?from_theconsensus=1)，来自 SenX 的时间序列数据库，我多年来一直在 OVHcloud (https://theconsensus.dev/company/ovhcloud.html) 与它打交道，并且对其了如指掌。我们直接与 SenX 团队合作完成了 3.0 版本 (https://blog.senx.io/introducing-warp-10-3-0/?from_theconsensus=1)，该版本将底层后端从 HBase 替换为 FoundationDB (https://theconsensus.dev/project/foundationdb.html)。这就是为什么我们的第一个集群从 0 开始，每秒 10 万次写入，吸收了 Clever Cloud (https://theconsensus.dev/company/clever-cloud.html) 平台每月生成的 10TB 遥测数据。我们对默认配置所做的唯一更改就是一些内存调优 (https://pierrezemb.fr/posts/redwood-memory-tuning/?from_theconsensus=1)。 ## 以前有人尝试过在 FoundationDB 上实现 SQL，但从未成功。你们打算怎么做？# 我们正在积极努力。概念验证是一个 PostgreSQL (https://theconsensus.dev/project/postgresql.html) 线协议层，后端基于 Apache DataFusion (https://theconsensus.dev/project/datafusion.html) 和 FoundationDB (https://theconsensus.dev/project/foundationdb.html)，目前这是我们 SQL 层押注的方向。我们现有的 DBaaS 产品已经服务于两种截然不同的用户。 一方面是高阶用户，他们依赖扩展、调优每个查询并使用每个新功能。另一方面是客户，他们只想要一个 SQL 形状的表层来持久存储数据，而无需成为兼职 DBA。我们正在为第二种角色设计 Materia SQL，我迫不及待地想看看一旦真实工作负载落在其上，我们会做出哪些权衡。