扩展预测洞察：Upollo 从 BigQuery 到 ClickHouse 的旅程

2021 年，Cayden Meyer 领导着 Canva 的企业、教育和团队业务。 识别转化、扩展和保留的机会，并了解影响它们的因素，对于帮助 Canva 的销售、客户成功和产品团队集中精力至关重要，但当时没有解决方案可以帮助他们轻松做到这一点。 这是 Cayden 在 Google 担任产品经理时就曾面临的差距，他知道全球数百万家订阅企业肯定也面临着同样的问题。

“当时就是没有工具能为我解决这个问题，”他说。“所以我决定自己构建一个。”

如今，Cayden 的公司 Upollo 通过预测谁有可能流失、转化或扩展以及原因，帮助企业推动收入和增长。 Upollo 分析超过 5000 万用户（每周还增加数百万用户）和 5 亿美元的收入，提供预测性洞察，帮助其客户更快地增长并构建更有效的产品。

Upollo 的使命和产品的核心是需要处理和分析“数十亿甚至数百亿的事件”，其中包括从点击和页面浏览量到计费事件和支持互动的所有内容。 然而，随着公司发展壮大，在服务越来越多的客户的同时处理超过 40 TB 的数据，Cayden 和团队意识到他们现有的数据仓库 BigQuery 已变得成本高昂且效率低下。

为了保持增长并大规模交付实时洞察，他们需要更高效、可扩展、经济高效的解决方案，而他们的搜索将他们引向了 ClickHouse Cloud。

Cayden 在 Google 工作期间开始使用 BigQuery，当时他负责管理 Google Keep、App Engine、Maps 和 Drive 等产品。 BigQuery 的性能和功能给他留下了深刻的印象，因此他选择了 BigQuery 作为 Upollo 的初始数据仓库。

“BigQuery 是一款出色的产品，可以非常快速地运行互联网规模的查询，”Cayden 说。 “然而，它为我们带来了两个关键挑战：成本以及更复杂工作流程（例如我们的用例所需的工作流程）所需的可扩展性。”

随着 Upollo 的发展并吸引了更多客户（“尤其是一些拥有相当大数据集的客户”，Cayden 指出），数据库管理成本稳步增加，直到 BigQuery 的支出占了他们每月账单的大部分。 “我们运行的查询成本高达数千美元，同时眼睁睁地看着我们的数据快速增长，”他说。 “我们做了数学计算，发现无论我们如何定价，它都无法扩展。”

效率低下不仅限于成本。 为了提供分析，Upollo 不得不在 BigQuery 和 Postgres 之间重复工作 - 创建模式、运行查询和传输结果。 正如 Cayden 解释的那样，这种工作流程增加了不必要的延迟并增加了工程开销。 “我们基本上不得不做两次相同的工作，”他说。 “这造成了大量的额外延迟，并为我们的团队增加了巨大的工作量。”

从 BigQuery 到 Postgres 的定期数据传输引入了更多的延迟，而 Postgres 在处理大型聚合时也显得力不从心，经常在处理更大的数据集时变慢或超时。 高成本、延迟以及管理两个独立数据库的操作麻烦相结合，使得向客户交付新鲜的分析变得越来越困难。 这些限制突显了对更精简、可扩展的解决方案的需求，这种解决方案可以消除双数据库方法并简化 Upollo 的工作流程。

当他们开始研究替代方案时，Upollo 团队建立了一些要求。 首先，他们需要一种可以随着其海量数据量经济地扩展的解决方案。 它必须支持实时数据服务，而无需复杂的工作流程和重复，同时处理为 Upollo 的预测功能提供支持的大型分析查询。 性能和可靠性至关重要，他们希望有一个强大的社区支持的平台，以确保它随着时间的推移不断改进。

“市面上有很多有趣、令人惊叹的产品，但我们想要一种我们知道在我们需要规模下使用的解决方案，并且有一个公司社区推动它随着时间的推移变得更好，”Cayden 说。

他们还优先考虑寻找一种托管服务，让他们避免自己维护数据库的麻烦。 “我们不希望我们的工程师将时间花在升级、补丁和维护上，”Cayden 说。 “我们宁愿他们专注于开发新功能和构建出色的产品。”

他们通过开源社区熟悉 ClickHouse，并在 Hacker News 等平台上看到过关于 ClickHouse 的讨论，尤其是在事件繁重的工作负载方面。 通过比较 ClickBench 上的基准测试，并阅读其他公司迁移类似工作负载的经验，他们清楚地意识到 ClickHouse 可能是他们正在寻找的解决方案。 凭借其托管服务产品以及活跃的社区和开源基础，OLAP 数据库有望简化 Upollo 的工作流程并支持其构建高效、可扩展数据基础设施的愿景。

“我们决定试一试，看看它是否能够处理我们的工作负载，并确定它是否对我们具有良好的长期意义，”Cayden 说。

