寫這篇分析的背景是，工作上正在經歷一個智能調度平臺的搭建和設計，希望通過對于滴滴調度系統進行調研，來得出一些可借鑒的、優秀的設計方案。本質上來講，一個好的調度系統，就是要解決資源最優利用的問題，這個在之前的文章做過簡單的介紹,見《調度系統的數學定義》。
它山之石，可以攻玉。
01 滴滴的智能調度是什么
智能調度是整個滴滴的智能大腦和決策系統。
核心思想是“激活閑置資源、中心調度、高效匹配”。
智能調度結合了大數據與機器學習，搭建滴滴交通和決策大腦，去年成立的滴滴研究院正在從事相關的實驗和研究。滴滴交通大腦需要收集每個城市、每一時刻的所有交通出行相關數據，然后做出最優的決策（匹配、導航等），從而提高出行效率。
02 體現在哪些地方
智能大腦主要滲透到以下各個環節：預測目的地、價格預估、時間預估、最佳路徑匹配、司機和乘客匹配、訂單分派、供需預測、預測乘客體驗。
其中，司機和乘客匹配、訂單分配是滴滴智能調度的核心。訂單分配：在某個時刻有成千上萬的乘客，同時也有成千上萬的空閑車輛，要完成司機和乘客的最優匹配，最大限度提升匹配率和成交率。
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秒鐘發起一次請求），描述整體資源的情況，當用戶發出用車需求后，第一時間根據資源情況，進行訂單推送。
訂單熱力圖：基于對歷史數據的統計并結合實時訂單數據，給出當前全城范圍內訂單密集區域的分布，給司機提供有價值的聽單位置參考，提高聽單概率并減少司機空駛時間。
供需預測：基于海量實時出行數據，以數十億訂單數據和數百萬司機位置信息為基礎，預測任意時間段各個區域的訂單需求和運力分布狀況。
運力調度：基于供需預測結果，大規模有序調動全城所有可用運力，實現資源最優化分配。
智能分單：在司機和乘客的歷史數據中學習接單概率模型，提高司機和乘客的匹配度，利用運力的規模效應實時地從全局上最優化總體交通運輸效率和乘客出行體驗。
