Apache Doris（incubating）從2008年第一個(gè)版本開(kāi)始到今天已經(jīng)走過(guò)了11個(gè)年頭。期間，Doris 從最初的只為解決百度鳳巢報(bào)表的專用系統(tǒng)，已經(jīng)成長(zhǎng)為目前國(guó)內(nèi)唯一的分析型數(shù)據(jù)庫(kù)孵化項(xiàng)目。一路走來(lái)， Doris 的初心從未改變。

Apache Doris —— 為分析而生

從誕生之日起，Doris 的每一步都是為了解決切實(shí)的業(yè)務(wù)痛點(diǎn)，每一次轉(zhuǎn)變都是在面對(duì)不同的業(yè)務(wù)挑戰(zhàn)。一路上，Doris 砥礪前行，凝結(jié)了眾多前輩的心血。相信未來(lái)，Doris 還會(huì)有更多的新鮮血液加入，我們一起走的更快、更遠(yuǎn)。

Doris 發(fā)展歷程

Doris 自第一版誕生以來(lái)，經(jīng)過(guò)了11年的發(fā)展，中間做過(guò)無(wú)數(shù)改進(jìn)。這只羅列對(duì) Doris 發(fā)展來(lái)說(shuō)比較重要的關(guān)鍵節(jié)點(diǎn)與事件。

#2008 Doris1，“筑巢引鳳”的重要基石

早年，百度最主要的收入來(lái)源是廣告。廣告主需要通過(guò)報(bào)表服務(wù)來(lái)查看廣告的展現(xiàn)、點(diǎn)擊、消費(fèi)等信息，并且能夠需要通過(guò)不同維度來(lái)獲得廣告的消費(fèi)情況，用以指導(dǎo)后續(xù)的廣告的投放策略。

在 Doris1 誕生之前，百度使用 MySQL Sharding 方式來(lái)為廣告主提供廣告報(bào)表支持。隨著百度本身流量的增加，廣告流量也隨之增加，已有的 MySQL Sharding 方案變得不再能夠滿足業(yè)務(wù)的需求。主要體現(xiàn)在以下幾個(gè)方面：

第一，大規(guī)模數(shù)據(jù)導(dǎo)入會(huì)導(dǎo)致 MySQL 的讀性能大幅降低，甚至還有鎖表情況，在密集導(dǎo)入數(shù)據(jù)的情況下尤為明顯。同時(shí)在數(shù)據(jù)導(dǎo)入時(shí)，MySQL 的查詢性能大幅下降，導(dǎo)致頁(yè)面打開(kāi)很緩慢或者超時(shí)，用戶體驗(yàn)很差；第二，MySQL 在大查詢方面性能很差，因此只能從產(chǎn)品層面來(lái)限制用戶的查詢時(shí)間范圍，用戶體驗(yàn)很差；第三，MySQL 對(duì)數(shù)據(jù)量的支持是有限的。單表存儲(chǔ)的數(shù)據(jù)有限，如果過(guò)大，查詢就會(huì)變慢。對(duì)此的解決方案只有拆表、拆庫(kù)、遷移數(shù)據(jù)。隨著數(shù)據(jù)量的快速增長(zhǎng)，已經(jīng)無(wú)法維護(hù)。

當(dāng)時(shí)數(shù)據(jù)存儲(chǔ)和計(jì)算成熟的開(kāi)源產(chǎn)品很少，Hbase 的導(dǎo)入性能只有大約2000條/秒，不能滿足業(yè)務(wù)每小時(shí)新增的要求。而業(yè)務(wù)還在不斷增長(zhǎng)，來(lái)自業(yè)務(wù)的壓力越來(lái)越大。在這種情況下，Doris1 誕生了，并且在2008年10月份跟隨百度鳳巢系統(tǒng)一起正式上線。

Doris1 的主要架構(gòu)如上圖所示。數(shù)據(jù)仍然通過(guò)用戶 ID 進(jìn)行 Hash，將同一個(gè)用戶 ID 的數(shù)據(jù)交由一臺(tái)機(jī)器處理。其中 Hm-Storage 負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)。ODP、OMG 負(fù)責(zé)將業(yè)務(wù)數(shù)據(jù)導(dǎo)入到 Hm-Storage 中。AS 負(fù)責(zé)解析、規(guī)劃查詢請(qǐng)求，并將查詢請(qǐng)求發(fā)給 Hm-Storage 處理，并對(duì) Hm-Storage 返回的數(shù)據(jù)進(jìn)行一些業(yè)務(wù)相關(guān)的計(jì)算后將查詢結(jié)果返回給用戶。

