使用 ClickHouse 驱动特征存储

在本文中，我们将深入探讨 MLOps 的世界，并探索特征存储：不同类型、您可能需要它的原因以及主要组件。考虑到这一点，我们将介绍如何使用 ClickHouse 来驱动特征存储，从而驱动模型生命周期，提供性能和灵活性。

这篇博客主要介绍该主题，旨在作为后续示例的前导，这些示例将展示如何使用驻留在 ClickHouse 中的特征来训练 ML 模型。作为此处潜力的证据，我们确实展示了我们最近与 Featureform 的集成 - 一个开源的“虚拟”特征存储，我们将在未来的示例中使用它。

在讨论什么是特征存储之前，澄清什么是特征可能很有帮助。

简单来说，特征是实体的某些属性，这些属性对于机器学习 (ML) 模型具有预测能力。从这个意义上讲，实体是特征的集合，以及表示现实世界概念的类别或标签。如果特征质量足够高，并且存在这种关系，则特征应有助于预测实体的类别。例如，银行交易可以被视为一个实体。这可能包含诸如交易金额和所涉及的购买者/卖方等特征，类别描述交易是否为欺诈。

开发特征通常需要一些先前的data engineering步骤和数据转换逻辑，然后才能使用它们。然后可以在训练模型或从中推断结果（做出预测）时使用它们。在前一种情况下，许多特征（和实体）将被组合并作为训练数据（通常尺寸很大）公开，并用于训练模型。在后一种推理情况下，模型会使用仅在预测时可用的数据的特征来调用，例如，欺诈预测情况下的交易详情。其他特征可能源自与训练数据相同的来源，但包含最新值，例如，用户的帐户余额。

上述假设特征始终可以在推理时根据需要构建，并且在训练时使用类似的转换。由于延迟要求，有时这是不可能的，因此通常需要缓存和预处理某些特征的最新版本在“在线”存储中。

训练一个以任何 准确度 进行预测的模型几乎总是（有时深度学习除外）需要数据科学家仔细选择与要预测的类别相关的特征。

以最简单的形式来看，特征存储库是用于存储和管理特征数据并充当真理来源的集中式存储库。

通过提供允许特征的存储、版本控制和检索的 API，特征存储旨在为从开发到生产环境的训练和推理提供一致的特征视图。无论是定制的内部解决方案还是现成的产品，特征存储提供的实际产品级特征都会有所不同，有些提供完整的数据平台，能够将数据聚合为特征，甚至提供用于训练模型的计算引擎 - 请参阅下面的特征存储的类型。其他则提供更轻量级的抽象，管理元数据和版本控制，但将训练和数据/特征存储推迟到它们集成的其他平台和数据库。

无论特征存储具有多少固有能力，所有特征存储都为数据科学家和工程师熟悉的基础数据提供抽象。除了以版本控制的实体、特征和类别的形式传递数据外，大多数还公开了特征组、训练集、批处理、流式传输和时间点查询的概念（例如，识别特征在特定时间点的值的能力，例如，最新值）。

理论上，特征存储将不同的系统和功能结合在一起，形成一个完整的 ML 数据层，既可以充当训练数据的真理来源，也可以在进行预测时提供上下文。

虽然它们提供的确切功能各不相同，但目标保持不变

• 通过集中管理特征及其转换逻辑，提高数据科学家和数据工程师之间的协作和可重用性
• 通过允许在训练和推理时重复使用特征，减少实验和部署期间的模型迭代时间
• 通过规则和版本控制进行治理和合规性，可以限制模型对敏感数据（和特征）的访问
• 通过从数据科学家那里抽象出数据工程的复杂性，并确保他们仅使用通过 API 交付的质量一致的特征来工作，从而提高模型性能和可靠性。

虽然这些代表了特征存储解决的一些问题的高度概述，但这里的主要好处是能够在团队之间共享特征，并为训练和推理使用相同的数据。

