ClickHouse 是俄羅斯的 Yandex 于 2016 年開源的列式存儲數據（DBMS），使用 C++語言編寫，主要用于在線分析處理查詢（OLAP），能夠使用 SQL 查詢實時生成分析數據報告

1）Parser與Interpreter

Parser和Interpreter是非常重要的兩組接口：Parser分析器是將sql語句已遞歸的方式形成AST語法樹的形式，并且不同類型的sql都會調用不同的parse實現類。而Interpreter解釋器則負責解釋AST，并進一步創(chuàng)建查詢的執(zhí)行管道。Interpreter解釋器的作用就像Service服務層一樣，起到串聯整個查詢過程的作用，它會根據解釋器的類型，聚合它所需要的資源。首先它會解析AST對象；然后執(zhí)行"業(yè)務邏輯" ( 例如分支判斷、設置參數、調用接口等 )；最終返回IBlock對象，以線程的形式建立起一個查詢執(zhí)行管道。

2）表引擎

表引擎是ClickHouse的一個顯著特性，上文也有提到，clickhouse有很多種表引擎。不同的表引擎由不同的子類實現。表引擎是使用IStorage接口的，該接口定義了DDL ( 如ALTER、RENAME、OPTIMIZE和DROP等 ) 、read和write方法，它們分別負責數據的定義、查詢與寫入。

3）DataType

數據的序列化和反序列化工作由DataType負責。根據不同的數據類型，IDataType接口會有不同的實現類。DataType雖然會對數據進行正反序列化，但是它不會直接和內存或者磁盤做交互，而是轉交給Column和Filed處理。

4）Column與Field

Column和Field是ClickHouse數據最基礎的映射單元。作為一款百分之百的列式存儲數據庫，ClickHouse按列存儲數據，內存中的一列數據由一個Column對象表示。Column對象分為接口和實現兩個部分，在IColumn接口對象中，定義了對數據進行各種關系運算的方法，例如插入數據的insertRangeFrom和insertFrom方法、用于分頁的cut，以及用于過濾的filter方法等。而這些方法的具體實現對象則根據數據類型的不同，由相應的對象實現，例如ColumnString、ColumnArray和ColumnTuple等。在大多數場合，ClickHouse都會以整列的方式操作數據，但凡事也有例外。如果需要操作單個具體的數值 ( 也就是單列中的一行數據 )，則需要使用Field對象，Field對象代表一個單值。與Column對象的泛化設計思路不同，Field對象使用了聚合的設計模式。在Field對象內部聚合了Null、UInt64、String和Array等13種數據類型及相應的處理邏輯。

5）Block

ClickHouse內部的數據操作是面向Block對象進行的，并且采用了流的形式。雖然Column和Filed組成了數據的基本映射單元，但對應到實際操作，它們還缺少了一些必要的信息，比如數據的類型及列的名稱。于是ClickHouse設計了Block對象，Block對象可以看作數據表的子集。Block對象的本質是由數據對象、數據類型和列名稱組成的三元組，即Column、DataType及列名稱字符串。Column提供了數據的讀取能力，而DataType知道如何正反序列化，所以Block在這些對象的基礎之上實現了進一步的抽象和封裝，從而簡化了整個使用的過程，僅通過Block對象就能完成一系列的數據操作。在具體的實現過程中，Block并沒有直接聚合Column和DataType對象，而是通過ColumnWith TypeAndName對象進行間接引用。

自從ClickHouse2016年6月15日開源后，ClickHouse中文社區(qū)隨后成立。中文開源組開始以易觀，海康威視,美團，新浪，京東,58,騰訊,酷狗音樂和俄羅斯開源社區(qū)等人員組成，隨著開源社區(qū)的不斷活躍，陸續(xù)有神州數碼，青云，PingCAP，中軟國際等公司成員加入以及其他公司成員加入。初始在群里討論技術后續(xù)有一些大型公司陸續(xù)運用到項目中，介于分享不方便問題解決，建立了相應的論壇。根據交流得知一些大公司已經運用。

最大的應用來自于Yandex的統計分析服務Yandex.Metrica，類似于谷歌Analytics(GA)，或友盟統計，小米統計，幫助網站或移動應用進行數據分析和精細化運營工具，據稱Yandex.Metrica為世界上第二大的網站分析平臺。ClickHouse在這個應用中，部署了近四百臺機器，每天支持200億的事件和歷史總記錄超過13萬億條記錄，這些記錄都存有原始數據（非聚合數據），隨時可以使用SQL查詢和分析，生成用戶報告。