相比于 MySQL 的方案，Doris1 主要在如下幾個(gè)方面進(jìn)行了改進(jìn)。

首先，Doris1 的數(shù)據(jù)模型將數(shù)據(jù)分為 Key 列、Value 列。比如一條數(shù)據(jù)的 Key 列包括：用戶 ID、時(shí)間、地域、來(lái)源等等，Value 列包括：展現(xiàn)次數(shù)、點(diǎn)擊次數(shù)、消費(fèi)額等。這樣的數(shù)據(jù)模型下，所有 Key 列相同的數(shù)據(jù) Value 列能夠進(jìn)行聚合，比如數(shù)據(jù)的時(shí)間維度最細(xì)粒度為小時(shí)，那同一小時(shí)多次導(dǎo)入的數(shù)據(jù)是能夠被合并成一條的。這樣對(duì)于同樣的查詢來(lái)說(shuō)，Doris1 需要掃描的數(shù)據(jù)條目相比 MySQL 就會(huì)降低很多。

其次，Doris1 將 MySQL 逐條插入改成了批量更新，并且通過(guò)外圍模塊將同一批次數(shù)據(jù)進(jìn)行排序以及預(yù)聚合。這樣一個(gè)批次中相同 Key 的數(shù)據(jù)能夠被預(yù)先聚合，另外排序后的數(shù)據(jù)能夠在查詢的時(shí)候起到聚集索引的作用，提升查詢時(shí)候的性能。

最后，Doris1 提供了天表、月表這種類似物化視圖的功能。比如用戶是想將數(shù)據(jù)按天進(jìn)行匯聚展現(xiàn)，那么對(duì)于這種查詢是可以通過(guò)天表來(lái)滿足的。而天表相對(duì)于小時(shí)表數(shù)據(jù)量會(huì)小幾倍，相應(yīng)的查詢性能也會(huì)提升幾倍。

通過(guò) Doris1 的工作，完全解決了 MySQL Sharding 遇到的問(wèn)題。并于2008年10月在鳳巢系統(tǒng)一起上線，完美地支撐了廣告統(tǒng)計(jì)報(bào)表需求。

#2009 Doris2，解“百度統(tǒng)計(jì)”燃眉之急

2008年的百度統(tǒng)計(jì)服務(wù)大約有50-60臺(tái) MySQL，但是業(yè)務(wù)每天有3000萬(wàn)+條增量數(shù)據(jù)，由于 MySQL 的存儲(chǔ)和查詢性能無(wú)法滿足需求，對(duì)存量數(shù)據(jù)的支撐已經(jīng)到了極限，問(wèn)題頻出，萬(wàn)般無(wú)奈之下百度統(tǒng)計(jì)甚至關(guān)閉了新增用戶的功能，以減少數(shù)據(jù)量的增加。

Doris1 由于當(dāng)時(shí)時(shí)間緊、任務(wù)重，所以設(shè)計(jì)、實(shí)現(xiàn)的時(shí)候只為了能夠滿足鳳巢的業(yè)務(wù)需求，并沒(méi)有兼顧其他的應(yīng)用需求。由于 Doris1 方案對(duì)于鳳巢成功的支持，百度統(tǒng)計(jì)同學(xué)開(kāi)始基于 Doris1 打造 Doris2 系統(tǒng)，主要將 Doris1 進(jìn)行通用化改造，包括支持自定義 schema 等，使 Doris 能夠應(yīng)用于其他產(chǎn)品。此外還進(jìn)行一些優(yōu)化以此來(lái)提升系統(tǒng)的查詢、存儲(chǔ)性能。

2009年 Doris2 研發(fā)完成后上線百度統(tǒng)計(jì)，并且成功支撐百度統(tǒng)計(jì)后續(xù)的快速增長(zhǎng)，成功助力百度統(tǒng)計(jì)成為當(dāng)時(shí)國(guó)內(nèi)規(guī)模最大，性能、功能最強(qiáng)的統(tǒng)計(jì)平臺(tái)。由于在鳳巢、百度統(tǒng)計(jì)上的成功，公司內(nèi)部后續(xù)其他類似統(tǒng)計(jì)報(bào)表類的需求也都由 Doris2 進(jìn)行支持，比如網(wǎng)盟、聯(lián)盟等報(bào)表服務(wù)。

