内部运营干货：手把手教你借助 ClickHouse 搞定产品运营分析

ClickHouse助力构建产品分析解决方案

最新推荐文章于 2025-04-19 21:47:39 发布

原创

最新推荐文章于 2025-04-19 21:47:39 发布 · 1.4k 阅读

23 ·

CC 4.0 BY-SA版权

文章标签：

#clickhouse #产品运营

本文字数：17525；估计阅读时间：44 分钟

作者： Chloé Carasso

本文在公众号【ClickHouseInc】首发

引言

ClickHouse 的名字来源于“Clickstream（点击流）”和“Data Warehouse（数据仓库）”的结合，体现了其最初的设计目标：记录来自全网用户的每一次点击。尽管如今 ClickHouse 已广泛应用于多种场景，它依然是捕获 Web 事件的分析领域中极受欢迎的工具。产品分析作为这一领域的自然延伸，致力于追踪和分析用户与产品的交互行为，从而洞察用户行为、参与度和满意度等关键指标。

在本篇博客中，我们将带你学习如何使用 ClickHouse 构建强大的产品分析解决方案，分享关键数据模式设计的经验、产品经理和增长营销人员常用的典型工作流，以及提取有价值指标的关键查询方法。这篇指南基于我们在开发和运营内部产品分析平台 Galaxy 时积累的经验。Galaxy 经过近两年的实际运行，不仅提供了可靠的洞察，还展现了强大的稳定性。

Galaxy 每天处理超过 200 亿个事件、14 TB 的数据，帮助我们定量评估每一次设计和产品决策的效果。通过支持 A/B 测试和常见用户操作路径的分析，这一平台使我们能够持续优化和改进 ClickHouse Cloud 的用户体验。

什么是产品分析？

产品分析是指通过收集、分析和解释用户在产品中的行为数据，发掘能够指导决策的深刻洞察。相比许多人熟悉的 Google Analytics 等工具提供的基础 Web 分析，产品分析更加关注用户在产品内的操作行为和使用模式。

产品分析能够回答许多关键问题，例如：哪些用户行为会带来更高的参与度或导致用户流失？用户在操作中会遇到哪些阻碍？用户是如何浏览产品功能的？通过记录和分析点击等事件，产品团队可以更深入地理解用户需求，改进用户体验，并优化关键指标，如转化率和留存率。

这一持续反馈的循环机制对于产品经理和增长营销人员来说尤为重要，因为它能够帮助他们基于数据做出调整，从而提升产品的使用率、用户参与度和整体满意度。

为何 ClickHouse 是产品分析的首选？

与 Web 分析类似，产品分析需要处理由用户行为（如点击、滑动和应用内交互）生成的大量事件驱动数据。针对这些数据，产品经理和增长营销人员提出的问题往往既涉及时间维度又十分复杂，例如：用户在注册流程中中断的关键点是什么？哪些使用模式能带来更高的客户生命周期价值？哪些功能需要优化或重新设计？

这种复杂的数据访问模式要求一个高性能的数据存储系统，能够同时满足快速数据摄取、复杂查询和高并发访问的需求。而 ClickHouse 的列式存储架构、实时数据摄取能力以及处理海量数据的高效性，正是应对这些挑战的完美选择。更重要的是，借助 SQL，用户几乎可以自由地提出任何问题。

ClickHouse 的列式设计结合数据插入时的排序特性，使其在存储效率上具备显著优势。例如，在大多数文本数据中，可实现高达 15 倍的压缩。这种能力让用户能够低成本地存储每一条交互记录，同时保留数据的完整性。无需提前定义所有分析需求，用户可以随时利用存储的数据解决未来可能出现的新问题。这种灵活性极大地降低了数据存储的限制。

以我们的 Galaxy 平台为例，我们实现了至少 14 倍的压缩率，成功支持了大规模的历史数据存储和深度回溯分析。

ClickHouse 的高效聚合能力使得用户可以实时回答复杂问题。对于产品经理而言，查询结果的延迟从分钟缩短到秒级。例如，你可以在不到一秒的时间内计算获客率、激活率和转化率随时间的变化趋势。这种即时响应极大地提升了工作效率。

