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