#2010 Doris3 ，讓查詢?cè)倏煲稽c(diǎn)

百度在2009-2011年發(fā)展迅猛，營(yíng)收每年近100%的速度增長(zhǎng)，與之相伴的是廣告數(shù)據(jù)量也隨之大幅增長(zhǎng)。隨著業(yè)務(wù)數(shù)據(jù)量的不斷增長(zhǎng)，Doris2 系統(tǒng)的問(wèn)題也逐漸成為業(yè)務(wù)發(fā)展的瓶頸。

首先體現(xiàn)在 Doris2 無(wú)法滿足業(yè)務(wù)的查詢性能需求，主要是對(duì)于長(zhǎng)時(shí)間跨度的查詢請(qǐng)求、以及大客戶的查詢請(qǐng)求。這是因?yàn)?Doris2 通過(guò)規(guī)則將全部數(shù)據(jù)按照用戶 ID 進(jìn)行 Sharding，這雖然能夠?qū)⑷繑?shù)據(jù)分散到多臺(tái)機(jī)器上，但是對(duì)于單一用戶的數(shù)據(jù)還是全部落在一臺(tái)機(jī)器上。隨著單一用戶數(shù)據(jù)量增多，一些查詢請(qǐng)求無(wú)法快速計(jì)算得到結(jié)果。

其次，Doris2 在日常運(yùn)維方面基本上都需要停服后手動(dòng)操作，比如 Schema Change、集群擴(kuò)縮容等，一方面用戶體驗(yàn)很差，一方面還會(huì)增加集群運(yùn)維的成本。最后，Doris2 本身并不是高可用系統(tǒng)，機(jī)器故障等問(wèn)題還是會(huì)影響服務(wù)的穩(wěn)定性，并且需要人肉進(jìn)行復(fù)雜的操作來(lái)恢復(fù)服務(wù)。

為了解決 Doris2 的問(wèn)題，團(tuán)隊(duì)開(kāi)始了 Doris3 的設(shè)計(jì)、研發(fā)。Doris3 的主要架構(gòu)如下圖所示，其中 DT（Data Transfer）負(fù)責(zé)數(shù)據(jù)導(dǎo)入、DS（Data Seacher）模塊負(fù)責(zé)數(shù)據(jù)查詢、DM（Data Master）模塊負(fù)責(zé)集群元數(shù)據(jù)管理，數(shù)據(jù)則存儲(chǔ)在 Armor 分布式 Key-Value 引擎中。Doris3 依賴 ZooKeeper 存儲(chǔ)元數(shù)據(jù)，從而其他模塊依賴 ZooKeeper 做到了無(wú)狀態(tài)，進(jìn)而整個(gè)系統(tǒng)能夠做到無(wú)故障單點(diǎn)。

在數(shù)據(jù)分布方面 Doris3 引入了分區(qū)的概念。首先數(shù)據(jù)會(huì)按照時(shí)間進(jìn)行分區(qū)（比如天分區(qū)、月分區(qū)）；在同一個(gè)分區(qū)里，數(shù)據(jù)會(huì)根據(jù)用戶 ID 再進(jìn)行 Sharding。這樣同一個(gè)用戶的數(shù)據(jù)會(huì)落在不同的分區(qū)上，而在查詢時(shí)多臺(tái)機(jī)器就能夠同時(shí)處理一個(gè)用戶的數(shù)據(jù)了，實(shí)現(xiàn)了單用戶的分布式計(jì)算能力。但是可能還會(huì)存在一個(gè)分區(qū)內(nèi)部單個(gè)用戶數(shù)據(jù)量過(guò)大的情況。對(duì)于這種情況 Doris3 設(shè)計(jì)了后續(xù)表功能，會(huì)將單個(gè)分區(qū)內(nèi)大用戶的數(shù)據(jù)進(jìn)行拆分，導(dǎo)入到多個(gè)分片中，這樣能夠保證每個(gè)分片內(nèi)單個(gè)用戶的數(shù)據(jù)總量最高是有限度的。

