为下一代电动汽车提供动力：NOVO Energy

在本次访谈中，我们有幸采访了 NOVO Energy，深入了解他们在使用 ClickHouse 和 AWS 上的 ClickHouse Cloud 的经验。我们讨论了他们在发现 ClickHouse 之前面临的挑战，它对他们的数据分析产生的影响，以及它如何改变了他们团队的运营方式。他们的见解让人们亲身了解到 ClickHouse 的速度、可扩展性和灵活性如何推动他们组织的创新和效率。尽情深入了解他们与 ClickHouse 的历程，或许能为您的数据挑战找到灵感。

我叫 Martin Hardselius，从事软件工程师工作已有 12 年多。在我的职业生涯中，我曾在多家不同的公司和行业工作过，包括在线身份、博彩、电信、消费电子、大公司、小型初创公司等。我最初是一名后端工程师，后来扩展到基础设施和站点可靠性，现在我发现自己身处电池研究和工业物联网领域，这可以看作是家庭自动化的升级版，从事跨整个技术栈的工作。

我于 2022 年 5 月 2 日加入 NOVO Energy，成为最早的员工之一。考虑到当时公司唯一了解电池制造的人是我们的 CTO Eerik Hantsoo，这有点滑稽。但他对强大的数据平台如何在促进良好研究中发挥核心作用有着远见，这就是为什么他在任何真正了解电池的人之前就聘请了我。现在，两年多过去了，我对该领域的知识有所增长，并且我有幸与一些非常聪明的人一起工作，使用令人兴奋的技术解决有趣的问题。

NOVO Energy 是 Northvolt 和沃尔沃汽车的合资企业。我们的使命是开发和生产可持续电池，专门为下一代纯电动沃尔沃汽车提供动力。在我们的研发机构中，我们从设备、研究仪器和装配机械中收集大量数据。这些数据用于分析我们生产的电池。

NOVO Energy 研发部门软件工程团队的目的是在内部实现研究数据的民主化访问。

我们收集的数据通常最终会进入我们的供应商选择用来支持其软件的任何存储中。我们正在编写软件，将这些数据复制到我们自己的数据库中，然后我们可以在其中使用我们组织中每个人都可以使用的工具自由查询和分析。我们集中化我们的数据，以便简化我们的工具。我们标准化我们的数据，以降低计算中出现错误的风险。我们将数据的访问民主化，以消除不必要的守门。我们概括我们的表示，以便可以跨不同的实验比较数据，而不管使用了哪种测试设备。

我们对任何数据库/存储的主要业务要求是我们拥有并控制我们存储的数据——没有供应商锁定，也没有围墙花园。

幸运的是，这不是最苛刻的要求。关于性能，我们正在寻找一种解决方案，该解决方案允许我们在合理的时间内从数十亿行的数据集中查询数百万行，而无需花费太多时间进行调整。此外，我们想要一个低维护或托管的解决方案，其中备份等基本卫生是软件包的一部分，易于与其他工具（如 Grafana 或 BI 解决方案）集成、熟悉的查询语言以及对至少 Rust 和 Python 的良好语言支持。

2023 年，我们在斯德哥尔摩 AWS 峰会上偶然发现了 ClickHouse 的展位。一位团队成员之前在 Hacker News 上看到过这个名字，所以我们决定走近。在与展位上的两位先生简短讨论后，我们意识到 ClickHouse 与我们的用例高度相关。

我们对 ClickHouse 的第一次评估包括在我们的笔记本电脑之一上试用它，用我们当前的数据播种它，然后玩查询。在这个阶段，我们已经对 ClickHouse 的性能感到满意，因为在这个阶段我们看到了 10-100 倍的性能提升。从那时起，我们决定试用 ClickHouse Cloud 免费层，经过进一步评估，我们很快升级到了付费层。

在使用 ClickHouse 之前，我们使用的是 TimescaleDB 的本地安装，它为我们提供了良好的服务，但我们没有花任何时间来调整硬件大小或调整数据库。在考虑其替代方案时，我们主要关注适合我们架构的托管产品。我们不想使用 AWS RDS 来支持我们的分析查询，我们也考虑过涉及 AWS S3、AWS Glue 和 Amazon Redshift 的解决方案，但我们觉得对于我们的运营规模来说有点过度设计了。

如前所述，并且由于我们是一个时间有限的小团队，我们正在寻找低维护或托管的解决方案。选择 AWS 上的 ClickHouse Cloud 是一个简单的决定，因为它使我们能够专注于我们的主要工作，而无需担心维护、升级、备份等等。

在撰写本文时，我们拥有略高于 4 亿行的电化学测试数据。考虑到我们仍处于启动阶段，我们认为这并不多。随着我们调试新的测试设备并提高测试仪利用率，这个数字将大大增加。当我们完全启动时，我们可能在任何给定时间测试大约 1300 个电池单元。该设备可能会以大约 0.1 Hz 的频率生成新数据。借助一些辅助传感器，以相同的频率采样，与很大一部分电池单元相关联，我们可能会看到每 10 秒钟插入大约 2000 条新记录。最重要的是，我们将从我们的工艺设备和 BMS（楼宇管理系统）收集遥测数据。这可能是另外 200 条记录，频率为 0.1 Hz。我们正在批量插入，大约每分钟发生一次，所以现在我们看到每分钟 12-13K 条记录。数据量不大，但在选择数据库时，插入性能从来都不是我们的首要任务。

SELECT channel, test_id, max(sequence_number), max(observed_at) 
FROM cycler_data GROUP BY channel, test_id

更关键的是查询性能。对于我们正在处理的每个测试，我们都会不断检查我们已经处理的最新记录。这将告诉我们何时从电池循环器请求新数据。此查询如下所示 随着测试数量的增加，以及每个测试可能具有数月的数据，此查询的性能变得越来越重要。目前，此查询大约需要 0.1 秒，数据库中只有 4400 个（和 400 万行）测试。没有投影，则需要 17 秒以上。

在这个阶段，我们已经完成了大部分数据管道的管道铺设工作。我们正在试验后处理管道，我们将来自 ClickHouse 的聚合结果推送到单独的 ClickHouse 表或 PostgreSQL。当然，我们将继续监控我们系统的性能。随着测试和测试记录数量的不断增长，我们可能需要优化我们设置的不同方面。

同样值得注意的是，我们正在使用 ClickHouse 来存储来自我们服务的日志。

与我们收集的实验室遥测数据相比，数据量可以忽略不计，但如果我们决定也摄取来自各种设备和机器的日志，数据量可能会增加。我们正在使用一种深受 (Uber) 启发的设置，并且它作为 CloudWatch 的替代品为我们提供了良好的服务。日志分析是我们尚未过多探索的东西，但可能对监控我们的运营具有吸引力。

简单、愉快、高性能。