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