關於滴滴智能調度的分析和思考

來自：https://www.jianshu.com/p/fd80741bb6fd

寫這篇分析的背景是，工做上正在經歷一個智能調度平臺的搭建和設計，但願經過對於滴滴調度系統進行調研，來得出一些可借鑑的、優秀的設計方案。本質上來說，一個好的調度系統，就是要解決資源最優利用的問題，這個在以前的文章作過簡單的介紹,見《調度系統的數學定義》。算法

它山之石，能夠攻玉。架構

01 滴滴的智能調度是什麼機器學習

智能調度是整個滴滴的智能大腦和決策系統。函數

核心思想是「激活閒置資源、中心調度、高效匹配」。學習

智能調度結合了大數據與機器學習，搭建滴滴交通和決策大腦，去年成立的滴滴研究院正在從事相關的實驗和研究。滴滴交通大腦須要收集每一個城市、每一時刻的全部交通出行相關數據，而後作出最優的決策（匹配、導航等），從而提升出行效率。大數據

02 體如今哪些地方優化

智能大腦主要滲透到如下各個環節：預測目的地、價格預估、時間預估、最佳路徑匹配、司機和乘客匹配、訂單分派、供需預測、預測乘客體驗。設計

其中，司機和乘客匹配、訂單分配是滴滴智能調度的核心。訂單分配：在某個時刻有成千上萬的乘客，同時也有成千上萬的空閒車輛，要完成司機和乘客的最優匹配，最大限度提高匹配率和成交率。orm

03 滴滴的調度算法排序

滴滴採用的搶單模式+滴米算法來造成本身的調度算法

首先說明一下搶單模式，相對於單獨派單模式而言，這裏就不得不說一下UBER的派單算法：

Uber使用Google的S2 Geometry Library，S2可以將球體分爲小區cell，每一個小區有一個id，地球大體是一個球形。S2有兩個重要特性：它可以定義每一個cell的分辨率，它能發現須要覆蓋區域的cell。Uber使用3,31平方千米的cell來分片其數據。全部這些讓Uber下降乘客等待時間，司機的額外駕駛以及到達乘客招車點的時間(ETA)，當一個乘客使用Uber會發生什麼？Uber會使用乘客的當時地理位置和S2的面積覆蓋函數來尋找其周圍適配的司機，Uber而後選擇更短的ETA， Uber尋找的不只是可搭載乘客的司機，並且還包括那些正在行駛到目標地可搭順路車的司機。

ETA : 預計達到時間

Uber主打是強制派單模式，旅客經過Uber發出訂單以後，需求會直接推送給某一位司機，若是司機在20秒內接單，則訂單成交。若是20秒後司機仍不接單，那麼系統會再把訂單派給另一位司機，繼續等20秒，這種調度模式的優點是用戶體驗比較好，能夠快速鏈接打車需求和司機端，可是這種調度模式依賴的匹配算法上的技術挑戰會比較高，須要準確匹配「乘客需求－司機供給」的模型，每一個訂單經過算法（包括是否可用、以往評價等因素），決定了司機和車輛的推薦順位，若是不能很好的匹配和推薦，會致使系統轉派指標值大幅上升，可是從目前實際運行效果看，這種調度算法運行還算是不錯的。

與UBER派單模式存在不一樣的是，滴滴採用的是搶單模式，乘客經過滴滴發出一個訂單後，系統會把這個需求推送給多位符合條件的司機，若是全部司機都拒絕後纔會進行第二輪派單。

滴滴的訂單分派模式

這種模式的優點在於一開始就能夠加大範圍的推送給司機，由司機端來進行搶單，對於調度算法的準確性要求不算過高。

可是這帶來了一個問題，如何有效規避司機「挑肥揀瘦」、最大程度讓乘客訂單呼叫都獲得知足，讓乘客得到更好的出行體驗。」滴米「在司機端的體現是一種虛擬積分。對於司機來講，行駛里程多、道路情況好的‘好單’會扣除滴米，而行駛里程較少、道路情況擁堵的「壞單」的司機則會獎勵‘滴米’。若是乘客發出叫車需求，而此時有兩輛車與乘客的距離是同樣的，那麼司機誰的‘滴米’多，就是誰得到這個訂單。因此這種方式嚴格的講是基於搶單模式的一種補充，造成搶單+派單混合模式來調度。

滴米算法：https://www.zhihu.com/question/29953467

04 滴滴專車派單架構

派單架構圖

1. 乘客打車下單到下單隊列，由派單引擎進行消費。

2. 根據匹配因子構建規則匹配相應產品，根據產品下配置的查詢規則從db中按照地理位置索引粗粒度選擇周邊司機，經內存匹配和內存排序匹配司機，進行發單。

3. 司機接單後便可搶單並加入搶單隊列，由派單引擎根據撮合規則進行匹配和排序，對乘客綁定的信用卡進行預受權並通知乘客下單成功。

05 匹配因子

匹配因子

如何權衡訂單是否匹配，合不合適，能夠有多種辦法解決：好比距離和時間上離你最近的司機。固然，權衡訂單問題背後也包含個性化搜索，如個別用戶可能只喜歡某一類車型、某一種類型的司機。尤爲是女性用戶在深夜十一二點，可能對車型和司機的要求比較高，這須要進行個性化匹配。

從乘客的角度，他可能但願本身發出打車指令，以他爲圓心由近到遠的發給司機，可是司機那邊收單時不該該是這樣的。從司機的角度看，他更但願的是先給他推送離他近的單，再是遠一點的單，乘客和司機是兩個圓，須要作比較複雜的匹配。

06 滴滴的業務模型

簡化的業務模型圖

