SIGQ为何从BigQuery迁移到ClickHouse？

SIGQ股份有限公司提供了一款专注于事件管理的AI代理“Incident Lake”。该公司原本以BigQuery作为数据平台，但在大约半年前迁移到了ClickHouse，目前已在ClickHouse上对多家客户的工作负载进行了生产环境部署。

4月下旬，在东京都内某地，ClickHouse联合创始人兼CTO Alexey Milovidov先生（以下简称Alexey）与SIGQ株式会社代表董事金筑敬晃（以下简称金筑）进行了一场对谈。本文将探讨ClickHouse是如何应对SIGQ所面临的挑战的，并深入剖析此次迁移的背景。

本文是对谈文章的前篇。后篇请参阅《从数据与事件管理探寻AI时代SRE的发展方向》。

C++工程师开发出用于分析全球最大规模流量的数据库的经过

问：Alexey先生自2009年起一直从事ClickHouse的开发工作，请问您最初是出于什么契机开始涉足数据库领域的？能否请您谈谈当时面临的首要挑战？

Alexey：我原本并不是数据库开发人员，而是一家大公司的C++工程师。我负责的项目是一项为网站运营者提供访客分析报告的服务。在此过程中，我遇到了一个巨大的挑战：在每天产生数千亿条事件的庞大平台上，必须实现报告的几乎无限定制，并提供能够获取用户所需任何汇总数据的功能。此外，还要求具备即时的实时性——用户定义报告的瞬间，结果就能立即显示出来。

显然，MySQL无法满足这一用例的需求，于是我开始尝试各种数据库。在此过程中，我了解到列式数据库和大数据平台的存在，并从性能、压缩率和成本等方面对现有产品进行了比较。结果，我开始认为，如果采用专门针对聚合、排序和过滤的列式存储，或许自己也能开发出来。于是，我开发出了名为“OLAPServer”的原型，并发现它的运行效果比现有系统更好。

※OLAP（在线分析处理）：一种能够对存储在数据仓库等中的海量数据进行即时多维分析的技术。例如，可用于按地区、时间等多重维度分析销售数据。

Q. 也就是说，这最终发展成了现在的ClickHouse。

Alexey：当时虽然还没有关于ClickHouse的明确愿景，但我隐约希望将系统通用化，以便能够处理各种查询。起初我利用业余时间开发，后来甚至开始在工作时间投入其中，最终于2012年发布了ClickHouse的首个版本。该版本不仅被我的团队使用，还被公司内部其他部门，如电子商务和商业分析部门所采用。此后，在参加技术会议的过程中，我意识到此类数据库存在极大的市场需求。许多企业的工程师都在各自独立开发与我的原型类似的系统。我确信应该将其开源，于是说服公司，并于2016年将其发布。今年6月，恰逢ClickHouse开源十周年。

Incident Lake面临的BigQuery限制

问：SIGQ最近将Incident Lake的数据平台从BigQuery迁移到了ClickHouse Cloud。此次迁移是为了解决哪些问题？

金筑：首先，我简要介绍一下Incident Lake的特点。Incident Lake是一个集成了AI技术的事件管理平台。与许多面向开发者的现有工具不同，我们的工具主要面向负责统筹事件响应的管理层。

在事件响应现场，故障处理和报告撰写请求层出不穷，而这些工作都极具挑战性。为此，Incident Lake的AI代理将协助完成时间线生成和报告生成等工作。因此，一旦发生故障，Incident Lake不仅会收集错误日志，还会收集Slack和Teams等通信日志。

Alexey：也就是说，利用收集到的数据自动生成摘要，对吧。

金筑：正是如此。而且，在实现这一机制的过程中，最关键的是数据时效性。如果无法掌握当前数据是否准确、哪些信息是最新的，那么由AI代理提供的支持从根本上就无法令人信服。

我们保存的数据分为两类：一类是用户消息等原始数据，另一类是向量化数据。所有生成的数据和报告都经过向量化处理，从而实现了类似语义搜索的功能。

为了跟踪瞬息万变的事件响应情况，数据时效性至关重要。因此，必须根据最新的时间线更新所收集的数据。

