建站
咨詢
售后
建站咨詢
新聞中心
【稿件】如果讓你從 0 組建一個智能化派單系統(tǒng)，日訂單量為 40W，你敢接單嗎?你會怎么做?
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了十堰免費建站歡迎大家使用！
做過的人都會說簡單，沒有做過的人卻連想都不敢想，其實技術(shù)上并沒有太大的差距，差就差在“做過一次”的經(jīng)驗。
聽別人講述自己的經(jīng)歷，也是積攢經(jīng)驗的一種好方法。我們曾邀請快狗打車高級經(jīng)理胡顯波講述他的職業(yè)生涯，他講述了快狗打車的派單系統(tǒng)從 0 到智能化的演進(jìn)。
下面是整理的文字版，希望您看了能有所啟發(fā)。
石器時代
單一拆分?jǐn)?shù)據(jù)庫、業(yè)務(wù)解耦
由于快狗打車是 58 同城當(dāng)時孵化的 N 個業(yè)務(wù)線之一，并且短短三周就已上線，最初的版本包含了用戶側(cè) App、商家 App、管理后臺三個模塊。
上圖所示的是業(yè)務(wù)孵化期整體系統(tǒng)架構(gòu)，采用的是的單一數(shù)據(jù)庫模式，與其他業(yè)務(wù)公用數(shù)據(jù)庫，節(jié)省成本，這樣做是為了快速驗證市場對業(yè)務(wù)接受度。
上圖所示是業(yè)務(wù)孵化期的派單系統(tǒng)，可以理解為一個單元運作。系統(tǒng)核心部分是 OrderPushJar，訂單創(chuàng)建、推送等派單邏輯都在這里進(jìn)行處理。
這個階段訂單調(diào)度原理很簡單，就是由推送框架 MQTT，把訂單推送給設(shè)定范圍內(nèi)所有司機，司機憑手速接單，單單都有補貼旨在快速搶占市場，這對平臺而言是龐大的浪費。
快狗打車上線之后，市場反響非常好，業(yè)務(wù)也在短短三個月增長了一萬單。但此時數(shù)據(jù)庫達(dá)到瓶頸，字段冗余、數(shù)據(jù)庫索引有效性等問題凸顯，沒辦法支持多業(yè)務(wù)的發(fā)展，某個子業(yè)務(wù)做上線下線等操作時，“同源”業(yè)務(wù)也會受到影響。
上圖是針對數(shù)據(jù)庫瓶頸的解決方案，把快狗打車的數(shù)據(jù)庫，從耦合的業(yè)務(wù)數(shù)據(jù)庫中拆分出來。方案中采用雙向同步模式來業(yè)務(wù)不停服的情況下進(jìn)行數(shù)據(jù)遷移。
整體遷移后，快狗打車整體系統(tǒng)大致分成訂單、結(jié)算、配置、軌跡等模塊，每一個模塊都有對應(yīng)單獨數(shù)據(jù)庫，這樣就很好的避免了業(yè)務(wù)之間的耦合，軌跡服務(wù)數(shù)據(jù)庫出現(xiàn)異常，并不會影響其他業(yè)務(wù)流程。
鐵器時代
雙推送通道、象限推送
2015 年，快狗打車進(jìn)入高速發(fā)展階段，市面上也出現(xiàn)了很多同類競品，如藍(lán)犀牛、1 號貨的及云鳥等。市場爭奪戰(zhàn)進(jìn)入白熱化階段，快狗打車采用大量訂單補貼的方式來提升市場占有率，產(chǎn)品方面也是爭分奪秒的進(jìn)行迭代，搶占市場先機。
上圖是業(yè)務(wù)高速發(fā)展時期的系統(tǒng)架構(gòu)。App、PC 及其他第三方渠道進(jìn)入到 OrderCenterServer(訂單中心)，OrderCenterServer 會根據(jù)具體職責(zé)進(jìn)入業(yè)務(wù)的模塊化，分成了像結(jié)算、支付、推送、司機任務(wù)等模塊。
為保證訂單能夠盡快被司機接收到以及保證消息推送到達(dá)率，快狗打車采用自研 TCP 通道與 GeTui 和 MiPush 等三方通道相結(jié)合。根據(jù)司機的手機品牌擇優(yōu)選擇 GeTui 或 MiPush 通道，加上自研的 TCP 通道，保證消息的到達(dá)率。
這個階段訂單調(diào)度原是按照不同的象限方式進(jìn)行予以推送，訂單產(chǎn)生時會先在附近 X 公里范圍之內(nèi)，尋找滿足該需求的司機，進(jìn)行推單。如果無人搶單便加部分補貼，激發(fā)司機的搶單意愿。
如上圖所示，會采用象限推送的模式，如果沒人搶單，就增加部分補貼，延象限進(jìn)行推送，如果搶單人數(shù)達(dá)到一定上限，就回降低部分補貼。
在指派司機的環(huán)節(jié)，根據(jù)搶單司機的距離、好評率、歷史訂單完成率等核心評估指標(biāo)進(jìn)行擇優(yōu)指派，這種簡單的方法既減少了平臺派發(fā)無效補貼的浪費，又有效避免了憑速度搶單的惡意競爭，進(jìn)而提升了整個平臺的訂單完成率。
智能時代
大數(shù)據(jù)平臺引入到智能化
2016 年，快狗打車成為行業(yè)佼佼者，進(jìn)入了平穩(wěn)期，這時更多考慮的是平臺補貼如何高效，起到真正補貼的作用、如何盡量滿足用戶的需求、如何分配司機的收益。
進(jìn)而效率提升成為這一年的整體目標(biāo)，主要做了引入大數(shù)據(jù)平臺、智能派單算法和智能分流框架等內(nèi)容。
第一步：數(shù)據(jù)收集
如上圖，App 用戶使用數(shù)據(jù)、H5 端日志操作，Server 端用戶請求日志等數(shù)據(jù)進(jìn)行收集并通過日志中心組進(jìn)行上報，匯集到日志中心，利用 Flume 和 Kafka 同步到大數(shù)據(jù)平臺。DB 則是通過 DTS 和 Canal 形式，也引入到大數(shù)據(jù)平臺。
第二步：智能模型訓(xùn)練
如上圖，是智能模型的訓(xùn)練邏輯。最底層是收集信息：
- 訂單的信息，包括：始發(fā)地、目的地、以及價格。
- 用戶的信息，包括：用戶位置、以及對于價格的敏感度。
- 司機的信息，包括：接單的意愿等。
- 客戶和司機的關(guān)系信息，包括：兩者能夠相匹配的標(biāo)準(zhǔn)。
- 整體訂單的推送和接單場景等信息。
憑借著歸一化&分桶、XGBoost、特征組合、編碼等大數(shù)據(jù)手段，進(jìn)行模型訓(xùn)練，目前擁有約 80 萬的數(shù)據(jù)模型用于整體的業(yè)務(wù)流程。
接下來，通過具體場景來詮釋大數(shù)據(jù)的智能化派單系統(tǒng)的應(yīng)用，涉及主要場景有計價、推單、中單等。
場景一：計價
先分享計價場景，是因為無論是打車用戶還是司機，對于價格都是很敏感的。
具體說來：用戶先上來詢價，根據(jù)詢價信息給予用戶一定的優(yōu)惠 A 元，同時也要據(jù)此來補貼司機 B 元，另外，在定價 C 元的基礎(chǔ)上，快狗打車還要通過一定的抽傭 D 元，來保證平臺的運營。
那么該如何計算 ABCD 之間的關(guān)系呢?顯然，在保證整體搶單率的情況下，應(yīng)使得 A 和 B 盡可能的小。
也就是說，在盡量降低平臺補貼的前提下，根據(jù)給定補貼的預(yù)算情況，來提高搶單率。
根據(jù)上述兩個計價模型，不難發(fā)現(xiàn)：為了保證訂單的完成率，至少要保證兩個司機的搶單：通過對司機和用戶的行為分析，要掌握司機對于訂單大致的接受價位;同時，也會通過整體的接單司機數(shù)量，來反過來驗證該模型的有效性。
上述優(yōu)惠模型是分析用戶流失率的手段。根據(jù)用戶每天的活躍度，訂單價值貢獻(xiàn)等，能夠獲悉：可能由于某些原因，用戶存在流失的風(fēng)險，就應(yīng)該通過平臺發(fā)券的方式將他刺激用戶的回流。
場景二：推單
上圖是一個接單的場景。把訂單推送給愿意接單的司機，既能降低用戶的等待時間、提升用戶的滿意度，又能通過訂單的成單率，來提升司機的興趣度。
那么司機的接單意愿又是從何而來呢?其中包括：訂單與司機之間的距離、訂單的價格、小費&補貼、以及起點&終點等方面。
平臺通過大規(guī)模的邏輯回歸，可以計算出附近司機的接單意愿，進(jìn)而推送給相應(yīng)的司機。
場景三:中單
在中單場景中，如果有 50 位司機搶單，那么哪位司機的好評率、距離、服務(wù)態(tài)度、以及是否愿意免費搬運等策略最為切合，誰就能夠“中簽”。
此處的服務(wù)模型相對較為簡單，主要涉及到距離、等級、評分、耦合度等指標(biāo)。
為了防止一些假司機來擾亂平臺秩序，快狗打車通過：設(shè)備交叉、訂單軌跡、客司金額分配、以及虛擬識別等手段，來識別訂單中的作弊概率。如果發(fā)現(xiàn)有作弊的訂單，平臺會對用戶和司機予以懲罰。
場景四：整體運營
如上圖，是整體運用場景。
- 在用戶下單時，快狗打車運用訂單的定價模型，來確定用戶是否需要調(diào)價、優(yōu)惠、或是補貼。
- 在系統(tǒng)推送時，快狗打車預(yù)測司機的接單意愿，以及推送的順序。
- 在司機搶單時，快狗打車預(yù)測整體的接單人數(shù)，一旦人數(shù)到達(dá)上限，就會通過降低訂單補貼等方式進(jìn)行動態(tài)微調(diào)。
- 在訂單指派時，快狗打車也會預(yù)測司機的完成概率，并獲取司機的質(zhì)量度。
- 在訂單完成后，快狗打車會預(yù)測用戶是否流失，并根據(jù)其留存價值，來確定是否給他更多的優(yōu)惠。
上圖展示的是整體派單側(cè)的架構(gòu)。核心在于策略應(yīng)用服務(wù)側(cè)、通用邏輯服務(wù)層，以及底層數(shù)據(jù)服務(wù)側(cè)的劃分。
上圖展示的是智能派單的核心流程。左側(cè)的核心模塊是特征數(shù)據(jù)，它經(jīng)由數(shù)據(jù)的收集與訓(xùn)練，得到相應(yīng)的特征數(shù)據(jù)值。通過特征匹配系統(tǒng)，將數(shù)據(jù)應(yīng)用到整體的業(yè)務(wù)系統(tǒng)中。同時這里的訂單隊列引擎和司機隊列引擎，根據(jù)訂單狀態(tài)的實時變化，將訂單推送給司機。
另外，通過業(yè)務(wù)監(jiān)督平臺，來保證新的模型、或算法在上線時得到相應(yīng)的分流與監(jiān)測。具體而言，根據(jù)用戶的設(shè)備特點，來模擬流量的分配，進(jìn)而實時地得到數(shù)據(jù)上報。
例如：用戶是否僅在詢價階段完成后就流失了。倘若流失率較高的話，就會通過實時報告將線上新的分流設(shè)置關(guān)閉掉。
接下來分享快狗打車的的監(jiān)控平臺，具體的定義如下三點：
- 算法需要穩(wěn)定的系統(tǒng)支撐
- 業(yè)務(wù)的波動要第一時間知悉
- 提高問題排查效率就是在挽回?fù)p失
如上圖，是快狗打車側(cè)立體化監(jiān)控部分截屏，涉及關(guān)鍵字監(jiān)控、接口監(jiān)控、流量，端口、JVM、CPU，線程、緩存、DB 等監(jiān)控。
業(yè)務(wù)指標(biāo)監(jiān)控包含訂單整體波動以及補貼整體波動等。訂單波動就是對附近平均司機數(shù)量，推單波動進(jìn)行監(jiān)控。補貼波動就是對用戶和司機的補貼實時投放的數(shù)據(jù)進(jìn)行監(jiān)控。這些核心業(yè)務(wù)指標(biāo)監(jiān)控需要做到實時反饋，有波動第一時間告警。
如果優(yōu)惠券訂單數(shù)為什么突然間在暴漲?補貼訂單數(shù)為什么突然之間下降?等等這些核心業(yè)務(wù)指標(biāo)監(jiān)控需要做到實時反饋。
總結(jié)
2014 年至今，一路走來快狗打車團隊不斷壯大，業(yè)務(wù)也是不斷地迭代和優(yōu)化，最后總結(jié)如下幾點：
- 架構(gòu)與團隊、業(yè)務(wù)對齊，保持服務(wù)的持續(xù)演進(jìn)，以響應(yīng)業(yè)務(wù)的快速變化
- 建議使用雙推送通道，保證推送的到達(dá)率
- 監(jiān)控很重要，第一時間發(fā)現(xiàn)問題，減少影響
- 持續(xù)提升，團隊的能力，要跟得上業(yè)務(wù)的節(jié)奏
【原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為.com】
本文標(biāo)題：如何從0組建一個日訂單40萬的智能化派單系統(tǒng)？
文章源于：http://www.5511xx.com/article/cdeiepc.html
