DataFun活动回顾 | 画像在外卖智能调度的实践-详细版

本文根据百度外卖首席架构师梁福坤先生在DataFun大数据架构系列活动——大数据架构在O2O场景中的应用所作分享《画像在外卖智能调度的实践》编辑整理而来，在未改变原意的基础上略作删减。梁福坤先生在业内有10年+的从业经验，百度do.baidu.com大数据平台的创始人，目前负责百度外卖大数据平台+智能物流策略方向。

编辑 | 数据猿

官网 | www.datayuan.cn

微信公众号ID | datayuancn

谢谢大家。今天是周末，大家还抽过时间过来非常不容易，在座的都是跟大数据相关的，有做策略的，还有做数据仓库，都是相关的从业人员。我先做一个调查，有多少用户用过百度外卖下过单的，举手示意一下，用过百度外卖和饿了吗的请举手？好，基本都用过。今天给大家分享的是画像，画像在我们智能调度的一些实践。

我基本是分这样四个场景，第一个是外卖的O2O场景介绍；第二，就是百度外卖智能调度面临的时空问题；第三个就是画像特征在外卖智能调度的应用；第四个就是一个实践。

因为今天的主题是在O2O的一些相关服务，我们介绍一下在外卖这个场景下是一个什么场景。刚刚我统计了一下，大家都用过外卖，我们打开相应APP，还有其他的一些方式，最早的就是在页面或者H5或者百度地图、糯米，都可以用到百度外卖，现在我们隶属于饿了吗，拉扎斯集团，通过他们的APP，我们一起提供O2O孵化的场景。左侧是进来后的场景，右侧就是下单，下单之后我们看到了一些控制台，在这可以看到，每个单来了之后有没有被分出去，有没有被商户接单，还有一些预期，距离用户期望时间的一些时间；这个地方是一个骑士的轨迹情况，针对个人APP，我们可以看到一些骑士的轨迹，有可能会越来越远，或者距离一公里，但是一直没有配送，其实在控制台可以看到他身上有一些其他的任务。这些具体调度的一些策略都是通过我们后端智能调度的一些服务。

外卖，其实大家最理解的场景就是送盒饭，但是现在针对外卖场景有非常大的不同，比如说从传统的餐饮到新零售，就是水果生鲜都可以通过外卖进行预定，包括商超、医药、鲜花，蛋糕，五金，电器等等生活服务类场景都可以进行相应的配送。同时，我们的预定模式也从最初的订餐，商家进行陪送，我们后期有相应的预订支持。

像万能跑腿，对于个人来讲类似于闪送一个场景，可以帮你买东西，或者取东西。

另外就是全城配送，有很多的商户，他可以覆盖城市的每一个角度，像在北京五环之内都可以覆盖到，他想去尝试本地化服务，做了一个这样的场景，所以我们的全城配送在很多场景下，比如说像水果生鲜、鲜花蛋糕这样类似的产品都可以以全城送这样的方式进行支持。

还有一些落地配，落地配主要是在和快递行业进行时间上的错峰，对于骑士来说高峰就是午餐和晚餐，但是对于快递来讲就是点餐之前的时间可以做到落地配；还有就是准时达，可以购买相应的增值服务，我可以做到时间上优先的保证；还有专人专送和众包业务等。

这都是在外卖场景之上进行综合，我们去把整个场景化做的更细，（右图）这些都是对外的一些直观感受。

外卖场景就有两个比较大的高峰期，午高峰和晚高峰；其他的时候，比如在夜宵的时候，还有下午茶，都是逐步弥补的一个空间；但是对于用户来讲有一个适应，或者说能够满足通过外卖的方式点下午茶或者点宵夜。

