在评估特征存储方案时,开源软件(OSS)提供了一个不错的折中方案,它介于从头开始构建系统和采用完全托管的云服务之间。开源选项提供了很大的灵活性和掌控权,使组织能够根据其特定的基础设施和工作流程定制系统,同时受益于社区贡献和透明度。Feast 作为领先且许多组织使用的开源特征存储之一,成为了解此类产品特点的一个很好的示例。了解 Feast 的架构和理念Feast 采用解耦架构,这使其与一些单体或紧密集成的系统有所不同。它的主要目的是提供一个中心注册表,用于定义、查找和访问特征,同时常常利用现有的数据基础设施进行存储和计算。主要组件通常包括:特征注册表: 一个中心目录,通常由 Git 仓库或数据库支持,用于存储特征定义(模式、元数据、数据源)。它充当现有特征的数据源头。离线存储连接器: 连接到大型批处理存储系统,如数据仓库(Snowflake, BigQuery, Redshift)或数据湖(S3, GCS, ADLS),历史特征数据存放于此。这些数据主要用于生成训练数据集。在线存储连接器: 连接到低延迟键值存储(Redis, DynamoDB, Datastore),用于在推理时迅速提供特征。数据通常从离线存储加载或通过流式管道摄入。Python SDK/客户端: 为数据科学家和工程师提供主要方式,用于定义特征、生成训练数据、获取在线特征以及管理特征存储配置。digraph FeastArchitecture { rankdir=LR; node [shape=box, style=rounded, fontname="sans-serif", color="#495057", fillcolor="#e9ecef", style="filled, rounded"]; edge [fontname="sans-serif", color="#495057"]; subgraph cluster_clients { label = "用户与系统"; bgcolor="#f8f9fa"; style="filled, rounded"; ML_Training [label="机器学习训练管道", shape=cylinder, fillcolor="#a5d8ff"]; ML_Serving [label="机器学习推理服务", shape=component, fillcolor="#a5d8ff"]; DS_User [label="数据科学家\n(Python SDK)", shape= Mrecord, fillcolor="#bac8ff"]; } subgraph cluster_feast { label = "Feast 核心"; bgcolor="#f8f9fa"; style="filled, rounded"; Registry [label="特征注册表\n(定义、元数据)", fillcolor="#ffec99"]; Python_SDK [label="Feast Python SDK/CLI", fillcolor="#bac8ff"]; Online_API [label="在线服务 API", fillcolor="#d0bfff"]; } subgraph cluster_storage { label = "数据基础设施(可插拔)"; bgcolor="#f8f9fa"; style="filled, rounded"; Offline_Store [label="离线存储\n(数据仓库/数据湖)\n 例如,BigQuery, Snowflake, S3", shape=database, fillcolor="#b2f2bb"]; Online_Store [label="在线存储\n(键值数据库)\n 例如,Redis, DynamoDB", shape=database, fillcolor="#fcc2d7"]; } Compute [label="外部计算\n(Spark, Pandas, Flink, 等)", shape=box3d, fillcolor="#ffd8a8", style="filled, rounded"]; DS_User -> Python_SDK [label="定义特征,\n管理存储"]; Python_SDK -> Registry [label="更新"]; Registry -> Python_SDK [label="读取定义"]; ML_Training -> Python_SDK [label="请求训练数据"]; Python_SDK -> Offline_Store [label="生成时间点查询"]; ML_Serving -> Online_API [label="请求特征\n(实体键)"]; Online_API -> Online_Store [label="获取特征向量"]; Online_API -> Registry [label="获取元数据"]; Compute -> Offline_Store [label="写入特征数据(批处理)"]; Compute -> Online_Store [label="写入特征数据(批处理/流式)"]; Python_SDK -> Compute [label="触发计算(可选)", style=dashed]; {rank=same; DS_User; ML_Training; ML_Serving;} {rank=same; Python_SDK; Online_API; Registry;} {rank=same; Offline_Store; Online_Store; Compute;} }该图展示了 Feast 的主要组件及其相互作用。Feast 作为一个编排和定义层,与现有的数据存储和计算系统结合。Feast 的理念侧重于有效使用您现有数据栈。它通常不自行执行复杂的特征转换;相反,它期望特征在上游进行计算(例如,使用 Spark, dbt, Flink 或 Pandas),然后注册并加载到它管理的存储中。这使其非常适应拥有成熟数据平台的组织,但需要单独管理特征计算管道。开源特征存储(如 Feast)的优势灵活性和定制性: 开源解决方案在选择底层存储技术(在线/离线存储)以及与现有计算框架配合方面提供了很大的自由度。您不会被锁定在特定供应商的生态系统中。例如,Feast 支持多种流行数据库和数据仓库的连接器。基础设施掌控: 您完全掌控部署环境,无论是在本地还是在您偏好的云 VPC 中。这对于有严格数据驻留、安全或网络要求的组织有帮助。成本管理: 尽管存在运营成本,但您避免了通常与托管服务一同出现的直接软件许可费用。成本主要来自于您直接管理的基础设施(计算、存储、网络)。透明度和社区: 代码库是开放的,可以进行检查、修改和贡献。活跃的社区(如 Feast 的 Slack 频道和 GitHub 仓库)提供支持,交流好的做法,并推动项目向前发展。如果需要,您可以直接影响路线图或分叉项目。配合潜力: 开源工具通常与其他的开源 MLOps 和数据工具(如 Kubeflow, Airflow, dbt)很好地配合,如果您的组织大量使用开源,这有助于形成更统一的工具链。挑战与注意事项运营开销: 部署、配置、扩缩、监控和升级开源特征存储需要专门的工程师工作。这包括管理底层数据库、计算任务、API 服务器,以及保证高可用和灾备——这些任务通常由托管服务负责。基础设施管理: 您负责提供和管理所需的基础设施(在线/离线存储的数据库,摄取/服务的计算资源)。优化这些组件以实现性能和成本优势需要专业知识。特征计算责任: 正如在 Feast 中提到的,计算逻辑通常位于核心特征存储框架之外。您需要数据管道将原始数据转换为特征,并将其一致地加载到离线和在线存储中。保证一致性(例如,减少在线/离线偏差)需要周密的管道设计和验证。学习曲线和专业知识: 设置并良好地运行开源特征存储,尤其是在复杂的生产环境中,对分布式系统、数据工程和 MLOps 的技术水平要求很高。最初的设置和集成工作量可能很大。支持模式: 尽管社区支持有价值,但它可能无法达到商业供应商提供的服务级别协议或专属支持渠道,这对于重要的生产系统可能是一个需要考虑的因素。评估适用性像 Feast 这样的开源特征存储通常是好的选择,当:您的组织拥有强大的数据工程和平台团队,可以管理运营方面。您在现有数据基础设施(数据仓库、数据湖、计算框架)中已投入较多资源,并且希望有效使用它们。由于特定的技术或合规需求,您需要高度定制或掌控特征存储环境。您倾向于避免云特定托管服务带来的供应商锁定。通过直接管理基础设施来优化成本,优先于托管服务带来的便利。另一方面,如果您的团队规模较小,缺乏深厚的基础设施知识,或者优先考虑减少运营负担并加快初始部署速度,那么托管式特征存储服务(接下来将讨论)可能是一个更适合的起点,尽管它在灵活性方面可能存在局限性或有更高的直接成本。选择开源特征存储需要仔细权衡掌控和定制的好处与运营管理和自身技术能力的所需投入。Feast 提供了一个强大、灵活的基础,但成功取决于能否将其有效配合到管理良好的数据和 MLOps 生态系统中。