1.概述

Apache Doris 是一個基于MPP架構(gòu)的高性能實時分析 OLAP 引擎，以其極快的速度和易用性而聞名。

它只需要亞秒的響應(yīng)時間即可在海量數(shù)據(jù)下返回查詢結(jié)果，并且不僅可以支持高并發(fā)點查詢場景，還可以支持高吞吐量復(fù)雜分析場景俩莽。

Apache Doris是一個現(xiàn)代化的MPP分析型數(shù)據(jù)庫產(chǎn)品。僅需亞秒級響應(yīng)時間即可獲得查詢結(jié)果乔遮，有效地支持實時數(shù)據(jù)分析扮超。Apache Doris的分布式架構(gòu)非常簡潔，易于運維蹋肮，并且可以支持10PB以上的超大數(shù)據(jù)集出刷。

Apache Doris可以滿足多種數(shù)據(jù)分析需求，例如固定歷史報表坯辩，實時數(shù)據(jù)分析馁龟，交互式數(shù)據(jù)分析和探索式數(shù)據(jù)分析等。令您的數(shù)據(jù)分析工作更加簡單高效濒翻！

MPP ( Massively Parallel Processing )，即大規(guī)模并行處理，在數(shù)據(jù)庫非共享集群中有送，每個節(jié)點都有獨立的磁盤存儲系統(tǒng)和內(nèi)存系統(tǒng)淌喻，業(yè)務(wù)數(shù)據(jù)根據(jù)數(shù)據(jù)庫模型和應(yīng)用特點劃分到各個節(jié)點上辽社，每臺數(shù)據(jù)節(jié)點通過專用網(wǎng)絡(luò)或者商業(yè)通用網(wǎng)絡(luò)互相連接讨衣，彼此協(xié)同計算育苟，作為整體提供數(shù)據(jù)庫服務(wù)议双。非共享數(shù)據(jù)庫集群有完全的可伸縮性饥臂、高可用腊敲、高性能找爱、優(yōu)秀的性價比惯驼、資源共享等優(yōu)勢清蚀。簡單來說匕荸，MPP 是將任務(wù)并行的分散到多個服務(wù)器和節(jié)點上，在每個節(jié)點上計算完成后枷邪，將各自部分的結(jié)果匯總在一起得到最終的結(jié)果 ( 與 Hadoop 相似 )榛搔。

Doris 主要解決 PB 級別的數(shù)據(jù)量（如果高于 PB 級別，不推薦使用 Doris 解決东揣，可以考慮用 Hive 等工具）践惑，解決結(jié)構(gòu)化數(shù)據(jù)，查詢時間一般在秒級或毫秒級嘶卧。

Doris 由百度大數(shù)據(jù)部研發(fā) ( 之前叫百度 Palo尔觉，2018年貢獻到 Apache 社區(qū)后，更名為 Doris )芥吟，在百度內(nèi)部侦铜，有超過200個產(chǎn)品線在使用，部署機器超過1000臺运沦，單一業(yè)務(wù)最大可達到上百 TB泵额。

百度將 Doris 貢獻給 Apache 社區(qū)之后，許多外部用戶也成為了 Doris 的使用者携添，例如新浪微博嫁盲，美團，小米等著名企業(yè)烈掠。

Apache Doris 核心特性：

發(fā)展歷程

2012 年之前羞秤，Doris 的定位就是一個 NoSQL 數(shù)據(jù)庫。

2012~2020 年期間左敌，Doris 的定位是 NewSQL瘾蛋，也就是說除了要兼顧存儲海量數(shù)據(jù)，也要具備 RDBMS 的 ACID 特性以及對于 SQL 的支持能力矫限。

2020 年以后哺哼，Doris 的定位是 Lakehouse佩抹。

關(guān)于 Lakehouse 請參考博客——湖倉一體（Lakehouse）是什么？

2.doris 架構(gòu)

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

Google Mesa（數(shù)據(jù)模型）

