什麼是 Apache Doris
Apache Doris 是一款 MPP 架構的 OLAP 列式存儲資料庫。
三個顯示關鍵詞及一個隐式關鍵詞：MPP 架構、OLAP、列式存儲以及隐藏的全面向量化。
那麼除去這些看起來很高大上的修飾術語，得到的是：Apache Doris 是一款資料庫。
但是這個資料庫究竟有什麼優勢，它能做哪些場景的事，我們根據這些資訊還是無法一目了然的了解。
本篇将給大家做一次梳理，讓不了解\不清楚\不知道 Apache Doris 适用于哪些應用場景的同學，快速對其的應用覆寫範圍有一個大緻的了解，後續會有八篇《Apache Doris 适用場景—— XX 詳解》這樣的分篇來較長的描述分類場景，此篇為淺析和綱要。
為什麼選擇 Apache Doris
以下文字可作為材料貼入選型理由：
運維成本低
部署簡單，二進制包解壓縮配置即可
擴縮容簡單，無需人工幹預 reblance
強大的自愈能力，定期自動進行 bad tablet 修複
使用成本低
高度相容 MySQL 協定，支援 MySQL 連結的地方就能用 Doris
相容 MySQL 文法，無需學更多方言 SQL，會 MySQL 文法即可
生态融合好，無論上遊的資料內建元件，還是下遊的BI報表元件，都有比較好的生态貫通
性能強大
全球範圍内，開源 OLAP 資料庫中，單表大寬表查詢性能與 ClickHouse 為同一梯隊
TPC-H 場景中，聯邦查詢能力比 Prosto 快 2-3 倍
聯表 JOIN 場景中，性能為其他競品的 1.5-2 倍
唯一一個有反向索引覆寫 ES 場景的 OLAP 庫
單 FE 在單表高并發點查場景下可以支援上萬 QPS
等資源下，ELT 任務執行速度比 Hive On MR 快 8-10 倍，比 Hive On Spark 快 2-3 倍
等資源下，比 Impala + Kudu 組合快 3-4 倍
資料流轉簡單
支援 Flink、Kafka、Spark 等資料 ETL 引擎或者消息中間件
支援 HTTP API、LocalFile、Stream 等資料格式導入
支援 MySQL、Hive、ES、Oracle、ClickHouse 等常見資料庫的外表挂載和導入
支援 Hudi、Iceberg、Paimon、Hive 等資料湖産品的生态融合
應用範圍廣
現代化實時資料平台
企業級報表展示平台
DMP/CDP 畫像平台
日志檢索查詢平台
離線數倉加速平台
高并發單表/維表點查平台
強大的活躍社群
500+ 的 Contributor
月活躍 Contributor 100+
Stars 8350+
30+ 的官方微信社群，去重後 1w+ 參與人數
半個月到一個月的新版本疊代周期
SelectDB 組建了三四十人的社群支援團隊做免費技術支援
BUG 響應及使用指導相應在小時級到分鐘級
純國産化的資料庫
完全由國人自主研發
完善的中文文檔
成熟的各個場景解決方案
常見适用場景
場景淺析
Apache Doris 在整個資料流中的位置
1. OLAP 分析引擎庫（大寬表場景）
OLAP 分析引擎庫，一般要選用在單表查詢方向能力比較強的資料庫，比如 ClickHouse、Druid 等，ClickHouse 本身是一款非常優秀的 MPP 資料庫，在大寬表的查詢領域可謂長期獨領風騷，但是自從去年 Apache Doris 完成了全面向量化以後，ClickHouse 就遇到了一生之敵也是一生摯友。
同樣用的 MPP 架構 + 向量化引擎的底層，看的就是哪家在細節上做的更好了，在去年十一期間，社群參與了 ClickHouse 發起的 OLAP 領域天梯榜 ClickBench，成功拿下全球性能第一的位置，并在再未重新打榜的基礎上在榜首待了四個月多月。
綜上，Doris 在 OLAP 大寬表分析場景裡，比 ClickHouse 具有優勢的地方在于易用性、易維護性和高拓展性，水準拓展後無需手動 reblance 即可完成資料的重負載，還有類似 HDFS 的強大三副本自愈能力等。
2. 日志檢索引擎庫
在傳統的日志檢索過程中，一般選用 ElasticSearch 作為存儲和分析庫，除去在搜尋引擎裡使用 ElasticSearch 強大的分詞能力和聯想能力以外，在大部分使用場景中，還是以核心的文本類型全文檢索為常用使用方式，是以 Doris 用 Loki 為代表的輕量索引/無索引架構，設計了反向索引和全文檢索特性。
這樣在隻需要核心文本類型做全文檢索和反向索引的場景裡，一來導入不需要再占據大量的附加索引空間，二來可以提升導入的時效性和效率，三來可以使用标準 SQL 進行半結構化資料的查詢，同時還能将日志資料和其他業務資料或者次元資料進行關聯，無需再進行導數同步，同時支援半結構化資料直接入庫。
用 ElasticSearch 的官方資料測試集測試後，Doris 的存儲成本相較 ElasticSearch 下降 80%，反向索引場景查詢速度快 2.3 倍，導入速度快 4.2 倍。
3. 單表高并發點查引擎庫
在企業應用中，一般會有兩種場景比較常見單表高并發點查，一種是将該庫用于維表關聯，可能會有高 QPS 的單表查詢場景，還有一種是将該庫直接提供給業務系統進行使用，這種場景下要求資料庫必須滿足整個系統工程的壓力。
無論是第一種還是第二種，業界對于單報表高并發點查場景的資料庫選型，一般是用 Redis 和 Hbase，比如在面向企業廣告主、或者是面向營運商消費使用者而言的高并發查詢場景裡，一般是一個明細表要進行各種過濾和聚合，比如要查一段時間内的廣告投放金額、一段時間内的話費消費情況等。
由于一般做 ETL 計算是上遊資料倉庫做的，是以往往這份資料需要在資料倉庫存一份，再在單報表高并發點查引擎庫裡存一份，一方面資料有備援性，存儲成本變大，另一方面資料鍊路變長，治理難度加大，資料時效性變低。
綜上，Doris 2.0 采用了行列混存資料存儲模式，單 FE 可支援上萬 QPS 的單報表高并發點查，完美适配這一場景。
4. 使用者畫像引擎庫
使用者畫像一般面臨的問題有兩個，一個是要極速的預估，一個是要快速的出包。
預估的速度決定了業務使用方在使用過程中是否可以體感比較好的完成業務訴求，而出包（人群包）的速度決定了整個畫像鍊路在觸達時候的時效性。
這一塊 Doris 已經有非常多的成熟案例了，諸如騰訊音樂 DMP、知乎 DMP等案例，可謂是業界的标杆級案例了。
究其底層呢，主要是在 bitmap 位圖索引上的大規模專項優化，包括函數和索引本身。以及為了适配畫像圈選大寬表的不确定性，還做了動态 Schema Change 的能力，極大的降低資料開發過程中的難度和使用難度。
以知乎為例（0.15非向量化版本），6台機器，撐起了1100億使用者資料、750個标簽組、250萬标簽值的畫像查詢任務，在 1000 個圈選條件下達到了 1s 出預估人群數，10個圈選條件下 1s 出人群包的極緻速度。
5. AdHoc 分析引擎庫
在企業日常内部場景中，AdHoc 場景随着大資料的發展變得越來越常見了。
這個場景裡，主打的是資料分析同學的自由編排能力，考驗的是底層引擎庫的查詢能力、分布式 Join 能力以及 CBO + RBO 優化能力。而早在 Doris 立項之初，本身就是為了解決百度内部報表問題的，是以在這個場景裡可謂磨煉了十年的最擅長的場景了。
Doris 是 MPP 架構的全面向量化引擎加持下的實時資料倉庫，在 2.0 會推出新的 CBO 和 RBO，是以這一場景無需贅述，選它就一定可以得到性能加速~
6. 統一網關平台
在湖倉并行時代裡，企業往往會使用大量的元件來分門别類的完成不同場景的應用，比如使用 Hive 建構離線數倉、使用 Hbase 完成高并發點查、使用 ClickHouse 完成 OLAP 大寬表極速查詢、使用 Impala + Kudu 完成 AdHoc 查詢等等，那麼在這麼多元件的情況下，想要拿 MySQL 裡的一個表的資料關聯 Hbase 裡的一個表的資料時，必須得把資料同步到一個庫内，或者再加一層 Presto 元件來統一網關層。
在這樣的複雜度情況下，元件越多意味着風險越高，穩定性越差，是以 Doris 本身自帶了聯邦查詢子產品，可以有效平替 Presto 的應用場景，性能還要優于 Presto 2-3 倍。
基于這一點，Doris 在複雜系統架構引入過程中，還可以采用非侵入式的引入，這樣就極大的降低了企業架構疊代過程中的痛苦，可以無感的進行架構更新和平台能力更新。
7. 實時數倉
實時數倉這個命題在很多場景都是僞命題，因為如果想要真做到實時數倉，必須要在導入、存儲、查詢這三塊都要做到實時，才算是實時倉庫。
目前業界主流的實時化平台是 Flink + Kafka 組合，這個組合有一定的缺點，就是本身的計算消耗資源比較大，出的名額比較固定，且還要解決很多業務上的諸如資料遲到、丢失等問題。
Doris 自身是保證導入事務性的，目前支援微批次的導入，在1台 8C32G 機器做 Flink 節點、3台 16C64G 機器做 Doris 叢集的情況下，壓測可達到 20w/s 的導入速度，同時 Doris 的導入事務就保證了但凡插入成功的資料批次，就一定是實時可見的。
同時 Doris 本身的物化視圖、索引等落盤資料，都是包含在導入事務控制裡的，是以可以做到不丢不重且實時可見性，而且 Doris 還提供了 AGG 聚合模型和 Unique 主鍵模型，在部分名額計算場景裡可以利用 AGG 模型來完成名額聚合計算，導入即計算完成，無需額外排程。
在2.0版本裡，已經開發完成全量級的多表物化視圖，預計2.1版本會開發完增量級的多表物化視圖，屆時 Apache Doris 的實時數倉場景将迎來蛻變級的新生！
8. 現代化資料平台
關于資料平台這個概念，我認為應當是集合了如上衆多能力的一個綜合體，可以給企業内部做報表分析，可以給業務系統提供查詢支援，可以通過埋點日志進行實時分析，可以為名額看闆/BI工具等上層應用提供支援，可以做 ETL/ELT 的離線加工等等，而 Apache Doris，就是一個集百家之長又專心于 OLAP 資料庫本身的一款實時資料倉庫。
Doris 的内表在和 Hive 等規模的情況下進行 ELT/ETL 任務對比時，Hive On MR 綜合執行時間是 Doris 的8-10倍，Hive On Spark 綜合執行時長是 Doris 的2-3倍，在新版本裡還會有保障 ETL/ELT 的三個特性來讓跑的更快、更穩。
是以如果中小企業選型，可以選擇 All In Apache Doris~
小結
Apache Doris 作為一款國産的 OLAP 資料庫，在目前國内開源界的影響力是與日俱增的，越來越多的中小企業選擇 All In Doris 作為自己的資料平台，也有衆多大企業選用 Doris 來解決不同業務線的重要問題，随着 Apache Doris 的進一步發展，一定是可以帶給更多的企業和個人帶來生産力的提升和成本的下降。
是以還在等什麼？速速聯系我加入到 Apache Doris 官方社群群裡開始一起玩耍呀！來感受和體驗一下最火熱的開源社群的熱情和疊代速度吧！