Hopsworks特征存储库统一了在线和批处理应用程序的特征访问而屏蔽了双数据库系统的复杂性。我们构建了一个可靠且高性能的服务，以将特征物化到在线特征存储库，不仅仅保证低延迟访问，而且还保证在服务时间可以访问最新鲜的特征值。
企业机器学习模型为指导产品用户交互提供了价值价值。通常这些 ML 模型应用于整个实体数据库，例如由唯一主键标识用户。离线应用程序的一个示例是预测客户终身价值（Customer Lifetime Value），其中可以定期（每晚、每周）分批预测，然后用于选择营销活动的目标受众。然而更先进的人工智能应用程序可以实时指导用户交互，例如推荐系统。对于这些在线应用程序，模型输入的某些部分（特征向量）将在应用程序本身中可用，例如最后点击的按钮，而特征向量的其他部分则依赖于历史或上下文数据，必须检索后端存储，例如用户在过去一小时内点击按钮的次数或按钮是否为热门按钮。
在这篇博客中，我们将深入探讨在线应用程序的需求细节，以及 Hopsworks Feature Store 如何抽象并规避双存储系统的复杂性。
1. 生产中的机器学习模型虽然具有（分析）模型的批处理应用程序在很大程度上类似于模型本身的训练，需要有效访问将要参与评分的大量数据，但在线应用程序需要低延迟访问给定主键的最新特征值，然后作为特征向量发送到模型服务实例进行推理。
据我们所知没有单一的数据库能够高性能满足这两个要求，因此数据团队倾向于将用于训练和批量推理的数据保留在数据湖中，而 ML工程师更倾向于构建微服务以将微服务中的特征工程逻辑复制到在线应用程序中。
然而，这给数据科学家和机器学习工程师带来了不必要的障碍，无法快速迭代并显着增加机器学习模型的用于生产环境的时间
数据科学视角：数据和基础设施通过微服务紧密耦合，导致数据科学家无法从开发转向生产，也无法复用特征。
ML 工程视角：大量工程工作以保证对生产中数据的一致访问，正如 ML 模型在训练过程中所看到的那样。
2. Hopsworks特征存储库：透明的双存储系统Hopsworks特征存储库是一个双存储系统，由高带宽（低成本）离线存储和低延迟在线存储组成。离线存储是我们 HopsFS 文件系统上的 Apache Hudi 表（由 S3 或 Azure Blob 存储支持）和外部表（例如 Snowflake、Redshift 等），提供对大量特征数据的访问以用于训练或批量评分。相比在线存储是一个低延迟的键值数据库，它只存储每个特征的最新值及其主键。 因此在线特征存储充当这些特征值的低延迟缓存。
为了使该系统对数据科学家有价值并缩短生产时间，并为最终用户提供良好的体验，它需要满足一些要求：
用于训练和服务的一致特征：在 ML 中，为生产中的特征复制精确的特征工程逻辑非常重要，因为它用于生成模型训练的特征。
特征新鲜度：低延迟、高吞吐量的在线特征存储只有在存储在其中的数据保持最新时才有益，特征新鲜度被定义为触发特征重新计算的事件到达与重新计算的特征在在线特征库中发布之间的端到端延迟。
延迟：在线特征库必须提供近乎实时的低延迟和高吞吐量，以便应用程序能够使用尽可能多的特征及其可用的SLA。
可访问性：数据需要可通过直观的 API 访问，就像从离线特征存储中提取数据进行训练一样容易。
Hopsworks在线特征库围绕四大支柱构建，以满足需求，同时扩展以管理大量数据：
HSFS API：Hopsworks 特征存储库是开发人员特征存储的主要入口点，可用于 Python 和 Scala/Java。HSFS 将两个存储系统抽象出来，提供透明的 Dataframe API（Spark、Spark Structured Streaming、Pandas）用于在线和离线存储的写入和读取。
元数据：Hopsworks 可以存储大量自定义元数据，以便数据科学家发现、管理和重用特征，而且还能够在将模型移至生产时依赖模式和数据质量。
引擎：在线特征存储带有可扩展的无状态服务，可确保数据尽快写入在线特征存储，而不会从数据流（Spark 结构化流）或静态 Spark 或 Pandas DataFrame中进行写入放大，即不必在摄取特征之前先将特征物化到存储中 - 可以直接写入特征存储。
RonDB：在线存储背后的数据库是世界上最快的具有 SQL 功能的键值存储。不仅为在线特征数据构建基础，而且还处理 Hopsworks 中生成的所有元数据。
我们将在以下部分详细介绍其中的每一部分，并提供一些用于定量比较的基准。
3. RonDB：在线特征存储，文件系统和元数据的基础Hopsworks 是围绕分布式横向扩展元数据从头开始构建的。这有助于确保 Hopsworks 内服务的一致性和可扩展性，以及数据和 ML 工件的注释和可发现性。