• Mesa是一種高度可擴展的分析數(shù)據(jù)存儲系統(tǒng)茵汰，用于存儲與Google的互聯(lián)網(wǎng)廣告業(yè)務(wù)有關(guān)的關(guān)鍵測量數(shù)據(jù)枢里。
• Mesa滿足一系列復(fù)雜且具有挑戰(zhàn)性的用戶和系統(tǒng)需求，包括接近實時的數(shù)據(jù)提取和查詢能力蹂午，以及針對大數(shù)據(jù)和查詢量的高可用性栏豺，可靠性，容錯性和可伸縮性豆胸。但是Mesa本身不提供SQL查詢引擎所以借鑒了下面奥洼。

Apache Impala（MPP Query Engine)

• Impala是一個非常好的MPP SQL查詢引擎，做更多的查詢優(yōu)化配乱，在速度上做到了很好溉卓。但是缺少比較完美的分布式存儲引擎，所以需要集成下面搬泥。

Apache ORCFile (存儲格式桑寨，編碼和壓縮)

• 只訪問查詢涉及的列，能大量降低系統(tǒng)I/O忿檩；列數(shù)據(jù)相對來說比較類似尉尾，壓縮比更高；每一列由一個線索來處理燥透，更有利于查詢的并發(fā)處理沙咏。

因此選擇了這三種技術(shù)的組合。

Doris的系統(tǒng)架構(gòu)如下圖： 架構(gòu)很簡潔班套，只設(shè)FE(Frontend)肢藐、BE(Backend)兩種角色、兩個進程吱韭，不依賴于外部組件吆豹，方便部署和運維。

Doris 的整體架構(gòu)和 TiDB 類似理盆，借助 MySQL 協(xié)議痘煤，用戶使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客戶端，都可以直接訪問 Doris猿规。

Doris 中的模塊包括 FE 和 BE 兩類：FE 主要負(fù)責(zé)元數(shù)據(jù)的管理衷快、存儲，以及查詢的解析等姨俩；一個用戶請求經(jīng)過 FE 解析蘸拔、規(guī)劃后师郑，具體的執(zhí)行計劃會發(fā)送給 BE，BE 則會完成查詢的具體執(zhí)行调窍。BE 節(jié)點主要負(fù)責(zé)數(shù)據(jù)的存儲呕乎、以及查詢計劃的執(zhí)行。

2.1 核心組件介紹

Doris 的架構(gòu)很簡潔陨晶，只設(shè) FE(Frontend)、BE(Backend)兩種角色帝璧、兩個進程先誉，不依賴于外部組件，方便部署和運維的烁。

• 以數(shù)據(jù)存儲的角度觀之褐耳，F(xiàn)E 存儲、維護集群元數(shù)據(jù)渴庆；BE 存儲物理數(shù)據(jù)铃芦。
• 以查詢處理的角度觀之, FE 節(jié)點接收、解析查詢請求襟雷，規(guī)劃查詢計劃刃滓，調(diào)度查詢執(zhí)行，* 返回查詢結(jié)果耸弄；BE 節(jié)點依據(jù) FE 生成的物理計劃咧虎，分布式地執(zhí)行查詢。

名詞解釋

FE(Frontend)

主要負(fù)責(zé)查詢的編譯蚁趁，分發(fā)和元數(shù)據(jù)管理。

• 1实胸、管理元數(shù)據(jù)（庫他嫡、表、分區(qū)庐完、tablet副本等信息）钢属，執(zhí)行SQL語句命令。
• 2门躯、FE高可用部署署咽，使用復(fù)制協(xié)議選主和主從同步元數(shù)據(jù)，所有的元數(shù)據(jù)修改操作生音，由FE Leader節(jié)點完成宁否，F(xiàn)E Follower節(jié)點可執(zhí)行讀操作。 元數(shù)據(jù)的讀寫滿足順序一致性缀遍。 FE的節(jié)點數(shù)目采用2n+1慕匠，可容忍n個節(jié)點故障。當(dāng)FE Leader故障時域醇，從現(xiàn)有的Follower節(jié)點重新選主台谊，完成故障切換。
  • Observer節(jié)點僅從 Leader節(jié)點進行元數(shù)據(jù)同步譬挚，不參與選舉锅铅。能夠橫向擴展以提供元數(shù)據(jù)的讀服務(wù)的擴展性。
