送外卖也要“黑科技”?阿里移动感知技术应用揭秘

一 背景

作为本地生活的一个重要组成部分,外卖已经进入千千万万的家庭。相信很多小伙伴已经注意到,饿了么的每一个订单,我们都会及时向用户通知这一单现在所处的状态,比如“商户接单”,“骑手到店”,“骑手送达”等。这个实时状态的更新,不仅能让用户及时了解自己外卖到了哪里,对于整个平台的骑手调度和时间预估都有着重要意义。

而在所有的节点中,骑手到店前后的两个节点“骑手到店”和“骑手取餐”对于整个平台的价值就更为重要,主要体现在以下三个方面:

时间预估

骑手到店的时间是骑手从接单位置到商户位置的终止时间,而骑手离店的时间则是骑手从商户位置到用户位置的起始时间。掌握这些准确的时间,能给时间预估模型提供准确的标签用于模型训练。我们在APP里看到的“预估配送时间”就是这样计算出来的。同时,知道骑手在商户位置等了多长时间,我们就可以知道商户准备这一单需要多长时间,也就是商户的“出餐时间”。而掌握了准确的出餐时间,我们在给某一单找合适骑手的时候就能更加地游刃有余了。

骑手调度

当用户在外卖平台下单后,平台就会开始为这一单寻找合适的骑手来配送,这个过程就叫骑手调度。骑手调度是一个复杂的过程,需要考虑同时考虑商户,骑手和用户的位置,还要考虑骑手身上已有的单和商户正在准备的单。一个总的原则是,让更近的,更顺路的骑手去取单。如果我们知道了骑手到店的准确时间,我们就可以知道骑手在当前时刻的具体位置,并且能够预估出骑手在未来一段时间的大概位置。这就给我们的骑手调度提供了准确可靠的数据源。

超时单判责

虽然调度系统会尽力保证每一单都尽快送达,但还是会有一些情况导致少部分运单会超时,给用户带来不好的体验。为了提升调度系统的性能,减少超时单。我们首先需要知道超时的原因,从而在未来的调度中作出改进。超时的两个主要原因是“商户已出餐但骑手未到店”和“骑手已到店但商户未出餐”。在没有明确数据的情况下,这两个对立的原因往往会出现“公说公有理,婆说婆有理”的情况。如果我们能够准确获得骑手到店的时间,这一困境就会迎刃而解。

二 挑战

既然获取准确的骑手到店时间是如此重要的问题,为什么现有的方法还是无法很好的解决这个问题呢?这是因为考虑到本地生活的场景,要获得准确的骑手到店时间,面临着以下几方面的挑战:

GPS在室内的漂移

现在手机定位最常用的方法就是GPS定位。但无论是GPS,还是我们最近刚组网成功的北斗系统,其本质上都需要手机里的芯片来接收地球上方的卫星信号。但商户的位置往往是在室内,当我们在室内环境时,GPS信号会受到建筑物的遮挡,导致GPS信号微弱甚至完全失去信号。这个时候GPS的精确度就会从几米扩大到几百米甚至几公里,导致GPS信号出现漂移。因为这一漂移现象的存在,我们需要划定一个范围来判断骑手是否到达了商户。当我们用一个较小的范围时,可能会出现“骑手已到店但我们认为没到”,如果我们用一个较大的范围,那么骑手到店时间的准确性则会大打折扣。

商户在不同楼层的垂直分布

在GPS漂移之外,商户在不同楼层的垂直分布也会给骑手到店的准确判定带来困难。当商户分布在不同楼层时,即使我们通过GPS判断出骑手已经在水平方向上到达商户附近,但由于没有垂直方向的信息,我们仍然无法准确判断出骑手到店的具体时间。如今越来越多的商户都分布在商场的不同楼层,这部分订单的骑手到店时间就很难观测。虽然GPS会返回一个海拔信息,但在实际的应用中我们发现这个值往往是不够准确的。

商户环境的动态性和骑手手机的多样性

一些室内定位的方法通过收集特定环境的声音指纹,光指纹或者磁场强度指纹来建立指纹库,然后通过指纹对比来判断手机所处的位置。理论上如果我们能够采集商户环境的指纹,并和骑手手机收到的信号进行比对,就可以判断骑手是否已经到达商户。但由于商户环境的动态性,比如装修改造和人来人往带来的实时扰动,我们很难建立一个稳定的指纹库来进行比对。同时,由于声光磁的指纹收集受到手机硬件的影响,骑手手机的多样性也对指纹库的建立带来很大挑战。

