基于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%以内__，實時資料準确性得到了大家的一緻認可！
線上運維
三、成果總結
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年加入阿裡，主要從事電商體系實時資料研發以及實時互動式查詢賦能于新商業