模型能夠作得很是抽象和簡單。好比，你想要打快車去機場，你就是一個需求方，你的需求會發到不少服務者那裏去，服務者會根據特徵進行一些匹配。最基本的特徵是服務能力，若是服務者可以開快車並經過了能力驗證，這個需求就有可能發給他。若是開出租車的也有能力開快車，可是他尚未在平臺上驗證這個能力，就只能開出租車。一我的能夠驗證不少服務，白天能夠開快車，晚上能夠作代駕，作不一樣的事。

服務和需求的匹配是經過計價模型和匹配策略來實現的。發送需求的時候須要選擇計價模型和車的類型。快車和專車服務過程大同小異，可是價格差異很明顯，專車價格會貴不少。經過匹配策略能夠實現各類需求的匹配。例如，選擇了拼車，這個需求會盡可能匹配已經有拼友和順路的車。若是選擇專車，能夠要求這輛車在指定時間來接人，這時候匹配策略會優化傾向這種方式。

滴滴全部的業務基本上都是以這種模式運轉的，全部功能都是核心主幹或者旁路，只要把業務模型抽象出來，基本上就可以知足大部分的業務了。

07 滴滴的系統架構

系統架構圖

滴滴的系統架構分爲四層。

1. 最頂層是用戶應用，每個用戶應用就是一個端，也就是用戶所能看到的入口。

2. 而後是接入層，這是很是傳統的結構，使用了Nginx，還專門作了TCP接入層。

3. 在業務層，Web是很是大的集羣，有很是大的代碼量，只對業務作了分割，有策略引擎、司機調度。

4. 在數據層，有KV集羣、MySQL集羣、任務隊列、特徵存儲。

08 技術上的挑戰

重新聞上看到，今年 4 月份滴滴第一次突破 1000 萬單一天，從籍籍無名到日訂單超過1000萬，滴滴花費了三年半的時間，相比之下，淘寶訂單從零到千萬卻用了八年。

隨着滴滴的體量愈來愈大：訂單量、用戶數、司機數量，天天產生的大數據，這些遠遠超出了人工規則的範疇。車輛的調度與用戶匹配上比想象的更復雜，考慮的維度、複雜性、實時性超越了其餘的行業。

好比如何分配訂單的問題：

1. 人多人少的時候該如何作；

2. 高峯期、平峯期又如何作；

3. 在有需求時須要考慮附近乘客和司機；

4. 拼車時考慮乘客以及順路的乘客；

5. 乘客、司機偏好等等。

這其中的變量和因素太多。同時因爲滴滴數據量特別大，每個乘客不僅是讓一個司機去匹配，而是須要跟周圍上百個司機匹配。在任何一個時刻，滴滴的匹配量高達千萬次以上，在一兩秒鐘完成上千萬次的路徑規劃，這是一項很是大的挑戰。

09 思考

1. 打車平臺真正要解決的就是如何提升匹配效率。滴滴初期可能更靠補貼和地推去搶市場，到了後期，匹配效率的提高是最重要的，只有匹配合適的出行資源，才能讓客戶的需求獲得最大限度的知足。

一樣的，在螞蟻金服客戶服務的智能調度當中，如何讓用戶的需求獲得最準確的匹配和解決，就能最大限度的達成用戶價值。

2. 支撐這套智能調度的能力包括，資源實時管控管控能力——地理信息實時更新（4秒鐘發起一次請求）、訂單熱力圖、供需預測（基於海量實時出行數據，以數十億訂單數據和數百萬司機位置信息爲基礎，預測任意時間段各個區域的訂單需求和運力分佈情況）、運力調度（基於供需預測結果，大規模有序調動全城全部可用運力，實現資源最優化分配）

09 思考

1. 智能調度的核心思想是「激活閒置資源、中心調度、高效匹配」。無論是滴滴的智能調度系統仍是螞蟻金服客戶中心的調度平臺，都是基於這樣的原則進行設計的。

中心調度體如今派單制上，即依據一系列因素算出一個或者一批效率最優解直接派單。

高效匹配其中一個的關鍵點是按需分配，識別用戶的準確需求，並在衆多資源當中匹配到最合適的。

爲了作到高效匹配，滴滴從每日上百萬訂單中積累了大量來自司機和用戶的信息，包括它們的行程路線、行爲習慣、特殊需求等等，除此以外，還有對整個城市交通情況的瞭解，作到提早預測需求，而後確保供應量與將要達到的需求量相匹配，這樣能夠以一個最佳的方式來激活閒置資源。

2. 打車平臺真正要解決的就是如何提升匹配效率。滴滴初期可能更靠補貼和地推去搶市場，到了後期，匹配效率的提高是最重要的，只有匹配合適的出行資源，才能讓客戶的需求獲得最大限度的知足。

一樣的，在螞蟻金服客戶服務的智能調度當中，如何讓用戶的需求獲得最準確的匹配，而且保證相應資源的可用性，解決了這些問題，才能能最大限度的達成用戶價值。

3. 支撐這套智能調度的能力包括：

資源實時管控能力：地理信息實時更新（4秒鐘發起一次請求），描述總體資源的狀況，當用戶發出用車需求後，第一時間根據資源狀況，進行訂單推送。

訂單熱力圖：基於對歷史數據的統計並結合實時訂單數據，給出當前全城範圍內訂單密集區域的分佈，給司機提供有價值的聽單位置參考，提升聽單機率並減小司機空駛時間。

供需預測：基於海量實時出行數據，以數十億訂單數據和數百萬司機位置信息爲基礎，預測任意時間段各個區域的訂單需求和運力分佈情況。

運力調度：基於供需預測結果，大規模有序調動全城全部可用運力，實現資源最優化分配。

智能分單：在司機和乘客的歷史數據中學習接單機率模型，提升司機和乘客的匹配度，利用運力的規模效應實時地從全局上最優化整體交通運輸效率和乘客出行體驗。