作者：哈九，菜鳥裹裹數據研發

無刃，菜鳥裹裹數據研發

夏招，菜鳥裹裹數據産品

菜鳥寄件業務當前為菜鳥的基礎設施建設業務，是用戶與【菜鳥】品牌最直接最基本的認知聯系。通過與三通一達等巨頭快遞公司合作，降本增效，數字化、智能化的推動了中國快遞行業騰飛。在新的一年裡，菜鳥裹裹更是【做物流行業數字化轉型的引擎】這一菜鳥大願景的踐行者。目前裹裹寄件日常寄件訂單量百萬級别，且雙十一等大促期間訂單量更是成倍增長。智能化履約過程及不斷精益化的業務系統，菜鳥裹裹團隊急需一套一體化的數據産品，能夠智能化、專業化、高效化的解決日常遇到的數據問題與需求，并在日常的數據監控與效果分析的過程中，用數據影響業務決策。基于業務越來越頻繁的數據需求及數據應用，我們使用Hologres構建萬能查産品，一勞永逸的解決業務洶湧的需求與各種口徑、降本增效等問題。

通過本文我們将會介紹菜鳥裹裹基于Hologres構建萬能查産品的最佳實踐。

菜鳥裹裹寄件業務發展至今，已經曆過多輪的業務方向調整以及組織架構的變動，必然會存在極重的數據曆史包袱。各類數據指标根據業務類型、運營模式的不同分散于不同的看闆模塊，效果分析關聯度低；或同時多數據看闆重複建設，類型過度細分，找數難，直接影響業務分析效率及體驗感。此外，業務和BI所面對的分析場景、彙報對象、實際目标的不同，對于同一個指标可能存在多版本多角度的統計口徑，易出現數據口徑等細微差異導緻的數據不準的情況，導緻了數據同學日益繁重的“找茬”工作。若再不協同各方梳理指标口徑，确定口徑定義模式，統一底層數據，删減冗餘看闆，最後壓死數據同學的将是任意一個不知名的“包裹”。

早期的數據産出常常以需求為導向，以快速滿足業務分析為目的。因此之前協作模式，主要為業務提出取數需求，分析現有數據看闆是否支持，若無法支撐則重新搭建，并未将數據産品化。快速發展的業務必然會衍生出新的分析維度，目前固化的數據看闆無法快速應對，同時也沒有業務可自助查詢數據的統一入口，數據分析進度與數據開發周期強綁定，從而導緻業務常常不得不停下來等數據，對業務進度上造成了一定的阻礙。

離線數據分析和業務看闆目前存在兩種常規設計方案，如下圖所示：

1. 用FBI等工具直接訪問MaxCompute（原ODPS）離線表，但是由于ODPS開發資源短缺和MR的處理架構導緻數據訪問速度相對較慢，用戶等待任務執行時間往往超于數據分析本身；
2. 形成一個adm層的聚合指标結果寬表，通過外表或DataX工具将聚合結果寫入OLAP引擎加速查詢（利用ADB提供的穩定查詢加速能力），但該方案數據需維護大量同步任務，且任務同步耗時較長。同時，該方案僅适用于較少且相對穩定的維度和指标查詢組合，隻需對彙總層結果進行簡單聚合計算。

業務發展處于高速發展階段，裹裹寄件運營模式在快速試驗快速試錯的過程中急需數據中台提供強有力的支持。個性化推薦、敏捷分析，大數據的應用在這個時代創造了很多千億級别的現象級公司，可見于此業務發展迅速膨脹，若數據中台依舊保留一對一的數據服務模式，服務速度将遠遠跟不上時代的前進腳步。目前迫切于找到應對指數級增長的數據需求的出路，打造一套一體化的數據産品，智能化、專業化、高效化的解決日常遇到的數據問題與需求，真正做到數據賦能，驅動寄件模式升級。

業務核心訴求是通過數據化産品快速監控分析，看清局部業務現狀并作出決策，并不在乎如何取數。數據計算過程，易造成數據過于定制化、靈活性差、分析維度不全面等問題。若後續出現同類取數分析需求，需增加新維度或指标時，數據同學需重新開發代替疊代，重啟新看闆模塊，成本高、效率低、排期長，業務抱怨不斷，與開始快速響應業務快速看數需求目的相悖。兼顧成本和體驗，釋放人力的同時保證業務同學可快速自助獲取數據，是一個迫在眉睫的問題。

目前裹裹寄件日常寄件訂單量百萬級别，且雙十一等大促期間訂單量更是成倍增長，其主要業務模式為收到各端寄件的需求（信息流），然後将寄件需求單分發給合作的快遞公司網點及小件員（三通一達），小件員在包裹俠上接單/消費者到站寄件；包裹攬收後消費者完成運費支付，快遞交付于第三方物流完成運輸配送。

