實時計算助力1688打造「實時挑貨」系統
一、背景
內容是一個電商app不可或缺的組成部分。越來越多的人會使用碎片時間瀏覽手機app的內容,包含導購的帖子、短視訊、直播等。1688挑貨業務,打造了基於買家和商家之間老買賣關係的內容場。讓商家通過內容維繫老客戶,挖掘新客戶。讓買家能第一時間獲取到關注商家的上新、優惠、直播等資訊,為自己的採購等決策提供幫助。
從巨集觀的背景分析,挑貨業務有以下幾個特點:
-
基於1688的老買賣關係: 關注關係、客戶會員關係、星標關係、分銷關係
-
內容的產生源頭是供應商,供應商在1688網站的各種行為,都可以轉變成內容資訊
-
內容的消費源頭是供應商的老買家(與供應商有老買賣關係)
-
內容形式比較多樣:帖子、營銷活動、店鋪上新、商家動態、直播、短視訊等一系列商家產生的有效內容
-
內容產生形式:供應商的主動行為、供應商的被動行為
基於上面的業務特點,我們梳理下挑貨整體的業務架構。
二、業務框架
-
供應商在1688網站可以直接將動態和文章釋出到挑貨。
-
供應商在1688網站的直播、店鋪上新、報名營銷活動、邀約客戶等行為,會被挑貨服務識別到,被動抓取到挑貨。
-
挑貨將供應商產生的內容推送到供應商老買賣關係的買家收件箱中。
-
買家訪問挑貨時,挑貨服務會從買家收件箱中將內容渲染成各種業務卡片,呈現到客戶手機端。
-
買家可以對部分有時效性的內容(直播預告、未開始的互動)設定訂閱提醒,當直播開始、活動開始時,挑貨服務主動通過訊息告知買家。
-
買家可以通過挑貨平臺去到供應商的店鋪和商品詳情去購買商品,產生交易訂單。
-
挑貨中的優質內容,可以投放到1688網站的其他模組,新使用者看到後,能有效的產生交易和關係轉化。
-
新使用者訪問挑貨時,挑貨服務會推薦部分優質供應商給使用者,使用者可以關注供應商,看到供應商的挑貨內容。
挑貨的業務價值在於可以維繫供應商的老買賣關係,提供買家快速獲取供應商資訊的內容,另外可以為供應商引入新的客戶,並沉澱為老買賣關係。而挑貨的優質內容可以投放到1688網站公域頻道,一方面節省運營成本,另一方面為供應商引入更多的新使用者。挑貨在1688公域、私域流轉上承擔著樞紐的作用。
三、技術框架
為了實現挑貨的業務架構,在1688無線領域孵化出多個技術方案。下面就其中關鍵的技術細節進行下描述。
挑貨總架構圖
-
業務對接方式:離線任務、訊息對接、實時rpc
-
feeds流的推拉引擎:feeds動態生成器、feeds的收件箱推送、架構圖未包含非活躍使用者走拉的模式、feeds流查詢服務
-
動態元件的對接方案Cybert:業務模型和元件UI分離、動態生成native元件
-
個性化演算法對接方案(未包含)
-
異構系統的監控體系(未包含):多種中介軟體平臺實現同一個業務時,異構系統的監控成為一大難題。在挑貨中,已經設計出了方案,目前正在對接中。
-
資料統計系統
1. feeds流推拉結合的引擎
挑貨的內容從供應商產生,到供應商的買家去消費,是典型的feeds場景。實現一個feeds流業界比較流行的主要是推模式、拉模式、或者是推拉結合的模式。
推模式:內容產生後,會為每一個訂閱內容的粉絲複製一份內容,放入粉絲獨有的收件箱中。
-
優點:粉絲讀取內容非常快,只是一個表查詢。在寫的過程中可以做很多業務干預。
-
缺點:寫的成本比較高,需要很多耗費儲存,資料冗餘。
拉模式:內容產生後,只會存入內容產生者的發件箱。讀取時,需要粉絲讀取每一個被關注使用者的發件箱,實時將內容聚合到一起排序,最終展現給粉絲。
-
優點:儲存耗費少,寫入速度快。
-
缺點:查詢都需要耗費很多計算資源做內容聚合,業務干預規則多時,會更加加重查詢複雜度,查詢效能會下降。
推拉模式:綜合推模式、拉模式的優缺點使用的方案。
我們從挑貨業務的特點和已有的技術積累兩個方面,選取了推拉結合,以推為主、拉為輔的技術方案。
-
1688有獨立的關係團隊維護了1688所有的老買賣關係資料,已經成為1688底層基礎服務。而微淘的關係和微淘的內容之前是在一個團隊孵化出來的。目前1688關係是B類的老買賣關係,和淘系的關係沒有打通。基於老買賣關係的挑貨不能直接複用微淘關係的技術。
-
微淘開發的timeline的拉引擎,使用多級快取,很好的支援了微淘業務的發展,在feeds流拉模式上有很強的專業性。而集團搜尋團隊的igraph圖資料引擎也能很好支援資料多維度拉取功能。igraph有詳細的文件、成體系化的接入和運維方案、專業的答疑。從對接的成本和後期運維角度,我們選擇了igraph作為拉引擎。
-
選擇以推為主,拉為輔的策略的原因:
-
資料規模比較小:1688的老買賣關係總量在4億,一個粉絲比較多的供應商的粉絲數量級在幾十萬,而在挑貨頻道活躍的粉絲,對應一個供應商量級在5萬以下。更多的在幾百到上千。所以這種量級的資料,使用推模式能很好的支援查詢效能。
-
集團的中介軟體平臺非常成熟:在blink平臺開發feeds流的收件箱推送功能,能根據資料規模擴縮容資源,有效的支援大規模資料的推送。tablestore是一個單表支援10PB資料的nosql,作為挑貨買家收件箱非常合適。
-
業務的規則干預比較多:需要支援遮蔽動態這樣干預feeds展現的業務規則。
-
下面看下挑貨feeds流引擎的架構圖:
-
內容資料流入動態生成器,產生挑貨feeds,挑貨feeds生成後傳送metaq訊息,被執行在blink上推送任務監聽到,將動態索引寫入到使用者到收件箱。
下面3張比較細節的圖:
-
活躍使用者-推模式
2.非活躍使用者-拉模式
3.非活躍使用者啟用策略
2. 動態元件的對接方案Cybert
Feeds列表原有純native的技術解決方案,對業務的核心痛點就在於發版週期和覆蓋率的限制;1. 半個月的發版週期嚴重限制了業務日常營銷活動、使用者活躍提升的運作方式,業務更希望營銷類的活動卡片做到快上快下,不跟隨發版節奏;2. 純native卡片還是依託與發版,新的營銷活動為了達到最佳效果,還期望於版本的覆蓋率,雖然目前安卓、ios的新版本覆蓋週期已經越來越短,但不代表可以做到像weex一樣立馬全版本覆蓋。
鑑於這些業務痛點,我們可以採用的技術方案有兩種1. 全weex化;2. native動態化。先從weex化來說起,去年整個營銷場在整體完成效能優化後,我們已經做到ios95%會場秒開,安卓超過85%,這個秒開率對於挑貨feeds來說已經足夠。但當時沒有采用全weex化的方案更多出於以下幾點考慮:1. 互動或者後期的tabview支援,挑貨feeds作為第二個主tab效能、互動、穩定性都必須去強保證,會場一些tab切換層面我們可以接受刷頁面的方案,但在核心主tab我們還希望做到更佳的使用者體驗;2. 改造成本,原有native卡片化的方式,如果整體切換就意味這頁面全部重做,這個改造成本不小。因此,我們考慮是否可以把應用在首頁、工作臺的native動態元件化方案做能力擴充套件,支援類似挑貨這類列表元件由“資料驅動ui”的渲染方式,老卡片仍然採用native方案,新元件採用dinamic元件插入,既做到老方案相容,有做到新元件動態釋出。在技術改造成本、動態性、業務支撐、互動體驗多個點上做平衡。
這裡,我先簡單介紹下目前首頁cyber動態元件化方案的業務價值、技術架構和能力。CyberT原生孵化於首頁,核心點就是native元件化方案,後續因為業務對於動態效能力的要求,支援了weex元件、dinamic元件的擴充套件,兩個動態化元件化方案看dinamic元件在首頁的效能從渲染耗時、記憶體開銷上更優。由服務端下發頁面佈局協議、元件ui協議、服務端資料協議來驅動端上的渲染,同時在ui協議上打平後可以做到元件單端投入雙端生效,後續也在進一步支援h5外投方案。
而對於feeds列表的場景,我們如何升級能力做到“資料驅動ui”?這主要是升級List複雜容器的支援,list元件的特點是由資料決定有多少個cell。cybertron 的layoutprotocl 支援list元件宣告其cell的型別 ,根據服務端返回的list資料,結合cellMapping & datamapping規則,會生成一個個cell例項,並且在框架層支援了常見的分頁載入(page模式和offset模式)。
這樣,由搭建平臺配置元件和對映協議,業務服務端下發資料,通過cybert容器的客戶端sdk實現協議、資料解析進行頁面的動態渲染。
3. 挑貨個性化演算法對接(實時特徵計算)
-
優化內容排序:使用者在1688手機阿里上各種訪問行為,特別是在挑貨的訪問行為,會被抽象成使用者的行為特徵。通過這些行為特徵,根據對應的演算法,將使用者收件箱中最感興趣的內容排序到最前面,增加使用者的閱讀體驗。
-
提取優質的內容:使用者的對內容行為,通過一定的演算法,可以給內容進行評分,提煉出優質的內容。這些優質內容可以投放到其他公域場景,為商家帶來更多的價值。
4. 異構系統的監控體系
整個挑貨系統,資料在多個系統中流轉,一旦某個系統出現故障,很難排查和追蹤問題。現有的監控體系對同構的應用的鏈路監控已經支援的很完善。一旦涉及到線上應用、離線任務、實時流計算多個異構的系統,就無法有效的做到串聯。為了保證挑貨的穩定性,我們設定了全域性的uuid,將整個系統的日誌採集到雲日誌中。通過專門的監控系統,去分析日誌,做到鏈路預警和資料視覺化。
5. 資料統計系統
挑貨業務承接是1688整個買家的內容需求。從業務在挑貨的展現的PV、UV到具體的業務轉化率,再到新業務的AB效果對比,都離不開資料化支援。所以資料化是挑貨系統的必不可少的組成部分。我們實現思路,從規範業務打點方式入手,到資料日誌輸出規範、資料統計模組、視覺化系統,完成一個閉環的資料化系統。
四、未來發展
-
內容對接平臺化(配置化、資料化):打造一個內容對接流程、內容資料展現、內容投放的配置後臺。
-
feeds引擎的抽象,支援更多的業務。
作者簡介
葛圓根,就職阿里巴巴,花名水鋒,採源寶和手機阿里挑貨技術負責人。13年起先後負責過1688內容平臺、阿里頭條、採源寶、挑貨等多個產品的架構和研發工作。在內容平臺的架構、電商app架構設計和開發、流式計算上經驗豐富。
如果您有實時報表/實時資料大屏/實時金融風控/實時電商推薦等相關實時化資料處理需求,可以加入如下釘釘交流群!
相關文章
- 聊一聊實時計算系統設計
- storm實時計算例項(socket實時接入)ORM
- Concurrent iHawk — 實時平行計算機模擬系統計算機
- 實時計算Flink——獨享模式系統架構模式架構
- 實時計算小括
- 基於實時計算(Flink)與高斯模型構建實時異常檢測系統模型
- Airwallex 基於 Flink 打造實時風控系統AI
- Arctic助力傳媒實現低成本的大資料準實時計算大資料
- 實時計算如何幫助淘寶實現線上「實時選品」?
- 10. 實時鐘系統設計
- 說說實時流式計算
- 實時計算神器:binlog
- Spark 實時計算整合案例Spark
- 愛奇藝統一實時計算平臺建設
- 稜鏡-分散式實時計算的跟蹤校驗系統分散式
- 阿里雲重磅開源實時計算平臺,挑戰計算領域的“珠峰”阿里
- Qt實時顯示系統時間QT
- 從 Kafka 到 Pulsar,BIGO 打造實時訊息系統之路KafkaGo
- 你瞭解實時計算嗎?
- Flink 在有贊實時計算的實踐
- vivo 實時計算平臺建設實踐
- 實時計算,流資料處理系統簡介與簡單分析
- 直播系統原始碼,實現倒數計時,定時任務原始碼
- 看了Java實時系統感受Java
- 下面的實時系統怎麼設計呢。
- 用Spark進行實時流計算Spark
- 實時計算無線資料分析
- Flink實時計算topN熱榜
- 實時計算Flink——產品安全
- 實時計算Flink效能調優
- 【MySQL】利用binlog完成實時計算MySql
- Storm 實戰:構建大資料實時計算ORM大資料
- Kafka實戰-實時日誌統計流程Kafka
- python 實現計時器,統計執行時長Python
- 分期商城實時推薦系統
- Hive實戰—時間滑動視窗計算Hive
- 實時計算Flink——快速入門概述
- Java如何使用實時流式計算處理?Java