前言
从AI概念提出到现在，越来越多的企业受益于AI模型提供的推理、决策等能力。特征是模型的主要输入，好的特征能极大帮助模型提升效果。然而特征的生成又是极为繁琐和耗时的工作，这个过程我们称之为特征工程。从数据采集分析到创建特征再到上线，会涉及到非常多的系统和工具交互，我们需要一个能够简化这些操作的平台来提升效率。
eBay AI平台团队日常与各个业务部门的数据科学家以及工程团队沟通合作紧密，总结了在特征工程这块，当下业务场景需求带来一些普遍性的挑战，主要集中在以下几个方面：
缺乏统一，标准的元数据定义及管理
缺乏对特征线上线下的统一的访问抽象
缺乏对特征的统一管理及使用监督
缺乏特征目录以及搜索发现机制
很难在不同的模型中重用特征
缺乏线上线下数据的一致性
缺乏PiT（Point-In-Time）特征的模拟。
为了解决这些挑战和痛点，eBay AI平台构建了一系列自动化智能特征功能，包含数据源Catalog,语义标注，特征生成（实时/近实时/批处理），自动特征生成以及特征执行DSL化，特征库，模型训练集等等。下图是整个特征工程平台的架构图:
（点击可查看大图）
特征平台核心功能包括：
在构建特征平台的过程中我们总结了一些心得，将以系列文章的方式跟大家分享，包括以下几个方面：
特征元数据和生命周期管理
近实时特征工程
在线特征仓库
线下特征仓库
本篇作为整个系列的开始，将介绍我们在特征平台上统一特征数据模型，如何进行元数据管理、查询、监督以及进行特征的生命周期管理的相关工作。
介绍
整个特征平台在设计的时候，主要从两方面考虑。站在用户的角度，用户需要快速发现特征，开发新的特征，以及对开发的特征进行生命周期管理；站在平台的角度，用户开发的新的特征需要根据其生命周期快速被不同的处理模块发现和生效（例如刚注册的特征需要对线下模拟引擎可见，发布的特征需要对线上近实时处理引擎可见），而不依赖这些处理引擎的重发布或重部署。
基于这两点考虑，我们特征平台从开始设计，一个核心架构原则就是基于统一元数据和配置驱动。
特征工程管理平台，包含以下主要功能：
特征的生命周期管理。这是最核心的功能，包含特征的定义，模拟，发布上线，下线等。
特征搜索发现。很多情况下，用户可以重用已有的特征而无需开发新的特征。加速用户的机器学习体验同时，也极大地节省了重复计算的资源消耗。
配置的管理和自动化。特征平台的业务配置和平台配置，既需要一套统一的管理方法，也需要有不同的管理粒度。
下图是整个特征管理平台的架构图。主要包含了元数据和配置的管理、特征生命周期管理，以及和不同平台团队的集成实现数据源目录集成、数据源上线自动化以及配置自动化。
（点击可查看大图）
我们采用eBay 数据基础平台提供的文档存储数据库来存储元数据和配置，文档存储的弱Schema 特性可以帮助我们未来业务扩展上做更好的支持。我们将特征管理平台在架构上拆解成两层服务。
1）特征管理服务(Feature Management Service )。负责特征管理中的平台集成、交互体验集成，业务验证以及生命周期管理流程等。
2）特征元数据及配置服务（Feature Meta & Config Service）。面向特征元数据和配置存储，提供高效以及高可用的读写能力。
将特征元数据及配置服务单独抽取出来作一个比较“薄”的服务主要是两方面的考虑：
1）元数据和配置的改动尽可能的少，元数据及配置服务核心关注简单的读写，甚至不需要了解具体实体的业务含义，而把相关的语义留给上面的管理服务。
2）整个特征平台在运行时对元数据及配置高度依赖，这是基于我们元数据和配置驱动的架构。所以单独抽取一层服务满足运行时读的需求。
1. 特征数据模型
用户的特征计算来自一些上游数据源，这些数据源主要包含三类：线上的Kafka Topic、线下的数仓里的Hadoop Table以及业务团队自己管理的数据源。数据源是特征工程平台第一个需要管理的元数据。
其次，考虑特征计算的通用典型特征，我们将特征变量抽象成两个基础类型：存储变量（Stored Variable）以及 特征模板（Feature Template）。举个实际业务场景例子，在一些搜广推的模型里，用户过去一段时间浏览eBay的商品数目是模型一个重要的输入特征，这里面就有几个问题需要考虑:
1）存储，用户浏览行为是一个时间序列事件，我们需要把这些事件信息记录或者存储在某些地方，方便快速查询计算；
2）存储复用粒度，A模型可能需要过去3小时的统计值，而B模型需要的可能是过去7天的统计值。通常特征值的粒度最小在分钟级，最高可到天级别。
存储变量(Stored Variable) 指的就是在原始数据源上执行一些预定义的聚合计算后存储在平台里的一些供实际特征计算需要的中间变量。这些聚合计算包含求和，求最大、最小以及平均值等。平台运行时针对默认或者用户自定义配置计算不同粒度的值，存储于健值对数据库中加速后续的特征计算和计算复用。
而特征模版（Feature Template）顾名思义，就是定义了某个特征计算逻辑的模板。以上面的用户行为特征为例，无论是过去3小时的用户浏览商品数，还是过去7天的用户商品浏览数，都是对某个时间段里的用户行为累加，唯一不同的是累加的时间区间不同，所以累加逻辑是模板，而时间区间是计算时带入的参数。故称之为特征模板。带着具体参数（3小时或者7天）调用计算逻辑生成的值就是具体特征。
用户的特征计算通常是围绕具体的Key来进行的，以用户行为特征为例，用户ID是上下文相关的，在某些场景里可能是买家ID，在另外的场景里可能是卖家ID。为了对Key做好治理，我们抽象出了KeyDimension和Key。具体地说，KeyDimension 描述了某一类Key的集合，而Key是有具体业务上下文含义的定义。例如，买家ID和卖家ID是两个不同的Key，但是都属于一个称做账户(Account)的KeyDimension。
所有的元数据都是在平台统一管理起来，但是会分属不同的业务领域（Domain）。特征相关的数据模型抽象可以简化为下图：
（点击可查看大图）
2. 数据源上线管理
用户定义特征变量之前，需要将相关的数据源上线到特征平台，这主要是为了：
获取数据源的元数据，便于特征变量DSL逻辑的自动生成
对于近实时数据源，可以基于数据源做在线到离线的数据转存，方便离线特征模拟
对于近实时数据源，自动配置运行时需要的Kafka Consumer相关的配置信息
2.1 数据源元数据发现
以近实时特征平台(NRT)工作流为例，特征平台依赖数据源的元数据用以：
在UI端根据用户的定义 (托拉拽的方式)，自动生成DSL的计算逻辑，简化用户的特征定义体验。
在用户定义变量的时候做数据源依赖的静态检查，防止因为DSL代码逻辑人为写的不当造成的运行时错误
计算引擎运行时依赖数据源的Shema对上线的新的Topic消息进行反序列化解析。
用户的数据大部分属于两大类，一类是离线的Hadoop数据，另一类是在线的Kafka Topic数据。这些在eBay内部都属于被充分管理的数据(managed data)，由数据基础服务团队(DI)负责。因此我们在项目开始之处，就和DI团队深度合作，利用他们提供的元数据目录服务，来协助平台在用户上线这些数据的时候的元数据集成发现。
特征平台主要集成了DI元数据目录服务的两个核心功能来提供用户上线数据源的体验，第一个是基于关键字的查询服务，第二个是对具体entity(Hadoop Table或 Kafka Topic) 的元数据查询。下图显示了用户上线数据源的体验流程：
选择数据源类型（Hadoop 或者 Kafka），输入关键字查询数据源
从候选的查询结果中，选择需要上线到平台的数据源从可选的数据源字段列表中，选择符合业务需求的字段定义一个或者多个Key Dimension
输入平台相关的配置，完成上线。
（点击可查看大图）
2.2 在线到离线数据转存
为了解决线上线下的一致性问题，特征平台提供了离线模拟能力，这就需要平台能够把线上的Kafka Topic实时转存到离线存储中。我们在这块也依托了DI团队提供的在线到离线转存服务，帮助用户转存已上线到平台的NRT DataSource。对于已上线到平台的数据源，用户通过UI提供一些简单基本信息，即可以完成数据转存服务。
Retention
时间分区字段
需要转存的字段列表
需要转存的数据对应的数据中心
2.3 在线Consumer自动化
对于NRT 数据源来说，当用户定义并发布了一个特征变量后，计算引擎需要部署对应Topic的Consumer。为了简化平台运维成本，特征平台也在这部分做了自动化，并且将这块的自动化配置和其他系统配置一样，实现了运行时的更新发现和热部署。
Consumer 的自动创建，依赖于DI的流团队提供的服务。在用户上线NRT数据源后，平台会向Kafka Service (Rheos)检查并申请Onboard Consumer的ACL权限。在数据源的特征变量发布的时候，向流平台申请Consumer 和 Capacity。
（点击可查看大图）
在实现上，和Kafka平台的集成涉及到权限审批和容量审批等需要异步完成的工作，特征平台通过一些打批的任务来实现异步查询和批量补偿。
3.特征生命周期管理
一个完整的特征变量生命周期包括特征变量注册，线下模拟、发布线上，下线。
刚定义的变量只对线下可见，用户可以通过离线模拟服务来验证定义的变量逻辑。
用户需要通过发布流程发布一个变量到线上生产环境，发布变量需要平台管理员的审核通过。
发布后的特征变量对线上计算引擎可见，线上引擎会基于计算逻辑产生存储变量或响应用户请求计算特征值。
（点击可查看大图）
特征管理平台提供特征变量不同生命周期的验证、发布管理、运行时部署。
3.1 验证
变量在注册和发布时，平台会对变量进行静态编译，避免运行时执行错误。
验证变量定义对应的Key Dimension 是否存在
验证变量对应的数据源以及引用的字段是否存在
验证变量所对应的数据源的Schema
编译验证DSL语法错误
3.2 DSL发布管理
用户定义特征变量(Stored Variable 和 Feature Template) ，最核心的是其DSL内容。DSL最终要被发布到线上生产环境用于计算。特征平台提供了一套轻量级的方法来进行DSL的发布，从而不需要依赖计算引擎的重启。
特征平台在特征变量定义基础上，增加了两个新的数据模型：DSLContent和DSLContentRepo。DSLContent 代表了一个具体变量类型的内容，而DSLContentRepo则可以理解成是一个DSLContent的集合。特征相关的元数据及其相互关系如下图所示:
（点击可查看大图）
DSLContent 包含如下字段：
id，一条记录的唯一标示。特征平台通过DSL本身内容生成的固定长度的摘要，用于发布的唯一性检查和幂等处理。
status，代表当前变量对应的生命周期状态。例如REGISTERED, RELEASED 等。
content，DSL本身的内容。
type，DSL的类型，包含schema定义，存储变量定义以及特征模板变量定义。
DSLContenRepo 则是当前处于同一个status的变量的集合。核心主要是三个字段：
contents，是DSLContent 在某一个时刻的id集合。
status，contents 都属于的状态。
version，版本信息。
当用户注册一个新的特征变量时，系统中除了记录这个变量的元数据外，还会生成一条新的DSLContent 记录和一条新的DSLContentRepo记录，如下图所示，其中v3是新注册的特征变量。
（点击可查看大图）
当用户发布一个新的特征变量并且审核通过后，该变量在DSLContent 记录状态会变成RELEASED 状态，同时会生成一条新的RELEASED 状态的DSLContentRepo记录。下图演示了变量v1发布后的数据模型变化。
（点击可查看大图）
可以看得出，DSLContentRepo是最新的DSL逻辑组合。我们在实现上做了一个简单异步优化处理。假设同时有10个用户的特征变量被发布，Repo的打包可能会收到10个请求，但是最终只会生成一个repo结果， 我们会基于Lifecyle Phase 做一次打包聚合。
3.3 运行时热部署
变量的发布不依赖计算引擎的重启。这里面特征平台通过三个方面来满足轻量级的版本发布更新。
1） 元数据和配置服务提供DSL Repo的版本管理。假设用户在发布变量之前最新的版本是100，则发布一个变量后，最新的版本则是101，并且服务提供查询最近版本的API供计算引擎的运行时查询。
2） DSL Loader SDK。DSL Loader 作为运行时组件，定期查询DSL版本号，当发现版本更新后及时刷新最新的Repo。元数据服务提供了全量和增量的API，来拉取当前最新的所有DSL或者增量变化的DSL，在计算引擎启动和运行时刷新分别集成。
运行时刷新DSL repo的流程为:
（点击可查看大图）
3） 运行时DSL Repo 计算流水线的重编译。计算引擎运行时集成了DSL Loader，当DSL Loader 发生变化的时候，重新编译整个计算流水线。
（点击可查看大图）
4.特征目录和查询
特征平台依赖数据基础服务团队的目录服务来获取发现数据源的元数据，同样，特征平台本身也需要特征目录服务帮助用户快速发现已有特征数据，实现特征发现和重用。在这块特征平台也依托数据基础服务团队的目录服务提供特征平台自身的元数据。
1） 特征平台所有的元数据，在发生增删改的时候，都会把相应的entity event 推送給数据目录服务，包含这些实体依赖的血缘关系，例如数据源对应的Kafka Topic，而Topic 信息天然也在数据目录服务里。
2） 数据目录服务提供基于filter和关键字的查询，用户的特征发现通过特征管理服务转发请求目录服务。
3） 特征平台提供元数据全量查询接口，数据目录服务定期打批做补偿和数据审计。
（点击可查看大图）
5.变量及系统配置热部署
除了特征变量的DSL之外，特征平台还需要依赖一系列的系统和变量层面的配置信息。以近实时特征流水线为例，需要的配置信息有：
特征变量的配置信息。特征平台做到变量级别的配置，对于近实时处理引擎而言，变量层面的配置包含更新数据需要发送的Kakfa Topic的Producer信息，以及存储变量计算的数据写入的数据库的配置。变量级别的配置粒度极大增加了系统的灵活性的同时，也带来管理的复杂性。因而从管理角度，我们做了优化，对于具体的变量来说，我们会根据所属的存储变量类型，提供默认配置，兼顾了灵活性和简易性。
不同计算引擎运行时需要的配置信息。例如用户onboard的数据源的consumer信息，聚合计算引擎需要的Flink Job 信息，存储阶段远程调用的Store Service信息，以及外部依赖服务信息等。
特征平台元数据和配置关系如图所示：
（点击可查看大图）
5.1 变量级配置和多写支持
考虑平台稳定性和业务扩展性支持考虑，平台在开始架构的时候，在配置上做了变量层面的设计，提供了灵活性。
变量层面的配置主要包含两方面： 计算增量结果需要发送的Kakfa Topic 的producer，以及存储阶段需要写入的健值数据库配置。
首先，平台会针对流水线配置默认的producer和kv数据库，这样能做到轻量级的变量配置部署上线，这也满足绝大多数场景需求，减少了人工介入的成本。
其次，平台提供管理员入口可以针对具体的变量定制化实现变量配置的无缝迁移。
最后，在一些场景上，需要把变量的计算结果写到多份数据库中，所以kv数据库配置在数据模型上是一个数组，运行时引擎自动适配实现多写。
（点击可查看大图）
5.2 配置热部署
变量相关的配置因为和DSL发布紧密关联，因而轻量级的部署是天然的要求。对于其他的配置，例如Flink Job, 健值数据库配置等变化没有那么频繁的，我们在管理上和变量配置一样，做了统一的管理，在平台内部做了一个轻量级的配置中心。
和DSL的热部署思想类似，变量和系统配置在运行时从属一个配置版本，当有新的配置或者已有配置修改后，整个系统的配置版本将会升级，计算引擎的运行时配置模块会检测到配置变更从而应用最新的配置信息。以变量发布上线为例，存储变量计算引擎会在运行时依赖配置版本变更执行新的变量的计算。
（点击可查看大图）
5.3 多处理流水线支持
特征平台在管理上的另外一个配置特性就是多处理流水线的支持。简单而言就是底层特征元数据存储只有一套，处理流水线代码也是一套，而构建在其上的处理流水线可以部署多个业务相互隔离的实例。在eBay AI 平台上，除了一些基础变量类型的处理流水线，我们也在管理上支持了不同业务部门独占的流水线。定制化的近实时处理流水线 + 统一的DSL特征开发 + 统一的元数据配置服务，使得平台具有极快扩展支持新业务的能力。
对于多处理流水线的配置支持，主要做到业务和配置两方面的隔离。因为计算流水线上的业务依赖主要是运行时的特征变量配置，所以变量的配置发生变量发布的时候。
变量的配置对系统配置有一些耦合的依赖，主要体现在变量计算依赖运行时的Kakfa Topic的consumer。而Topic作为数据源，在event onboard过程中是不感知具体的运行时流水线的。
因此创建consumer就被延迟到变量配置发生的时候。平台会检测该特征变量需要发布到的具体流水线是否已onboard 对应数据源的consumer，完成onboarding。
在系统配置层面，我们每一个配置都增加了流水线上下文的信息，从而做到配置在流水线之间的隔离。有了这层配置后，和业务的衔接就比较方便。下图展示了多流水线支持的配置数据关系图：
（点击可查看大图）
总结
本文主要总结了eBay AI团队在特征平台上做的一些特征元数据和生命周期管理的思路和相关工作。目前核心实现了统一的数据模型，自动化数据源接入和管理，特征变量的生命周期管理和系统配置自动化管理。希望能给大家带来帮助。
在后续的系列文章中，我们将继续介绍我们在近实时特征工程、在线特征仓库和线下特征仓库的相关工作。
