大數據在快狗打車中的應用與實踐

本文根據胡顯波老師在2018年5月12日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

講師簡介：

胡顯波：快狗打車IT總部高級技術經理，2014年加入58到家，負責快狗打車後端整體業務和架構工作，專註智慧物流以及智能派單領域的探索和創新，有豐富的業務架構和團隊管理經驗。

分享大綱：

一、業務與系統架構簡介

二、大數據應用場景

三、總結

正文：

一、 業務與系統架構簡介

上圖是快狗打車的發展史， 2014年快狗打車服務上線，2015年10月份快狗打車的企業服務板塊上線，2016年平台日訂單突破20萬，2017年與海外同城物流平台GOGOVAN達成合作，建立覆蓋中國及東南亞地區的同城貨運平台，現階段已有超300駐點城市，百萬註冊司機，服務貨運用戶超億次。

上圖是我們的訂單調度系統架構圖、用戶下完單後，進入訂單推送系統，系統會根據大數據分析訂單和用戶信息，來判斷是否需要對該訂單用戶給予優惠、對接收該訂單司機進行補助，判斷完畢進入訂單調度系統，通過距離、接單時間等來匹配最優司機完成。系統中的司機訂單隊列引擎，根據司機的服務質量來進行業務分配，優先服務質量好的司機，以此來正向引導司機為用戶提供高質量服務。

二、 大數據應用場景

在大數據沒有出現之前，我們是如何進行數據分析的呢?初創公司一般是沒有自己大數據服務的，寫個SQL或腳本查詢夠可以滿足需求。隨著業務的快速增長，在原來技術基礎上無法快速解決數據需求了，開始引入大數據平台，進行數據分析整理。通過AI來進行用戶畫像，分析用戶和司機使用習慣，實現高效的訂單推送。

數據來源有很多，首先是APP上的用戶日誌，然後微信、瀏覽器等H5日誌，以及服務Server在計算過程中產生的數據通過日誌，這些數據統一通過日誌組件上傳到日誌中心，在需要數據時由大數據平台抓取並進行分析。資料庫信息我們採用的是阿里DTS同步實時同步。

數據收集之後，該如何應用這些數據呢?在上圖可以看到，我們收集了用戶、司機、訂單等多維度的信息，另外還有用戶與司機關係的信息。

信息收集後會進行特徵處理，歸一化距離、分桶化訂單價格來減少碎片化信息，例如：訂單始發地與司機距離是500米、300米等，統一划分到1000米的範圍，訂單價格是40元、45元等，劃分到價格50的區間內，另外還有訂單始發地與目的地的信息，對它們進行整合，建立相應的交易模型。快狗打車現階段擁有約400萬模型在線上運用。為了保證模型的準確性，模型建立完後，會使用歷史數據進行特徵回歸，測試模型是否符合預期目標，同時對特徵性能進行分流測試，要確保運用新模型後訂單相關指標不會受到影響。

上圖是大數據在計價場景上的應用，首先用戶下單，確定訂單預估價格，我們的用戶群體包含一些小B客戶,對價格比較敏感，他想運貨的話，他會去關注不同平台的價格，他認為我就願意出這麼多錢，哪個平台能給我找個司機，那就選擇哪個平台。

從司機的角度來講，假如司機接了這個訂單，需要先開車去發貨地，拿到貨物後再運到訂單目的地之後返程，在這個過程中他需要考慮在目的地有沒有可能接到別的訂單，考慮自己的時間、油費成本，再有用戶運的一般是體積大或者重量較重的貨物，司機可能需要幫忙搬運，司機也會考慮自己的人力成本。

在貨運領域，北京來說業務範圍一般都是在五環、六環甚至在郊區的地方，訂單目的地如果是比較偏的地方，司機的返程是存在空駛可能的，這個時候平台需要根據訂單的特徵屬性去判定是否給這個訂單一定的補貼，助力訂單的完成。

數據關於演算法的賦能，上圖中的X和Y的差值需要平台計算確定，求A和B的最小值以及對應的C值，這些依賴於大數據對訂單歷史數據的分析和大量計算。平台如何制定價格，可以使用戶下單意願更強，司機的接單率要更高，訂單完成率更高。

在保證用戶活躍度的情況下，如果用戶定價過高，平台一般會給用戶優惠或者針對於用戶特徵進行折扣，讓用戶感受到平台在關注他，增加用戶與平台的粘性。

在2015年，快狗打車拿到第一筆融資後，定下打補貼戰的策略，平台初期給用戶的優惠大概是每單15~20元，給司機的補貼是20~30元。每單的補貼可能在35塊錢左右。按這個策略當時一天能砸出去上百萬、一個月幾千萬，補貼持續了2到3個月，耗費的資金很多，但效果也十分顯著，當時同領域的競爭對手基本都銷聲匿跡了。

到2016年，業務持續增長，公司考慮是否把補貼砍掉，但砍掉之後用戶是否會離開、會不會轉到競爭對手或者轉為黑車。這個論題需要我們逐步去實驗，如何在補貼減少過程中，對業務的影響最小。

首先在歷史特徵數據基礎上建立模型，不斷進行線上實驗，在試點城市進行分流測試，對價值比較高的訂單不給補貼，通過分配訂單減少差單的補貼。司機加入平台是為了收入，司機一天拉黑車的收入大概在200元，如果平台可以保證司機每天收入在200元~300元，司機是願意在沒有補貼的情況下接單的 。

