导读
茶理宜世 CHARLIE'S TEA 创立于 2015 年，是新式江南鲜茶品牌，将传统茶文化与现代潮流相结合。
作为国内领先的生活服务茶饮品牌，茶理宜世在多业务协同与实时洞察场景下，对数据分析性能和系统稳定性提出了更高要求。通过引入云器Lakehouse构建一站式大数据平台，茶理宜世成功实现了：
- 维护成本降低 60% ： 一键式部署和运维，不再需要单独维护多个组件
- 性能提升 ： 单引擎覆盖多种业务场景
- 离线 ETL 性能提升 2 倍
- BI 查询性能平均提升 20%-30%
- 开发效率提升 ： 一站式平台完成数据分析和报表开发
- 弹性扩展 ： 按需弹性扩缩容，支撑业务快速增长
客户证言
云器 Lakehouse 帮助我们在尽量控制迁移风险和成本的前提下，完成了数据平台的整体升级与架构优化。平台在稳定性和性能层面均有明显提升，运维成本下降约 60%，同时也显著降低了日常运维和故障处理的复杂度。
更重要的是，数据团队得以从大量基础设施维护和性能调优工作中解放出来，将更多精力投入到业务数据建模、分析能力建设以及对经营决策的支持上。随着查询性能的持续提升，BI 报表的响应速度和交互体验得到明显改善，数据分析逐步从"可用"走向"好用"。
—— 茶理宜世 大数据负责人
现状与痛点
1.1 架构背景
随着门店数量持续增长，数据规模同步扩大。为了分析用户行为、优化运营策略、提升服务质量，茶理宜世早期自建了一套大数据平台。
原有架构 ：
- 数据源 ： MySQL 生产数据库
- 数据同步 ： 源库小时级同步到茶理宜世自建 MySQL
- 数据处理层 ： DataX 天级同步至 StarRocks 集群
- 数据加工 ： StarRocks 中按 ODS→DWD→ADS 分层加工（天级离线）
- 数据消费 ： 帆软 BI 通过 JDBC 连接读取数据，生成可视化报表
1.2 核心问题
业务规模扩大后，数据平台暴露出以下核心痛点：
问题一 ： 自建运维负担重
- MySQL、DataX、StarRocks 等组件需要专人维护，缺乏自动化运维能力，人力占用大
- StarRocks 集群资源固定，高峰期性能不足、低谷期资源闲置
- 数据同步和任务调度开发成本高
问题二 ： 数据源分散，缺乏统一集成方案和数仓模型
- 数据源散落在不同系统
- 缺乏统一的企业级数据仓库模型
- 链路复杂导致数据模型管理困难，影响决策准确性
升级选型：为什么选云器 Lakehouse
2.1 关键选型因素
经过内部评估，茶理宜世明确了以下核心诉求：
| 关键能力分类 | NO. | 关键项 | 说明 |
|---|---|---|---|
| 已有能力保持及优化 | 1 | 多数据源接入能力 | 需要支持MySQL、Kafka、Oracle、API 等多种数据源的接入方式，并将各服务统一的数据进行实时或批量摄入Lakehouse中 |
| 2 | 高效的数据存储与计算 | 需要对大量数据进行高效存储和管理、计算等操作 | |
| 3 | 统一的企业级数据仓库模型 | 使用Lakehouse建立统一的企业级数据仓库模型 | |
| 4 | BI报表开发工具集成 | 集成BI工具，快速搭建各类数据分析报告和仪表板，为决策提供有力支持 | |
| 新一代湖仓平台能力建设 | 5 | Serverless弹性能力 | 业务波动大，需要资源能够灵活弹缩，按需计费 |
| 6 | 兼容Spark/Mysql SQL | 现有 大部分数据开发基于Starrocks SQL，新引擎需要兼容主流SQL方言 | |
| 7 | 存算分离架构 | 降低存储成本，计算资源可独立扩展 | |
| 运维负担 | 8 | 全托管、零运维 | 将工程师从集群管理、参数调优等事务中解放出来，专注于业务价值创造 |
| 9 | 高可用保障 | 平台需要具备自动故障转移、数据备份等高可用能力 |
2.2 方案选择
在评估继续使用自建 StarRocks、迁移到其他开源方案等选项后，团队最终选择引入 云器 Lakehouse 作为新一代一体化湖仓平台的核心。
云器 Lakehouse 方案的核心优势 ：
| 需求维度 | 云器Lakehouse解决方案 |
|---|---|
| 数据接入 | 1. 通过云器提供的多种数据源连接方式（如Kafka、MySQL、Oracle等），将各服务统一的数据进行实时或批量摄入Lakehouse中2. 支持多表实时、多表合并（分库分表合并的场景）、整库离线等多种同步方式3. 可视化点点点快速配置完成开发 |
| 数据存储与计算 | 1. 统一流批交互，真Kappa架构以增量计算新模式支持的Single Engine • 高效开发：完整SQL语法/UDF支持，与离线SQL开发基本一致； • 大规模&低成本：湖仓存储状态支持大规模扩展；自动增量优化显著降低资源成本。 • 灵活：申明式开发范式，一次开发、流批可调2. 原生存算分离架构 |
| 统一数仓模型 | 1. 使用Lakehouse建立统一的企业级数据仓库模型2.1>N 引擎消除冗余计算，减少数据口径误差 |
| BI集成 | 1. 提供Python SDK/JDBC，集成简单，1个人一周内就可以完成2. 兼容多种BI工具（帆软、Tableau、观远 BI等） |
| 弹性能力 | 1. 纯Serverless，按需弹性；而且实现秒级弹缩，弹性性能更极致，收费可以精确到1分钟2. 用资源才收费，不用不收费，成本大幅降低 |
| SQL兼容性 | 1. 兼容Spark SQL2. 兼容Presto 、Mysql、PostgreSQL等 sql 方言 |
| 湖仓能力 | 1. 天然湖仓一体架构，一个引擎同时支持离线加工、基于增量计算的实时加工、实时分析等多场景2. 有很好的开放性，兼容Iceberg、Parquet、HMS等，可被外部引擎消费 |
| 运维负担 | 全托管，零运维，无需关心底层基础设施 |
云器 Lakehouse 方案介绍
3.1 新架构设计
基于云器 Lakehouse，茶理宜世重构了数据平台架构。
第一阶段架构：快速迁移，简化运维
与原架构对比：
-
简化运维 ： 原来的
MySQL 同步 → DataX → StarRocks 三段全部需要自运维，现简化为：只运维数据接入端的自建 MySQL，其余交给免运维的云器 LakehouseMySQL 同步 → DataX → StarRocks -
统一平台、多源集成
- 灵活接入 ： MySQL、Oracle、API 等数据源均通过 Studio 数据集成统一接入。接入、推送、存储、计算、建模全部在一个平台完成
- 工具链完善 ： 涵盖数据集成、开发、运维、调度、监控、质量、权限、数据资产、AI、DataGPT 等全套工具链
-
弹性资源 ： 从固定资源（3 台 16 core / 128 G）改为按需弹性的 Serverless 模式
-
数据质量与治理增强
- 全链路监控 ： Studio 提供完整的数据监控和质量管理，及时发现异常
- 权限管控 ： 细粒度权限管理，保障数据安全合规
- 资产化管理 ： 数据资产管理让数据价值可视化、可衡量
-
统一查询引擎
- Single Engine ： 单引擎统一处理 OLTP 和 OLAP 查询
- 标准 SQL ： 完全兼容 Spark SQL 及 Presto、Hive、MySQL 等方言，支持 BI 工具 JDBC 连接，应用迁移零改造
- 智能优化 ： 自动索引、智能缓存等优化，缩短复杂查询响应时间
同时新增AI 能力，降低数据分析门槛
- DataGPT / Copilot ： 业务人员用自然语言提问即可获取数据洞察，无需编写复杂 SQL
- 智能 SQL 生成 ： DataGPT 自动把业务问题翻译为优化后的 SQL，分析效率提升 5 倍以上
- 自动化洞察 ： AI 自动识别数据趋势、异常和关联模式，为运营决策提供建议
- 降低门槛 ： 非技术人员也能快速完成数据查询和分析
第二阶段架构：基于 Lakehouse 的业务架构演进
架构升级对比：从分散到统一
- 原架构痛点 ： 数据孤岛、处理滞后。外部数据源经 API 批量写入 MySQL，再小时级同步到自建 MySQL，最后同步到云器 Lakehouse。链路过长导致时效性差，无法支撑实时业务决策。
新架构价值：实时性大幅提升，业务决策更及时
- 对比原架构 ： 小时级同步 → 实时同步。API、Oracle 等多源数据通过 Studio 数据集成直接接入，消除中间环节，数据延迟从小时级降到秒级 / 分钟级
- 增量计算升级 ： 原离线天级批处理改造为"实时集成 + 增量计算"，报表更新从 T+1 提升到准实时
3.2 关键能力实现
3.2.1 数据接入：两种方式灵活选择
云器 Lakehouse 提供两种数据接入方式：
方式一：SQL 方式
以对象存储为例：
--创建volume, 用于映射对象存储目录 CREATE EXTERNAL VOLUME pipe_volume location 'oss://ossmy/autoloader/pipe/' using connection my_connection_exnet directory = ( enable=true, auto_refresh=true ) recursive=true; -- 创建实时同步任务 create pipe volume_pipe_list_purge VIRTUAL_CLUSTER = 'default' --执行获取最新文件使用扫描文件模式 INGEST_MODE = 'LIST_PURGE' as copy into pipe_purge_mode from volume pipe_volume(id int,col string) using csv OPTIONS( 'header'='false' ) --必须添加purge参数导入成功后删除数据 purge=true ;
方式二：界面化配置
- 在云器 Studio 可视化界面即可配置实时同步（对象存储、Kafka 等）和 30+ 数据源的批量导入导出
- 支持全量 + 增量同步
- 自动化字段映射，无需手动维护类似 DataX 的配置
3.2.2 BI集成：支持多种连接方式，无缝对接BI
3.3 迁移实施
迁移策略：平滑过渡，零业务中断
- 第一阶段：验证测试（2 周）
- 在云器 Lakehouse 构建测试任务
- 同步部分历史数据做功能验证
- BI 报表对比测试
- 第二阶段：并行运行（1 周）
- 新老系统并行、双写数据
- 逐步将 BI 报表切换到新平台
- 监控性能和稳定性
- 第三阶段：全量切换（1 周）
- 完成所有业务迁移
- 下线旧 StarRocks 集群
- 释放运维资源
总迁移周期：4 周
实际收益
基于生产环境数据，云器 Lakehouse 为茶理宜世带来了以下业务价值：
4.1 维护成本降低 60%+
成本对比 ：
| 成本项 | 迁移前（自建StarRocks） | 迁移后（云器Lakehouse） | 节省 |
|---|---|---|---|
| 基础设施成本 | 3台服务器（16core 128G） | Serverless按需计费 | 60% |
| 运维人力成本 | 1名专职DBA 50%工作量 | 零运维 偶尔配置调整 | 80% |
| DataX、Starrocks维护成本 | 脚本、组件维护 | 无需维护 | 100% |
综合成本降低 60% 以上
4.2 性能提升：查询响应提速 3-5 倍
ETL 任务对比测试
测试背景：
- 业务场景 ： 门店经营分析看板的核心查询，按门店、商品品类、时段、营销活动等维度复盘销售与会员消费数据
- SQL 结构 ： 订单事实表 JOIN 门店、商品、会员、营销活动等多张维度表；商品名使用 LIKE 模糊匹配，门店 ID 使用大 IN 列表过滤；输出 15+ 业务维度聚合
- 数据规模 ： 亿级订单明细
- 对照口径 ： 任务一、任务二为同一 SQL，仅时间范围筛选不同（1 年 vs 半年）
| 时间范围 | sr | lakehouse | 提升点 | |
|---|---|---|---|---|
| 规格 | 16c/128G * 3 =48C /384G | 32C/128G | 使用更少的资源(减少33%)实现更好的性能 | |
| 任务一 | 1 年 | 2min 左右 | 1min 左右 | 2 倍性能提升 |
| 任务二 | 半年 | 1min 10s 左右 | 35s 左右 | 2 倍性能提升 |
4.3 开发效率提升
- 一个平台完成数据接入、存储、建模、计算、推送全流程，任务链开发复杂度显著下降
- 可视化数据接入和运维降低了开发难度，缩短了接入时间
4.4 弹性支撑业务发展
- 高峰期自动扩容 ： 促销活动期间查询并发从 50 QPS 升至 200 QPS，系统自动扩容，业务稳定
- 低谷期成本优化 ： 闲时自动缩容，节省成本
- 快速响应需求 ： 可视化操作缩短新增数据源接入时间
总结与展望
5.1 项目总结
茶理宜世通过引入云器 Lakehouse，完成了从自建 StarRocks 到云原生湖仓的升级：
- ✅ 一站式平台 ： 数据接入、存储、计算、BI 一体化，告别多组件维护
- ✅ 显著降本 ： 基础设施成本降低 60%，运维人力成本降低 80%
- ✅ 性能提升 ： BI 查询响应提升 20%-30%，用户体验明显改善
- ✅ 弹性伸缩 ： Serverless 架构按需计费，灵活应对业务波动
- ✅ 开发提效 ： 一站式开发环境，效率显著提升
5.2 未来展望
基于云器 Lakehouse，茶理宜世计划进一步拓展数据平台的应用场景：
- 实时数据分析 ： 引入流式计算，实现秒级数据洞察
- 数据科学平台 ： 构建机器学习平台，落地用户画像、销量预测等 AI 场景
- 数据治理体系 ： 完善数据质量、血缘、安全管理体系
- 多云部署 ： 基于云器 Lakehouse 多云能力，实现跨云数据协同
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