上面是订单的一个周期，下面是我们的一个服务接口相关的一个实时的动态。白天的时候就是交易比较集中的就是两大高峰，两大角色参与，就是商家和用户，是两个最主要的参与者。但是，这两个角色交互了以后，多个角色参与什么意思呢？在我们外卖的场景下，其实想做一个通过沟通层面、算法层面达到一个最优解的情况下，我们变量参与的越少，你能够比较快、比较准的达到一个最优解，当你角色参与的越来越多，比如说我们角色有哪些呢？像骑士这个角色，交通的情况，天气的情况，这些都是在你下完单之后，我们在履约完成都会在里面参与其中；尤其是恶劣天气，大家都会感同身受，无论是配送的难度，还是等餐的时长，都会在整个决策中受到很大的影响。

另外一个，就是履约流程比较长，从下完单，其实感觉到就是商务出餐，但是背后一些财务的、营销的、翘单等。

交易非常的复杂，时效性非常高；你如果是一个打车行业，可能就是叫个出租车，在进行距离召回进行相应司机的指派，或者司机的抢单；如果是共享单车这种情况，就需要你去主动到达服务这个点，接下来由你来操控最终到达，然后履约整个链条的完成；对于外卖来讲，基本上你在触达手机下单之后，所有的事情都不需要你来做，只需要你来取餐就行了。

这是一个外卖订单的生命周期，大家可以看一下。我先说一下，从这里下单，这个是用户决策参，。下面就是商户进行接单，接单了以后，然后，骑士就是到店，骑士到店后，会等这个出单时间，像披萨出餐时间就是5分钟左右，像排骨米饭，大家想象一下几分钟？其实排骨饭非常快，只有有一些配菜在最后一个阶段。但是，有一些中式其他一些餐饮，像金百万，像其他的红烧肉这种，有一些场景下高峰期出餐速度也是一个瓶颈。

商户出餐之后，骑士就可以正常配送，进行取餐，对一个订单来讲取餐之后就可以进行送达，然后到达具体的楼宇，或者办公楼、小区进行交付，可能还有等待用户下来取餐，这样一个过程，这是一个订单整个的一个生命周期。

参与的角色包括用户，商户，还有骑士，隐含的是我们下面的一些消费经理BD这样的一些角色。服务平台，涉及到交易，销售，营销，支付和结算，对于商户来讲，他是一个小度掌柜，对BD来讲是Banff这样一个系统，Banff是用来发现商机，跟用户进行签约。整个过程当中风控就在无时无刻地进行介入，订单是否属于违约或者属于刷单这样的情况，还有一些运营体系。

接下来就是一些营销，怎么可以把流量导入进来，把用户留住，最终提升一些转化或者回头客。履约的外部因素就是提交通天气，像楼梯的高度，还有一些小区骑士没有办法直接进入，需要步行，还有一些校区，不允许骑士进入，需要等待学生到校门口取餐这样非常复杂的一个过程。另外对骑士来讲，对POI、AOI这样一个点或者面，有一个熟悉程度。在骑士的心目当中有一个地理维度、导航，他都是有这样的一个人为的画像。

后是外卖面临的一个时空问题。

然后，在去年的时候，这个都是在朋友圈刷遍了，谷歌AlphaGo算法，然后看到百度卖黑科技，就两个字外卖，其实普遍地想想，作为一个高科技的公司，百度对标的公司是谷歌，但是最终谷歌在阿尔法狗，而百度在送外卖。大家想一下，一个送盒饭的，为什么要搞的那个高大上，为什么百度这么招黑呢，这是在知乎上截图的，大家期望的是达到谷歌的一个高度，其实外卖是百度现在能达到的一个高度，当然现在随着百度AI的进程，百度外卖被剥离出来，最终和拉扎斯集团一起携手向前走。

接下来讲一下为什么我们是一个黑科技，真实的是百度外卖背后是人工智能调度的问题。这个解决的就是一个非常简单的场景，就是订单该给哪个骑士。实时物流系统通过智能调度，骑手为配送的订单，不同的目的地，进行不同的学习，骑手的实时位置和他的一些方向，然后，我们进行海量的大数据处理了之后就进行派单，系统地也会自动适应这个过程。比如说，刚刚看到的高峰期，他会在压单模式上，然后一些派送的追单上，在适用的场景下都会有不同的解。然后将“最后一公里”加入到整个路面的配送效率上，最终规划导航路径。我们现在的平均配送时间是28.6分钟，所以，这也是一个人工智能高科技与生活的一个结合。

