使用 Trackingplan 和 ClickHouse 实现大规模更优分析

对于许多企业而言，他们的网站是一项关键产品，分析对于收入和做出明智的业务决策至关重要。Trackingplan 提供由 ClickHouse 驱动的完整测试解决方案，适用于 Web、iOS、Android 和后端分析。

通过拦截和抽样发送到 Google Analytics、Segment 和 MixPanel 等平台以及社交媒体广告归因工具的数据，Trackingplan 可以检测营销和产品“跟踪计划”中的问题，这些问题是由于需求变化和库更改而出现的。通过确保此数据完整且与历史学习示例一致，Trackingplan 确保关键任务营销报告的生成既精确又稳健。这些功能范围从简单检测缺失数据流到更复杂的模式不一致或异常事件检测。Trackingplan 用户可以放心地报告营销漏斗统计数据，因为这些数据已经过全面测试，并且在所有来源中保持一致。

ClickHouse 构成了 Trackingplan 产品的支柱，作为存储用户分析事件的数据库。ClickHouse 闪电般快速的聚合和专为分析设计的分析功能，可以快速检测和纠正数据不一致问题。

Trackingplan 的初始产品基于 AWS DynamoDB。这提供了一种简单的入门方式，同时数据访问模式正在被理解，并且确切的查询需求已被确定。虽然 DynamoDB 为获取行提供了快速读取，但其有限的分析能力要求 Trackingplan 在数据插入之前使用基于 Python (Pyspark) 的 ETL 管道执行大部分处理。这意味着任何需要的统计数据都在插入之前预先计算，从而使 Dynamo 能够提供简单、快速的读取。

这种方法虽然最初足够，但存在一些明显的局限性。新统计数据的计算需要重新处理和回填数据。Trackingplan 不断改进的产品服务加剧了这种缺乏灵活性，该服务需要解释问题的原因。随着计算的统计数据越来越多，很明显，通常需要完整的数据才能向最终用户解释检测到的问题。

在意识到需要一个能够为完整数据提供动态查询的分析数据库后，Trackingplan 开始评估替代方案。

"我们希望能够回答那些我们无法预见用户会提出的问题。我们无法提前知道用户需要的所有用例和功能，并且需要一个分析解决方案"

在决定使用 ClickHouse 之前，Trackingplan 评估了 4 个替代方案：Snowflake、BigQuery、Athena 和 Redshift。Snowflake 和 BigQuery 因其定价是其他替代方案的数倍而被排除在外，Trackingplan 的持续查询工作负载预计不会从它们的空闲能力或仅按扫描字节收费的能力中受益。虽然考虑了 Redshift，但测试证实，对于示例查询，它比 ClickHouse 慢得多。Athena 中的查询速度比 ClickHouse 慢 20 倍。

对于即席数据分析，Trackingplan 发现 ClickHouse 比 Athena 快 20 倍。

与此同时，ClickHouse 即使在没有应用任何优化（例如，物化视图）且需要线性扫描的即席分析查询方面也提供了无与伦比的性能。在优化的仪表板查询中达到毫秒级性能，即使在最复杂的即席 GROUP BY 查询中，在数亿行数据上也能达到低秒级性能，这让 Trackingplan 确信可以在 ClickHouse 上构建其产品的下一个迭代版本。

"由于 ClickHouse 是一个快速的 OLAP，我们可以回答计划外的查询。即使没有提前处理，查询也始终有效，即使它们需要几秒钟。这种检查和处理原始数据的能力是至关重要的。"

一旦 ClickHouse 被选为首选数据库，Trackingplan 就评估了供应商。Trackingplan 更倾向于原生 ClickHouse 服务而不是基于 ClickHouse 的平台，并且更倾向于与该技术的维护者合作，因此选择了 ClickHouse Cloud。存储和计算分离的解决方案的成本优势为使用 Cloud 而不是 OSS 提供了额外的令人信服的理由。

ClickHouse 的采用因其原生 SQL 接口而变得简单——这是 Trackingplan 所有开发团队都掌握的技能。ClickHouse 提供的额外的专用分析功能使这种体验更加轻松，这些功能大大简化了分析查询。

虽然 ClickHouse 灵活的查询功能受到赞赏，但 Trackingplan 仍然认识到需要对某些查询执行优化。统计数据的预计算（Python 用于 Dynamo）在逻辑上映射到 ClickHouse 物化视图。这些视图的增量性质与 Trackingplan 的用例特别相关，该用例有效地生成时间序列数据。通过在插入时预先计算聚合结果并确保在新数据插入时更新它们，Trackingplan 能够加速特定的重要查询并减少其所需的资源占用。更具体地说，物化视图用于加速显示实时统计数据的最常见的仪表板查询——确保仪表板在保持交互性的同时具有高度响应性。

对于我们可以预见的用例，我们仍然可以优化查询，就像我们对 Dynamo 所做的那样，通过使用物化预先计算统计数据

一旦用户需要对数据进行更深入的分析，例如，搜索特定页面的点击率，物化的叉积将变得非常庞大。此时，Trackingplan 依赖于 ClickHouse 的即席查询功能和合理的 primary key，以确保大多数查询仍然在毫秒范围内返回。

分析数据的动态特性意味着模式需要灵活。为了捕获动态的用户特定属性，Trackingplan 利用 ClickHouse 的 Map 和 Array 类型。这些类型的聚合函数使他们能够回答即使是最复杂的问题。

Trackingplan 目前在 ClickHouse 中拥有约 300 亿行数据。此数据量继续以每年超过 400% 的速度增长。虽然当前的访问模式仅使用最近 30 天的数据，但 ClickHouse 中的高压缩率可能允许 Trackingplan 保留所有原始事件，从而在未来解锁涉及历史分析的潜在用例。

目前，所有数据都存储在一组表中，其中客户 ID 作为排序键的组成部分。这针对最常见的访问模式进行了优化：每个用户的分析。这种多租户方法代表了最简单的方法，每个客户一张表也是可能的。如果客户需要在存储层实现完全的数据隔离，ClickHouse Cloud 允许 Trackingplan 通过简单地为每个客户创建专用服务来实现这一点。

Trackingplan 建议学习有关 ClickHouse 排序键以提高查询性能的知识。虽然存在许多其他优化技术，但他们发现这是最有效的初始步骤，并且在大多数情况下足以获得良好的查询性能。

在识别出用户的常用查询模式或需要公开新统计数据时，Trackingplan 会创建一个物化视图来优化查询并减少集群负载。创建视图后，使用视图查询和 INSERT INTO SELECT 回填过去 30 天的数据。这是可能的，因为原始数据存在于 ClickHouse 中。

Trackingplan 利用 ClickHouse Cloud 的扩展 API 及其在各个地理区域数据中心的广泛存在，这对于确保符合当地隐私法规至关重要。由于他们的高使用率时期是可预测的，例如黑色星期五，他们在这些时期发生之前扩展他们的服务。一旦他们检测到使用率已恢复到较低水平，就会主动减少服务以最大限度地减少支出。

最后，Trackingplan 对 ClickHouse Cloud 中正在开发中的许多功能感到兴奋。具体而言，他们期待能够分离用于插入和查询的计算——每个功能都有单独的服务，从而允许为这些功能独立扩展资源。

使用 Trackingplan 在源头修复您的用户数据，发现您正在收集的数据的真相，执行您的业务规则，并在错误影响您的报告和决策之前修复它们。在此处获取您的免费计划和企业试用版。