你好,游客 登录 注册 搜索
背景:
阅读新闻

如何从0组建一个日订单40万的智能化派单系统?

[日期:2019-09-20] 来源:51CTO技术栈  作者:王雪燕 [字体: ]

如果让你从 0 组建一个智能化派单系统,日订单量为 40W,你敢接单吗?你会怎么做?

做过的人都会说简单,没有做过的人却连想都不敢想,其实技术上并没有太大的差距,差就差在“做过一次”的经验。

听别人讲述自己的经历,也是积攒经验的一种好方法。我们曾邀请快狗打车高级经理胡显波讲述他的职业生涯,他讲述了快狗打车的派单系统从 0 到智能化的演进。

下面是整理的文字版,希望您看了能有所启发。

石器时代

单一拆分数据库、业务解耦

由于快狗打车是 58 同城当时孵化的 N 个业务线之一,并且短短三周就已上线,最初的版本包含了用户侧 App、商家 App、管理后台三个模块。

上图所示的是业务孵化期整体系统架构,采用的是的单一数据库模式,与其他业务公用数据库,节省成本,这样做是为了快速验证市场对业务接受度。

上图所示是业务孵化期的派单系统,可以理解为一个单元运作。系统核心部分是 OrderPushJar,订单创建、推送等派单逻辑都在这里进行处理。

这个阶段订单调度原理很简单,就是由推送框架 MQTT,把订单推送给设定范围内所有司机,司机凭手速接单,单单都有补贴旨在快速抢占市场,这对平台而言是庞大的浪费。

快狗打车上线之后,市场反响非常好,业务也在短短三个月增长了一万单。但此时数据库达到瓶颈,字段冗余、数据库索引有效性等问题凸显,没办法支持多业务的发展,某个子业务做上线下线等操作时,“同源”业务也会受到影响。

上图是针对数据库瓶颈的解决方案,把快狗打车的数据库,从耦合的业务数据库中拆分出来。方案中采用双向同步模式来业务不停服的情况下进行数据迁移。

整体迁移后,快狗打车整体系统大致分成订单、结算、配置、轨迹等模块,每一个模块都有对应单独数据库,这样就很好的避免了业务之间的耦合,轨迹服务数据库出现异常,并不会影响其他业务流程。

铁器时代

双推送通道、象限推送

2015 年,快狗打车进入高速发展阶段,市面上也出现了很多同类竞品,如蓝犀牛、1 号货的及云鸟等。市场争夺战进入白热化阶段,快狗打车采用大量订单补贴的方式来提升市场占有率,产品方面也是争分夺秒的进行迭代,抢占市场先机。

上图是业务高速发展时期的系统架构。App、PC 及其他第三方渠道进入到 OrderCenterServer(订单中心),OrderCenterServer 会根据具体职责进入业务的模块化,分成了像结算、支付、推送、司机任务等模块。

为保证订单能够尽快被司机接收到以及保证消息推送到达率,快狗打车采用自研 TCP 通道与 GeTui 和 MiPush 等三方通道相结合。根据司机的手机品牌择优选择 GeTui 或 MiPush 通道,加上自研的 TCP 通道,保证消息的到达率。

这个阶段订单调度原是按照不同的象限方式进行予以推送,订单产生时会先在附近 X 公里范围之内,寻找满足该需求的司机,进行推单。如果无人抢单便加部分补贴,激发司机的抢单意愿。

如上图所示,会采用象限推送的模式,如果没人抢单,就增加部分补贴,延象限进行推送,如果抢单人数达到一定上限,就回降低部分补贴。

在指派司机的环节,根据抢单司机的距离、好评率、历史订单完成率等核心评估指标进行择优指派,这种简单的方法既减少了平台派发无效补贴的浪费,又有效避免了凭速度抢单的恶意竞争,进而提升了整个平台的订单完成率。

智能时代

大数据平台引入到智能化

2016 年,快狗打车成为行业佼佼者,进入了平稳期,这时更多考虑的是平台补贴如何高效,起到真正补贴的作用、如何尽量满足用户的需求、如何分配司机的收益。

进而效率提升成为这一年的整体目标,主要做了引入大数据平台、智能派单算法和智能分流框架等内容。

第一步:数据收集

如上图,App 用户使用数据、H5 端日志操作,Server 端用户请求日志等数据进行收集并通过日志中心组进行上报,汇集到日志中心,利用 Flume 和 Kafka 同步到大数据平台。DB 则是通过 DTS 和 Canal 形式,也引入到大数据平台。

第二步:智能模型训练

如上图,是智能模型的训练逻辑。最底层是收集信息:

  • 订单的信息,包括:始发地、目的地、以及价格。
  • 用户的信息,包括:用户位置、以及对于价格的敏感度。
  • 司机的信息,包括:接单的意愿等。
  • 客户和司机的关系信息,包括:两者能够相匹配的标准。
  • 整体订单的推送和接单场景等信息。

