博客 / 产品

ClickHouse 和机器学习数据层

Kelly Toole

2024 年 2 月 15 日 - 7 分钟阅读

您可能听说过这样的传说：机器学习从业者 80% 的时间都花在处理或清理数据上。无论这个说法是否属实，但数据是机器学习问题的核心，从始至终，这一点是毋庸置疑的。无论您是构建 RAG 管道、微调、训练自己的模型还是评估模型性能，数据都是每个问题的根源。

但是，管理数据可能很棘手，并且作为副产品，这个领域出现了大量旨在通过解决机器学习数据问题的特定部分来提高生产力的工具。通常，这表现为围绕更通用的解决方案的抽象层，具有固有的界面，从表面上看，这使得更容易应用于手头的特定子问题。实际上，这降低了通用解决方案的灵活性，转而支持特定任务的易用性和简洁性。

也就是说，这种方法存在一些缺点。与通用解决方案加上支持应用程序代码相比，级联的专用工具、产品和服务套件会带来更大的架构复杂性和数据成本的风险。您很容易意外地发现自己拥有无穷无尽的工具和服务列表，每个工具和服务仅用于一个步骤。

mad2023 (1).jpg 庞大的机器学习领域

这些风险有两个常见的维度

学习、维护和切换成本

机器学习架构可能会因各种工具和组件而变得过于杂乱，从而创建一个碎片化且难以学习和管理的环境，同时增加故障点和费用攀升。

数据重复和传输成本

在机器学习管道中使用多个离散但重叠的数据系统可能会引入不必要的且通常是昂贵的开销，即将数据从一个系统传输到另一个系统。

向量数据库是这种权衡的一个很好的例证。向量数据库专为存储和搜索向量的超特定机器学习任务而设计。虽然这在某些架构中可能是正确的选择，但在另一些架构中，向量数据库可能是不必要的添加到技术堆栈中的新事物，因为它又是另一个需要集成、管理以及数据传入和传出的系统。大多数现代通用数据库都开箱即用地（或通过插件）提供向量支持，并具有更广泛和跨领域的功能。换句话说，在这些架构中，可能根本不需要专门处理向量的全新数据库。重要性归结为向量特定的便利功能（例如，内置嵌入模型）是否至关重要且值得付出成本。

因此，问题变成了：何时最好使用单个数据库或数据仓库，而不是使用多个这些专用工具？在以下文章中，我们将描述 ClickHouse（一个实时数据仓库）如何非常适合作为机器学习数据层的中心数据存储，有可能帮助简化整体基础设施并提高长期开发人员效率。

在定义机器学习问题、目标和成功标准之后，常见的下一步是探索将用于模型训练和评估的相关数据。

在此步骤中，分析数据以了解其特征、分布和关系。这种评估和理解的过程变成了一个迭代的过程，通常会导致在一系列数据集上执行一系列临时查询，其中查询响应能力至关重要（以及其他因素，例如成本效益和准确性）。随着公司存储越来越多的数据以用于机器学习目的，这个问题（检查您拥有的数据的问题）变得更加困难。

这是因为对于传统数据系统，分析和评估查询在规模上通常变得非常缓慢或令人望而却步。一些大型厂商大幅增加了成本以缩短查询时间，并且通过按查询或扫描的字节数收费来抑制临时评估。工程师可能会为了弥补这些限制，而求助于将数据子集拉取到本地机器上。

另一方面，ClickHouse 是一个实时数据仓库，因此用户可以从行业领先的分析计算查询速度中获益。此外，ClickHouse 从一开始就提供高性能，并且不会将关键的查询加速功能置于更高的定价层之后。 ClickHouse 还可以直接从对象存储或数据湖查询数据，并支持 Iceberg、Delta Lake 和 Hudi 等常见格式。这意味着无论您的数据位于何处，ClickHouse 都可以作为机器学习工作负载的统一访问和计算层。

ClickHouse 还拥有广泛的预构建统计和聚合函数套件，可以扩展到 PB 级数据，从而可以轻松编写和维护执行复杂计算的简单 SQL。凭借对最精细精度数据类型和编解码器的支持，您无需担心降低数据的粒度。

“ClickHouse 非常适合作为我们 ML 模型的大数据存储” - Admixer

然后准备数据——对其进行清理、转换并用于提取模型将训练和评估的特征。此组件有时称为特征生成或提取管道，是机器学习数据层的另一个部分，可能会引入新工具。像 Neptune 和 Hopsworks 这样的 MLOps 参与者提供了用于编排此类管道的各种不同数据转换产品的示例。然而，由于它们是与它们所操作的数据库分离的工具，因此它们可能很脆弱，并且可能导致需要手动纠正的中断。

