Lbs

作者：京东批发 郑书剑 1、举荐LBS业务介绍1.1 业务场景现有的同城购业务围绕京东即时批发能力搭建了到店、到家两种业务场景。同城业务与现有业务进行互补，利用高频，时效性快的特点，能够无效晋升主站复访复购频次，是批发的重要策略方向。 1.2 名词解释LBS：基于地位的服务（Location Based Services）。 下文LBS商品代指京东小时购商品；LBS举荐代指京东基于地理位置的举荐能力，须要思考到左近的供应和履约能力。 B2C：间接面向消费者销售产品和服务商业的批发模式。 下文B2C商品代指京东主站商品，包含自营/pop等非小时购商品；B2C举荐指主站支流举荐能力，不须要思考以后地理位置的供应，而是面向全国用户的举荐模式。 1.3 举荐模式次要举荐模式集中在一下四种流量场域： 1、左近-商品推feeds举荐； 2、左近-纯门店举荐； 3、左近-门店-商品列表页举荐； 4、主站外围举荐场景lbs商品混排举荐（首页为你举荐、购物车、我的京东等）； 左近-商品推feeds左近-纯门店左近-门店-商品列表页首页为你举荐2、举荐零碎设计目前主站外围场景从反对b2c商品举荐，b2c内容素材/聚合素材举荐拓展到更丰盛的业务模式，反对lbs业务逻辑举荐，给用户带来更多元化的体验，同时给线下商家和经营提供了更丰盛的流量浸透策略。 目前lbs商品举荐架构和b2c商品举荐架构的举荐流程严密的耦合在一起，上线lbs商品举荐相干策略，都须要思考到b2c举荐业务的逻辑无diff，效率低，兼容性差，迭代老本高，不利于后续优化策略的疾速迭代。通过对lbs商品举荐的整体链路进行降级，与目前的b2c商品举荐链路进行解耦，晋升零碎的拓展性，更易保护，进步算法策略接入的效率。b2c商品和lbs商品均具备独立quota空间，举荐链路更加清晰，成果优化空间更大。 3、算法实际3.1 概述咱们的前端展示状态分为纯商品、纯门店、门店-商品三种状态，且举荐位散布较多，为了缩小人力保护老本，同时思考到LBS举荐模式和传统电商模式的差别，以及流量场域散布和举荐展现状态的区别，咱们针对LBS举荐能力进行了独自的设计，形象出一套举荐模板能够同时解决三种举荐模式，反对跨场景复用。 首先前端申请入参用户以后的经纬度信息，举荐零碎从gis零碎获取以后可履约的门店信息；举荐零碎依据用户个性化信息和门店-商品信息，为用户举荐感兴趣的左近门店-商品。 此时的item粒度为门店+商品粒度，为了同时保障用户对门店和商品趣味的同时感知，区别于b2c商品的举荐模式，咱们将整个零碎分为两个阶段。在一阶段对用户感兴趣的门店进行举荐，在二阶段对用户的感兴趣的门店下的商品进行举荐。在两个阶段内实现门店举荐、商品举荐、门店-商品举荐三种模式，三种举荐模式可复用算子达到80+%，笼罩站点从京东主站到小程序，笼罩场景从首页-为你举荐到营销举荐位，总计笼罩外围举荐位30+。 3.2 LBS召回算法实际3.2.1 背景概述背景：LBS举荐是基于地理位置的举荐场景，和主站b2c举荐模式有所差别；用户对更多维度的因素敏感，如门店品质，配送间隔，配送时效等等； 所以举荐零碎须要在召回的时候就思考到这些体验因素，所以咱们将LBS的召回算法设计成两阶段的模式。一阶段依据用户趣味（user-store趣味）和门店品质（ka/销量/间隔/时效）等因素召回用户感兴趣的高质量/间隔近/配送快的门店。在二阶段进行商品召回用于召回用户感兴趣的商品。 同时咱们面临着以下几个问题： 冷启问题：咱们是新业务+新场景，新品多，新用户多，相比拟成熟的b2c场景，lbs场景交互稠密问题重大； 跨场域趣味迁徙：用户在b2c场景和lbs场景的趣味表白往往是不一样的，不同场景的趣味表白往往存在着肯定的差别和分割，怎么精准捕获和表白用户跨场景体现出的趣味是新场景初期倒退的重要工作； 趣味激发周期短：lbs场景用户决策成本低，转化链路短，高转化场景下更要关注物品相干关系的表白； 咱们初期也对以上几个问题进行了简略的摸索，通过跨域趣味摸索和优化i2i关联关系简略的验证了咱们的想法。 3.2.2 召回算法实际1、冷启动召回冷启动召回个别有以下几种计划： •商圈热门：毛病是和user无关，纯热门item召回，相关性差；这里咱们将全局热销/poi热销商品作为兜底召回，用于补充； •cross domain：是一种基于不同场域（如京东b2c场景/lbs场景）独特用户的行为将不同域的用户映射到同一个向量空间，而后借助其余域的丰盛行为晋升本域冷启动用户的召回成果。 咱们这里次要针对cross domain的形式进行了一些简略摸索来优化跨场域用户的冷启体验成果。 1）潜客画像召回：依据用户在b2c场景的相干行为（诸如偏好类目是否为lbs转化劣势类目）以及是否对lbs相干场景有前置行为的用户（举荐下浏览过左近/搜寻内点击过小时购通栏等），来判断以后用户是否为lbs的潜在转化用户，给这些用户举荐其在b2c偏好下的高转化lbs商品； 2）跨域类目召回：通过对b2c/lbs共现商品进行开掘，失去b2c到lbs的类目协同关系，依据用户在b2c场景下的偏好类目举荐对应的lbs类目下的商品； 3）跨域i2i召回：联合b2c/lbs的用户的跨场域行为，对lbs商品和b2c商品进行i2i关系开掘，失去b2c sku到lbs sku的类似相干关系，应用b2c的用户行为为其举荐lbs商品； 4）间接召回：基于b2c召回后果，为用户召回类似相干的lbs商品。 2、i2i间接召回基于用户在lbs场景的行为间接召回lbs商品，常见办法有如itemCF，swingCF等。 咱们针对lbs场景高转化的特点对i2i召回进行了针对性的优化。咱们对lbs场景的用户行为进行了剖析，发现用户的点击行为体现了商品的相似性（同品比拟等），订单行为体现了商品之间的相干关系（搭配购等），然而用户的订单行为往往十分稠密，且思考到lbs商品还含有地区属性，间接应用订单行为构建相干的i2i关系失去的后果十分稠密，召回的下发占比往往比拟低。 于是咱们把订单的i2i关系形象为类目-类目，产品词-产品词的的粗粒度相干关系。而后对全站lbs行为进行i2i关系开掘，失去的后果应用粗粒度相干关系进行过滤，失去了比间接应用定订单行为构建i2i关系更丰盛的后果，召回效率也比类似关系的效率更高。 3、向量化召回i2i vs embed：i2i的类似相干关系体现的更加精准，然而覆盖率低；embed形式新颖性好，覆盖率高，然而关系表白绝对不这么精准。 为了解决前文中提到的问题，对用户行为进行预处理，对异样用户和异样体现的商品先进行过滤，避免脏数据对整体数据分布造成影响，行为选取时，优先保留订单行为左近的用户行为（高质量行为），同时历史行为序列进行了session划分，保障行为的连续性和相关性，更能体现出用户决策周期内的集中趣味，优化i-i的关联关系。 模型方面咱们采纳了随机游走的graph embedding建模形式，和传统计划差别不大：行为序列开掘 -> 同构图构建 -> 带权重游走序列采样 -> skip-gram+负采样训练，失去物品的item embedding。 同时这里的用户行为序列的选取也能够参考跨域的思路，应用b2c行为进行补充，进一步解决lbs场域召回稠密的问题。线上即能够应用i2i的形式进行召回，也能够应用u2i的形式进行召回。相比i2i间接召回，曝光占比更高，效率更高。 4、其余召回通道还有诸如其余的依据品类趣味和常购行为的趣味画像召回，复购、常购召回等。 3.3 排序模型实际排序筹备方面，因为历史遗留起因，目前无论是用户在lbs场域的行为，还是lbs商品画像都有所缺失。于是第一步，咱们首先对根底数据进行了保护：1）对立了全站lbs行为接入口径：通过门店pv和商详的pv埋点，捕获全站lbs行为；2）建设了user-sku和user-store的用户画像和lbs商品画像。 排序特色方面：在复用了b2c商品的局部精排特色的根底上，构建了lbs场景的特有特色，如lbs场景用户行为序列，lbs场景商品/门店反馈特色，以及配送时效，配送费，配送间隔等context类特色。 模型优化方面：引入了用户在b2c场景的用户行为，同时引入了b2c训练样本做样本加强。 ...

