成本下降50%，腾讯音乐StarRocks存算分离大规模实践！

腾讯音乐娱乐集团是中国在线音乐娱乐服务开拓者，提供在线音乐和以音乐为核心的社交娱乐两大服务。腾讯音乐娱乐在中国有着广泛的用户基础，拥有目前国内市场知名的移动音频产品：QQ 音乐、酷狗音乐、酷我音乐、全民 K 歌、懒人听书等产品。

数据基建团队负责搭建集团统一的数据平台，支持数据接入、数据处理、数据查询和数据资产治理等。

腾讯音乐在 2021 年的时候为了响应业务敏捷分析的请求，对原有的数据架构进行了升级。

随着对成本效益的关注不断增加及湖仓一体化技术的不断进步，腾讯音乐开始构建新的湖仓一体架构以进一步达成集团元数据的统一管理和管理效率提升。新的架构除了希望解决之前数据从湖导出至 OLAP 引擎而导致的元数据碎片化问题外，我们还希望通过引入弹性伸缩和分层存储技术来更进一步降本增效。然而，当时以 ClickHouse 和 Druid 组成的架构已经无法满足这些需求：

经过深入分析对比 ClickHouse、Presto 以及 StarRocks，我们得出以下关键结论：

在我们选择 StarRocks 存算分离架构作为我们构建湖仓一体新架构后，面临的首要工作是将原有的 ClickHouse、Druid、Doris 集群的数据进行迁移，而且还要做到业务的无感，对于我们的迁移工作提出了巨大的挑战。

为此，我们在设计迁移方案时，遵循的基本思路是从影响范围由小到大逐渐灰度，实现快速试错快速修复，并将成功经验快速推广。基于这个出发点我们优先选择了 ClickHouse 实时写入子集群作为对象，将其作为切入点。以下是我们的迁移路线图：

ClickHouse 迁移实施

针对问题 1，我们与社区成员紧密合作，进行了广泛的测试，以确定在不同场景下的最佳实践。这些成果将在后续的最佳实践部分详细分享，这里暂时不展开讨论。

针对问题 2，我们的团队开发了一个基于抽象语法树（AST）的 SQL Rewriter，它能够将 ClickHouse SQL 语句改写为 StarRocks SQL。目前，该工具支持包括作用域计算列改写、模糊列消歧、子查询自动添加别名，以及非标复杂语法改写(比如 ClickHouse 独有的窗口从句，ARRAY JOIN 从句，双引号剥离等)。此外，我们还将该项目贡献回了社区，详情可访问StarRocks SQLTransformer（https://github.com/StarRocks/SQLTransformer）。

针对问题 3，为了支持数据关联，我们为 StarRocks 贡献了 ClickHouse JDBC Catalog 功能。通过在 StarRocks 集群中创建 ClickHouse JDBC Catalog，我们能够兼容那些需要关联未迁移数据的查询。

在线上查询流量迁移的过程中，融合查询网关可以自动将已迁移至 StarRocks 数据的查询路由到 StarRocks 集群，完美地实现业务查询无感替换。

（融合查询网关同时兼容历史 ClickHouse 查询和 StarRocks 查询）

在具体实施的时候我们考虑到当前实时集群的成本是离线的两倍，而实时表的数量是离线表的十分之一，在切换的过程中网关也需要做多源改造，可能对用户产生影响，我们决定从影响范围最小、收益最大的实时集群开始切换。这一策略旨在逐步迁移各个子集群，并在此过程中积累对 StarRocks 的实践经验。

面对规模达数百台机器的 ClickHouse 和 Druid 集群，我们的团队需要精心规划，以逐步、平稳地将业务迁移至 StarRocks，同时确保整个过程中业务的连续性和用户体验的无缝性。在查询网关层面，实现智能查询路由，确保已迁移的表查询能够无缝切换至 StarRocks 集群，或在必要时回滚至 ClickHouse。在写入层面，实施 ClickHouse 和 StarRocks 的双写策略，确保数据的实时同步。在 StarRocks 集群稳定运行后，停止向 ClickHouse 写入数据。

Druid 迁移实施

目前已经有 9 个业务集群从原有的架构统一收敛到了 StarRocks 湖仓一体新架构，我们也进行了阶段性的总结，复盘了升级后给业务带来的价值。

性能不变

