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

作者：林豪，爱奇艺大数据 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 后，我们的整体架构如下：

1. 集群部署：同时部署物理机上的存算一体集群和弹性计算集群，满足高性能需求并具备灵活扩展能力。
2. 缓存优化：当前使用基于 Alluxio 的缓存机制，未来可能引入 StarRocks 自带的 DataCache 缓存机制或结合 Alluxio 进行对比测试。
3. 智能 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 双跑平台，该平台支持多种场景需求，如引擎切换、版本升级、参数验证以及机型选择变更等。

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

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

图片

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

双跑对数-5 轮结果汇总

图片

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

1. 切换到 StarRocks 后执行失败：这种情况可以接受，可能由于 UDF 不支持、语法兼容问题或数据规模较大等原因导致。如果 StarRocks 执行失败，平台会自动降级到 Spark 执行，从业务感知上来说，最终 SQL 仍然执行成功。因此，只要将失败比例控制在较低水平即可。
2. StarRocks 执行成功，但数据存在不一致：这种情况不能接受，因为用户无法判断哪些查询可以切换到 StarRocks。因此，修复数据不一致问题非常重要。我们最终修复了 13 个不一致问题，将不一致的比例从 19% 降低到 0%。
3. 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 引擎，提升整体性能。