上圖是補貼制定的流程，如果訂單一直處於沒有司機接單的狀態，證明這個訂單可能屬於差單，有可能訂單目的地太過偏遠，運輸的貨物台中，路程耗費時間久，但如果我們能用補貼促使這個訂單完成，這樣補貼才是真正起到了作用。

一般用戶下完訂單後，平台會根據歷史數據去預測搶單司機的數量：分析訂單的相似歷史發單，在這個地點或者附近，哪些司機接了哪些訂單?哪些沒接?為什麼沒接?去預估這個訂單下單後有多少個司機接單。如果預計接單司機有兩個以上，平台就不會進行補貼，如果接單人數少，就會給接這個訂單的司機發放一定的補貼，促使這個訂單的完成。

上圖是優惠模型的流程，互聯網用戶的活躍是存在周期的，從用戶的加入期開始，逐步進入成熟期，之後是衰減期，最終會出現流失的現象。如果平台想要留住用戶就需要進行干預，在用戶的熱度流失時，平台及時給用戶優惠，比如發放優惠券或者推行下單有折扣等活動，用戶持續的保留在平台上的概率會提升。

上圖是訂單推送的流程，在下完訂單後，平台將訂單以一定的演算法規則推給附近的司機，，並不是司機的距離近就先收到訂單，平台會進行擇優選取，比如：3公里以內有100個司機，平台會根據這100個司機歷史訂單完成概率、司機服務水平還有司機是否去過目的地等進行排序，排完序後進行訂單推送，提升訂單的匹配效率，同時降低訂單用戶等待時間。

上圖是接單意願的排序，通過訂單和司機的距離、訂單預估價格、小費補貼、起點終點等這些具體的數據進行大規模的數據回歸，計算出來每一個司機的接單意願，制定推送順序。

上圖是中單場景的應用，比如說訂單推送給了50個司機，可能有10個司機都有接單的意願，這個時候平台會選取一個最有可能完成這個訂單的司機來接單，提升訂單完成率。此外還有司機車型對訂單的匹配度，如果用戶運的是家居，那對車型的要求包括車后座是否拆除、車內空間是否足夠都有需要求，如果司機的車不符，用戶就會取消訂單，降低了訂單的完成率，影響用戶滿意度。

上圖是我們對不同時期用戶的定義，不同時期的用戶採取不同的運營措施來提高用戶與平台的粘性。1)留存期是用戶存在下單行為，但最後一單距當前時間小於1.5乘以用戶單均下單周期。2)沉睡期是超過平常下單周期而沒有下單行為的用戶。3)流失期的用戶可能一段時期沒有下單記錄，但依舊有用車需求，不過可能轉到了線下或者其他平台。面對不通階段的用戶，我們其會採用優惠活動、發放優惠券、發簡訊、廣告的形式來去激活這部分用戶。

還有一個是反作弊的判定，大數據在平台上運用的一部分是進行演算法相關規則的計算，另一部分是收集用戶和司機的信息進行作弊的判定。為防止作弊行為平台需要進行實時監測，首先會在大數據中根據用戶下單的設備、訂單數、歷史下單行為，去判定是不是虛假設備或者惡意下單，同時會根據接單司機的運行軌跡等信息去統一判斷是否有作弊行為、是否對司機或用戶進行相關懲處。

上圖是大數據提取的完整訂單模型，用戶下完單後，判定用戶所在商圈，判斷訂單所在商圈運作力是否充足，這個訂單所在商圈的價格是否能滿足司機需求，如果不相符就觸發調價策略，尤其在假期時商家要備貨，運貨需求比較高，有可能出現司機短缺狀態，平台會進行調價或者通知其他區域司機。

接下來是系統預測司機接單意願，確定推送司機範圍，司機端進行搶單，在搶單過程中動態調整司機補貼，第四步預測訂單完成概率，選擇哪個司機接單更容易將訂單完成，最後訂單完成後，啟動用戶留存模型，預測用戶是否會流失，基於預測結果來確定優惠的發放。

上圖是業務監控的具體分布，首先技術上的業務監控，比如在推單時，如果附近司機的數量和往常司機數量產生比較大的波動，比如原來3公里內有50個司機，但今天只有10個司機，第一點需要排查是否系統存在問題?第二點需要和城市側溝通司機側是否出現什麼變動，這些變動都需要實時的進行報警。

另外一個是訂單的推單波動，比如一個訂單推送時推送50個司機就會有司機接單，今天可能推了100個司機依舊沒有司機接單，在推送過程中有可能出現了異常，有沒有可能需要進行業務測試。還有優惠波動，優惠單數是否有較大的波動，補貼單數是否和往常不同，是否存在異動，該如何解決，這些都是需要實時監控來發現。

最後一個是演算法方面的具體措施，比如平台更新一些新演算法，我們需要監測演算法在線上實際運行的效果，剛開始肯定不能進行全國更新，現在大數據的分析，基本上是一天一分析，如果線上出現了問題，影響是比較嚴重的，所以我們會進行實時儲備，實時數據上報。對新演算法的實驗，採取線上用戶的分流，比如用戶採用的是哪一種演算法，在這種演算法下有沒有下單，訂單有沒有完成，針對這種演算法，我們會去做分流和監測，通過監測產生業務報表，如果這個新演算法在業務上出現規模較大的影響，系統會自動關閉這種演算法，不再進行分流。

三、 總結

最後一句話總結： 一切脫離業務的大數據應用都是耍流氓，希望大家注重業務與數據的結合，不要脫離實際運用場景。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！