• 3减宣、FE的SQL layer對用戶提交的SQL進行解析盐须、分析、語義分析和關(guān)系代數(shù)優(yōu)化漆腌，生產(chǎn)邏輯執(zhí)行計劃贼邓。
• 4阶冈、FE的Planner負(fù)責(zé)把邏輯計劃轉(zhuǎn)化為可分布式執(zhí)行的物理計劃，分發(fā)給一組BE塑径。
• 5女坑、FE監(jiān)督，管理BE的上下線统舀，根據(jù)BE的健康狀態(tài)和存活數(shù)匆骗，維持tablet副本的數(shù)量。
• 6誉简、FE協(xié)調(diào)數(shù)據(jù)導(dǎo)入, 保證數(shù)據(jù)導(dǎo)入的一致性绰筛。

BE([Backend]

主要負(fù)責(zé)數(shù)據(jù)的存儲、以及查詢計劃的執(zhí)行

• 1描融、BE管理tablet副本，tablet是table經(jīng)過分區(qū)分桶形成的子表衡蚂，采用列式存儲窿克。
• 2、BE受驅(qū)動FE毛甲，創(chuàng)建或刪除子表年叮。
• 3、BE接收FE分發(fā)的物理執(zhí)行計劃并指定BE coordinator節(jié)點玻募，在BE coordinator的調(diào)度下只损，與其他BE worker共同協(xié)作完成執(zhí)行。
• 4七咧、BE讀取本地的列存儲引擎獲取數(shù)據(jù)跃惫，并通過索引和謂詞下沉快速過濾數(shù)據(jù)。
• 5艾栋、BE后臺執(zhí)行compact任務(wù)爆存，減少查詢時的讀放大。
• 6蝗砾、數(shù)據(jù)導(dǎo)入時, 由FE指定BE coordinator先较，將數(shù)據(jù)以fanout的形式寫入到tablet多副本所在的BE上。

MySQL Client

Doris借助MySQL協(xié)議悼粮，用戶使用任意MySQL的ODBC/JDBC以及MySQL的客戶
端闲勺，都可以直接訪問Doris

Broker

Broker為一個獨立的無狀態(tài)進程。封裝了文件系統(tǒng)接口扣猫，提供Doris讀取遠(yuǎn)端存儲系統(tǒng)中文件的能力菜循，包括HDFS申尤、S3子眶、BOS等

元數(shù)據(jù)

• Doris 采用 Paxos 協(xié)議以及 Memory + Checkpoint + Journal 的機制來確保元數(shù)據(jù)的高性能及高可靠序芦。
• 元數(shù)據(jù)的每次更新臭杰，都首先寫入到磁盤的日志文件中，然后再寫到內(nèi)存中渴杆，最后定期 checkpoint 到本地磁盤上宪塔。相當(dāng)于是一個純內(nèi)存的一個結(jié)構(gòu)磁奖，也就是說所有的元數(shù)據(jù)都會緩存在內(nèi)存之中，從而保證 FE 在宕機后能夠快速恢復(fù)元數(shù)據(jù)某筐，而且不丟失元數(shù)據(jù)比搭。* Leader身诺、follower 和 observer 它們?nèi)齻€構(gòu)成一個可靠的服務(wù)抄囚，這樣如果發(fā)生節(jié)點宕機的情況，在百度內(nèi)部的話穴亏，一般是部署一個 leader 兩個 follower重挑，外部公司目前來說基本上也是這么部署的。就是說三個節(jié)點去達到一個高可用服務(wù)蟆湖。
• 單機的節(jié)點故障的時候其實基本上三個就夠了玻粪，因為 FE 節(jié)點畢竟它只存了一份元數(shù)據(jù)，它的壓力不大伦仍，所以如果 FE 太多的時候它會去消耗機器資源很洋，所以多數(shù)情況下三個就足夠了，可以達到一個很高可用的元數(shù)據(jù)服務(wù)

