Apache Doris 和 ClickHouse 的深度分析

背景介紹

Apache Doris 是由百度貢獻的開源 MPP 分析型數據庫產品，亞秒級查詢響應時間，支持實時數據分析；分佈式架構簡潔，易於運維，可以支持 10PB 以上的超大數據集；可以滿足多種數據分析需求，例如固定歷史報表，實時數據分析，交互式數據分析和探索式數據分析等。

ClickHouse 是俄羅斯的搜索公司 Yandex 開源的 MPP 架構的分析引擎，號稱比事務數據庫快 100-1000 倍，團隊有計算機體系結構的大牛，最大的特色是高性能的向量化執行引擎，而且功能豐富、可靠性高。

京東當前都在大範圍使用這兩種分析引擎，總集羣規模超過 3000 臺服務器，涵蓋了交易、流量、線下和大屏等各類場景。本文將結合京東團隊的調研成果和幾年的實踐經驗，對 Doris 和 ClickHouse 這兩種分析引擎進行深入對比，驗證廣爲流傳的說法，供大家在場景選型或內核研發時提供一個參考，另外對於兩者社區規劃提供一定的借鑑。

差異和選擇建議

Doris 更優的方面

  1. 使用更簡單，如建表更簡單，SQL 標準支持更好， Join 性能更好，導數功能更強大

  2. 運維更簡單，如靈活的擴縮容能力，故障節點自動恢復，社區提供的支持更好

  3. 分佈式更強，支持事務和冪等性導數，物化視圖自動聚合，查詢自動路由，全面元數據管理

ClickHouse 更優的方面

  1. 性能更佳，導入性能和單表查詢性能更好，同時可靠性更好

  2. 功能豐富，非常多的表引擎，更多類型和函數支持，更好的聚合函數以及龐大的優化參數選項

  3. 集羣管理工具更多，更好多租戶和配額管理，靈活的集羣管理，方便的集羣間遷移工具

那麼兩者之間如何選擇呢？

  1. 業務場景複雜數據規模巨大，希望投入研發力量做定製開發，選 ClickHouse

  2. 希望一站式的分析解決方案，少量投入研發資源，選擇 Doris

另外， Doris 源自在線廣告系統，偏交易系統數據分析；ClickHouse 起源於網站流量分析服務，偏互聯網數據分析，但是這兩類場景這兩個引擎都可以覆蓋。如果說兩者不那麼強的地方，ClickHouse 的問題是使用門檻高、運維成本高和分佈式能力太弱，需要較多的定製化和較深的技術實力，Doris 的問題是性能差一些可靠性差一些，下面就深入分析兩者的差異。

架構分析

從部署運維、分佈式能力、數據導入、查詢、存儲和使用成本等方面進行對比，這部分會涉及到內核中的設計原理、方案和實現，瞭解這些原理會有助於理解上文的結論。

部署運維

部署和日常運維

部署指部署集羣，安裝相關依賴和核心組件，修改配置文件，讓集羣正常運行起來；運維指日常集羣版本更新，配置文件更改、擴縮容等相關事項。集羣所需組件如下：

  1. 左側是 Doris 的部署架構圖，JDBC 指接入協議，DNS 是域名和請求分發系統。Managerment Panel 是管控面。Frontend 指前端模塊簡稱 FE，包含了 SQL 解析、查詢計劃、計劃調度、元數據管理等功能，Backend 指後端模塊簡稱 BE 負責存儲層、數據讀取和寫入，另外還有一個 BrokerLoad 導數組件最好是單獨部署。所以，Doris 一般只需要 FE 和 BE 兩個組件。

  2. 右側是 ClickHouse 的部署架構圖，ClickHouse 本身只有一個模塊，就是 ClickHouse Server，周邊有兩個模塊，如 ClickHouseProxy 主要是轉發請求、配額限制和容災等，ZooKeeper 這塊負責分佈式 DDL 和副本間數據同步，ClickHouseCopier 負責集羣和數據遷移，ClickHouse 一般需要 Server、ZooKeeper 和 CHProxy 三個組件。

  3. 日常運維如更新版本、更改配置文件兩者都需要依賴 Ansible 或者 SaltStack 來進行批量更新。兩者都有部分配置文件可以熱更新，不用重啓節點，而且有 Session 相關參數可以設置可以覆蓋配置文件。Doris 有較多的 SQL 命令協助運維，比如增加節點，Doris 中 Add Backend 即可，ClickHouse 中需要更改配置文件並下發到各個節點上。

