送5本新出版ClickHouse書籍

文末送書！

導(dǎo)讀： ClickHouse速度快的秘訣在于——利用存儲引擎的特殊設(shè)計(jì)充分減少磁盤I/O對查詢速度的影響。

ClickHouse為什么查詢速度快？本文來揭秘。

作者直播，一鍵預(yù)約

0 1 從存儲引擎視角看

ClickHouse速度快的秘訣在于——利用存儲引擎的特殊設(shè)計(jì)充分減少磁盤I/O對查詢速度的影響。從用戶提交一條SQL語句進(jìn)行查詢到最終輸出結(jié)果的過程中，大量的時(shí)間是消耗在了磁盤I/O上，在很多情況下，I/O所占用的時(shí)間可以達(dá)到整個(gè)時(shí)間的90%以上。對存儲引擎磁盤I/O的優(yōu)化可以獲得非常大的收益。ClickHouse的存儲引擎設(shè)計(jì)中大量優(yōu)化的目的也是為了減少磁盤I/O。本節(jié)將從該視角對ClickHouse存儲引擎的優(yōu)化進(jìn)行解讀。

1、預(yù)排序

ClickHouse與傳統(tǒng)事務(wù)數(shù)據(jù)庫的一個(gè)不同之處在于ClickHouse寫入數(shù)據(jù)文件的數(shù)據(jù)時(shí)有序的，這就是本節(jié)將要介紹的預(yù)排序：將數(shù)據(jù)在寫入磁盤前進(jìn)行排序，以保證數(shù)據(jù)在磁盤上有序。

預(yù)排序在數(shù)據(jù)庫系統(tǒng)是一個(gè)被廣泛使用的技術(shù)，在實(shí)現(xiàn)范圍查找時(shí)，可以將大量的隨機(jī)讀轉(zhuǎn)換為順序讀，從而有效提高I/O效率，降低范圍查詢時(shí)的I/O時(shí)間。在點(diǎn)查找時(shí)，預(yù)排序能做到和未排序數(shù)據(jù)相同的性能。因此，預(yù)排序可以在不降低點(diǎn)查找性能的情況下，有效提高范圍查詢的性能。

2、列存

列存數(shù)據(jù)庫和行存數(shù)據(jù)庫最根本的區(qū)別在于列存數(shù)據(jù)庫將一行數(shù)據(jù)拆分到多個(gè)數(shù)據(jù)文件中。在列存數(shù)據(jù)庫中，同一列的所有數(shù)據(jù)都在同一個(gè)文件中，因此在硬盤上是連續(xù)的。這種特性特別適合OLAP的低范式查詢場景。

3、壓縮

ClickHouse的另一個(gè)降低I/O的手段是壓縮，壓縮可以減少讀取和寫入的數(shù)據(jù)量，從而減少I/O時(shí)間。并不是所有場景下都可以引入壓縮的，很顯然，壓縮必然帶來壓縮和解壓縮的CPU消耗，這是一個(gè)利用CPU時(shí)間換I/O時(shí)間的手段。事務(wù)數(shù)據(jù)庫由于大部分情況下是針對行的操作，因此如果對每一行都進(jìn)行一次壓縮解壓縮，帶來的時(shí)間消耗是遠(yuǎn)大于磁盤I/O時(shí)間的。這就是事務(wù)數(shù)據(jù)庫沒有使用壓縮技術(shù)的原因。

而ClickHouse則不同，ClickHouse的最小處理單元是塊，塊一般由8192行數(shù)據(jù)組成，ClickHouse的一次壓縮針對的是8192行數(shù)據(jù)，這就極大降低CPU的壓縮和解壓縮時(shí)間。同時(shí)，ClickHouse是列存數(shù)據(jù)庫，同一列的數(shù)據(jù)相對更有規(guī)律，因此能夠帶來比較大的壓縮比。因此，塊+壓縮在ClickHouse中成為一個(gè)非常關(guān)鍵的優(yōu)化手段。

0 2 從計(jì)算引擎視角看

不同于存儲引擎的設(shè)計(jì)，ClickHouse計(jì)算引擎的設(shè)計(jì)在很多方面都有著很大的爭議，一方面向量化引擎的精妙設(shè)計(jì)讓人拍案叫絕，另一方面相對粗糙的SQL解析和優(yōu)化（解釋）器也讓ClickHouse在執(zhí)行某些操作時(shí)讓用戶咬牙切齒。

1、 ClickHouse速度快的前提

在正式進(jìn)入本節(jié)內(nèi)容之前，我們首先需要明確一個(gè)前提：ClickHous不是在所有場景下都能獲得很強(qiáng)的性能。因此，需要先分析ClickHouse在滿足哪些前提下才能獲得最強(qiáng)的查詢性能。

ClickHouse計(jì)算引擎最精妙的設(shè)計(jì)在于向量化引擎，那么ClickHouse由于計(jì)算引擎原因?qū)е碌目欤隙ㄊ莵碜韵蛄炕娴募映帧?span style="font-size:15px;">而ClickHouse的計(jì)算引擎導(dǎo)致的慢是因?yàn)槿狈Υ鷥r(jià)優(yōu)化器，那么由于計(jì)算引擎導(dǎo)致的慢也來自缺乏代價(jià)優(yōu)化器帶來的缺陷。基于這兩個(gè)邏輯，我們可以分析出ClickHouse速度快的前提。

1）大量使用向量化運(yùn)算

