真的前几天才知道，放到自己的知识版图，接下来完善吧。
https://zhuanlan.zhihu.com/p/357897337
在建模应用领域，有不少数据处理特征工程方面的操作和应用会更加复杂，例如：
-
需要使用模型来生成特征，例如各种表达学习中学到的embedding信息。
-
需要考虑特征计算生成的实践开销与其所带来的模型效果提升的权衡。
-
跨组织的特征共享与使用。
在这些挑战下，feature store的概念逐渐兴起。
v2-e452be489ef1b7aa116a5603a675a0f1_r.jpg
这方面有一个非常不错的汇总网站可以参考：Feature Store for ML ，上面列举了各种开源/闭源feature store实现的信息，包括耳熟能详的Michelangelo，FBLearner，也有像开源界的Feast，Hopsworks等。
Feature Store要解决的核心问题上面也基本提到了，主要包括：
-
一个统一的特征管理中心，包括特征的各类元数据，计算逻辑，特征版本，数据血缘等，方便在组织内部管理和共享特征的使用。
-
特征的生成支持，包括各类数据源的接入，特征自动化计算，持久化，backfill等。很多时候业务都包含了batch, streaming两大类型的数据源，这部分感觉可以从lambda架构中学习一些经验。
-
特征的消费支持，也可以分为offline和online两大类。Offline就是训练阶段的特征提取支持，而online则是model serving时需要获取特征的支持。这里需要解决的一个比较重要的问题就是training-serving skew。
-
特征的各类监控支持，包括特征生成的开销，特征的统计信息，数据质量，模型应用的精度，特征重要度等等。
从上面这些核心的功能点，可以看到Feature Store的一些比较特别的技术架构设计：
-
在存储方面，大多数的解决方案都会区分提供offline和online服务的存储系统，因为两者的访问pattern分别是大批量获取和小批量低延迟获取。例如Michelangelo里offline存储使用了Hive，而online的存储利用了Cassandra的KV查询能力。Hopsworks的offline存储用了Hudi，可以比较好的支持数据版本。Feast的offline和online存储分别是BigQuery和BigTable/Redis，不过这个选型对不同云平台的支持会有一些挑战。像一些新近的“湖仓一体”技术，或许未来也有机会成为Feature Store的底层技术支持。
-
在计算引擎方面，算法建模的同学最习惯的肯定还是Python生态，而batch和streaming两块比较流行的框架是Spark和Flink。如何保持算法建模的灵活性，同时又要兼顾线上运行的稳定和一致性已经是不小的挑战了，再加上batch和streaming计算逻辑的统一，难度就更大了。Feast在这方面利用了Apache Beam，可以同时支持Spark和Flink后端，但是构建feature的灵活度肯定就没有原生Python那么高了。也有不少公司例如Uber，Pinterest，Twitter都开发了相应的DSL，也是一种思路。国内应该有不少公司也是DSL/SQL的思路？印象中美团有篇文章就提到了他们开发了特征工程相关的DSL。
-
数据版本方面，看起来用Delta Lake/Hudi/Iceberg等的解决方案还比较少，很多都是自行开发的支持。个人猜测跟复杂的serving pattern支持有一定关系，比如Delta Lake对于实时查询访问的支持就会比较困难。
-
数据格式的支持，相比于标准的结构化数据，算法训练过程中不同库需要消费的数据格式也不尽相同，还需要考虑到online serving的格式支持。像offline情况下可以选择parquet存储，支持更高效的数据压缩和传输，而online情况下可能需要json/protobuf之类便于API消费的数据格式。
未来Feature Store也还有很多想象发展空间，例如与Cloud-native技术结合形成的新技术架构；在计算逻辑上的抽象统一，并提高可组合能力；Feature Store中存储的各类元信息，也有机会被meta learning等技术手段进行更加深入的应用。
image.png
网友评论