多租戶管理

ClickHouse 的權限和 Quota 的粒度更細，可以很方便的支持多租戶使用共享集羣。比如可以設置查詢內存、查詢線程數量、查詢超時等，以便來限制查詢的大小；同時結合查詢併發和一定時間窗口內的查詢數量，以便來控制查詢數量。多租戶的方案，對發展中的業務非常友好，因爲使用共享集羣資源，可以快速動態調整配額，如果是獨佔集羣資源利用率不高、擴容相對麻煩。

集羣遷移

Doris 通過內置的 backup/restore 命令將數據和元數據備份到三方對象存儲或者 HDFS 上，backup 可以通過快照的方式完整導出一致性的數據和元數據，並且可以按照分區來實現增量備份，降低備份的成本。在 Doris 中，有一種變通的遷移集羣的方法，把新機器分批加入到已有的集羣，然後再把舊機器逐步下線，集羣能夠自動均衡，這個過程視集羣數據量可能會持續數天。

ClickHouse 有幾個方法實現數據遷移，數據量大通過自帶的 Clickhouse-copier 工具進行集羣間的數據拷貝，實現數據的跨集羣遷移，需要手工配置很多信息，我們做了一些完善和改進；數據量小通過 SQL 命令 remote 關鍵字實現跨集羣的數據遷移。而官方對實現其他存儲介質的備份和恢復的推薦是採用文件系統的 snapshot 實現，或者可以通過三方工具（https://github.com/AlexAkulov/clickhouse-backup）來實現。

擴容 / 縮容

Doris 支持集羣的在線動態擴縮容，通過內置的 SQL 命令 alter system add/decomission backends 即可進行節點的擴縮容，數據均衡的粒度是 tablet，每個 tablet 大概是數百兆，擴容後表的 tablet 會自動拷貝到新的 BE 節點，如果在線擴容，應該小批量去增加 BE，避免過於劇烈導致集羣不穩定。

ClickHouse 的擴容縮容複雜且繁瑣，目前做不到自動在線操作，需要自研工具支持。擴容時需要部署新的節點，添加新分片和副本到配置文件中，並在新節點上創建元數據，如果是擴副本數據會自動均衡，如果是擴分片，需要手工去做均衡，或自研相關工具，讓均衡自動進行。

分佈式能力

分佈式協議和高可用

Doris 在 FrontEnd 中包含元數據的管理能力，內置了 BerkeleyDB JE HA 組件，包含選舉策略和副本數據同步，提供了 FE 的高可用方案。FE 中管理的元數據也非常豐富，包含節點、集羣、庫、表和用戶信息，以及分區、Tablet 等數據信息，也包含事務、後臺任務、DDL 操作和導數相關任務等信息。

Doris 的 FrontEnd 可以部署 3 個 Follwer + n 個 Oberserver（n>=0）的方式來實現元數據和訪問連接的高可用，Follower 參與選主，在有 Follwer 宕機時，會自動的選舉出新節點保證讀寫高可用，Observer 是隻讀的擴展節點，可以水平擴展實現讀的擴展。BE 通過多副本來實現高可用，一般來說也採取默認的三副本，寫入的時候採用 Quroum 協議保證數據一致性。Doris 的元數據和數據多副本存儲的，能自動複製具有自動災備的能力，服務掛了可以自動重啓，壞一塊盤數據自動均衡，小範圍的節點宕機不會影響集羣對外的服務，但宕機後數據均衡過程會消耗集羣資源，引發短時間的負載過高。架構如下圖：

