跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)

跨越速运集团有限公司创建于2007年,目前服务网点超过3000家,覆盖城市500余个,是中国物流服务行业独角兽企业。跨越集团大数据中心负责全集团所有数据平台组件的建设和维护,支撑20余条核心业务线,面向集团5万多员工的使用。目前,大数据中心已建设数据查询接口1W+,每天调用次数超过1千万,TP99在1秒以下。我们利用StarRocks作为通用查询引擎,有效解决了原架构大量查询返回时间过长,性能达不到预期的问题。

“ 作者:张杰,
跨越集团大数据运维架构师,负责集团公司大数据平台的维护和建设 ”
业务背景
总体架构 我们原始离线数仓的总体架构如下图所示,数据从各个业务线的数据库,比如MySQL等,通过数据集成工具汇聚到ETL集群(即Hadoop集群),再使用Hive、Spark、Presto等批量处理引擎进行数据仓库的分层处理,然后将DW层和ADS层的数据推送到各种不同的查询引擎。
在这些查询引擎之上,有个统一的查询API网关,应用层的自助分析工具或ERP系统前端通过调用这个API网关,将数据内容呈现给用户。
跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)
文章图片

业务痛点
该系统最大的痛点是查询性能问题。公司对大数据查询接口的响应延迟是有考核的,期望99%的查询请求都能在1秒内返回,比如页面ERP系统、手机端各类报表APP,用户会随时查看数据并进行生产环节调整,过慢的查询响应会影响用户体验,甚至影响业务生产。针对复杂的SQL查询场景,之前采用的Presto、Impala+Kudu、ClickHouse等系统,是远远达不到预期的。另外,针对各种复杂的数据分析业务场景,引入很多不同组件,导致了维护和使用成本非常高。
【跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)】因此,我们急需一个新的查询引擎,能统一查询引擎,解决性能查询问题,降低使用和维护成本。
OLAP引擎选型
跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)
文章图片

第一阶段,在2019年,跨越集团大数据中心使用Presto作为通用的查询引擎。此阶段集团大数据中心数仓层基本用的是Hive,Presto可以直连Hive的特性让我们无需做过多的改造,就可以直接生成查询的API。从性能角度考虑,我们也会将数仓中的部分数据拷贝至独立的Presto集群,和数仓ETL集群进行资源隔离。这套架构运行一年多之后,随着业务需求越来越复杂,数据量越来越大,该基于Presto构建的集群性能急剧下降。
第二阶段,为解决Presto集群性能不足的缺陷,我们基于ClickHouse开始构建新的通用查询引擎。2020年我们使用ClickHouse构建了大量大宽表,将此前需要多层关联的查询逐步迁移到ClickHouse集群。通过这种方式,我们确实解决了此前面临的性能问题。但与此同时,我们需要建设越来越多的大宽表,操作繁琐运维困难。并且这种数据模型无法随业务需求变化而快速改变,灵活性差。
第三阶段,我们在2021年开始寻找其他能满足我们需求的OLAP引擎,此时我们发现了StarRocks这个产品。首先关注到StarRocks的单表、多表关联查询的性能都非常优秀,能够满足我们对查询延时的需求;StarRocks支持MySQL协议,让我们开发同事在开发接口的时候学习和使用门槛非常低。另外,StarRocks还具备支持按主键更新、支持多种类型外表、部署运维简单以及支持丰富的数据导入方式等特性。这些都是我们所需要的。
因此,我们开始逐步将以往的分析业务迁移到StarRocks集群上,将StarRocks作为大数据中心的通用查询引擎。
StarRocks在跨越集团的应用
在线场景应用 当前我们每天在线数据接口的查询请求量已经超过千万。在引入StarRocks前,我们用了8到9种查询引擎来支撑各种在线业务场景。大数据量的明细点查场景使用ElasticSearch作为支撑;对于查询维度固定、可以提前预计算的报表场景,会使用MySQL;对于SQL查询复杂,如果多表Join、子查询嵌套的查询场景,会使用Presto;实时更新的场景,则会使用Impala+Kudu的组合来支撑。
跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)
文章图片

