【文末抽奖赠书】算法与数据中台:基于 Google、Facebook 与微博实践

冬瓜:这是博文视点的新书 《算法与数据中台:基于 Google、Facebook 与微博实践》,在文末会有抽奖,欢迎大家积极参与。

在O2O 模式下,网约车平台成为其中最为经典的案例,无论是美国的 Uber 还是国内的滴滴都已经发展成为社会的基础设施。

网约车平台的使用界面

从这两大巨头的发展史来看,尽管前期它们都是利用补贴大战来完成对市场的占领的,但是随后它们也都专注于更为精细的运营和服务,以便满足乘客、司机和平台这三方的利益诉求。

为了实现这些目标,Uber 和滴滴等网约车平台都聚焦于技术的深耕和创新,它们的成功实践经验表明技术是业务发展的强大驱动力。业务和产品的快速迭代需要依靠优良的系统架构,而算法与数据中台在整体架构中又发挥了极为重要的作用,它是实现数据驱动和智能调度的核心组件。

本文选自《算法与数据中台:基于Google、Facebook与微博实践》一书,我们将围绕着网约车平台来探讨一下算法与数据中台在该业务中的重要意义和实践经验。

▼ 扫码获取本书详情 ▼


数据中台技术架构

从乘客和司机的角度来看,网约车平台的整个运行过程是十分简单的,他们似乎感知不到背后互联网技术的存在。但实际上正是由于技术的支持和赋能,才给予了使用者更简单、更流畅和更智能的体验。

这里我们着重围绕整体架构与核心算法来阐述网约车平台背后的技术力量。

1  分层系统架构

我们可以把网约车平台的典型系统架构简化为这样的分层设计模型。

网约车平台的分层系统架构

其包含了产品接入平台业务中台算法与数据中台以及基础架构这四个互相依赖的层次。

 产品接入平台 : 该平台不仅为乘客(用车需求方)和司机(用车服务方)提供了对接入口,而且也满足了来自不同业务线的乘车产品的功能性需求。

 业务中台 : 它包含了网约车业务中最核心和最通用的业务,其中需求池、运力池、调度系统、订单系统、司机系统、分单系统、定价系统和策略引擎等是业务中台里至关重要的组成部分。业务中台是网约车业务区别于其他互联网业务的核心部分,它体现了与打车最为密切的功能特性和业务策略。

 算法与数据中台 : 它是支持网约车业务中各种产品与功能进行数据驱动和智能化升级的关键组件。通常来说,它由用户画像服务、司机画像服务、LBS 数据服务、机器学习平台、在线预估服务和样本拼接系统等部分构成。

基础架构 : 作为底层支持,它为网约车业务中的上层建筑提供了必要的存储保障、算力保障、资源保障、运维保障以及其他必要的支撑。该层面的系统和其他互联网系统中的基础架构组件没有本质区别。

2  业务中台

业务中台管理着打车、分单、接单和定价等核心业务流程,因此它也集成了如下网约车平台中最通用的业务系统。

 需求池和运力池:这两个系统分别管理着出行需求信息和车辆运力信息。

 调度系统:它可以根据不同的分单场景和需求,在资源调度的过程中选择抢单模式或者分单模式。

 订单系统:它管理着所有的历史订单以及当前的订单状态。

司机系统:它管理着所有司机端的数据和状态。

 分单系统:作为最核心的业务系统,它需要从全局的角度将订单和司机进行高效匹配。

 抢单系统:在抢单模式下,它需要对乘客订单在多个司机间的争抢来进行仲裁。

 策略引擎:它需要根据机器学习模型、专家规则和人工策略对业务系统的运行过程进行干预与指导,从而提高系统的智能化水平。

 定价系统:它需要根据里程、时间、供需关系以及其他数据对行程进行动态定价。