另外 Doris3 在日常運(yùn)維 Schema Change，以及擴(kuò)容、縮容等方面都做了針對(duì)性設(shè)計(jì)，使其能夠自動(dòng)化進(jìn)行，不依賴線上人工操作。

在當(dāng)時(shí)，由于種種原因，Doris3 最終確定使用了 Armor 來(lái)作為底層存儲(chǔ)系統(tǒng)。Armor 是一款分布式 Key-Value 系統(tǒng)，支持多副本強(qiáng)一致，且單表內(nèi)全 Key 有序。選用 Armor 作為底層存儲(chǔ)能夠使 Doris3 只負(fù)責(zé)管理分片，而分片的副本，以及副本的一致性都由 Armor 來(lái)處理。并且，集群的擴(kuò)、縮容等操作也只需要 Armor 感知即可，Doris3 本身并不需要感知。當(dāng)然除了這些好處外，這樣的選型也有一些弊端。

由于 Armor 是一個(gè)通用的 Key-Value 系統(tǒng)，并不感知上層的業(yè)務(wù)數(shù)據(jù)，它并不支持 Doris 這種數(shù)據(jù)模型，相同 Key 的數(shù)據(jù)，Value 字段是可以進(jìn)行聚合的。比如數(shù)據(jù)導(dǎo)入的批次是五分鐘一批，但是數(shù)據(jù)時(shí)間粒度是小時(shí)，那么其實(shí)一個(gè)小時(shí)的數(shù)據(jù)可能是多次導(dǎo)入的，但是邏輯上是可以合并成一條數(shù)據(jù)的。所以為了實(shí)現(xiàn)這個(gè)功能，只能是 Doris3 自身實(shí)現(xiàn)了較為復(fù)雜的數(shù)據(jù)合并策略來(lái)完成相關(guān)數(shù)據(jù)的合并。

Doris3 在2011年完成開(kāi)發(fā)后逐漸替換 Doris2 所制成的業(yè)務(wù)，并且成功解決了大客戶查詢的問(wèn)題。而公司內(nèi)部后續(xù)的新需求，也都由 Doris3 來(lái)承擔(dān)支持。

#2012 MySQL + Doris3 ，百度的第一個(gè) OLAP 平臺(tái)

2012年隨著 Doris3 逐步遷移 Doris2 的同時(shí)，大數(shù)據(jù)時(shí)代悄然到來(lái)。在公司內(nèi)部，隨著百度業(yè)務(wù)的發(fā)展，各個(gè)業(yè)務(wù)端需要更加靈活的方式來(lái)分析已有的數(shù)據(jù)。而此時(shí)的 Doris3 仍然只支持單表的統(tǒng)計(jì)分析查詢，還不能夠滿足業(yè)務(wù)進(jìn)行多維分析的需求。由于缺少通用的 SQL 支持，Doris3 在面對(duì)更加靈活的多維分析場(chǎng)景時(shí)有點(diǎn)力不從心。當(dāng)時(shí)，公司內(nèi)只有 Hive 以及類似系統(tǒng)支持大數(shù)據(jù)量的 SQL 查詢，但是他們均是面向解決離線分析場(chǎng)景，而在線多維分析領(lǐng)域缺少一款產(chǎn)品來(lái)滿足業(yè)務(wù)方的需求。

所以，為了能夠支持業(yè)務(wù)的多維分析需求，Doris3 采用了 MySQL Storage Handler 的方式來(lái)擴(kuò)展 Doris3。通過(guò)此種方式，將 Doris3 偽裝成一個(gè) MySQL 的存儲(chǔ)后端，類似于 MyISAM、InnoDB 一樣。這樣既能夠利用上 MySQL 對(duì)于 SQL 的支持，也能利用上 Doris3 對(duì)于大數(shù)據(jù)量的支持。由于這里 MySQL 是計(jì)算單點(diǎn)，為了減輕 MySQL 的計(jì)算壓力，Doris3 應(yīng)用了 MySQL 的 BKA（Batched Key Access）以及 MRR（Multi-Range Read）等機(jī)制盡量將計(jì)算下推到 Doris3 來(lái)完成，從而減輕 MySQL 的計(jì)算壓力。

通過(guò) MySQL + Doris3 這個(gè)方案，百度 Insight 團(tuán)隊(duì)為 PS、LBS、WISE 等產(chǎn)品線提供了百度內(nèi)部第一個(gè) OLAP 分析服務(wù)平臺(tái)。

