跨越速运集团有限公司创建于年，目前服务网点超过家，覆盖城市余个，是中国物流服务行业独角兽企业。跨越集团大数据中心负责全集团所有数据平台组件的建设和维护，支撑20余条核心业务线，面向集团5万多员工的使用。目前，大数据中心已建设数据查询接口1W+，每天调用次数超过1千万，TP99在1秒以下。我们利用DorisDB作为通用查询引擎，有效解决了原架构大量查询返回时间过长，性能达不到预期的问题。
“作者：张杰
跨越集团大数据运维架构师，负责集团公司大数据平台的维护和建设”
业务背景
总体架构
我们原始离线数仓的总体架构如下图所示，数据从各个业务线的数据库，比如MySQL等，通过数据集成工具汇聚到ETL集群（即Hadoop集群），再使用Hive、Spark、Presto等批量处理引擎进行数据仓库的分层处理，然后将DW层和ADS层的数据推送到各种不同的查询引擎。
在这些查询引擎之上，有个统一的查询API网关，应用层的自助分析工具或ERP系统前端通过调用这个API网关，将数据内容呈现给用户。
业务痛点
该系统最大的痛点是查询性能问题。公司对大数据查询接口的响应延迟是有考核的，期望99%的查询请求都能在1秒内返回，比如页面ERP系统、手机端各类报表APP，用户会随时查看数据并进行生产环节调整，过慢的查询响应会影响用户体验，甚至影响业务生产。针对复杂的SQL查询场景，之前采用的Presto、Impala+Kudu、ClickHouse等系统，是远远达不到预期的。另外，针对各种复杂的数据分析业务场景，引入很多不同组件，导致了维护和使用成本非常高。
因此，我们急需一个新的查询引擎，能统一查询引擎，解决性能查询问题，降低使用和维护成本。
OLAP引擎选型
第一阶段，在年，跨越集团大数据中心使用Presto作为通用的查询引擎。此阶段集团大数据中心数仓层基本用的是Hive，Presto可以直连Hive的特性让我们无需做过多的改造，就可以直接生成查询的API。从性能角度考虑，我们也会将数仓中的部分数据拷贝至独立的Presto集群，和数仓ETL集群进行资源隔离。这套架构运行一年多之后，随着业务需求越来越复杂，数据量越来越大，该基于Presto构建的集群性能急剧下降。
第二阶段，为解决Presto集群性能不足的缺陷，我们基于ClickHouse开始构建新的通用查询引擎。年我们使用ClickHouse构建了大量大宽表，将此前需要多层关联的查询逐步迁移到ClickHouse集群。通过这种方式，我们确实解决了此前面临的性能问题。但与此同时，我们需要建设越来越多的大宽表，操作繁琐运维困难。并且这种数据模型无法随业务需求变化而快速改变，灵活性差。
第三阶段，我们在年开始寻找其他能满足我们需求的OLAP引擎，此时我们发现了DorisDB这个产品。首先