一、背景与思考
1.1 背景
携程酒店排序推荐广告工程（以下简称酒店推荐工程）在数据层面引入抽象化的统一数据协议UnifiedPB，解决了过去各场景各自维护，建立各自的数据流，网状开放式数据表，烟囱式迭代的问题，实现了全场景数据的标准化、规范化、统一化。
那么，UnifiedPB具体是什么呢？它是基于protobuf构建的统一工程、策略、数据三方的标准数据模型。从数据时效性上，我们抽象出三类：Online、NearLine、Offline；从数据类型归属上，我们抽象出四类：User、Item、User-Item、Common（公用字典）。
UnifiedPB数据作为酒店推荐工程最核心的底层数据基座，是整个推荐工程的数据入口，无论是在线Serving（召回→ 粗排 → 精排 → 重排），还是离线调研（特征调研 → 小流量 → 全流量），全链路多模块都强依赖UnifiedPB数据，因此UnifiedPB数据填充的上线质量和效率显得尤为重要，将直接影响到系统推荐质量和策略收益效果。
1.2 存在问题
基于上述现状背景，虽然我们引入UnifiedPB统一数据协议解决了网状开放式迭代问题，但是UnifiedPB数据填充在开发效率和成本等方面还存在如下一些问题亟需解决：
迭代效率低：case by case按需、人工hardCode开发、专人运维模式，交付周期长，效率低。例如60个特征从需求提出，到开发测试，最终上线预估需要8天。
复用效率低：三端、跨场景之间无法快速直接复用。一个版本特征在某个小流量场景实现显著后，期望能够在其他场景快速复用生效，需要重新进行重复开发工作，效率低。
逻辑耦合不透明：策略逻辑与数据工程强耦合，且不透明化，排查问题需要人工扒代码，排查效率低。
成本不可控：数据版本生命周期缺乏有效的管理监测机制，各模块各阶段（小流量/全流量）所依赖的数据版本是由人肉进行控制。随着特征数据的快速迭代，势必会造成数据冗余存储，快速扩张，造成资源浪费。
三端不统一：酒店排序推荐广告一直存在着三端（国内/海外/IBU）不统一的问题，三端各自进行迭代，架构逻辑不统一，数据不统一是其中最底层最重要的一部分，需求无法快速三端同时上线。
二、解决方案
针对上述面临的效率和成本问题，我们以技术驱动主动进行工程端的重大技术升级创新。基于serverless理念，设计并落地了填充引擎框架，实现了逻辑与资源的隔离解耦，策略只需关注逻辑，工程负责框架。框架核心架构bin+data+conf，构建出标准化、低码化、配置化、可度量的数据填充引擎，实现一站式、自动化数据填充。同时，对全场景数据进行统一收口，对数据创建到销毁下线的全生命周期管理监控机制，杜绝冗余存储，有效控制资源成本，实现资源利用率最大化。
2.1 实现方案
基于逻辑与资源隔离的核心思想，设计出如下图的实现方案，总体分为两块策略逻辑和工程框架。其中，策略逻辑主要是进行逻辑开发，算法同学只需要关注逻辑实现，可用最擅长的、学习成本最低的SQL实现，并通过统一的web页面进行管理和规范。
工程框架主要由工程负责开发，重点关注框架的功能性，流程规范制定和性能保障。两者之间通过配置进行解耦并关联，最终以配置驱动，实现需求上线。通过框架实现标准化、配置化、自动化实现UnifiedPB数据一站式填充，最终输出给推荐引擎（排序推荐广告三端全场景）。
2.2 框架架构
框架整体架构包含Bin + Conf + Data三个模块，Data模块即特征数据生产模块，生产逻辑由需求方策略同学开发；Conf模块配置中心，是连接填充模块和数据之间的桥梁，使用公司内部框架qconfig进行配置文件存储。由于配置文件内容直接影响UnifiedPB数据填充结果，因此文件的生成只能通过web页面按照规范自动生成，严格禁止进行人工直接修改。
Bin模块是框架核心模块，主要包含CodeGen、DataLoad、Transform、ConfListen等模块。为了提高框架整体性能，采用字节码+反射方式，在应用初始化阶段进行配置文件的解析，生成相应的动态类，实现对用PB节点的数据填充；数据加载模块即将策略生产的特征数据实时加载，给填充模块进行填充；当需要对源数据字段级别的数据进行二次处理，即可以使用transform模块，支持以插件形式进行扩展，用户自定义实现相关功能。配置更新模块会实时监听配置文件变化，当需要新增修改特征数据时，配置更新模块将实时获取到实时结果，异步进行动态类构建。基于上述几个核心模块整体联动协调，实现UnifiedPB数据一站式、自动化填充。
2.3 质量保障
通过配置驱动，自动化实现需求上线，大家会担心觉得不够可靠。那么我们是如何保证需求上线质量的呢？我们有一套完整的流程去保证这件事情的稳定性和可靠性，实现每次变更都可灰度、可回滚、可观测。
质量保障覆盖发布前、中、后三个阶段，发布前主要是自动化测试，包含一套标准全面的测试组件Pipeline（TestCase/BDA/PFT），确保每次发布变更的稳定性和可靠性。规则校验：主要是对数据质量进行一些基本规则校验，比如总量、值范围等；TestCase：即单例测试，主要对本地新增的特征进行单例测试，确保新增特征的准确性；BDA：批量兼容性测试，确保新增数据，不影响老数据；PFT：性能测试，确保每次新增特征，对性能影响符合预期可控范围之内。
发布中、后主要以监控为主，包括整体服务性能监控和数据级别监控，同时有一键回滚机制。
2.4 可视化平台
平台接入使用方式，与设计理念基本一致，包括三个角色：策略、工程、平台。策略负责特征逻辑实现（标准化SQL语句）、工程负责框架升级和发布校验流程执行、平台负责规范约束。下图给出了策略新增特征所进行的具体流程。
策略：选择数据源 -> 特征导入 -> 编写SQL逻辑 -> 定义主键 -> 特征路径选择
工程：审核新增特征 -> 灰度发布 -> 自动化pipline -> 发布
三、落地成果
3.1 落地场景
该项目已分阶段（酒店词推荐（2023.02）、IBU全场景（2023.04）、海外全场景（2023.05）、国内全场景（2023.09））在酒店排序广告推荐三端20多个场景落地上线，100%覆盖酒店排序推荐广告全场景。后续将积极赋能推广到其他BU团队，近期已在准备在携程公共首页信息流团队接入。
3.2 效率提升
需求迭代上线效率
产品策略日常新增特征需求，都需要经过特征数据数据从数仓Adm层->UnifiedPB。以往hardCode开发模式，包括需求沟通、排期、开发、测试、发布，这样一个长周期的上线过程（8d/60个特征）。填充引擎在这一阶段实现数据填充的配置化、自动化，产品策略需求上线周期从天/周级别 -> 小时级别。同时数据跨场景之间可以直接快速复用，复用效率也得到了极大提升，整体效率提升90%以上。
特征数据表切换效率
排序推荐广告业务不同于其他业务领域，模型的推荐效果对特征数据的一致性、准确性有较高的要求。当遇到特征数据上游团队（前端埋点、数仓等）有数据变更或迁移时，需要重新开发接入新数据，进行线上无diff AB实验。以上半年前端埋点token数据切换为例，接入token新数据开发测试上线用时近15天，整体效率低，并且会影响上游团队的进度。为此，填充引擎针对此类需求，实现了在线AB分版本特征填充的配置化，可快速实现此功能，当天即可上线，已在多场景落地应用。
上图展示了我们构建的数据度量系统，横轴代表需求新增特征数量，纵轴代表从需求提出到开发完成上线所用的时间。可以明显看出，接入填充引擎前后，需求上线迭代的效率明显提升。接入填充引擎前，由于开发人员排期、开发测试、新增特征的数量、开发过程中遇到节假日、开发人员休假等因素，需求上线迭代效率非常低。接入填充引擎后，上线效率明显提升，并且排期开发、特征数量的多少等因素对上线效率的影响很小，上线时间基本维持在小时级别，当天即可上线，平均新增一个特征用时由20+小时降低到2小时，效率提升90%以上。
3.3 三端数据统一
针对酒店排序推荐广告三端不一致的历史长期问题，填充引擎实现了数据层面三端的一致性，对三端各业务场景提供统一的数据访问层，数据透明化，无需关注具体数据内容；产品策略同学通过可视化配置，即可实现三端数据的快速同时上线，彻底解决三端数据不一致、复用上线效率低的问题。
3.4 成本可控
通过featureLineage构建了一套从数据创建到销毁下线的全生命周期管理监控机制，进行可视化管理，全场景（精排）数据统一收口，杜绝冗余存储，实现资源利用率最大化，有效控制资源成本。
3.5 逻辑透明
策略逻辑与数据填充的解耦，数据填充逻辑、Source-Target映射关系实现可观测、透明化，产品策略自助进行逻辑排查，极大提高了问题排查效率。
四、总结与展望
这篇文章介绍了酒店机器学习工程团队，围绕效率、成本、效果三个方面，通过技术驱动在酒店排序广告推荐的实践和优化思路。
经过近一年的摸索建设和实践，填充引擎已经建立起完善的架构体系、一站式的服务流程，为酒店排序广告推荐业务的算法迭代提供了高效可靠支撑。未来，将继续围绕上述三方面，在迭代效率、性能优化、成本控制等方面持续投入探索和建设。同时，积极赋能其他BU，在更多的业务场景中发挥平台的价值，助力集团业务蓬勃发展。
作者简介
yang，携程资深后端开发工程师，专注推荐系统架构、数据流批一体、系统稳定性、效率提升等领域；
kevin，携程高级研发经理，专注以技术驱动解决推荐系统中产品业务上的共性问题，创新生产模式，重构生产力；
莫秃，携程高级后端开发工程师，负责酒店机器学习平台的研发工作；
本文采用「CC BY-SA 4.0 CN」协议转载自互联网、仅供学习交流，内容版权归原作者所有，如涉作品、版权和其他问题请给「我们」留言处理。
