我们很高兴在最近的 ClickHouse 旧金山聚会上听到 OpenMeter 的首席执行官兼联合创始人 Peter Marton 分享他们公司的数据摄取方法，重点介绍了他们的 Kafka + ClickHouse 架构。
OpenMeter 帮助 AI 和云公司采用按使用量计费的定价模型。为了满足 AI 业务的需求并实现实时使用案例（例如使用限制执行），OpenMeter 团队开发了一个可扩展、稳健的计量系统，该系统能够处理每秒数百万个计费事件，并基于 ClickHouse Cloud 构建。如今，按使用量计费的定价和账单对于许多云基础设施、开发者工具和 AI SaaS 服务至关重要。然而，许多采用这种方法的公司在确保精确计量以实现准确计费和提供实时使用反馈方面遇到了挑战。
Peter 将开发 OpenMeter 的想法归功于他在可观测性和基础设施方面的背景。在他在 Stripe 任职期间，他意识到由于缺乏标准化的计量，从基础设施组件收集使用数据的难度。高质量的数据至关重要，但收集、聚合和分析使用情况既耗时又费力。随着 AI 和按使用量计费的定价模型的日益普及，计量已成为支持计费、成本和收入运营的关键。这种认识促使了 OpenMeter 的开发，OpenMeter 是一个开源平台，可提供实时计量和计费解决方案。
在旧金山聚会上的演讲探讨了计量的一些挑战。数据需要被收集、清理、标准化为相同的一分钟“滚动窗口”、去重，并长期保留。与 DevOps 收集的可观测性指标不同，数据不能在摄取时进行采样，也不能在一段时间后汇总。
在使用 ClickHouse 之前，OpenMeter 的架构成本高昂且难以维护，尤其是在平台上的用户数量增长时。它基于 Kafka 进行事件流处理，ksqlDB 用于聚合到一分钟的滚动窗口，以及 Postgres 用于存储预聚合事件。这种方法存在许多挑战——主要源于 ksqlDB 不支持集群化，因此团队不得不进行手动分片并运行许多独立的 ksqlDB 实例，这既耗费资源又在操作上很复杂。
对于新架构，稳健且可扩展的计量事件收集被确定为关键要求。以及在此数据之上进行快速的搜索时聚合——这对于面向客户的仪表板至关重要，用户希望在这些仪表板中实时了解使用情况对成本的影响。
OpenMeter 最终确定的技术架构基于 Kafka 用于事件缓冲和管理反压，修改后的 ClickHouse Kafka Connect Sink 用于处理事件去重，以及 ClickHouse Materialized Views 与 AggregatingMergeTree 表引擎，用于将原始事件转换为滚动窗口以及长期分析数据存储。Peter 强调了去重和批量数据处理的一些复杂性，并强调了为每个客户分区的 Kafka 主题的使用。
总而言之，这次演讲非常有益地展示了 OpenMeter 如何应对大规模摄取计量事件的一些关键挑战，演示了 OpenMeter 如何通过 Kafka 和 ClickHouse 应对挑战并优化其架构。他们现在拥有一个强大的数据库摄取架构，适用于他们的实时分析用例，并帮助他们满足客户不断变化的需求。