#2012 OLAP Engine，突破底層存儲(chǔ)束縛

另一方面 Doris3 支持報(bào)表分析場(chǎng)景時(shí)，底層通用 Key-Value 存儲(chǔ)引擎的弊端也逐漸顯露。

第一，由于 Key-Value 系統(tǒng)讀取只能夠讀取全 Key，全 Value，而報(bào)表分析系統(tǒng)中的大部分查詢并不需要讀取所有列，這樣會(huì)帶來(lái)不必要的 IO 開(kāi)銷；第二，正如前文所說(shuō)，由于引擎本身不感知業(yè)務(wù)模型，不能夠再進(jìn)行 Merge 的同時(shí)完成數(shù)據(jù)的合并，這需要 Doris3 借助復(fù)雜的作業(yè)管理在引擎外部完成 Merge 工作既不簡(jiǎn)潔、也不高效；第三，為了保證業(yè)務(wù)的導(dǎo)入原子性，Doris3 為每批次導(dǎo)入都賦值一個(gè)版本號(hào)，并記錄在每條數(shù)據(jù) Key 的最后部分。這樣在查詢的時(shí)候，需要對(duì)每條數(shù)據(jù)進(jìn)行 Key 的解析，比較版本號(hào)，過(guò)濾掉不需要的版本。這樣一方面需要讀取無(wú)需讀取的數(shù)據(jù)，一方面需要解析所有 Key，從而帶來(lái)不必要的 CPU 開(kāi)銷；第四，Key-Value 系統(tǒng)無(wú)法感知數(shù)據(jù)內(nèi)容，只能使用通用壓縮算法，進(jìn)而導(dǎo)致數(shù)據(jù)的壓縮效率不高。這樣在查詢、讀取時(shí)都會(huì)帶來(lái)較多的 IO 負(fù)載。

為了能夠在底層存儲(chǔ)引擎上有所突破，OLAP Engine項(xiàng)目啟動(dòng)了。這個(gè)項(xiàng)目的發(fā)起者是當(dāng)時(shí)從 Google 來(lái)的高 T，為百度帶來(lái)了當(dāng)時(shí)業(yè)界最領(lǐng)先的底層報(bào)表引擎技術(shù)。OLAP Engine 最大的特點(diǎn)包括以下幾點(diǎn)。

第一，引擎端原生就支持 Schema，并且所有的列分為 Key 列，Value 列。這樣就能夠跟上層的業(yè)務(wù)模型能夠?qū)?yīng)上，查詢部分列時(shí)，無(wú)需加載全部列，減少不必要的 IO 開(kāi)銷。

第二，獨(dú)特的數(shù)據(jù)模型。Value 列支持聚合操作，包括 SUM、MIN、MAX 等。在 Key 列相同的情況下，Value 列就能夠按照聚合操作類型完成對(duì)應(yīng)的聚合操作。而引擎本身導(dǎo)入方式類似于 LSM Tree，這樣在引擎后臺(tái)進(jìn)行 Merge 的同時(shí)，就能夠?qū)⑾嗤?Key 的數(shù)據(jù)中的 Value 字段按照對(duì)應(yīng)的操作進(jìn)行聚合。這樣就無(wú)需外部再進(jìn)行數(shù)據(jù)合并作業(yè)管理，將引擎層與業(yè)務(wù)層合并合二為一，省去不必要的 IO、CPU 開(kāi)銷。

第三，數(shù)據(jù)批量導(dǎo)入，原子生效。對(duì)于每個(gè)批次的導(dǎo)入，都會(huì)有個(gè) Delta 文件對(duì)應(yīng)，并且會(huì)有個(gè)版本號(hào)。在查詢的時(shí)候只是在初始化的時(shí)候來(lái)確定讀取哪個(gè)文件，這樣就只會(huì)讀取生效版本的數(shù)據(jù)，而不會(huì)讀取沒(méi)有生效版本的數(shù)據(jù)，更不會(huì)浪費(fèi) CPU 來(lái)進(jìn)行版本號(hào)比較過(guò)濾。

第四，行列式存儲(chǔ)。多行（比如1024行）數(shù)據(jù)存儲(chǔ)在一個(gè) Block 內(nèi)，Block 內(nèi)相同列的數(shù)據(jù)一同壓縮存放，這樣可以根據(jù)數(shù)據(jù)特征利用不同的壓縮算法（比如對(duì)于時(shí)間字段使用 RLE 等）大幅提高數(shù)據(jù)壓縮效率。

