一. 大綱

本篇分享下個人在實時數(shù)倉方向的一些使用經(jīng)驗，主要包含了ClickHouse 和 Doris 這兩款目前比較流行的實時數(shù)倉，文章僅代表個人拙見，有問題歡迎指出，Thanks?(?ω?)?

關(guān)于實時數(shù)倉，是目前在互聯(lián)網(wǎng)上比較火的概念，不同于傳統(tǒng)的 T+1 的離線數(shù)倉（Hadoop 之類），實時數(shù)倉更加追求于數(shù)據(jù)的實時分析能力，也更加符合現(xiàn)階段各類分析場景對于數(shù)據(jù)及時性的訴求，例如：ClickHouse 、Doris等都是這一方案的典型代表。

先簡單介紹下本篇討論的兩款實時數(shù)倉產(chǎn)品：

• ClickHouse：由 Yandex(俄羅斯最大的搜索引擎)開源的一個用于實時數(shù)據(jù)分析的基于列存儲的數(shù)據(jù)庫。
• Doris：新一代的國產(chǎn)MPP數(shù)據(jù)庫，由 Apache Doris 數(shù)據(jù)庫演進而來，并且進行了商業(yè)化支持。

二. 調(diào)研過程簡述

2.1. 調(diào)研訴求

項目上由于 MySQL 中的數(shù)據(jù)量極速增長后，MySQL 自身無法承擔(dān)一些實時的olap查詢，所以需要調(diào)研一款實時數(shù)倉來解決。

我這的業(yè)務(wù)訴求比較簡單，大致有以下幾點：

• 實時數(shù)倉需要兼容 MySQL 協(xié)議與 SQL 語法，開發(fā)不需要額外的學(xué)習(xí)成本，可以快速上手。
• 日志類數(shù)據(jù)(只會追加)需要支撐億級別實時分析，而業(yè)務(wù)類數(shù)據(jù)(不斷更新)需要支撐千萬級別實時分析并且對于 JOIN 性能要比較好，因為存在很多 JOIN 查詢。
• 整體架構(gòu)要比較簡單，因為很多項目硬件資源相對緊張，并且同步延遲保持在30秒內(nèi)。
• 數(shù)據(jù)同步過程中并不需要清洗轉(zhuǎn)換，只需要將 MySQL 中的數(shù)據(jù)鏡像復(fù)制到 MPP 中即可。

基本架構(gòu)如下圖所示：

image.png

2.2. ClickHouse 調(diào)研

帶著上述的調(diào)研訴求，我們首先調(diào)研的是 ClickHouse ，因為這是一款以單機性能強悍著稱的 OLAP 數(shù)據(jù)庫，而且當(dāng)時在IT圈里也非常流行。

經(jīng)過我們的調(diào)研測試后，發(fā)現(xiàn) ClickHouse 只適合于日志類流數(shù)據(jù)的分析，而日志流數(shù)據(jù)最大的特點就是數(shù)據(jù)只會追加而不會變更刪除，即所謂的append流。我們用一臺單機的 ClickHouse 就可以支撐上億的日志聚合分析，效果比較滿意，部分查詢場景還可以配合物化視圖達到更極速的分析。

針對于另外一種業(yè)務(wù)類數(shù)據(jù)的分析場景，因為數(shù)據(jù)會不斷的更新，即所謂的change流，和日志流數(shù)據(jù)不太相同，因此我們嘗試了用ReplacingMergeTree引擎的自動合并去重能力，再加上查詢時顯示指定final關(guān)鍵字去達到精確查詢的效果，但是性能方面不盡如人意，特別是 JOIN 場景。

對于 ClickHouse 的集群模式，因為需要引用 zookeeper 實現(xiàn)分布式協(xié)調(diào)，并且還需要創(chuàng)建分布式表，個人覺得比較復(fù)雜，而且測試下來，對于更新場景效果還是不好，其他精確查詢的方式也不太便捷，因此暫時放棄使用ClickHouse實現(xiàn)業(yè)務(wù)數(shù)據(jù)的即時分析，更推薦ClickHous去處理日志流數(shù)據(jù)。

兼容性方面，ClickHouse 兼容 MySQL 協(xié)議，SQL 語法方面和 MySQL 類似，但是部分基本函數(shù)名稱變了，而且列名大小寫敏感，除這2點比較惡心外，其他基本無問題，后續(xù)我們也主要用 ClickHouse 去處理項目上的日志分析，效果還可以。

2.3. Doris 調(diào)研

因為 ClickHouse 無法有效的支撐業(yè)務(wù)類數(shù)據(jù)的分析場景，所以我們繼續(xù)調(diào)研了 Doris ，主要是看重了 Doris 里存在非常適合實時更新場景的主鍵模型(Primary key)，和其比較優(yōu)越的JOIN性能。

經(jīng)過測試對比，Doris 中使用主鍵模型可以很好的支撐業(yè)務(wù)數(shù)據(jù)分析，因為主鍵模型采用了Delete+Insert的策略，保證同一個主鍵下僅存在一條記錄，雖然犧牲了一些寫入性能，但是極大的提升了查詢效率。同時 JOIN 性能也相較于 ClickHouse 提升了很多。

Doris 集群方面不依賴于 ZK ，通過 BE 和 FE 模塊了組成了存算分離的架構(gòu)模型，相比于 ClickHouse 的集群實現(xiàn)簡單很多，因此我們可以很便捷的完成 Doris 集群部署及后期的水平擴展。

最后就是 Doris的兼容性，相比于 ClickHouse ，Doris的 MySQL 兼容性更加優(yōu)秀，基本完全兼容 MySQL 協(xié)議與 SQL 語法，開發(fā)也可以無縫切換到 Doris進行開發(fā)，比較省事。

后期我們主要通過部署 Doris來解決項目上業(yè)務(wù)數(shù)據(jù)的實時分析，不過相較于 ClickHouse 的單機部署，Doris則通常是多節(jié)點部署才能發(fā)揮更好的查詢性能，因此 Doris對于硬件的需求會比 ClickHouse 更加高些。

三. 總結(jié)

總結(jié)一下，如果是需要分析日志流數(shù)據(jù)，更加推薦 ClickHouse ，因為 ClickHouse 單機強悍，可以支撐億級別數(shù)據(jù)量，架構(gòu)簡單，相比于 Doris也更加穩(wěn)定，相比集群，更推薦單機 ClickHouse 。

如果是分析業(yè)務(wù)流數(shù)據(jù)，更加推薦 Doris，因為 Doris對于更新場景性能更加，而且 JOIN 性能更好，而且更加推薦部署 Doris集群，可以充分發(fā)揮 Doris的性能。

如果是混合場景，既有日志分析，也存在業(yè)務(wù)分析，那么也可以用 Doris一套包掉。

image.png