ClickHouse提供了很多內(nèi)置函數(shù)，在使用這些內(nèi)置函數(shù)時(shí)，ClickHouse會自動進(jìn)行向量化優(yōu)化。因此盡可能使用提供的內(nèi)置函數(shù)進(jìn)行計(jì)算，而不是自己寫SQL語句。下面展示錯(cuò)誤的SQL寫法以及正確的寫法。

      
        SELECT (2/(1.0 + exp(-2 * x))-1) as tanh_x  ……    // 錯(cuò)誤的寫法
      
      
        SELECT tanh(x) as tanh_x ……    // 正確的寫法，直接使用ClickHouse的內(nèi)置函數(shù)
      
    

2）查詢語句中沒有使用Join子句，或盡可能少的使用Join操作

ClickHouse沒有代價(jià)優(yōu)化器，這導(dǎo)致了ClickHouse在Join操作時(shí)會出現(xiàn)內(nèi)存不足等情況，導(dǎo)致查詢失敗。Join的性能問題其實(shí)并不僅僅是ClickHouse才遇到，任何數(shù)據(jù)庫在遇到大表Join時(shí)都有可能導(dǎo)致查詢時(shí)間暴增。

大數(shù)據(jù)中的Spark計(jì)算引擎對Join操作做了非常多的優(yōu)化，借助其強(qiáng)大的CBO實(shí)現(xiàn)了Join算法的自動選擇。更是在此基礎(chǔ)上，通過AQE（Adaptive Query Execution,自適應(yīng)查詢引擎），解決了大表Join操作時(shí)遇到數(shù)據(jù)傾斜時(shí)的性能問題。

正是由于ClickHouse沒有實(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建模的過程中大量存在。因此，ClickHouse在設(shè)計(jì)良好的DW上運(yùn)行向量化查詢的性能最高。讀者應(yīng)該盡可能避免將ClickHouse用于ODS的建模工作中。當(dāng)數(shù)據(jù)量大時(shí)，這類建模工作還是盡可能下推到Spark上執(zhí)行。

2、ClickHouse快的本質(zhì)

ClickHouse在滿足上面提到的兩個(gè)條件時(shí)，在不考慮存儲引擎影響的情況下，應(yīng)當(dāng)能夠在計(jì)算引擎上達(dá)到最大的性能。ClickHouse計(jì)算引擎快的本質(zhì)是利用了CPU提供的硬件加速特性。 除此之外，ClickHouse客觀上的確在一些環(huán)節(jié)存在著一些問題，個(gè)人認(rèn)為這些問題和ClickHouse的定位有關(guān)。ClickHouse在設(shè)計(jì)之初就給自身進(jìn)行了清晰的定位——充分發(fā)揮單機(jī)性能的OLAP引擎。在此基礎(chǔ)上，分布式的join能力其實(shí)并不重要，畢竟業(yè)界已經(jīng)有Spark了，完全可以將ClickHouse建立在Spark之上，由Spark解決建模問題，由ClickHouse強(qiáng)大的DW分析能力實(shí)現(xiàn)OLAP的最后一公里問題。 作為用戶，我們應(yīng)該清晰地了解ClickHouse速度快的前提，有意識地避開ClickHouse的雷區(qū)，不要將ClickHouse用于其不擅長的場景。正如此時(shí)此刻，大家都意識到了MySQL無法解決大數(shù)據(jù)量的OLAP問題，這類問題要通過專業(yè)的OLAP引擎解決。 開源社區(qū)要的并不是什么能力都有的但都不強(qiáng)的平庸的軟件，而是百花齊放，各自有著各自擅長的領(lǐng)域，通過組合實(shí)現(xiàn)架構(gòu)上的合力。以上僅代表作者個(gè)人觀點(diǎn)，歡迎讀者有不同意見，大家互相討論。

0 3 總結(jié)

本文分別對ClickHouse的存儲引擎和計(jì)算引擎進(jìn)行了簡單分析，分別得出了ClickHouse速度快的不同的前提。 存儲引擎需求的前提如下。

• 使用MergeTree存儲引擎。
• 按照業(yè)務(wù)需求，正確設(shè)置數(shù)據(jù)表的排序鍵，查詢時(shí)需滿足最左原則。

計(jì)算引擎架構(gòu)要求的前提如下。

• 沒有或少用Join操作。
• 盡可能多地使用內(nèi)置函數(shù)。
  

當(dāng)滿足如上4個(gè)條件時(shí)，使用ClickHouse才有可能達(dá)到比較優(yōu)秀的性能。

關(guān)于作者： 陳峰 ，資深大數(shù)據(jù)專家和架構(gòu)師，ClickHouse技術(shù)專家，滴普科技（2B領(lǐng)域獨(dú)角獸）合伙人兼首席架構(gòu)師。 《 ClickHouse性能之巔： 從架構(gòu)設(shè)計(jì)解讀性能之謎 》作者。

推薦語： 滴普合伙人兼首席架構(gòu)師/資深ClickHouse專家撰寫，從架構(gòu)剖析ClickHouse底層邏輯，總結(jié)大量性能調(diào)優(yōu)方法

直播間新書限時(shí)5折發(fā)售，一鍵預(yù)約

      
          粉絲福利
        
      

如何獲得書籍？

因?yàn)楣娞柣貜?fù)抽獎(jiǎng)有職業(yè)羊毛黨專門擼書，所以峰哥決定在朋友圈讓大家參與，一方面限制羊毛黨，另外一方面也能控制參與人數(shù)，讓大家中獎(jiǎng)幾率更大。

已經(jīng)加我微信的同學(xué)，我會將 抽獎(jiǎng)鏈接 發(fā)到 朋友圈 里，大家記得及時(shí)參與。 不是我好友的，可以添加下方微信，備注【 書籍 】我會通過，通過之后大家直接去朋友圈參與即可。

▲添加上方二維碼好友▲

▲備注「書籍」，參與抽獎(jiǎng)▲