即使分布式層沒(méi)有采用復(fù)雜的分布式管理，只是使用類似 Doris2 的用戶 ID Sharding 方式，OLAP Engine 后續(xù)也成功地支持了鳳巢，網(wǎng)盟等廣告業(yè)務(wù)。這充分體現(xiàn)了 OLAP Engine 強(qiáng)大的報(bào)表分析能力。雖然 OLAP Engine 取得了成功，但是由于硬 Sharding 方案帶來(lái)的不易運(yùn)維、不易擴(kuò)展等問(wèn)題仍然存在。

#2013 用 PALO，玩轉(zhuǎn) OLAP

底層技術(shù)的發(fā)展會(huì)激發(fā)上層業(yè)務(wù)的需求，而上層業(yè)務(wù)的需求同時(shí)會(huì)為底層的技術(shù)帶來(lái)新的挑戰(zhàn)。隨著第一款 OLAP 產(chǎn)品的問(wèn)世，數(shù)據(jù)分析師們的建模就更加復(fù)雜，有時(shí)查詢 SQL 會(huì)有上千行，人為閱讀已經(jīng)相當(dāng)吃力。而 MySQL + Doris3 方案的弊端也就越發(fā)突顯。因?yàn)榉治?SQL 越來(lái)越復(fù)雜，大量的計(jì)算都需要在 MySQL 中完成，這樣 MySQL 的計(jì)算能力就成為整個(gè)系統(tǒng)的性能瓶頸，突破這個(gè)性能瓶頸也就變得極為緊迫。

因此 Doris 亟需一款擁有分布式計(jì)算能力的查詢引擎。幸運(yùn)的是當(dāng)時(shí)（2013年）各種 SQL on Hadoop 項(xiàng)目也正蓬勃發(fā)展，比如 Impala，Tajo，Presto 等等。在有限的時(shí)間內(nèi)并不充分調(diào)研的情況下，團(tuán)隊(duì)選取了 Impala 作為了后續(xù)系統(tǒng)的分布式查詢引擎。當(dāng)時(shí)選擇 Impala 主要的原因是因?yàn)槠湫阅茌^高，并且 BE 的 C++ 語(yǔ)言跟我們已有系統(tǒng)的語(yǔ)言一致，未來(lái)可以省去一部分序列化開(kāi)銷。

由于 MySQL + Doris3 的方案制約了業(yè)務(wù)的使用，當(dāng)時(shí)公司的另一個(gè)團(tuán)隊(duì)邀請(qǐng)了 Oracle 的 Exadata 進(jìn)行 POC，這給了 Doris 團(tuán)隊(duì)很大的壓力。如果 Doris 想繼續(xù)在 OLAP 領(lǐng)域繼續(xù)發(fā)展，就需要快速產(chǎn)出原型，并且性能上還要?jiǎng)俪?Exadata。為了快速驗(yàn)證方案的可行性，團(tuán)隊(duì)幾個(gè)月內(nèi)就把 Impala 與 Doris3 進(jìn)行了集成，并用 TPC-H 進(jìn)行了測(cè)試，結(jié)果是 Impala + Doris3 性能比 Exadata 更好。這次原型的成功為我們贏得了一次機(jī)會(huì)，能夠讓團(tuán)隊(duì)繼續(xù)改造 Doris3 從而更好地支持 OLAP 場(chǎng)景。

新產(chǎn)品的名字命名為 PALO，意為玩轉(zhuǎn) OLAP。

PALO1 除了增加分布式查詢層之外，因?yàn)?OLAP Engine 在統(tǒng)計(jì)報(bào)表領(lǐng)域的成功，PALO1 放棄了 Doris3 依賴的通用 Key-Value 系統(tǒng)，選擇了 OLAP Engine 作為自己的單機(jī)引擎。因?yàn)闆](méi)有了分布式 Key-Value 系統(tǒng)，那么 PALO1 自己完成數(shù)據(jù)分片管理、副本管理等工作。