然而，当时的BigQuery存在一项限制，即无法更新刚插入的数据，这给保持数据时效性带来了难题。因此，我们决定借此机会迁移到ClickHouse Cloud。

Alexey：ClickHouse的用户中，有许多企业多年来一直使用BigQuery。与SIGQ的情况类似，不少企业是因为延迟问题而迁移过来的。此外，由于ClickHouse的功能更丰富，也有许多企业出于这一原因进行迁移。另外，成本问题也是关键因素。BigQuery采用按量计费模式，根据每次查询和处理的数据量收费。对于偶尔手动执行查询的用户来说还算可以，但对于需要执行大量查询的用户——尤其是AI代理——则不太适用。AI代理经常在一个请求中执行10次、20次甚至更多的查询，这会导致BigQuery的成本急剧上升。

Q. Incident Lake是如何利用ClickHouse的功能的？特别是，请问金筑先生是否感受到某些功能带来的实际价值？

金筑：举个例子，ClickHouse具备近似向量搜索功能。在Incident Lake中，我们利用这一功能来获取类似的事件。

在事件响应过程中，掌握过去是否发生过类似案例至关重要。然而，仅通过简单的向量搜索来查找类似事件，实际上非常困难。因此，Incident Lake利用ClickHouse的近似向量搜索功能，将相似度以数值形式呈现出来。客户对这一相似度显示及类似事件搜索功能给予了高度评价。

在迁移到ClickHouse之前，我们曾自行实现相似度计算功能，但这给系统带来了巨大的工作负载。通过利用ClickHouse的近似向量搜索功能，我们不仅大幅降低了系统负载，同时也提升了Incident Lake的价值。

问：听说SIGQ是日本首家采用ClickHouse近似向量搜索功能的企业。

金筑：是的。从这项新功能在ClickHouse Cloud上上线的那一天起，我们就开始使用了。其实，我们一直都在期待这个功能的发布，甚至还曾向ClickHouse团队询问过“什么时候能用上”。

Alexey：有这样的客户，我们真的感到非常高兴。我们一直在寻找能够利用实际业务中的工作负载来验证新功能的技术合作伙伴。或许正是金筑先生的热情，推动了该功能在ClickHouse Cloud上的发布。

为什么全球顶尖的AI企业会选择ClickHouse？

Q. ClickHouse 作为一款高速分析数据库而闻名，能够对 petabyte 级数据和复杂的遥测数据进行查询，并在亚秒级（不到 1 秒）内返回结果。它为何能够同时兼顾如此大规模的数据和实时性呢？

Alexey：首先，作为一项基本前提，在ClickHouse中无需将事务（OLTP）数据与分析（OLAP）数据分离。关于大数据的一个典型误解是，认为事务数据和用于分析的高时效性数据应当分开管理。

※OLTP（在线事务处理）：一种旨在准确读写少量数据（事务）的技术，例如银行转账和电商网站的订单处理等。

例如，“将所有历史数据存储在S3或RDBMS中，仅将实时分析所需的小量新鲜数据放入分析数据库”这种想法，是一种常见的误解。但实际上，通过结合多种技术，既可以实现接近实时的数据插入，又能确保分析查询的响应时间控制在亚秒级以内。具体而言，这些技术包括能够实现高速查询处理的列式存储，以及支持高速数据插入的MergeTree数据结构等。

此外，ClickHouse 将所有数据存储在共享存储中，并结合了分层缓存机制。通过将缓存部署在本地机器的 SSD 和内存中，既能为高频访问的数据提供媲美内存的性能，又能为大部分数据提供 NVMe SSD 的性能，同时还能让整个系统充分利用对象存储的成本效益。

能够将所有这些功能整合为一个统一的系统，正是ClickHouse的优势所在。

问：包括OpenAI、Anthropic在内的许多全球顶尖AI企业都在ClickHouse上部署可观测性解决方案。他们选择ClickHouse的原因是什么？

Alexey：答案很简单。因为AI企业所需的庞大数据量，是其他任何技术都无法处理的。实际上，我们尝试过许多技术，但都失败了。然而ClickHouse却出人意料地运行良好，因此他们一直沿用至今。

