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