本文根據百度外賣首席架構師梁福坤先生在2018年DataFun大資料架構系列活動——大資料架構在O2O場景中的應用所作分享《畫像在外賣智能排程的實踐》編輯整理而來，在未改變原意的基礎上略作删減。梁福坤先生在業内有10年+的從業經驗，百度do.baidu.com大資料平台的創始人，目前負責百度外賣大資料平台+智能物流政策方向。
導讀：今天給大家分享的是畫像，畫像在我們百度外賣智能排程的一些實踐。我基本是分這樣四個場景，第一個是外賣的O2O場景介紹；第二，就是百度外賣智能排程面臨的時空問題；第三個就是畫像特征在外賣智能排程的應用；第四個就是一個實踐。
--
01
外賣的O2O場景介紹
因為今天的主題是在O2O的一些相關服務，我們介紹一下在外賣這個場景下是一個什麼場景。剛剛我統計了一下，大家都用過外賣，我們打開相應APP，還有其他的一些方式，最早的就是在頁面或者H5或者百度地圖、糯米，都可以用到百度外賣，現在我們隸屬于餓了嗎，拉紮斯集團，通過他們的APP，我們一起提供O2O孵化的場景。左側是進來後的場景，右側就是下單，下單之後我們看到了一些控制台，在這可以看到，每個單來了之後有沒有被分出去，有沒有被商戶接單，還有一些預期，距離使用者期望時間的一些時間；這個地方是一個騎士的軌迹情況，針對個人APP，我們可以看到一些騎士的軌迹，有可能會越來越遠，或者距離一公裡，但是一直沒有配送，其實在控制台可以看到他身上有一些其他的任務。這些具體排程的一些政策都是通過我們後端智能排程的一些服務。
外賣，其實大家最了解的場景就是送便當，但是現在針對外賣場景有非常大的不同，比如說從傳統的餐飲到新零售，就是水果生鮮都可以通過外賣進行預定，包括商超、醫藥、鮮花，蛋糕，五金，電器等等生活服務類場景都可以進行相應的配送。同時，我們的預定模式也從最初的訂餐，商家進行配送，我們後期有相應的預訂支援。
像萬能跑腿，對于個人來講類似于閃送一個場景，可以幫你買東西，或者取東西。
另外就是全城配送，有很多的商戶，他可以覆寫城市的每一個角度，像在北京五環之内都可以覆寫到，他想去嘗試本地化服務，做了一個這樣的場景，是以我們的全城配送在很多場景下，比如說像水果生鮮、鮮花蛋糕這樣類似的産品都可以以全城送這樣的方式進行支援，
還有一些落地配，落地配主要是在和快遞行業進行時間上的錯峰，對于騎士來說高峰就是午餐和晚餐，但是對于快遞來講就是點餐之前的時間可以做到落地配；還有就是準時達，可以購買相應的增值服務，我可以做到時間上優先的保證；還有專人專送和衆包業務等。
這都是在外賣場景之上進行綜合，我們去把整個場景化做得更細，（右圖）這些都是對外的一些直覺感受。
外賣場景就有兩個比較大的高峰期，午高峰和晚高峰；其他的時候，比如在宵夜的時候，還有下午茶，都是逐漸彌補的一個空間；但是對于使用者來講有一個适應，或者說能夠滿足通過外賣的方式點下午茶或者點宵夜。
上面是訂單的一個周期，下面是我們的一個服務接口相關的一個實時的動态。白天的時候就是交易比較集中的就是兩大高峰，兩大角色參與，就是商家和使用者，是兩個最主要的參與者。但是，這兩個角色互動了以後，多個角色參與什麼意思呢？在我們外賣的場景下，其實想做一個通過溝通層面、算法層面達到一個最優解的情況下，我們變量參與得越少，你能夠比較快、比較準的達到一個最優解，當你角色參與的越來越多，比如說我們角色有哪些呢？像騎士這個角色，交通的情況，天氣的情況，這些都是在你下完單之後，我們在履約完成都會在裡面參與其中；尤其是惡劣天氣，大家都會感同身受，無論是配送的難度，還是等餐的時長，都會在整個決策中受到很大的影響。
另外一個，就是履約流程比較長，從下完單，其實感覺到就是商務出餐，但是背後一些财務的、營銷的、翹單等。
交易非常的複雜，時效性非常高；你如果是一個打車行業，可能就是叫個計程車，在進行距離召回進行相應司機的指派，或者司機的搶單；如果是共享單車這種情況，就需要你去主動到達服務這個點，接下來由你來操控最終到達，然後履約整個鍊條的完成；對于外賣來講，基本上你在觸達手機下單之後，所有的事情都不需要你來做，隻需要你來取餐就行了。
這是一個外賣訂單的生命周期，大家可以看一下。我先說一下，從這裡下單，這個是使用者決策參，。下面就是商戶進行接單，接單了以後，然後，騎士就是到店，騎士到店後，會等這個出單時間，像披薩出餐時間就是5分鐘左右，像排骨米飯，大家想象一下幾分鐘？其實排骨飯非常快，隻有有一些配菜在最後一個階段。但是，有一些中式其他一些餐飲，像金百萬，像其他的紅燒肉這種，有一些場景下高峰期出餐速度也是一個瓶頸。
商戶出餐之後，騎士就可以正常配送，進行取餐，對一個訂單來講取餐之後就可以進行送達，然後到達具體的樓宇，或者辦公樓、小區進行傳遞，可能還有等待使用者下來取餐，這樣一個過程，這是一個訂單整個的一個生命周期。
參與的角色包括使用者，商戶，還有騎士，隐含的是我們下面的一些消費經理BD這樣的一些角色。服務平台，涉及到交易，銷售，營銷，支付和結算，對于商戶來講，他是一個小度掌櫃，對BD來講是Banff這樣一個系統，Banff是用來發現商機，跟使用者進行簽約。整個過程當中風控就在無時無刻地進行介入，訂單是否屬于違約或者屬于刷單這樣的情況，還有一些營運體系。
接下來就是一些營銷，怎麼可以把流量導入進來，把使用者留住，最終提升一些轉化或者回頭客。履約的外部因素就是交通天氣，像樓梯的高度，還有一些小區騎士沒有辦法直接進入，需要步行，還有一些小區，不允許騎士進入，需要等待學生到校門口取餐這樣非常複雜的一個過程。另外對騎士來講，對POI、AOI這樣一個點或者面，有一個熟悉程度。在騎士的心目當中有一個地理次元、導航，他都是有這樣的一個人為的畫像。
--
02
外賣智能排程的時空問題
然後是外賣面臨的一個時空問題。
然後，在去年的時候，這個都是在朋友圈刷遍了，谷歌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位址，就是因為層次的問題，最終就是繞一公裡到達樓上，在一個地鐵，上面是居民區，下面是地鐵空間。
然後，另外一個空間相似性聚類，這個聚類涉及到我們真正地去為無論是營銷發券，還是做地推活動，這個都是非常相似的。尤其是在北京樓宇裡面，等電梯的時間就是非常長的。另外，就是兩個模式，貪吃蛇和雞爪模式，這是什麼意思呢？貪食蛇就是取送，送完之後正好是取，然後在接着送。雞爪模式，是商戶比較的集中，會把身上的單集中取，然後就是一個方向，或者角度相似的方向去送，這是一個雞爪模式。這是在空間上的一個識别。
另外一個就是時間，就是往上面一個圖可以看到生命的一個周期，時間就是商戶出餐時間，這個其實是一個商戶畫像的一個特征。我定餐了以後大概多長時間出餐，讓騎士過去。另外，就是等使用者的時間。還有騎士到店，時間預估，然後就是這個單配送過程中，依賴于導航距離是否夠用，還有現在所用的交通工具，騎士在電動車，機車，還有一些是地鐵配送的一些情況下，實際上差距非常大；另外就是時間的商圈壓力，我會預估接下來壓力非常大，接下來騎士怎麼做一個最優，在惡劣條件下，當你的商圈壓力非常大的情況下，基本上不會在考慮使用者是否可以準時吃到餐，你考慮的是什麼？是騎士能否可以走最近最少距離送完剩下的單。是以，在最優解、不同場景下是什麼呢？你滿足的是什麼？你滿足的是騎士的體驗，可以保留更多的電量送下午的單；還是在使用者體驗上，盡快讓使用者拿到他想要的單。
還有就是空駛排程，兩個高峰以外，下午茶和早上，應該讓騎士在哪蹲點，這都是在時間上預測接下來會發生什麼。
--
03
畫像特征在外賣智能排程的應用
這就是簡列的圖，這就是我們的商圈配送，剛剛就是商家下面的騎士。我們現在看到的就是一個商圈，因為涉及到這個畫像，到底是在智能排程的場景下是怎麼來應用的。
我們在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、騎士、交通
還有商圈，這些畫像都是我們在整個排程、營銷、或者說管道分析裡面設計到的。
--
04
畫像模型實踐
先看一下我們的一個架構圖，前面小龍講完了以後，其實在網際網路資料處理上大家都是差不多的，無非就是資料怎麼擷取到，怎麼在資料倉庫有所運用，最終就在使用者的查詢互動上都有這樣一個場景，我簡單過一下。最下面就是原始資料，對外賣來講，像使用者的資料，商戶，物流，騎士，還有一些賬務的資訊，這個都是我們能夠參與的這種角色，這都是我們的一些資料。然後下面是一些業務資料庫，行為日志，軌迹資料，還有第三方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上用的比較多，然後資料集市是在整個資料資産上，也就是解決第二資料哲學問題，就是資料是什麼，他用來做什麼的，就是在資料集市裡面，他是在某個主題下面建立了次元，還是作為名額的一個計算項，這就是資料集市裡面要展示的内容。
模型标簽，這些都是比較通用，就從特征的提取，特征的清晰，特征值的處理，選擇。最後再做一個特征的組合，通過降維處理之後，給到具體的一個産出，無論到資料倉庫還是給到第三方的應用。最後，我們通過一些監控和量化的方式，來鑒别目前我們這樣的一些标簽是否符合預期，是否是真的符合事實。
今天的分享就到這裡，謝謝大家。
01/關于我們
DataFun：專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章800+，百萬+閱讀，14萬+精準粉絲。