特征存储还解决了 MLOps 中存在的许多其他挑战，例如如何回填特征数据、处理对源数据的增量更新（以更新特征）或监视新数据以查找漂移。最近，他们还集成了向量数据库，以充当 RAG 管道的编排层，或帮助使用嵌入查找相似的特征 - 这在某些模型训练期间是一项有用的功能。

当决定是使用现成的特征存储还是构建自己的特征存储时，该决定可能取决于几个因素（在我们看来）

• 现有工具 - 如果您使用完整的 ML 平台，那么您很可能不需要特征存储。这些功能中的大多数是此类平台的子集。但是，这些平台通常是最不灵活的，并且采用成本最高且最复杂。相反，如果您使用不同的系统和工具集合来实现 ML 训练和推理过程的不同部分，那么它可能是有意义的。

• 复杂性和规模 - 虽然 ML 模型训练不需要成为您业务的基础，但您可能需要相当数量的数据集、模型和数据科学家来证明额外的复杂性是合理的。虽然对于较小的用例，可以以临时方式工作，但将更大、更关键任务的模型转移到生产环境将需要更强的治理和更强大的管道。

• 抽象的好处 - 特征存储提供的抽象将使某些团队比其他团队受益更多。如果您有角色非常不同的数据科学家和数据工程师，那么特征存储可能实现的关注点分离可能很有吸引力。在这种情况下，工程师可以通过简单的 API（以他们理解的术语）向数据科学家交付特征，后者从特征准备过程中抽象出来。

  相反，如果您的数据科学家对特征工程感到满意，那么提供的抽象可能带来的好处较少。例如，假设您的数据驻留在 SQL 兼容的数据库或数据湖（可通过查询引擎访问）中，则可以通过 dbt 等工具管理转换。这将要求您的数据科学家直接在 SQL 中查询表，但这可能就足够了，dbt 提供了转换的版本控制和文档记录。但是，这确实使您需要使用特定的点解决方案来解决 ML ops 的许多其他挑战。

在我们探讨 ClickHouse 如何适应特征存储之前，了解常见组件对于上下文很有帮助。通常，特征存储将包含最多 4 个主要组件

• 数据源 - 虽然这可以像 CSV 文件一样简单，但通常是数据库或数据湖，其中文件格式如 Iceberg，并且可以通过查询引擎访问。
• 转换引擎（可选） - 原始数据需要转换为特征。在简单的情况下，特征可以与列的值相关联。更常见的情况是，它是转换过程的结果，该过程涉及连接、聚合和表达式，这些表达式会更改列值的结构和/或类型。某些特征存储（请参阅特征存储的类型）可能提供内置功能来实现此目的；其他特征存储可能会将工作卸载到本地 Python 函数，或者对于更大的数据集，则通过物化卸载到数据库（甚至可能在底层使用 dbt），或者卸载到 Spark 等处理引擎。使用 ClickHouse，可以通过物化视图实现这一点。持续更新的特征通常需要某种形式的流式传输管道，通常使用 Flink 或 Spark Streaming 等工具实现。通常，如果这些转换是链式的，并且需要跟踪依赖关系，则需要某种形式的有向无环图 (DAG)。
• 离线（训练）存储 - 离线存储保存来自先前转换管道的特征。这些特征通常分组为实体，并与标签（目标预测）关联。通常，模型需要有选择地（迭代地或通过聚合）消耗这些特征，可能多次且以随机顺序。模型通常需要多个特征，需要将特征分组到一个“特征组”中 - 通常按实体 ID 和时间维度分组。这要求离线存储能够为特定时间点提供正确版本的特征和标签。这种“时间点正确性”对于需要增量训练的模型通常至关重要。
• 在线（推理）存储 - 模型经过训练后，可以部署并用于进行预测。此推理过程需要仅在预测时刻可用的信息，例如，交易的用户的 ID。但是，它也可能需要用于预测的特征，这些特征可能是预先计算的，例如，表示历史购买的特征。即使对于 ClickHouse 而言，这些特征在推理时计算通常也太昂贵了。这些特征需要在对延迟敏感的情况下提供服务，基于数据的最新版本，尤其是在需要实时进行预测的情况下，例如欺诈检测。特征可以从离线存储物化到在线存储以进行服务。

