利用 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。由于其定价是替代方案的几倍，而 Trackingplan 的持续查询工作负载预计不会从其闲置功能或仅按扫描字节计费功能中获益，因此 Snowflake 和 BigQuery 被排除在外。虽然考虑了 Redshift，但测试证实其速度明显慢于 ClickHouse，因为样本查询。Athena 中的查询速度比 ClickHouse 慢 20 倍。

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

同时，ClickHouse 即使在临时分析查询上也提供了无与伦比的性能，这些查询没有应用任何优化，例如物化视图，并且需要线性扫描。在经过优化的仪表板查询上以毫秒级的性能，以及在数亿行上，即使是最复杂的临时 GROUP BY 查询也以秒级的性能，让 Trackingplan 确信将他们的产品的下一代建立在 ClickHouse 之上。

“由于 ClickHouse 是一种快速的 OLAP，因此我们可以回答计划外的查询。即使没有事先处理，查询也始终有效，即使它们需要几秒钟。这种检查和使用原始数据的能力是决定性因素。”

在选择 ClickHouse 作为首选数据库后，Trackingplan 评估了供应商。与基于 ClickHouse 的平台相比，更偏爱本机 ClickHouse 服务，并且更倾向于与该技术的维护人员合作，Trackingplan 选择了 ClickHouse 云。将存储和计算分离的解决方案的成本效益为使用云服务而不是 OSS 提供了其他令人信服的理由。

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

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

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

一旦用户需要对数据进行更深入的分析，例如搜索特定页面的点击率，物化之间的交叉产品将变得过于庞大。此时，Trackingplan 依赖于 ClickHouse 的临时查询功能，并使用合理的 primary key 来确保大多数查询仍然在毫秒级内返回。

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

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

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

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

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

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

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

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