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