Cayden 在一个下午的 30 分钟内将 Upollo 的核心数据迁移到了 ClickHouse Cloud。 设置非常简单，团队可以快速加载数据并与之交互。 “我们已经能够非常高效、非常快速地提取大量批次的数据，”Cayden 说，并强调他们使用 ClickPipes 在几分钟内移动大量事件数据。

对于 Upollo 的团队和业务而言，其影响是巨大的。 ClickHouse 的性能不仅使查询速度提高了 20 倍，而且还解锁了 Upollo 以前甚至无法尝试的功能。 正如 Cayden 解释的那样，“我们有客户要求组合过滤器来识别更多要销售的人。 以前这需要几分钟或超时，但现在是即时的。”

一个例子是高计数查询和大型分析查询。 以前，他们的数据库在处理大规模计数任务时显得力不从心，通常需要数十秒，甚至崩溃或超时。 使用 ClickHouse，这些相同的查询（鉴于 Upollo 服务的客户通常拥有 1 亿或更多用户，这很常见）在不到一秒的时间内完成。 “过去需要几天甚至几天的工作，现在可以在一两个小时内完成，”Cayden 说。

ClickHouse 还简化了 Upollo 的数据架构。 通过在一个平台上整合存储、处理和服务，他们减少了重复和延迟。 “与管理多个模式并在数据库之间同步相比，这是一个效率更高的设置，”Cayden 说。

最后，ClickHouse Cloud 的存储和计算分离对 Upollo 的成本和工作负载灵活性来说是一个“游戏规则改变者”，Cayden 说。 “我们可以根据需要向上或向下扩展，处理批处理作业而不会影响生产，并避免维护大型集群的高成本。” 这意味着 Upollo 可以随着数据需求的持续增长，优化性能和预算的资源。

当然，没有哪个迁移是没有阵痛的，Upollo 迁移到 ClickHouse 也带来了一系列挑战。 Cayden 说，其中第一个挑战仅仅是理解新系统的学习曲线。 “为了从 ClickHouse 中获得我们想要的一切，我们最终深入研究了代码，以了解产品的工作原理以及如何充分利用它，”他说。 他们还从 ClickHouse 的社区、文档和支持团队获得了帮助。

早期的一个挑战是管理内存，以避免在大型查询期间出现内存不足 (OOM) 问题。 “ClickHouse 团队一直很乐于助人，就解决这些挑战的标志、对核心产品进行更改、将内容添加到路线图等方面提供建议，”Cayden 说。 “我们仍然偶尔会遇到 OOM，但频率远低于以前。”

在 Upollo 采用 ClickHouse 的同时，他们还引入了 dbt（数据构建工具）来简化他们的数据工作流程。 dbt Cloud 不支持 ClickHouse，因此 Upollo 团队创建了自己的工具来弥合差距。 当他们报告一个长期存在的、阻碍他们工作的错误时，ClickHouse 团队第二天就立即介入并提供了修复程序。

在整个过渡过程中，他们需要调整 ClickHouse 的各种标志和设置以优化性能。 “有一些明显的缺点，”Cayden 说，并指出直接开箱即用地运行 ClickHouse 可能并不总是能提供最佳性能。 但他说，ClickHouse 团队提供了指导，帮助 Upollo 的工程师调整平台以处理他们独特的数据密集型工作负载。

对于任何考虑使用 ClickHouse Cloud 的人，Cayden 的建议很简单：试一试。 “将数据传输过来并开始使用它比您想象的要容易，”他说，并补充说 ClickHouse 的试用额度使探索和测试数据库变得容易

ClickHouse 的开源社区和全面的文档使 Upollo 的过渡更加顺利。 “有一些令人难以置信的资源可用，”Cayden 说。 他还建议联系 ClickHouse 的友好人士加入 beta 计划，并指出这是抢先体验新功能的好方法——“只要您对处于前沿感到满意即可。”

随着他们的核心数据迁移完成，Cayden 和团队期待通过迁移更多工作负载并利用倒排索引等新功能来深化他们与 ClickHouse 的关系。 “我们梦想的状态是，我们所有可以在 ClickHouse 上高效运行的分析工作负载和查询都可以在 ClickHouse 上运行，”他说。

对于 Upollo 而言，迁移到 ClickHouse 提高了成本效率和性能，使他们能够扩展并向客户交付预测性洞察，而不会受到之前面临的限制。 查询运行速度更快，大型数据批次在几分钟内提取，Upollo 的工程师可以专注于创新而不是维护。

“ClickHouse 让我们能够以 BigQuery 根本无法做到的经济高效的方式进行扩展，”Cayden 说。

要了解有关 ClickHouse 如何提高数据操作可扩展性的更多信息，请免费试用 ClickHouse Cloud 30 天。