直观看一下感受，下面这个是商家，上面俩个是用户，分别是2个用户下了两个商家的单，现在有4个骑士，分别在所示的这个位置。对于大家的直观感受来讲，这两个单怎么送？（观众：2或者4）其实很多场景下，如果是单纯的这个解的话，应该是让一个骑士就近配送，尤其是涉及到了冬天，骑士的很多交通工具像电瓶车，他基本是上午跑完下午23点电就消耗光了，他需要回到他的一个点去换第二块电瓶，然后第一块电瓶充电，然后再迎接晚上的一个跑单，所以说能够提高骑士的定单率，也就是相同的定单，相似的定单尽量并给一个骑士，这个叫做定单的追单或者一个分组。比如说，我们现在在这个情况之下，骑士1和3不被考虑的。

接下来大家看一下，这个定单希望时间，11：43，11：57，相差了14分钟，答案还是2、4吗？这个有一个条件，商家的出餐是不是也是这样一个时间的阶梯？相差14分钟。比如说，这个商家出餐时间是一样的，大家都在骑士到达了以后就准时出餐。这要考虑场景，就是用户和商家的距离，比如非常近，在0.5公里范围内，如果让用户等待的时间比较久，可能会让俩个订单都非常久，如果为了等其中的一单；如果距离非常的远，这个时间上有一定的差异化，可能也会让一个骑手去送。所以，这个情况之下时间差异不大的情况，2和4是最好的选择，如果时间差异大，可能就会分给俩个骑士去送。

现在问题来了，4就是一个新骑手，他刚刚是在行业里面从业，经验不是很多，单多的情况之下就会发生履约链条时间比较长，就耽误了配送时效，如果是新骑手的情况下4就是不考虑了，就剩下了2。

我再增加一个场景，接下来我们的地图出现了，这个是在果园地铁站附近两个单和相应商家，这里有因素要考虑吗？你会发现，在很多情况之下我们的路要么就被高架桥，河流，或者高速路环绕，就会出现什么呢？骑手配送过程当中走的是导航的一个线，走到这里，走到这里，前面会绕，最终会送到，这是一个导航距离，在现实当中骑士经历的场景非常复杂。

如果在用户一和用户二进行切换的过程当中，绕的路非常的远，比如绕到下面的白色的线穿过去，这样无形中增加的距离是非常高的，不如俩个骑士分别走，这就涉及到一个收益的计算。收益是什么？其实如果这样去送的话，他付出的是什么？得到的又是什么？得到的是给用户的准时率，失去的是什么？骑士的单均配送距离增长，如果骑士3身上的单就是那个方向走的，骑士2是朝下面走的。大家认为还合适吗？就是什么呢？他就送过去送过来，最后就到这里，或者在一到达了以后三又回来了。所以，这又涉及到了一个指派时机的问题，什么时候指派这个单。所以，我压了10分钟之后，骑士3又回来了，然后骑士4也没有单了，可能又合适了。如果从现在这个情况下，骑士1就是比较的合适。所以在时空问题下，你参与的角色越多，你在一个求最优解的情况下是一个非常困难的一个统计学问题或者说是一个功利学问题。

这就是外卖为什么是一个黑科技的原因。

真正的骑士是这样的，这是一个商圈，商圈是什么呢？是在一个数据层面，或者说在一个管理层面，他是一个集合，北京会划分非常多的商圈，统一进行管理。看到了这个绿色，黄色，还有黑色，其实都是一个骑士。如果我们把它身上的单，以及方向画完了以后这个地图就没办法看了，这个是一个现实的场景。

