共计 3280 个字符，预计需要花费 9 分钟才能阅读完成。
逾越速运团体有限公司创立于 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 这么好的产品，满足了咱们对性能强、性能全的查问引擎产品的要求；感激鼎石始终以来提供的技术支持，解决了咱们在应用中遇到的各类问题。
