Doris架構包含哪些技術？為什么進行技術整合？

Doris主要整合了Google Mesa(數(shù)據(jù)模型)，Apache Impala(MPP Query Engine)和Apache ORCFile (存儲格式，編碼和壓縮)的技術。

為什么要將這三種技術整合?

Mesa可以滿足我們許多存儲需求的需求，但是Mesa本身不提供SQL查詢引擎。

Impala是一個非常好的MPP SQL查詢引擎，但是缺少完美的分布式存儲引擎。

自研列式存儲：存儲層對存儲數(shù)據(jù)的管理通過storage_root_path路徑進行配置，路徑可以是多個。存儲目錄下一層按照分桶進行組織，分桶目錄下存放具體的tablet，按照tablet_id命名子目錄。因此選擇了這三種技術的組合。

Doris的系統(tǒng)架構如下，Doris主要分為FE和BE兩個組件。

整體架構

Doris的架構很簡潔，使用MySQL協(xié)議，用戶可以使用任何MySQL ODBC/JDBC和MySQL客戶端直接訪問Doris，只設FE(Frontend)、BE(Backend)兩種角色、兩個進程，不依賴于外部組件，方便部署和運維。

FE：Frontend，即Doris的前端節(jié)點。主要負責接收和返回客戶端請求、元數(shù)據(jù)以及集群管理、查詢計劃生成等工作。

BE：Backend，即Doris的后端節(jié)點。主要負責數(shù)據(jù)存儲與管理、查詢計劃執(zhí)行等工作。

FE,BE都可線性擴展?FE主要有兩個角色，一個是follower，另一個是observer。多個follower組成選舉組，會選出一個master，master是follower的一個特例，Master跟follower，主要是用來達到元數(shù)據(jù)的高可用，保證單節(jié)點宕機的情況下，元數(shù)據(jù)能夠實時地在線恢復，而不影響整個服務。

Observer節(jié)點僅從leader節(jié)點進行元數(shù)據(jù)同步，不參與選舉?？梢詸M向擴展以提供元數(shù)據(jù)的讀服務的擴展性。

數(shù)據(jù)的可靠性由BE保證，BE會對整個數(shù)據(jù)存儲多副本或者是三副本。副本數(shù)可根據(jù)需求動態(tài)調整。

元數(shù)據(jù)結構

Doris采用==Paxos協(xié)議以及Memory+ Checkpoint + Journal的機制==來確保元數(shù)據(jù)的高性能及高可靠。元數(shù)據(jù)的每次更新，都會遵照以下幾步：

（1）寫入到磁盤的日志文件中

（2）再寫到內存中

（3）定期checkpoint到本地磁盤上

相當于是一個純內存的一個結構，也就是說所有的元數(shù)據(jù)都會緩存在內存之中，從而保證FE在宕機后能夠快速恢復元數(shù)據(jù)，而且不丟失元數(shù)據(jù)。

Leader、follower和observer它們三個構成一個可靠的服務，如果發(fā)生節(jié)點宕機的情況，一般是部署一個leader兩個follower，目前來說基本上也是這么部署的。就是說三個節(jié)點去達到一個高可用服務。單機的節(jié)點故障的時候其實基本上三個就夠了，因為FE節(jié)點畢竟它只存了一份元數(shù)據(jù)，它的壓力不大，所以如果FE太多的時候它會去消耗機器資源，所以多數(shù)情況下三個就足夠了，可以達到一個很高可用的元數(shù)據(jù)服務。