汕头网站建设网站推广,江苏常州建设银行网站,毕业答辩ppt网站开发,阳江网作者#xff1a;小红书 OLAP 研发负责人 王成 近两年 StarRocks 一直是小红书 OLAP 引擎体系里非常重要的部分#xff0c;过去一年#xff0c;小红书的 StarRocks 使用规模呈现出翻倍的增长速度#xff0c;目前整体规模已经达到 30 个集群#xff0c;CPU 规模已经达到了 3… 作者小红书 OLAP 研发负责人 王成 近两年 StarRocks 一直是小红书 OLAP 引擎体系里非常重要的部分过去一年小红书的 StarRocks 使用规模呈现出翻倍的增长速度目前整体规模已经达到 30 个集群CPU 规模已经达到了 3 万。 在 11 月 17 日举行的 StarRocks Summit 2023 上小红书 OLAP 研发负责人王成介绍了最近一年小红书的 StarRocks 的应用新进展并重点分享了 StarRocks 在小红书自助分析场景下的应用与实践经验。据王成介绍StarRocks 3.0 在湖上分析能力的增强促使小红书自助分析场景的主力查询引擎通过灰度迁移机制从 Presto 平滑迁移到 StarRocks已迁移部分的平均查询性能提升了 6~7 倍。 我们将王成的精彩演讲整理出来希望小红书的实践经验对大家能有所启发。 背景 数据平台架构 图中是小红书数据平台的整体架构从下往上分别为存储层、表格式层、数据加工层、查询层、应用层。 存储层小红书的所有的存储都架构在各家云厂商的对象存储之上 表格式层以 Hive 和 Iceberg 为主 数据加工层包括离线跟实时两个链路离线同步链路主要使用 Spark 实时则主要使用 Flink 查询层目前主要有4款查询引擎在这些引擎的基础上我们构建了非常丰富的数据产品以及分析产品 应用层包括各类的实时报表平台、自助分析平台以及一些即席分析平台。 基于 StarRocks 的实时分析场景 近两年StarRocks 的存算一体的模式一直支撑着小红书实时分析场景发展我们已经全面覆盖了广告、社区、电商直播等等各个核心领域的报表以及数据产品。 StarRocks 在实时分析场景的规模 过去一年小红书的 StarRocks 使用规模翻倍增长目前整体规模已经达到 30 个集群总 CPU 核数达到 3 万每天数据写入量达到千亿级别查询达到上亿次单个集群的查询峰值 QPS 能够达到 2000 甚至 3000并且整体的平均查询延迟能够控制在 200 毫秒这些数字都充分说明了 StarRocks 小红书内部起的关键作用。 Adhoc 场景遇到的问题 但是这种存算一体的模式也存在一定缺陷最核心的问题是存在额外的数据同步过程数据必须同步到 StarRocks 内部才能对外提供服务这就引入了数据同步以及数据冗余带来了额外的资源消耗。此外数据同步以及数据校验方面的工作也给我们带来了很大的运维压力。 在自助分析场景下查询的 QPS 以及延迟时间要求会稍微低一些但是数据规模非常大底层数据是整个数仓的基础数据包括上万张表、 EB 级别的数据如果想把这么多数据都同步到 StarRocks 里明显不现实。在这个场景下我们之前选择了采用 Presto 来优化整体的查询性能Presto 因其在交互式分析以及复杂查询上面的优势过去几年帮助我们在很好地提升了查询性能、提高用户体验。但是随着小红书自助分析场景需求的不断增长Presto 已不能满足我们日益增长的降本增效方面的需求。 在 Adhoc 场景下Presto 上遇到了几个问题 技术架构复杂化公司内部同时有 Clickhouse、Presto 及StarRocks 三个核心查询引擎需要维护大大增加了我们开发以及运维上面的难度。 Presto 的性能优化困难。 Presto 的主从模式还存在单点故障的问题有潜在的稳定性的风险。 升级选型与真实场景测试 StarRocks 湖仓新范式 StarRocks 3.0 提出了湖仓分析的新范式在湖上分析能力的增强给我们带来了曙光。根据官方的一个Benchmarks相比于 Trino StarRocks 直接分析湖仓数据的能够有 3~5 倍的性能提升因此我们也是选择从 Presto 迁移到 StarRocks 上。 迁移的理由包括 StarRocks 性能的优化代表它能够提供更高的性价比能够给我们在降本增效上带来收益。 StarRocks 能够简化我们的技术体系降低运维难度。现在 StarRocks 实际上在小红书内部已经是最重要的一款查询引擎我们对 StarRocks 的运维以及技术方面的积累更为深厚的。在这种情况下如果能把 Presto 替换成 StarRocks我们的整体的运维压力以及运维难度会大大降低。 从 Presto 到 StarRocks 的迁移非常方便我们在 StarRocks 里面如果要查询外部数据只需要简单定义一个 catalog 就可以了同时 StarRocks 能够支持一些 Java 的 udf这就方便我们去迁移在 Presto 上开发的一些定制化的功能。更重要的是StarRocks 3.0 支持了 Trino 的方言模式。对我们来说用户是我们的分析师他们的常用习惯是很难改变的在这种情况下兼容 Trino查询语义可以让我们的整个迁移过程变得更平滑用户体验也会更好。 ***基于实际业务验证的四个方向 我们基于实际业务验证的 4 个方向分别是正确性、稳定性、性能以及兼容性。正确性和稳定性是查询引擎的生命基线性能决定着我们在迁移之后能够拿到多大的业务价值兼容性则代表着迁移的步伐以及迁移的难度。 正确性方面我们整体的验证过程起始于 3.0 版本收敛于 3.1 版本。在 3.0 版本上我们在测试过程中其实也是遇到了一些问题但是在跟社区合作过程中社区非常活跃及时地解决了这些问题在 3.1 版本基本上不再存在正确性方面的问题了。 在稳定性方面3.1 版本已经能够达到非常高的稳定性在我们的高压的测试当中可以稳定运行一周以上。我们做了不同并发下的一个压力测试分别是 10 并发、20 并发以及 30 并发使用了 StarRocks 3.1.4 和线上稳定的 Presto 版本进行对比。随着查询并发数的增加StarRocks 在稳定性方面的表现明显优于 Presto。 在性能方面我们从过去的线上的实际查询中抽取了 3000 个查询分别进行了串行 10 并发、20 并发、30 并发的压力测试。对比 Presto 3000 个查询里面有 96% 的查询都有非常明显性能优化效果。同时在所有的并发度下StarRocks 的查询性能相比于 Presto 而言都会有 4 倍以上的提升。 在兼容性上3.1 版本在对很多的语法兼容能力进行补全之后目前对 Presto 相关语法兼容性能够达到 90%还差了少量特殊语法例如 CTAS。目前我们线上的整体覆盖度能够达到60%。 目前我们线上稳定版本已经升级到 3.2 该版本不仅提供了 CTAS 语法的支持并通过jni接口帮助我们去扩展更多的 table format以及还有很多 Iceberg 相关的兼容性优化。基于这些优化我们的整体覆盖度已经提高到 85%左右我们还在持续地扩展部分自定义功能预计整体覆盖度可以提升到 90% 以上达到新的里程碑。 从上述 4 个维度上来说StarRocks 都已经达到了生产准入的标准。 迁移过程 在后续的迁移过程中我们希望整个迁移过程尽可能的平稳以及稳定因此采取了动态灰度策略。 原查询服务整体架构 如图所示是引入 StarRocks 之前小红书自助分析的整体架构在这里面的 Kyuubi 是具有分布式以及多租户特性的网关服务也是我们查询服务 SQL 查询的入口。在 Kyuubi 上我们也做了深度定制化开发在这个场景里面我们用到的核心功能是查询的路由功能和灰度功能。查询路由功能就是 Kyuubi 在接收到用户的查询之后会根据用户查询的语法特性以及负载情况将其动态路由到合适的计算引擎进行查询。 在这个场景下我们是以 Presto 的查询引擎为主当用户的查询涉及到一些比较特殊的语法或者数据的扫描量特别大的时候会将这些查询路由到 Spark 去执行。 灰度迁移机制 在引入 StarRocks 之后我们对原有的 Presto 集群进行了切割搭建了一个 StarRocks 集群同时在路由规则里面增加 StarRocks 目前还不兼容的语法判断条件。当用户的查询过来之后会首先判断用户的查询是否在 StarRocks 上能兼容如果不能兼容就会直接路由到 Presto 去执行。如果能够兼容就会根据我们的灰度规则来动态决定它是发到 StarRocks 还是 Presto。这里的灰度规则主要是指动态的灰度比例可以进行实时调整。 实际业务效果 在整个灰度调整过程中我们会进行持续的正确性验证会利用每天闲时也就是集群使用量较低的低峰期时间段去对 StarRocks 上的查询结果跟 Presto 查询结果进行动态比对。只有当天的查询性能、稳定性以及正确性都满足目标的时候我们才会进一步增加动态灰度比例。这样的灰度调整大概持续了一个月StarRocks 的灰度比例从 0% 提升到了100%在这个过程中我们切实享受到了 StarRocks 带来的性能提升效果。就已经迁移的部分而言整体的平均查询性能提升了 6~7 倍查询的 p90 降低了 90%对于用户来说查询体验得到了非常大的优化。并且我们整个迁移过程非常平稳没有出现任何事故也没有遇到用户吐槽。 弹性伸缩降本增效 集群架构 基于以上已经灰度的 StarRocks 湖上分析集群我们拿到了很多的性能上的收益。同时我们希望能够在保持这部分性能不变的情况下进一步达到降本增效的效果因此我们在弹性伸缩上做了一些尝试。我们的 StarRocks 湖上分析集群整体架构分为 FE、CN 两部分其中 CN 作为计算节点本身就没有状态非常符合弹性伸缩的理念。 基于 AWS Spot 的弹性伸缩方案 通常可以通过 CN 的容器化来进行弹性伸缩我们的场景会更特殊一点因为我们目前的数仓架构体系核心还是构建在 AWS 之上的而 AWS 提供的 Spot 实例的服务可以让我们以竞价的方式来获取空闲的机器这个竞价相比于包年包月的方式能够最高享受到 90% 的折扣并且可以随起随用在低峰期可以直接把机器还给 AWS不收取任何费用。 为了适配弹性伸缩我们主要实现了两块内容一个是 CN 的自动化部署的脚本还有一个是 CN 会自动的向 FE 进行注册跟注销。在扩容的时候我们会自动向 AWS 去申请 Spot 实例机器当这些实体机器就位之后会通过我们的自动化部署脚本进行部署然后注册到我们的 FE上这时候就可以对外提供服务了。缩容的时候会自动的从 FE 进行注销注销完之后再向 AWS 归还我们的 Spot 实例。这两个自动化脚本让我们整体的扩缩容的流程变得更加的丝滑扩缩容操作可以在 2 分钟内完成。 在整体架构上我们所有的 FE 以及少量的 CN 上使用的是包年包月方式少量常驻的机器能保证我们能够提供最基础的服务能力另外有 90% 的 CN 节点是通过 Spot 来申请的可以在低峰期将这部分机器完全还掉。 成本优化效果 目前我们采取的还是一种固定时间进行弹性扩展的方式。比如现在定义的低峰期就是 00:00~8:00高峰期是9:00~23:00。高峰期机器比较抢手竞价价格会比较高我们也不希望我们的机器经常被其他用户所抢占因此高峰期的成本基本持平。在低峰期我们可以将 90% 的 CN 机器全部还掉这能够节约大量的成本。总体而言在目前查询性能不变的前提下总体的成本能够降低 35%。 未来规划 短期目标进一步拓展 StarRocks 的湖上分析能力 未来我们的短期目标还是继续在 StarRocks 的湖上分析上进行更多拓展。StarRocks 湖上分析是我们走向湖仓一体的第一步这一块目前还有一些欠缺。 我们目前最关注的指标就是整体查询的覆盖度3.2 的版本的发布给我们带来很大的覆盖度提升。剩下一部分主要是 udf 功能持续的丰富StarRocks 目前的 udf 相比于 Hive 而言灵活性稍差比如支持的类型有限不能支持动态返回类型等我们未来会和社区一起在这方面进行持续的功能拓展。 数据湖 Iceberg 的集成优化这一块目前也有很多亟需优化的点我们会持续的跟社区一起去合作打磨。 我们目前完全没有开启缓存上述的那些测试数据都是不包括缓存的我们未来也希望能够去对本地缓存以及分布式缓存进行持续的探索看看能不能基于缓存去进一步优化我们整体的查询性能。 长期目标实践存算分离与湖仓一体 长期来看我们的两个方向一个是存算分离模式的实践另外一个还是湖仓一体的建设。 存算分离模式的引入能够帮助我们去替换掉更多的 OLAP 分析场景帮助我们进一步降低整体技术栈的复杂度。 在湖仓一体方面我们希望能将存算分离模式和湖上分析场景融合到一起通过湖仓一体架构带来更强的数据开发和数据分析能力包括但不止于以下两个关键特性 1 打破湖和仓之间的隔阂降低架构复杂度 存算分离模式StarRocks 私有的数据格式也会放到云上实际上成为了整个湖仓体系中一个普通的数据 format。用户在基于湖数据进行自助分析时如果对查询性能有了更高的要求可以通过物化视图的方式将数据聚合成更高维度的 StarRocks 私有格式数据提供查询加速。物化视图的构建也可以根据查询历史自动化构建更为智能和高效。 2 数据的流转更加方便高效 社区目前也在尝试通过 Spark 直接生成 StarRocks 自由格式数据这项功能可以进一步实现读写分离优化湖仓一体场景下数据同步的性能和便利性。 本文由 mdnice 多平台发布
