閑魚商品選投實時性優化

馬赫是閑魚的選品和投放系統，閑魚業務中多數商品都是孤品即單庫存商品，所以商品的實時變更需要即刻反饋到選品和投放鏈路中，為了滿足業務訴求馬赫設計之初就把實時性作為最重要的技術目標，隨著系統的運行資料的膨脹實時性也遇到了瓶頸，本文將介紹近一年來在提升馬赫實時性上的相關作業，目標是選品實時性延遲控制在秒級別，如果有對馬赫不了解的同學可以回顧公眾號內馬赫相關文章，

選投實時鏈路

馬赫整個選品和投放的程序中資料流轉如下圖所示主要分為三個部分，第一部分是選品資料接入，資料是馬赫選品的根本，資料的實時是整個馬赫流程能有效運轉的基礎，第二部分是選品規則計算，規則計算是馬赫的核心，計算的實時性保證了馬赫能把選品結果同步到各個下游節點，第三部分是商品投放，商品投放是與用戶距離最近的部分，實時的反饋能給用戶帶來更好的體驗，

馬赫實時性性能優化也是從這三部分入手，下面將針優化程序進行詳細介紹，

選品資料實時性能優化

馬赫選品依賴的選品寬表資料，主要由兩類資料構成，一類是商品基礎資料，商品基礎資料指用戶發布的商品資訊包括：商品型別、商品狀態、商品價格、商品描述、商品圖片；該類資料通過訂閱商品資料庫的變更已經實作了實時性，另外一類是基于商品衍生出的統計和預測資料，這類的資料一般都是通過ODPS（阿里內部離線計算平臺）離線計算，產出時間與商品基礎相比大多是天級別或小時級別延遲，該類資料原有的接入方案如下，無論是小時級別延遲還是天級別延遲產出的資料，都是進行統一的處理，每天把所有的資料JOIN到一起后輸出到一個離線資料表中，然后把該資料通過BLINK 和 MetaQ訊息通道與馬赫的資料統一接入層對接，該方案的優點是所有的離線產出資料只需要處理一次方便運維，同時每天一次回流整個程序的資料量可控，缺點也是顯而易見，首先每天匯總資料產出時間取決于上游耗時最長的資料，如果有資料延遲將會影響整個流程的耗時，其次明明是H+1產出的資料卻要等到T+1才可使用，這嚴重影響了選品能力，

問題已經明確那剩下來的就是解法，首先要解決的匯總資料依賴上游最長耗時的問題，常規的解法是匯總資料定時產出，到了定時時間，上游各個節點資料已經產出那么就使用，如果沒有產出就使用上一次產出的資料，最初解決時也確實采用了該方案，該方案會造成部分資料要T+2才可以進入選品寬表，雖然不是很好的解法但是解法簡單，作為過渡方案在馬赫里面也運行了一段時間，下面介紹這個問題馬赫采用的最終解法，如下圖所示：

首先把資料按照產出周期進行分類，H+1產出的資料量級在萬，T+1產出的資料量級在億，對于H+1的資料直接利用BLINK讀取后，利用MetaQ資料通道輸出到資料統一接入層，保證了資料產出即用，對于T+1的資料同樣直接利用BLINK讀取，由于該部分資料過大，如果直接輸出QPS將會達到百萬級別對于下游壓力過大，所以馬赫利用BLINK的滑動視窗的聚合能力，把商品ID作為KEY對視窗內的資料進行聚合，聚合后再輸出到馬赫資料統一接入層，滑動視窗越小那么實時性將會越高，但是同樣系統壓力也會越大，目前馬赫的滑動視窗時間為6個小時，該方案解決了商品演算法和統計資料接入實時性的問題，但整個系統流量增加了4倍，這也是設計系統時候常常糾結的時間成本與空間成本的權衡問題，在本次優化中選擇了用空間換時間并有節制的控制了兩個的平衡，優化后效果從天級別延遲縮短至小時級別，

選品規則計算實時性優化

選品規則計算包含兩個部分一部分是運營創建選品規則時在馬赫選品寬表中運算選并產出結果集稱為離線選品規則執行引擎，另一部分是當商品資訊變更時需要重新計算當前商品命中的選品規則稱為在線選品規則執行引擎，

首先介紹第一部分離線選品規則執行引擎的優化，運營創建的選品規則會映射成SQL在馬赫選品寬表ADB上進行執行，ADB是全索引資料表這里主要是用空間去換時間，但是有一類問題很難解決就是文本的全欄位匹配，舉一個例子選品寬表中有個從商品基本資料表中映射欄位ATTRIBUTE，從名字就不難看出該欄位是當時商品設計中預留出的擴展欄位，其內容以kv對分號分隔的形式進行存盤，運營在進行選品時最終映射到該欄位的規則SQL是用LIKE關鍵字進行在十幾億的資料中檢索在其性能可想而知，所以針對該類欄位做了多值映射即把kv對映射成數字進行存盤，該方案雖然不復雜但是解決了創建規則時商品量計算以及商品預覽的時效性問題不做過多贅述，優化后商品計算從6分鐘級別降至30秒，具體效果如下：

