#漫谈两轮调度智能优化之路

一、业务背景

关于两轮智能调度引擎的解读，调度指的是通过算法结合人工干预，将任务分配给运维职员，把站点的共享单车调动到另一个站点，以实现全局单车收益的最大化。站点画像是调度的基础数据支撑，涵盖了调度的核心链路。在离线环境中，大家对查询站点画像有需求，而在在线情况下，对查询的时效性要求则更高，必需控制在50毫秒以内，减少搜索等待时间至关重要，由于这直接影响司机的调度体验。

二、问题拆解

站点画像因为高CPU负载所带来的问题，可以分为写入和查询两个方面。首先，写入过程中的Flink任务可能面临同步延迟的挑战。我们对站点上共享单车的聚合指标要求时效性极高，这些指标是模型计算调度任务的枢纽，一旦写入过程中泛起较大的延迟，模型输出的任务质量将受到严峻影响。接下来，查询耗时过长成了我们面临的另一个问题。我们的C端红包车推荐场景中，用户通过选定的空闲共享单车骑行至供应不足的站点以获利，因此低耗时对C端用户来说显得格外重要，必需控制在50毫秒以内。

三、一些尝试

在2023年，我们的团队在高CPU负载的苦恼中挣扎超过一年，同时也针对新增场景进行了一些尝试。首先，针对C真个红包和众包车场景，为了解决经纬度四周调度的瞬时耗时问题，开发了Redis缓存来满意C端用户对低耗时的需求。然而，这种方案在精度上有所欠缺，召回点位的需求以用户为中央的圆形区域，而我们的Redis构建却是长方形的，导致一些召回点位的漏掉。随后，我们还针对供需池场景进行了一些探索，尽管HBase为点查场景提供了支撑，但在实际使用中却发现其不稳定性太高，终极不得不抛却。

四、技术挑战

在经历了近一年的折腾后，2023年的每次技术方案挑战老是涉及站点画像的各种问题，这大概是一种对底层数据稳定性敏感度的锻炼。我们尝试了多种方案，团队成员也换了几波，接力棒在我手中，就像一个定时炸弹，随时都有可能引发事故。面对2024年新增场景和现有场景扩量的需求，站点画像的优化迫在眉睫。

五、优化过程

我们察觉到，在站点画像构建的早期阶段，为了实现多功能查询，我们对所有字段添加了映射，初步统计显示有282个复杂类型的索引（包括文本、数字、浮点数、日期、地理位置等）和67个关键词映射，很多实际上没有必要检索的字段也添加了映射，估计经由优化后会有显著效果。接着，我们对ES的相关原理进行了拆解和分析，参考了官网关于映射索引类型的推荐，并将这些知识应用到我们的线上流程中。

5.1、映射索引对集群CPU水位的影响

我们从三个角度分析映射索引如何影响集群机能。首先，当段的创建和合并频繁时，ES集群由多个节点组成，索引用分片构成，每个分片都是Lucene索引实例，跟着刷新天生的段文件增多，合并段的需求也随之上升，段文件数目增加将占用更多的文件句柄、内存和CPU周期，每个搜索哀求需逐段检查，段越多，搜索速度越慢。其次，增加了不必要的字段映射，造成多余的索引构建消耗。再次，错误的数据类型设置也会影响机能，针对数值型字段，假如采用不合适的类型，将影响查询效率。

5.2、选择准确的映射类型映射字段的选择通常根据查询场景决定。在我们的案例中，我们删除了不必要的类型映射并根据实际检索需求调整了字段类型。

5.3、线上零停机重构映射经由上面的先容，得出的结论是只对必要的检索字段进行映射，并根据实际场景选择对应的映射类型。面对300多个映射字段和不同业务多条检索需求的挑战，我们的解决方案先是梳理出核心链路的检索前提，随后实施了可灰度、可回滚、可监控的稳定性方案，终极成功完成重构。

六、效果在进行映射优化后，我们的成效十分显著。复杂类型索引从282减少到74，关键词映射从67减少到59。此外，错误的数据类型修正后，CPU水位在高峰时控制在50%，日常均匀为20%，同时Flink数据同步任务的最大延迟也从1.5小时缩短至10分钟，查询耗时峰值从1秒降至150毫秒，均匀查询耗时则压缩至14.5毫秒。终极，我们不仅压缩了机器，还回收了年化本钱1.6万元。

这次优化之旅，让我们更深刻地理解了数据的气力，真正实现了机器与人的高效协作。像我常说的，“当灵活与不乱交织在一起，结果必然引人注目。”

未经允许不得转载：头条资讯网_今日热点_娱乐才是你关心的时事 » 探讨两轮调度的ES优化之路径与策略