本文介紹Doris版本演進規劃和V1.2版本的新特性。
Apache Doris是一個現代化的MPP分析型數據庫產品。僅需亞秒級響應時間即可獲得查詢結果，有效地支持實時數據分析。Apache Doris的分布式架構非常簡潔，易于運維，并且可以支持10PB以上的超大數據集。
Apache Doris可以滿足多(duo)種(zhong)數(shu)據(ju)(ju)分(fen)析(xi)需求，例如固(gu)定歷史報表，實(shi)時數(shu)據(ju)(ju)分(fen)析(xi)，交互(hu)式數(shu)據(ju)(ju)分(fen)析(xi)和探索式數(shu)據(ju)(ju)分(fen)析(xi)等。
Doris-1.1版本回顧：
|
|
特性 |
1.0版本 |
1.1版本 |
優化效果 |
|
1 |
性能優化 |
正式(shi)發(fa)布向量化引擎，查(cha)詢(xun)性能提升，但不穩定 |
默認開啟向量化引擎 |
查詢性能提升： 2.TPCH整(zheng)體提升(sheng)4.5倍。 |
|
2 |
Compaction優化 |
高頻數據導入(ru)場景會出現版本堆積（-235）錯誤(wu)：導入(ru)速(su)度大于(yu)后端數據merge速(su)度時會阻塞導入(ru) |
1. 優化compaction選擇(ze)版(ban)本的策略，避免一次處理選擇(ze)大量版(ban)本而導致線程阻塞(sai) 2. 主動compaction，杜(du)絕(jue)版本堆積錯誤 |
高(gao)QPS數(shu)據導入場景下，處理延時由200ms降(jiang)低至50ms |
|
3 |
LTS與發版周期 |
/ |
1.1版本未(wei)發布較(jiao)多新功能，主要做bug修復和性能優化。 |
2位版本：（2-3個月(yue)）包(bao)括BUG修復和功能(neng)更新（如1.1->1.2） 3位版本：（2-3周）包(bao)括BUG修(xiu)復(fu)和穩定優化(hua)（如1.2.1->1.2.2） |
發版迭代計劃：
用戶在進行版本升級時，需要滿足舊版本bug修復需求，但對新功能的不確定性存在顧慮，所以doris探索LTS(Long-Term-Support)版本的維護，每2-3月更新大版本（2位版本），每2-3周更新小版本（3位版本），3位版本更新代碼變化不大，可回滾，可通過3位版本更新修復緊急問題。
Doris-1.2版本新功能特性：
發布時間：2022年8月
|
特性 |
1.1版本 |
1.2版本 |
優化效果 |
|
|
1 |
冷熱分離 |
采用本地盤(pan)/云磁(ci)盤(pan)實現(xian)數據存儲： 3副本； 單位存儲成本高，無彈性(xing)； 難以根據業務需求(qiu)來計算(suan)存儲(chu)成本； 云磁盤甚至達到9副本 |
1. 支持對(dui)象存儲：糾刪碼(ma)；單(dan)位存儲成本低；無限付費；按(an)需付費 2. Rowset級別的冷熱分(fen)離（Tablet下以(yi)不同Rowset存儲冷數據和(he)熱數據） 3. 冷數據支(zhi)持導入、查詢(xun)、schema change 4. 創建存(cun)儲策略，制定數據(ju)冷卻的(de)時間和位置，支(zhi)持分區級別(bie) 5. 后續(xu)優(you)化：當前(qian)對象(xiang)存(cun)儲(chu)副本(ben)數和本(ben)地副本(ben)數一致(zhi)，后續(xu)會優(you)化為單副本(ben)；通(tong)過緩(huan)存(cun)機制使得(de)對象(xiang)存(cun)儲(chu)中的(de)歷史數據第(di)一次查詢時間可能(neng)較長，但(dan)進行第(di)二次查詢的(de)性(xing)能(neng)等同于本(ben)地盤效(xiao)果
|
1. 存儲成本降(jiang)低70%； 2. 場景：可(ke)以將歷史數據冷存到對(dui)象存儲上，犧牲查詢性能以換取存儲成本的降低。 |
|
2 |
New unique key |
Unique 模型，數據按主鍵做更新，merge-on-read機制，計算(suan)和查(cha)詢過程中進(jin)行(xing)大量歸并、排序、比較(jiao)等(deng)操(cao)作，無法了解非KEY列的謂詞下推，性能較(jiao)差 |
1. 基于主鍵(jian)索引(yin)，在(zai)做數據導入時(shi)在(zai)索引(yin)中查(cha)找(zhao)并標(biao)記(ji)狀態記(ji)錄(lu)在(zai)delete bitmap中，數據讀(du)取時(shi)先通過delete bitmap過濾，減(jian)少(shao)讀(du)取時(shi)的歸(gui)并排序 2. 高頻導入場景，會(hui)產生(sheng)多個(ge)(ge)版本數據，如果每個(ge)(ge)版本查找主(zhu)(zhu)鍵(jian)效率較低(di)，通過添加索(suo)引可快速檢索(suo)所(suo)需主(zhu)(zhu)鍵(jian) 3. merge-on-write，將歸并等(deng)處理放在寫入階段，提升查(cha)詢階段的性能 |
1. 寫(xie)入性能降低30%； （append->append+lookup） 2. 查(cha)詢(xun)性能提升10倍，接近明細模(mo)型的查(cha)詢(xun)效(xiao)率 3. 適合場(chang)(chang)景：對寫入(ru)壓力不大，查(cha)詢性能要(yao)求高的場(chang)(chang)景 |
|
3 |
Light schema change |
無法支持上游schema變更（如加減列），schema同步延遲(chi)在分鐘級別，會造成數據堆積 |
1. 輕量級schema change 2. 只修改FE元數據 3. 毫秒級的加減(jian)列更新(xin) 4. 底(di)層數據不動 5. tablet下(xia)放(fang)到rowset級別，對應(ying)標記schema，寫(xie)入rowset時(shi)，如果schema變更，會(hui)使用新(xin)的(de)(de)schema寫(xie)新(xin)的(de)(de)rowset，數(shu)據查詢時(shi)保(bao)證每一(yi)個rowset的(de)(de)schema自解釋 |
1. 支(zhi)持同步(bu)元數據變更 2. 適合(he)場(chang)景(jing)：上游(you)(you)數據(ju)通過(guo)CDC同步到下游(you)(you)，上游(you)(you)業務(wu)數據(ju)經常變(bian)更，schema變(bian)更情況的場(chang)景(jing) |
|
4 |
New mem tracker |
內存統計(ji)不(bu)完善，大查詢會(hui)導致進(jin)程OOM，BE掛掉 |
1. 自動(dong)統計(ji)內存開銷(xiao) 2. 進程(cheng)級內存限(xian)制(zhi)，防止OOM 3. 查詢級別內存限制 4. 查詢內存超限時會自(zi)動(dong)取消(xiao)查詢 5. 算子級別(bie)內存統(tong)計(ji)，提升可觀測(ce)性 |
通過(guo)內存限制，避(bi)免進程OOM，減(jian)少集(ji)群節(jie)點故障
|
|
5 |
Multi catalog |
查詢外表需手動創建外表table，使用不方(fang)便 |
1. 對(dui)應(ying)多(duo)數據源的catalog 2. 只(zhi)需建(jian)立連(lian)接就(jiu)可以自動同步外(wai)表 |
支持多種外部數據源的聯邦查詢 |
