我们小组主要负责四轮场景下的司乘匹配工作，基于开源分布式搜索引擎ElasticSearch实现订单的召回。同时我们使用Flink实时消费kafka消息，将订单数据写入到对应的ES索引中。

在一次全链路压测过程中，顺风车匹配ES集群出现了个别节点CPU几乎被打满的情况。第二轮压测，我们关闭了最近上线的H3召回匹配升级AB实验，在同样压力下集群cpu运行平稳，保持在35%左右，开启AB实验后之前异常节点cpu又急速增加，初步定位到节点异常应该和H3召回升级实验相关。

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

公司内部的ES访问架构一般是，Java应用--->SLB(域名)---->ES ingest node (no data) --> ES data node，其中ingest节点是对外暴露的，供Java应用访问，承担了一个纯client角色，不提供数据存储和倒排索引检索服务。这其中SLB是为了方便起到一个域名和负载均衡的功能，绑定后端的n个client节点，并且做到对业务...

我们团队基于Elasticsearch开发了一款将数据从数据库实时同步至Elasticsearch的工具——搜索平台，其实现方式主要是通过flink将数据库中已有的存量数据导入Elasticsearch，并订阅数据表的binlog，将实时改动也同步至Elasticsearch。

搜索平台的公共集群，由于业务众多，对业务的es查询语法缺少约束，导致问题频发。业务可能写了一个巨大的查询直接把集群打挂掉，但是我们平台人力投入有限，也不可能一条条去审核业务的es查询语法，只能通过后置的手段去保证整个集群的稳定性，通过slowlog分析等，下图中cpu已经100%了。

今天我要分享的主题是《基于ElasticSearch的搜索平台在哈啰出行的应用》。相信大家对ElasticSearch都有一定的了解。今天主要分享一下基于ElasticSearch的搜索在出行行业的应用，其中会涉及到一些 ES相关的技术细节。最后从大的方面来分享落地平台的一些经验和个人的一些感触，希望今天的分享能够给大家带来一些思考和启发。