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

对于许多企业来说，他们的网站是一项关键产品，分析对于收入和做出明智的业务决策至关重要。Trackingplan 提供由 ClickHouse 驱动的完整网站、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 在源头修复用户数据，发现您正在收集的数据的真相，执行您的业务规则，并在错误影响您的报告和决策之前修复错误。在此处获取您的免费计划和企业试用版。