当前位置：首页 > article >正文

StarRocks 在爱奇艺大数据场景的实践

article 2026/3/31 23:46:52

作者：林豪，爱奇艺大数据 OLAP 服务负责人

小编导读：

本文整理自爱奇艺工程师在 StarRocks 年度峰会的分享，介绍了爱奇艺 OLAP 引擎演化及引入 StarRocks 后的效果。

在广告业务中，StarRocks 替换 Impala+Kudu 后，接口性能提升 400%，P90 查询延迟缩短 4.6 倍。

在“魔镜”数据分析平台中，StarRocks 替代 Spark 达 67%，P50 查询提升 33 倍，P90 提升 15 倍，节省 4.6 个人天。

爱奇艺 OLAP 体系简介

爱奇艺数据分析场景

在爱奇艺的大数据分析场景中，通常需要实现两个核心目标：一是看过去，包括生成报表、分析剧集热度以及会员运营等；二是知未来，即预测用户增长和预估收入。虽然我们的最终目标是精准预测未来，但由于这一任务难度较大，我们更多地是通过精准的报表和历史数据分析，挖掘数据中的潜在价值，从而为未来决策提供支持。

爱奇艺 OLAP 架构

上图是爱奇艺 OLAP 架构的总体设计。底层存储层包括传统的 Hive（用于离线存储）和 Kafka（用于实时数据仓库），近年来还引入了 Iceberg 作为近实时的存储解决方案。在存储层之上是多种查询引擎，随着 OLAP 引擎的快速发展，我们引入了多种引擎以满足不同需求。再往上是我们自研的智能 SQL 网关，它可以屏蔽底层众多引擎的接入细节，最上层则是各种应用场景。

如此多样的引擎带来了巨大的运维负担。因此，我们需要对引擎进行整合，以降低运维复杂性。

爱奇艺 OLAP 引擎演化

接下来，我将从两个角度介绍我们引擎的发展历程：传统数仓（存算一体）场景 和 数据湖（存算分离）场景。这种划分并非绝对，而是基于实际需求和客观约束形成的两种技术形态。

在数仓场景中，我们通常需要满足高并发、低延迟的在线查询需求，因此需要独立的存储。早期，我们使用 MySQL 或 Elasticsearch（ES），但 MySQL 的规模较小，而 ES 则是性能较差。随后，我们引入了 Impala 结合 Kudu，虽然性能有所提升，但规模仍受限。对于大规模时序数据，我们引入了 Druid，但它不支持明细查询和 Join 操作。为了追求极致性能，我们又引入了 ClickHouse。

在数据湖场景中，我们更多地用于即席分析和故障排查等场景，这些场景对性能要求不高，但对数据规模和成本控制要求较高。最初，我们使用 Hive，随着需求增长，我们引入了 Spark 和 Trino。然而，近期我们发现 StarRocks 能够实现数仓和数据湖计算引擎的统一。在数仓场景中，StarRocks 能够达到与 ClickHouse 相当的查询性能，同时替代 Druid，支持大规模数据下的明细分析。在数据湖场景中，StarRocks 的性能也优于 Spark 和 Trino。

高性能实时数仓：StarRocks vs. ClickHouse

接下来，我将介绍在数仓场景中实时数据处理的典型应用。以我们内部的广告场景为例，其核心需求是高并发、低延迟和数据一致性。在传统的 Lambda 架构中，我们同时进行实时数据写入和离线数据覆盖，以处理反作弊等行为。早期，我们使用 Kudu 和 HDFS 分别保存实时和离线数据，并通过 Impala 提供统一查询接口。这一方案在很长一段时间内能够满足业务需求。

然而，随着数据量的持续增长和查询频率的提升，现有方案的性能瓶颈愈发明显。为了追求更高性能，我们考虑了 ClickHouse，但其在数据一致性方面存在不足，最终选择了 StarRocks。接下来，我将详细阐述为何放弃 ClickHouse，转而选择 StarRocks 来满足这一场景需求。

ClickHouse 和 StarRocks 在很多方面有相似之处，例如它们都追求极致性能，采用 MPP 架构，支持向量化执行和物化视图。但今天我更想强调它们的不同点，尤其是 ClickHouse 的局限性。主要问题可以归纳为三个方面：数据一致性问题、存算分离的支持程度以及运维复杂度。以下我将分别展开讨论这三个方面：

数据一致性