在这些业务系统中,分单系统占据着核心地位,因此,我们着重对这一部分进行介绍。在任意时刻都会有众多的乘车需求和闲置运力等待匹配,分单系统便承担了对供需进行高效匹配的重任。为了满足多种打车产品的功能性需求,平衡多方的利益诉求,并且实现资源的优化配置,分单系统通常都有着复杂的运行逻辑。我们需要知道,当分单系统完成了订单和司机的匹配后,乘客会有一定的概率进行订单撤销操作,同时司机也会有一定的概率选择拒绝接单。因此,分单系统的一个重要优化目标就是降低这些有损订单成交的操作,系统需要在算力可行和决策时间有限的约束下来实现总成交量或总成交额最大化的分单目标。

以城市或者行政区域为界限,我们可以把这个范围内的所有订单和司机的匹配需求按照 DO(Driver-Order)匹配矩阵抽象为数据模型。

司机与订单的 DO 对矩阵和二分图最佳匹配示意图

上图左侧横行代表了所有的订单,竖列代表了所有的司机,它们之间都是可以匹配的,但是匹配的概率各不相同。此外,这里有一个重要的现实约束条件,即一个司机在同一时刻只能匹配一个订单,并且一个订单在同一时刻只能被一个司机接单。因此,匹配问题又可以转化成一个如右侧所示的二分图最佳匹配问题(连线代表有一定的权值),它的最终优化目标是使得所有连线的权值之和最大化,经典的 KM 算法(Kuhn Munkres Assignment Algorithm)比较适合解决此类问题。在进行二分图匹配的求解过程中,系统需要对权值进行数值定义。如果以交易额为优化目标,那么权值就是订单价值乘上预估的成交概率;如果单纯以交易量为优化目标,那么权值就是成交概率。平台可以在不同的阶段和场景下采用不同的权值定义,并且权值的设定也需要考虑一些运营策略和安全因素,例如,评分较低的司机或者乘客需要被降权。

分单系统的大体运行流程图

上图展示了分单系统的大体运行流程,它包括权值计算和权值调整两个关键阶段。权值计算基本上是根据行车距离以及其他硬性规则来进行成交额的估算,这里的距离可以被定义为球面距离或者路面距离。权值调整则是根据模型预估以及一些运营策略和安全策略来进行权值的加权、降权或者过滤操作。从分单的全流程来看,整个过程涉及多种数据,以及包括应答率预估、等车时长预估以及安全预估等多个机器学习模型的使用,因此算法与数据中台在这个场景中为分单系统提供了重要的数据和智能支撑。

3  算法与数据中台

算法与数据中台是网约车业务进行数据驱动决策和智能化升级的必要条件,正如前文中所探讨的,业务系统中的各个环节均需要它来提供支撑。在网约车业务中,最为核心的数据可以被归纳到用户数据、运力数据和订单数据三个方面。

 用户数据 : 从平台的角度来看,用户数据包括乘客信息和司机信息两部分,完善的用户画像对于网约车平台进行资源的有效调度起着关键作用。乘客画像一般包括乘客的性别、年龄、身份和是否为车主等信息,这些数据可以被平台用来进行价格的动态调整,从而实现运力资源的调配和优化。司机画像一般包括司机的年龄、性别、驾驶习惯、信用分以及投诉记录等信息,这些数据可以被平台用来进行激励策略的动态调整,以便实现运力的有效配置。

 运力数据 : 运力数据在网约车业务中有着不可替代的影响力,通过对与运力相关的实时特性以及历史特性的掌握,平台可以有效地实现资源利用效率和多方利益的最大化。网约车平台一般将地理区域按照一定规则划分为多个较小的子区域并统计各个子区域的实时运力信息和历史运力信息。实时运力信息一般包括当前的司机数、订单数、未播发的订单数等信息,而历史运力信息一般包括过去一段时间的司机数以及相同时间段的订单数等信息。

 订单数据 : 订单数据包括两部分,即当前订单的详细信息和历史订单的统计信息。当前订单的详细信息里包含了预估价格、预估时间、预估距离、折扣率和产品选择等,而历史订单的统计信息里一般包含了历史订单数、历史消费金额、历史订单取消数、历史打车产品类型以及历史投诉订单数等信息。