下面介紹第二部分在線規則執行引擎的優化，在線引擎是在BLINK中實作的，商品的變更資訊作為輸入源，在執行引擎中計算出當前商品命中的商品池，把商品和對應命中的商品池作為結果輸出到下游，原有的流程如下所示：

在BLINK中主要完成了馬赫關鍵的MERGE 和 DIFF操作，MERGE是把BLINK記憶體中的資料與輸入進來的資料取欄位上的最大的更新時間戳為最新資料把商品資訊整合，然后把整合后的資料在所有的選品規則上運行，運行結果與上一次結果做對比，篩選出兩次結果不同的資料作為結果輸出這步操作稱為DIFF，這樣做的好處是記憶體存盤商品最新資料減少讀取的IO減少時間消耗，同時輸出結果時只輸出DIFF，減少資料量的傳輸再次節省時間，該方案也有著明顯的弊端整個資料都在記憶體中存盤，如果發生不可預期的例外記憶體中的資料將會丟失，從系統開始運行到優化前從沒有停機過，其中付出的運維成本可想而知，同時不可停機導致系統無法升級和使用新版本的BLINK能力，下面針對不可停機問題進行如下解法：

在BLINK接受到商品資訊時首先從本地拉取資料，如果拉取不到則從商品資訊庫中讀取對應資料，在結果輸出時在輸出原有的資訊同時增加輸出商品資訊與全量的規則命中資訊，作為備份存盤方便停機恢復，其中為了減少存盤空間和資料的IO在傳輸和存盤程序中對資料都進行了壓縮處理，最終方案整個邏輯不是很復雜，復雜的是如何從原有的方案平滑切換到現在的方案，其中涉及到資料同步、資料轉換、資料校對，這里面踩了不少坑，該部分不是本文的重點就不贅述了，最終在解決不可停機的問題同時也升級了BLINK版本，升級后資料延遲從原有的2分鐘降低至2秒，讓整個在線規則引擎運行更快更平穩，

商品投放的實時優化

商品投放是與用戶側距離最近的能力，運營圈選商品后形成商品池，然后利用商品池搭建頁面投放給用戶，在用戶請求時把商品從商品池中召回然后展現給用戶，具體流程如下圖所示，

在這個程序中與馬赫發生深層關系的是在召回的部分，目前馬赫支持搜索召回和演算法召回兩種召回方式，搜索召回中把商品池的實時變更同步給搜索引擎做增量的迭代，天然支持實時召回的能力只需要保證增量的穩定即可；演算法召回利用的是用戶屬性召回相關商品，用戶和商品的關系是T+1產出，這與馬赫場景中強調的實時性相悖，為了解決演算法召回的實時性問題，馬赫做出如下解法：

首先我們看一下召回流程：當接受到一個用戶請求，我們會得到兩個資訊一個是用戶的ID和商品池的ID，首先利用用戶ID查詢用戶與商品關系表進行個性化召回，然后利用商品池的ID查詢選品池與商品關系資料表進行通用性召回，最后把兩部分資料進行去重合并這里統稱為個性召回，召回后的資料JOIN商品與商品池關系表，只保留符合該商品池ID下的商品這里稱為召回過濾，如果此時商品數量滿足召回要求則回傳，如果不滿足召回要求則查詢商品池與商品關系資料表召回的兜底資料這里統稱為兜底召回，通過召回流程后再經過RANK和資訊補充就把資料呈現給用戶了，

上面流程中提到多個資料表，那么這些資料表是如何產出又為什么這么設計下面詳細介紹，首先介紹在個性召回中使用的BE用戶和商品關系資料表的產出邏輯，這部分資料不依賴馬赫的任何資訊，僅僅是通過用戶在閑魚的點擊瀏覽等用戶偏好行為對用戶喜歡的商品進行預測，每個用戶相關商品規模在2000個是T+1產出，然后介紹個性召回中使用的BE選品池和商品關系資料，這部分資料是依賴馬赫離線引擎同步產出的，這里的產出邏輯是首先根據各項指標對選品池中的商品進行排序，排序后保留前5000個作為通用召回是T+1產出，使用依賴這兩個表完成了個性召回步驟，然后是召回過濾中BE商品與選品池關系資料，這部分資料是利用在線同步引擎實時更新的，之所以設計這步召回過濾是為了防止個性召回的T+1的商品，當前已經不在商品池中了，所以理所當然的就有了召回兜底邏輯，該部分資料是由馬赫的同步引擎保證實時更新存盤在IGRAPH中，可以用商品池的ID召回當前池子中最新的2000個商品作為兜底，通過以上的邏輯保證了用戶在演算法進行召回時的實時性，

總結

本文從馬赫選品到馬赫投放實時性優化做了全面的介紹，每一步優化呈現的都是最終方案，為了保證系統的平滑過渡優化中中踩了很多坑不過最終都平穩落地，優化后的馬赫從選品到投放整個實時鏈路時延有一個質的變化，選品資料從T+1變為H+1，選品流程從6分鐘變為30秒，投放流程從2分鐘變為2秒，系統更健壯也更實時，從整體功能看馬憾訓是屬于一個工具級別系統，還遠沒有達到產品級別系統級，

如上圖所示，未來會把重點放在選品能力與整體運維能力上，在優化原有系統的同時增加新的能力，逐步把馬赫打造成產品化系統，