所以，在外卖场景下的时空分为两种，如果单独来看就是空间和时间。空间，比如说，像空间坐标点的导航距离，也就说是从商户到用户之间的一个导航，可能不是单纯的一个直线，这种导航在我们很多case里面，遇到的非常多，同一个小区可能没有办法跨，需要外面绕很大一圈。但是，如果有小门的话，地图上可能没办法识别。还有就是取送规则的路径规划，比如三个单，你是怎么送？这就是一个路径规划，在一个空间问题上的问题，再一个，空间会有层次性，我们曾经遇到过一个情况，地铁下面两层和上面两层是同一个POI地址，就是因为层次的问题，最终就是绕一公里到达楼上，在一个地铁，上面是居民区，下面是地铁空间。

然后，另外一个空间相似性聚类，这个聚类涉及到我们真正地去为无论是营销发券，还是做地推活动，这个都是非常相似的。尤其是在北京楼宇里面，等电梯的时间就是非常长的。另外，就是两个模式，贪吃蛇和鸡爪模式，这是什么意思呢？贪食蛇就是取送，送完之后正好是取，然后在接着送。鸡爪模式，是商户比较的集中，会把身上的单集中取，然后就是一个方向，或者角度相似的方向去送，这是一个鸡爪模式。这是在空间上的一个识别。

另外一个就是时间，就是往上面一个图可以看到生命的一个周期，时间就是商户出餐时间，这个其实是一个商户画像的一个特征。我定餐了以后大概多长时间出餐，让骑士过去。另外，就是等用户的时间。还有骑士到店，时间预估，然后就是这个单配送过程中，依赖于导航距离是否够用，还有现在所用的交通工具，骑士在电动车，摩托车，还有一些是地铁配送的一些情况下，实际上差距非常大；另外就是时间的商圈压力，我会预估接下来压力非常大，接下来骑士怎么做一个最优，在恶劣条件下，当你的商圈压力非常大的情况下，基本上不会在考虑用户是否可以准时吃到餐，你考虑的是什么？是骑士能否可以走最近最少距离送完剩下的单。所以，在最优解、不同场景下是什么呢？你满足的是什么？你满足的是骑士的体验，可以保留更多的电量送下午的单；还是在用户体验上，尽快让用户拿到他想要的单。

还有就是空驶调度，两个高峰以外，下午茶和早上，应该让骑士在哪蹲点，这都是在时间上预测接下来会发生什么。

看下画像特征在外卖智能调度的应用。

这就是简列的图，这就是我们的商圈配送，刚刚就是商家下面的骑士。我们现在看到的就是一个商圈，因为涉及到这个画像，到底是在智能调度的场景下是怎么来应用的。我们在30秒会做一轮的配送、计算。计算所有非分的单，有的是计算好，但还没有分配给骑士的单，另外是在这新一个周期里用户新下的单，这都是待分配的单，然后还有骑士身上未取餐的订单，商圈压力、还有骑士画像、用户画像，用户画像这边更多的会用到，用户是不是VIP用户，还有一些POI的画像，这些拿到之后，我们会进行一个订单和骑士的打分矩阵，这时候涉及到你的哪些变量得多少分的问题，最终会得到一个打分矩阵，这个矩阵，我们首先会做追单，合适的订单会先追单，不合适的订单会在订单池等待，如果能追上就会更新骑士的任务，把任务模式进行更新，最终结束了。另外一个就是如果没法追单，就看有没有到下一个周期的时间，如果到时间了，就看非配订单的集合，做订单相似性的处理，相似性由哪些因素决定：商家比较就近，用户就近，时间相仿，客价等等。另外VIP的单是不需要等的，会直接分配。再就是，我们根据相似性，会把订单进行分组，然后会做一个订单组和骑士之间的打分矩阵。还有一些强制指派的，比如骑士身上没有单了，虽然不合适，距离非常远，也需要把骑士调过来，进行订单分配，这是一个强制指派。再一个就是用户的时间，压得非常短，比如说还有30分钟，如果还不指派，就会超时，这种情况下，也会增加强制指派。最终订单池和骑士会有个打分矩阵。

