特征配置角度:平台根据每个特征配置,单独启动任务进行特征拉取 。
上游Hive表角度:Hive表中多个特征字段,统一放至同一任务中拉取 。
上述两种方案都存在各自问题,不能很好满足业务需求 。因此,特征平台结合两个方案的优点,并经过探索分析,提出了特征语义的概念:
特征平台对特征语义的处理分为两个阶段:语义抽取和语义合并,如下图所示:
3.1.2 特征多任务调度为了保证每天数十TB数据量的快速同步,特征平台首先按照特征的处理流程:获取、聚合和同步,分别制定了特征语义任务、特征聚合任务和特征同步任务:
同时,特征平台搭建了多任务调度机制,将不同类型的任务进行调度串联,以提升特征同步的时效性,如下图所示:
Protobuf的常规使用方式是通过Proto文件维护特征配置 。新增特征需编辑Proto文件,并编译生成新版本JAR包,在离线&在线同时发布更新后,才能生产解析新增特征,导致迭代成本较高 。Protobuf也提供了动态自描述和反射机制,帮助生产侧和消费侧动态适配消息格式的变更,避免静态编译带来的JAR包升级成本,但代价是空间成本和性能成本均高于静态编译方式,不适用于高性能、低时延的线上场景 。
针对该问题,特征平台从特征元数据管理的角度,设计了一种基于Protobuf的特征动态序列化机制,在不影响读写性能前提下,做到对新增特征读写的完全配置化 。
为方便阐述,先概述下Protobuf编码格式 。如下图所示,Protobuf按“键-值”形式序列化每个属性,其中键标识了该属性的序号和类型 。可以看出,从原理上,序列化主要要依赖键中定义的字段序号和类型 。

文章插图
因此,特征平台通过从元数据管理接口查询元数据,来替换常规的Proto文件配置方式,去动态填充和解析键中定义的字段序号和类型,以完成序列化和反序列化,如下图所示:
3.1.3.2 特征多版本特征数据存储于KV系统中,为在线服务提供特征的实时查询 。业界常见的特征在线存储方式有两种:单一版本存储和多版本存储 。
因此,特征平台选择特征多版本作为线上数据存储方式 。
传统的多版本方式是通过全量数据的切换实现,即每天在全量数据写入后再进行版本切换 。然而,特征平台存在增量和全量两种更新方式,不能简单复用全量的切换方式,需考虑增量和全量的依赖关系 。因此,特征平台设计了一种适用于增量&全量两种更新方式下的版本切换方式(如下图所示) 。该方式以全量数据为基础,白天进行增量更新,版本保持不变,在增量更新结束后,定期进行全量更新(重写),并进行版本切换 。
3.2 特征获取计算:高性能的特征获取计算能力特征获取计算为模型服务、业务系统、离线训练提供特征的实时获取能力和高性能的计算能力,是特征平台能力输出的重要途径 。
- 外卖小哥高烧39℃|外卖小哥高烧39℃送完餐瘫倒在地是怎么回事 如何看待带病送外卖的行为
- 美容院的产品的进货渠道是怎么找到的 美容院进货平台
- 淘米生活是什么平台
- 支付宝打车是哪个平台的车
- 浦惠到家是个什么平台
- Zoom是什么平台
- 美团优选是自提还是送货
- yy平台是做什么的
- 云闪付是什么平台,安全吗?
- 微信聊天记录在平台系统保留多久
特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