基于Wi-Fi的方法的局限性

随着越来越多的室内环境有Wi-Fi信号的覆盖,基于Wi-Fi信号的室内定位也得到了充分研究。但基于Wi-Fi方法也有两个局限性:一是持续的Wi-Fi扫描会带来极大的能耗负担,这对于工作极度依赖手机的骑手很不友好;二是出于隐私保护等原因,iOS系统只支持获取当前连接的Wi-Fi信息,而不支持获取Wi-Fi扫描的列表,但骑手在取餐过程中很少连接商户的Wi-Fi。这两个原因导致了基于Wi-Fi的定位方法无法适用于骑手到店的场景。

三 解决方案

当我们把骑手到店观测问题抽象出来,可以发现这是移动感知(Mobile Sensing)领域经典的“室内定位(Indoor Localization)”或者“存在监测(Presence Detection)”的问题。移动感知是指利用移动设备上的网络信号或声光电磁等传感器信号对用户的位置,行为,场景等进行感知的技术。手机上的计步功能,以及智能手表提供的心率监测和睡眠监测等功能,都是移动感知技术在生活中的具体应用。近些年来,随着移动设备的升级,研究者们也在探索移动感知的新应用,比如用Wi-Fi信号感知键盘敲击和老人摔倒,用手机话筒来检测醉驾,用新的传感器来感知用户的情绪和压力状态等。

这些研究也给我们的到店观测问题提供了很多思路,比如基于Wi-Fi的室内定位,基于特定光信号和声信号的定位方法等。但是通过上面的讨论我们可以看出,这些方法都难以很好地解决骑手到店观测问题。针对这一情况,我们设计并部署了aBeacon系统,一个基于蓝牙信号的移动感知系统,来解决骑手到店观测的问题。其实基于蓝牙的移动感知并不是一个全新的技术,苹果公司在2013年提出基于蓝牙的iBeacon协议用于移动感知[1],2016年蓝牙5.0中的新特征(更低功耗,更大范围)真正让蓝牙感知技术得以落地。蓝牙移动感知的原理就是通过在特定位置部署一些持续发送蓝牙信号的Beacon设备,同时手机进行持续的扫描来感知周围的蓝牙Beacon信号,从而来判断手机是否到达了特定位置。

基于这样的感知技术,我们建立了aBeacon系统,如图1所示,系统由三部分组成:部署在商户的蓝牙Beacon硬件、骑手APP内的蓝牙监听模块和平台服务器上的后端模块。在骑手配送过程中,APP上的蓝牙监听模块会持续监听周围的蓝牙Beacon信号,当骑手到达商户附近(比如10米范围内)时,手机会监听到该商户内的蓝牙Beacon信号,并把该数据和当前时间戳上传到服务器,服务器通过和预置的Beacon地图进行比对,就可以得到该骑手到达该商户的准确时间。在Beacon硬件方面,我们采用了自主定制的硬件,在降低成本的同时保证了蓝牙广播的质量,同时引入了加密技术来保护商户的位置隐私。在手机监听模块方面,我们通过设计一个动态监听模块,在保证到店判断能力的前提下降低了能耗。

对比前面提到的几个挑战,我们可以发现,因为蓝牙信号自身的特性,Beacon信号在室内环境的传播仅限于几米到几十米的范围(相信大家使用蓝牙耳机和鼠标都有类似的感受),因此基于蓝牙的到店判断不会出现GPS那样几百米的误差,可以极大提高骑手到店观测的准确性。同时,因为蓝牙信号的穿墙能力较差,因此只有当骑手到达商户所在的楼层时才会接收到蓝牙信号,这样就避免了商户楼层带来的影响。此外,我们通过标准化的部署流程,使得Beacon硬件部署在商户的骑手取餐处的上方,避免了商户内动态环境的改变对信号的影响。蓝牙协议的标准化和手机硬件的成熟化也降低了骑手手机硬件对到店观测的影响。此外,因为蓝牙监听属于非连接通信,骑手使用蓝牙耳机的功能也不会受到影响。最后,和Wi-Fi相比,蓝牙监听的功耗也很低,我们的实验证明,Beacon监听每天只会给骑手手机带来3%的额外功耗负担。