Doris FE高可用方案：

• 如果你是離線業(yè)務(wù)官脓，對高可用要求不是那么高可以使用 1 FE（Follower leader） + 1 FE（Observer）
• 如果你是實時在線業(yè)務(wù)涝焙，對高可用要求很高，建議使用 3 FE（Follower）赤兴，會自動選舉出一個 leader

數(shù)據(jù)分布及可靠性

Doris 數(shù)據(jù)主要都是存儲在 BE 里面隧哮，BE 節(jié)點上物理數(shù)據(jù)的可靠性通過多副本來實現(xiàn)，默認(rèn)是 3 副本陨帆，副本數(shù)可配置且可隨時動態(tài)調(diào)整,滿足不同可用性級別的業(yè)務(wù)需求采蚀。FE 調(diào)度 BE 上副本的分布與補齊搏存。

如果說用戶對可用性要求不高矢洲，而對資源的消耗比較敏感的話读虏，我們可以在建表的時候選擇建兩副本或者一副本。比如在百度云上我們給用戶建表的時候灾螃，有些用戶對它的整個資源消耗比較敏感揩徊，因為他要付費，所以他可能會建兩副本熄赡。但是我們一般不太建議用戶建一副本齿税，因為一副本的情況下可能一旦機器出問題了，數(shù)據(jù)直接就丟了词渤，很難再恢復(fù)串绩。我們在公司內(nèi)部的話，一般是默認(rèn)建三副本志笼，這樣基本可以保證一臺機器單機節(jié)點宕機的情況下不會影響整個服務(wù)的正常運作把篓。

3.doris內(nèi)部組件及周邊生態(tài)組件介紹

3.1 Frontend（FE）

Java語言開發(fā)韧掩，Doris 系統(tǒng)的元數(shù)據(jù)管理和節(jié)點調(diào)度疗锐。在導(dǎo)入流程中主要負(fù)責(zé)導(dǎo)入 plan 生成和導(dǎo)入任務(wù)的調(diào)度工作，請求接入等

3.2 Backend（BE）

C++語言開發(fā)口芍，Doris 系統(tǒng)的計算和存儲節(jié)點雇卷，執(zhí)行SQL計劃等关划。在導(dǎo)入流程中主要負(fù)責(zé)數(shù)據(jù)的 ETL 和存儲。

3.3 Broker

Broker 為一個獨立的無狀態(tài)進程裤翩。封裝了文件系統(tǒng)接口调榄，提供 Doris 讀取遠(yuǎn)端存儲系統(tǒng)中文件的能力，包括HDFS臼疫，S3烫堤，BOS等

3.4 Mysql Client

Doris 借助 MySQL 協(xié)議，用戶使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客戶端拔创，都可以直接訪問 Doris

3.5 Doris on ES

Doris-On-ES將Doris的分布式查詢規(guī)劃能力和ES(Elasticsearch)的全文檢索能力相結(jié)合富蓄，提供更完善的OLAP分析場景解決方案：

• ES中的多index分布式Join查詢
• Doris和ES中的表聯(lián)合查詢立倍，更復(fù)雜的全文檢索過濾

3.6 ODBC External Table Of Doris

ODBC External Table Of Doris 提供了Doris通過數(shù)據(jù)庫訪問的標(biāo)準(zhǔn)接口(ODBC)來訪問外部表，外部表省去了繁瑣的數(shù)據(jù)導(dǎo)入工作变擒，讓Doris可以具有了訪問各式數(shù)據(jù)庫的能力寝志，并借助Doris本身的OLAP的能力來解決外部表的數(shù)據(jù)分析問題：