这个就涉及到有什么变量，最后得多少分。这个是什么局面？我们首先做的什么？首先就做追单，追单什么概念？比如说，骑士现在是那个，店在这个位置，用户也都是在一个小区，尽量先追单，合适的单尽量追出去，不合适就是什么呢？如果可以追上就追，就把导航模式进行更新，最终就结束了。另外一个，如果没有办法追单，没有办法追单，就看一下有没有到时间？就是到下午的时间，如果到了时间，就看一下那个定单的集合，做定单相似性的那个。如果一个平均35，一个是100多的，他们那个有多少呢？但是，这个就在那个单上可能差的比较的远，这个相似性计算涉及到的非常的多。另外一个，就是用户画像，就是VIP这个部分，就是不需要大家弄的。另外一个，就是我们根据相似性就把定单做一个分组，定单分组了以后，就跟骑士做一个定单组，还有和骑士之间一个打分矩阵。然后，在计算定单相似性的时候会考虑这些因素，然后，下面还有一些什么呢？比如说，骑士身上没有单了，虽然不合适，距离非常远，需要把这个调度回来，然后进行一个定单的分配。这里我们会用到Km算法计算订单组与骑士最大权匹配。还有一个可能就是如果骑士身上的订单非常多的时候，或者暴单的情况下，这个时候再用Km计算，压力会非常大，在30秒之内算完全国这种几亿或者几千亿的场景，基本上算不过来，所以除了Km之外，我们还有一个模拟退口的算法应用，这时候我们会关联到相应的骑士，观察骑士身上的单是否完成，如果没有完成就放到候选队列里，当骑士身上的单完成时，会把候选队列里的单给骑士， 候选队列还有个被清空的策略，如果自动计算时间也就是下一轮计算又开始了，这时会把候选队列清空，重新计算，所有订单会回到订单池里。这就是一个比较简版的商圈的一个计算。这就是一个时空最优解的策略模型，我们要考虑的因素有：订单相似性分组、商圈压力曲线预估、出餐时间预估、餐等人时间预估、用户画像因子、空驶调度策略、远近单并单逻辑、最佳分配时机、骑手能力画像等。这是画像相关的在外卖的一些应用。 

我们大概过一下这个简单的过程，比如说路径规划，就是取送规则什么样子的，看一下这个贪吃蛇，是这样的，骑士身上三单在这里，取然后送，又取又送，取取送送，这是一个贪吃蛇的模式，这个有什么弊端呢？大家看一下，会有往返。站长是非常反感这种情况，我已经走了然后再回来。当然，这个大家也是了解的，骑士感觉什么呢？就没有那个成就感，走了又回来，走了又回来，右面这个我说一下，骑士在这里。一取三送，接下来又是取，又送。这个是一个什么？这个是贪吃蛇加一个鸡爪的模式。但是，背后就是动态规划，最优配送路径，合理的追单、并单，然后是顺路单，降低整体的配送成本，也就是收益。然后，首先就是满足用户，然后就是骑士的相关的一些体验。这个是一个用户希望的一个时间的TSP求解的问题。另外，就是构建评估模型，然后，给用户的体验，以及配送成本之间进行相应的打分。然后，采用动态规划和模拟退火算法等，求最优解。

这是我们一个任务的模式，也就是路线规划这块儿，很多情况之下，你的时间预估，基本上会完全依赖骑士最终是否按照你的路线去做。比如说，我们组和组之间，判断他们有没有相关性的时候，会判断上一组，最后一个定单送完，和下一组商户的距离是不是相近？但是，如果骑士没有按照我们的配送去做，可能导致我们当时希望他去取得那个定单，或送的定单，最后一个和我预期的不相符。所以，路径规划里面做到一个非常高的可靠性，也就是业务上的可靠性。