总体来说,aBeacon系统的主要贡献在于将蓝牙感知的技术真正应用到骑手到店观测的问题中,并解决了一系列实际应用中的挑战,比如能耗,可靠性,隐私保护等,并且从理论层面上对系统的成本和效用进行分析,从而指导今后大规模感知系统的落地。

在系统的设计中,我们考虑了下面的一些指标:

成本

成本是我们上线一个商业化的系统所必须考虑的因素之一。aBeacon系统的成本包括两部分:aBeacon设备的硬件成本,和大规模部署的成本。在硬件成本方面,我们通过对硬件的定制来降低成本。在部署成本方面,我们通过简化硬件部署的流程,从而在业务经理的帮助下降低部署成本。

寿命

出于易用性的考虑,我们的aBeacon硬件采用了电池供电的方式。这样电池的容量就成为了限制系统寿命的主要因素。但在两年的运行之后,我们发现除了电池的寿命,环境变化也是影响系统寿命的重要因素。

可靠性

可靠性是指在所有的骑手到店行为中,有多大比例可以被aBeacon系统观测到。在实际中,可靠性受到包括部署质量,商户环境,骑手手机等诸多因素的影响。

效用

骑手到店观测给整个系统提供了更准确的数据,它带来的效用是基础但难以直接衡量的,因此我们采用超时率这一衡量整个调度系统的指标来评估aBeacon的效用。

在系统的设计过程中,我们首先量化了上面的四个指标,然后建立这四个指标和我们要优化的终极目标——aBeacon带来的累积收益——之间的量化关系。因此,我们可以在这个量化关系的指导下对各个因素进行权衡。

在这样的设计思路的指导下,aBeacon系统的部署和运行主要包含了两个主要环节:

设计与测试

基于成本和设计自由度的考虑,我们选择自主定制aBeacon设备,同时自主定制还能让我们嵌入隐私保护等其他功能。在大规模的部署前,我们挑选了几个商场进行小规模的测试。在测试中,我们将自主定制的aBeacon设备和另一种商用的Beacon设备同时部署在商户里。通过对比测试,我们发现采用自主定制的aBeacon设备可以在压缩成本的同时达到和商用Beacon设备同样的可靠性。

部署与运行

在小规模测试后,从2018年1月开始,如图2所示,我们在上海的12000余家商户里部署了aBeacon设备。我们用一份包含“部署在哪里”、“怎么固定”、“如何绑定”等问题的部署手册来指导业务经理进行部署。在运行过程中,我们通过后台收集的数据,可以对所有设备进行实时监控,所有设备被分类为“健康”、“部署错误”、“下线”等状态。我们针对不同的设备还可以采取不同的维护措施,比如针对“部署错误”的设备进行重新部署。

另一个很重要的问题是系统安全和隐私保护,这也是我们在aBeacon设备的定制过程中作出的重要改进之一。因为传统的iBeacon协议是固定ID的明文广播,可能导致系统的安全性漏洞。比如:

  • 未授权的用户可能通过战争驾驶(wardriving)[2] 的方法来反推出Beacon设备的位置,并用于其他目的。
  • 恶意攻击者可能通过在异地复制已有Beacon设备的蓝牙广播,向系统中注入错误的位置数据。

针对这一问题,我们在自主定制的设备中对蓝牙广播进行加密,通过一种TOTP[3]的加密算法,让所有aBeacon设备广播的ID内容定时进行变更,而ID和设备位置的映射关系存在只有授权用户可以访问服务器。这样极大地提高了系统的安全性。

四 效果

为了评估aBeacon系统给整个配送过程带来的效果,我们采用了“超时率”这一总体指标作为指标。我们用上海未部署aBeacon设备的一万多家商户作为参照,来评估部署了aBeacon设备的商户在部署前后超时率的变化。通过对比我们发现,在总体上,通过一年的运行,aBeacon系统可以将超时率降低0.24%,这使得我们每年可以减少超过7余万超时配送订单。

同时我们还发现,aBeacon系统在不同楼层和不同的地区体现出较大的差异性。如图3所示,部署在B2层和4/5层的设备可以带来更大的效用,这其实也印证了我们前面的分析,骑手在这些楼层商户的准确到店时间更难观测,通过部署aBeacon设备,我们可以在这些商户取得更大的效用。

迄今为止,aBeacon系统为上海超过10万骑手提供准确的到店观测分析,通过不断优化骑手配送流程,每年可减少超过7余万超时配送订单,为超过700万的用户人群提供更优质服务。

五 讨论与发现