相比之下，数据转换可以直接在 ClickHouse 中通过物化视图轻松完成。这些在将新数据插入 ClickHouse 源表时自动触发，并用于轻松提取、转换和修改到达的数据——无需自己构建和监控定制管道。

而且，当这些转换需要对可能无法容纳在内存中的完整数据集进行聚合时，利用 ClickHouse 可确保您不必尝试改造此步骤以使其与本地计算机上的数据帧一起工作。对于那些更方便在本地评估的数据集，ClickHouse Local 是一个很好的替代方案，以及 chDB，它允许用户将 ClickHouse 与 Pandas 等标准 Python 数据库一起使用。

“我们从客户的手机和其他更传统的来源收集数万个数据点。 ClickHouse 被用作处理所有这些 SMS 消息并提取用于评分和欺诈模型的有价值信息的一种方式。” - QuickCheck

此时，特征将被拆分为训练集、验证集和测试集。这些数据集已进行版本控制，然后由各自的阶段使用。

这里通常会引入另一个专用工具——特征存储——到机器学习数据层。特征存储最常见的是数据库周围的抽象层，它提供特定于管理模型训练、推理和评估数据的便利功能。这些便利功能的示例包括版本控制、访问管理以及自动将特征定义转换为 SQL 语句。

离线特征存储用于模型训练。这通常意味着特征本身是通过批处理数据转换管道生成的（如上节所述），并且对这些特征的可用性通常没有严格的延迟要求。

在线特征存储用于存储用于推理的最新版本的特征，并在实时应用。这意味着这些特征需要以最小的延迟计算，因为它们用作实时机器学习服务的一部分。

使用 ClickHouse 驱动特征存储

许多现代系统都需要离线和在线存储，并且很容易得出结论，这里需要两个专用特征存储。然而，这引入了保持这两个存储同步的额外复杂性，这当然也包括在它们之间复制数据的成本。

像 ClickHouse 这样的实时数据仓库是一个可以同时支持离线和在线特征管理的单一系统。 ClickHouse 有效地处理流式和历史数据，并具有在为实时推理和离线训练提供特征时所需的无限扩展能力、性能和并发性。

在考虑在此阶段使用特征存储产品与直接利用实时数据仓库之间的权衡时，值得强调的是，版本控制等便利功能可以通过诸如表或模式设计之类的古老数据库范例来实现。其他功能（例如将特征定义转换为 SQL 语句）可以作为应用程序或业务逻辑的一部分提供更大的灵活性，而不是存在于固有的抽象层中。

“我们在 ClickHouse 中聚合用户的历史记录，并将其用作训练和推理的数据存储。即使读取数千万行，性能也非常好，并且在训练新模型时不是瓶颈。” - DeepL

模型推理是运行训练好的模型以接收输出的过程。当推理由数据库操作触发时——例如，插入新记录或查询记录——推理步骤可以通过定制作业或应用程序代码来管理。

另一方面，它可以在数据层本身中管理。 ClickHouse UDF（用户自定义函数）使用户能够在插入或查询时直接从 ClickHouse 调用模型。这提供了将传入数据传递到模型、接收输出并将这些结果与摄取的数据自动存储的能力——所有这些都无需启动其他进程或作业。这还提供了一个单一的接口 SQL，通过该接口可以管理此步骤。

“在测试 Hadoop 和 Spark 之后，我们选择了 ClickHouse” - DENIC

向量存储是一种特定类型的数据库，它经过优化，可以存储和检索向量，通常是数据片段（例如文本或图像）的嵌入，这些嵌入在数值上捕获了它们的底层含义。向量是当今生成式 AI 浪潮的核心，并在无数应用程序中使用。

向量数据库中的主要操作是“相似性搜索”，以根据数学度量找到彼此“最接近”的向量。向量数据库之所以变得流行，是因为它们采用了旨在使这种检查（向量比较）尽可能快速的特定策略。这些技术通常意味着它们近似向量比较，而不是将输入向量与存储的每个向量进行比较。

这类新工具的问题在于，包括 ClickHouse 在内的许多通用数据库都开箱即用地提供向量支持，并且通常也内置了这些近似方法的实现。尤其是 ClickHouse，专为高性能大规模分析而设计——允许您非常有效地执行非近似向量比较。这意味着您可以获得精确的结果，而无需依赖近似值，并且不会牺牲速度。

一旦您的机器学习应用程序上线，它将生成数据，包括日志和跟踪数据，这些数据可以为模型行为、性能和潜在的改进领域提供有价值的见解。

基于 SQL 的可观测性是 ClickHouse 的另一个关键用例，其中发现 ClickHouse 比其他替代方案成本效益高出 10-100 倍。事实上，许多可观测性产品本身都是使用底层 ClickHouse 构建的。凭借一流的摄取率和压缩率，ClickHouse 提供了成本效益和极快的速度，可在任何规模下为机器学习可观测性提供支持。