春节的脚步越来越近，又迎来一年的春运返乡顶峰，小伙伴们是不是等不及要回家过大年？是不是还在忙着搜寻各种攻略，钻研如何避开春运顶峰，让回家的路更顺畅一些呢？ 腾讯智慧交通、腾讯地图、腾讯研究院、腾讯位置服务、腾讯主动驾驶联结广东省公安厅交通管理局，基于腾讯交通数字底座外围能力，针对脱敏后的交通出行、位置服务大数据进行多维时空剖析计算，公布《2022年广东省春运交通预测报告》（以下称《预测报告》），对省内春运路线拥挤、路线平安、车流迁徙及客流方面提供预测，帮忙宽广市民正当布局春节出行。 一、路线拥挤状况预测 依据《预测报告》显示，春运期间，高速出程在1月26日开始呈现拥挤小顶峰；相比出程而言，返程顶峰压力较大，工夫次要集中在2月6日（正月初六）和7日（正月初七），2月16日（正月十六）开始呈现返程次顶峰。春节期间，预计2月5日（正月初五）开始提前进入高速返程顶峰，拥挤顶峰预计将从2月6日（正月初六）11点继续至16点。 春节期间高速易拥挤路段如下表： 二、高速平安预测 春运期间，高速超速驾驶高发路段（理论驾驶速度大于限速）将集中在立交、出入口、桥梁和隧道左近，高速超速驾驶高发前10路段如下表，将驶入以下路段的车主需标准驾驶行为、防止超速。 三、车流迁徙预测春运期间，不同城市间的车流迁徙方面，最频繁的城市迁徙路线为广州-佛山、佛山-广州、东莞-深圳和深圳-东莞；热门城市之间的车流迁徙趋势出现规律性变动，从元旦前一周开始逐渐升高，到1月31日（元旦）达到最低，2月8日（正月初八）开始逐渐恢复正常。 广州市春运期间车流迁徙预测表明，迁入、迁出趋势将在1月31日（元旦）左右达到波谷；迁入、迁出前3的城市均为佛山市、东莞市和清远市。 预计春运期间广州市迁入、迁出排行前10的高速路线别离如下图： 深圳市春运期间车流迁入、迁出趋势将在1月31日（元旦）左右达到波谷；迁入、迁出前3城市均为东莞市、惠州市和广州市。 预计深圳市迁入、迁出排行前10高速路线别离如下图： 四、客流预测节日期间，广东省客流迁徙前三名省份将别离是广西壮族自治区、湖南省和江西省。客流迁徙出行形式次要以汽车和火车为主，占比近九成。 城市方面，预计大湾区城市群迁徙最频繁的城市对前4为：广州-佛山、深圳-东莞、深圳-惠州以及广州-东莞。 省内重点城市迁入、迁出将出现对称趋势，其中广州市迁入、迁出前三城市均为佛山、东莞、深圳；深圳市迁入、迁出前三城市均为东莞、惠州、广州。 跨省出行方面，广州市、深圳市省外迁出、迁入前三名城市均为衡阳、郴州、赣州。 铁路客运方面，春运期间省内铁路交通天级客流量呈峰-谷-峰态势，火车站点节前流量安稳回升，1月25日（腊月廿三）至1月30日（腊月廿八）迎来峰值；节中1月31日（元旦）及2月1日（春节）客流量骤降；节后客流量则逐步回升，别离在2月6日（正月初六）至2月8日（正月初八）及2月16日（正月十六）至2月18日（正月十八）迎来客流量峰值。 省内重点铁路站点均面临较大客流压力，其中以广州南站和深圳北站为最。倡议旅客提前布局交通形式并预留进站安检工夫；候车期间全程佩戴口罩，放弃平安间隔。 航空客运呈绝对集中态势，省内重点航空枢纽客流量排名前六的机场将是广州白云国际机场、深圳宝安国内机场、珠海金湾机场、揭阳潮汕国内机场、湛江机场和惠州平潭机场。 省内热门景区前3预计为南澳岛生态旅游区、北京路步行街以及广州长隆游览度假区。客流峰值别离将呈现于2月4日（正月初四）、2月1日（春节）、2月3日（正月初三）。 热门商圈方面，客流量排名前列的将别离是龙华商圈（深圳市）、新市商圈（广州市）、沙井商圈（深圳市）和观澜商圈（深圳市）。 值此新春佳节，揭示宽广返乡的司乘人员：在恪守各地防疫要求的前提下，提前把握车况、路况和天气状况，正当布局出行路线，平安驾驶，开心过年！ 《2022年广东省春运交通预测报告》全文关注官网公众号，查问原文支付。