第一个问题是数据一致性。假设我们使用 Flink 从 Kafka 消费数据并写入 ClickHouse，其官方的连接器通常只能保证“至少一次（at least once）”的语义。这意味着当 Flink 任务因集群或节点问题重启时，可能会导致 ClickHouse 中的数据重复。相比之下，StarRocks的 Flink 连接器支持“精确一次（exactly once）”语义，这是一个非常重要的特性，能够有效避免数据重复问题。

此外，我们需要通过离线数据覆盖实时数据，例如在反作弊处理后校准实时数据。然而，ClickHouse 的分布式表不支持原子替换操作，替换时需逐个节点操作，增加了复杂性。如果临时表数据为空，可能导致空数据覆盖目标表。虽然可以通过技术手段解决，但无疑增加了数据流程的复杂性。StarRocks 在这方面表现更为出色，支持分区级别的原子替换操作，确保离线覆盖时的安全和高效。

湖仓融合特性

接下来讨论第二个特点：湖仓融合能力。湖仓融合是当前数据处理领域的一个重要趋势，许多企业都在探索如何更好地整合数据湖和数据仓库。

虽然 ClickHouse 支持湖仓查询，但其能力相对有限，主要通过外部表访问数据湖，而非通过统一的 Catalog 管理。此外，在与 Iceberg 等数据湖技术的集成上，ClickHouse 的支持并不友好。下面我使用一个场景来做对比：

上图展示的是一个故障级降级场景：业务通过 Hive 离线同步到 ClickHouse 提供日常服务。如果要为此业务提供高可用方案，ClickHouse 通常需要搭建灾备集群并进行数据同步，主集群故障时切换到灾备集群。这种方案成本高且需额外管理同步链路。

相比之下，StarRocks 的方案更简单。当主集群故障时，只需启动一个 StarRocks 弹性计算集群，并通过外表模式直接访问 Hive 表。关键在于访问 Hive 外表的性能能否接近 StarRocks 内表的性能。我们的测试表明，在大多数查询场景中，StarRocks 访问 Hive 外表的性能能够与内表相近，甚至在某些大数据规模场景下（如 Q2），直接查询 Hive 外表的性能更快。

运维复杂度--扩缩容

最后讨论运维复杂性，尤其是集群的扩缩容问题。ClickHouse 在这方面更像“手动挡”汽车，需要大量手动调优。扩容时，ClickHouse 的历史数据无法自动重新分布，只有新数据会自动分配到新节点。若某节点宕机，需手动处理，否则可能导致副本数量不足，甚至数据丢失。此外，ClickHouse 的缩容操作几乎无法实现。

相比之下，StarRocks 在扩缩容方面更为自动化，类似“自动挡”汽车。StarRocks 支持无缝扩缩容，能够自动进行数据均衡，节点宕机或缩容时，StarRocks 能自动同步副本，无需人工干预。

引入 StarRocks 与上线效果

在引入 StarRocks 后，我们的整体架构如下：

集群部署：同时部署物理机上的存算一体集群和弹性计算集群，满足高性能需求并具备灵活扩展能力。
缓存优化：当前使用基于 Alluxio 的缓存机制，未来可能引入 StarRocks 自带的 DataCache 缓存机制或结合 Alluxio 进行对比测试。
智能 SQL 网关：在架构上层部署自研的智能 SQL 网关，屏蔽底层引擎的复杂性（如用户名和密码等细节），支持高可用性（HA）并基于集群健康度和性能动态调度。查询拦截功能通过网关实现，所有 SQL 查询都通过网关处理，为未来的性能优化和物化视图分析提供数据基础。

广告业务上线效果：

在广告业务场景中，我们将原有的 Impala+Kudu 替换为 StarRocks 后，接口性能显著提升，整体性能提升了 400%，P90 查询延迟加快了 4.6 倍。

湖上即席查询：从 SparkSQL 到 StarRocks

引擎选择

爱奇艺内部有一个名为“魔镜”的一站式数据分析平台，每天支持 500+ 用户和 1400 多个查询。此前，我们使用 Spark 查询引擎进行即席查询，性能较慢，导致分析师在交互过程中需要等待数据返回，严重影响了分析效率。经过评估，我们发现每天因查询延迟浪费的分析师人力相当于 12.5 个人天。

在 SQL 引擎方面，我们原本计划从 Spark 切换到 Trino，但鉴于两者语法差异较大，最终决定直接切换到 StarRocks。经过测试，StarRocks 不仅与 SparkSQL 兼容性良好，性能也比 Trino 快 2 到 3 倍。

Pilot 双跑平台