实时分析产品改动的影响同样至关重要。在 ClickHouse 的支持下，产品经理可以快速进行 A/B 测试，评估新功能对漏斗关键指标的影响。这种敏捷性让表现优异的功能得以保留，而未达到预期的功能则能快速优化或重新设计，从而不断改进产品体验和用户满意度。

自建还是购买现成方案？

凭借 ClickHouse 在产品分析场景中的出色性能，许多解决方案（如 PostHog）都将 ClickHouse 作为其核心数据存储和分析引擎，这并不令人意外。但这也引出了一个值得探讨的问题：你应该基于 ClickHouse 自建解决方案，还是选择像 PostHog 这样的开箱即用产品？

答案取决于多个因素，包括你对事件收集灵活性的需求、团队对 SQL 的熟练程度，以及是否需要将产品分析数据与其他数据源深度关联。

以下是我们的实际案例：

事件收集的灵活控制：我们需要对捕获的事件进行精细化控制，让开发人员能够决定发送哪些事件以及何时发送。为此，我们开发了一套自定义 SDK，赋予开发人员对埋点的完全掌控权。
SQL 专业技能：我们的主要用户（如产品经理和增长营销人员）对 SQL 十分熟悉，这使他们可以直接探索数据，并根据需要编写自定义查询。
跨数据源的关联分析：我们的数据仓库基于 ClickHouse，整合了来自 Salesforce、Google Analytics，以及计费和监控系统的数据。此外，我们的 ClickHouse Cloud 可观测性平台（用于日志、指标和追踪）同样基于 ClickHouse。通过将产品分析与这些数据源集成，我们可以回答复杂的跨领域问题。例如，我们能够分析客户流失是否与 ClickHouse Cloud 集群中的错误相关（产品分析 + 可观测性），或者跟踪不同客户群体的消费模式（产品分析 + 计费）。
成本考量：我们希望实现无限期的数据保留，同时在固定成本下支持无限次查询，并且不对开发人员可发送的数据施加任何限制。

基于这些原因，我们选择自建方案。不论你是选择自建还是购买，以下的实践经验将为你设计和运行基于 ClickHouse 的产品分析解决方案提供有价值的参考。

非规范化事件表

ClickHouse 作为列式数据库，非常适合单表中存储大量行和适量列（数百列也毫无问题）。尽管支持 Join 操作，但在产品分析场景中，由于事件量巨大，避免 Join 带来的查询时间开销，使用单一稀疏表通常是更优的选择。幸运的是，这种稀疏性——将多种事件类型存储在同一张表中，仅部分事件使用部分列——对 ClickHouse 的性能几乎没有影响。这是因为数据经过排序和压缩处理，连续的空值序列可以通过稀疏序列化技术（如下图所示）实现极高的压缩率，从而显著减少 I/O 并加速读取。

对于一列包含稀疏值的数据①，ClickHouse 仅将非默认值写入磁盘的列文件②，并生成一份稀疏编码文件③，用于记录非默认值的偏移量：即每个非默认值之前有多少个默认值。在查询时，ClickHouse 会基于稀疏编码创建一份内存中的直接偏移量表示④。稀疏编码存储格式能够高效处理重复值的数据。

通过避免 Join 操作，并主要使用带过滤器的聚合查询，用户可以在 TB 级别的数据规模上实现亚秒级的查询性能。正因如此，我们在产品分析的实现中选择了单表设计，所有事件均被收集到同一个表中。

基础数据模式

以下是我们当前在 Galaxy 中使用的数据模式：

CREATE TABLE galaxy.forensics
(
	`created_at` DateTime('UTC') DEFAULT now(),
	`environment` LowCardinality(String),
	`session_id` Nullable(String),
	`request_id` Nullable(String),
	`client_ip` Nullable(IPv4),
	`org_id` Nullable(UUID),
	`user_id` Nullable(String),
	`namespace` Nullable(String),
	`component` Nullable(String),
	`event` String,
	`interaction` LowCardinality(String),
	`payload` Nullable(String),
	`message` Nullable(String)
)
ENGINE = MergeTree
ORDER BY created_at

该模式包含一些 ClickCloud 专属的元素，同时也有部分可以复用的通用字段。具体说明如下：