ClickHouse 目前版本是基於 ZooKeeper 來存儲元數據，包含分佈式的 DDL、表和數據 Part 信息，從元數據豐富程度來說稍弱，因爲存儲了大量細粒度的文件信息，導致 ZooKeeper 經常出現性能瓶頸，社區也有基於 Raft 協議的改進計劃。ClickHouse 依賴 Zookeeper 來實現數據的高可用，Zookeeper 帶來額外的運維複雜性的同時也有性能問題。ClickHouse 沒有集中的元數據管理，每個節點分別管理，高可用一般依賴業務方來實現。ClickHouse 中某個副本節點宕機，對查詢和分佈式表的導入沒有影響，本地表導入要在導數程序中做災備方案比如選擇健康的副本，對 DDL 操作是有影響的，需要及時處理。

在分佈式能力這塊，Doris 在內核側已經實現，使用的代價更低；而 ClickHouse 需要依賴於外部配套的措施去保障，使用成本較高。

事務支持

ACID 指事務的原子性、一致性、隔離性和持久化，OLAP 的事務體現在幾個方面，一是導數，需要保證導數的原子性，同時也要保證明細數據和物化視圖的數據一致性；二是元數據的變更，需要保證所有節點的元數據統一變更的強一致性；三是在節點間做數據均衡時，需要保證數據的一致性。

Doris 提供了導入的事務支持，可以保證導數的冪等性，比如數據導入的原子性，如果有其他錯誤會自動回滾，同時相同標籤的數據不會重複導入。基於導入事務的功能，Doris 還實現了 Flink-connector 這樣的外部組件可以實現數據導入不丟不重。兩者均不支持通用 TP 場景中的 BEGIN/END/COMMIT 語義的事務，很明顯有事務支持的 Doris 比無事務支持的 ClickHouse 要節省很多開發成本，因爲在 ClickHouse 中，這一切都需要外部導數程序來保證。

ClickHouse 不支持事務，需要在外部去做各種校驗和檢查，在導數這塊能保證 100 萬以內的原子性，但是不保證一致性，比如要更新某些字段或者更新物化視圖，這個操作是後臺異步的，需要顯示指定關鍵字 FINAL 來查詢最終數據，而且其他操作沒有事務支持。

DDL 操作兩者都是異步的，但是 Doris 能保證各個節點元數據的一致性，但 ClickHouse 中保證不了，會出現局部節點元數據和其他節點不一致的情況。

數據導入

Doris 中有 RoutineLoad、BrokerLoad 和 StreamLoad 等豐富內置的導數方式，這些功能非常好用，雖然無法處理複雜的 ETL 邏輯，但是支持簡單過濾和轉換函數，也能容忍少量的數據異常，同時支持 ACID 和導數冪等性。

  1. Routineload 支持消費 Kafka 的實時數據，按每批條數、導入間隔和併發數等設置導數參數，用於實時數據的導入；

  2. Brokerload 支持從 HDFS 上導入數據文件，用於離線導數，速度不是很快； 

  3. Streamload 是導數的底層接口，更加高級的功能可以外部程序處理後通過 Steamload 來導入。

ClickHouse 中並沒有後臺導數任務這一概念，它更多的是通過各種引擎去連接到各種存儲系統中，。導數在 1048576 條以內是原子的，要麼都生效，要麼都失敗，但是沒有類似 Doris 中事務 ID 的概念，在 Doris 中相同的事務 ID 插入數據是無效的，這也避免了重複的導數，在 CH 中如果導數重複，只能刪除重新導入。CH 中比較有特色的是既可以寫分佈式表又可以寫本地表。

導入性能因爲 ClickHouse 可以導入本地表，而且沒有事務的限制，所以導入性能差不多是節點磁盤寫入的性能，而 Doris 的導數受限於只能分佈式表的導入，導入性能差一些。