作为一篇介绍移动感知技术大规模应用的文章,我们在系统设计和部署过程中的发现希望能给后来者的工作带来更多启发。总的来说,我们的发现包括以下两个方面:

(1) 系统可靠性。在移动感知领域,研究者们为我们带来了很多新的想法。但这些想法在实际落地的过程中都会遇到可靠性的问题,我们用aBeacon系统的部署过程说明了,即使是用蓝牙信号进行存在感知这样一个简单的应用,系统的可靠性也会受到硬件设备的部署和用户手机硬件等诸多因素的影响。因此在以后的研究中,我们需要在系统设计的过程中更多地考虑这些因素,让系统就有更强的鲁棒性。

(2) aBeacon系统的局限之一就是我们还需要部署和维护硬件设备,在后来的工作中,我们仍在探索采用已有的终端设备作为虚拟的aBeacon设备用以辅助骑手的定位。基于此,我们正在开展aBeacon+系统的研究工作,解决一些相关的问题,比如终端设备自身定位,以及隐私保护等。

六 总结

基于aBeacon系统,阿里本地生活科技中心的论文“From Conception to Retirement : a Lifetime Story of a 3-Year-Old Operational Wireless Beacon System in the Wild” 被计算机网络系统领域的顶级会议NSDI’21收录。作为首篇基于本地生活场景的系统论文,这也代表了阿里本地生活科技中心在移动感知方面的工作得到了来自网络系统领域顶级会议的认可。在落地应用后,通过获取更准确的骑手到店和离店时间,该系统为全国超过10万骑手提供准确的到店观测分析,通过不断优化骑手配送流程,每年可减少超过7余万超时配送订单,为超过700万的用户人群提供优质服务。未来,在阿里巴巴本地生活和新零售的业务布局下,我们还会持续加强相关领域的研究,将更多前沿技术投入到更多场景的运营分析中,发挥出更多作用,用技术服务用户。

参考文献:

[1] Apple Inc. iBeacon. https://developer.apple.com/ibeacon/ , 2020 [2] Wikipedia, Wardriving, https://en.wikipedia.org/wiki/Wardriving, 2020 [3] Wikipedia. Time-based one-time password, https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm , 2020........

原文链接

本文为阿里云原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/510726.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

视频需求超平常数 10 倍,却节省了 60% 的 IT 成本投入是一种什么样的体验?

近年来,Serverless 一直在高速发展,并呈现出越来越大的影响力。主流的云服务商也在不断地丰富云产品体系,提供更好的开发工具,更高效的应用交付流水线,更好的可观测性,更细腻的产品间集成,但一切…

打好“三场仗”,数据库新晋厂商石原子胜券在握

纵观数字经济时代,数据规模呈爆发式增长,国产化替代加速发展。据中国信通院《数据库发展研究报告(2021年)》预测,预计到2025年,全球数据库市场规模将达到798亿美元,其中,中国数据库市场总规模将达到688亿元…

基于信通院 Serverless 工具链模型的实践:Serverless Devs

前言 2022 年 6 月 15 日,信通院在中国信通院云原生产业大会上发布《基于无服务器架构的工具链能力要求》标准,至此全球首个云原生 Serverless 开放工具链模型正式发布!Serverless Devs [1]作为开源开放的开发者工具积极参与工具链模型建设&…

Serverless 架构落地实践及案例解析

互联网软件架构演进 我们先简单回顾下互联网软件架构的演进之路。 单机部署 在单机部署中,将所有的业务和数据库都部署在一台主机中。 此架构的优点是:开发、部署以及运维都非常简单。缺点是:一旦遇到流量过大或者机器故障,整个…

十年 Python 程序员,初次尝试 Rust:“非常优秀!”

摘要:Python 和 Rust,都是近几年深受开发者喜爱的编程语言,那么作为一个拥有十年 Python 编程经验的开发者来说,初次尝试 Rust 会有怎样的感受呢?链接:https://karimjedda.com/carefully-exploring-rust/声…

让阿根廷队“告吹”的三个球背后,2022 年世界杯暗藏哪些技术玄机?

整理 | 苏宓出品 | CSDN(ID:CSDNnews)「足球反着买,别墅靠大海」,昨晚 2022 年卡塔尔世界杯的一场小组赛上,最有看头的阿根廷球队出现惊天冷门,以 1:2 败北沙特阿拉伯队,为此&#x…

科学地花钱:基于端智能的在线红包分配方案

