聊聊分布式 SQL 數(shù)據(jù)庫Doris(一)

這篇具有很好參考價值的文章主要介紹了聊聊分布式 SQL 數(shù)據(jù)庫Doris(一)。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

MPP

MPP:Massively Parallel Processing, 即大規(guī)模并行處理.

一般用來指多個SQL數(shù)據(jù)庫節(jié)點搭建的數(shù)據(jù)倉庫系統(tǒng). 執(zhí)行查詢的時候, 查詢可以分散到多個SQL數(shù)據(jù)庫節(jié)點上執(zhí)行, 然后匯總返回給用戶.

Doris

Doris 作為一款開源的 MPP 架構 OLAP 高性能、實時的分析型數(shù)據(jù)庫，能夠運行在絕大多數(shù)主流的商用服務器上。

架構組成

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命名子目錄。因此選擇了這三種技術的組合。

聊聊分布式 SQL 數(shù)據(jù)庫Doris(一)

使用場景

如下圖所示，數(shù)據(jù)源經過各種數(shù)據(jù)集成和加工處理后，通常會入庫到實時數(shù)倉 Doris 和離線湖倉（Hive, Iceberg, Hudi 中），Apache Doris 被廣泛應用在以下場景中。

報表分析
- 實時看板（Dashboards）
- 面向企業(yè)內部分析師和管理者的報表
- 面向用戶或者客戶的高并發(fā)報表分析（Customer Facing Analytics）。比如面向網(wǎng)站主的站點分析、面向廣告主的廣告報表，并發(fā)通常要求成千上萬的 QPS ，查詢延時要求毫秒級響應。著名的電商公司京東在廣告報表中使用 Apache Doris ，每天寫入 100 億行數(shù)據(jù)，查詢并發(fā) QPS 上萬，99 分位的查詢延時 150ms。
即席查詢（Ad-hoc Query）：面向分析師的自助分析，查詢模式不固定，要求較高的吞吐。小米公司基于 Doris 構建了增長分析平臺（Growing Analytics，GA），利用用戶行為數(shù)據(jù)對業(yè)務進行增長分析，平均查詢延時 10s，95 分位的查詢延時 30s 以內，每天的 SQL 查詢量為數(shù)萬條。
統(tǒng)一數(shù)倉構建：一個平臺滿足統(tǒng)一的數(shù)據(jù)倉庫建設需求，簡化繁瑣的大數(shù)據(jù)軟件棧。海底撈基于 Doris 構建的統(tǒng)一數(shù)倉，替換了原來由 Spark、Hive、Kudu、Hbase、Phoenix 組成的舊架構，架構大大簡化。
數(shù)據(jù)湖聯(lián)邦查詢：通過外表的方式聯(lián)邦分析位于 Hive、Iceberg、Hudi 中的數(shù)據(jù)，在避免數(shù)據(jù)拷貝的前提下，查詢性能大幅提升。

架構概述

Doris整體架構如下圖所示，Doris 架構非常簡單，只有兩類進程

Frontend(FE), 主要負責用戶請求的接入、查詢解析規(guī)劃、元數(shù)據(jù)的管理、節(jié)點管理、生成查詢計劃相關工作。
Backend(BE), 主要負責數(shù)據(jù)存儲、查詢計劃的執(zhí)行。

這兩類進程都是可以橫向擴展的，單集群可以支持到數(shù)百臺機器，數(shù)十 PB 的存儲容量。并且這兩類進程通過一致性協(xié)議來保證服務的高可用和數(shù)據(jù)的高可靠。這種高度集成的架構設計極大的降低了一款分布式系統(tǒng)的運維成本。

FE主要分為三個角色：Leader、Follower、Observer及其作用：

leader, follower: 在Leader宕機之后，F(xiàn)ollower節(jié)點能夠迅速代替Leader的工作，能夠實現(xiàn)實時恢復元數(shù)據(jù)，從而保證對Doris集群不造成任何影響;leader負責數(shù)據(jù)的寫入.
observer: 用來拓展查詢節(jié)點, 僅從leader節(jié)點同步元數(shù)據(jù), Observer只參與讀取，不參與寫入

類似Zookeeper中的節(jié)點角色及其職責。

具體的來說:

Backend（BE）節(jié)點：
- BE 節(jié)點是 Apache Doris 中的數(shù)據(jù)存儲和計算節(jié)點。每個 BE 節(jié)點負責存儲和管理分配給它的表的數(shù)據(jù)。
- 數(shù)據(jù)以分區(qū)為單位存儲在 BE 節(jié)點上，而分區(qū)是表的邏輯組織單位，用于提高查詢性能和管理數(shù)據(jù)。
- BE 節(jié)點還執(zhí)行查詢計劃，進行數(shù)據(jù)的讀寫、計算等操作，是實際進行數(shù)據(jù)處理的節(jié)點。
Frontend（FE）節(jié)點：
- FE 節(jié)點是 Doris 中的前端節(jié)點，負責接收用戶請求、解析查詢語句、生成查詢計劃等前端任務。
- FE 節(jié)點并不存儲實際的數(shù)據(jù)，而是將用戶請求翻譯為查詢計劃，并將查詢計劃發(fā)送給 BE 節(jié)點執(zhí)行。
- FE 節(jié)點還負責元數(shù)據(jù)的管理，包括表的定義、分區(qū)信息、索引等。

在使用接口方面，Doris 采用 MySQL 協(xié)議，高度兼容 MySQL 語法，支持標準 SQL，用戶可以通過各類客戶端工具來訪問 Doris，并支持與 BI 工具的無縫對接。Doris 當前支持多種主流的 BI 產品，包括不限于 SmartBI、DataEase、FineBI、Tableau、Power BI、SuperSet 等，只要支持 MySQL 協(xié)議的 BI 工具，Doris 就可以作為數(shù)據(jù)源提供查詢支持。

在存儲引擎方面，Doris 采用列式存儲，按列進行數(shù)據(jù)的編碼壓縮和讀取，能夠實現(xiàn)極高的壓縮比，同時減少大量非相關數(shù)據(jù)的掃描，從而更加有效利用 IO 和 CPU 資源。

列式存儲(column-based) 是相對于傳統(tǒng)關系型數(shù)據(jù)庫的行式存儲(Row-basedstorage)來說的。簡單來說兩者的區(qū)別就是如何組織表：

Doris 也支持比較豐富的索引結構，來減少數(shù)據(jù)的掃描：

Sorted Compound Key Index，可以最多指定三個列組成復合排序鍵，通過該索引，能夠有效進行數(shù)據(jù)裁剪，從而能夠更好支持高并發(fā)的報表場景
Min/Max ：有效過濾數(shù)值類型的等值和范圍查詢
Bloom Filter ：對高基數(shù)列的等值過濾裁剪非常有效
Invert Index ：能夠對任意字段實現(xiàn)快速檢索

在存儲模型方面，Doris 支持多種存儲模型，針對不同的場景做了針對性的優(yōu)化：

Aggregate Key 模型：相同 Key 的 Value 列合并，通過提前聚合大幅提升性能
Unique Key 模型：Key 唯一，相同 Key 的數(shù)據(jù)覆蓋，實現(xiàn)行級別數(shù)據(jù)更新
Duplicate Key 模型：明細數(shù)據(jù)模型，滿足事實表的明細存儲

Duplicate、Aggregate、Unique 模型，都會在建表指定 key 列，然而實際上是有所區(qū)別的：對于 Duplicate 模型，表的key列，可以認為只是 “排序列”，并非起到唯一標識的作用。而 Aggregate、Unique 模型這種聚合類型的表，key 列是兼顧 “排序列” 和 “唯一標識列”，是真正意義上的“ key 列”。索引的創(chuàng)建與key列是直接相關的。

Doris 也支持強一致的物化視圖，物化視圖的更新和選擇都在系統(tǒng)內自動進行，不需要用戶手動選擇，從而大幅減少了物化視圖維護的代價。

在查詢引擎方面，Doris 采用 MPP 的模型，節(jié)點間和節(jié)點內都并行執(zhí)行，也支持多個大表的分布式 Shuffle Join，從而能夠更好應對復雜查詢。

參考：

Doris (Incubating) 原理與實踐文章來源地址http://www.zghlxwxcb.cn/news/detail-746561.html

到了這里，關于聊聊分布式 SQL 數(shù)據(jù)庫Doris(一)的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！