引入StarRocks后,目前已替换掉Presto和Impala+Kudu支撑的场景。ElasticSearch、MySQL以及ClickHouse,后续也可能会根据业务场景实际情况逐步替换为StarRocks。
下面详细介绍一个实际在线场景的典型案例。如上图,我们在原Presto系统上有一个包含200个字段的宽表聚合查询。由于业务需求比较复杂,SQL语句有600多行。我们曾希望从业务逻辑上进行优化,但是并不容易,不能因为系统能力问题就一味要求业务方来迁就。现在我们使用10个节点相同配置的StarRocks替换原15台相同配置服务器的Presto集群后,在没有做什么业务逻辑变化的情况下,使用StarRocks明细模型,凭借StarRocks本身的高性能将查询延时从5.7秒降低为1秒,性能是原Presto集群的近6倍。
OLAP场景应用 跨越集团的OLAP多维分析平台是我们自研的一套BI系统。用户可以根据自己业务场景选择字段以及关联条件等,以拖拉拽的方式生成数据的表格或图表。最早我们支撑OLAP多维分析的后端引擎是Presto,在这类场景下的性能确实不尽如人意。因为性能问题,我们也没办法将这个工具推广给更多的用户使用。我们将后端查询引擎替换为StarRocks后,性能提升非常明显。我们将OLAP多维分析平台向整个集团推广,受到了越来越多的用户好评。
OLAP多维分析主要是离线分析为主,以客户离线分析场景为例,数据经过ETL处理后,生成对应的DW层或ADS层数据,再通过Broker Load将数据按天导入StarRocks中。我们使用星型模型构建客户主题域,客户主表以明细模型在StarRocks中建表,同样以明细模型创建维表。这样用户就可以在前端对客户主题域的各种指标、各种维度进行拖拉拽,生成对应的表格和图表。
跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)
文章图片

在客户离线分析场景下,我们StarRocks上线前后业务逻辑没有进行太多调整前提下,TP99从4.5秒下降到1.7秒,性能是原来的三倍(后续我们将尝试开启CBO优化器,预计会有更大性能提升)。绝大多数场景都能实现1s内返回,大大提升了用户的体验。
跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)
文章图片

利用StarRocks的实时分析能力,我们还构建了实时OLAP多维分析。以运单实时分析场景为例,原本我们是用Hive每两小时跑批的方式来实现的,将固定维度数据算好,结果写入Presto上提供查询,逻辑类似于离线数仓,并不能称为真正的实时。引入StarRocks后,我们调整数据流转逻辑,通过监听Binlog将数据写入Kafka,再通过Rontine Load的方式消费Kafka,将数据实时写入StarRocks中。我们使用更新模型建立实时运单主表,将运单ID设置成主键,这样每一笔运单更新后,都能实时更新到运单主表中。和离线分析场景一样,使用星型模型构建运单主题域。
跨越速运 x StarRocks(统一查询引擎,强悍性能带来极速体验)
文章图片

通过这样的调整,以往每两小时更新数据的运单主题域,现在可以实现秒级更新,成为名副其实的实时分析。另外此前需要依赖预计算,维度都是固定的,很多分析上功能受限。经改造后,除了大幅提升“实时”体验外,在分析灵活性上的提升也非常明显。实时体验和灵活分析也成为OLAP多维分析平台工具在实际服务中最大的亮点。
后续规划
1、 为了避免部分慢查询影响整体的集群性能,后续会搭建多套StarRocks集群,按业务场景进行物理资源隔离。
2、 StarRocks查询Hive外表的功能,经内部测试比Presto查询Hive的性能要好,后续会将原本Presto查询Hive的场景无缝迁移到StarRocks上。
3、 目前我们在StarRocks上写入了很多实时数据,这些数据需要进行聚合等处理,我们正在尝试使用调度工具,在StarRocks上进行5分钟级、10分钟级的轻量ETL处理。
4、 开启StarRocks的CBO优化器,进一步提升查询性能。
最后,感谢鼎石为我们提供StarRocks这么好的产品,满足了我们对性能强、功能全的查询引擎产品的要求;感谢鼎石一直以来提供的技术支持,解决了我们在使用中遇到的各类问题。

    推荐阅读