要将上面这些数据充分应用和赋能到网约车业务中,则需要借助机器学习模型和业务策略机制来实现。下面我们就算法模型在网约车平台中的使用场景进行简要介绍。

  • 订单展示:平台可以依据算法模型对出行时间和出行价格进行准确预估。

  • 订单定价:平台可以利用算法模型对应答率、转化率和留存率等指标进行精准预估,并将这些预估值作为定价策略的依据。

  • 运力估算:平台可以构建供需预测模型,并基于模型预估值为乘客提供打车排队时间的预估值。

  • 智能分单:平台可以利用诸如强化学习等更为复杂的算法来进行订单的分发。

  • 乘车安全:平台可以建立相应的机器学习模型来预测司机和乘客的冲突概率,或者司机对乘客的骚扰概率,进而提升乘车的安全性和乘车体验。

通过上面的介绍,我们可以看到数据和算法已经成为网约车业务中不可替代的决定性要素,而算法与数据中台则为业务的快速发展和智能化升级提供了重要支撑。

接下来,我们从打车定价和打车安全这两个核心场景进行探讨,并阐述算法与数据中台在这些场景中的应用。

案例一:打车定价场景

网约车平台需要同时兼顾乘客、司机和平台这三方的利益诉求,而在所有因素中出行价格则占有核心地位,它直接影响了乘客对出行方式的选择、司机的服务利润以及平台的商业利益。本节我们将对打车定价场景进行探讨并分析算法与数据中台在该场景中的作用。

1. 场景描述

为了兼顾灵活性和执行效率,网约车平台一般会将规则定价策略和智能定价策略结合起来,进而实现动态价格。

  • 规则定价策略:

它与传统的出租车定价策略并无本质区别,该策略会按照城市、里程和时间等有明确定义的规则来产生基准的出行价格,这些规则也都会以明文的形式在打车应用中进行公布。由于这部分内容一般由运营团队和数据分析团队来制定,因此这里不做过多描述。

  • 智能定价策略:

作为规则定价的重要补充,智能定价是网约车平台所具备的独特定价方式。相比于司机和乘客,网约车平台不仅可以感知全局的即时供需情况,它也拥有丰富的历史数据积累。智能定价的一个核心目标是负责统筹全局来满足乘客和司机的需求,并在此基础上完成自己的商业目标。

一个完善的动态价格机制需要考虑闲置运力、乘客意愿、使用场景以及历史数据等一系列因素,由于现实场景的复杂性,在专家规则的基础上,平台需要更多地借助数据和算法来进行价格的动态调整。举例来说,价格的动态上浮比例以及下浮折扣率都需要基于大量历史数据和准确的机器学习模型来计算得到。由此可见,算法与数据中台在智能定价场景中有着举足轻重的影响,我们可以用下图来描述它在这个业务场景中的应用。

算法与数据中台在定价场景中的应用

2  价格动态下浮策略

价格的动态下浮在网约车平台里十分常见,其通常采用抵用券、打折和一口价等方式来展现。

打车价格浮动示意图

价格的动态下浮是一定发展阶段下和某些市场营销需求下的运营手段,也是实现三方利益最大化的技术手段。一般来说,通过对价格进行合理尺度的下浮操作,平台可以在自己利润正向的前提下来促进订单总量和司机留存的提升。

网约车平台里的动态定价策略通常涉及订单转化率和订单价值这两个核心指标。

前者衡量的是乘客看到预估价格等信息后所表现出来的用车意愿的强烈程度,后者衡量的是订单的实际价值。订单价值在不同的平台或者不同的运营阶段有着不同的含义,平台既可以将订单价值定义为订单费用的数额,也可以把它定义为司机在单位时间内的收益。价格下浮定价策略的一个典型应用场景就是寻找到那些订单转化率很低但是订单价值却很高的订单,并针对这些订单进行降价操作。

价格下浮定价策略会给予这类订单一定比例的折扣(如下图),以便在保障订单价值不受过大损失的情况下来快速提升订单转化率,从而实现整体利益的最大化。

