01 向量化引擎

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

▲圖1 列存和行存的對比

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

▲圖2 SIMD加速原理示意圖

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

02 高效的數據壓縮

列存儲為ClickHouse帶來的另一個非常明顯的優(yōu)勢就是大幅度提高了數據壓縮空間。列存儲的本質是將同一列的數據存儲在連續(xù)的空間，相比于行存儲，列存儲在連續(xù)的空間上更有規(guī)律。而規(guī)律的存儲，帶來了更大的壓縮率。從而大幅減少壓縮后的數據大小，極大地減少了磁盤的I/O時間。

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

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

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

03 高效的I/O優(yōu)化

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

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

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

關于作者：陳峰，資深大數據專家和架構師，ClickHouse技術專家，滴普科技（2B領域獨角獸）合伙人兼首席架構師。《ClickHouse性能之巔：從架構設計解讀性能之謎》作者。