如果數據量少可以使用 OLAP 中的導數，數據量大邏輯複雜，一般使用 Spark/Flink 等外部計算引擎來做 ETL 和導數功能，主要是導數消耗集羣資源

存儲架構

MVCC 模型

Doris 的存儲部分參考 GoogleMesa，採用的 MVCC 模式，MVCC 指 Multi-version concurrency control 多版本控制，通過版本可以實現事務的兩段提交，可以通過版本進行小文件合併，也可以在明細表和物化視圖之間實現強一致性。

ClickHouse 中也是類似，有兩個操作，一種是 Merge 合併小的 Part 文件到一個大的 Part，提升查詢性能避免掃描多個小文件，合併過程類似上圖。另外一種是 Mutation 就是在已有的 Part 中實現數據的變更或元數據的變更，如下圖的 SQL：

ALTER TABLE [db.]table DELETE WHERE filter_expr;
ALTER TABLE [db.]table UPDATE column1 = expr1 [, ...] WHERE filter_expr;

存儲結構

兩者都是列存，列存的好處就是

  1. 分析場景中需要讀大量行但是少數幾個列，只需要讀取參與計算的列即可，極大的減低了 IO，加速了查詢

  2. 同一列中的數據屬於同一類型，壓縮效果顯著，節省存儲空間，降低了存儲成本

  3. 高壓縮比，意味着同等大小的內存能夠存放更多數據，系統 Cache 效果更好

Doris 的數據劃分方式是 Table、Partition、Bucket/Tablet、Segment 幾個部分，其中 Partition 代表數據的縱向劃分分區一般是日期列，Bucket/Tablet 一般指數據的橫向切割分桶規則一般爲某主鍵， Segment 是具體的存儲文件。Segment 中包含數據和索引，數據部分包含多個列的數據按列存放，有三種索引：物理索引、稀疏索引和 ZoneMap 索引。

ClickHouse 中分爲 DistributeTable、LocalTable、Partition、Shard、Part、Column 幾個部分，差不多能和 Doris 對應起來，區別就是 CH 中每個 Column 都對應一組數據文件和索引文件，好處就是命中系統 Cache 性能更高，不好的地方就是 IO 較高且文件數量較多，另外 CH 有 Count 索引，所以 Count 時命中索引會比較快。

通過分區分桶的方式可以讓用戶自定義數據在集羣中的數據分佈方式，降低數據查詢的掃描量，方便集羣的管理。分區作爲數據管理的手段， Doris 支持按照 range 分區，ClickHouse 可以表達式來自定義。Doris 可以通過動態分區的配置來按照時間自動創建新的分區，也可以做冷熱數據的分級存儲。ClickHouse 通過 distrubute 引擎來進行多節點的數據分佈，但是因爲缺少 bucket 這一層，會導致集羣的遷移擴容比較麻煩， Doris 通過分桶的配置可以進一步對數據劃分，方便數據的均衡和遷移。

表引擎 / 模型

兩者都有典型的表類型（引擎類型）的支持

  1. Doris：可重複的 Duplicated Key 就是明細表，按維度聚合的 Aggregate Key，唯一主鍵 Unique Key，UniqueKey 這個可以視爲 AggregateKey 的特例，另外在這三種基礎上可以建立 Rollup（上卷），可以理解爲物化視圖。

  2. ClickHouse : 主要是 MergeTree 表引擎家族，主要是 ReplicatedMergeTree 帶副本的、ReplacingMergeTree 可以更新數據的和 AggregatingMergeTree 可以聚合數據，另外還有內存字典表可以加載數據字典、內存表可以加速查詢或獲得更好寫入性能。CH 比較特殊地方是分佈式表和每個節點的本地表都要單獨創建，物化視圖無法自動路由。

另外，Doris 新開發的 Primary Key 模型，對實時更新場景下的讀性能進行了深度優化，在支持 update 語義的同時，避免了 Unique key 的 sort merge 開銷。在實時 update 的壓力下，查詢性能跟是 Unique key 的 3-15 倍。類似的，相比 ClickHouse 的 ReplicatedMergeTree，也避免了 select final/optimize final 的問題。

