ClickHouse為什么查詢(xún)速度快？
一、從存儲(chǔ)引擎視角看
ClickHouse速度快的秘訣在于——利用存儲(chǔ)引擎的特殊設(shè)計(jì)充分減少磁盤(pán)I/O對(duì)查詢(xún)速度的影響。從用戶(hù)提交一條SQL語(yǔ)句進(jìn)行查詢(xún)到最終輸出結(jié)果的過(guò)程中，大量的時(shí)間是消耗在了磁盤(pán)I/O上，在很多情況下，I/O所占用的時(shí)間可以達(dá)到整個(gè)時(shí)間的90%以上。對(duì)存儲(chǔ)引擎磁盤(pán)I/O的優(yōu)化可以獲得非常大的收益。ClickHouse的存儲(chǔ)引擎設(shè)計(jì)中大量?jī)?yōu)化的目的也是為了減少磁盤(pán)I/O。本節(jié)將從該視角對(duì)ClickHouse存儲(chǔ)引擎的優(yōu)化進(jìn)行解讀。
1、預(yù)排序
ClickHouse與傳統(tǒng)事務(wù)數(shù)據(jù)庫(kù)的一個(gè)不同之處在于ClickHouse寫(xiě)入數(shù)據(jù)文件的數(shù)據(jù)時(shí)有序的，這就是本節(jié)將要介紹的預(yù)排序：將數(shù)據(jù)在寫(xiě)入磁盤(pán)前進(jìn)行排序，以保證數(shù)據(jù)在磁盤(pán)上有序。
預(yù)排序在數(shù)據(jù)庫(kù)系統(tǒng)是一個(gè)被廣泛使用的技術(shù)，在實(shí)現(xiàn)范圍查找時(shí)，可以將大量的隨機(jī)讀轉(zhuǎn)換為順序讀，從而有效提高I/O效率，降低范圍查詢(xún)時(shí)的I/O時(shí)間。在點(diǎn)查找時(shí)，預(yù)排序能做到和未排序數(shù)據(jù)相同的性能。因此，預(yù)排序可以在不降低點(diǎn)查找性能的情況下，有效提高范圍查詢(xún)的性能。
2、列存
列存數(shù)據(jù)庫(kù)和行存數(shù)據(jù)庫(kù)最根本的區(qū)別在于列存數(shù)據(jù)庫(kù)將一行數(shù)據(jù)拆分到多個(gè)數(shù)據(jù)文件中。在列存數(shù)據(jù)庫(kù)中，同一列的所有數(shù)據(jù)都在同一個(gè)文件中，因此在硬盤(pán)上是連續(xù)的。這種特性特別適合OLAP的低范式查詢(xún)場(chǎng)景。
3、壓縮
ClickHouse的另一個(gè)降低I/O的手段是壓縮，壓縮可以減少讀取和寫(xiě)入的數(shù)據(jù)量，從而減少I(mǎi)/O時(shí)間。并不是所有場(chǎng)景下都可以引入壓縮的，很顯然，壓縮必然帶來(lái)壓縮和解壓縮的CPU消耗，這是一個(gè)利用CPU時(shí)間換I/O時(shí)間的手段。事務(wù)數(shù)據(jù)庫(kù)由于大部分情況下是針對(duì)行的操作，因此如果對(duì)每一行都進(jìn)行一次壓縮解壓縮，帶來(lái)的時(shí)間消耗是遠(yuǎn)大于磁盤(pán)I/O時(shí)間的。這就是事務(wù)數(shù)據(jù)庫(kù)沒(méi)有使用壓縮技術(shù)的原因。
而ClickHouse則不同，ClickHouse的最小處理單元是塊，塊一般由8192行數(shù)據(jù)組成，ClickHouse的一次壓縮針對(duì)的是8192行數(shù)據(jù)，這就極大降低CPU的壓縮和解壓縮時(shí)間。同時(shí)，ClickHouse是列存數(shù)據(jù)庫(kù)，同一列的數(shù)據(jù)相對(duì)更有規(guī)律，因此能夠帶來(lái)比較大的壓縮比。因此，塊+壓縮在ClickHouse中成為一個(gè)非常關(guān)鍵的優(yōu)化手段。
二、從計(jì)算引擎視角看
不同于存儲(chǔ)引擎的設(shè)計(jì)，ClickHouse計(jì)算引擎的設(shè)計(jì)在很多方面都有著很大的爭(zhēng)議，一方面向量化引擎的精妙設(shè)計(jì)讓人拍案叫絕，另一方面相對(duì)粗糙的SQL解析和優(yōu)化（解釋?zhuān)┢饕沧孋lickHouse在執(zhí)行某些操作時(shí)讓用戶(hù)咬牙切齒。
1、 ClickHouse速度快的前提
在正式進(jìn)入本節(jié)內(nèi)容之前，我們首先需要明確一個(gè)前提：ClickHous不是在所有場(chǎng)景下都能獲得很強(qiáng)的性能。因此，需要先分析ClickHouse在滿(mǎn)足哪些前提下才能獲得最強(qiáng)的查詢(xún)性能。
ClickHouse計(jì)算引擎最精妙的設(shè)計(jì)在于向量化引擎，那么ClickHouse由于計(jì)算引擎原因?qū)е碌目欤隙ㄊ莵?lái)自向量化引擎的加持。而ClickHouse的計(jì)算引擎導(dǎo)致的慢是因?yàn)槿狈Υ鷥r(jià)優(yōu)化器，那么由于計(jì)算引擎導(dǎo)致的慢也來(lái)自缺乏代價(jià)優(yōu)化器帶來(lái)的缺陷?；谶@兩個(gè)邏輯，我們可以分析出ClickHouse速度快的前提。
1）大量使用向量化運(yùn)算
ClickHouse提供了很多內(nèi)置函數(shù)，在使用這些內(nèi)置函數(shù)時(shí)，ClickHouse會(huì)自動(dòng)進(jìn)行向量化優(yōu)化。因此盡可能使用提供的內(nèi)置函數(shù)進(jìn)行計(jì)算，而不是自己寫(xiě)SQL語(yǔ)句。下面展示錯(cuò)誤的SQL寫(xiě)法以及正確的寫(xiě)法。
2）查詢(xún)語(yǔ)句中沒(méi)有使用Join子句，或盡可能少的使用Join操作
ClickHouse沒(méi)有代價(jià)優(yōu)化器，這導(dǎo)致了ClickHouse在Join操作時(shí)會(huì)出現(xiàn)內(nèi)存不足等情況，導(dǎo)致查詢(xún)失敗。Join的性能問(wèn)題其實(shí)并不僅僅是ClickHouse才遇到，任何數(shù)據(jù)庫(kù)在遇到大表Join時(shí)都有可能導(dǎo)致查詢(xún)時(shí)間暴增。
大數(shù)據(jù)中的Spark計(jì)算引擎對(duì)Join操作做了非常多的優(yōu)化，借助其強(qiáng)大的CBO實(shí)現(xiàn)了Join算法的自動(dòng)選擇。更是在此基礎(chǔ)上，通過(guò)AQE（Adaptive Query Execution,自適應(yīng)查詢(xún)引擎），解決了大表Join操作時(shí)遇到數(shù)據(jù)傾斜時(shí)的性能問(wèn)題。
正是由于ClickHouse沒(méi)有實(shí)現(xiàn)CBO，因此ClickHouse在實(shí)現(xiàn)Join操作時(shí)，選擇余地很少。尤其是分布式大表Join操作時(shí)，ClickHouse只實(shí)現(xiàn)了廣播連接（Broadcast Join）算法，極大地降低了ClickHouse的Join能力。
在使用ClickHouse時(shí)，應(yīng)當(dāng)盡可能避免Join操作。而Join操作在ODS建模的過(guò)程中大量存在。因此，ClickHouse在設(shè)計(jì)良好的DW上運(yùn)行向量化查詢(xún)的性能最高。讀者應(yīng)該盡可能避免將ClickHouse用于ODS的建模工作中。當(dāng)數(shù)據(jù)量大時(shí)，這類(lèi)建模工作還是盡可能下推到Spark上執(zhí)行。
2、ClickHouse快的本質(zhì)
ClickHouse在滿(mǎn)足上面提到的兩個(gè)條件時(shí)，在不考慮存儲(chǔ)引擎影響的情況下，應(yīng)當(dāng)能夠在計(jì)算引擎上達(dá)到最大的性能。ClickHouse計(jì)算引擎快的本質(zhì)是利用了CPU提供的硬件加速特性。
除此之外，ClickHouse客觀上的確在一些環(huán)節(jié)存在著一些問(wèn)題，個(gè)人認(rèn)為這些問(wèn)題和ClickHouse的定位有關(guān)。ClickHouse在設(shè)計(jì)之初就給自身進(jìn)行了清晰的定位——充分發(fā)揮單機(jī)性能的OLAP引擎。在此基礎(chǔ)上，分布式的join能力其實(shí)并不重要，畢竟業(yè)界已經(jīng)有Spark了，完全可以將ClickHouse建立在Spark之上，由Spark解決建模問(wèn)題，由ClickHouse強(qiáng)大的DW分析能力實(shí)現(xiàn)OLAP的最后一公里問(wèn)題。
作為用戶(hù)，我們應(yīng)該清晰地了解ClickHouse速度快的前提，有意識(shí)地避開(kāi)ClickHouse的雷區(qū)，不要將ClickHouse用于其不擅長(zhǎng)的場(chǎng)景。正如此時(shí)此刻，大家都意識(shí)到了MySQL無(wú)法解決大數(shù)據(jù)量的OLAP問(wèn)題，這類(lèi)問(wèn)題要通過(guò)專(zhuān)業(yè)的OLAP引擎解決。
開(kāi)源社區(qū)要的并不是什么能力都有的但都不強(qiáng)的平庸的軟件，而是百花齊放，各自有著各自擅長(zhǎng)的領(lǐng)域，通過(guò)組合實(shí)現(xiàn)架構(gòu)上的合力。以上僅代表作者個(gè)人觀點(diǎn)，歡迎讀者有不同意見(jiàn)，大家互相討論。
三、總結(jié)
本文分別對(duì)ClickHouse的存儲(chǔ)引擎和計(jì)算引擎進(jìn)行了簡(jiǎn)單分析，分別得出了ClickHouse速度快的不同的前提。
存儲(chǔ)引擎需求的前提如下。
- 使用MergeTree存儲(chǔ)引擎。
- 按照業(yè)務(wù)需求，正確設(shè)置數(shù)據(jù)表的排序鍵，查詢(xún)時(shí)需滿(mǎn)足最左原則。
計(jì)算引擎架構(gòu)要求的前提如下。
- 沒(méi)有或少用Join操作。
- 盡可能多地使用內(nèi)置函數(shù)。
當(dāng)滿(mǎn)足如上4個(gè)條件時(shí)，使用ClickHouse才有可能達(dá)到比較優(yōu)秀的性能。關(guān)于作者：陳峰，資深大數(shù)據(jù)專(zhuān)家和架構(gòu)師，ClickHouse技術(shù)專(zhuān)家，滴普科技（2B領(lǐng)域獨(dú)角獸）合伙人兼首席架構(gòu)師?！禖lickHouse性能之巔：從架構(gòu)設(shè)計(jì)解讀性能之謎》作者。?
