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

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

作者：张杰

跨越集团大数据运维架构师，负责集团公司大数据平台的维护和建设 

业务背景

总体架构

我们原始离线数仓的总体架构如下图所示，数据从各个业务线的数据库，比如 MySQL 等，通过数据集成工具汇聚到 ETL 集群（即 Hadoop 集群），再使用 Hive、Spark、Presto 等批量处理引擎进行数据仓库的分层处理，然后将 DW 层和 ADS 层的数据推送到各种不同的查询引擎。

在这些查询引擎之上，有个统一的查询 API 网关，应用层的自助分析工具或 ERP 系统前端通过调用这个 API 网关，将数据内容呈现给用户。

业务痛点

该系统最大的痛点是查询性能问题。公司对大数据查询接口的响应延迟是有考核的，期望 99%的查询请求都能在 1 秒内返回，比如页面 ERP 系统、手机端各类报表 APP，用户会随时查看数据并进行生产环节调整，过慢的查询响应会影响用户体验，甚至影响业务生产。针对复杂的 SQL 查询场景，之前采用的 Presto、Impala+Kudu、ClickHouse 等系统，是远远达不到预期的。另外，针对各种复杂的数据分析业务场景，引入很多不同组件，导致了维护和使用成本非常高。

因此，我们急需一个新的查询引擎，能统一查询引擎，解决性能查询问题，降低使用和维护成本。

OLAP 引擎选型

第一阶段，在 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 的组合来支撑。

引入 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 中建表，同样以明细模型创建维表。这样用户就可以在前端对客户主题域的各种指标、各种维度进行拖拉拽，生成对应的表格和图表。

在客户离线分析场景下，我们 StarRocks 上线前后业务逻辑没有进行太多调整前提下，TP99 从 4.5 秒下降到 1.7 秒，性能是原来的三倍（后续我们将尝试开启 CBO 优化器，预计会有更大性能提升）。绝大多数场景都能实现 1s 内返回，大大提升了用户的体验。

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

通过这样的调整，以往每两小时更新数据的运单主题域，现在可以实现秒级更新，成为名副其实的实时分析。另外此前需要依赖预计算，维度都是固定的，很多分析上功能受限。经改造后，除了大幅提升“实时”体验外，在分析灵活性上的提升也非常明显。实时体验和灵活分析也成为 OLAP 多维分析平台工具在实际服务中最大的亮点。

后续规划

1、 为了避免部分慢查询影响整体的集群性能，后续会搭建多套 StarRocks 集群，按业务场景进行物理资源隔离。

2、 StarRocks 查询 Hive 外表的功能，经内部测试比 Presto 查询 Hive 的性能要好，后续会将原本 Presto 查询 Hive 的场景无缝迁移到 StarRocks 上。

3、 目前我们在 StarRocks 上写入了很多实时数据，这些数据需要进行聚合等处理，我们正在尝试使用调度工具，在 StarRocks 上进行 5 分钟级、10 分钟级的轻量 ETL 处理。

4、 开启 StarRocks 的 CBO 优化器，进一步提升查询性能。

最后，感谢鼎石为我们提供 StarRocks 这么好的产品，满足了我们对性能强、功能全的查询引擎产品的要求；感谢鼎石一直以来提供的技术支持，解决了我们在使用中遇到的各类问题。