QQ音乐数据仓库演进历程与StarRocks实践总结
数据仓库演进史与场景应用
QQ音乐数据仓库经历了从传统模式到StarRocks存算分离模式的演进。演进过程中主要解决了组件多、维护复杂、成本高、恢复周期长等问题。当前主要应用场景包括:
- 监控多维查询:支持实时查询,处理多维度随机数据。
- 访问链路拓扑查询:高并发、高时效性,查询条件相对固化。
- 业务日志流水查询:长时跨度、多维度、低并发。
StarRocks存算分离模式优势
StarRocks模式在TME的实践显著提升了运维效率与性能:
- 运维简化:组件减少,维护简单,排查快速。
- 成本降低:数据份数减少,成本降低50%以上。
- 恢复效率:支持自动冷热分离,恢复周期短。
- 功能增强:支持自定义管理,优化查询性能。
核心场景与集群指标
- 多维分析:集群总平均QPS 600,峰值1600;数据导入峰值3亿条/min。
- 查询性能:秒级响应占比99%。
- 晚高峰数据量:监控场景148w/h,链路拓扑270w/h,日志流水68w/h。
调优与优化措施
- 存储桶打散:提升查询效率。
- 表结构分区:优化数据管理。
- 返回码/接口视图:简化监控。
- 物化视图降维:将原始表高频查询耗时从秒级降至毫秒级,支持自动刷新、分区刷新、Schema Change等特性。
标准化建设与维护模式
- 维护模式:一体化2套,分离化7套。
- 集群升级:秒级监控集群升级至StarRocks。
总结
QQ音乐通过引入StarRocks存算分离模式,显著提升了数据仓库的运维效率、查询性能与成本控制,同时支持多样化业务场景需求,实现标准化与自动化管理。
曹凤龙
腾讯音乐专家工程师,业务运维中心总监
QQ音乐数据仓库的演进历程
StarRocks的存算分离模式在TME的实践
数据仓库的演进史
应用场景与数据服务框架
场景一、监控多维查询
查询维度多,数据随机性强,即实时查询
场景二、访问链路拓扑查询
数据时效性高,并发高,查询条件相对固化
场景三、业务日志流水查询
数据时间跨度长,维度多,并发低
维护数据集群的挑战
组件多、维护复杂、排查慢
Historical发生重启,恢复周期长
数据份数多,成本高
页面查询为主、未开放自定义
组件少,维护简单,排查快
支持自动冷热分离、恢复周期短
数据份数少,成本降50%+
支持自定义管理
监控集群的调优
存储桶打散
表结构分区
返回码视图
接口视图
物化视图降维
晚高峰148w/h条数据
晚高峰270w/h条数据
晚高峰68w/h条数据
秒级监控集群升级SR
物化视图查询优化
表由于原始表包含IP、端口、返回码等维度,数据量级比较大,对原始表做高频查询,查询性能并不能达到预期。
StarRocks的物化视图特性后,对非IP的查询过滤,耗时降低至毫秒级
物化视图特性:自动刷新、分区刷新、Schema Change等
主流场景与集群大盘指标
多维分析
StarRocks套件的标准化建设
维护一体模式2套,分离模式7套
集群总平均QPS 600,峰值1600
数据导入峰值3亿条/min
查询秒级响应占比99%
数据管理的全景图
感谢观看!关注公众号