1. 準備工作

1）確定防火墻處于關閉狀態(tài)

2）CentOS 取消打開文件數限制

在 hadoop102 的 /etc/security/limits.conf 文件的末尾加入以下內容

在 hadoop102 的/etc/security/limits.d/20-nproc.conf 文件的末尾加入以下內容

執(zhí)行同步操作

3） CentOS 取消打開文件數限制

4）CentOS 取消 SELINUX

修改/etc/selinux/config 中的 SELINUX=disabled

執(zhí)行同步操作

重啟三臺服務器。

2. 單機安裝

1）在 hadoop102 的/opt/software 下創(chuàng)建 clickhouse 目錄

2）將/2.資料/ClickHouse 下 4 個文件上傳到 hadoop102 的software/clickhouse 目錄下

3）將安裝文件同步到 hadoop103、hadoop104 并rpm執(zhí)行

4）修改配置文件

把 :: 的注釋打開，這樣的話才能讓 ClickHouse 被除本

機以外的服務器訪問

分發(fā)配置文件

sudo /home/atguigu/bin/xsync /etc/clickhouse-server/config.xml

在這個文件中，有 ClickHouse 的一些默認路徑配置，比較重要的

數據文件路徑：/var/lib/clickhouse/

日志文件路徑：/var/log/clickhouse-server/clickhouse-server.log

5）啟動 Server

6）使用 client 連接 server

Clickhouse為什么做查詢分析那么快？

因為clickhouse使用了下列方案：

• clickhouse 數據分區(qū)

• clickhouse 列式存儲

所有的OLAP技術，基本都是使用的列式存儲。其有以下優(yōu)點：

分析場景中往往需要讀大量行但是少量列。在行存儲模式中，所有的列數據都存儲在一個block中，不參與計算的列在IO的時候也需要讀取，造成沒必要的IO浪費。而列式存儲，則只需要讀取參與計算的列即可，極大的減少了IO消耗，加快了查詢效率同一列數據中的數據類型相同，這有利于提高壓縮比，節(jié)省大量存儲空間而壓縮比高，則意味著數據體積小，對應的其IO讀取耗時更短

自由壓縮算法選擇，不同的列可以根據數據類型，來使用不同的壓縮算法高壓縮比，同時也會減少內存消耗，同樣的內存可以緩存更多的數據

• clickhouse 數據壓縮

關于數據壓縮：Clickhouse的數據存儲文件 column.bin中存儲的是一列數據，由于一列是相同的數據類型，所以方便高效壓縮，在進行壓縮的時候，請注意：一個壓縮數據塊由頭信息和壓縮數據兩部分組成，頭信息固定使用9位字節(jié)表示，具體由1個UInt8（1字節(jié)）整型和2個UInt32(4字節(jié))整型組成，分別代表使用的壓縮算法類型、壓縮后的數據大小和壓縮前的數據大小。每個壓縮數據塊的體積，按照其壓縮前的數據字節(jié)大小，都被嚴格控制在64KB ~ 1MB，其上下限分別由 min_compress-block_size(默認65535=64KB)與max_compress_block_size(默認1MB)參數指定。

具體壓縮規(guī)則：

1. 單個批次數據 size < 64KB：如果單個批次數據小于64KB，則繼續(xù)獲取下一批數據后，直至累計到size >= 64KB時，生成下一個壓縮數據塊。如果平均每條記錄小于8byte，多個數據批次壓縮成一個數據塊

2. 單個批次數據 64KB <= size <= 1MB：如果單個批次數據大小在64KB與1MB之間，則直接生成下一個壓縮數據塊

3. > 單個批次數據 size > 1MB：如果單個批次數據直接超過1MB，則首先按照1MB大小截斷并生成下一個壓縮數據塊。剩余數據繼續(xù)依照上述規(guī)則執(zhí)行。此時，會出現一個批次數據生成多個壓縮數據塊的情況。如果平均每條記錄的大小超過128byte，則會把當前這一個批次的數據壓縮成多個數據塊

• clickhouse 數據標記

關于數據標記，數據標記文件也與xxx.bin文件一一對應，是一級索引與數據塊之間關系的數據

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