Elasticsearch 整合机器学习强化排序

本文介绍如何将机器学习预测能力迁移至es内部，增强排序能力, 构建一个高性能、分布式搜排一体系统，并通过落地更多复杂模型特征和更深的计算，为业务带来新的增长点，我们将LR->树模型完成全量排序，给核心业务带来1.2%的ab增长。

背景介绍

我们团队主要负责哈啰四轮司乘匹配的召回排序，在顺风车司乘匹配场景中，司机发单后系统会从订单池中筛选展示合适的乘客订单，促进司机发单到完单，带来营收。整个过程排序是一个非常关键的环节，目前我们底层的排序架构是用了经典粗排-精排重排级联排序。

在粗排阶段，我们使用LR（Logistic Regression）算法对数千个订单进行排序。而在精排阶段，我们筛选出前300名订单，并使用rankservice完成深度排序。在重排阶段，我们再选取10个订单进入业务相关重排。

我们团队在精排阶段将模型由树模型升级成深度模型，并取得了不错的业务效果，同时也沉淀了一定的技术。因此我们开始考虑将粗排也进行精排化，即采取更加复杂的模型和更多的特征。参考行业经验以及业务场景的特点，如路线匹配路线和算法离线评估，我们决定将粗排从LR升级为效果更好的树模型。

在达成这个目标的同时，也会解决历史中存在的技术问题。之前的树模型受限于技术，单机只能支持300排序 -> 升级到es内部完成全排序。LR的迭代全部手写代码->编程配置化，加速迭代，增加稳定性。

整体方案

机器学习在线预测流程

需要在程序中获取一批特征inputs传入模型，返回模型预测分数output。在这个过程中，根据来源分成以下几种类型：

• 实时特征
• 上下文特征  
• 离线特征    
• 组合特征

每种类型特征都需要对应一套技术解决方案。

具体方案

我们将整个机器学习以插件的形式嵌入es内部，其中包含多个重要的组件。

1.特征获取方案

• 实时特征
  司机的实时特征由flink计算后上游查询从接口传入，订单的实时特征由flink写入索引。
• 上下文特征
  司机的实时特征由调用传参带入。
• 离线特征
  由kkv系统完成离线特征的加载、查询、更新，可以支持到分钟级别。
• 组合特征
  我们内部设计了一套DSL，通过配置即可完成特征生成，包含了组合特征。

2.重要组件简介

• kkv：
  在线获取离线特征。
• 热加载：
  es脚本插件需要重启整个集群才能完成更新，我们在它的底层接口进行了一层抽象，借助热加载的能力完成对业务插件的更新。
• 执行引擎：
  执行引擎主要用来对模型的加载、预测，底层支持多种算法模型预测。
• 文件分发系统：
  主要用于将文件更新到整个集群，触发业务回调，算法同学在训练平台玩完成kv训练，模型训练以及配置文件设置，会通过文件分发系统实时同步到整个es集群，完成更新，触发业务回调。
• 特征生成：
  特征配置生成系统，通过自定义DSL获取全部的模型入参特征。
• DEBUG：
  用于快速验证在es内部机器学习模型预测的准确性。

关键组件

执行引擎

执行引擎主要用于对模型的加载预测。

算法训练常见的模型有树模型、深度模型，还有部分自定义。不同的模型框架，算法可能需要工程做单独的适配，我们期望有一种通用的执行引擎可以解决掉复杂的适配问题，既可以支持在sparkml 的模型，也可以支持深度学习。我们选择了mleap，它是一种通用的执行引擎，算法同学使用sparkML完成模型的训练，使用mleap进行序列化，生成统一的模型，在线上使用mleap的api 进行加载预测。

kkv系统

主要用于离线特征的加载和查询，我们会面对一些海量离线特征存储查询的挑战。

挑战：

• 检索rt要求高
  举个例子，假设本次检索命中了1000个订单，模型有100个离线特征，单位时间kv检索到达10w次。远程io无法支持，所以做成特征本地化。
• 特征量大
  我们的特征已经到达百亿级别，传统的加载无法支持，这块我们的解决方案是使用mmap内存映射技术，读取二进制实时反序列化，这个解决方案es的docvalue 底层是一样的。

我们调研了一些常见mmap解决实现, ohc mapdb rocksdb paldb , 发现paldb在性能、存储和索引速度都是最快的。

线上数据：

（数据均来自精排的深度学习）

hive表 50G -> 索引文件 20G -> 映射内存 10G

查询速率：获取390订单，100纬度离线100组合50上下文的特征数据，耗时5.6ms。

(总rt 18.5  tf预测: 12.5  特征: 6)

文件分发系统

dragonfly主要用于更新文件触发业务回调。

我们有配置文件 jar 模型 kv 文件，需要被分发到es内部，触发回调。我们针对共性的需求开发了一个分发系统。

