ClickHouse Cloud：Gumlet 处理每日数十亿视频和图像请求的关键

每天，一站式媒体托管和流媒体解决方案 Gumlet，为印度最大的新闻机构、电子商务公司和社交媒体平台处理超过 20 亿次的视频和图像请求。该平台每天为超过 1 亿用户提供服务，旨在流畅、可靠且以闪电般的速度交付内容。

但快速交付仅仅是故事的一部分。Gumlet 还跟踪各种指标，如播放时长、重新缓冲率、带宽使用情况等，帮助客户微调性能并保持用户参与度。与简单的网络流量指标不同，视频分析非常复杂，需要实时捕获和处理时序数据，以考虑暂停、跳过和缓冲等行为。随着 Gumlet 的规模扩大，管理跨越 9000 亿行数据的洞察力变得越来越昂贵且复杂。

在 2024 年 9 月班加罗尔的 ClickHouse 聚会上，Gumlet 联合创始人兼首席执行官 Aditya Patadia 分享了迁移到 ClickHouse Cloud 如何帮助团队克服这些挑战，并改造他们的分析管道以支持未来的增长。

最初，Aditya 和团队依赖 BigQuery 来管理他们的分析。通过与其 CDN 提供商 Fastly 的直接集成，该公司可以摄取和查询数据，而无需任何额外的工具。然而，随着 Gumlet 的运营规模扩大到每天数十亿行，他们开始体验到系统中的裂缝。

Aditya 说，最紧迫的问题是成本螺旋式上升。BigQuery 的定价模式基于摄取和每次查询收费，变得非常昂贵。“当您实时同步数据时，BigQuery 会产生摄取成本，并且每次查询都会增加费用，”Aditya 解释说。“任何使用过 BigQuery 的人都知道这些成本累积起来有多快，这取决于您触发的查询类型和数量。”

另一个问题是 BigQuery 限制了 100 个并发查询，这为 Gumlet 的客户造成了瓶颈。“如果我们的客户需要触发超过 100 个分析 API 请求，他们就会失败或进入队列，”Aditya 说。“我们可以切换到 BigQuery 专用计划，但这会带来自身的一系列问题。”

存储成本增加了进一步的复杂性。BigQuery 基于逻辑存储收费，逻辑存储根据数据的理论大小而不是物理占用空间计费，这意味着 Gumlet 为每个数据点的完整大小付费，即使数据很小或重复也是如此。例如，一个简单的 HTTP 状态代码，如“200 OK”，表示请求成功，将被收取 32 字节的费用。“当您存储数十亿个这样的条目时，成本可能会很快失控，”Aditya 说。

意识到 BigQuery 的局限性，Aditya 和团队开始评估可以更好地处理他们数据需求的替代方案。他们的标准很简单：可扩展的存储、固定的计算成本、出色的文档，最好是无需维护。“我们是一个相对精简的远程团队，由 12 名工程师组成，没有 SRE 或 DevOps 团队，”Aditya 说。“我们想要一些可以快速运行的东西，而且我们完全不必管理。”

他们考察了几个选项，包括 Athena、Redshift、Snowflake 和 ClickHouse。Athena 由于查询速度慢而被早期排除，而 Redshift 提供了更好的性能，但存储和计算成本更高。与此同时，Snowflake“极其昂贵”的定价使其成为 Gumlet 规模的不可行选择。“我们稍微测试了一下 Snowflake，但对于我们拥有的数据规模而言，其定价实在太高，无法进一步探索，”Aditya 说。

最终，ClickHouse 成为最适合 Gumlet 需求的方案。它提供了可扩展的存储、可预测的成本和出色的性能。此外，其文档使 Aditya 和团队可以轻松上手，而无需陡峭的学习曲线。

在评估了开源版本和托管版本后，他们选择了 ClickHouse Cloud。“当 ClickHouse Cloud 首次推出时，我们是最早的客户之一，”Aditya 说。“它是自助式的，易于设置。我们直接开始使用它，并且从未回头。”

迁移到 ClickHouse 不仅仅是将一个数据库换成另一个数据库。它要求 Aditya 和团队重新思考他们的整个数据管道。

