"陸戰之王"大潤發如何在零售業數字化轉型中搶占先機？
作者：大潤發大數據團隊
?
自 1998 年在上海開設第一家大型超市以來，大潤發已在中國大陸地區成功開設近 500 家綜合性大型超市，覆蓋全國 29 個省市及自治區達 230 多個城市，年銷售額過千億。大潤發優鮮、淘鮮達、餓了么、天貓超市線上平臺用戶達到 6900 萬?；钴S用戶超過 1650 萬，一線城市平均每店日均線上訂單量突破 2000單。
作為國內大型連鎖量販超市的先導者，大潤發在物流倉儲、商品管理等領域很早就引入了大數據技術進行智能決策分析，幫助優化管理精度、提高管理水平。大數據平臺也跟隨技術浪潮多次迭代升級，沉淀出一整套特有的數據子系統和大數據處理方案。
大潤發大數據業務起步較早、數據累積和歷史組件較多，同時為了保證技術的前沿性，因此逐步發展出了多分析引擎的架構。一方面可以根據各類型引擎的特點處理合適的在線數據產品，一方面也可以根據各類引擎的技術優勢及使用效果調整使用場景調節使用權重。
然而，隨著業務需求的多樣化、復雜化以及數據系統的改造升級，原本一些下放門店庫的查詢需求統一收歸中心化的數據中臺處理，導致高
并發
且復雜的查詢場景出現頻次激增。面對此種場景，無論是能力還是效率，現有的分析引擎都顯得力不從心，復雜查詢性能出現明顯不足。因此我們亟需一款能夠適應高并發低延時的查詢引擎作為我們大數據框架
OLAP
分析平臺的全新動力。
?
OLAP組件選型
選型要求
對于新的
OLAP
引擎我們的需求有如下幾點期待：
-
社區活躍的 開源框架 ，運維成本不會太高；
-
能夠支持多類型 Join，大表 Join 性能要優秀；
-
要支持高 并發 處理查詢，且查詢延遲低，這也是我們最核心的訴求；
-
要能夠支持大規模數據的導入導出，且能與現有數據平臺相互兼容；
-
數據模型靈活，使用場景全面；
-
支持預計算技術。
選型對比
我們針對時下流行的組件進行了前期調研，StarRocks以其出色的性能、良好的兼容、極簡的部署吸引了我們的注意。StarRocks 與大潤發數據平臺框架現有組件的特點及應用場景對比如下：
?
組件測試
為了驗證 StarRocks 實際使用性能是否能夠達到預期，我們采用了學術界和工業界廣泛使用的星型模型測試集 Star Schema Benchmark（簡稱SSB測試集），在本地測試集群（3
FE
+3BE架構）上進行了單表查詢的系列測試。
單表查詢的測試結果如下：
?
系列測試結論如下：
-
在 SSB 測試集的 13 個查詢中，StarRocks 的整體查詢性能是 ClickHouse的 2倍多；
-
在 SSB 測試集的 12 個低基數查詢中，StarRocks 的整體查詢性能為 ClickHouse 的 1.1倍。
?
組件部署
從測試結果來看，StarRocks 的性能非常優秀，組件架構也非常精簡。經過簡單的部署改造，StarRocks 增強了我們
OLAP
分析引擎高
并發
場景下的處理能力。
?
實踐案例
離線應用
1、建模
大潤發的核心業務依托于各大中小門店的進、銷、存經營數據，該部分數據以業務流程型單據明細為主。通常的邏輯是，業務中臺系統的門店明細數據經過自研采集系統同步到數據中臺中，經過 ETL 清洗、轉換、聚合處理，輸出到
BI
報表進行結果展現。
在應用外部
OLAP
分析引擎的場景中，我們會把業務維表和部分分析邏輯放到
引擎庫中。引入 StarRocks 改造后，我們也進行了初步探索，針對 StarRocks 的四種模型規定了使用場景，并特別對明細模型的建模細化了兩種應用方式：一種是不用分區的維度表，一種是需要按同步時間分區的明細表。
建表還需要注意一些分區分桶問題，官方建議單個分桶的大小在
1-10G
，此時查詢性能較好。所以如果源表數據量過大或過小，可以適當調整分區或分桶數，以達到最佳的性能狀態。
2、同步
得益于 StarRocks 兼容 MySQL 協議，能夠與我們現有的數據平臺整合，進行簡單的配置就可以進行數據的同步和開發。
不同于以往的
Hive
或者 MySQL 數據庫，StarRocks 通過動態分區導入數據的前提是分區必須已被創建，而其本身無法根據分區字段實時動態創建分區。這里有兩種方法解決：
-
可以根據建表語句properties配置中的參數開啟動態分區功能，讓StarRocks調用底層常駐線程預創建分區；
-
可以關閉StarRocks的動態分區，通過數據平臺執行預定義SQL語句進行分區創建操作。
在刷數的時候，對于特定歷史分區的刷數操作，可以使用StarRocks的臨時分區功能實現無感刷數。
3、查詢
我們所使用的
BI
報表工具，對
前端
報表查詢控件的操作都會在底層轉化成預定義的 SQL 向 StarRocks 查詢，返回結果再進行 Web 渲染。由于采用的是自動生成的 SQL 語句，需要注意在 SQL 生成的過程中，是否對表的索引字段自動添加了轉換函數，從而導致索引失效的情況。
4、性能效果
報表上線后，我們對實際的查詢效果也做了持續的觀察和分析。包括復雜查詢在內，總體 99% 查詢延時在150ms左右，QPS 9000+的高并發場景下仍能較為穩定執行，達到了導入的預期效果。
?
實時探索
1、兼容測試
實時團隊也測試了 Flink+StarRocks 的兼容性，憑借官方的 Flink-connector-starrocks 依賴，可以很好實現實時需求的改造。不過需要注意的是：
-
1.11 版本的依賴沒有 Source 讀取方法，仍需使用 JDBC 讀取。
-
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 版本已開始支持并逐步完善多表物化視圖功能。
?
實踐總結
優點
-
性能卓越：StarRocks 的單表性能不輸 ClickHouse，多表 Join 的延時對比我們現有的的組件又有著較大優勢，即便不做特定的優化，也能有較好表現，這是十分難得的。
-
運維簡單：StarRocks 舍棄了傳統多組件的架構形式， FE +BE 的結構十分精簡，部署較為便捷。而運行上的穩定可靠，使得對運維的資源消耗非常低。
-
插件豐富：開發者維護了一些較為實用的插件和工具，可以進行一鍵部署、日志結構化等。如果這些功能后期能夠穩定嵌入 StarRocks 后續 版本 中，應該可以更好優化使用體驗。
-
社區活躍：開源社區有長期穩定版和快速迭代版可以自由選擇，版本升級操作也較為容易。同時有中文社區論壇和官方群可以隨時進行問題反饋獲得答疑，這一點是要勝過很多競品的。
不足
這里基于 2.1.6 版本提出兩點使用中的困擾：
-
權限管理不足：StarRocks 的用戶角色功能有待改善，例如該版本只能在創建用戶時授予角色，不能授予用戶多角色，刪除角色后用戶權限依然保留。慶幸的是，在不久后的 3.0 版本中，StarRocks 將實現完整的 RBAC ，并豐富更多權限項目，從而解決這一問題。
-
預計算功能泛用性不強：物化視圖作為預計算的特色功能，運用場景較為基礎，條條框框局限過多，比如不能實現多列聚合運算，不能實現多表 Join 等，使用起來難以做到如臂使指的效果。StarRocks 2.4 版本的異步物化視圖功能已經在逐步解決這一困擾。
?
我們通過實踐發現，StarRocks 能夠很好地解決大潤發數據分析中的一些痛點問題，能夠解決問題的工具就是好工具。StarRocks 以其優異的特性，得到大潤發數據團隊的一致好評。而其開發團隊從善如流的服務態度，高效迭代的技術努力，無不彰顯著他們在這片市場耕耘的勃勃雄心，相信 StarRocks 在不遠的未來，能夠結出他們所期待的光明。
|
- 上一條： 百度工程師教你玩轉設計模式（裝飾器模式） 2022-12-23
- 下一條： 當談論 React hook，我們究竟說的是什么？ 2022-12-23
相關文章
- 借力StarRocks，"陸戰之王"大潤發如何在零售業數字化轉型中搶占先機？ 2022-12-23
- 從數據治理到數據應用，制造業企業如何突破數字化轉型困境丨行業方案 2022-12-16
- MongoDB在騰訊零售優碼中的應用 2022-06-27
- Tapdata 楊哲軒：如何在零售行業實施主數據治理？ 2022-08-31
- 數字化轉型中的DevOps——數字可視 2021-11-13
熱度排行