然后，路线规划，怎么计算相似性。比如说，考虑的因素，商户的位置，用户的位置，还有出餐时间。

第一个是基于位置考虑。大家想一下，一个商户下面两个用户，我们说是大鹏展翅的模式，这个是非常要命的。对于第一种情况，如果不并单，则送餐距离为0.5+0.5=1公里，如果并单，则送餐距离是0.5+1=1.5公里，即增加了0.5公里；对于第二种情况，如果不并单，则送餐距离为0.5+1.5=2公里，如果并单，则送餐距离0.5+1=1.5公里，即减少了0.5公里。所以，虽然在用户距离相等的情况下，订单方向的不同，配送成本也不同，这样的两个订单的相似度应该有所差异。因此，在计算订单相似度时考虑订单的方向是本次优化的切入点。

 

第二是基于节约成本的考虑。如果是这样一个骑士去送两个用户，就是两个商家和两个用户，我们可以看一下，这个就是分开配送，取餐距离要乘以2，等餐时间也要乘以2，最终送餐就是什么呢？就是AC加上BD，这俩个骑士，这个是分开配送的一个场景，等用户的时间是乘以2。如果合并配送，也就是由一个骑士配送，我们走的取餐路程是乘以1的。然后，接下来就是串起来，从这到这串起来，这个就是实现一个最小的距离，这个公式非常简单。最终，相似性定单能否相似，最主要就是一个分开配送的成本减去一个合并配送的成本，这个里面有非常多的项性来参与，这就是相似性的一个规划。

还有就是并联和分组，相似的订单分在一个组里面，提高并单率，减少配送次数，右面可以看一下不同的颜色代表不同的组。然后，我们的方式，定单分组，就是新单和新单进行一个分组，订单并联就是订单和骑士身上没有取餐的订单进行并联。具体方法就是，计算订单之间的相似度，然后通过聚类或贪心的算法去完成，并联就是遍历骑士，与骑士身上每一组订单计算相似度，并入相似度最高的组。但是，我们在这用贪心算法是这样的，如果是Km取最优的话就不一定，有可能骑士得到的是次优解，而不是最优解，因为他要在一个商圈下，整体得分最高，这样的话不一定选取最合适的骑士。

 

这个图大家看到了，时间预估的话，一般是我们基于定位，其实在O2O也好LBS这样的行业下，基本是非常依赖定位数据。包括像滴滴打车，还有58速运，类似这样的场景，我们依赖精准定位，然后把取送的顺序，也就是任务模式那块，进行相应的安排。之后通过历史数据，离线模型得到相关的一些画像的数据。下面有两个骑士速度预估，一个是取餐和送餐，怎么做到回归拟合。其实速度在很多场景下，一天的变化是有不同的。比如说，他的电量影响因素，这个骑士当前的一个匹配程度，或者当前骑士交通运力的情况，都会对取送速度有影响。很多情况下我们做画像也好，还是做数据分析也好，其实有一个非常片面的一个原因，有些数据你看到的就是一个结果，而不是一个原因。很多分析，可能就是基于这个结果去做了一个原因的分析，有可能场景下是没有办法进行倒推的。

然后时间预估这块儿简单看一下就可以，后面还会讲到画像怎么来做的。基本上就是获取样本，去噪，然后基础特征取，做成组合特征，然后构建，最后在进行组合特征编码，然后各个商户特点，每周几作为一个特征维度，做成一个稀疏矩阵，在工作日和周末场景之下，对于外卖的诉求场景不是一样的，尤其是客单价和订单商户类别，最后就是PCA降维。

模型有俩个，第一是深度学习模型，然后是XGBoost模型，XGBoost求近似解非常快，也避免了过高的时间复杂度，XGBoost更多的是通过不同的维度结合起来，看这个特征是否满足你最后的一个相关性。 

