赋能下一代电动汽车：NOVO Energy

在本访谈中，我们很荣幸地与 NOVO Energy 坐下来，深入探讨他们使用 ClickHouse 和 ClickHouse Cloud 在 AWS 上的经验。我们讨论了他们在发现 ClickHouse 之前面临的挑战，它对他们的数据分析的影响，以及它如何改变了他们团队的运营方式。他们的见解为我们提供了第一手资料，了解 ClickHouse 的速度、可扩展性和灵活性如何在他们的组织中推动创新和效率。享受这段深入了解他们使用 ClickHouse 的旅程，并可能从中获得灵感，解决您自己的数据挑战。

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

我于 2022 年 5 月 2 日加入 NOVO Energy，是第一批员工之一。这有点滑稽，因为当时公司里唯一懂电池制造的人是我们的首席技术官 Eerik Hantsoo。但他对一个健壮的数据平台如何在实现良好研究中发挥核心作用有一个愿景，这就是为什么他在任何真正了解电池的人之前就让我加入了。现在，两年多了，我对该领域的了解已经有所增长，我有幸与一些非常聪明的人一起工作，使用激动人心的技术解决有趣的问题。

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

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

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

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

幸运的是，这不是最难满足的要求。在性能方面，我们正在寻找一种解决方案，它允许我们在合理的范围内从数十亿行数据集中查询几百万行，而无需花费太多时间进行调整。此外，我们希望使用低维护或托管解决方案，其中基本卫生（如备份）是套餐的一部分，易于与其他工具集成，例如 Grafana 或 BI 解决方案，熟悉的查询语言以及至少对 Rust 和 Python 的良好语言支持。

我们在 2023 年的 AWS Summit Stockholm 上偶然发现了 ClickHouse 的展位。团队成员之一曾在 Hacker News 上看到过这个名字，所以我们决定去看看。与展位上的两位男士简短交谈后，我们意识到 ClickHouse 与我们的用例高度相关。

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

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

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

截至撰写本文时，我们拥有超过 4 亿行的电化学测试数据。考虑到我们仍处于快速增长阶段，我们认为这并不多。随着我们新测试设备的投入使用和测试仪利用率的提高，这个数字将大幅增长。当我们完全投入运行时，我们可能会在任何给定时间进行约 1300 个电池单元的测试。设备可能会以大约 0.1 赫兹的速度生成新数据。对于与大部分电池单元相关联的辅助传感器，采样频率相同，我们可能需要每 10 秒插入约 2000 条新记录。除此之外，我们还将从我们的工艺设备和 BMS（楼宇管理系统）收集遥测数据。这可能在 0.1 赫兹时产生另外 200 条记录。我们将批处理插入操作大约每分钟发生一次，因此现在我们正在查看每分钟 12-13K 条记录。这并不是很多数据，但插入性能从未是我们选择数据库时的首要任务。更重要的是查询性能。对于我们处理的每个测试，我们都会不断检查我们已经处理的最新记录。这将告诉我们何时从电池循环器请求新数据。此查询类似于

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

随着测试数量的增加，每个测试可能都有数月的积累数据，因此此查询的性能变得越来越重要。目前，此查询在数据库中仅有 4400 个（以及 400 万行）测试的情况下大约需要 0.1 秒。如果没有投影，则需要超过 17 秒。

在此阶段，我们已经为数据管道构建了大部分基础设施。我们正在尝试后处理管道，将 ClickHouse 中的聚合结果推送到单独的 ClickHouse 表格或 PostgreSQL 中。当然，我们将继续监控系统的性能。随着测试数量和测试记录数量随着时间的推移而增长，我们可能需要优化设置的不同方面。

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

数据量与我们收集的实验室遥测数据相比微不足道，但如果我们决定也摄取来自各种设备和机器的日志，这可能会增长。我们使用的设置很大程度上受到 ( Uber) 的启发，并且它已经很好地取代了 CloudWatch。我们还没有深入研究日志分析，但这对于监控我们的运营来说可能具有吸引力。

简单、愉快、高性能。