逻辑很简单，文件通过dragonlfy 上传到存储系统中(OSS,HDFS等)，修改meta，consumer 监听远程文件，发现meta变更自动下载文件->校验md5->触发回调用。

功能：

• 文件变更自动下载最新文件，触发业务回调；
• 极速MD5校验本地记录MD5；
• 易用性，支持注解驱动；
• 支持灰度加载，可与任意配置中心整合 apollo，自定义配置；
• 更新回调状态，用于监控；
• 支持多环境，采用虚拟环境；
• 支持多回调等等。

以下为rankservice与spring整合的截图。

 //文件监听
  @Dragonfly(storagePath = "model/lo_cc_deep_model_v1.tar.gz")
    public void getDeepFMModel(File file, String path) throws IOException {
        super.getDeepFMModel(file,path);
    }
  //多回调
  @Dragonfly(storagePath = "model/lo_cc_deep_model_v1.tar.gz")
    public void test(File file, String path) throws IOException {
        System.out.println("单体测试3");
    }
  //目录监听
  @Dragonfly(dirPathMonitor = "model/deep",filterBean = ApolloFilter.class )
    public void getDeepFMModel(File file, String path) throws IOException {
        super.getDeepFMModel(file, path);
    }

热加载

不需要重启整个集群即可完成插件更新的功能。

es启动的时候就会进行热加载插件的加载，通过dragonfly监听/回调业务.jar，装载实现进入插件库，es query 中指定相关的实现即可完成对业务执行。

jar里面包含了多种类型插件实现：

• filter实现：eta过滤，夹角过滤，沿途距离过滤等
• sort实现：排序有顺路度，mleap排序(树模型排序，tf排序)
• script_field实现：字段插件有顺路度

插件开发tips：

• 是否存在外部资源
  需要手动关闭
• 是否存在第三方jar，存在内存泄漏
  热加载常见问题内存泄漏，可以通过压测来发现
• 提前加载预热，防止突刺
  对class提前初始化，存在资源加载的情况
  模型提前预热
• 分层热加载
  轻资源 class的加载和卸载
  重资源独立，不参与热加载，比如 kv 热加载会导致之前的kv pagecache淘汰，重新reload，会消耗系统资源
• 错误日志限制输出
  es 文档计算是row by row，有多少文档输出多少次日志，严重消耗系统cpu，导致服务不稳定
  限制一次请求只能输出一个错误日志

配置化的迭代

我们期望特征迭代配置化，算法工程同学不写一行代码。

难点：特征组合(特征交叉)，特征处理的逻辑千变万化，需要设计一套方案来解决特征灵活变换的问题。

介绍：如何获取一个组合特征

如图所示, 原始user 特征+原始item特征，经过特征组合或者交叉，生成模型特征。

我们看下之前的解决方案：每个特征都需要手写代码，一个模型有几百个特征，非常麻烦，并且容易出错。

我们的解决方案：使用自定义算子+原始特征，利用反射来完成特征生成。

我们内部自研了一套dsl，通过配置就完成模型任意类型特征的生成。（实时 kv 上下文 组合）

我们会将验证准确的特征配置录入到特征表中，算法同学在录入模型特征的时候自动出提示，保证录入的准确性与效率，如果是模型微调v2版本，直接复制v1 修改几个特征即可。整个算法特征被管理起来，保证同组使用的唯一性。

DEBUG

在ES内部快速完成机器学习debug。

解决方案:
ES内部有一个API
org.elasticsearch.script.ScoreScript#execute(ExplanationHolderexplanation explanation)
我们将计算每个item预测过程进行对外输出。

比如以下例子：包含了策略名称，请求入参数，模型入参数

explanation.set(String.format("mleap(policyName=%s,params=%s,detail=%s)", this.sortPolicy, params,tempMap));

如图所示：可以对匹配到的订单进行debug

可以获得：原始user特征，原始item特征，模型入参特征详细信息，这样就可以对模型的准确进行校验。

稳定性

完善压测方案

每次新上线模型前除了常规的fat、uat环境测试，上了pre环境会进行压测回归&新功能验证。

针对存在的风险点进行极限压测

涉及变更点：业务插件，模型，特征；

要求：新老插件交替，模型特征重置，保证不出现抖动，在任意变更点保证服务都是稳定的；

方案：天级别变更为分钟级别变更；

结果：经过一周的压测，服务整体稳定，没有出现内存泄露，基本判断方案成了。

灰度变更

稳定性三板斧：可灰度，可监控，可回滚。由于新上模型，需要做变更灰度。我们借助dragonfly顺序加载&灰度来完成。

dragonfly优先监听加载灰度文件，针对灰度文件配置加载其他文件。

如上图所示：

