ClickHouse的由來 ClickHouse是什麼資料庫？ClickHouse速度有多快？應用場景是怎麼樣的？ClickHouse是關係型資料庫嗎？ClickHouse目前是很火爆的一款面向OLAP的數據，可以提供秒級的大數據查詢。 Google於2003～2006年相繼發表了三篇論文“Goog ...

ClickHouse的由來

ClickHouse是什麼資料庫？ClickHouse速度有多快？應用場景是怎麼樣的？ClickHouse是關係型資料庫嗎？ClickHouse目前是很火爆的一款面向OLAP的數據，可以提供秒級的大數據查詢。

Google於2003～2006年相繼發表了三篇論文“Google File System”“Google MapReduce”和“Google Bigtable”，將大數據的處理技術帶進了大眾視野。2006年開源項目Hadoop的出現，標志著大數據技術普及的開始，大數據技術真正開始走向普羅大眾。長期以來受限於資料庫處理能力的大數據技術，開始了波瀾壯闊的技術革新浪潮席卷而來。Hadoop最初指代的是分散式文件系統HDFS和MapReduce計算框架，但是它一路高歌猛進，在此基礎之上像搭積木一般快速發展成為一個龐大的生態，包括Yarn、Hive、HBase、Spark等數十種之多組件相繼開源。Hadoop全家桶很快成為了主流。傳統關係型資料庫所構建的數據倉庫，被以Hive為代表的大數據技術所取代，數據查詢分析的查詢計算引擎Spark、Impala、Kylin等都出來了。Hadoop成為大數據的代名詞。

Hadoop雖然帶來了諸多便利性，隨著時代的發展，但是也帶來了一些新的問題。

Hadoop生態化的兩面性：臃腫和複雜。Hadoop生態下的每種組件都自成一體、相互獨立，強強組合的技術組件有些時候顯得過於笨重了。
隨著現代化終端系統對實效性的要求越來越高，Hadoop在海量數據和高時效性的雙重壓力下，速度有點更不上了。

當然這是hadoop生態的確定，但是目前最普及的方案還是hadoop莫屬，但是hadoop生態在大數據量的查詢和組件的笨重確實存在，在日常的數據開發中，數據分析，BI等都需要查詢數據，目前的hadoop查詢引擎提供的查詢速度，相對於ClickHouse，會慢很多。

所以，這款非Hadoop生態、簡單、自成一體的技術組件ClickHouse橫空出世。

ClickHouse背後的研發團隊是一家俄羅斯本土的互聯網企業Yandex公司，2011年在納斯達克上市，它是現今世界上最大的俄語搜索引擎,占據了本國47%以上的搜索市場,Google是它的直接競爭對手。 ClickHouse的前身是一款線上流量分析的產品Yandex.Metrica，類似Google Analytics，隨著Yandex.Metrica業務的發展，其底層架構歷經四個階段，最終形成了大家現在所看到的ClickHouse。

ClickHouse的定義及其優缺點

ClickHouse是一款高性能、MPP架構、列式存儲、具有完備DBMS功能的OLAP資料庫。

ClickHouse可以在存儲數據超過20萬億行的情況下，做到了90%的查詢能夠在1秒內返回。它基本能夠滿足各種數據分析類的場景，並且隨著數據體量的增大，它與Spark、Impala、Kylin對比，優勢也會變得越為明顯。

ClickHouse適用於商業智能領域（BI），也能夠被廣泛應用於廣告流量、Web、App流量、電信、金融、電子商務、信息安全、網路游戲、物聯網等眾多其他領域。應該說它適合的場景，就是OLAP。

ClickHouse不是萬能的。它對於OLTP事務性操作的場景支持有限，它有以下幾點不足。

不支持事務。
不擅長根據主鍵按行粒度進行查詢（雖然支持），故不應該把ClickHouse當作Key-Value資料庫使用。
不擅長按行刪除數據（雖然支持）。

這些弱點並不能視為ClickHouse的缺點，事實上其他同類高性能的OLAP資料庫同樣也不擅長上述的這些方面。因為對於一款OLAP資料庫而言，上述這些能力並不是重點，只能說這是為了極致查詢性能所做的權衡。