數據類型

ClickHouse 中存在較多的複雜類型的支持如 Array/Nested/Map/Tuple/Enum 等，這些類型能夠滿足一些特性場景，還是比較好用的。

數據查詢

查詢架構

分佈式查詢指查詢分佈在多臺服務器上的數據，就如同使用一張表一樣，分佈式 Join 比較繁瑣，Doris 的分佈式 Join 有 Local join，Broadcast join，Shuffle join，Hash join 等方式。ClickHouse 只有 Local 和 Broadcast 兩種 Join，這種架構比較簡單，也限制了 Join SQL 的自由度，變通的方式是通過子查詢和查詢嵌套來實現多級的 Join。

Doris 和 ClickHouse 都支持向量化執行，向量化簡單理解就是一批數據一批數據去執行，可以多行併發執行，同時也提升了 CPU Cache 命中率。在數據庫領域，一直是 Codegen 和 Vectorized 並存，如下圖是 TPC-H 的五個測試 SQL，縱軸是查詢時間，Type 是編譯執行，TW 是向量化執行，可以看出兩者在不同場景下，性能表現不一樣。

併發能力

OLAP 因爲 MPP 架構，每一個 SQL 所有節點都會參與計算，以此來加速海量計算，因此一個集羣的併發能力和單臺沒有太大的區別，所以，OLAP 和數據庫類似，並不是能夠承擔極高併發的系統。但是也並非毫無辦法，比如通過增加副本數來達到承載較大併發的能力。比如 4 個分片 1 個副本，能承擔 100QPS，那麼如果要承擔 500 的 QPS，則只需要把副本數擴展到 5 個副本即可。另外一點很重要的是查詢能否利用到 Cache，包括 ResultCache，Page Cache 和 CPU Cache，這樣併發還能提升一個很大的臺階。

Doris 有兩點比較優勢，一是副本數的設置是在表級別的，只需要把併發大的表設置副本數多一些即可，當然副本數不能超過集羣的節點數，而 ClickHouse 的副本數設置是集羣級別的。

SQL 支持

Doris 與 MySQL 語法兼容，支持 SQL99 規範以及部分 SQL2003 新標準 (比如窗口函數，Grouping sets)。

ClickHouse 部分支持 SQL-2011 標準（https://clickhouse.tech/docs/en/sql-reference/ansi/），但是由於 Planner 的一些限制，ClickHouse 的多表關聯需要對 SQL 做大量改寫工作，比如需要手動下推條件到子查詢中，所以複雜查詢使用不太方便。

ClickHouse 支持支持 ODBC、JDBC、HTTP 接口，Doris 支持 JDBC 和 ODBC 接口。

聯邦查詢

函數支持

0****6

使用成本

使用成本

Doris 使用成本低，是一個強一致性元數據的系統，導數功能較爲完備，查詢 SQL 的標準兼容好無需額外的工作，彈性伸縮能力要好，而 ClickHouse 則需要做較多工作：

  1. ZooKeeper 存在性能瓶頸導致集羣規模不能特別大

  2. 基本無法做到彈性伸縮，純手工擴縮容工作量巨大且容易出錯

  3. 故障節點的容忍度較低，出現一個節點故障會引發某些操作失敗

  4. 導數需要外部保證數據不重不丟，導數失敗需要刪了重導

  5. 元數據需要自己保證各個節點一致性，偶發性的不一致情況較多

  6. 分佈式表和本地表有兩套表結構，較多用戶難以理解

  7. 多表 Join SQL 需要改寫和優化，方言較多幾乎是不兼容其他引擎的 SQL

所以，在大規模實施 ClickHouse 時，需要研發一個比較好用的運維繫統的支持，處理大部分的日常運維工作。

** 代碼框架**