我们进行切换的核心目标是对业务完全透明，让业务方感知不到底层使用的是 Spark 还是 StarRocks。为此，我们依托内部的 Pilot 双跑平台，该平台支持多种场景需求，如引擎切换、版本升级、参数验证以及机型选择变更等。

整个切换流程大致分为四个阶段：

SQL 集合筛选：从历史 SQL 执行记录中，通过筛选或手动录入的方式，圈定需要双跑的 SQL 集合。
配置实验：定义对照组（Spark）和实验组（StarRocks）。为每个 SQL 分别生成子任务，分别在对照组和实验组中执行。
SQL 改写与执行：对 SQL 进行改写，例如将写入线上表的语句改为写入临时表，避免影响生产环境。所有子任务执行完成后，我们会进行行列级别的数据校验，只有数据完全一致才视为对数通过。
生成实验报告：对于通过验证的 SQL 集合，我们可以进行切换；对于未通过的集合，我们会分析具体问题，并进行参数调优。

上图 Pilot 双跑平台的页面示意图清晰展示了每个子任务的耗时和对数结果。如果发现某个子任务失败或数据不一致，可以通过详情页面查看具体细节。双跑平台极大地简化了我们的数据切换工作。

双跑对数-5 轮结果汇总

我们对历史数据进行了多轮对数验证，并将 Spark 与 StarRocks 的切换情况分为以下三种场景：

切换到 StarRocks 后执行失败：这种情况可以接受，可能由于 UDF 不支持、语法兼容问题或数据规模较大等原因导致。如果 StarRocks 执行失败，平台会自动降级到 Spark 执行，从业务感知上来说，最终 SQL 仍然执行成功。因此，只要将失败比例控制在较低水平即可。
StarRocks 执行成功，但数据存在不一致：这种情况不能接受，因为用户无法判断哪些查询可以切换到 StarRocks。因此，修复数据不一致问题非常重要。我们最终修复了 13 个不一致问题，将不一致的比例从 19% 降低到 0%。
StarRocks 执行成功且数据一致：这是我们追求的理想场景。在双跑验证中，最终能够成功切换的比例约为 78%。

对数不一致常见问题

精度问题：某些字段最初的小数保留位数较少，经过调整后，我们增加了保留位数，从而实现了数据的一致性。我们设定了一个标准：精度误差不超过万分之一，即可视为一致。
函数语义不同：例如，from_unixtime 函数在不同系统中的支持类型有所不同。StarRocks 官方支持的类型有限，而我们在生产环境中遇到了多种类型，因此我们对其进行了扩展支持，以确保兼容性。类似的，日期函数和 split 函数的适配也遵循这一原则，确保能够支持类似正则表达式的识别功能。

其他：例如数组的起始下标或类型转换。以 StarRocks 为例，如果尝试将一个带有小数点的值转换为 BIGINT，Spark 能够正确处理，但 StarRocks 会返回 NULL。

切换效果

针对上述提到的一些问题，我们已经进行了修复，以下是修复后的上线效果：

目前，StarRocks 的切换比例为50%。这一比例尚未达到更高，并非因为存在技术限制，而是许多业务在查询时明确指定了使用 Spark 引擎。现阶段，我们优先尊重业务的指定选择。未来，我们会积极推动业务逐步提高使用 StarRocks 的比例。

在已切换的业务中，StarRocks 成功替换 Spark 的比例约为67%，即三分之二左右。这一比例略低于我们此前双跑测试时的预期，但对于切换成功的部分，效果非常显著：P50 查询速度提升了 33 倍，P90 查询速度提升了 15 倍。

此外，我们通过优化节省了 4.6 个人天。从柱状图中可以看出，前两个柱子代表纯 Spark 的查询，后面的柱子代表部分切换到 StarRocks 后的查询。切换到 StarRocks 后，查询耗时大幅减少，节省了大量时间。

未来展望与规划

存算一体

技术升级：我们将升级至3.3版本，并验证物化视图的加速效果，同时考虑引入分级存储，将历史数据转存到 HDFS。
引擎收敛：未来一年，我们将重点替换 ClickHouse 和 Druid，逐步统一数据处理引擎，降低运维复杂度。

存算分离

扩大规模：目前切换成功比例为三分之二。未来，我们将扩大切换规模，解决 UDF 兼容性不足的问题，进一步提升切换成功率。
性能优化：针对外表查询性能不够理想的情况，我们将通过物化视图实现透明加速，并计划替换 Trino 引擎，提升整体性能。

更多交流，联系我们：StarRocks