打车定价场景下的订单转化率和订单价值的关系

降价的幅度通常以折扣率来表示,因此我们可以建立折扣率和订单转化率之间的关系,这种关系完全可以通过机器学习模型来描述,其中折扣率是该模型中一个非常重要的特征。

订单转化率模型的特征选择和模型演进方向

在特征选择方面,除了折扣率,乘客的画像特征、打车记录特征、行程、预估价格和运力供给等因素也与订单转化率有非常大的相关性。在机器学习模型的选择上,我们也看到了从简单的 LR 模型到 XGBoost 模型再到DNN模型的演进方向。无论是特征的选择还是模型的迭代,除了最基本的离线评估,网约车平台都需要借助算法与数据中台里的 AB 实验平台在真实场景下进行验证和评估。

3  价格动态上浮策略

价格的动态上浮一般出现在诸如高峰期、极端天气和特别活动等供需不平衡的场景下。

在供远小于需的场景下,由于闲置运力的缺乏,再多的出行订单也无法被有效满足,长时间的等待还会严重影响乘客的用户体验。通过对价格进行合理的动态上浮,平台可以迫使部分非刚需乘客放弃用车,从而更好地满足刚需乘客的用车需求。同时,平台利用较高的服务报酬也可以有效地吸引其他区域的空车司机前来接单,从而从更大的空间尺度上来实现供需平衡。

价格动态上浮的尺度可以用司机的应答率来衡量,因此我们可以建立价格上浮比例和司机应答率之间的关系,这种关系完全可以通过机器学习模型来描述,其中价格上浮比例是该模型中一个非常重要的特征。在特征选择方面,除了价格上浮比例,司机应答率与下面这些因素也密切相关。

  • 历史特征:平均价格、昨天的历史应答率、一周前的历史应答率。

  • 实时特征:实时订单数、实时未播发订单数、实时空车司机数。

  • 空间特征:周围空车司机数、周围已创建订单数、周围抢单和发单比。

  • 订单特征:预估价格、预估时间、预估行驶距离、行驶方向。

从机器学习模型选择的角度来看,该场景下的模型也经历了从简单到复杂的演进。目前来说,深度神经网络模型已经成为主流选择。理所当然地,特征和模型的迭代上线都需要将离线评估指标与AB 实验平台产生的在线指标作为主要评判依据。

 / 案 例 小 结 / 

这个案例所阐述的智能定价方式只是网约车平台里定价策略的一种基本形式,在不同的时期和市场状况下,网约车平台所追求的目标是不一样的。在发展的初期,平台追求的是订单量的最大化而非运营利润;而在发展的中后期,平台则更多地考虑乘客、司机和平台这三方利益的平衡。在平台的不同发展阶段以及定价策略的迭代过程中,数据和算法总是发挥了重要作用,特别是在平台转入精细化运营阶段后,算法与数据中台则发挥了决定性作用。


案例二:打车安全场景

出行安全是所有乘客都关心的首要问题。相比于出行费用和出行品质,出行安全对于网约车平台来说是一个更基本的要求,特别是在多起安全事故之后,对于乘客和司机的安全保障成为网约车行业中一个极为关切的话题。

▊ 1. 场景描述

各类网约车平台为了切实保障乘客和司机的出行安全,纷纷出台了实名认证、行程分享、全程录音等多种安全保障措施。但这些基本上都属于事后补救措施,要做到事前预防,则需要在撮合订单和司机过程中进行,这就是本节所要阐述的派单安全保障机制。

部分女性乘客可能会有这样的经历,在深夜里打车去往地点较为偏僻的地方时,她们往往需要等待较长时间才会有司机接单。同理,对于女性司机来说,在深夜时也基本不会接前往偏僻目的地的乘客订单,这些现象背后都有派单安全保障机制的参与。派单系统将自动地分析安全事故在各类场景下的可能性,从而避免高风险订单的分发。系统通常会结合乘客的出行习惯、司机驾驶习惯、历史订单信息和投诉记录等特征来进行综合判断。派单安全保障机制往往需要借助机器学习模型来进行风险预测,它可以在上文中介绍的二分图匹配算法里降低那些具有较高风险匹配对的权值。