凭借着归一化&分桶、XGBoost、特征组合、编码等大数据手段,进行模型训练,目前拥有约 80 万的数据模型用于整体的业务流程。

接下来,通过具体场景来诠释大数据的智能化派单系统的应用,涉及主要场景有计价、推单、中单等。

场景一:计价

先分享计价场景,是因为无论是打车用户还是司机,对于价格都是很敏感的。

具体说来:用户先上来询价,根据询价信息给予用户一定的优惠 A 元,同时也要据此来补贴司机 B 元,另外,在定价 C 元的基础上,快狗打车还要通过一定的抽佣 D 元,来保证平台的运营。

那么该如何计算 ABCD 之间的关系呢?显然,在保证整体抢单率的情况下,应使得 A 和 B 尽可能的小。

也就是说,在尽量降低平台补贴的前提下,根据给定补贴的预算情况,来提高抢单率。

根据上述两个计价模型,不难发现:为了保证订单的完成率,至少要保证两个司机的抢单:通过对司机和用户的行为分析,要掌握司机对于订单大致的接受价位;同时,也会通过整体的接单司机数量,来反过来验证该模型的有效性。

上述优惠模型是分析用户流失率的手段。根据用户每天的活跃度,订单价值贡献等,能够获悉:可能由于某些原因,用户存在流失的风险,就应该通过平台发券的方式将他刺激用户的回流。

场景二:推单

上图是一个接单的场景。把订单推送给愿意接单的司机,既能降低用户的等待时间、提升用户的满意度,又能通过订单的成单率,来提升司机的兴趣度。

那么司机的接单意愿又是从何而来呢?其中包括:订单与司机之间的距离、订单的价格、小费&补贴、以及起点&终点等方面。

平台通过大规模的逻辑回归,可以计算出附近司机的接单意愿,进而推送给相应的司机。

场景三:中单

在中单场景中,如果有 50 位司机抢单,那么哪位司机的好评率、距离、服务态度、以及是否愿意免费搬运等策略最为切合,谁就能够“中签”。

此处的服务模型相对较为简单,主要涉及到距离、等级、评分、耦合度等指标。

为了防止一些假司机来扰乱平台秩序,快狗打车通过:设备交叉、订单轨迹、客司金额分配、以及虚拟识别等手段,来识别订单中的作弊概率。如果发现有作弊的订单,平台会对用户和司机予以惩罚。

场景四:整体运营

如上图,是整体运用场景。

  • 在用户下单时,快狗打车运用订单的定价模型,来确定用户是否需要调价、优惠、或是补贴。
  • 在系统推送时,快狗打车预测司机的接单意愿,以及推送的顺序。
  • 在司机抢单时,快狗打车预测整体的接单人数,一旦人数到达上限,就会通过降低订单补贴等方式进行动态微调。
  • 在订单指派时,快狗打车也会预测司机的完成概率,并获取司机的质量度。
  • 在订单完成后,快狗打车会预测用户是否流失,并根据其留存价值,来确定是否给他更多的优惠。

上图展示的是整体派单侧的架构。核心在于策略应用服务侧、通用逻辑服务层,以及底层数据服务侧的划分。

上图展示的是智能派单的核心流程。左侧的核心模块是特征数据,它经由数据的收集与训练,得到相应的特征数据值。通过特征匹配系统,将数据应用到整体的业务系统中。同时这里的订单队列引擎和司机队列引擎,根据订单状态的实时变化,将订单推送给司机。

另外,通过业务监督平台,来保证新的模型、或算法在上线时得到相应的分流与监测。具体而言,根据用户的设备特点,来模拟流量的分配,进而实时地得到数据上报。

例如:用户是否仅在询价阶段完成后就流失了。倘若流失率较高的话,就会通过实时报告将线上新的分流设置关闭掉。

接下来分享快狗打车的的监控平台,具体的定义如下三点:

  • 算法需要稳定的系统支撑
  • 业务的波动要第一时间知悉
  • 提高问题排查效率就是在挽回损失

如上图,是快狗打车侧立体化监控部分截屏,涉及关键字监控、接口监控、流量,端口、JVM、CPU,线程、缓存、DB 等监控。

业务指标监控包含订单整体波动以及补贴整体波动等。订单波动就是对附近平均司机数量,推单波动进行监控。补贴波动就是对用户和司机的补贴实时投放的数据进行监控。这些核心业务指标监控需要做到实时反馈,有波动第一时间告警。

如果优惠券订单数为什么突然间在暴涨?补贴订单数为什么突然之间下降?等等这些核心业务指标监控需要做到实时反馈。

总结

2014 年至今,一路走来快狗打车团队不断壮大,业务也是不断地迭代和优化,最后总结如下几点:

  • 架构与团队、业务对齐,保持服务的持续演进,以响应业务的快速变化
  • 建议使用双推送通道,保证推送的到达率
  • 监控很重要,第一时间发现问题,减少影响
  • 持续提升,团队的能力,要跟得上业务的节奏
推荐 打印 | 录入:admin | 阅读:
本文评论   
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款
-->