Hologres是一站式實時數據倉庫引擎，支持海量數據實時寫入、實時更新、實時分析，與MaxCompute、Flink、DataWorks深度融合，提供離在線一體化全棧數倉解決方案，廣泛應用在實時數據中台建設、精細化分析、自助式分析、營銷畫像、人群圈選、實時風控等場景。HOLO的主要特性有：

• 支持高并發數據實時寫入和實時查詢，存儲計算分離可獨立擴展；
• 底層數據架構統一，行存表支持高QPS KV點查詢，列存表适應于OLAP分析或Adhoc查詢；同時支持負載隔離，統一數據訪問接口與安全策略；
• 聯邦查詢，支持盤古2.0文件直接讀取；外表加速Hologres無縫對接MaxCompute，支持外部表透明加速查詢，支持OSS外部表讀寫；

通過目前現有的數據支撐能力，依賴Hologres引擎，将裹裹寄件常用且穩定的維度和指标封裝于萬能查中。用戶可根據自己的需求篩選字段，定制化自己的報表，快速自助完成運營數據分析。基于一體化數據分析産品「萬能查」，突破目前數據産品的壁壘，達到降低成本、提高效率、保證數據準确性、完成體驗升級的目的。

• 統一口徑：協同BI、多方業務梳理業務過程、整理刻畫業務形态的關鍵性指标、統一數據指标計算口徑、及對外輸出查詢口徑；
• 産品刻畫：萬能查為一套一體化多維度多場景的數據分析體系，快速為運營決策、産品策略提供快速有效的數據支撐。汰換之前的「報表」 「臨時取數」的數據輸出模式下，業務方可通過萬能查有效地監控運力任務單據的生命周期，管理小件員運力流程，自主完成分析結論、臨時取數需求，減少開發成本，提高運營效率。

産品需求設計過程中，會接受到不同的用戶各種的個性化訴求。業務團隊主要将運營過程劃分為訂單運營和用戶運營，而不同的需求會有不同視角和粒度的看數訴求。另外，由于淘退訂單的業務特殊性，需基于全局淘退訂單進行分析，訂單視角存在較大的區别。因此針對用戶的個性化需求，以及實際業務場景，我們将萬能查劃分為三大模塊：訂單，用戶，淘退，設計多款萬能查産品。

• 數據能力矩陣，根據前期的需求調研，積極協調業務、BI同學對裹裹寄件的分析場景、産出邏輯、最終目标進行統一；收集整理刻畫裹裹寄件業務過程的關鍵指标，構建數據指标矩陣

• 數據建模，完成核心指标需求收集和分析後，劃分數據域，聯系多部門團隊同學，确定數據中間層，并進行數倉模型評審

基于數據量大、周期長、鍊路範圍廣、維度特征多等業務需求特點，且結合Hologres存儲費用高等問題。我們整體萬能查設計結構如下：

• 在ODPS中讀取各主題的公共層及維表，構建可擴展性較高的輕度彙總層。将查詢頻率較高的近一年數據通過内表的形式導入Hologres表的各曆史分區，提高高速查詢；
• 考慮到業務分析時使用跨年的數據進行同期比較分析，但分析頻率并不高，因此選擇犧牲速度提供外表的形式查詢（外表最多支持512分區查詢）。目前FBI一個組件隻支持一個數據集，為保證用戶的使用體驗，我們利用試圖的方式在Hologres中将内表以及外表進行合并，對外隻透傳視圖。
• 基于輕度統計層的按時間範圍的OLAP查詢是主要的數據場景，存在大量聚合Group by等操作，因而Holo表的屬性選擇上，毫無疑問是列存 日期分區表。一方面對于日期（ds）設置為分區字段，可以有效縮小每次查詢的掃描範圍；另一方面也可以較安全的進行運維和排查問題。
• 具體結構如下：

Hologres提供了Distribution Key、Segment Key、Clustering Key、Bitmap Columns等一系列的索引方式對表進行優化，合理的使用各類索引，可以大幅提升使用性能。

基于裹裹寄件業務導入數據為輕度彙總無唯一主鍵且無自增/類自增字段的特性，不設置Distribution Key以及Segment_key，采用随機分發到shard的模式，其中，設計Segment_key索引中會存在一個誤區，是指定具備遞增邏輯列，區别于ds分區字段，同時設置分段列需排序後寫入，才會生效。

此外，由于用戶存在多種等值過濾查詢場景，經過統計分析經常用在Filter和Range場景的字段，我們将使用次數相對較多的字段“業務子類”設置為聚簇索引Clustering Key，其餘分析維度設置Bitmap，如攬件網點，運力類型，發貨城市等信息。

CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'orientation', 'column'); CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'clustering_key', 'send_sub_type'); CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'bitmap_columns', 'fac_id,fac_name',...); CALL SET_TABLE_PROPERTY('"public".holo_adm_ord_1d', 'time_to_live_in_seconds', '34560000');

由于采用了Hologres分區表的設計方式，但在ODPS數據回流至Hologres時，Hologres分區表無法直接向父表插入數據，需依次删除并重建分區子表，将數據插入分區子表中，實現分區父表動态更新數據，且當前不支持python/shell等腳本循環調度Hologres SQL實現數據回刷。實現Hologres的分區表動态分區式更新回流數據，即循環執行Hologres分區表腳本将數據回流至每一個分區子表。（了解到後期holo1.3版本上線，将支持動态分區管理，離線将支持動态寫入，且可支持并行補數據。）

Table Group的設置一般根據數據規模、訪問特性、資源規格和使用重心（Join頻次）等綜合考慮。需要關聯的表放入同一個Table Group，通過Local Join減少數據的Shuffle，可極大提升查詢效率。一定範圍内，Shard Count可以提高數據寫入和查詢分析處理的并行度。但大量的Shard數需要更多的節點間通信資源、計算資源以及内存資源支撐，從而導緻資源浪費。

目前，裹裹寄件輕度統計層數據，數據來源統一，表單分區一般在數千萬行量級，一般做靈活多維度彙總，并發不高，且無需做多流join。因此選擇默認Shard Count為12，不做特殊修改。

• 篩選所需指标維度，也可以在搜索框中輸入你想要查找的字段。比如【及時回單率】【網點ID】點擊确定，指标數據将會自動聚合，秒級返回；可在同一數據入口，查詢分析包裹全鍊路的指标數據；
• 自主上傳運單号或用戶ID，快速分析用戶複購率、訂單流程進度等分析型數據需求；
• 定制化，選擇指标結果及篩選項結果将會記錄下來，在下次進入時仍然會記住這些選項，無需重複操作；

1. 統一口徑：萬能查統一了數據指标計算口徑、及對外輸出查詢口徑，大幅度減少不同報表數據對不齊、對不準等問題，預計下線30 FBI看闆，且間接性達到對外傳遞數據支撐能力，反向沉澱數據資産的效果。
2. 提高效率：萬能查涵蓋規模、客訴、服務質量、健康度考核、淘系逆向、用戶等多維度多業務的數據，已可支撐業務日常的監控考核需求；同時，業務方可通過萬能查多維度自由組合自行完成分析結論需求、及95% 臨時取數需求，數據指标開發需求從原來的一周提6次降低位兩周提2次，大幅減少開發成本，提高運營效率，業務同學滿意度95% 。

• 爽約率案例：快速監控網點爽約率波動，精準分析波動原因，并快速觸達至城市經理；
• 疫情訂單攔截案例：針對突發疫情，業務方可快速通過萬能查明細查詢異常包裹，将響應過程縮短至小時級别。

3. 降低成本：萬能查數據産品上線以來，重新規整鳥查FBI數據看闆，删減冗餘看闆近30 ；
4. 産品影響力：萬能查已覆蓋了裹裹整條業務線的内部用戶，涵蓋商家、運力、線上寄件、IOT、大B銷售、客服、體驗、業務産品技術等将近15個團隊，周均DAU200 ，季度均DAU1000 ，已收到幾十位業務同學的滿意反饋。目前該産品模式已廣泛複用于其他菜鳥業務線。

目前運營決策、産品策略的效果分析關聯度分析能力還比較弱，能較大程度的滿足業務方全局監控分析的需求，但卻無法精細化感知指标數據的波動以及産品變更與數據波動的因果關系。對于數據變化的業務能力升級，将是産品接下來疊代的重點方向；

目前産品主要是基于離線數據設計，但是存在較多的實時數據查詢需求，如疫情預警時，需依賴實時/小時數據取出截止當前時段的包裹明細。我們後續可以讀取Hologres Binlog或者TT/MQ消息，利用Flink的流處理能力，通過查詢持久化存儲的Hologres維表補全模型字段，構成明細表，寫入到Hologres分區的當日實時分區；并在T 1日我們通過Hologres的外表導出的功能，将T日實時寫入的這類快照狀态字段從Hologres導出到ODPS做持久化離線存儲，充分利用Hologres資源。

最後：菜鳥裹裹數據産品設計任重道遠，Hologres在數據産品上的應用範圍非常廣泛，萬能查隻是該數據引擎的探路者，中間碰到了各種各樣的問題，包括模型設計、性能調優等，感謝數據團隊同學在數據技術和Hologres架構等方面的支持和幫助，未來我們也将會持續使用共建。