举例来说,我们可以为派单安全保障机制建立如下一些机器学习模型。

  • 司乘冲突模型:用来预估司机和乘客发生冲突的概率。

  • 司机骚扰模型:用来预估司机对乘客实施骚扰的概率。

  • 醉酒伤人模型:用来预估乘客醉酒可能导致伤人的概率。

2  安全策略

限于篇幅,这里我们仅对司机骚扰模型在派单安全保障机制中的可能应用方案进行探讨。

司机骚扰模型在派单安全保障机制中的应用方案原理示意图。

派单系统会利用司机骚扰模型来预测乘客订单 O4 和司机 D1 或司机 D4 之间发生骚扰的概率。假设该订单与司机 D4 之间的预估骚扰概率大于某个设定阈值,那么该匹配会被直接过滤;假设该订单与司机 D3 之间的预估骚扰概率较小,那么该匹配会被降权处理。

在这类场景下的模型中,乘客和司机双方的用户画像具有突出的特征重要性,具体来说,模型可以考察如下一些特征数据。

  • 乘客特征:年龄、性别、近期订单次数、用券情况、打车产出选择等。

  • 司机特征:年龄、性别、驾驶习惯、历史订单信息、信用分、投诉记录等。

  • 订单信息:目的地坐标、行驶路线、行驶距离、当前时间和天气等。

司机骚扰预测这类的安全机制模型和其他场景下的模型有一些不同之处,由于样本稀疏且实验成本很高,因此它无法完全依赖 AB 实验平台来进行在线评估。这类模型一般会转而利用订单请求回放的方式来进行离线评估。在线评估一般只是为了试探模型对诸如应答率和订单数等其他指标的影响,从而避免过度惩罚对于用户正常出行需求的负面影响。

/ 案例小结 /

对于出行安全的保障是网约车平台得以生存的根本所在,除了全程录音等事后补救措施,更重要的机制是提前预防安全事故的发生。在订单和司机的匹配过程中加入多种与安全策略相关的机器学习模型是一个可行的技术方案。

(完)

本文有删减,完整案例详解请见《算法与数据中台:基于Google、Facebook与微博实践》一书。

《算法与数据中台:基于Google、Facebook与微博实践》

詹盈 著

  • 智能数据中台横空出世

  • Facebook、Google、Uber、阿里、腾讯技术带头人领衔力荐

本书作者依据在Google、Facebook、新浪微博及滴滴出行等中美一流互联网公司的实际工作经历,对算法技术、数据技术,以及围绕它们进行的技术中台建设实践进行了全面的探讨,并在此基础上对信息流推荐、计算广告及智能出行等核心互联网业务进行了案例剖析。


点击图片抽奖

▼点击阅读原文,了解本书详情!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
从0-N建立大数据中台,数据驱动速度决定了 数据驱动速度决定了 数据驱动速度决定了 数据驱动速度决定了 数据驱动速度决定了 MVP MVP迭代的速度, 迭代的速度, 迭代的速度, MVP MVP迭代速度决定了商业模式是否可以成立 迭代速度决定了商业模式是否可以成立 迭代速度决定了商业模式是否可以成立 迭代速度决定了商业模式是否可以成立 迭代速度决定了商业模式是否可以成立 迭代速度决定了商业模式是否可以成立 迭代速度决定了商业模式是否可以成立 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 让数据分析业务人员独立完成和运营,减少 ETL 脚本和提数重复工作量,高业务人员分析效率 脚本和提数重复工作量,高业务人员分析效率 脚本和提数重复工作量,高业务人员分析效率 脚本和提数重复工作量,高业务人员分析效率 脚本和提数重复工作量,高业务人员分析效率 脚本和提数重复工作量,高业务人员分析效率 脚本和提数重复工作量,高业务人员分析效率 脚
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值