一、前言 本文是作者在1688进行新人红包发放的技术方案总结,基于该技术方案的论文《Spending Money Wisely: Online Electronic Coupon Allocation based on Real-Time User Intent Detection》已经被CIKM2020接收,欢迎交流指正! 关于作者 …

为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(上)

前言 随着现代化应用的普及和企业上云的深入,项目中会涉及越来越多的云资源使用。企业上云过程中,往往会有平台(Platform)团队和基础设施(Infra)团队:平台团队关注业务,根据业务场景…

达摩院打破权威榜单纪录,中文语言理解表现首超人类

11月25日消息,在最新的中文语言理解领域权威榜单CLUE中,阿里AI以86.685的总分成绩创造了新纪录,这是该榜单诞生近三年以来,AI首次超越人类成绩(86.678),意味着AI模型的中文语言理解水平达到了新…

阿里云云原生一体化数仓 — 离线实时一体化新能力解读

实时离线一体化概述 在讲实时离线一体化概述前,可以先回顾一下之前两位阿里同学的精彩演讲。 离线实时一体化数仓与湖仓一体--云原生大数据平台的持续演讲 https://developer.aliyun.com/article/804337 云原生离线实时一体化数仓建设与实践: https:/…

50 万开发者不愿付费使用,Python 代码补全神器 Kite 失败!

作者 | 苏宓出品 | CSDN(ID:CSDNnews)AI 编程距离程序员还有多远?如果说 GitHub Copilot 的到来,让众多开发者看到了希望,那么初创公司 Kite 的倒闭,也让我们认清了现实。Kite 是一家使用 AI 帮…

模拟 IDC spark 读写 MaxCompute 实践

一、背景 1、背景信息 现有湖仓一体架构是以 MaxCompute 为中心读写 Hadoop 集群数据,有些线下 IDC 场景,客户不愿意对公网暴露集群内部信息,需要从 Hadoop 集群发起访问云上的数据。本文以 EMR (云上 Hadoop)方式模…

基因检测,如何帮助患者对抗疾病?

为什么别人胡吃海塞都依然瘦成竹竿,我喝水都会胖? 为什么我这么不幸,疾病会找上我?早知道就不乱喝酒。 为什么是同一种病,别人吃这个药有用,我吃却没用? 从日常的健康管理、疾病预防&#xf…

“小语言”才是编程的未来!

摘要:随着软件功能不断增加,代码数量也日益膨胀,我们要如何停止不断堆砌,甚至缩小软件体积?本文作者提出了一种可能性:“小语言”。链接:https://chreke.com/little-languages.html声明&#xf…

夯实密码基础服务,服务上层应用

“十四五”是国家数字化战略转型建设的关键阶段,5G、人工智能、云计算、大数据等新一代信息技术进一步加快了工业和信息化领域数字化转型的步伐。与此同时,也带来了新的网络安全风险。加快推动商用密码与新一代信息技术的深度融合和协同创新,…

储留香:数据迁移上云避坑指南

简介: 常言道:人往高处走,水往四面八方流,而让数据如水一般流动则是IT人孜孜以求的。那么在如今这个风起“云”涌,不管是上云,还是换云都涉及到数据迁移的时代,如何做到这一点呢?今天…

为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(下)

在上篇中,主要介绍了 Serverless Devs 多环境功能的使用,用户读完可能会些疑问,本文会就一些常见问题进行下回答。 1、Serverless Devs 和 Terraform 的关系 可能有些用户会问,既然你们已经支持了 Terraform,那 Serv…

这个简单的小功能,半年为我们产研团队省下213个小时

大多数人对产研同学的认知都是每天做着高大上的活儿。 我们以为的产研团队是: 研发负责人:今年最新的技术架构是什么、我的团队适合吗?开发同学:010001,一顿代码猛如虎测试同学:OK,测试一次性…

腾讯云开源项目Crane成FinOps首个认证降本增效开源方案

刚刚,腾讯云开源项目 Crane(Cloud Resource Analytics and Economics)正式成为FinOps认证解决方案(FinOps Certified Solutions)。作为全球范围内首个开源的FinOps认证解决方案,Crane能够助力云原生用户充分发挥云上资源的最大价值…

JDBC 在性能测试中的应用

前言 我们能否绕开 http 协议,直接测试数据库的性能?是否觉得从数据库中导出 CSV 文件来构造压测数据很麻烦?怎样在压测结束后做数据清理?能不能通过数据库中的插入(删除)记录对压测请求做断言&#xff1f…