• 支持各種數(shù)據(jù)源接入Doris
• 支持Doris與各種數(shù)據(jù)源中的表聯(lián)合查詢材部，進行更加復(fù)雜的分析操作
• 通過insert into將Doris執(zhí)行的查詢結(jié)果寫入外部的數(shù)據(jù)源

3.7 Spark Doris Connector

Spark Doris Connector 可以支持通過 Spark 讀取 Doris 中存儲的數(shù)據(jù)。

• 當(dāng)前版本只支持從Doris中讀取數(shù)據(jù)苦丁。
• 可以將Doris表映射為DataFrame或者RDD物臂，推薦使用DataFrame鹦聪。
• 支持在Doris端完成數(shù)據(jù)過濾蒂秘，減少數(shù)據(jù)傳輸量姻僧。

3.8 Flink Doris Connector

Flink Doris Connector 可以支持通過 Flink 讀取 Doris 中存儲的數(shù)據(jù)。

• 可以將Doris表映射為DataStream或者Table
• 支持通過Flink table的方式使用doris數(shù)據(jù)
• 可以通過Flink table 方式方便的將數(shù)據(jù)通過insert into select方式將數(shù)據(jù)插入到doris表中

3.9 DataX doriswriter

DataX doriswriter 插件赌莺，用于通過 DataX 同步其他數(shù)據(jù)源的數(shù)據(jù)到 Doris 中松嘶。

這個插件是利用Doris的Stream Load 功能進行數(shù)據(jù)導(dǎo)入的。需要配合 DataX 服務(wù)一起使用遵倦。

這個擴展可以很方便的將業(yè)務(wù)數(shù)據(jù)庫中的數(shù)據(jù)快速的抽取導(dǎo)入到doris數(shù)倉中

3.10 Doris output plugin

該插件用于logstash輸出數(shù)據(jù)到Doris官撼，使用 HTTP 協(xié)議與 Doris FE Http接口交互傲绣，并通過 Doris 的 stream load 的方式進行數(shù)據(jù)導(dǎo)入.

3.11 審計日志擴展

Doris 的審計日志插件是在 FE 的插件框架基礎(chǔ)上開發(fā)的。是一個可選插件续搀。用戶可以在運行時安裝或卸載這個插件顷链。

該插件可以將 FE 的審計日志定期的導(dǎo)入到指定 Doris 集群中嗤练，以方便用戶通過 SQL 對審計日志進行查看和分析。

4霜大、使用場景

報表分析可視化

• 實時儀表板
• 內(nèi)部分析師和經(jīng)理的報告
• 高度并發(fā)的面向用戶或面向客戶的報表分析

ad-hoc

• 以分析師為導(dǎo)向的自助服務(wù)分析战坤，具有不規(guī)則的查詢模式和高吞吐量要求残拐。

統(tǒng)一數(shù)據(jù)倉庫建設(shè)

• 一個滿足統(tǒng)一數(shù)據(jù)倉庫建設(shè)需求和簡化復(fù)雜數(shù)據(jù)軟件堆棧的平臺溪食。
• 流批一體
• 實時數(shù)倉

數(shù)據(jù)湖查詢

• 通過使用外部表聯(lián)合位于 Apache Hive、Apache Iceberg 和Apache Hudi 中的數(shù)據(jù)栅组，查詢性能大大提高枢析，同時避免了數(shù)據(jù)復(fù)制醒叁。

參考：
https://doris.apache.org/zh-CN/docs/dev/summary/basic-summary

https://zhuanlan.zhihu.com/p/400642016

https://blog.csdn.net/Shockang/article/details/127062897

https://blog.csdn.net/qq_43141726/article/details/120607561

https://blog.csdn.net/yy8623977/article/details/126072971

https://blog.csdn.net/Hello_Java2018/article/details/124806183