ClickHouse的查詢效能優勢

01

向量化引擎

在儲存引擎的設計上，ClickHouse採用了基於列儲存的儲存結構設計。列儲存在很多場景中極大地降低了資料分析過程中讀取的資料量，圖1展示了列儲存相比於行儲存減少資料量的原理。明顯地，在寬表場景下，由於行儲存在抽取某些列時必須讀取該行的所有列，因此讀取了大量無效的資料(圖1種行存方案中未加▲的深色方塊資料為無效的不參與計算的列)，從而降低了讀取效率。

▲圖1 列存和行存的對比

在計算引擎的設計上,ClickHouse首次使用了向量化計算引擎。向量化計算引擎的計算原理如圖2所示，藉助CPU提供的SIMD技術，可以充分發揮現代計算機體系架構的優勢，最大限度地壓榨單機效能。

▲圖2 SIMD加速原理示意圖

而ClickHouse對單機效能的壓榨，使得ClickHouse可以在單機部署的情況下處理非常大量的資料，在實際使用中，基本上百億以下的資料表，都可以使用單機解決。這種程度的單機處理能力已經可以滿足非常多企業的需要。這也很大程度上解決了傳統大資料數倉帶來的效率低和成本高的問題。

02

高效的資料壓縮

列儲存為ClickHouse帶來的另一個非常明顯的優勢就是大幅度提高了資料壓縮空間。列儲存的本質是將同一列的資料儲存在連續的空間，相比於行儲存，列儲存在連續的空間上更有規律。而規律的儲存，帶來了更大的壓縮率。從而大幅減少壓縮後的資料大小，極大地減少了磁碟的I/O時間。

作者在實際專案中，基本都能做到8:1的壓縮比，即8T的資料只需要1T的儲存空間即可。這個提高了計算效率的同時也降低了儲存成本的。相比於Hadoop的三副本策略，儲存成本大幅降低。

讀者可能會存在這個疑問：Hadoop的三副本能保證資料不丟失，而ClickHouse的儲存是無法保證資料不丟失的，那麼二者是否不能放在一起比較?這個疑問是有一定道理的，二者應用場景不同，面臨的問題也不同。Hadoop如果需要發揮能力，必須有一個龐大的叢集來攤銷低效率帶來的額外處理時間，這意味著叢集中任何一臺機器出現故障，都有可能導致叢集不可用，從機率學上看，假設一臺機器的故障率是1%，那麼100臺機器中有一臺出現故障的機率已經接近100%了。由此可見，在一個龐大的Hadoop叢集中是必須考慮機器故障的。

而ClickHouse則不同，ClickHouse在設計時傾向於榨乾單機效能，在很多場景下用單機解決問題。這種設計使得單機ClickHouse出現故障的機率只有1%，可以在一定程度上忽略機器故障。當然，具體場景需要讀者依據業務需求進行分析，如果確實需要保證資料不丟失，可以使用RAID在物理層面提供保障，也可以使用ClickHouse提供的複製表從軟體上來解決該問題。總之，ClickHouse提供了比較靈活的機制。

03

高效的I/O最佳化

超高的壓縮率為ClickHouse帶來到了更低的資料儲存成本和更低的I/O時間，同時也帶來了計算時的額外開銷——解壓。資料壓縮後儲存到磁碟上，意味著壓縮的資料被讀取後無法直接獲取內容，也就無法參與分析的計算，必須經過解壓還原原始資料，才可以參與計算分析。那麼如何最大限度地減少壓縮時間，甚至在資料被程式讀取前就過濾掉一部分不相關的資料，成為具備壓縮能力的儲存引擎的一大挑戰。

ClickHouse透過基於LSM技術的稀疏索引來應對這個挑戰。透過LSM技術，保證資料寫入磁碟前就已經按照要求做好了排序，這意味著數倉中非常常見的範圍查詢場景可以減少非常大量的I/O時間，從而提升查詢速度。

本文摘編自《ClickHouse效能之巔：從架構設計解讀效能之謎》，經出版方授權釋出。(書號：9787111716587)轉載請保留文章出處。

關於作者：陳峰，資深大資料專家和架構師，ClickHouse技術專家，滴普科技(2B領域獨角獸)合夥人兼首席架構師。《ClickHouse效能之巔：從架構設計解讀效能之謎》作者。