电商网站开发的目的和意义,网站建设方案的摘要怎么写,广东推广网络,北京建设工程交易网作者#xff1a;林豪#xff0c;爱奇艺大数据 OLAP 服务负责人 小编导读#xff1a; 本文整理自爱奇艺工程师在 StarRocks 年度峰会的分享#xff0c;介绍了爱奇艺 OLAP 引擎演化及引入 StarRocks 后的效果。 在广告业务中#xff0c;StarRocks 替换 ImpalaKudu 后#x…作者林豪爱奇艺大数据 OLAP 服务负责人 小编导读 本文整理自爱奇艺工程师在 StarRocks 年度峰会的分享介绍了爱奇艺 OLAP 引擎演化及引入 StarRocks 后的效果。 在广告业务中StarRocks 替换 ImpalaKudu 后接口性能提升 400%P90 查询延迟缩短 4.6 倍。 在“魔镜”数据分析平台中StarRocks 替代 Spark 达 67%P50 查询提升 33 倍P90 提升 15 倍节省 4.6 个人天。 爱奇艺 OLAP 体系简介
爱奇艺数据分析场景 在爱奇艺的大数据分析场景中通常需要实现两个核心目标一是看过去包括生成报表、分析剧集热度以及会员运营等二是知未来即预测用户增长和预估收入。虽然我们的最终目标是精准预测未来但由于这一任务难度较大我们更多地是通过精准的报表和历史数据分析挖掘数据中的潜在价值从而为未来决策提供支持。
爱奇艺 OLAP 架构 上图是爱奇艺 OLAP 架构的总体设计。底层存储层包括传统的 Hive用于离线存储和 Kafka用于实时数据仓库近年来还引入了 Iceberg 作为近实时的存储解决方案。在存储层之上是多种查询引擎随着 OLAP 引擎的快速发展我们引入了多种引擎以满足不同需求。再往上是我们自研的智能 SQL 网关它可以屏蔽底层众多引擎的接入细节最上层则是各种应用场景。
如此多样的引擎带来了巨大的运维负担。因此我们需要对引擎进行整合以降低运维复杂性。
爱奇艺 OLAP 引擎演化 接下来我将从两个角度介绍我们引擎的发展历程传统数仓存算一体场景 和 数据湖存算分离场景。这种划分并非绝对而是基于实际需求和客观约束形成的两种技术形态。
在数仓场景中我们通常需要满足高并发、低延迟的在线查询需求因此需要独立的存储。早期我们使用 MySQL 或 ElasticsearchES但 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 查询都通过网关处理为未来的性能优化和物化视图分析提供数据基础。
广告业务上线效果
在广告业务场景中我们将原有的 ImpalaKudu 替换为 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 为例如果尝试将一个带有小数点的值转换为 BIGINTSpark 能够正确处理但 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
