1.1. 在机器学习模型中，还有一个额外的步骤是发现特征

1.1.1. 在机器学习模型中使用某个特征时需要数据属性的历史值

1.2. 特征是一种数据属性，可以直接提取，也可以从数据源通过计算来获得

1.3. 构建数据管道来生成训练以及推理所需的特征是一个重要的痛点

1.3.1. 数据科学家必须编写访问数据存储的低级代码，这需要数据工程技能

1.3.2. 生成这些特征的管道有多种实现方式，这些实现并不总是一致的

1.3.3. 管道代码在不同机器学习项目中是重复的，而且不能重用，因为它是作为模型实现的一部分嵌入的

1.3.4. 没有变更管理或特征治理

1.4. 关键是数据用户通常缺乏工程技能来开发健壮的数据管道，并在生产中监控这些管道

1.5. 特征管道是反复从头开始构建的，而不是在机器学习项目之间共享

1.6. 构建机器学习模型的过程是迭代的，需要对不同的特征组合进行探索

1.7. 理想情况下，特征存储服务应该为机器学习模型的训练和推理提供有据可查、有管理、有版本、有整理的特征

1.7.1. 数据用户可以通过最小的数据工程来搜索和使用特征以构建模型

1.7.2. 用于训练和推理的特征管道在实现上是一致的

1.7.3. 在不同机器学习项目中缓存和重用特征可以减少训练时间和基础设施成本

1.8. 该服务成功与否的指标是特征处理耗时

1.9. 随着特征越来越丰富，通过在此基础上构建特征存储服务可以以更快的速度、更低的成本来构建新模型

1.10. 特征存储作为特征的存储仓库，用于多个数据项目中模型的训练和推理

1.11. 如今，在模型服务和训练过程中，没有原则性的方法来访问特征

1.11.1. 通常，特征无法在多个机器学习管道之间轻松重用，并且机器学习项目是在没有协作和重用的情况下独立完成的

1.11.2. 特征存储可以解决这些问题，并能在大规模开发机器学习模型时节省成本

2.1. 开发和管理特征是开发机器学习模型的关键步骤

2.2. 通常，数据项目会共享一组公共特征，允许重复使用相同的特征

2.3. 随着复用特征数量的增加，会降低新数据项目实现的成本

2.4. 在不同的项目中，特征有较多的重叠

2.5. 发现可用特征

2.5.1. 作为探索阶段的一部分，数据科学家搜索可用于构建机器学习模型的可用特征

2.5.2. 目标是重用特征并降低构建模型的成本

2.5.3. 包括分析可用特征是否具有良好的质量，以及它们的使用方法

2.5.4. 随着模型数量的增加，很快就变成了难以管理的管道丛林

2.6. 训练集生成

2.6.1. 在模型训练过程中，需要由一个或多个特征组成的数据集来训练模型

2.6.2. 训练集包含这些特征的历史值，并与预测标签一起生成

2.6.3. 特征集需要不断地更新新值

2.6.3.1. 这个过程称为回填

2.6.4. 有了特征存储，在构建模型的过程中就可以获得特征的训练数据集

2.6.5. 开发训练集往往要花费大量的时间

2.7. 用于在线推理的特征管道

2.7.1. 对于模型推理，特征值作为模型的输入，然后由模型生成预测输出

2.7.2. 在推理过程中，生成特征的管道逻辑必须与训练过程中使用的逻辑相匹配，否则模型的预测将是错误的

2.7.3. 除了管道逻辑之外，在在线模型中生成用于推理的特征时延迟也要尽量小

2.7.4. 当前，嵌入在机器学习管道中的特征管道不方便重用

2.7.5. 训练管道逻辑的变化可能无法与相应的模型推理管道保持一致

3.1. 特征处理耗时包括创建和管理特征所花费的时间

3.1.1. 特征计算涉及用于生成训练和推理特征的数据管道

3.1.2. 特征服务的重点是在训练过程中为大量数据集提供服务，为模型推理提供低延迟的特征值，并使数据用户能够方便地跨特征搜索和协作

3.2. 特征计算

3.2.1. 特征计算是将原始数据转化为特征的过程

3.2.2. 训练数据集需要不断地用更新的样本进行回填

3.2.3. 关键的挑战

3.2.3.1. 管理管道丛林的复杂性

