OpenReplay：单机ClickHouse支撑日均数十亿事件

OpenReplay是一个为开发者构建的会话回放和产品分析平台。通过了解用户如何与其应用交互，产品团队可以使用该平台来识别摩擦点、理解用户行为，并更快地排查和解决问题。

OpenReplay 的创始人兼 CEO Mehdi Osman 将其描述为面向前端工程师的可观测性。“就像坐在用户旁边一样，”他说。“你不必给他们打电话，你不必做访谈。你只需安静地坐着，准确观察他们在做什么。”

OpenReplay 最大的差异化优势之一是它完全可自托管。“这为我们的最终客户提供了绝对的数据控制和治理，”Mehdi 说。它也是开源的，这使团队能够根据社区反馈快速迭代，并且与该平台构建在其他开源项目（如 ClickHouse、Postgres、Kafka 和 Redis）之上相契合。

正如 Mehdi 所说，数据挑战分为三个部分。后端必须为每个客户每天摄取数 TB 的数据。“任何一粒沙子都可能影响整个摄取管道，”他说。然后 OpenReplay 必须将这些数据转化为有用的东西，这就是“ClickHouse 发挥作用的地方”。而所有这些都必须在每个客户自己的环境中运行，并且对客户和 OpenReplay 的小团队来说，运营开销最小。

我们与 Mehdi 和高级软件工程师 Taha Yassine Kraiem 进行了交流，聊了聊他们的历程，包括 OpenReplay 最大的客户如何在一个垂直扩展的 ClickHouse 实例上每天摄取数十亿个事件，并实现亚秒级查询。

用 ClickHouse 替换 Postgres

早在 2019 年，OpenReplay 的所有内容都运行在 AWS 上托管的 Postgres 上。事务数据库处理元数据没问题，但行为事件（构成会话的点击和页面浏览）则是另一回事。“它不是分析数据库，”Mehdi 说。“有些我们无法在 Postgres 上做的事情需要很长时间才能运行。”团队尝试对表进行分片来弥补，但正如 Mehdi 所说，“这造成了一个我们无法处理的运营混乱。那是一条死路。”

性能问题的一个很好的例子是 OpenReplay 的会话搜索。它可以按顺序组合多种事件类型，并对每种类型设置条件。团队的目标是响应时间低于一秒。即使在添加索引、分区和分片之后，典型的 Postgres 查询也要大约三秒才能返回，有些甚至长达 10 秒。

迁移到 ClickHouse 后，平均响应时间降至约一秒。“我们永远无法用 Postgres 实现这一点，”Mehdi 说。“我的意思是，我们可以，但那意味着大量的工作、大量的分片、我们没有的运营开销。”

存储也是类似的情况。在 Postgres 中增长到约 1 TB 的事件表在 ClickHouse 中压缩到 1 或 2 GB。“基本上就像什么都没有一样，”Taha 说。“而且即使在压缩数据上运行查询仍然超级快。”

Postgres 的另一个问题是保留期。OpenReplay 将会话数据保留一段设定的时间，然后将其删除。在 Postgres 中，这意味着脚本、删除和清理操作会锁定表并强制重启。“这完全是一团糟，”Taha 说。“它花费了我们大量的时间和精力，有时某件事出了问题，我们还得修复它。”

由于客户是自托管的，清理也意味着在流量较低的周末与每个客户进行协调。“那需要好几天，因为只是清理、锁定表，你根本不知道发生了什么，”Mehdi 说。

借助 ClickHouse 的 TTL（生存时间）特性，保留期在安装时设置一次。“对于某些客户来说是三个月，对于另一些客户来说是一年，对于其他客户来说是一个月，”Mehdi 说。“我们只需在那里设置好，就这样，数据就得到了处理。”对象存储上的生命周期规则以同样的方式处理录制文件，而 Postgres 只保存元数据。与客户进行周末清理通话已成为过去。“使用 ClickHouse，”Taha 说，“我们每六个月与他们联系一两次，只是为了检查是否有任何需要进行的维护。”

“那个 TTL 真是太有价值了，”Mehdi 补充道。“我知道这是一个小功能。你会谈论 JSON、缓存和查询。但 TTL 为我们节省了太多的周末。”

OpenReplay 如何构建在 ClickHouse 之上

如今，ClickHouse 处于 OpenReplay 数据管道的中心。每个行为事件都落入一张表中；从那里，一系列 物化视图 在每次插入时触发，转换行并将它们传递下去。“每一个都会提取和转换数据，直到到达其目标表，”Taha 解释道。“它运行得非常快。我们只需更改数据库，就这样。我们不必编辑其背后的任何代码。”

这与管道过去的工作方式相比是一个显著的变化，当时在表之间移动数据意味着要么使用 Postgres 触发器，要么使用 Go worker（管道所使用的语言），而且对表结构的任何更改都需要对 worker 进行相应的更改。如今 Go worker 仍然处理管道的一部分，但借助物化视图，过去需要两天开发和调试的更改现在大约需要半天。“将所有内容集中在 ClickHouse 中使生活变得简单得多，”Taha 说。

