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性能之巔：從架構設計解讀性能之謎》作者。