机器学习
机器学习数据层
你可能听过这样的说法：机器学习从业者 80% 的时间都花在清洗数据上。 不管这个说法是否完全准确，始终不变的一点是：从开始到结束，数据都是机器学习问题的核心。 无论你是在构建 RAG pipeline、进行微调、训练自有模型，还是评估模型效果，数据都是每个问题的根源所在。
管理数据本身就很棘手，因此围绕这一领域涌现了大量工具，试图通过解决机器学习数据问题中的某个具体子问题来提升生产力。 通常，这表现为在一个通用解决方案之上包了一层抽象，并提供一个带有强烈“主见”的接口，从表面上看，使其更容易用于当前的某个子问题。 但这样一来，本质上是用某一特定任务的易用性和简单性，换取了通用解决方案所提供的灵活性。
这种方式存在几个缺点。 与“通用解决方案 + 支撑应用代码”的组合相比，一整套层层叠加的专用工具、产品和服务，往往会带来不必要的架构复杂度和数据成本风险。 你很容易不知不觉间就堆出一长串工具和服务，而每一个只负责其中的一个步骤。
这些风险主要有两个常见维度：
- 学习、维护与切换成本
机器学习架构可能被各种工具和组件塞得过于臃肿，导致学习和管理环境支离破碎、难度增加，同时引入更多故障点和持续攀升的开销。
- 数据复制与传输成本
在机器学习 pipeline 中使用多个相互重叠但彼此独立的数据系统，往往会引入不必要、而且通常是高昂的开销，用于在系统之间反复搬运数据。
向量数据库就是这种取舍的一个典型例子。 向量数据库是为存储和检索向量这一高度特定的机器学习任务而设计的。 虽然在某些架构中它可能是正确选择，但在其他架构中，引入向量数据库可能是一项没有必要的技术栈扩展，因为这又是一个需要集成、运维以及在其间传输数据的新系统。 多数现代通用数据库都开箱即用（或通过插件）地提供向量支持，并具备更广泛且跨场景的能力。 换句话说，在这些架构中完全没必要为向量单独引入一个全新的数据库。 关键在于，那些面向向量的便捷功能（例如内置嵌入模型）是否属于“任务关键”，以及是否值得为此付出成本。
数据探索
在定义完机器学习问题、目标和成功标准之后，一个常见的第一步是探索将用于模型训练和评估的相关数据。
在这一步中，需要对数据进行分析，以理解其特性、分布和相互关系。 这一评估与理解的过程是迭代式的，通常会在数据集上执行一系列即席查询，此时查询的响应速度至关重要（同时还要考虑成本效率和准确性等因素）。 随着企业为机器学习用途而存储的数据量不断增加，“看清你已经拥有的数据”会变得愈发困难。
原因在于，在传统数据系统中，分析与评估类查询在规模化场景下往往会变得令人厌烦地缓慢，甚至慢到不可接受。 一些大型厂商会要求显著提高成本来换取更低的查询时延，并通过按查询计费或按扫描字节数计费的方式，抑制即席评估查询。 工程师可能会退而求其次，将数据子集拉到本地机器来弥补这些限制。
另一方面，ClickHouse 是一个实时数据仓库，用户可以在分析计算中享受到业界领先的查询速度。 此外，ClickHouse 从一开始就提供高性能，并不会把关键的查询加速功能锁在更高价位的套餐之后。 ClickHouse 还可以直接从对象存储或数据湖中查询数据，支持 Iceberg、Delta Lake 和 Hudi 等常见格式。 这意味着无论你的数据存放在哪里，ClickHouse 都可以作为你机器学习负载的统一访问与计算层。
ClickHouse 还提供了丰富的内置统计与聚合函数套件，可以在 PB 级数据上扩展，使你能够通过简单的 SQL 来编写和维护复杂计算。 借助对最高精度数据类型和编解码器的支持，你无需为了适配系统而降低数据粒度。
虽然你可以直接在 ClickHouse 中，或在插入前使用 SQL 查询对数据进行转换，ClickHouse 也可以通过 chDB 在 Python 等编程环境中使用。 这样一来，嵌入式 ClickHouse 可以以 Python 模块的形式暴露出来，在 notebook 中对大型数据帧进行转换和操作。 因此，数据工程师可以在客户端执行数据转换工作，并将结果以特征表的形式物化到集中式 ClickHouse 实例中。
数据准备与特征提取
接下来对数据进行准备：清洗、转换，并用于提取模型训练和评估所依赖的特征。 这一组件有时被称为特征生成或特征提取流水线，是机器学习数据层中经常引入新工具的另一部分。 像 Neptune 和 Hopsworks 这样的 MLOps 平台提供了众多不同数据转换产品的示例，这些产品被用于编排类似的流水线。 然而，由于它们是独立于所操作数据库之外的工具，往往比较脆弱，可能导致中断，并需要人工修复。
相比之下，在 ClickHouse 中可以通过 物化视图 直接、轻松地完成数据转换。 这些视图会在新数据插入 ClickHouse 源表时自动触发，用于在数据到达时方便地提取、转换和修改数据——无需你亲自构建和监控定制流水线。 当这些转换需要对可能无法全部放入内存的完整数据集执行聚合时，借助 ClickHouse 可确保你不必尝试将此步骤“硬塞”进本地机器上的数据帧处理流程。 对于那些在本地评估更方便的数据集，ClickHouse local 以及 chDB 是很好的替代方案，它们允许你配合 Pandas 等标准 Python 数据处理库来使用 ClickHouse。
训练与评估
在这一阶段，特征已经被划分为训练集、验证集和测试集。 这些数据集会进行版本管理，然后在各自阶段中使用。
在流水线的这一阶段，通常会在机器学习数据层中再引入一种专用工具——特征存储（feature store）。 特征存储通常是在数据库之上的一层抽象，为模型训练、推理和评估时的数据管理提供特定的便利功能。 这些便利功能的示例包括版本管理、访问管理，以及将特征定义自动转换为 SQL 语句。
对于特征存储，ClickHouse 可以充当：
数据源（Data source）——凭借对 70 多种不同文件格式（包括 Iceberg 和 Delta Lake 等数据湖格式）的查询或摄取能力，ClickHouse 是理想的长期存储，用于保存或查询数据。 通过使用对象存储实现存储与计算分离，ClickHouse Cloud 进一步允许数据被无限期保存——同时通过缩减计算规模甚至完全空闲来将成本降到最低。 灵活的编解码器结合列式存储和磁盘上的数据排序，最大化压缩率，从而将所需存储空间降到最低。 用户可以轻松将 ClickHouse 与数据湖结合使用，通过内置函数直接就地查询对象存储上的数据。
转换引擎（Transformation engine）——SQL 提供了一种声明数据转换的自然方式。 当结合 ClickHouse 的分析和统计函数时，这些转换会变得简洁且高度优化。 除了应用于 ClickHouse 用作数据存储时的表之外，表函数还允许针对以 Parquet 等格式存储在磁盘或对象存储中的数据，甚至其他数据存储（如 Postgres 和 MySQL）编写 SQL 查询。 完全并行化的查询执行引擎结合列式存储格式，使 ClickHouse 能在数秒内对 PB 级数据执行聚合——不同于对内存中数据帧的转换，用户不会受限于内存。 此外，物化视图允许在插入时对数据进行转换，从而将计算负载从查询时转移到数据加载时。 这些视图可以利用同样广泛的分析和统计函数，非常适合用于数据分析和汇总。 如果 ClickHouse 现有的分析函数仍不足以满足需求，或需要集成自定义库，用户还可以使用用户自定义函数（User Defined Functions，UDF）。
离线特征存储
离线特征存储用于模型训练。 通常，这意味着特征本身是通过批处理式数据转换流水线生成的（如上一节所述），并且对这些特征的可用性通常没有严格的延迟要求。
凭借从多个数据源读取数据并通过 SQL 查询进行转换的能力，这些查询的结果也可以通过 INSERT INTO SELECT 语句持久化到 ClickHouse 中。
由于转换通常按实体 ID 分组，并返回多列结果，ClickHouse 的模式推断功能可以根据这些结果自动识别所需的数据类型，并生成合适的表结构来存储它们。
用于生成随机数和统计采样的函数，使数据可以以每秒数百万行的速度被高效迭代和扩展，用于为模型训练流水线提供数据。
通常，特征以带有时间戳的表形式表示，用于指示在特定时间点上某个实体和特征的取值。 如前所述，训练流水线通常需要在特定时间点以及成组地获取特征的状态。ClickHouse 的稀疏索引允许对数据进行快速过滤，以满足时点查询和特征选择过滤条件。其他技术（如 Spark、Redshift 和 BigQuery）依赖缓慢的有状态窗口方法来识别特定时间点上特征的状态，而 ClickHouse 则支持 ASOF（截至该时间点）LEFT JOIN 查询和 argMax 函数。 除了简化语法之外，这种方法还通过使用排序与合并算法，在大规模数据集上提供极高的性能。 这使得可以快速构建特征组，从而减少训练前的数据准备时间。
在线特征存储
在线特征存储用于保存用于推理的最新特征版本，并在实时场景中应用。 这意味着这些特征必须以极低的延迟完成计算，因为它们会作为实时机器学习服务的一部分被使用。
作为一款实时分析型数据库，ClickHouse 可以在低延迟的前提下承载高度并发的查询负载。
虽然这通常要求数据是反规范化的，但这与在训练和推理阶段使用的特征组的存储方式是一致的。
重要的是，ClickHouse 能够在承受高写入负载的同时，依然提供这种查询性能，这要归功于其日志结构合并树。
这些特性是在线存储保持特征最新所必需的。
由于特征已经存在于离线存储中，它们可以通过现有能力（例如 remoteSecure）轻松物化到同一 ClickHouse 集群或不同实例中的新表中。
通过 Kafka 的集成——无论是借助具备“精确一次”语义的 Kafka Connect 能力，还是在 ClickHouse Cloud 中通过 ClickPipes——也使得从流式来源消费流式数据变得简单且可靠。
许多现代系统同时需要离线和在线存储，因此人们很容易得出需要两个专用特征存储的结论。 然而，这会引入额外的复杂性，即需要保持这两个存储同步，当然这也包括在它们之间复制数据的成本。
像 ClickHouse 这样的实时数据仓库是一个可以同时支撑离线和在线特征管理的单一系统。 ClickHouse 高效处理流式和历史数据，并具备在为实时推理和离线训练提供特征时所需的无限扩展性、性能和并发能力。
在权衡在这一阶段使用特征存储产品，还是直接利用实时数据仓库时，值得强调的是，诸如版本管理之类的便利功能，可以通过诸如表或模式设计等由来已久的数据库范式实现。 其他功能，比如将特征定义转换为 SQL 语句，作为应用或业务逻辑的一部分，可能会比存在于带有强烈主观设计的抽象层中提供更大的灵活性。
推理
模型推理是运行已训练模型以获取输出的过程。 当推理由数据库操作触发时——例如插入一条新记录或查询记录——推理步骤可以通过定制作业或应用代码进行管理。
另一方面，它也可以在数据层本身中进行管理。ClickHouse 的 用户自定义函数 (UDFs) 赋予用户在插入或查询时直接从 ClickHouse 调用模型的能力。 这使得可以将传入数据传给模型、接收输出，并将这些结果与摄取的数据一同自动存储——而无需启动其他进程或作业。 这也提供了一个用于管理此步骤的统一接口，即 SQL。
向量存储
向量存储是一类专门的数据库，针对向量的存储与检索进行了优化，通常用于保存一条数据（如文本或图像）的嵌入向量（embedding），这些嵌入向量以数值形式刻画其底层语义。 向量是当今生成式 AI 浪潮的核心，被广泛应用于无数场景中。
向量数据库中的主要操作是“相似性搜索”，即根据某种数学度量来查找彼此“最接近”的向量。 向量数据库之所以流行，是因为它们采用了特定策略，以尽可能加快这一过程——向量比较——的速度。 这些技术通常意味着它们只对向量比较进行近似计算，而不是将输入向量与每一个已存储的向量进行逐一比较。
这类新工具的问题在于，许多通用型数据库（包括 ClickHouse）都开箱即用地提供了向量支持，并且通常还内置了这些近似方法的实现。 尤其是 ClickHouse，被设计用于高性能的大规模分析——可以非常高效地执行精确（非近似）的向量比较。 这意味着你可以在不牺牲速度的情况下获得精确结果，而无需依赖近似。
可观测性
一旦你的机器学习应用上线，它就会产生数据，包括日志和追踪数据，这些数据能够为模型行为、性能以及潜在的改进空间提供有价值的洞察。
基于 SQL 的可观测性是 ClickHouse 的另一个关键用例，在这一领域，ClickHouse 被证明在成本上比替代方案低 10–100 倍。 事实上，许多可观测性产品本身就是在底层使用 ClickHouse 构建的。 凭借业界一流的摄取速率和压缩比，ClickHouse 在任何规模上都能为机器学习可观测性提供高性价比和极致速度。
