大資料在快狗叫車中的應用與實踐

本文根據胡顯波老師在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個司機依舊沒有司機接單，在推送過程中有可能出現了異常，有沒有可能需要進行業務測試。還有優惠波動，優惠單數是否有較大的波動，補貼單數是否和往常不同，是否存在異動，該如何解決，這些都是需要實時監控來發現。

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

三、 總結

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