3.2.3.1.1. 管道从源数据存储中提取数据并将其转换为特征

3.2.3.1.2. 特征数据样本的数量也在不断增长，特别是对于深度学习模型而言，在大规模生产中管理大型数据集需要分布式编程来优化扩展性和性能

3.2.3.1.3. 构建和管理数据管道通常是模型创建中最耗时的部分之一

3.2.3.2. 为特定的特征编写单独的管道来训练和推理

3.2.3.2.1. 有不同的时效要求，模型训练通常是面向批处理的，而模型推理是流式的，要求近实时的延迟

3.2.3.2.2. 训练和推理管道计算中的差异是导致模型准确率问题的关键原因，也是在大规模生产中进行调试的噩梦

3.3. 特征服务

3.3.1. 特征服务包括为训练提供大量特征值，以及为推理提供较低的延迟

3.3.2. 它要求特征易于发现，并易于与其他现有特征进行比较和分析

3.3.3. 关键挑战是性能扩展，因为在原型开发过程中，数据用户要在数百种模型排列中进行快速探索，避免探索重复的特征也是关键挑战之一

3.3.4. 常见的问题是，模型在训练数据集上表现良好，但在生产中表现不佳

3.3.5. 标签泄露是由于为模型特征提供了不正确的时间点值

4.1. 特征存储服务是特征的集中存储仓库，既可以提供特征在数周或数月等长时间内的历史值，也可以提供几分钟内的近实时特征值

4.2. 特征计算

4.2.1. 特征计算需要与数据湖和其他数据源进行深度集成

4.2.2. 维度

4.2.2.1. 考虑要支持的不同类型的特征

4.2.2.1.1. 特征可以与单个数据属性关联，也可以是复合聚合而成

4.2.2.1.2. 相对于标称时间，特征可以是相对静态的，而不是连续变化的

4.2.2.2. 考虑特征工程需要支持的编程库

4.2.2.2.1. 在处理大规模数据集的用户中，Spark是数据整理的首选

4.2.2.2.2. 处理小型数据集的用户更喜欢使用NumPy和pandas等框架

4.2.2.3. 考虑保存特征数据的数据存储系统

4.2.2.3.1. 存储系统可以是关系型数据库、NoSQL数据存储、流计算平台以及文件和对象存储

4.3. 特征服务

4.3.1. 特征存储需要支持强大的协作能力，特征的定义和生成应该可以跨团队共享

4.3.2. 特征组

4.3.2.1. 特征存储有两个接口：向存储写入特征，以及在训练和推理时读取特征

4.3.2.2. 特征通常被写入文件或特定项目数据库

4.3.2.3. 基于同一个处理作业计算的特征或来自同一原始数据集的特征可以进一步分组

4.3.3. 性能扩展

4.3.3.1. 特征存储中支持的特征数量

4.3.3.2. 调用特征存储进行在线推理的模型数量

4.3.3.3. 用于日常离线推理和训练的模型数量

4.3.3.4. 训练数据集中包含的历史数据量

4.3.3.5. 生成新样本时回填特征数据集的每日管道数

4.3.3.6. 特定的性能扩展要求

4.3.3.6.1. 计算特征值的TP99延时值

4.3.3.7. 对于在线训练，要考虑回填训练集的时间和数据库模式突变

4.3.3.8. 通常，历史特征需要少于12小时，而近实时特征值需要少于5分钟

4.3.4. 特征分析

4.3.4.1. 特征应该是可搜索的和易于理解的，以确保它们在机器学习项目中被重用

4.3.4.2. 数据用户需要能够识别转换以及分析特征，发现异常值、分布漂移和特征相关性

4.4. 非功能性需求

4.4.1. 自动监控和告警

4.4.1.1. 服务的运行状况应该易于监控

4.4.1.2. 生产过程中的任何问题都应该产生自动告警

4.4.2. 响应时间

4.4.2.1. 服务应该在毫秒级响应特征搜索查询请求，这一点很重要

4.4.3. 直观的界面

4.4.3.1. 为了使特征存储服务高效，需要所有跨组织的数据用户都采用它

4.4.3.2. 拥有易于使用和理解的API、命令行界面和Web门户非常重要

5.1. 混合特征计算模式

5.1.1. 将批处理和流处理组合用于计算特征的模式

5.1.2. 机器学习场景

5.1.2.1. 离线训练和推断，以小时为频率计算批量历史数据