Mehdi 补充说，物化视图也是新功能的起点。“当它是一个新功能，我们还不确定数据结构时，我们依赖这些物化视图，因为我们可以非常快速地处理数据，”他说。“我们可以删除它，再次重做。经过几次迭代，当我们确定后，我们就把那部分拿出来放到 Go 代码中，因为这样插入会快得多。”

他还强调了 ClickHouse 的 原生 JSON 支持这为自定义事件打开了大门。虽然点击和页面浏览量会被自动捕获，但进行严肃产品分析的客户希望自己埋点事件（例如带有名称、正文和属性列表的“payment done”或“order sent”）。“如果没有 ClickHouse 对 JSON 的支持，我们就做不到这一点，”Mehdi 说，“因为你不仅要插入这些事件，还需要在之后非常容易地查询它们，并构建所有这些漏斗、热图和流程。在幕后，ClickHouse 把这些属性当作列来处理，而你甚至察觉不到。”

这一切都建立在一个简单到一两句话就能描述清楚的模式上。“我们基本上有两张主表，”Mehdi 说。“一张是包含录制元数据的会话表，另一张是事件表，一张所有事件都被插入其中的大型扁平表。两张表，很容易理解，但我们却能在其上执行非常强大的查询。”

单个实例上每天数十亿事件

OpenReplay 面对的数据量范围很广。有些客户每天摄入一两百万个事件。另一些客户每天摄入数十亿个事件，数据量高达每天 6 TB。即使在这样的规模下，每个部署也运行在单个 ClickHouse 实例上，这是为运行在客户基础设施上的产品做出的有意选择。团队不进行分片或集群，而是垂直扩展，随着客户增长增加内存和 CPU。正如 Mehdi 所说，“我们甚至还没有触及 ClickHouse 能处理的深度。”

他举了一个客户的例子，这是一家价值数十亿美元的金融科技公司，之所以选择 OpenReplay，是因为它可以自托管。“他们可以在自己的服务器上运行整个平台，并且完全掌控数据隐私和安全，”他说。他们的两大主要用例是缺陷复现和支持。用户来信说他们无法完成支付或签署合同。支持人员可以与他们实时共同浏览并在其屏幕上标注。如果这样仍不能解决问题，开发人员会打开开发者工具重放该会话。

这家金融科技公司的部署每天记录数十万个会话，每个会话包含数百个事件。这加起来每天有数亿个事件，全部进入 Kubernetes 上的单个 ClickHouse 实例。“每当他们增长时，每隔几个月，我们就垂直扩展它，”Mehdi 说。“我们不必分片，也不必添加其他 ClickHouse 实例。因此运营成本相当低，这在自托管环境中极其重要。”

他补充说，如果 OpenReplay 仅是 SaaS，那么这种权衡会有所不同。“我们可能会订阅 ClickHouse Cloud 服务，仅此而已，”他说。“但我们把整个产品部署到他们的服务器上，这就是为什么我们必须非常精简。”

重放时间，以及下一步

在内部，OpenReplay 跟踪一项它称为“重放时间”的指标，衡量从会话发生到开发人员能够点击播放并观看它所需的时间。

“大规模摄入必须是实时的。如果你只捕获几千个事件，你不会察觉到。但如果你每天捕获数 TB 的数据，任何小的故障都可能产生影响，并且需要一两天才能从滞后中恢复。因此拥有一条精简的流水线非常重要，而 ClickHouse 是其中的重要部分。” — Mehdi Osman，OpenReplay 的创始人兼 CEO

在查询方面，目标是产品中的每个视图，从搜索到漏斗、热图和流程图，都在两秒内返回。团队最近启用了 ClickHouse 的 查询缓存，因此一位工程师运行的查询对几分钟后的同事来说就是即时的。“缓存就是那种你启用后它就能正常工作的东西，”Mehdi 说。当被问及是否有任何关于针对 ClickHouse 编写查询的内容想补充时，Taha 的回答也是一样。“没什么特别的，”他说。“它就能正常工作。”

OpenReplay 现在正使用 ClickHouse 构建一项即将推出的代理功能，该功能会自动审查会话录像并主动发现问题，因为没有团队能每天观看数十万条录像。“可以把它想象成一个分析师团队，他们的工作就是像人一样审查所有用户会话，”Mehdi 说，并补充说代理产生的每一条追踪记录都会进入 ClickHouse：“这就是我们用于评估的东西，这就是我们用于故障排查的东西，这就是我们用来了解代理表现如何的东西。”

七年来，ClickHouse 已成为 OpenReplay 信任的、运行在其无法控制的 infrastructure 上的少数标准组件之一。客户将数据保留在自己的服务器上，而 OpenReplay 的技术栈保持足够精简，以便他们自行运行。“所有这些组件都是出于特定原因被选中的，”Mehdi 说，“即非常低的开销，即使是在为客户部署以及之后维护时也是如此。”