上面省略了一些组件，这些组件虽然不一定是特征存储的一部分，但在任何 ML 管道中都高度关联且是必需的

• 训练引擎和模型托管 - 任何管道都需要计算框架和引擎，以使用离线存储中的特征来训练模型。反过来，此模型需要进行版本控制和托管，以便可以调用它来进行推理。一个 模型注册表 可能是其中的一个重要组成部分，提供模型沿袭、版本控制、标记和注释。
• 向量数据库 - 在以前的博客文章中，我们探讨了 向量搜索 及其在 RAG 工作流 中的应用。虽然传统上不是特征存储的组件，但它们与在线存储具有相似之处。通常，向量嵌入将与存储中存在的实体关联。然后可以将数据库部署在经典的 RAG 工作流中，或用于识别相似的特征 - 这在训练和推理时都是有用的功能。

以上所有内容都需要某种形式的状态管理，例如，跟踪特征版本。这通常是本地于存储的，并且相对于源数据和特征本身而言通常很小。

并非所有特征存储都直接提供上述组件，它们在灵活性和提供的功能方面有所不同。例如，某些特征存储可能具有现有的转换引擎，并为离线存储部署 Postgres 等数据库，或为在线组件部署 Redis。因此，ClickHouse 集成到特征存储中需要一定程度的架构灵活性和开放性。

我们在下面探讨这些差异，以及它们如何与 ClickHouse 共存。为了更详细地描述虚拟特征存储与替代方案（字面存储和物理存储）之间的差异，我们推荐 Featureform 的优秀博客。

物理存储提供了一个更集成的解决方案，计算和存储特征。这种类型的存储在 Tecton 等专有供应商中很常见，通常由带有集成在线和离线存储以及某些流式传输功能的转换引擎组成。通常，它们与外部数据存储集成，并且可以将某些工作推送到这些存储，例如，用于数据子集选择。在这种情况下，用户投资于一个灵活性有限的完整解决方案。历史上，这种灵活性的缺乏会通过更高的性能来弥补。与字面存储相比，用户还必须学习明显更少的技术，但代价是潜在的供应商锁定。

Tecton 架构 - 来源: https://www.tecton.ai/

在此架构中，ClickHouse 充当训练数据的源存储库，几乎没有其他集成机会。

在字面存储中，特征在存储外部处理，存储仅充当集中式存储库。特征通常发送到离线存储，而将这些特征物化到在线存储的过程留给用户。然后，这些特征用于推理，并具有如上所述通常公开的时间点正确性功能。从这个意义上讲，特征存储是一个实际的数据存储，其范围有限，仅存储和提供特征，同时位于实际的真实数据存储之上。此架构的经典实现是 Feast。这种方法提供了最大的灵活性，但也给采用者带来了最大的负担，即构建转换管道以从源生成特征。在这里，用户必须学习和连接各种技术才能构建强大的 MLOps 管道。

Feast 架构 - 原始来源: https://feast.dev/

虽然 ClickHouse 可能可以用作字面存储的存储引擎，但这种特征存储类型未能充分利用 ClickHouse 的功能。ClickHouse 的用途不仅仅是存储和提供特征。虽然字面存储用户可能会在存储外部使用 ClickHouse 进行转换，但它不提供集成的体验。

Featureform 是一个开源项目，将其自身描述为“虚拟特征存储”。Featureform 提出了虚拟存储的概念，作为上述架构之间的平衡。在这种情况下，用户可以在其基础设施中利用他们选择的任何存储、转换和流式传输引擎。特征存储负责管理转换以及特征的持久性和版本控制，但仅充当编排器。这种插件架构使采用者可以选择他们喜欢的每种组件技术，使他们能够获得像物理存储这样的集成体验的好处，同时还保持与字面存储相关的灵活性。从这个意义上讲，虚拟存储可以被认为是工作流管理和协调层，确保为每个角色使用最佳技术，同时使用数据科学家和工程师习惯的相同抽象。

