1. StarRocks技术选型背景
作为国内领先的在线旅游服务平台，去哪儿网每天需要处理数十亿级别的用户查询请求，涵盖机票、酒店、景点等业务的实时数据分析和交互式查询。传统基于Hadoop的离线数仓方案存在明显的查询延迟问题，而MPP数据库在复杂分析场景下又面临性能瓶颈。
我们最终选择StarRocks作为新一代实时分析引擎，主要基于以下技术考量：
- 实时分析需求：业务部门要求90%的查询响应时间控制在秒级，特别是动态定价、实时风控等场景需要亚秒级响应
- 高并发挑战：大促期间QPS峰值超过5000，需要支持至少200并发查询稳定运行
- 数据新鲜度：从数据产生到可查询的时间间隔要求控制在1分钟以内
- 成本效率：相同查询性能下，硬件成本需比原有方案降低30%以上
2. 核心架构设计与优化
2.1 分布式集群部署方案
我们采用混合部署模式，将集群划分为3种节点类型：
graph TD A[FE节点] --> B[BE节点] A --> C[Broker节点] B --> D[对象存储] C --> D具体配置参数：
- FE节点：16C64G * 3（1 Leader + 2 Follower）
- BE节点：32C128G * 12（每个节点配8*1TB NVMe SSD）
- Broker节点：8C32G * 2（对接S3兼容存储）
关键优化点：
- FE高可用：通过Apache ZooKeeper实现元数据自动故障转移
- BE数据分布：采用3副本策略，结合机房拓扑感知配置
- 冷热数据分层：
- 热数据：保留最近7天，存放BE本地SSD
- 温数据：7-30天，存放本地HDD
- 冷数据：30天以上，自动下沉到对象存储
2.2 数据模型设计实践
针对旅游行业特点，我们设计了三种数据模型：
- 明细模型（用于订单流水）
CREATE TABLE ods_orders ( order_id BIGINT, user_id BIGINT, product_type VARCHAR(20), amount DECIMAL(18,2), order_time DATETIME, ... ) DUPLICATE KEY(order_id) PARTITION BY RANGE(order_time)( PARTITION p202301 VALUES LESS THAN ('2023-02-01'), ... ) DISTRIBUTED BY HASH(order_id) BUCKETS 32 PROPERTIES ( "replication_num" = "3", "storage_medium" = "SSD", "storage_cooldown_time" = "7 days" );- 聚合模型（用于业务指标）
CREATE TABLE dws_sales_agg ( product_type VARCHAR(20), dt DATE, province VARCHAR(50), total_amount DECIMAL(38,2), order_count BIGINT SUM ) AGGREGATE KEY(product_type, dt, province) PARTITION BY RANGE(dt)(...) DISTRIBUTED BY HASH(product_type) BUCKETS 16;- 更新模型（用于用户画像）
CREATE TABLE dim_users ( user_id BIGINT, vip_level INT, last_consume_time DATETIME, consume_amount DECIMAL(18,2), ... ) UNIQUE KEY(user_id) DISTRIBUTED BY HASH(user_id) BUCKETS 24;3. 性能优化实战
3.1 查询加速技术
- 物化视图优化：
-- 创建机票业务的热门航线预聚合 CREATE MATERIALIZED VIEW mv_flight_route_stats REFRESH ASYNC EVERY INTERVAL 1 HOUR AS SELECT departure_city, arrival_city, COUNT(*) AS flight_count, AVG(price) AS avg_price, PERCENTILE_APPROX(price, 0.5) AS median_price FROM dwd_flight_orders GROUP BY departure_city, arrival_city;- Colocate Group应用：
-- 将订单表与用户表绑定存储位置 CREATE TABLE colocate_group ( "colocate_with" = "order_user_group" );- Runtime Filter优化：
SET runtime_filter_type = "BLOOM_FILTER,MIN_MAX"; SET runtime_filter_wait_time_ms = 1000;3.2 资源隔离方案
通过资源组实现关键业务保障：
CREATE RESOURCE GROUP rg_urgent TO (db1.tbl1, db2.tbl2) WITH ( "cpu_core_limit" = "30", "mem_limit" = "40%", "concurrent_limit" = "50", "max_cpu_cores" = "32" );4. 运维监控体系
4.1 监控指标设计
我们搭建了基于Prometheus+Grafana的监控看板，核心监控项包括：
| 指标类别 | 关键指标 | 告警阈值 |
|---|---|---|
| 查询性能 | p99_latency | >3s持续5分钟 |
| 资源使用 | be_mem_usage | >85%持续10分钟 |
| 数据同步 | max_load_lag | >300s |
| 节点健康 | be_unhealthy_tablet_count | >0 |
4.2 自动化运维脚本
- 分区自动管理：
#!/bin/bash # 自动创建未来7天的分区 for i in {1..7}; do dt=$(date -d "+${i} days" +%Y-%m-%d) mysql -h${FE_HOST} -P9030 -uroot -e " ALTER TABLE dwd_orders ADD PARTITION p${dt//-/} VALUES LESS THAN ('${dt} 00:00:00'); " done- 数据平衡检查：
from starrocks.client import Client def check_balance(): fe = Client(host='fe-prod', port=9030) be_stats = fe.execute("SHOW BACKENDS") max_used = max(b['UsedCapacity'] for b in be_stats) min_used = min(b['UsedCapacity'] for b in be_stats) return (max_used - min_used) / max_used < 0.25. 业务价值体现
5.1 性能提升对比
| 指标 | 原系统(Hive+Spark) | StarRocks | 提升幅度 |
|---|---|---|---|
| 平均查询延迟 | 12.8s | 0.78s | 16x |
| 99分位延迟 | 28.4s | 2.1s | 13x |
| 数据新鲜度 | 1小时 | 30秒 | 120x |
| 并发能力 | 150 QPS | 5200 QPS | 34x |
5.2 典型业务场景
- 实时定价系统：
-- 动态计算航线竞争指数 SELECT route_id, CURRENT_PRICE, AVG(price) OVER(PARTITION BY route_id ORDER BY dt RANGE INTERVAL 7 DAY PRECEDING) AS avg_7d, PERCENTILE_CONT(0.5) WITHIN GROUP(ORDER BY price) OVER(...) AS median_price FROM dwd_flight_prices WHERE dep_date BETWEEN NOW() AND DATE_ADD(NOW(), 3 DAY);- 大屏实时监控：
-- 大促期间实时成交看板 SELECT product_type, TIME_FLOOR(event_time, 'INTERVAL 5 SECOND') AS time_slice, COUNT(*) AS order_count, SUM(amount) AS gmv FROM kafka_orders WHERE event_time >= NOW() - INTERVAL 1 HOUR GROUP BY product_type, time_slice ORDER BY time_slice DESC;6. 踩坑经验分享
内存管理问题：
- 现象：BE节点频繁OOM
- 根因：未限制查询内存导致大查询耗尽资源
- 解决：设置
query_mem_limit和load_mem_limit
小文件合并：
-- 定期执行compaction ADMIN SET FRONTEND CONFIG ("enable_auto_compaction" = "true"); ALTER TABLE dwd_orders COMPACT;版本升级注意：
- 重要变更：2.0版本后默认启用CBO
- 升级步骤：
- 先升级FE follower节点
- 滚动升级BE节点
- 最后升级FE leader
7. 未来规划
- 云原生架构演进：测试Kubernetes部署方案
- 智能预聚合：基于查询模式自动优化物化视图
- 多租户隔离：完善资源配额与权限体系
- 向量化计算：评估SIMD指令集加速效果
通过StarRocks的落地，我们构建了支撑千亿级数据分析的实时数据平台，查询性能提升10倍以上的同时，硬件成本降低40%。特别是在2023年春运期间，平稳支撑了单日超8000万次的查询请求，为业务决策提供了实时数据支撑。