Doris 整體架構分爲 FrontEnd 和 BackEnd，FE 由 Java 編寫，BE 是 C/C++，通信部分是 BRPC。FE 中包含了元數據、SQL Parser、Optimizer、Planner 和 Coodinator 幾個部分，BE 中包含寫入、存儲、索引和查詢執行部分。Doris 的代碼風格整體質量是比較高的，風格統一，有較爲完善的單測用例，如果要在 Doris 上做二次開發，則需要熟悉 Java 或 C++。

ClickHouse 包含 ClickHouse Client/Copier/Server 這幾個比較主要的模塊，其中 Client 是日常使用的命令行客戶端，Copier 是數據遷移工具，Server 是集羣核心服務。Server 部分包含 Parser、Interpreter、Storage、Database、Function 等模塊。代碼整體上是 C++11 以上的風格，大量使用 Poco 庫，大量使用較新的語言特性。

因此 ClickHouse 對二次開發更加友好，技術棧單一，且測試框架完善，模塊間互相依賴關係相對較小。

性能測試

TPC-DS 測試是大數據領域比較常用的一個測試，24 張表、99 個 SQL，可以生成不同容量的數據，京東內部常用來做不同引擎的對比測試。

1） 這兩個引擎都無法全部支持 99 個 SQL，不支持的部分我們根據各個引擎不同特點，進行手工 SQL 改寫讓其能正確執行，Doris 改動量較小，ClickHouse 的多表關聯幾乎都要改寫；

2） 爲了簡化測試過程，我們挑選了 9 個關聯查詢的 SQL，然後自己構造了 9 個單表查詢的 SQL，共 18 個 SQL 來測試性能；

舉個例子

如下是一個典型的多表關聯例子，在 Doris 中不需要做改動，但是在 ClickHouse 中，需要改爲多個 Global Inner Join 來執行， ClickHouse 的多表關聯查詢一般都需要改寫。

--Doris/DorisDB SQL 1
select i_item_id, avg(cs_quantity) agg1, avg(cs_list_price) agg2, avg(cs_coupon_amt) agg3, avg(cs_sales_price) agg4
from catalog_sales, customer_demographics, date_dim, item, promotion
where cs_sold_date_sk = d_date_sk and 
    cs_item_sk = i_item_sk and
    cs_bill_cdemo_sk = cd_demo_sk and
    cs_promo_sk = p_promo_sk and
    cd_gender = 'M' and 
    cd_marital_status = 'D' and
    cd_education_status = 'Advanced Degree' and
    (p_channel_email = 'N' or p_channel_event = 'N') and d_year = 1998 
group by i_item_id order by i_item_id limit 10;
--ClickHouse SQL 1
select i_item_id, avg(cs_quantity) agg1, avg(cs_list_price) agg2, avg(cs_coupon_amt) agg3, avg(cs_sales_price) agg4 from catalog_sales_dist
global inner join (select cd_demo_sk from customer_demographics_dist where cd_gender = 'M' and cd_marital_status = 'D' and cd_education_status = 'Advanced Degree' ) 
on cs_bill_cdemo_sk = cd_demo_sk
global inner join (select d_date_sk from date_dim_dist where d_year = 1998 ) on  cs_sold_date_sk = d_date_sk
global inner join ( select i_item_sk, i_item_id from item_dist ) on cs_item_sk = i_item_sk
global inner join ( select p_promo_sk from promotion_dist where p_channel_email = 'N' or p_channel_event = 'N') on cs_promo_sk = p_promo_sk
group by i_item_id order by i_item_id limit 10;

測試環境

硬件：3 臺 32 核 / 128G 內存 / HDD 磁盤的服務器

軟件：Doris 0.13.1、ClickHouse 21.3.13.1

配置：3 個分片 1 副本，都是默認配置

測試總結

  1. 單表性能 ClickHouse 更好，無論是查詢延時還是併發能力

  2. 多表性能 Doris 優勢更明顯，特別是複雜 Join 和大表 Join 大表的場景，另外 ClickHouse 需要改寫 SQL 有一些工作量

單表延時和併發