Featureform 架构 - 来源: https://www.featureform.com/

此架构的传统实现可能牺牲了物理存储的一些性能，以提供等效的协调和管理层，同时保留字面存储的相同灵活性。这种灵活性还会带来一些部署成本，异构架构本身就具有更大的 DevOps 开销。但是，通过使用 ClickHouse 为架构的重要组件提供支持，用户可以获得优于更异构架构的性能，并减少管理开销。诸如特征缩放和相关矩阵计算之类的昂贵操作可以在 PiB 数据集上在几秒钟内完成。灵活性也仍然保留 - 如果用户希望替换 ClickHouse，他们可以自由地这样做，同时仍然保留一致的版本控制方案和特征定义的集中式跟踪。

作为 实时数据仓库，ClickHouse 可以履行许多组件的角色 - 从而可能大大简化特征存储架构。

具体来说，ClickHouse 可以充当

• 数据源 - ClickHouse 能够以 70 多种不同的文件格式（包括 Iceberg 和 Delta Lake 等数据湖格式）查询或摄取数据，使其成为存储或查询数据的理想长期存储。通过使用对象存储分离存储和计算，ClickHouse Cloud 还允许无限期地保存数据 - 计算可以缩小或完全空闲，以最大程度地降低成本。灵活的编解码器，加上面向列的存储和磁盘上数据的排序，最大限度地提高了压缩率，从而最大限度地减少了所需的存储空间。用户可以轻松地将 ClickHouse 与数据湖结合使用，并使用内置函数就地查询对象存储上的数据。

• 转换引擎 - SQL 提供了一种声明数据转换的自然方式。当扩展 ClickHouse 的分析和统计函数时，这些转换变得简洁且优化。除了应用于 ClickHouse 表之外，在 ClickHouse 用作数据存储的情况下，表函数允许针对以 Parquet 等格式存储在磁盘上或对象存储上，甚至其他数据存储（如 Postgres 和 MySQL）中的数据编写 SQL 查询。完全并行化的查询执行引擎，加上面向列的存储格式，使 ClickHouse 能够在几秒钟内对 PB 级数据执行聚合 - 与内存中数据帧上的转换不同，用户不受内存限制。此外，物化视图允许在插入时转换数据，从而将计算从查询时间转移到数据加载时间。这些视图可以利用相同的分析和统计函数范围，非常适合数据分析和汇总。如果 ClickHouse 的任何现有分析函数不足或需要集成自定义库，用户还可以使用用户定义的函数 (UDF)。

  虽然用户可以直接在 ClickHouse 中或在使用 SQL 查询插入之前转换数据，但 ClickHouse 也可以在 Python 等编程环境中使用，通过 chDB。这允许将嵌入式 ClickHouse 公开为 Python 模块，并用于在笔记本中转换和操作大型数据帧。这允许转换工作由数据工程师在客户端执行，结果可能会物化为集中式 ClickHouse 实例中的特征表。

• 离线存储 - 凭借上述从多个来源读取数据并通过 SQL 应用转换的功能，这些查询的结果也可以通过 INSERT INTO SELECT 语句持久化在 ClickHouse 中。由于转换通常按实体 ID 分组并返回多个列作为结果，ClickHouse 的模式推断可以自动从这些结果中检测所需的类型，并生成适当的表模式来存储它们。用于生成随机数和统计抽样的函数允许以每秒数百万行或行的速度有效地迭代和缩放数据，以用于模型训练管道。

  通常，特征在表中表示，表中带有时间戳，指示实体和特征在特定时间点的值。如前所述，训练管道通常需要在特定时间点和分组中特征的状态。ClickHouse 的稀疏索引允许快速过滤数据，以满足时间点查询和特征选择过滤器。虽然 Spark、Redshift 和 BigQuery 等其他技术依赖于缓慢的有状态窗口方法来识别特定时间点特征的状态，但 ClickHouse 支持 ASOF（as-of-this-time）LEFT JOIN 查询和 argMax 函数。除了简化语法外，这种方法通过使用排序和合并算法，在大型数据集上具有很高的性能。这允许快速构建特征组，从而减少训练前的数据准备时间。

