02
-
实时特征计算延迟高： 定制的模板化配置方式和手动分配运行资源，导致奇流海资源调度不合理，频繁出现 IO 阻塞，部分实时特征生产延迟高达 6 小时。 -
离线特征生产故障风险高： 在离线大数据平台上开发数据任务后再通过 SDK 写入特征平台，导致特征配置和特征计算跨平台，无法及时感知任务启停状态变更、管理任务代码，出现过多次故障，影响风控策略效果。 -
特征配置冗余：部分复杂特征需要同时配置实时特征和离线特征，在策略中采用多窗口组合的方式来使用，此时需要在奇数、奇流海平台上分别配置、分别生产，运营效率低下，且存储计算冗余。
03
-
简化特征配置：以 DAG + SQL 的形式提供，DAG 赋予开发者灵活的链路编排能力，SQL 则可以统一流批开发语义，降低开发门槛； -
统一特征生产与管理：我们对接了爱奇艺 Opal 机器学习平台上的特征中心，Opal 为我们提供了特征流批一体调度生产、特征查询 SDK 等功能； -
特征生产提速：通过多重优化策略，如下沉链路异步拆分、运行时任务自动合并、长窗口累计指标拓扑优化进行等； -
高可用：研发特征发布版本化控制和统一发布管理，提升特征任务的资源效率、产出效能及运行稳定性。
04
一体化开发运营
流批一体开发语义
在我们的设计中，DAG 节点被清晰地划分为三大类别：数据源节点、计算节点，以及下沉节点。离线和实时特征任务，尽管它们共享了基本的节点分类框架，但在具体节点类型上有所区分：
-
数据源节点：离线特征任务专注于处理静态数据集，因而仅对接诸如 Hive 或 Iceberg 这类离线数据存储系统。相反，实时特征任务面向动态数据流，支持诸如 Kafka 这样的实时数据源，确保了对流式数据的即时处理能力。 -
下沉节点：延续这一区别，离线特征任务的下沉节点设计上同样偏向离线存储，而实时特征任务的下沉节点则展现出更高的灵活性，既可对接流式数据接收端，也能适应离线存储，满足多样化输出需求。 -
计算节点：双方均采用 SQL 配置节点，强调了易用性和灵活性，允许用户通过标准 SQL 来定制复杂的计算逻辑。实时特征在此基础上更进一步，引入了专用的累计节点类型 Cumulate，专门服务于实时数据窗口内的累加计算，尽管常规 SQL 节点也能实现累计功能，但 Cumulate 节点的引入为实时窗口计算提供了更加方便简洁的配置方案。
统一的部署能力
新平台统一收口了特征的部署链路，支持了特征的版本化迭代和一站式部署能力。这样一来，使用者无需关心底层的部署集群和复杂的任务上线链路；同时基于平台的统一信息管理，用户还可以直观了解任务的生命周期及当前状态，运行时上下游依赖。
优化效果
-
开发效能提升：新平台让我们摆脱了跨平台开发维护特征的历史，我们的特征运营平台数量从 4 个集中到了 1 个；统一的部署流程简化了上线链路：特征开发上线耗时从平均 5 小时缩短为最长 1 小时。 -
特征开发和维护成本降低：由于 DAG 中抽象了数据源和下沉节点，使用者可以聚焦于业务逻辑开发，灵活的链路编排能力让复杂计算链路的组合配置变得简单，统一的 SQL 开发语义也降低了开发门槛；特征的平均开发耗时从 3 小时降低为 30 分钟左右。 -
任务管理能力提升：新平台实现了特征任务的强管理，一方面特征和任务的映射关系变得明晰，另一方面由于统一了任务的打包和部署，基础组件（Kafka、Spark、Flink 等）升级及集群迁移将对使用者无感，平台侧能够进行统一升级。
流特征任务运行优化
合并相同前缀计算节点
-
基于计算前缀与数据源的一致性合并：识别那些源自相同数据源且执行相同计算逻辑的节点，将它们合并为单一运算单元。这样，相同的数据处理只需执行一次即可服务于多个下游任务节点，而其他不具备合并条件的节点则保持独立运行。被合并的任务作为一个整体提交执行，这不仅减少了调度开销，还降低了重复计算消耗并提升了单个任务的资源利用率。 -
风险控制与合并策略的审慎应用：尽管任务合并带来了效率的提升，但我们也意识到其潜在的风险，单个子任务的故障会导致整个合并任务集的中断，同时过多子任务合并会带来单个任务依赖资源过多，不利于计算调度。为平衡效率与稳定性，我们设立了合并任务的数量上限，并通过运行时监控和合并自动调整，动态管理了任务的运行规模，将任务大小控制在一定量级，同时也减少异常扩散的范围。
数据异步下沉
优化效果
-
资源利用率提升：通过适当的任务合并和动态监控调整合并规模，我们将特征运行任务的资源利用率控制在了合理范围（目前特征任务的 CPU 利用率维持在 60% 左右），同时确保了运行的稳定性； -
特征生效延迟降低：基于下沉链路的异步化和下沉消费隔离改造，实时特征缓存生效时间从之前最长 6 小时左右缩短到最长 4 分钟左右。
复杂任务计算优化
-
基础层：直接依托原始数据流，每分钟汇总每台设备过去 60 秒内的登录次数，生成即时数据集合 C1。这一层奠定了后续计算的基础。 -
中间层一：构建于 C1 之上，每分钟进一步汇总过去 10 分钟内每台设备的登录总和，形成数据集合 C2。 -
中间层二：以 C2 为输入，继续每分钟累计过去 1 小时内每台设备的登录总数，输出为数据集合 C3。 -
汇总层：最终层依赖于 C3，每分钟计算过去 24 小时内每台设备的登录总量，得出最终所需的长周期累计数据集合。
特征迭代版本化方案
特征生产版本化隔离
-
特征 key 设计增加版本号维度字段，实现存储逻辑隔离； -
提供特征覆写 SDK，支持基于版本刷新和清理缓存数据。
-
特征试运行阶段多版本任务共存； -
灰度比例控制阶段支持对线上使用特征版本进行动态调整； -
特征回滚操作基于灰度比例快速回退线上使用特征版本，同时通过特征覆写sdk异步清理试运行版本缓存数据； -
上线阶段将只存在最新版特征任务。
-
缓存中查询某个特征最多进行两个 key 点查就可获得数据； -
历史稳定版本特征和最新稳定版特征 key 结构保持一致，确保缓存高效地被新数据覆写，查询时也无需进行多版本路由。反之，如果所有稳定版本特征任务都在 key 中包含版本号，查询缓存时就需要由新至老遍历版本，直至查到第一个数据。
特征查询版本化路由
05
-
图风控支持：图是计算群组特征的一大利器，新平台将摸索与图引擎的结合，利用图作为数据源或计算引擎生产图相关的特征，以支持图风控场景； -
复合特征支持：针对运行时动态特征生成的诉求，我们将推出复合特征，这类特征将集成动态特征计算脚本，支持运行时依赖其他特征或数据接口计算出特征数据；
06
本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
