"陸戰之王"大潤發如何在零售業數字化轉型中搶佔先機?

語言: CN / TW / HK
作者:大潤發大資料團隊
 
自 1998 年在上海開設第一家大型超市以來,大潤發已在中國大陸地區成功開設近 500 家綜合性大型超市,覆蓋全國 29 個省市及自治區達 230 多個城市,年銷售額過千億。大潤發優鮮、淘鮮達、餓了麼、天貓超市線上平臺使用者達到 6900 萬。活躍使用者超過 1650 萬,一線城市平均每店日均線上訂單量突破 2000單。
作為國內大型連鎖量販超市的先導者,大潤發在物流倉儲、商品管理等領域很早就引入了大資料技術進行智慧決策分析,幫助優化管理精度、提高管理水平。大資料平臺也跟隨技術浪潮多次迭代升級,沉澱出一整套特有的資料子系統和大資料處理方案。
大潤發大資料業務起步較早、資料累積和歷史元件較多,同時為了保證技術的前沿性,因此逐步發展出了多分析引擎的架構。一方面可以根據各型別引擎的特點處理合適的線上資料產品,一方面也可以根據各類引擎的技術優勢及使用效果調整使用場景調節使用權重。
然而,隨著業務需求的多樣化、複雜化以及資料系統的改造升級,原本一些下放門店庫的查詢需求統一收歸中心化的資料中臺處理,導致高 併發 且複雜的查詢場景出現頻次激增。面對此種場景,無論是能力還是效率,現有的分析引擎都顯得力不從心,複雜查詢效能出現明顯不足。因此我們亟需一款能夠適應高併發低延時的查詢引擎作為我們大資料框架 OLAP 分析平臺的全新動力。
 

OLAP元件選型

選型要求

對於新的 OLAP 引擎我們的需求有如下幾點期待:
  1. 社群活躍的 開源框架 ,運維成本不會太高;
  2. 能夠支援多型別 Join,大表 Join 效能要優秀;
  3. 要支援高 併發 處理查詢,且查詢延遲低,這也是我們最核心的訴求;
  4. 要能夠支援大規模資料的匯入匯出,且能與現有資料平臺相互相容;
  5. 資料模型靈活,使用場景全面;
  6. 支援預計算技術。

選型對比

我們針對時下流行的元件進行了前期調研,StarRocks以其出色的效能、良好的相容、極簡的部署吸引了我們的注意。StarRocks 與大潤發資料平臺框架現有元件的特點及應用場景對比如下:
 

元件測試

為了驗證 StarRocks 實際使用效能是否能夠達到預期,我們採用了學術界和工業界廣泛使用的星型模型測試集 Star Schema Benchmark(簡稱SSB測試集),在本地測試叢集(3 FE +3BE架構)上進行了單表查詢的系列測試。
單表查詢的測試結果如下:
 
系列測試結論如下:
  1. 在 SSB 測試集的 13 個查詢中,StarRocks 的整體查詢效能是 ClickHouse的 2倍多;
  2. 在 SSB 測試集的 12 個低基數查詢中,StarRocks 的整體查詢效能為 ClickHouse 的 1.1倍。
 

元件部署

從測試結果來看,StarRocks 的效能非常優秀,元件架構也非常精簡。經過簡單的部署改造,StarRocks 增強了我們 OLAP 分析引擎高 併發 場景下的處理能力。
 

實踐案例

離線應用

1、建模
大潤發的核心業務依託於各大中小門店的進、銷、存經營資料,該部分資料以業務流程型單據明細為主。通常的邏輯是,業務中臺系統的門店明細資料經過自研採集系統同步到資料中臺中,經過 ETL 清洗、轉換、聚合處理,輸出到 BI 報表進行結果展現。
在應用外部 OLAP 分析引擎的場景中,我們會把業務維表和部分分析邏輯放到 引擎庫中。引入 StarRocks 改造後,我們也進行了初步探索,針對 StarRocks 的四種模型規定了使用場景,並特別對明細模型的建模細化了兩種應用方式:一種是不用分割槽的維度表,一種是需要按同步時間分割槽的明細表。
建表還需要注意一些分割槽分桶問題,官方建議單個分桶的大小在 1-10G ,此時查詢效能較好。所以如果源表資料量過大或過小,可以適當調整分割槽或分桶數,以達到最佳的效能狀態。
2、同步
得益於 StarRocks 相容 MySQL 協議,能夠與我們現有的資料平臺整合,進行簡單的配置就可以進行資料的同步和開發。
不同於以往的 Hive 或者 MySQL 資料庫,StarRocks 通過動態分割槽匯入資料的前提是分割槽必須已被建立,而其本身無法根據分割槽欄位實時動態建立分割槽。這裡有兩種方法解決:
  1. 可以根據建表語句properties配置中的引數開啟動態分割槽功能,讓StarRocks呼叫底層常駐執行緒預建立分割槽;
  2. 可以關閉StarRocks的動態分割槽,通過資料平臺執行預定義SQL語句進行分割槽建立操作。