如果您是一位企业开发者，在应用腾讯位置服务的时候是否被以下问题困扰过？ — 企业当中有多人须要登录控制台，但企业只有1个账号，无奈同时登录… — 某位开发者须要登录，但企业账号不是自己注册的，须要找过后的注册人获取账号、明码能力登录，十分麻烦… — 账号里只能设置1位用户接管报警信息，万一这个人一时忽略漏掉了信息，就可能酿成业务事变… — 企业里不同的角色（比方开发、运维、设计、商务等）尽管分工不同，但都看到的是同一个控制台界面，容易产生误操作… — 企业里不同的部门，尽管共用一个企业账号，但并不心愿其余部门看到本部门的具体信息，比方创立了哪些利用、调用量如何、购买了多少配额等… 日前，腾讯位置服务官网控制台的“子账号”体系正式上线，上述问题能够迎刃而解。 首先揭示一下，只有通过了企业认证的账号能力创立子账号。企业用户在登录控制台后，进入“集体核心-子账号治理”，能够在右上角找到创立子账号的入口。 一、如何创立子账号？ 在对主账号的身份进行短信验证之后，即可输出子账号的手机号进行邀请。 受邀者在收到邀请短信之后点击“批准”即可成为子账号用户。（提醒：如果受邀者之前未在腾讯位置服务注册过，须要先实现平台注册才可成为子账号用户） 二、如何调配子账号权限？ 主账号用户在“集体核心-子账号治理”界面能够看到所有已邀请的子账号列表。如果子账号的状态是“已承受”，则能够在右侧看到“受权”和“解除绑定”操作按钮。 目前反对对控制台的7大功能模块别离进行受权，每一个模块都蕴含查看和治理2类权限。 比方，对于开发人员来说，常常须要创立key、编辑key、查看key，这些都蕴含在利用治理的权限当中；对于运维人员，可能更关注配额用量、以及是否有超额告警等，能够给他们调配配额治理的权限；而对于地图设计师来说，则能够被调配个性化款式和图层的权限，用于创立和编辑不同的款式和图层…通过这种精密的权限治理，实现了同一账号下不同角色之间的操作隔离，既晋升了多人协同的工作效率，又躲避了误操作的可能性。 三、如何登录子账号？ 子账号的登录入口与主账号略有不同，须要切换至专门的登录入口，并且，目前只反对手机号登录。 在主账号没有给子账号授予任何权限的状况下，子账号登录进去之后会提醒用户分割主账号开明权限。 在主账号受权之后，子账号控制台的左侧菜单栏就能显示出相应的功能模块，并且在“集体核心-我的信息”当中能间接查看以后开明了哪些权限。 子账号体系的上线，无效的解决了在同一个企业账号下多人合作、多角色合作、多部门合作的难题，同时也实现了对账号拜访和操作权限的无效管制。 诚邀宽广企业开发者登录官网控制台体验子账号性能，置信此项性能将在保障您账号安全性的根底上，大大晋升企业组织协同办公的工作效率。在应用过程中如遇任何问题，欢送随时提工单反馈，腾讯位置服务将竭诚为您服务。