ClickHouse為何這麼快的原因

前面我們說了ClickHouse以在存儲數據超過20萬億行的情況下，在1秒內返回查詢，那它是怎麼做到的？主要有下麵的原因。

列式存儲與數據壓縮
列式存儲和數據壓縮，對於一款高性能資料庫來說是必不可少的。如果你想讓查詢變得更快，那麼最簡單且有效的方法是減少數據掃描範圍和數據傳輸時的大小，列式存儲和數據壓縮就可以做到這兩點。
向量化執行
能升級硬體解決的問題，千萬別優化程式。能用錢解決的問題，那都不是問題。
向量化執行，可以簡單地看作一項消除程式中迴圈的優化，是基於底層硬體實現的優化。這裡用一個形象的例子比喻。小胡經營了一家果汁店，雖然店裡的鮮榨蘋果汁深受大家喜愛，但客戶總是抱怨製作果汁的速度太慢。小胡的店裡只有一臺榨汁機，每次他都會從籃子里拿出一個蘋果，放到榨汁機內等待出汁。如果有8個客戶，每個客戶都點了一杯蘋果汁，那麼小胡需要重覆迴圈8次上述的榨汁流程，才能榨出8杯蘋果汁。如果製作一杯果汁需要5分鐘，那麼全部製作完畢則需要40分鐘。為了提升果汁的製作速度，小胡想出了一個辦法。他將榨汁機的數量從1台增加到了8台，這麼一來，他就可以從籃子里一次性拿出8個蘋果，分別放入8台榨汁機同時榨汁。此時，小胡只需要5分鐘就能夠製作出8杯蘋果汁。為了製作n杯果汁，非向量化執行的方式是用1台榨汁機重覆迴圈製作n次，而向量化執行的方式是用n台榨汁機只執行1次。

上圖中，右側為vectorization(向量化計算)，左側為經典的標量計算。將多次for迴圈計算變成一次計算完全仰仗於CPU的SIMD指令集，SIMD指令可以在一條cpu指令上處理2、4、8或者更多份的數據。在Intel處理器上，這個稱之為SSE以及後來的AVX；在ARM處理器上，這個稱之為NEON。

因此簡單來說，向量化計算就是將一個loop——處理一個array的時候每次處理1個數據共處理N次，轉化為vectorization——處理一個array的時候每次同時處理8個數據共處理N/4次，假如cpu指令上可以處理更多份的數據，設為M，那就是N/M次。

為了實現向量化執行，需要利用CPU的SIMD指令。SIMD的全稱是Single Instruction Multiple Data，即用單條指令操作多條數據。現代電腦系統概念中，它是通過數據並行以提高性能的一種實現方式，它的原理是在CPU寄存器層面實現數據的並行操作。ClickHouse目前利用SSE4.2指令集實現向量化執行。

多樣化的表引擎
與MySQL類似，ClickHouse也將存儲部分進行了抽象，把存儲引擎作為一層獨立的介面。目前ClickHouse共擁有合併樹、記憶體、文件、介面和其他6大類20多種表引擎。每一種表引擎都有著各自的特點，用戶可以根據實際業務場景的要求，選擇合適的表引擎使用。
多線程與分散式
多線程處理就是通過線程級並行的方式實現了性能的提升，ClickHouse將數據劃分為多個partition，每個partition再進一步劃分為多個index granularity，然後通過多個CPU核心分別處理其中的一部分來實現並行數據處理。這種設計下，可以使得ClickHouse單條Query就能利用整機所有CPU，極致的並行處理能力，極大的降低了查詢延時。

而分散式數據屬於基於分而治之的基本思想，實現的優化，如果一臺伺服器性能吃緊，那麼就利用多台服務的資源協同處理。這個前提是需要在數據層面實現數據的分散式，因為計算移動比數據移動更加划算，在各伺服器之間，通過網路傳輸數據的成本是高昂的，所以預先將數據分佈到各台伺服器，將數據的計算查詢直接下推到數據所在的伺服器。