通过 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 keys 来确保大多数查询仍然在毫秒级内返回结果。

分析数据的动态特性意味着模式需要灵活。为了捕获动态的特定于用户的属性，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 修复源头处的用户数据，了解您收集数据的真实情况，执行您的业务规则并在错误影响您的报告和决策之前修复它们。获取您的免费计划和企业试用版 这里。