PALO1 的架構(gòu)如下所示。其中 DM 負(fù)責(zé)管理元數(shù)據(jù)、數(shù)據(jù)的分布、分片副本管理等內(nèi)容，DM 本身沒(méi)有狀態(tài)，元數(shù)據(jù)內(nèi)容都存儲(chǔ)在 MySQL 中。FE 負(fù)責(zé)接收用戶的查詢請(qǐng)求，并且進(jìn)行查詢規(guī)劃解析。BE 是負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，以及進(jìn)行具體的查詢執(zhí)行。

隨著 PALO1 的正式上線，除了遷移所有 Doris3 已有的業(yè)務(wù)外，也成功支持了當(dāng)時(shí)百度內(nèi)部大部分的 OLAP 分析場(chǎng)景。

#2015 PALO2，讓架構(gòu)再簡(jiǎn)單一點(diǎn)

如果說(shuō) PALO1 是為了解決性能問(wèn)題，那么 PALO2 主要是為了在架構(gòu)上進(jìn)行優(yōu)化。由于 PALO1 模塊數(shù)目較多，并且外部依賴 MySQL，這其實(shí)還是增加了運(yùn)維的壓力的。所以我們?cè)?PALO2 項(xiàng)目中力求將系統(tǒng)的架構(gòu)進(jìn)行簡(jiǎn)化。經(jīng)過(guò)簡(jiǎn)化后的系統(tǒng)架構(gòu)如下圖所示。

PALO2 中我們只存在2種模塊：FE、BE。FE 一方面負(fù)責(zé)管理、存儲(chǔ)元數(shù)據(jù)，另一方面 FE 還負(fù)責(zé)與用戶交互，接受用戶查詢，對(duì)查詢規(guī)劃，監(jiān)督查詢執(zhí)行，并將查詢結(jié)果返回給用戶。FE 本身是有狀態(tài)的，但是它內(nèi)部通過(guò) BDB JE，能夠?qū)⒃獢?shù)據(jù)進(jìn)行多副本復(fù)制，從而能夠保證服務(wù)的高可用。BE 與 PALO1 功能一致，只是 PALO2 的 BE 包含了存儲(chǔ)引擎，一方面減少了一個(gè)模塊，并且在用戶查詢的時(shí)候少了一次數(shù)據(jù)的序列化、反序列化操作，節(jié)約 CPU 消耗。

通過(guò) PALO2 的工作，系統(tǒng)架構(gòu)本身變得相當(dāng)簡(jiǎn)潔，并且不需要任何依賴。因?yàn)?PALO2 架構(gòu)的簡(jiǎn)潔，我們后續(xù)也相對(duì)容易的基于 PALO2 提供了公有云服務(wù)以及私有化部署；另一方面，當(dāng) PALO 開(kāi)源之后其他用戶也能夠用通過(guò)較低的門(mén)檻來(lái)搭建使用 PALO 。在此之后 PALO 雖然經(jīng)過(guò)幾次改進(jìn)，但是整體架構(gòu)仍然保持 PALO2 的架構(gòu)。

#2017 and Future Apache Doris (incubating) ，是更廣闊的世界

PALO2 在百度內(nèi)部基本服務(wù)了所有的統(tǒng)計(jì)報(bào)表、多維分析需求，我們相信它一定可以應(yīng)用到其他公司，能夠幫助更多的人更加高效、方便地支持類似的業(yè)務(wù)需求。因此，我們選擇了開(kāi)源，PALO 于2017年正式在 GitHub 上開(kāi)源，并且在2018年貢獻(xiàn)給 Apache 社區(qū)，并將名字改為 Apache Doris（incubating） 進(jìn)行正式孵化。貢獻(xiàn)給 Apache 之后，Doris 就不僅僅是百度的項(xiàng)目，而成為了 Apache 的項(xiàng)目。

隨著開(kāi)源，Doris 已經(jīng)在京東、美團(tuán)、搜狐、小米等公司的生產(chǎn)環(huán)境中正式使用，也有越來(lái)越多的Contributor 加入到 Doris 大家庭中。一路走來(lái)，Doris 從未懼怕過(guò)挑戰(zhàn)，也從未被困難擊倒。時(shí)至今日，Doris 已經(jīng)站在了更高的舞臺(tái)上，準(zhǔn)備擁抱更多的機(jī)遇與挑戰(zhàn)。

希望未來(lái)，會(huì)有更多的人來(lái)續(xù)寫(xiě)這篇 Doris 簡(jiǎn)史，講述這個(gè)為分析而生的故事。