第一步是重新设计摄取过程。以前，Gumlet 依靠其 CDN 提供商 Fastly 将数据直接推送到 BigQuery 中。在迁移到 ClickHouse 后，他们实施了一个自定义的摄取管道，使用基于 Golang 的服务在将数据写入数据库之前对其进行处理和批处理。ClickHouse 最适合大批量插入，因此他们优化了管道，使其一次写入 20,000 行。“这使我们能够在保持插入频率足够高的同时获得最佳性能，以进行实时分析，”Aditya 说。

Gumlet 基于 ClickHouse 的新分析管道

他们还利用 ClickHouse 的内置集成来简化其工作流程的其他部分。例如，来自其 CDN 和内部服务的日志存储在 AWS S3 中，可以使用其 S3 导入功能直接摄取到 ClickHouse 中。这消除了对复杂 ETL 管道的需求，并使其更容易分析数十亿行的日志数据。

查询性能是另一个关注领域。该团队使用 ClickHouse 的 物化视图来预聚合常用分析请求的数据，例如播放指标和重新缓冲率。正如 Aditya 解释的那样，物化视图使他们能够预先计算结果并提供实时仪表板，而不会增加延迟。

对于 Aditya 和 Gumlet 团队来说，迁移到 ClickHouse 带来了许多重大改进，从成本到性能和可扩展性。

最重要的胜利之一是成本可预测性。与 BigQuery 可变的每次查询定价模式不同，ClickHouse Cloud 提供固定的计算成本，只有存储成本与使用量挂钩。“我们知道我们每个月要为计算支付多少费用，这非常重要，因为那是成本最高的部分，而不是存储，”Aditya 说。

另一个巨大的好处是摄取速度的提高。通过高效地处理批量插入并利用 ClickHouse 的 S3 集成，他们消除了对复杂 ETL 流程的需求。“自从迁移到 ClickHouse 以来，我们只是将所有内容都扔给它，它在不到两分钟的时间内处理所有内容，”Aditya 说。

Aditya 还强调了切换到新系统后的快速响应时间，并且对并发查询的数量没有限制。“我们可以一次运行 500 个查询，它可以非常快速地处理它们——在两三秒内，而不是几分钟，”他说。“它是世界上最快的数据库。你无法反驳这一点。”

最后，作为一项托管服务，ClickHouse Cloud 简化了 Gumlet 的运营，帮助他们卸载了扩展、复制和备份等任务。这释放了宝贵的工程资源，使团队可以完全专注于改进他们的产品。

虽然 Gumlet 迁移到 ClickHouse 是成功的，但与任何重大变更一样，它也带来了一些经验教训，Aditya 与任何考虑迁移到 ClickHouse 的人分享了这些经验。

其中之一是需要调整工具和工作流程以适应新系统。例如，Gumlet 决定切换到 Metabase 以满足其商业智能 (BI) 需求，因为 ClickHouse 缺乏对其以前的 BI 工具 Google Data Studio 的原生支持。同样，并非所有 ETL 工具目前都支持 ClickHouse，因此团队不得不选择与其数据处理需求兼容的替代方案。

迁移还突出了模式设计的重要性。“ClickHouse 需要预先仔细规划，特别是对于主键，”Aditya 说。“稍后更改主键意味着删除并重新创建表，因此第一次就正确设置非常重要。”他还强调了 ClickHouse 功能（如 LowCardinality 和 Delta 压缩）在提高查询性能和降低存储成本方面的价值。

最后，团队确定了一些技术考虑因素，例如从 DateTime64 切换到标准 DateTime，以提高大型数据库的性能。虽然这些调整需要一些前期工作，但它们有助于提高数据管道的效率和成本效益。

Gumlet 的 ClickHouse 之旅是变革性的，它帮助公司扩展了其分析能力，同时保持了成本效率、可预测性和性能。

通过重新构想其数据架构并利用 ClickHouse Cloud 的高级功能，Aditya 和团队构建了一条每天能够处理数十亿行数据的管道。从更快的摄取到闪电般快速的查询响应，迁移意味着 Gumlet 可以提供可操作的实时洞察，帮助其客户优化性能。

凭借 ClickHouse 为其分析提供支持，Gumlet 拥有灵活性和性能，可以持续增长，同时忠实于其为印度各地的客户提供最快速、最可靠的视频托管和流媒体服务的使命。

要了解有关 ClickHouse 的更多信息，并了解它如何改变您公司的数据运营，免费试用 ClickHouse Cloud 30 天。