單表的 SQL 都比較簡單，大部分是全表分組 group by 之後 avg/sum/count/count distinct 的各種聚合，單表查詢時間如下，可以看出整體上 ClickHouse 要明顯好一些，同時，爲了壓測方便我們找了 2 個延時低的 SQL Single4 和 Single5 測試了一下不同併發下的 QPS，發現也是 ClickHouse 更優一些。

ClickHouse 的單表性能好，得益於向量化執行引擎，在數據密集情況下，利用內存的 PageCache 和 CPU 的 L2 Cache 可以大大加速查詢過程。

Join 的延時和併發

從多表測試來看，Doris 在 Join6、Join7、Join8、Join9 要好一些，Join3 兩者差不多，其他情況 ClickHouse 好一些。同樣，我們挑選了 2 個延時低的 SQL Join8 和 Join9 做了一下併發測試，併發的測試結果和延時表現比較匹配，延時低的 SQL 測試併發時 QPS 同樣高。

Doris 多表關聯有四種 Join 方式，BroadCast Join，Shuffle Join/Bucket Shuffle Join 和 Colocation Join，ClickHouse 只有 Global Join（就是 BroadCast Join）和 Local Join（對應 Colocation Join），因此在大表 Join 大表時，要把右表廣播到所有節點，性能可想而知。

Doris 的執行計劃對 SQL 進行了較多的優化，因此多表關聯中的大部分情況，能找到最優的執行方式，因此多表關聯性能較好一些，但是也並不是所有的關聯 SQL 都要好。

ClickHouse 小表不同數據量下延時

通過上面的測試，大家肯定有疑問，不是說 ClickHouse 的 Join 性能不行麼，爲什麼表現並不差呢？因此，貼一個去年做的一組 ClickHouse 大小表的測試供大家參考，就是用一個大表關聯查詢不同數據規模的小表，看 Join 性能情況怎麼樣。橫軸是指小表的不同數據量，縱軸是執行時間。可以看出，因爲 Join 機制不一樣，ClickHouse 的延時隨小表數據量加大梯度更大，ClickHouse 小表數據量 1000 萬以內尚可，超過 1000 萬性能比就比較差了。

對比表格

上面的對比，是從大的幾個方面來進行的，下面是比較詳細的對比，綠色指我們覺得比較佔優的部分。

8k57HY xyuTIJ 5Sultk DSFFMf qIW8Yt

未來規劃展望

Apache Doris 從測試和使用的過程中看，性能非常不錯，能滿足京東在 OLAP 場景上的需求，後續會逐步上線到更多業務中使用，同時我們也會積極參與到 Apache Doris 開源社區建設中來，憑藉京東在 OLAP 領域深厚的技術積累和實踐經驗，一起把 Apache Doris 這個項目發展成全球領先的分析型數據庫項目。

ClickHouse 在京東也有大規模的使用，在一些極端場景下表現非常出色，零事故支撐了數次大促，京東 OLAP 團隊也在高可用方面有很多心得，自研了基於 Raft 的分佈式元數據管理服務、在線擴縮容提升彈性能力和強大的管控面降低運維複雜度，未來會在雲原生的 OLAP 方面繼續努力，把 ClickHouse 打造爲有京東特色的 OLAP 引擎。

作者：李海波

參考資料

  1. Google mesa：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/42851.pdf

  2. Oracle Berkeley DB High Availability：https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/berkeleydb-je-ha-whitepaper-132079.pdf

  3. ClickHouse 內核分析 - ZooKeeper 在分佈式集羣中的作用 https://developer.aliyun.com/article/762917

  4. ClickHouse Polymorphic Parts 特性淺析 https://www.jianshu.com/p/f3881fae4b9e

  5. Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask http://www.vldb.org/pvldb/vol11/p2209-kersten.pdf

  6. 【Doris 全面解析】存儲層設計介紹 1——存儲結構設計解析

  7. 最佳實踐｜Apache Doris Join 實現與調優實踐

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fyVSRB3wxmsZUx4kY1eQRQ

猜你喜歡