5.1.2.2. 在线训练和推断，以分钟为频率计算一次特征值

5.1.3. 功能模块

5.1.3.1. 批处理计算管道

5.1.3.1.1. 传统的批处理作为ETL作业，每隔几个小时运行一次或每天运行一次，以计算历史特征值

5.1.3.1.2. 该管道经过优化，可以在大时间窗口上运行

5.1.3.2. 流式计算管道

5.1.3.2.1. 在实时消息总线上对数据事件进行流式分析，以低延迟计算特征值

5.1.3.2.2. 特征值被回填到批处理管道的大量历史数据中

5.1.3.3. 特征规范

5.1.3.3.1. 为了确保一致性，数据用户不需要为新特征创建管道，而是使用特定领域的语言（DSL）定义一个特征规范

5.1.3.3.2. 该规范指定了数据源和依赖关系，以及生成特征所需的转换

5.1.3.3.3. 该规范会自动转换为批处理管道和流式管道，这确保了用于训练和推理的管道代码的一致性，并且无须用户参与

5.1.3.3.4. 特征是使用DSL定义的，DSL可以选择、转换和组合在训练和预测时发送给模型的特征

5.1.3.3.5. DSL是作为Scala的一个子集来实现的，Scala是一种纯函数语言，拥有一套完整的常用函数

5.1.3.3.6. 数据用户还可以添加用户实现的自定义函数

5.1.4. 优点

5.1.4.1. 在跨批处理和流时间窗口的特征计算中，能获得最佳性能

5.1.4.2. 用DSL来定义特征，避免了训练和推理的管道实现中的差异带来的不一致性

5.1.5. 缺点

5.1.5.1. 在生产中实现和管理该模式并不简单，它的实现依赖成熟的数据平台

5.1.5.2. 混合特征计算模式是实现特征计算的一种先进方法，它同时针对批处理和流式计算进行了优化

5.1.5.2.1. Apache Beam等编程模型正在逐渐将批处理和流式计算融合起来

5.2. 特征注册模式

5.2.1. 用于训练和推理的特征的模式

5.2.2. 特征注册模式可以让特征易于发现和管理，并能高效地为在线/离线训练和推理服务提供特征值

5.2.3. 批量训练和推理需要高效的批量访问，实时预测需要低延迟、每条记录的访问

5.2.4. 单一存储对于历史和近实时特征来说并不是最佳选择的原因

5.2.4.1. 数据存储对于点查询或批量访问都是高效的，但不是同时都高效

5.2.4.2. 频繁的批量访问会对点查询的延迟产生负面影响，使得两者难以共存

5.2.4.2.1. 不管是哪种用例，特征都是通过规范名称来标识的

5.2.5. 对于特征发现和管理，特征注册模式是发布和发现特征以及训练数据集的用户界面

5.2.6. 特征注册模式还可以作为一种工具，通过比较特征版本来分析特征随时间的变化

5.2.7. 功能模块

5.2.7.1. 特征值存储

5.2.7.1.1. 存储特征值

5.2.7.1.2. 针对批量存储的常见解决方案有Hive（Uber和Airbnb使用）、S3（Comcast使用）和Google BigQuery（Gojek使用）

5.2.7.1.3. 对于在线数据，通常使用Cassandra等NoSQL存储

5.2.7.2. 特征注册存储

5.2.7.2.1. 存储计算特征的代码、特征版本信息、特征分析数据和特征文档

5.2.7.2.2. 特征注册提供自动特征分析、特征依赖跟踪、特征作业跟踪、特征数据预览，以及对特征/特征组/训练数据集元数据的关键字搜索

5.2.8. 优点

5.2.8.1. 它提供了高性能的训练数据集和特征值服务

5.2.8.2. 它能减少数据用户的特征分析时间

5.2.9. 缺点

5.2.9.1. 当为数百个模型提供服务时，可能存在性能瓶颈

5.2.9.2. 特征数量不断增加时，需要为连续特征分析进行扩展

5.3. 开源的特征存储服务

5.3.1. Uber的Michelangelo

5.3.2. Airbnb的Zipline

5.3.3. Gojek的Feast

5.3.4. Comcast的Applied AI

5.3.5. Logical Clock的Hopsworks

5.3.6. Netflix的Fact Store

5.3.7. Pinterest的Galaxy