• 模型1：允许2台机器加载
• 模型2：只允许节点为ES1进行加载
• jar：允许两台机器加载

机器学习分组加载

各个业务的模型不一样，需要的特征也不一样，我们期望针对每一个模型进行分组加载，而不是让每台机器全量加载。这里我们借助的是es的分组特性和index的模板。

我们在创建index的时候会直接绑定这个index在哪些机器上生成，如index1在group1上，index2在group2上，index3在group3上，通过文件分发系统来完成对整个机器学习的分组加载。同时，我们也可以通过对每个业务模型特征，进行分组加载来减少不必要的开销。例如，某些业务可能只需要部分特征进行训练，kkv系统支持按需进行索引部分字段提供线上查询，这样就可以减少特征的维度，从而降低了计算成本，提升了系统性能。

模型预测加速

我们从三个维度进行机器学习的性能加速。首先是请求缓存，第一个是user特征的缓存，计算一次后可重复使用。第二个是对象复用，由于es的计算是row by row的计算，我们计算完一个row后，它的模型入参inputs可以继续复用，下一个计算开始的时候直接对item维度特征修改即可。

其次是模型缓存，即模型预测加速。我们固定了输入/输出的schema，并预分配足够的内存空间用于存储所有的结果数据，从而避免了多余的计算和内存空间动态分配的开销。同时，我们也采用了模型入参减少key的输入优化方式，进一步缩短了计算时间。

接下来是全局缓存，我们通过mmap内存映射技术做整个kv的加速，还有一些做特征加速。我们会有一些高频的特征，比如某个特征的均值、方差、最大值、最小值等，具有量小、高频访问特性，所以我们可以把它长驻堆内。

上线后业务上的表现

1.支持spark 全部的模型；
2.模型迭代，免开发，通过特征配置化、热加载、压测、灰度可以快速稳定上线；
3.算法插件组件化、可插拔、灵活编排和支持多轮排序；

这里是一个常见的例子，es召回完成之后，直接进行级联排序,模型B进行score，模型C进行rescore。其次是灵活编排，我们整个模型库可能有ABCDEF的模型，假设在第一阶段有10000个订单，我们使用模型ABC同时进行排序，排序后组合取Top1000进行模型D排序，排序后取300个进行模型E排序，整个过程非常灵活。

4.热加载，特征模型 jar实时更新，无抖动；
5.火焰图，单核心场景，排序只占到7%的cpu消耗；
6.在单机单分片场景 1500深度下,  树模型相比LR 多了10ms，全场景 LR  -> 树模型，顺风车核心ab 增加 1.2%。

后续动作

短期目标：后续我们计划会补齐es的排序短板，支持深度学习。

目前主要的问题在于es的计算是row by row的，没有办法使用TF的batch计算，每一次计算TF都要开启session，这是非常耗资源的。这块未来会通过es rescore插件来解决。

同时我们会去整合openvino，目前在业内有很多机器学习框架，如Tensorflow、飞桨、Pytorch、Caffe等，算法又有这方面的诉求，需要工程同学去做每一个框架适配，我们在思考有没有统一的解决方案，可以将主流的DL框架收拢起来，使用一个API就能完成预测。我们发现可以使用openvino来解决这个问题。目前已经在做相关的技术调研，预计下半年可以上到我们的rankservice中，稳定半年以上就会开始迁移到ES。

我们最终期望实现的目标是将所有排序都在es内部完成，可以达到一排到底，做到极致的性能及高度的灵活。

问题：排序系统为什不单独做？

我们选择将排序系统与搜索系统结合在一起，主要是为了在有限的资源内兼顾性能和业务效果。

这样做的优势包括：

• 性能强大：我们将搜排系统融合在一起，使得排序系统具有极强的性能。
• 开发、维护和运维成本低：与单独构建排序系统相比，我们不需要关注数据质量、存储、分片、查询mapreduce等问题，因为搜索系统已经提供了这些功能，因此我们所需关注的就是排序方法，这使得我们的排序系统更加灵活并易于维护，相当于了实现Serverless运行。
• Lucene的完善支持：我们的排序系统使用Lucene作为基础，并利用其丰富的功能（例如function_score、score、rescore和debug），这使得我们可以进行灵活编排和支持多轮排序的操作。
• 稳定&效率：我们的排序系统使用特征配置化的方式来进行开发，通过标准化的上线流程、压测、灰度和分组等一系列措施来保证其稳定性，这可以使得我们的系统更加易于管理和调试。

综上所述，将排序系统和搜索系统结合在一起，可以实现性能优秀、维护成本低、功能丰富、操作灵活和稳定性高的排序系统，这正是我们所需要的。

（本文作者：彭晟）

关注公众号「哈啰技术」，第一时间收到最新技术推文。