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年左右開始大面積推廣使用。