我们原先 Druid 的实时查询 P99 在迁移到 StarRocks 后性能表现与原先持平，大表查询都在 4 秒左右；中小表秒级响应。

成本降低

在存储上，我们本地只需要存一份数据，存储成本节约了一半。在运维上，由于新架构是存算分离的，我们可以在方便的通过定时 review 推动业务下线或者缩短数据生命周期的同时快速地缩容集群来节约成本。根据我们的内部估算，替换原有的 ClickHouse 集群后，成本降低了 40%，而替换 Druid 集群后，成本更是减少了超过 50%。

简化运维与快速弹性

由于我们是首次在生产环境中大规模尝试 StarRocks 存算分离新架构的湖仓一体方案，我们在新架构落地过程中也积累了不少的最佳实践，这里探讨一些我们实践过程中积累的经验，相信也会对大家有不小的帮助。

面对业务中存在的多张大表和每日上千亿的数据增量，若所有数据都存储在单一存储桶中，很容易达到带宽上限。为解决这一问题，我们采取了以下策略：

如果观察到合并分数持续上升或 compactions 任务数量持续增加，且这些趋势没有收敛的迹象，这通常意味着合并操作的速度无法跟上数据写入的速度。这时我们要分析是不是写入的batch太小导致写入次数太多，如果是合并的吞吐不够，我们可以考虑增加合并的线程数。具体操作可以参考《极速查询：StarRocks 存算分离 Compaction 原理 & 调优指南》

在某些情况下，如我们所经历的，DataCache 时间和用户查询时间的不匹配可能导致频繁的冷数据读取，这不仅增加了对 COS 下行带宽的压力，甚至在极端情况下可能导致整个集群的响应能力下降。为避免这种情况，我们可以通过 StarRocks 提供的监控工具来跟踪缓存命中率。

另外，在实践中，我们发现到升级到 StarRocks 的新版本后，其默认的 Cache 机制得到了改进。新版本的缓存不仅资源消耗更少，也能更好地控制存储空间占用。通过与 StarRocks 核心研发同学的深入交流，我们对新旧缓存机制的差异有了更全面的认识。对此感兴趣的同学可以参考文章：StarRocks 存算分离 Data Cache 二三事（https://zhuanlan.zhihu.com/p/695673099）。

我们也向官方贡献了自己的成果，如音乐自研的 ClickHouse SQL 改写模块，提交了 ClickHouse JDBC Catalog 的 PR ，并发现了大规模使用中的内存泄漏等潜在问题。此外，我们提出的关于用户体验的建议和需求也得到了社区的积极响应。

在迁移过程中，我们通过表级粒度的放量和回滚控制，以及线上查询流量的重放，逐步推进迁移工作，确保了用户无感知、服务稳定和业务连续性。

目前，我们已经完成了首个实时集群的迁移工作。迁移后的 StarRocks 集群在 P95 查询性能上与原 ClickHouse 集群相当，而成本降低了 40%，符合我们的预期。未来几个月，我们将继续推动更多集群的迁移，并探索更多的应用场景。我们的下一步目标是利用物化视图进行 ETL 处理和湖上外表的联动，预期这将进一步降低成本，实现更统一的元数据管理和更精简的数据架构。未来我们也将持续提高湖仓融合的程度，最终达成全面的湖仓一体化。

关于 StarRocks

Linux 基金会项目 StarRocks 是新一代极速全场景 MPP 数据库，遵循 Apache 2.0 开源协议。

面世三年来，StarRocks 致力于帮助企业构建极速统一的湖仓分析新范式，是实现数字化转型和降本增效的关键基础设施。目前，全球 400 家以上市值超过 70 亿元人民币的顶尖企业选择用 StarRocks 来构建新一代数据分析能力，这些企业包括腾讯、携程、平安银行、中原银行、中信建投、招商证券、大润发、百草味、顺丰、京东物流、TCL、OPPO 等。StarRocks 也已经和全球云计算领导者亚马逊云、阿里云、腾讯云等达成战略合作关系。

StarRocks 全球开源社区也正飞速成长。目前，StarRocks 的 GitHub star 数已达 8300，吸引了超过 350 位贡献者和数十家国内外行业头部企业参与共建，用户社区也有过万人的规模。凭借其卓越的表现，StarRocks 荣获了全球著名科技媒体 InfoWorld 颁发的 2023 BOSSIE Award 最佳开源软件奖项。