实景三维正在塑造数据、技术、利用的全新生态。 为了构筑对立的空间基底，监管部门与企业的联动更加频繁，跨畛域企业单干正在成为常态。作为空间信息畛域的深度参与者，腾讯在从数据生态、技术生态再到利用生态的产业链条中，扮演着助手的角色。 “腾讯近日公布的实景三维中国解决方案是一个凋谢的生态。” 腾讯位置服务总经理牟蕾向泰伯网介绍：“在数据采集层和数据处理层，咱们向地信测绘等业余机构提供算法、算力等凋谢能力。在应用层，则向更多企业和民众提供更加丰盛的服务。” 蓝海下仍存“暗礁”实景三维中国建设及其伴生而来的利用场景，俨然是一片蓝海。只是驶入蓝海时，仍需警觉水下“暗礁”。 “实景三维小场景都没问题，但到了几百平方公里、几千平方公里的时候，质变引起了量变”。据业内人士介绍，现阶段具体我的项目的建设过程中，依然存在技术瓶颈。 正如中国工程院院士、中国测绘迷信研究院声誉院长刘先林所提醒， “不能依附大量的人力和资金的投入，靠拼分辨率、堆服务器数量的笨办法来解决问题，要关注大数据、云计算、云存储、物联网等新技术。” 腾讯，正是具备新技术能力的入局者之一。 腾讯位置服务产品总监曹栋清在2021实景三维中国翻新峰会上介绍，实景三维是对人类生产、生存和生态空间进行实在、平面、时序化反映和表白的数字虚拟空间。 构建这样一个数字虚拟空间，须要实现从形象到实在，从立体到平面，从动态到时序，从按因素、分尺度到按实体、分精度，从只须要人了解到人机兼容了解，从海洋表层到全空间表白的六点转变。 而实景三维叠加市场需求，则须要摸索更实时、宽泛的感知，更疾速、低成本的更新，更多元的数据交融以及更深刻的利用。为此，腾讯联结大势智慧，独特推出了实景三维解决方案，向行业及利用对象提供自主可控的天文实体生成算法、海量算力的基础设施以及行业利用落地平台。 牟蕾示意，从数据采集层、数据处理层到应用层，实景三维建设的每一层都须要宏大的算力做撑持。在数据采集层，测绘、遥感、卫片等成绩都波及端上算力的撑持和优化；在数据处理层，海量、多源非结构化数据须要宏大算力进行结构化解决；在应用层，巨量三维模型也须要依附算法和算力，实现对各行各业利用的撑持。 “三维数据的采集存在波峰波谷的业务个性，因而不少测绘单位在解决数据时可能会遇到一个难题——算力不可伸缩。”牟蕾举例称：“当有工作下来时，数据量会呈现短时间的暴发，须要较大的算力撑持。但日常工作的数据处理量并不大，会出现绝对低谷的状态，测绘单位如果投入较高费用在服务器等硬件上，并不是一个经济正当的选项。基于腾讯的算力撑持，则能够为需要单位提供更为正当的解决方案。” “腾讯退出实景三维建设的行列中，就是心愿可能推动升高技术、老本和利用的门槛，让利用可能成长在更好的数据基底之上。” 动静联合的新生态“从实景三维所建设的天文实体空间降级到城市数字孪生，须要将动静孪生与动态孪生两张网络联合在一起。” 基于对数十亿人口的服务教训，互联网企业在“动”里取得了十分好的生态。而在实景三维所属“静”的一层，则有很多数据把握在监管部门手中。在牟蕾看来，仅靠一家单位或企业的力量，无奈构建真正残缺的数字孪生。 牟蕾将之拆分为数据生态、技术生态和利用生态，并进一步解释： 在数据生态中，测绘院等单位的数据可能构建出残缺的天文实体，但包含人车数据、业务流数据等动态数据，都须要企业参加提供，并保障数字孪生生态长期经营。 在技术生态中，测绘院及地理信息企业曾经领有不少创新能力，但因为数字孪生的技术点太多，须要更多单位、企业基于本身外围能力一直冲破，一直降低成本和应用门槛，赋能其余合作伙伴。 而在利用生态中，如果没有二次调配，无奈造成经济流，就无奈吸引企业长期投入。仅靠财政投入并非长久之计，须要企业应用和C端利用带来更大的经济体量，滋润整个产业的生态环境。 这须要政企两侧密切合作。在保障数据安全、可控的前提下，政府侧有层层凋谢数据的志愿和能源，企业侧有提供服务反对的能源，能力实现动静联合，触发经济效率良性循环，将服务水平晋升到更高层次。 基于这一前提，本次腾讯公布的实景三维中国解决方案，依然是凋谢的生态。 牟蕾介绍，解决方案中面向数据采集层和数据处理层的能力将面向传统测绘、地信畛域的单位及企业凋谢，通过升高算法、算力的技术门槛为其提供助力。应用层则面向更多企业和公众凋谢，帮忙更多搭档基于实景三维寻找到丰盛的利用机会。 腾讯心愿与测绘/地信产业搭档，独特构建“全面鲜活”的数据层、“海量算力、加强根底”的算力层、“开发互联”的应用层，助力数字中国建设。 关上设想空间在互联网相干技术赋能实景三维建设的同时，实景三维也为生产互联网的倒退提供了更广大的设想空间。 作为一家联通多端的生态型企业，腾讯的服务生态笼罩超十亿用户。在退出实景三维建设的过程中，腾讯看到了串联起产业互联网和生产互联网的又一门路。 “实景三维的建设与互联网产业的倒退出现回旋回升的趋势，二者相互促进。”牟蕾示意：“腾讯既是实景三维的建设者，也是受益者。” “在产业互联网中，腾讯更多是提供算法、算力等技术撑持，表演一个助手的角色。而在生产互联网中，咱们更多的是通过手机地图等利用去连贯C端用户。”牟蕾介绍：“在实景三维建设的力量驱动下，咱们可能将数据底盘做的更加丰盛，以更加低廉的老本向消费者提供更加多样的服务模式。” “将来的数字世界，将是实在三维物理世界的映射。” 牟蕾表白了她基于实景三维将来利用的局部构想：“以地图利用为例，现阶段的手机地图依然以立体为主，但基于实景三维这样的平面空间，咱们或者可能在数字世界中还原并摸索真实世界。” 这与大火的元宇宙概念不约而同。 “元宇宙与游戏最大的不同，在于它是一个真实世界与虚拟世界混行的状态。从近期来看，一些元宇宙概念下的企业更多侧重于打造游戏和VR等场景互动的模式，它们能够利用基于实景三维构建进去的虚拟空间。”牟蕾示意，“久远来看，除了游戏和VR，实景三维构建的数字空间能够撑持各行各业的利用。” 牟蕾认为，当虚拟世界从二维向三维演进时，承载终端将会一直进化，在车载终端、VR头显及便携投影设备等不同终端上出现的地图状态，也会自然而然的产生转变。这将是三维空间生态逐步成熟的过程。 腾讯始终在摸索利用天文空间更好的实现信息可视化，以帮忙人们更好的了解数字世界。为此，腾讯相继凋谢许多信息可视化与地图接口相结合的组件，也将沿着数据采集层、引擎服务能力层及应用层的脉络，持续推动相应工作。 “现阶段，三维数据的解决依然十分的‘吃’算力，对硬件设施要求十分高，咱们很难让一座残缺的数字孪生城市跑在一个个挪动端下面，这些技术问题依然期待被攻克。” “只有当实景三维这样的天文空间底座与各行各业利用混合在一起时，咱们能力足不出户摸索地球，能力催生更大的经济体。” 牟蕾示意：“这个凋谢生态有着微小的设想空间，也须要政府、企业和更多的参与者来独特建设。”

