性能全面飙升!StarRocks 在贝壳找房的极速统一实践
本文发表于: &{ new Date(1690905600000).toLocaleDateString() }
小编导读:
贝壳找房是国内最大的在线房产交易平台之一,利用大数据技术进行房源的挖掘和匹配,通过数据分析和挖掘,更准确地了解用户需求,并为用户提供个性化的房源推荐和交易服务。
随着数据和业务规模的增长,传统数仓的分析能力面临很大的挑战,贝壳需要引入新兴的数据湖技术来支撑业务的发展。作为 StarRocks 最早一批用户之一,StarRocks 于 2021 年落地贝壳,并经过两年的发展,在大数据查询场景下已经能够满足 90% 以上的需求场景。
贝壳在指标分析场景、实时业务场景采用 StarRocks 替换原有的 Kylin、Clickhouse 等组件,业务性能上有 5-6 倍性能提升;同时,贝壳也开始推动 StarRocks 替换 Presto 的场景,进一步简化架构,实现分析层的统一,与 StarRocks 社区共建极速统一的湖仓新范式。
StarRocks 在贝壳的应用现状
01 历史的数据分析架构
早期为了支持多样化的分析能力,引入了多种 OLAP 引擎以支持不同的场景,其中包括:
Kylin、Druid:用于高 QPS 的指标查询、报表系统等
Presto、Impala:基于 Hive 数据分析
- ClickHouse :用于支撑用户分析、风控等实时业务
随着使用规模的扩大,维护成本越来越高,在扩展引擎数量的同时,必须考虑上下游配套产品的兼容性改造,由于每个引擎的特殊性,适配的开发成本也很高,随着引擎数量增加和特性迭代,这方面的工作量越来越大。尽管数据开发平台已经在很大程度上屏蔽了引擎的使用细节,但随着业务的深入使用,某些场景可能需要使用引擎的高级特性支持。一些业务逻辑需要沉淀到引擎底层,增加了业务模型的开发维护成本。
02 OLAP选型
离线场景:最初使用 Kylin 进行指标分析,Kylin 是一种空间换时间的方案,并且依赖于 HDFS 和 HBase。此外,Kylin 在维度计算方面需要较长的构建时间,查询性能受到 HBase 的限制,调优成本较高。Druid 的引入虽然解决了以上问题,但 Druid 本身也存在一些局限性,比如 SQL 能力较弱,不支持 JOIN 操作。对于数据分析产品来说,如果只能使用宽表模型,那产品的灵活性就会受到一定的限制。
实时场景:ClickHouse 主要是支撑实时分析场景,但在更新操作、高并发和 Join 等场景有诸多限制。
从总体来看面临以下比较严重问题:
- 复杂、灵活的业务模型要求
- 高性能的查询和高稳定性
- 多引擎的高运维成本
03 StarRocks 的引入
带着这些问题开始调研市场上新兴的 OLAP 技术,发现 StarRocks 能够完全解决以上痛点。2021 年 StarRocks 在贝壳落地,截止 2022 年底,StarRocks 在占据了近 70% 的流量份额。生产环境共有 10 集群在使用,大规模集群 BE 节点 40 个,小规模集群 BE 节点数 5~10 个。
规模:
- 存储总量 80TB
- 日均写入的数据量 12TB,离线 7TB,实时 5TB
日均的查询量 1400 万次
StarRocks 在贝壳的分析实践
引入 StarRocks 最主要的目标是解决多引擎的问题,接下来通过 3 个场景来介绍各引擎如何统一到 StarRocks 上:
01指标分析(Druid To StarRocks)
指标开发为 3 个阶段:
- 数据准备:数据开发人员准备 Hive 表和 StarRocks 表
- 指标开发:基于元数据进行模型和指标开发
模型构建:将模型转化到具体引擎的实现
在构建阶段,使用 Spark 任务将 Hive 数据同步到 StarRocks 中,使用 Flink 同步 Kafka 中的数据。
在指标分析场景中引入 StarRocks ,需要关注的主要问题有两个:
建表:
- 离线场景:数据来源于 Hive,可以进行数据内容探测,根据数据量自动计算分桶数。根据实践经验,慢查询 SQL 中有很大一部分是模型问题导致,智能化建表模式能更好的适配业务。
实时场景:虽然可以预估数据规模来生成表模型,但是业务的增长和发展是难以预估的。因此,对实时表通过添加定期巡检任务进行周期性的检测,根据历史数据规模评估表的分区和分桶是否合理,定时向用户反馈,协助用户进行模型优化。
数据导入:
- 临时分区:采用临时分区来解决导入期间无法查询的问题
- 预聚合:在 Spark 阶段对数据进行部分计算,以降低导入过程中 BE 节点的资源消耗。由于大量的导入通常发生在晚上 0 点至凌晨 6 点之间,并伴随着离线导入的高峰期,提前进行聚合可以减轻 compaction 的压力
高基数字符列精确去重:需要兼容之前的字符精确去重场景( Kylin、 Druid)使用 Hive 的全局字典来实现去重列编码。去重计数列使用 bitmap 类型,查询性能提高约 3~4 倍,在高 QPS 场景下,集群吞吐能力提升更加明显。
02 实时业务(ClickHouse To StarRocks)
ClickHouse 不支持直接的 update 操作,因此需要通过使用视图和 argMax() 函数计算最新数据以达到实时更新的目的。对一个复杂的模型而言,需要为每一张表都创建对应的视图,最终要多张表和视图才能实现,如图 7 所示:
ClickHouse 涉及到本地表、分布式表和视图等不同层级的结构,最顶层的 view 相当于用户指标建模时所用的表,从开发角度来看相当复杂:
- 开发门槛较高:数据开发人员需要对 ClickHouse 有较高的掌握程度
- 维护迭代成本高:对于频繁迭代的业务来说,模型的修改和数据验证过程会变得比较复杂
- 底表数据量大:底层表存储了所有变更记录,在频繁变更的场景下,底表的数据量会变得很大
- 并发场景下 Scan 高:底层每次执行都需要扫描大量数据,导致集群的 I/O 压力较高,读写互相影响
Join 性能有限:在复杂场景下,多张表的关联查询性能不及预期
StarRocks 原生支持 update、高性能的 Join,高 QPS 这些特性可以解决以上所有痛点;针对目前 ClickHouse 中存量的模型,通过以下方式平滑迁移到 StarRocks:
- 模型:使用 Duplicate 模型对应 ClickHouse 中的 MergeTree 模型,StarRocks 中与 argMax() 函数对应的有 row_number()
查询:查询层通过查询服务直接转换到 StarRocks 语法结构
下图是迁移后查询性能对比结果,平均响应时间大幅下降。通过相同集群规模的并发压测,QPS 提升了 5 倍以上。
03 可视化分析(Presto To StarRocks)
贝壳内部的 BI 产品 ODIN 分析平台中提供基于 Hive 的分析能力,底层通过 Presto 引擎查询,用户通过 PrestoSql 进行建模分析,模型和引擎耦合非常紧密,无法轻易的转换成到其他引擎的查询。
StarRocks 支持了 Hive 外表的功能,同时相比 Presto 有 3 倍以上的性能提升,使得 StarRocks 在贝壳有能力统一 OLAP 场景。目前已开始将分流到 StarRocks 做测试验证,后续随着 StarRocks Trino/Presto 兼容能力的进一步提升,会继续提升 StarRocks 的流量占比,实现 StarRocks 在分析层的完全统一。
未来规划
贝壳找房引入 StarRocks 已经有两年的时间了,从实践结果来看,StarRocks 能满足 90% 以上的需求场景。引入 StarRocks 对贝壳整个分析链路的建设起到了关键性作用,达到了极速统一的目标,并且带来了显著的性能收益,极大提升了 OLAP 分析场景的能力和效率。以下是未来的发展规划:
稳定性:对大规模集群的运维,需要从以下方面加强稳定性建设
细化监控维度,增加重要指标的监控告警。
集群上下游链路的阻断控制能力:阻断能力在稳定性保障中非常重要,监控的目的是更好地发现问题,一旦发现问题,就需要有效的手段来控制降级,比如查询降级,危险 SQL 拦截、写入限制等。
多集群数据源的故障恢复自动化:对于一些核心业务,已经建立了双链路保障策略,出现问题时能够自动切换不需要人工干预。
StarRocks 新特性采用:我们比较关注 StarRocks 新特性主要是物化视图、Trino 语法兼容和 LakeHouse 架构
- 物化视图在 OLAP 场景下对查询的性能提升非常大,目前社区在物化视图的多表、异步、自动更新等方面已经有了很丰富的功能支持。如何将这些功能结合业务场景,自动探测查询模式生成对应的物化视图将是未来的重点工作。
- 从 StarRocks 3.0 版本开始,StarRocks 支持 Trino 方言,这一点对存量的 Presto 模型迁移来说,降低了迁移和使用成本,同时有不错的查询性能提升。
- LakeHouse 架构是 StarRocks3.0 的新架构模式,相比 2.0 版本的资源隔离能力,全新的存算分离架构支持硬资源隔离,这个特性使得现在的多个小规模集群模式可以统一成大规模集群,进一步降低资源和维护成本;弹性计算能力可以满足不同业务的使用场景。此外,StarRocks 也支持了 Apache Hudi、Apache Iceberg 和 Delta Lake 主流数据湖,统一湖仓查询场景不再是问题。