所有这些工作都可以下推到 ClickHouse、并行化并在集群中执行。这允许离线存储扩展到 PB 级，而特征存储本身仍然是一个轻量级的协调层。

• 在线存储 - 作为实时分析数据库，ClickHouse 可以以低延迟服务于高度并发的查询工作负载。虽然这要求数据通常是非规范化的，但这与训练和推理时使用的特征组的存储是一致的。重要的是，由于其日志结构合并树，ClickHouse 能够在承受高写入工作负载的同时提供这种查询性能。在线存储中需要这些属性以保持特征最新。由于特征已在离线存储中可用，因此可以通过现有功能（例如 remoteSecure）轻松地将它们物化到同一 ClickHouse 集群或不同实例中的新表中。

  通过完全一次 Kafka Connect 产品或通过 ClickHouse Cloud 中的 ClickPipes 与 Kafka 集成，也使得从流式传输源使用流式传输数据变得简单而可靠。

对于需要非常高的请求并发性（即每秒数千次）和非常低延迟的用例，我们建议用户仍然考虑专用的数据存储，例如 Redis，专为这些工作负载而设计。

• 向量数据库 - ClickHouse 通过 浮点数组 内置了对向量嵌入的支持。这些可以通过 距离函数 进行搜索和比较，从而允许将 ClickHouse 用作向量数据库。这种线性比较可以轻松地针对更大的数据集进行缩放和并行化。此外，ClickHouse 对 近似最近邻 (ANN) 索引以及 使用纯 SQL 的超平面索引（大型向量数据集所需）具有成熟的支持。

通过满足上述每个角色，ClickHouse 可以大大简化特征存储架构。除了简化操作之外，此架构还允许更快地构建和部署特征。单个 ClickHouse 实例可以垂直扩展以处理 PB 级数据，只需添加其他实例即可实现高可用性。这最大限度地减少了数据存储之间的数据移动，从而最大限度地减少了典型的网络瓶颈。ClickHouse Cloud 通过仅在对象存储中存储数据的单个副本，并允许节点根据需要动态地垂直或水平扩展以响应负载，从而进一步扩展了这一点。

上述架构仍然需要 ClickHouse 未满足的几个关键组件：Kafka + Flink 等流式传输引擎和提供模型训练计算的框架。还需要一种托管模型的方法。为简单起见，我们假设使用云托管解决方案来解决这些问题，例如 Confluent 和 Amazon SageMaker。

为了实现我们由 ClickHouse 强力驱动的虚拟特征存储的愿景，我们确定 Featureform 是集成的理想解决方案。除了开源（因此允许我们轻松贡献）之外，Featureform 还为离线存储、在线存储和向量数据库提供了成熟的（按设计）集成点。

对于我们的 初始集成，我们已将 ClickHouse 添加为离线存储。这代表了最大的工作量，并允许将 ClickHouse 用作数据源以及特征和训练集的主存储。用户还可以利用 ClickHouse 在创建特征组和从其他来源插入数据时为转换提供支持。

这代表了我们与 Featureform 集成的首次尝试。预计很快就可以使用 ClickHouse 作为在线存储和向量数据库！

在这篇博客中，我们介绍了特征存储的概念及其在 MLOps 工作流程中的用途。我们探讨了您可能使用特征存储的原因、特征存储的主要类型及其核心架构组件。以此为基础，我们介绍了如何使用 ClickHouse 作为高性能实时数据仓库来驱动“虚拟”特征存储的多个组件，并宣布最近与 Featureform 的集成为例。

在本系列的下一篇博客中，我们将探索使用 Featureform 和 AWS Sagemaker 集成和训练模型，数据和特征保存在 ClickHouse 中！