本文由云+社区发表作者：腾讯云数据库团队随着国内服务共享化的热潮普及，共享单车，共享雨伞，共享充电宝等各种服务如雨后春笋，随之而来的LBS服务定位问题成为了后端服务的一个挑战。MongoDB对LBS查询的支持较为友好，也是各大LBS服务商的首选数据库。腾讯云MongoDB团队在运营中发现，原生MongoDB在LBS服务场景下有较大的性能瓶颈，经腾讯云团队专业的定位分析与优化后，云MongoDB在LBS服务的综合性能上，有10倍以上的提升。 腾讯云MongoDB提供的优异综合性能，为国内各大LBS服务商，例如摩拜单车等，提供了强有力的保障。LBS业务特点以共享单车服务为例，LBS业务具有2个特点，分别是时间周期性和坐标分布不均匀。一．时间周期性高峰期与低谷期的QPS量相差明显，并且高峰期和低峰期的时间点相对固定。 二.坐标分布不均匀坐地铁的上班族，如果留意可能会发现，在上班早高峰时，地铁周围摆满了共享单车，而下班 时段，地铁周围的共享单车数量非常少。如下图，经纬度（121，31.44）附近集中了99%以上 的坐标。此外，一些特殊事件也会造成点的分布不均匀，例如深圳湾公园在特殊家假日涌入大量的客户，同时这个地域也会投放大量的单车。部分地域单车量非常集中，而其他地域就非常稀疏。MongoDB的LBS服务原理MongoDB中使用2d_index 或2d_sphere_index来创建地理位置索引(geoIndex),两者差别不大，下面我们以2d_index为例来介绍。一．2D索引的创建与使用db.coll.createIndex({“lag”:“2d”}, {“bits”:int}))通过上述命令来创建一个2d索引，索引的精度通过bits来指定，bits越大，索引的精度就越高。更大的bits带来的插入的overhead可以忽略不计db.runCommand({geoNear: tableName,maxDistance: 0.0001567855942887398,distanceMultiplier: 6378137.0,num: 30,near: [ 113.8679388183982, 22.58905429302385 ],spherical: true|false})通过上述命令来查询一个索引，其中spherical：true|false 表示应该如何理解创建的2d索引，false表示将索引理解为平面2d索引，true表示将索引理解为球面经纬度索引。这一点比较有意思，一个2d索引可以表达两种含义，而不同的含义是在查询时被理解的，而不是在索引创建时。二．2D索引的理论 MongoDB 使用GeoHash的技术来构建2d索引（见wiki geohash 文字链 https://en.wikipedia.org/wiki...RecordId的索引映射方式存储在Btree中 很显然的，一个2bits的精度能把平面分为4个grid，一个4bits的精度能把平面分为16个grid。 2d索引的默认精度是长宽各为26，索引把地球分为(2^26)(2^26)块，每一块的边长估算为2PI6371000/(1<<26) = 0.57 米 mongodb的官网上说的60cm的精度就是这么估算出来的 By default, a 2d index on legacy coordinate pairs uses 26 bits of precision, which isroughly equivalent to 2 feet or 60 centimeters of precision using the default range of-180 to 180三.2D索引在Mongodb中的存储上面我们讲到Mongodb使用平面四叉树的方式计算Geohash。事实上，平面四叉树仅存在于运算的过程中，在实际存储中并不会被使用到。插入 对于一个经纬度坐标[x,y]，MongoDb计算出该坐标在2d平面内的grid编号，该编号为是一个52bit的int64类型，该类型被用作btree的key，因此实际数据是按照 {GeoHashId->RecordValue}的方式被插入到btree中的。查询 对于geo2D索引的查询，常用的有geoNear和geoWithin两种。geoNear查找距离某个点最近的N个点的坐标并返回，该需求可以说是构成了LBS服务的基础（陌陌，滴滴，摩拜），geoWithin是查询一个多边形内的所有点并返回。我们着重介绍使用最广泛的geoNear查询。geoNear的查询过程,查询语句如下db.runCommand({geoNear: “places”, //table Namenear: [ -73.9667, 40.78 ] , // central pointspherical: true, // treat the index as a spherical indexquery: { category: “public” } // filtersmaxDistance: 0.0001531 // distance in about one kilometer}geoNear可以理解为一个从起始点开始的不断向外扩散的环形搜索过程。如下图所示： 由于圆自身的性质，外环的任意点到圆心的距离一定大于内环任意点到圆心的距离，所以以圆 环进行扩张迭代的好处是： 1）减少需要排序比较的点的个数 2）能够尽早发现满足条件的点从而返回，避免不必要的搜索 MongoDB在实现的细节中，如果内环搜索到的点数过少，圆环每次扩张的步长会倍增MongoDB LBS服务遇到的问题部分大客户在使用MongoDB的geoNear功能查找附近的对象时，经常会发生慢查询较多的问题，早高峰压力是低谷时段的10-20倍，坐标不均匀的情况慢查询严重，濒临雪崩。初步分析发现，这些查询扫描了过多的点集。 如下图，查找500米范围内，距离最近的10条记录，花费了500ms，扫描了24000+的记录。类似的慢查询占据了高峰期5%左右的查询量测试环境复现与定位 排查数据库的性能问题，主要从锁等待,IO等待,CPU消耗三封面分析。上面的截图扫描了过多的记录，直觉上是CPU或者IO消耗性的瓶颈。为了严谨起见，我们在测试环境复现后，发现慢日志中无明显的timeAcquiringMicroseconds项排除了MongoDB执行层面的锁竞争问题，并选用较大内存的机器使得数据常驻内存，发现上述用例依旧需要200ms以上的执行时间。10核的CPU资源针对截图中的case，只能支持50QPS。 为何扫描集如此大 上面我们说过，MongoDB搜索距离最近的点的过程是一个环形扩张的过程，如果内环满足条件的点不够多，每次的扩张半径都会倍增。因此在遇到内环点稀少，外环有密集点的场景时，容易陷入BadCase。如下图，我们希望找到离中心点距离最近的三个点。由于圆环扩张太快，外环做了很多的无用扫描与排序。 这样的用例很符合实际场景，早高峰车辆聚集在地铁周围，你从家出发一路向地铁，边走边找，共享单车软件上动态搜索距你最近的10辆车，附近只有三两辆，于是扩大搜索半径到地铁周围，将地铁周围的所有几千辆车都扫描计算一遍，返回距离你最近的其余的七八辆 问题的解决问题我们已经知道了，我们对此的优化方式是控制每一圈的搜索量，为此我们为geoNear命令增加了两个参数，将其传入NearStage中。hintCorrectNum可以控制结果品质的下限，返回的前N个一定是最靠近中心点的N个点。hintScan用以控制扫描集的大小的上限。hintScan: 已经扫描的点集大小大于hintScan后，做模糊处理。 hintCorrectNum:已经返回的结果数大于hintCorrectNum后，做模糊处理。该优化本质上是通过牺牲品质来尽快返回结果。对于国内大部分LBS服务来说，完全的严格最近并不是必要的。且可以通过控制参数获得严格最近的效果。在搜索过程中，密集的点落到一个环内，本身距离相差也不会不大。该优化在上线后，将部分大客户的MongoDB性能上限从单机1000QPS提升了10倍到10000QPS以上。和Redis3.2的对比Redis3.2也加入了地理位置查询的功能，我们也将开源Redis和云数据库MongoDB进行对比。 Redis使用方式：GEORADIUS appname 120.993965 31.449034 500 m count 30 asc。在密集数据集场景下，使用腾讯云MongoDB和开源的Redis进行了性能对比。下图是在密集数据集上，在24核CPU机器上，MongoDB单实例与Redis单实例的测试对比。需要注意的是Redis本身是单线程的内存缓存数据库。MongoDB是多线程的高可用持久化的数据库，两者的使用场景有较大不同。 总结MongoDB原生的geoNear接口是国内各大LBS应用的主流选择。原生MongoDB在点集稠密的情况下，geoNear接口效率会急剧下降，单机甚至不到1000QPS。腾讯云MongoDB团队对此进行了持续的优化，在不影响效果的前提下，geoNear的效率有10倍以上的提升，为我们的客户如摩拜提供了强力的支持，同时相比Redis3.2也有较大的性能优势。此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号 ...

