1.1.3 Doris引擎升级

在完成存储引擎的重构以后，Doris的I/O瓶颈得到突破。随着Doris性能的提升，Doris的查询和应用场景也变得越来越复杂，原本采用的MySQL查询引擎逐渐出现瓶颈。

幸运的是，2013年各种SQL on Hadoop项目正蓬勃发展。经过对比，百度研发团队选取Impala作为后续系统的分布式查询引擎。当时选择Impala的主要原因是C++性能较高，并且跟Doris后端开发语言一致，可以省去一部分数据序列化开销。

基于Impala改进的新产品被命名为Palo。Palo除了增加分布式查询层之外，还将Doris 3的OLAP作为单机存储引擎。由于没有分布式Key-Value系统，最初的Palo版本需要自己完成数据分片管理、副本管理等工作。后来为了增加灵活性，MySQL替换ZooKeeper实现元数据存储，整体架构如图1-2所示。

图1-2 Palo 1.x整体架构

从图1-2可以看出，Palo 1.x的组件非常多，运维难度非常大。于是，在随后的Palo 2版本中，元数据管理、分片管理和元数据副本管理合并到Frontend（Doris前端模块，以下简称为FE）组件，OLAP存储引擎和查询引擎合并到Backend（Doris后端模块，以下简称为BE）组件，减少了Agent组件和uWSGI服务组件。FE负责接收用户的查询请求，对查询进行规划，监督查询执行情况，并将查询结果返给用户。BE负责数据的存储，维护多副本数据，以及具体的查询执行。简化后的Doris架构如图1-3所示。

图1-3 Palo 2系统架构

经过Palo 2版本的改进，Doris的架构变得相当简洁，并且不再需要任何外部依赖。在此之后，虽然Doris经过几次改进，但是整体架构仍然保持Palo 2的架构。Palo 2在2015年左右开始大面积推广使用。