决策模型，如果大家在不同的场景下差异非常大，在我们这就是保证订单不超时的情况下骑士距离最少；对用户来讲，就是要准时，对 于骑士打分，还有菜品质量是否过关；还有一些过程指标是我们非常看重的，比如说并单率，改派率，商圈的压力，还有骑士的空驶距离，他有没有跨商圈，或者说成本的收益，都可以作为一个决策模型，最终的一个考核项。

定单组与骑士打分这个考虑比较多，通过两个用户，两个商户有一个直观感受，骑士位置，时间，还有新定单一个紧急程度。组的单量，这个量非常多的情况之下，还有骑士一些评分，历史接单量，历史接单量在行业里面是什么呢，和程序员差不多，有的人是任劳任怨干的，我们现在招一些95后，相当于享受型的，我们的骑士，他们10点以后下班，再会熟悉附近能够接的一些小区，所以，骑士用这样的方式，别人超时的单都可以给他。这样的骑士是想养家糊口，想多赚钱的。这个场景之下，有很多众包的骑士，中午的时间段进行一些相应的配送，做兼职，都是一些最早在行业里面比较好的骑士，他对于小区状况非常的熟悉，他又干另外一份工作。其实下午4点钟才开始吃饭，否则，基本上这个时间会拖的更晚。有的骑士晚上10点以后才吃第三顿饭。骑士的历史接单量，可以得到一个骑士的画像，他的送餐能力，他的POI熟悉程度，这个都是考虑的一些因素。    

分配方案，通过贪心和KM算法，得到一个最优解，这个在算法里面比较通用的方式。

总结一下，在百度外卖我只是讲了智能调度下面有非常多的商家、用户、POI、骑士、交通

还有商圈，这些画像都是我们在整个调度、营销、或者说渠道分析里面设计到的。

第四个就是最后一节。

先看一下我们的一个架构图，前面小龙讲完了以后，其实在互联网数据处理上大家都是差不多的，无非就是数据怎么获取到，怎么在数据仓库有所运用，最终就在用户的查询交互上都有这样一个场景，我简单过一下。最下面就是原始数据，对外卖来讲，像用户的数据，商户，物流，骑士，还有一些账务的信息，这个都是我们能够参与的这种角色，这都是我们的一些数据。然后下面是一些业务数据库，行为日志，轨迹数据，还有第三方API，还有地图；这些都是比较原始的数据，通过数据的采集器，然后，我们做到数据能够有一个持有，然后，像日志这个都可以去采集，然后，还有一些骑士的轨迹。这些数据拿到之后，数据采集完，我们最终会放到上面的一些组件或者工具生态上面进行解析，就是数据的ETL。 

   

上面这一层就是资源和引擎，大家可以看到，大数据的这个分时调度，这个都是在什么情况之下数据采集，数据ETL转化，整个集群是通过这样来管理整个的计算，包括Spark、Hive还有就是Impala。最终，数据可以被消费，我们不会暴露这些资源层，而是通过这些引擎。像Impala、HBase、还有ES、Druid、Spark对外提供，他们提供完之后，得到的是什么呢？得到的是一个事实的标签，这里没有太多的机器学习和数据挖掘。

再往上就是一个建模的分析，他要产生的是模型的一个标签，我们称之为挖掘平台，通过Spark Streaming、MLab这样一些模型，还有算法的一些生态，我们产生上面的一些模型的标签。

深度挖掘学习的话，我们在用TensorFlow，当然还有一个ID-Mapping，ID-Mapping是做用户画像的，我们用到的数据多元，一个自然人的识别。

上面是不同的应用层去用，我们这有风控，还有智能调度，营销，还有渠道等。因为画像这个层面，想达到经济化，做到千人千识，都是经济化、思维定制的一个过程。