在刷數的時候,對於特定歷史分割槽的刷數操作,可以使用StarRocks的臨時分割槽功能實現無感刷數。
3、查詢
我們所使用的 BI 報表工具,對 前端 報表查詢控制元件的操作都會在底層轉化成預定義的 SQL 向 StarRocks 查詢,返回結果再進行 Web 渲染。由於採用的是自動生成的 SQL 語句,需要注意在 SQL 生成的過程中,是否對錶的索引欄位自動添加了轉換函式,從而導致索引失效的情況。
4、效能效果
報表上線後,我們對實際的查詢效果也做了持續的觀察和分析。包括複雜查詢在內,總體 99% 查詢延時在150ms左右,QPS 9000+的高併發場景下仍能較為穩定執行,達到了匯入的預期效果。
 

實時探索

1、相容測試
實時團隊也測試了 Flink+StarRocks 的相容性,憑藉官方的 Flink-connector-starrocks 依賴,可以很好實現實時需求的改造。不過需要注意的是:
  1. 1.11 版本的依賴沒有 Source 讀取方法,仍需使用 JDBC 讀取。
  2. 1.13 以後版本的依賴有 Source 和 Sink 方法,
這兩個方法的底層實際是轉為 Stream Load 方法進行寫入寫出,對比 JDBC 的單 FE ,可以實現多 FE 資料傳輸,效能更強。所以如果有實時的應用場景,推薦Flink 1.13+ 版本配合對應的依賴取得更好的使用體驗。
2、其他設想
我們曾嘗試使用 Kafka+RoutineLoad 的方式將資料匯入 StarRocks,期望結合StarRocks 本身的物化檢視預計算實現實時 Join,從而直接替代 Spark/Flink 這類專業的實時引擎。遺憾的是,我們 基於 2.1.6 版本的物化檢視功能比較基礎,尚無法實現更為複雜的表間關聯操作,而 StarRocks 2.4 版本已開始支援並逐步完善多表物化檢視功能。
 

實踐總結

優點

  1. 效能卓越:StarRocks 的單表效能不輸 ClickHouse,多表 Join 的延時對比我們現有的的元件又有著較大優勢,即便不做特定的優化,也能有較好表現,這是十分難得的。
  2. 運維簡單:StarRocks 捨棄了傳統多元件的架構形式, FE +BE 的結構十分精簡,部署較為便捷。而執行上的穩定可靠,使得對運維的資源消耗非常低。
  3. 外掛豐富:開發者維護了一些較為實用的外掛和工具,可以進行一鍵部署、日誌結構化等。如果這些功能後期能夠穩定嵌入 StarRocks 後續 版本 中,應該可以更好優化使用體驗。
  4. 社群活躍:開源社群有長期穩定版和快速迭代版可以自由選擇,版本升級操作也較為容易。同時有中文社群論壇和官方群可以隨時進行問題反饋獲得答疑,這一點是要勝過很多競品的。

不足

這裡基於 2.1.6 版本提出兩點使用中的困擾:
  1. 許可權管理不足:StarRocks 的使用者角色功能有待改善,例如該版本只能在建立使用者時授予角色,不能授予使用者多角色,刪除角色後用戶許可權依然保留。慶幸的是,在不久後的 3.0 版本中,StarRocks 將實現完整的 RBAC ,並豐富更多許可權專案,從而解決這一問題。
  2. 預計算功能泛用性不強:物化檢視作為預計算的特色功能,運用場景較為基礎,條條框框侷限過多,比如不能實現多列聚合運算,不能實現多表 Join 等,使用起來難以做到如臂使指的效果。StarRocks 2.4 版本的非同步物化檢視功能已經在逐步解決這一困擾。
 
我們通過實踐發現,StarRocks 能夠很好地解決大潤發資料分析中的一些痛點問題,能夠解決問題的工具就是好工具。StarRocks 以其優異的特性,得到大潤發資料團隊的一致好評。而其開發團隊從善如流的服務態度,高效迭代的技術努力,無不彰顯著他們在這片市場耕耘的勃勃雄心,相信 StarRocks 在不遠的未來,能夠結出他們所期待的光明。