基于Blink為新商業調控打造實時大數據交互查詢服務
案例與解決方案匯總頁:
阿里云實時計算產品案例&解決方案匯總
從IT到DT、從電商到新商業,阿里巴巴的每個細胞都存在大數據的DNA,如何挖掘大數據的價值成為搶占未來先機的金鑰匙!傳統的大數據開發主要基于離線計算平臺MaxCompute(ODPS)進行天級別、小時級別的批量數據分析,但近些年隨著618、99、雙11、雙12等大促活動的常態化,傳統的離線數據分析已經無法滿足大促當天的需求,以雙11實時交易數據為例,試想如果我們只能看到前一小時或者前一天的成交數據,對于公司高層的決策制定、對于行業/運營/商家/商品的行動指導、對于算法的預測調控將大大折扣,可以說大數據實時化已經成為通向新商業體系必須擁有的諾亞船票。
從2017年8月開始,一群有激情有干勁的小伙伴歷經三個月打造出一套實時大數據交互查詢服務,完美的支撐了珠峰、閃電、通天塔、優惠券、湊單等業務的實時需求,并經過了雙11、雙12等大促活動的實戰考驗!!
一、背景介紹
珠峰調控的典型應用場景如下圖所示:
- 采集:用戶在淘寶的每一次瀏覽/點擊/加購/成交等行為都被記錄在日志中,并實時傳送到TimeTunnel,該部分工作由業務團隊或數據團隊完成
- 加工:基于集團的明星產品Blink,對所需業務渠道的日志進行加工處理,產出業務所需要的各種維度/各種指標
- 裝載:將加工好的格式化數據裝載到lightning交互式查詢引擎,方便后續快速查詢
- 分析:通過定制化報表可以實時動態展示行業/類目/商家/寶貝/分桶等多維實時指標,方便小二分析決策,更多業務報表詳見珠峰、閃電
- 干預:在搜索/推薦等產品中,算法自動獲取指標、并根據實時分析的結果更改線上參數,影響線上效果
- 干預后的結果又進入下一個數據輪回,直到業務目標完成
二、解決方案
2.1 確立目標
改造后的實時數據既要滿足功能,還要可兼容、可擴展:
- 數據的正確性和穩定性是一切的前提,實時數據統計口徑必須和離線一致
- 資源有限,必須打造統一的解決方案滿足已有需求,以及未來可能的需求
- 建立標準化,拉更多人一起參與數據共建
- 數據的生產和消費都要統一管理,消滅一切不合理
2.2 梳理需求
將各平臺的業務需求進行挨個梳理,針對數據自身特點進行抽象,確定數據分層:
- 全網數據:獨立的數據表,如全網加購、全網成交等
- 渠道數據:根據業務獨立性劃分為手淘搜索、推薦、營銷平臺等渠道,各渠道包括數據指標:曝光(寶貝曝光/搜索曝光)、點擊、引導加購、引導成交等,各數據指標是獨立的數據表
- 子業務場景:含在渠道數據表中,存儲在固定字段并用關鍵字區分,例如手淘搜索全部分頁/天貓分頁、推薦的猜你喜歡/購后等
- 數據維度:含在渠道數據表中,存儲在固定字段(如時間、寶貝、賣家、類目、行業等)和多值字段(如分桶、BC類型等)
梳理各業務方關注的數據場景,梳理出雙11的數據需求和查詢需求:
-
數據要求:
- 寶貝量從去年的20w到5kw,增長250倍
- 賣家量從去年的1500到16w,增長100倍
- 單表最大數據量 > 600億
-
實時性:
- 單表寫入最大QPS > 200w/s
- 數據延遲時間(日志落地到查詢可見) < 5s
-
查詢需求:
- 查詢頻率:3s、1min、5min、1h
- 查詢范圍:當天、當前小時、前5min、前10min
- 查詢響應時間 < 3s
- 單表查詢QPS < 100/s
2.3 架構選型
目前可以滿足上訴性能要求,并且相對成熟的實時大數據架構方案有兩種:
- blink + kv存儲:在blink層進行數據預聚合并將聚合后的計算值寫入kv存儲,用戶按照事先約定好的key進行查詢即可拿到實時結果,常用的kv存儲比如hbase、redis、tair等。該方案的優勢是查詢毫秒級響應并支持查詢高并發,但不足之處是可擴展性較差,增加維度或改變查詢條件需要改動整條鏈路。比如雙11媒體交易大屏,提供00:00到當前時刻的交易總額,但如果想查看10:00-10:20的交易總額改造成本就會很高甚至無法進行
- blink + olap/oltp:在blink層進行數據明細加工并補充數據標簽,加工后的數據裝載到olap/oltp,用戶帶著自定義條件進行查詢。該方案最大的優勢就是交互式查詢,用戶可以根據自己需要進行各種維度的查詢組合,但不足之處就是無法支持高并發高QPS查詢,而且查詢之間會互相干擾,偶爾一個大的聚合查詢會導致其它查詢失敗
兩套方案各有優劣各有適應的業務場景,考慮到我們打造的實時數據支持的業務場景較多而且需求各不相同,綜合比較之后我們選擇了第二套方案,至于不支持高QPS的問題我們通過優化查詢Query解決。實踐證明我們的選擇是很明智的,用戶對實時數據的查詢需求隨著大促逐漸臨近呈爆發性的增長,甚至雙11當天決策層還對我們提出若干新的數據需求,不過我們都輕松應對,合理的架構讓一切不可能成為了可能
2.4 最終架構
2.5 規范標準
統一接口定義
- 全網數據接口定義
- 渠道搜索數據接口定義
- 渠道寶貝數據接口定義
規范實時處理邏輯的分析方法
- 找日志生產者掌握字段含義,并結合業務需求進行初步設計
- 以BI使用的ODPS表為基礎,梳理離線處理邏輯
- 訂閱實時日志,使用離線處理邏輯進行日志詳細分析
- 實現實時任務代碼
- 實時離線對比驗證,分別從全部、賣家、寶貝三個維度驗證,要求數據差異均小于3%
制定Blink代碼開發規范
- 主流程使用Table API,Scala開發
- 日志處理以及字段處理使用UDF,Java開發
- UDF設計盡量只專注一件事,如多值字段中n個字段最好提供n個UDF分別處理
- 過濾邏輯和處理邏輯要求代碼層面隔離,不能耦合
- 嚴格遵守集團開發規約
讓合適的人做合適的事
- 搜索數據屬于我們擅長的,我們負責開發維護
- 其它數據推動相應業務方按照標準開發,我們提供技術支持和資源支持
2.6 重構
實時任務
實時任務重構過程中做了很多細節優化:
- ID值存儲:實時數據均存儲各維度ID值,將冗余字段Name剔除,大大減少查詢引擎的存儲查詢壓力
- 輔表為主:當數據在輔表和日志都存在時,優先透出輔表數據
- 數據打標:提供全網用戶/全網賣家/全網寶貝的數據打標,方便業務方按照數據標一次查詢獲得結果
- 數據分區:產出到TT中的實時數據按照寶貝ID進行Partition,可以減少查詢引擎的單次消耗
- 異步讀寫:寫TT以及讀寫HBase均采用異步操作,既提高讀寫QPS又保證實時任務受集群環境影響最小化
- 離線備份:所有的實時數據表每15min同步到相應的云存儲ODPS表,以防不時之需
- ……
封裝查詢接口
為了約束規范業務方使用實時數據,我們封裝了統一的數據查詢接口:
- 采用租戶分配QPS配額的方式,控制訪問頻率
- 對常用查詢方法進行封裝,減少用戶學習成本
- 每次查詢都進行實時監控并記錄追蹤日志,方便出現問題時快速排查
另外我們對業務方每條Query進行了分析,推動業務方優化不合理的Query,對于查詢Query較大較慢的業務搭建獨立的查詢引擎,通過以上措施減少了業務間互相干擾,大大的提高了系統穩定性,業務效率也得到了極大提升
數據校驗
邀請BI作為裁判對重構的實時數據進行了一致性校驗,__校驗結果:90%以上的場景數據差異在1%以內__,實時數據準確性得到了大家的一致認可!
線上運維
- 使用烽火臺監控延遲報警、無數據報警
- 在KMonitor建立各級監控:全景監控、單任務監控、全鏈路大盤
- 通過多輪壓測保證任務資源占用既不浪費又能滿足大促需要
三、成果總結
3.1 實戰效果
2017年雙11活動期間,實時大數據共運行Blink任務40+,產生實時數據表40+,占用資源約近5000vcore、近20T mem
雙11當天處理日志量數百T,數據峰值TPS約7000w+,產出純凈業務數據數十T,總條數1500億+,其中單表全天近700億,數據處理峰值200w+;支持了全網數據的輔表信息透出,實時數據延遲在秒級別;查詢服務全天請求近200w,QPS峰值約700次,平均響應時間1.5s
3.2 建立生態
隨著實時大數據取得的成功,越來越多平臺希望引入實時數據,截止到18年1月底實時大數據服務情況如下圖所示,目前業務平臺、數據渠道、數據指標仍在不斷擴充中,實時大數據生態已經初具規模,這對參與實時數據建設的所有小伙伴們來說是莫大的認可
四、作者簡介
花名:言柏,來自搜索事業部-工程效率&技術質量-算法工程平臺-實時大數據平臺
14年加入阿里,主要從事電商體系實時數據研發以及實時交互式查詢賦能于新商業