预测是辅助平台，比如我们的时光机，时光机是用来当一套新的策略生成之后，我用真实的数据去跑，新的策略去看下接下来的变化情况，真正去跑的话是通过仿真系统，还有加速器，加速器是什么意思呢，相当于我去回到历史，去改变历史，然后用现在去看历史，有点绕，比如说我要拿到历史真实的数据，换成我新的策略，最终我要看下新的策略之后接下来发生的事情。这是我们在开发过程中的一个加速器，还有相关的评测，大家做策略算法的话都会有这样的一个模型。还有线上小流量。是基于基于访真情况之下有一些偏差，想尽快得到真实的验证，可以通过小流量去做。

所以，如果想做一个画像的话要从需求开始来，也就是我事实的标签，在低成本情况下通过多角度，多层次做到比较丰富的呈现。模型化的标签要定制化去做，比如之前图里的标签都是业务方有具体的需求。比如说，商户的画像，他的出餐时间的预估，他就就是非常模型化标签的一个定制。不要为了画像而画像，一切从实际的解决业务场景出发，另外画像数据也是有假的。在我们真实的骑士的世界里，也是有假数据的，他为了完成指标，会提前点送达，最终我们的数据在画像的数据层面上会是一个假的。这时候要靠线下的辅助纠偏。

采集，像日志的采集，通过Flume，我们分装用的是Pids，主要保证数据不重复。我们从上游来保证各种数据的不丢，Binlog是采集，通过TR方式去采集。数据库的话我们是通过Sqoop的方式，还有些网页的抓取，API的对接，还后是数据托管，能够让其他业务方的同学，而不是我们这些资深的同学去用，比如说业务分析的同学剩下了很多用户做短信的营销，这时候通过大数据系统是没办法单独给他做的，这时候就要用到数据托管。

要满足用户画像可以拿到的数据源，从数据采集就要满足数据的生命周期，我们称之为数据的人生哲学问题，就是数据从那里来，他要到哪里去，数据是做什么用的，都在我们的数据集市里有所展示。然后离线和实时的，在我们的场景下，用户场景下点餐可能用到，一个用户他想吃什么是不固定的，但是用户检索了什么或者浏览了什么，接下来类似的场景的推荐，这样的一个诉求。还有些数据属于结构化的非结构化的，还有一些异常、脏数据的过滤都在数据采集层可以做。 

数据ETL，是从数据采集，到最终交付数据，到数据仓库的整个一个桥梁，他可以使用刚才提到的大数据分布式调度。最小力是在度字段级别这样的一个依赖分析，如果想做用户，尤其是风控方向，ID-Mapping一个自然人的识别，确实非常的一个过程。另外就是在入数据仓库前要做好数据的主题域，最主要是用来做MLab分析，然后ETL经常要做通用化、平台化这样一个解决方案，通过集群来完善数据的消化能力，这里面会有不同的选型。集群的消化能力，跟你自身业务场景是有很大的关系的。然后，ETL过程当中对数据进行Check和交付，这是ETL过程当中要完善的一个过程。

事实标签很多程度上，是通过统计方式SQL去进行交付，数据分布情况都可以通过方差，T分布，这都是最初能过借助于工具来完成数据的一个分析，然后通过引擎进行交付，前端是通过Adhoc，服务端是通过Adhoc接口，也可以通过UDF的方式，UDF在Impala和Hive上用的比较多，然后数据集市是在整个数据资产上，也就是解决第二数据哲学问题，就是数据是什么，他用来做什么的，就是在数据集市里面，他是在某个主题下面建立了维度，还是作为指标的一个计算项，这就是数据集市里面要展示的内容。

模型标签，这些都是比较通用，就从特征的提取，特征的清晰，特征值的处理，选择。最后再做一个特征的组合，通过降维处理之后，给到具体的一个产出，无论到数据仓库还是给到第三方的应用。最后，我们通过一些监控和量化的方式，来鉴别当前我们这样的一些标签是否符合预期，是否是真的符合事实。

好，今天的分享就到这里，谢谢大家。

如需PPT请关注“DataFunTalk”公众号，私信小编。

金猿榜往期的获奖名单，将会在峰会现场隆重发布，期待你们的身影?