ClickHouse的优势在于其可扩展性。人工智能企业必须处理每天涌入的数十拍字节规模的数据。借助ClickHouse，可以构建由数千台服务器组成的集群，并在其上执行分布式查询。此外，还能高效地为海量日志数据创建文本索引。与现有系统相比，ClickHouse在处理这些任务方面表现得更为出色。

此外，高数据压缩率也是其一大特点。Comcast和eBay等企业已实现了20倍、30倍的压缩率。由于其他系统不具备如此高的存储效率，因此在需要存储数十拍字节级数据的环境中，ClickHouse堪称独领风骚。此外，通过与对象存储相结合，它几乎能提供完美的解决方案。

事实上，OpenAI、Anthropic、特斯拉和xAI等顶尖AI企业都在大规模利用ClickHouse来实现可观测性，并以原有的规模对最新鲜的数据进行分析。

金筑：刚才的讲解让我豁然开朗。节点是如何进行横向扩展的，数据又是如何分布的。理解了这一机制后，就能直观地明白ClickHouse为何能够持续处理拍字节级的数据了。 

数据库的未来在于OLTP与OLAP的融合

问：刚才Alexey提到“在ClickHouse中无需将事务数据与分析数据分离”，但在AI时代的大规模数据基础设施中，这两者今后是否会走向融合？请两位谈谈对下一代数据库的展望。

金筑：其实，我在从事业务工作的同时，也在数据库领域开展研究，主要研究一种名为HTAP的方法。在前一份工作中，我曾参与大规模数据分析系统的运维，但一直为将数据从OLTP传输到OLAP时的延迟管理问题所困扰。因此，我对能够彻底消除数据整合工作本身的HTAP方法产生了浓厚兴趣，并开始了相关研究。今年3月，我还在EDBT/ICDT（欧洲最著名的数据库会议之一）同期举办的DOLAP会议上发表了论文。

※HTAP：在单一平台上同时执行事务处理（OLTP）和分析处理（OLAP）的技术

HTAP当前面临的挑战是数据同步。在内部，虽然会将写入OLTP的数据传输到OLAP，但这一过程成本高昂，且难以维持数据流的畅通。明明希望立即对写入的数据进行分析，但如果查询延迟长达1小时，最终还是无法掌握最新情况。

Alexey：在构建HTAP数据库时，一个主要挑战在于不同工作负载所需的内部数据结构存在根本性差异。OLAP数据库需要采用列式存储来实现高速处理，并需要在压缩块上建立稀疏索引。然而，这种数据结构难以高效地读取或更新单条记录。另一方面，OLTP数据库则需要针对每条记录建立精细的索引，以及能够快速替换记录的数据结构。

因此，有两种方法。一种是在单一数据结构中寻找折中方案的方法。内存数据库就是其典型代表，但实际上并未取得太大成功。这是因为在处理大规模数据时，统一的数据结构并不太适合分析处理，一旦数据无法全部装入内存，系统就会崩溃。

另一种方法是高速同步两种不同数据结构。目前，这种方法更为普遍。ClickHouse Cloud也采用了这种方法。具体来说，我们通过在高速NVMe存储上部署ClickHouse和ClickHouse Postgres，并使两者保持同步。这样，ClickHouse就能以合理的延迟访问Postgres上的数据。

金筑：在Incident Lake项目中，我们也同时使用了Postgres和ClickHouse。虽然目前两者尚未实现数据同步，但我们希望尽可能将更多数据整合到ClickHouse中。ID的唯一索引以及SQL兼容性等问题目前还存在一些障碍，请问未来是否有相关的开发计划？

Alexey：答案是肯定的，目前正在开发中。此外，关于SQL的兼容性，经SQL Logic Test测试显示，兼容性已达到97%以上，充分支持标准SQL的功能。

AI时代的数据基础需要什么

通过迄今为止的对话可以看出，SIGQ迁移至ClickHouse的原因不仅仅在于降低成本。更根本的动机在于满足AI时代事件管理对数据基础架构的要求，而这些要求与ClickHouse的发展历程和技术特性高度契合。

在后篇中，我们将深入探讨在该数据基础架构之上，AI时代下的事件管理和SRE模式将发生怎样的变化。