导读:本文主要分享阿里云 FeatHub 项目组在特征工程开发中的平台实践和建设经验。

本次分享分为四大部分,第一部分总体介绍 FeatHub 在特征开发、部署、监控、分享过程中面临的场景、目标、痛点和挑战;第二部分介绍 FeatHub 的架构思路实践,及相关核心概念;第三部分介绍 FeatHub 在使用过程中的 API 基本使用、基本计算功能,样例场景的代码实践,还有性能优化,未来的扩展目标,以及开源社区的共建,提供项目的学习、开发使用,还将分享 FeatHub 历史数据的回放功能, 支持离线、近线、在线处理和阿里云上下游组件的支持等问题。

今天大部分流行的机器学习的推理和训练程序基本都是由数据科学家用 Python 来编写的,比如流行的 TensorFlow、PyTorch 以及一些传统机器学习场景中用到的 scikit-learn 等等。我们希望支持数据科学家继续使用熟悉的 Python 编写特征工程代码来完成端到端机器学习链路的开发与部署,并且能够使用他们所熟悉的 Python 生态环境中的库。

越来越多的机器学习应用在往实时方向发展,通过实时处理可以提高机器学习的效率和准确度。为了达到目标,需要生成实时特征。这里不仅仅是去实时获取查询特征,而是要实时生成特征。例如需要实时获取用户在最近两分钟内的点击次数,为此需要使用流式计算引擎完成实时特征计算。

越来越多的中小型公司希望做到多云部署,以得到生产的安全保证,以及获得云厂商之间的竞价优势。因此我们的方案不要求用户绑定一个云厂商,而是要让用户能够自由地在不同云厂商之间做选择,甚至在私有云部署特征工程作业。

今天已经有很多公司在开发实时特征工程作业。其中存在一些痛点,涵盖了特征的整个生命周期,包含开发、部署、监控、以及之后的分享。

开发阶段,用的比较多的是实时特征框架 Apache Flink,因为 Flink 已经基本上是实时流计算的事实标准,但是用 Flink 或者类似的框架来开发实时特征存在着需要解决特征穿越的难点。很多数据科学家并不了解特征穿越的解决经验,并且需要比较多的学习时间和成本来解决这类问题,这是开发阶段的主要痛点。

很多公司会有一个专门的平台团队把数据科学家写的单进程 Python 作业翻译成可分布式执行的 Flink 或者 Spark 作业,来实现高性能高可用的部署。其翻译过程会增加整个开发生命周期长度。并且因为还需要额外的人力去做翻译工作,增加了开发成本,更进一步带来了引入 Bug 的可能。另一拨人将数据科学家的作业翻译之后的逻辑未必和原先的逻辑保持一致,这样就带来更多的 Debug 工作量。

特征工程作业的整个质量和效率不只是取决于作业有没有 Bug,还依赖于上游的输入数据数值分布能满足一些特性,例如能接近于训练时的数据数值分布。很多作业的推理效果下降,经常是由于上游作业生产的数据分布发生了变化。这种情况下,需要开发者去追踪整个链路,一段段去看在哪个地方的特征数据分布发生了变化,根据具体情况再去看是否需要重新训练或者解决 Bug。这部分人力工作量过大也是一个痛点。

虽然很多特征计算作业的开发团队和场景不同,但其实用了类似甚至相同的特征定义。很多公司中没有一个很好的渠道,让公司内不同团队能查询和复用已有特征。这就导致不同团队经常需要做重复开发,甚至对于相同特征需要重复跑作业去生成一些特征。这带来了人力和计算/储存资源的浪费,因为需要更多的计算、内存、存储空间去生成相同特征。

为了让大家能够理解什么叫特征穿越,上图给出了一个简单例子,来展现这个问题。图左上表是用户的一个行为特征,表达了在不同时间节点,对于一个给定 ID 的用户,在最近两分钟内的点击数。这个点击数可能帮助我们推理用户是否会点击某个广告。为了用这些特征去做训练,通常需要将特征拼接到用户带有 Label 的一些数据集上。图左下表展现的是一个用户实际有没有点击广告的一些正样本和负样本的数据集,标注了在不同的时间点,用户所产生的正样本或负样本。为了将这两个数据集中的特征拼接起来,形成训练用的数据集,通常需要根据用户 ID 作为 key 进行特征拼接。如果只是简单地进行 Table Join,不考虑时间戳,就可能产生特征穿越问题。 例如在 6:03 分时,用户最近 2 分钟点击数应该是 10,但拼接得到的特征值可能是来自 7:00 分时的 6。这种特征穿越会带来实际推理效果的下降。一个具有 point-in-time correct 语义的 Join 结果应该如下图所示:

为了在样本拼接时避免特征穿越,对于在上图左表中的每一条数据,应该在维表的多个版本特征当中找到时间戳小于并且最接近于左表中的时间戳的特征数值,并将其拼接到最终生成的训练数据集上。这样一个具有 point-in-time correct 语义的拼接,将产生上图右边所显示的训练数据集。针对不同的时间点,都有所对应最近两分钟内产生的特征值。这样生成的训练数据集可以提高训练和推理的效果。

接下来介绍 FeatHub 作为一个 Feature Store,对于整个特征开发周期的每一阶段试图解决的问题和提供的工具。

在特征开发阶段,FeatHub 会提供一个基于 Python 的具有高易用性的 SDK,让用户能简洁地表达特征的计算逻辑。特征计算本质是一个特征的 ETL。开发阶段最重要的是 SDK 的易用性和简洁性。

在特征部署阶段,FeatHub 会提供执行引擎,实现高性能,低延迟的特征计算逻辑的部署,并且能对接不同的特征存储。部署阶段最重要的是执行引擎的性能和对接不同特征存储的能力。

在特征监控阶段,为了方便开发者及时发现特征数值分布的变化并做出应对,FeatHub 将来会产生一些常用指标来覆盖常见的特征质量问题,例如具有非法数值的特征比例,或者特征平均值,并根据这些指标进行报警,去及时通知负责人调查相关特征分布变化的原因和做出应对,来维护端到端的推荐链路的效果。

在特征分享阶段,FeatHub 将来会提供特征的注册和搜索能力,支持同一公司内不同团队的开发人员去查询自己想要的特征是不是已经存在,并复用这些特征定义和已经产生的特征数据。

上图中说明 FeatHub 的核心特点。在开发阶段,FeatHub 能提供简单易用的 SDK,支持具有 point-in-time correct 语义的特征拼接,特征聚合等逻辑。在部署阶段,FeatHub 能支持高吞吐、低延迟的特征生成,支持使用 Flink 作为执行引擎来计算特征;并且能支持多种特征存储系统,方便用户自由选择所希望使用的存储类型。在监控阶段, FeatHub 将能提供实时指标来监控特征分布的变化,包含离线和实时监控,方便开发者及时发现问题。在分享阶段,FeatHub 将会提供简单易用的 Web UI 以及 SDK,支持开发者注。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注