白话解读离线learning部分本质上是将任意时刻任意空间位置离散化为时空网格，根据派单记录（含参加调度但无单的司机）计算该时空网格到当天结束时刻的预期收入。关键问题：怎么计算预期收入？动态规划思路：假设总共有时刻区间为[0, T)；先计算T-1时刻的所有网格的预期收入（此时未来收入为0，只有当前收入），其本质就是计算当前收入的均值；然后计算T-2时刻的所有网格的预期收入；…；以此类推这样的话，就可以计算出每个时空网格到当天结束时刻的预期收入。重点：为什么按照这个方式得到的值函数是合理的？The resultant value function captures spatiotemporal patterns of both the demand side and the supply side. To make it clearer, asa special case, when using no discount and an episode-length of a day, the state-value function in fact corresponds to the expected revenue that this driver will earn on average from the current time until the end of the day.在线planning部分使用以下公式描述订单和司机之间的匹配度：价格越高，匹配度越高当前位置价值越大，匹配度越低未来位置价值越大，匹配度越高接驾里程，隐形表达，越大则预计送达时间越大，衰减系数越小，匹配度越低使用KM算法求解匹配结果评估方案AB-test方案we adopted a customized A/B testing design thatsplits tra c according to large time slices (three or six hours). Forexample, a three-hour split sets the rst three hours in Day 1 to runvariant A and the next three hours for variant B. The order is thenreversed for Day 2. Such experiments will last for two weeks toeliminate the daily di erence. We select large time slices to observelong-term impacts generated by order dispatch approaches.实际收益the performance improvementbrought by the MDP method is consistent in all cities, with gains inglobal GMV and completion rate ranging from 0.5% to 5%. Consis-tent to the previous discoveries, the MDP method achieved its bestperformance gain in cities with high order-driver ratios. Meanwhile,the averaged dispatch time was nearly identical to the baselinemethod, indicating little sacrifice in user experienceValue function可视化效果如何包装为强化学习将时空网格定义为state；将派单和不派单定义为action；将state的预期收入定义为状态值函数。强化学习的目的是求解最优策略，也等价于求解最优值函数。派单场景的独特的地方是，建模的时候agent是每个司机，做决策的时候是平台决策，所以司机其实是没有策略的，或者说，通过派单机制，司机的策略被统一化为使平台的期望收入最大。因此在强化学习的框架下，可以将离线learning和在线planning认为是policy iteration的两个步骤，learning是更新value function，planning是policy update。然而，其实细想起来，还是有些勉强。 ...