導(dǎo)讀茶理宜世 CHARLIES TEA 創(chuàng)立于 2015 年是新式江南鮮茶品牌將傳統(tǒng)茶文化與現(xiàn)代潮流相結(jié)合。作為國內(nèi)領(lǐng)先的生活服務(wù)茶飲品牌茶理宜世在多業(yè)務(wù)協(xié)同與實時洞察場景下對數(shù)據(jù)分析性能和系統(tǒng)穩(wěn)定性提出了更高要求。通過引入云器Lakehouse構(gòu)建一站式大數(shù)據(jù)平臺茶理宜世成功實現(xiàn)了維護(hù)成本降低 60%一鍵式部署和運維不再需要單獨維護(hù)多個組件性能提升單引擎覆蓋多種業(yè)務(wù)場景離線 ETL 性能提升 2 倍BI 查詢性能平均提升 20%-30%開發(fā)效率提升一站式平臺完成數(shù)據(jù)分析和報表開發(fā)彈性擴(kuò)展按需彈性擴(kuò)縮容支撐業(yè)務(wù)快速增長客戶證言云器 Lakehouse 幫助我們在盡量控制遷移風(fēng)險和成本的前提下完成了數(shù)據(jù)平臺的整體升級與架構(gòu)優(yōu)化。平臺在穩(wěn)定性和性能層面均有明顯提升運維成本下降約 60%同時也顯著降低了日常運維和故障處理的復(fù)雜度。更重要的是數(shù)據(jù)團(tuán)隊得以從大量基礎(chǔ)設(shè)施維護(hù)和性能調(diào)優(yōu)工作中解放出來將更多精力投入到業(yè)務(wù)數(shù)據(jù)建模、分析能力建設(shè)以及對經(jīng)營決策的支持上。隨著查詢性能的持續(xù)提升BI 報表的響應(yīng)速度和交互體驗得到明顯改善數(shù)據(jù)分析逐步從可用走向好用?！?茶理宜世 大數(shù)據(jù)負(fù)責(zé)人現(xiàn)狀與痛點1.1 架構(gòu)背景隨著門店數(shù)量持續(xù)增長數(shù)據(jù)規(guī)模同步擴(kuò)大。為了分析用戶行為、優(yōu)化運營策略、提升服務(wù)質(zhì)量茶理宜世早期自建了一套大數(shù)據(jù)平臺。原有架構(gòu)數(shù)據(jù)源MySQL 生產(chǎn)數(shù)據(jù)庫數(shù)據(jù)同步源庫小時級同步到茶理宜世自建 MySQL數(shù)據(jù)處理層DataX 天級同步至 StarRocks 集群數(shù)據(jù)加工StarRocks 中按 ODS→DWD→ADS 分層加工天級離線數(shù)據(jù)消費帆軟 BI 通過 JDBC 連接讀取數(shù)據(jù)生成可視化報表1.2 核心問題業(yè)務(wù)規(guī)模擴(kuò)大后數(shù)據(jù)平臺暴露出以下核心痛點問題一自建運維負(fù)擔(dān)重MySQL、DataX、StarRocks 等組件需要專人維護(hù)缺乏自動化運維能力人力占用大StarRocks 集群資源固定高峰期性能不足、低谷期資源閑置數(shù)據(jù)同步和任務(wù)調(diào)度開發(fā)成本高問題二數(shù)據(jù)源分散缺乏統(tǒng)一集成方案和數(shù)倉模型數(shù)據(jù)源散落在不同系統(tǒng)缺乏統(tǒng)一的企業(yè)級數(shù)據(jù)倉庫模型鏈路復(fù)雜導(dǎo)致數(shù)據(jù)模型管理困難影響決策準(zhǔn)確性升級選型為什么選云器Lakehouse2.1 關(guān)鍵選型因素經(jīng)過內(nèi)部評估茶理宜世明確了以下核心訴求關(guān)鍵能力分類NO.關(guān)鍵項說明已有能力保持及優(yōu)化1多數(shù)據(jù)源接入能力需要支持MySQL、Kafka、Oracle、API 等多種數(shù)據(jù)源的接入方式并將各服務(wù)統(tǒng)一的數(shù)據(jù)進(jìn)行實時或批量攝入Lakehouse中2高效的數(shù)據(jù)存儲與計算需要對大量數(shù)據(jù)進(jìn)行高效存儲和管理、計算等操作3統(tǒng)一的企業(yè)級數(shù)據(jù)倉庫模型使用Lakehouse建立統(tǒng)一的企業(yè)級數(shù)據(jù)倉庫模型4BI報表開發(fā)工具集成集成BI工具快速搭建各類數(shù)據(jù)分析報告和儀表板為決策提供有力支持新一代湖倉平臺能力建設(shè)5Serverless彈性能力業(yè)務(wù)波動大需要資源能夠靈活彈縮按需計費6兼容Spark/Mysql SQL現(xiàn)有 大部分?jǐn)?shù)據(jù)開發(fā)基于Starrocks SQL新引擎需要兼容主流SQL方言7存算分離架構(gòu)降低存儲成本計算資源可獨立擴(kuò)展運維負(fù)擔(dān)8全托管、零運維將工程師從集群管理、參數(shù)調(diào)優(yōu)等事務(wù)中解放出來專注于業(yè)務(wù)價值創(chuàng)造9高可用保障平臺需要具備自動故障轉(zhuǎn)移、數(shù)據(jù)備份等高可用能力2.2 方案選擇在評估繼續(xù)使用自建 StarRocks、遷移到其他開源方案等選項后團(tuán)隊最終選擇引入云器 Lakehouse作為新一代一體化湖倉平臺的核心。云器 Lakehouse 方案的核心優(yōu)勢需求維度云器Lakehouse解決方案數(shù)據(jù)接入1. 通過云器提供的多種數(shù)據(jù)源連接方式如Kafka、MySQL、Oracle等將各服務(wù)統(tǒng)一的數(shù)據(jù)進(jìn)行實時或批量攝入Lakehouse中2. 支持多表實時、多表合并分庫分表合并的場景、整庫離線等多種同步方式3. 可視化點點點快速配置完成開發(fā)數(shù)據(jù)存儲與計算1. 統(tǒng)一流批交互真Kappa架構(gòu)以增量計算新模式支持的Single Engine高效開發(fā)完整SQL語法/UDF支持與離線SQL開發(fā)基本一致大規(guī)模低成本湖倉存儲狀態(tài)支持大規(guī)模擴(kuò)展自動增量優(yōu)化顯著降低資源成本。靈活申明式開發(fā)范式一次開發(fā)、流批可調(diào)2. 原生存算分離架構(gòu)統(tǒng)一數(shù)倉模型1. 使用Lakehouse建立統(tǒng)一的企業(yè)級數(shù)據(jù)倉庫模型2.1N 引擎消除冗余計算減少數(shù)據(jù)口徑誤差BI集成1. 提供Python SDK/JDBC集成簡單1個人一周內(nèi)就可以完成2. 兼容多種BI工具帆軟、Tableau、觀遠(yuǎn) BI等彈性能力1. 純Serverless按需彈性而且實現(xiàn)秒級彈縮彈性性能更極致收費可以精確到1分鐘2. 用資源才收費不用不收費成本大幅降低SQL兼容性1. 兼容Spark SQL2. 兼容Presto 、Mysql、PostgreSQL等 sql 方言湖倉能力1. 天然湖倉一體架構(gòu)一個引擎同時支持離線加工、基于增量計算的實時加工、實時分析等多場景2. 有很好的開放性兼容Iceberg、Parquet、HMS等可被外部引擎消費運維負(fù)擔(dān)全托管零運維無需關(guān)心底層基礎(chǔ)設(shè)施云器 Lakehouse 方案介紹3.1 新架構(gòu)設(shè)計基于云器 Lakehouse茶理宜世重構(gòu)了數(shù)據(jù)平臺架構(gòu)。第一階段架構(gòu)快速遷移簡化運維與原架構(gòu)對比簡化運維原來的 MySQL 同步 → DataX → StarRocks 三段全部需要自運維現(xiàn)簡化為只運維數(shù)據(jù)接入端的自建 MySQL其余交給免運維的云器 Lakehouse統(tǒng)一平臺、多源集成靈活接入MySQL、Oracle、API 等數(shù)據(jù)源均通過 Studio 數(shù)據(jù)集成統(tǒng)一接入。接入、推送、存儲、計算、建模全部在一個平臺完成工具鏈完善涵蓋數(shù)據(jù)集成、開發(fā)、運維、調(diào)度、監(jiān)控、質(zhì)量、權(quán)限、數(shù)據(jù)資產(chǎn)、AI、DataGPT 等全套工具鏈彈性資源從固定資源3 臺 16 core / 128 G改為按需彈性的 Serverless 模式數(shù)據(jù)質(zhì)量與治理增強(qiáng)全鏈路監(jiān)控Studio 提供完整的數(shù)據(jù)監(jiān)控和質(zhì)量管理及時發(fā)現(xiàn)異常權(quán)限管控細(xì)粒度權(quán)限管理保障數(shù)據(jù)安全合規(guī)資產(chǎn)化管理數(shù)據(jù)資產(chǎn)管理讓數(shù)據(jù)價值可視化、可衡量統(tǒng)一查詢引擎Single Engine單引擎統(tǒng)一處理 OLTP 和 OLAP 查詢標(biāo)準(zhǔn) SQL完全兼容 Spark SQL 及 Presto、Hive、MySQL 等方言支持 BI 工具 JDBC 連接應(yīng)用遷移零改造智能優(yōu)化自動索引、智能緩存等優(yōu)化縮短復(fù)雜查詢響應(yīng)時間同時新增AI 能力降低數(shù)據(jù)分析門檻DataGPT / Copilot業(yè)務(wù)人員用自然語言提問即可獲取數(shù)據(jù)洞察無需編寫復(fù)雜 SQL智能 SQL 生成DataGPT 自動把業(yè)務(wù)問題翻譯為優(yōu)化后的 SQL分析效率提升 5 倍以上自動化洞察AI 自動識別數(shù)據(jù)趨勢、異常和關(guān)聯(lián)模式為運營決策提供建議降低門檻非技術(shù)人員也能快速完成數(shù)據(jù)查詢和分析第二階段架構(gòu)基于 Lakehouse 的業(yè)務(wù)架構(gòu)演進(jìn)架構(gòu)升級對比從分散到統(tǒng)一原架構(gòu)痛點數(shù)據(jù)孤島、處理滯后。外部數(shù)據(jù)源經(jīng) API 批量寫入 MySQL再小時級同步到自建 MySQL最后同步到云器 Lakehouse。鏈路過長導(dǎo)致時效性差無法支撐實時業(yè)務(wù)決策。新架構(gòu)價值實時性大幅提升業(yè)務(wù)決策更及時對比原架構(gòu)小時級同步 → 實時同步。API、Oracle 等多源數(shù)據(jù)通過 Studio 數(shù)據(jù)集成直接接入消除中間環(huán)節(jié)數(shù)據(jù)延遲從小時級降到秒級 / 分鐘級增量計算升級原離線天級批處理改造為實時集成 增量計算報表更新從 T1 提升到準(zhǔn)實時3.2 關(guān)鍵能力實現(xiàn)3.2.1 數(shù)據(jù)接入兩種方式靈活選擇云器 Lakehouse 提供兩種數(shù)據(jù)接入方式方式一SQL 方式以對象存儲為例--創(chuàng)建volume, 用于映射對象存儲目錄 CREATE EXTERNAL VOLUME pipe_volume location oss://ossmy/autoloader/pipe/ using connection my_connection_exnet directory ( enabletrue, auto_refreshtrue ) recursivetrue; -- 創(chuàng)建實時同步任務(wù) create pipe volume_pipe_list_purge VIRTUAL_CLUSTER default --執(zhí)行獲取最新文件使用掃描文件模式 INGEST_MODE LIST_PURGE as copy into pipe_purge_mode from volume pipe_volume(id int,col string) using csv OPTIONS( headerfalse ) --必須添加purge參數(shù)導(dǎo)入成功后刪除數(shù)據(jù) purgetrue ;方式二界面化配置在云器 Studio 可視化界面即可配置實時同步對象存儲、Kafka 等和 30 數(shù)據(jù)源的批量導(dǎo)入導(dǎo)出支持全量 增量同步自動化字段映射無需手動維護(hù)類似 DataX 的配置3.2.2 BI集成支持多種連接方式無縫對接BI3.3 遷移實施遷移策略平滑過渡零業(yè)務(wù)中斷1. 第一階段驗證測試2 周在云器 Lakehouse 構(gòu)建測試任務(wù)同步部分歷史數(shù)據(jù)做功能驗證BI 報表對比測試2. 第二階段并行運行1 周新老系統(tǒng)并行、雙寫數(shù)據(jù)逐步將 BI 報表切換到新平臺監(jiān)控性能和穩(wěn)定性3. 第三階段全量切換1 周完成所有業(yè)務(wù)遷移下線舊 StarRocks 集群釋放運維資源總遷移周期4 周實際收益基于生產(chǎn)環(huán)境數(shù)據(jù)云器 Lakehouse 為茶理宜世帶來了以下業(yè)務(wù)價值4.1 維護(hù)成本降低 60%成本對比成本項遷移前自建StarRocks遷移后云器Lakehouse節(jié)省基礎(chǔ)設(shè)施成本3臺服務(wù)器16core 128GServerless按需計費60%運維人力成本1名專職DBA 50%工作量零運維偶爾配置調(diào)整80%DataX、Starrocks維護(hù)成本腳本、組件維護(hù)無需維護(hù)100%綜合成本降低 60% 以上4.2 性能提升查詢響應(yīng)提速 3-5 倍ETL 任務(wù)對比測試測試背景業(yè)務(wù)場景門店經(jīng)營分析看板的核心查詢按門店、商品品類、時段、營銷活動等維度復(fù)盤銷售與會員消費數(shù)據(jù)SQL 結(jié)構(gòu)訂單事實表 JOIN 門店、商品、會員、營銷活動等多張維度表商品名使用 LIKE 模糊匹配門店 ID 使用大 IN 列表過濾輸出 15 業(yè)務(wù)維度聚合數(shù)據(jù)規(guī)模億級訂單明細(xì)對照口徑任務(wù)一、任務(wù)二為同一 SQL僅時間范圍篩選不同1 年 vs 半年時間范圍srlakehouse提升點規(guī)格16c/128G * 3 48C /384G32C/128G使用更少的資源(減少33%)實現(xiàn)更好的性能任務(wù)一1 年2min 左右1min 左右2 倍性能提升任務(wù)二半年1min 10s 左右35s 左右2 倍性能提升4.3 開發(fā)效率提升一個平臺完成數(shù)據(jù)接入、存儲、建模、計算、推送全流程任務(wù)鏈開發(fā)復(fù)雜度顯著下降可視化數(shù)據(jù)接入和運維降低了開發(fā)難度縮短了接入時間4.4 彈性支撐業(yè)務(wù)發(fā)展高峰期自動擴(kuò)容促銷活動期間查詢并發(fā)從 50 QPS 升至 200 QPS系統(tǒng)自動擴(kuò)容業(yè)務(wù)穩(wěn)定低谷期成本優(yōu)化閑時自動縮容節(jié)省成本快速響應(yīng)需求可視化操作縮短新增數(shù)據(jù)源接入時間總結(jié)與展望5.1 項目總結(jié)茶理宜世通過引入云器 Lakehouse完成了從自建 StarRocks 到云原生湖倉的升級? 一站式平臺數(shù)據(jù)接入、存儲、計算、BI 一體化告別多組件維護(hù)? 顯著降本基礎(chǔ)設(shè)施成本降低 60%運維人力成本降低 80%? 性能提升BI 查詢響應(yīng)提升 20%-30%用戶體驗明顯改善? 彈性伸縮Serverless 架構(gòu)按需計費靈活應(yīng)對業(yè)務(wù)波動? 開發(fā)提效一站式開發(fā)環(huán)境效率顯著提升5.2 未來展望基于云器 Lakehouse茶理宜世計劃進(jìn)一步拓展數(shù)據(jù)平臺的應(yīng)用場景實時數(shù)據(jù)分析引入流式計算實現(xiàn)秒級數(shù)據(jù)洞察數(shù)據(jù)科學(xué)平臺構(gòu)建機(jī)器學(xué)習(xí)平臺落地用戶畫像、銷量預(yù)測等 AI 場景數(shù)據(jù)治理體系完善數(shù)據(jù)質(zhì)量、血緣、安全管理體系多云部署基于云器 Lakehouse 多云能力實現(xiàn)跨云數(shù)據(jù)協(xié)同云器科技官網(wǎng) - 改變數(shù)據(jù)的使用方式更多內(nèi)容歡迎關(guān)注「云器科技」官網(wǎng)云器科技-多云及一體化數(shù)據(jù)平臺提供